Jump to content
  • Advertisement
  • entries
    11
  • comments
    14
  • views
    11831

Buh-bye Windows, hello Linux!

Sign in to follow this  
Polydone

1571 views

I've been looking into server hosting for the game server, and since Windows Server does cost a bit to lease and also fires up a bunch of services that I don't need at all I've been looking into Linux.
The server is written in C# and previously Mono was the only realistic alternative for Linux - but it had a reputation for very bad performance in many cases.
.Net Core 1.x was way too restricted feature-wise, but with .Net core 2.x the tables have turned.
So last day I embarked on a mission to port my entire codebase - except for some Windows Forms test projects - into .Net Standard, and created a .Net Core console project to start the service.
This turned out to be totally painless. I wasn't using any functionality that wasn't part of .Net Standard 2.x so it simply just worked.

The next step was to run this on Linux. I have very little experience with Linux but Google works well for most things so I set up a Centos 7 VM in Hyper-V and went to work. The installation did take a few tries and I had to battle a few permission problems when following a guide on installing .Net Core on Centos but they weren't a big hurdle.
Of course when I managed to start the program it crashes immediately, and I found some issues with path names - backslashes and case-sensitivity - when loading game data. These were also fixed pretty easily and soon the server was running.
I couldn't connect to it though from the host system, but this was a simple matter of opening a port in the firewall.

So far I'm already becoming a Linux fan at least when it comes to servers. Running a box without any graphical user interface is in some ways easier.
Everything is a file and everything you can do can be done with a command.
On Windows most things you do when managing a server consist of a complex series of clicking this and that button or file icon, filling out textfields etc. etc. and is hard to document (I'm sure you can also do most things with CMD and Powershell of course)
On Linux it might take some time to research how to do even the simplest thing for a newbie such as myself, but every command needed can simply be stored in a text-file, so that I can easily set up a new server from scratch.
And this file can easily be updated - and reviewed by a Linux expert for troubleshooting.

Sign in to follow this  


0 Comments


Recommended Comments

In my pre-Indie Game Maker career I worked in Investment Banking IT designing and developing mission critical high-performance systems and we used almost entirely Linux.

Linux machines are cheaper, more reliable and waste fewer resources as you can run them without a GUI. Even when you have insane uptime requirements one can cluster them and/or setup load-balancing and fallback system designs with enough machines to achieve the reliability of all but the most specialized systems, at a fraction of the price.

We had them doing everything from hosting clustered load-balanced in-memory caching systems, message queuing infrastructures and databases to being the building blocks of thousands-sized distributed computing clusters for calculating the value of non-market traded financial assets.

Even before that when I was doing other server-side work (such as the server-side of web apps) we overwhelmingly used Linux as it delivers more bang for the buck and for the same hardware is more reliable than Windows.

I have more than a decade of server-side and networked systems design and development expertise and have worked with other OSes on the server side (not just MacOS and WIndows but also more obscure and old OSes) and I can't see myself using anything other than Unix for the server side of things, and unless there are some special requirements for insanelly reliable hardward that comes with its own Unix, that would be Linux.

So applause for doing this transition and keep on with it as it's well worth it.

Share this comment


Link to comment

Do try out linux desktop too. I eventually gave up the whole microsoft ecosystem last year after trying out linux mint, and was so impressed I reformatted all my hard disks to ext, ported all my work, and almost a year and a half later I couldn't be happier. :)

Share this comment


Link to comment

Thanks. When I get around to buying a new computer I'll definitely be looking into creating a dual-boot setup, because I want to release my game for Linux too - might as well since I'm using Unity for the client.

I'm not quite able to switch to Linux as a main desktop because of Visual Studio and games. Pretty much everything else on Windows is non-essential for me, although I'm not 100% sure how well the Unity editor runs on Linux.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Tape_Worm
      Same as the previous image, only using more recent code (hence the lower frame rate).
      A major difference is that I'm using multiple cameras to simulate parallax between the sun, earth,(you can't see it) the moon, and the other ships.
      Doing this little experiment has been so helpful in dog-fooding Gorgon.
    • By Tape_Worm
      Just a test to see what I can actually do with my own library.  And also to learn about this whole ECS thing that everyone's so nuts about.
      Everything in this image is a simple sprite. Without lighting (and the post processing) it looks rather plain and incredibly flat. It's amazing what a couple of lights and some effects can do to spruce up the final output.
    • By Enzo123
      Is it possible to move a sprite with keyboard with C (not in C ++) without SDL library?

      I'm finding for a simple code to do it.

      Thanks

    • By Ruben Torres
      [This post was originally posted with its original formatting at The Gamedev Guru's Blog]
      If you've been following me, you will probably know my interest in Unity Addressables. That is for a reason.

      Unity Addressables is a powerful Unity package that upgrades the way you and I have been tackling some of the most important challenges in Game Development: efficient, pain-free content management.
      When managing your game assets, it's hard to keep good standards that prevent our project from becoming a disgusting pile of mess. A big issue there is the coupling between the different responsibilities of our asset management systems.
      The way we store the assets in our project has way too much to do with the method we load them, and later use them.
      For instance, you may decide to store an innocent sprite in the Resources folder. This, in turn, will force Unity to build the player in a way that that sprite is put into special archive files. And the fact that it was put there, will corner you into loading it through the Resources API.
      Things get messy quicker than you can realize!
      One choice, multiple long-term consequences.
      A good system will prevent you and me from easily making sloppy mistakes like that. A great system will be that, and also easy to learn and use.
      With Unity Addressables, we separate the asset management concerns. Our goal is to remain flexible and to keep our project maintainable.
      Here are 3 proven ways Unity Addressables will help you and your games:

      1. Reduce Your Game's Memory Pressure
      When you publish your game, you'll be required on most platforms to specify the minimum hardware specifications your players must meet to buy and play your game.
      The math is easy here: the more hardware power you demand, the fewer will buy your game. Or, seen from another perspective, the better memory management you do, the higher the amount of content and fun you can offer in your game.
      Unity Addressables helps you in this regard enormously!
      To give you a brief idea, converting this kind of code:
      public class CharacterCustomization : MonoBehaviour { [SerializeField] private List<Material> _armorVariations; [SerializeField] private MeshRenderer _armorRenderer; public void ChangeArmorVariation(int variationId) { _armorRenderer.material = _armorVariations[variationId]; } } Into this other one:
      using UnityEngine.AddressableAssets; public class CharacterCustomizationV2 : MonoBehaviour { [SerializeField] private List<AssetReference> _armorVariations; [SerializeField] private MeshRenderer _armorRenderer; public IEnumerator ChangeArmorVariation(int variationId) { var loadProcess = _armorVariations[variationId].LoadAssetAsync(); yield return loadProcess; _armorRenderer.material = loadProcess.Result; } } Will bring you these results:

      Easy gains I'd say.
      -> Read more on Unity Addressables for better memory management in Unity Addressables: It's Never Too Big to Fit (opens in a new tab)
       

      2. Sell Your Next DLC - Quick and Easy
      The fact that Unity Addessables gives you full control over how, when and where to store and load your game assets is incredibly useful for implementing and selling Downloadable Content.
      Even if you are not thinking of releasing DLCs any time soon, just by using Unity Addressables in your project, you will have done already a big chunk of the work ahead.
      Other approaches for selling DLCs, such as Asset Bundles, are a very deprecated way of doing the same thing but at a much higher cost. Maintaining a well-functioning Asset Bundle pipeline is painfully time-consuming and requires a high degree of expensive expertise.
      There are many ways you can approach implementing DLCs in Unity, but for starters, this is a good starting point:
       
      public class DlcManager : MonoBehaviour { // ... public IEnumerator TryDownloadDlc() { if (_hasBoughtDlc && _dlcDownloaded == false) { var operationHandle = Addressables.DownloadDependenciesAsync("DLC-Content"); while (operationHandle.IsDone == false) { _progressText.text = $"{operationHandle.PercentComplete * 100.0f} %"; yield return null; } } } } You get the idea.
      Why would you say no to selling more entertainment for your players at a fraction of the cost?

      3. Reduce Your Iteration Times
      Using Unity Addressables will reduce the time wasted waiting in several areas.
      Tell me, how frustrating is it to be blocked for half a minute after pressing the Unity play button? And it only gets worse if you deploy your build on another platform, such as mobile or WebGL. This all starts adding minutes and minutes to your iteration times. It gets old so quickly.
      I don't like waiting either.
      But do you know what I like? Unity Addressables, my long-awaited hero. This is how Addressables will help you:
      A) Reduced Build Size
      Your game has a lot of content, I get it. Gamers love enjoying content. Developers love creating content.
      That doesn't mean, however, that every single asset you produced has to be included in the build your players will install. In fact, you should remove as much as possible.
      Players want to start playing ASAP. And they're not happy when your game steals 2GB of their data plan and 30 minutes of their gaming time. They'll just keep downloading Candy Crush kind of games that install well under 50MB.
      One strategy is to include only the assets needed to run your game up to the main menu. Then, you can progressively download the rest of your content in the background, starting, of course, downloading the first level of your game.
      It's also neat to realize that your deployment times during development will be much faster. You'll be able to iterate more times each day; this benefit quickly adds up in the long term.

      Unity Addressables - Reduced Build Sizes
      B) Reduced Load Times
      We, both as game developers and as players, hate waiting. Waiting takes us out of the zone and before you realize it, it is time to go to bed.
      Unity is working hard towards reducing the time it takes us to start playing our games, both in the Unity Editor and in the games we distribute.
      But not hard enough.
      Things look promising in the future, but not without side effects. Avoiding domain reloads in Unity 2019.3 looks promising, but as of today that's still in beta and not everyone can profit from it.
      In the mean-time, we can do better than just being frustrated.
      Let's say you're working on a medieval game. Several months ago, you implemented armor types for your game. You did a pretty damn good job and generated over 100MB of content.
      At some point, it was time to move on and right now you're working on something else, let's say sword fighting.
      Realize that, every time you press the play button to work on your features, you are loading an insane amount of data coming from all the already developed features, and loading this data takes a massive amount of time. You press play to test your sword fighting animations, and you spend 5 seconds waiting due to loading the armor features you implemented.
      The time wasted in loading is mostly spent on I/O (Input/Output), because memory bandwidth is expensive. And, on top of that, your CPU has to process it. You, as a developer, pay this time penalty while developing in the Unity Editor. But your players pay it as well in the games you are distributing.
      Knowing how big of a deal this can be, let's ask ourselves: which shortcuts can we take here?
      It turns out that Unity Addressables can help us here in two ways.
      1. Unity Addressables will reduce your Players' Loading Times
      We can alleviate some of our players' pain.
      Keeping indirect references to our assets instead of direct references will drastically improve your loading times.
      By using indirect references (AssetReference), Unity will not load everything at once but only what you tell it to. And more importantly, you have direct control over when that happens.
      2. Unity Addressables will reduce your Unity Editor Iteration Times
      How much do you know about the play mode script in the Unity Addressables Window? The play mode script defines how the Unity Editor should load the content marked as Addressable.
      With Packed Play Mode selected, Unity will directly load your pre-built addressable assets with little to no processing overhead, effectively reducing your Unity Editor iteration times
      Just do not forget to build the player content for this to work

      Unity Addressables - Build Player Content
      What if you applied these strategies to your most demanding content?
      4. Extra: Are You There Yet?
      It is true. Unity Addressables is very helpful. But this package will help only those who want to be helped.
      After reading how Addressables will help you producing better and selling more to your players, you probably want to start with it right away. However, starting in this new unknown area may be challenging.
      To make the most of your chance, answer these questions first:
      Where are you standing right now? Are you just starting, or are your skills production-ready? When to use indirect references, when to use direct references? What's the bigger picture? What is your next logical step? → Take this short quiz now to test your answers ← (opens in a new tab)

    • By Elliot Nykvist
      Hey!
      I wonder how to program a mobile game in C # that should be like Mario Wanted, but I want the object to be still and when you click on the right guy a new level appear, but if you click on wrong you lose the game
      Thanks in advance!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!