Theoretical: Server version of my game

So, I am currently in the process of making my first game, a little tank battle game, got some progress into it, single player, AI shooty parts, health, life etc.

Then I managed to get this stuff working in multiplayer using the server/client and client modes only 2 player at this point but from my tests, a couple more instances could easily add more players with no issues.

Now comes my theoretical question, due to the way things happen differently between the clients and server ie. spawning bullets have to be done in a certain way to work which I figured out eventually, this leaves me to wonder, could I possibly make a version of the game that while is essentially a server/client but act almost completely only as a server and clients connect to that server and then battle eachother?

Please bear in mind that at this point my C# and Unity skills are still in their very early days and at this point don't plan to make any money from this game and I am not a fully fledged indie dev, just a guy with a hobby so I don't have Unity Pro or paid services. But don't let that stop you from answering, if it's too much of stretch for me right now, I can look back later when my skills are better and for now will settle with the client/server - client arrangement as it works with a few twitches here and there.

Cheers

 

You just don't start the client part on the server, and generally you'd make the server build headless.

 

It's great that you are thinking along these lines, as this shows thoughtful thinking!

Unity, in general, is designed to be easily accessible (or convenient) at the cost of performance and in some cases best practices. This isn't always a bad thing, they've done a great job and opening up the game development industry, however it does mean that their focus on how they release their features (ie. unet) can be a little misleading, if you want to focus on performance/optimization and/or best practices.

As a result, unet looks to be built for the peer-host/peer-to-peer model that you have initially described, where one player is the "host"/server/peer-server and all other players are "clients". The reason why you are introduced to unet as a peer-to-peer networking solution is because this model is easy to understand, and very cheap to set up. But as you've discovered already it has a number of drawbacks.

Essentially what you are looking to do is adopt to the client-server model, where you build two applications: one for your players (the "client") and one that you will run on a dedicated server (the "server"). Funnily enough, unet is very well built to support this model, although it doesn't seem like it at first! Here's some basic steps on how to achieve it:

• I recommend having a single scene in your project, called "SERVER" (or something similar) to represent all of the server-side parts of your game. Then, when you want to build the server "application" of your game, you can simply select your "SERVER" scene and build that as your server application
• Then, just work on the client-side parts in a separate scene/seperated scenes, and build that/them as your client application
• During development, simply build the server application to run it on your local machine. This means that during testing, you will need to make sure that your client-side connects to 127.0.0.1 or localhost. Note though that when you deploy your server application on a dedicated server, the client will connect to the server's ip address.
• When you are ready to test a production setup, make sure that you have linux support installed along with unity (you'll need to re-run the unity installer if you don't) and build your server application as a headless linux build. We chose linux because a linux server will always out-perform a windows server when you come to setting up/renting a server. "Headless" basically allows you to run the game without any rendering/audio pipeline, which will massively reduce cpu and ram usage when the server application is run
• To run the application on your linux server, you would run something like this from the command line: ./server_application.x86_64 -batchmode -nographics. The "./server_application.x86_64" part references the executable file that was built by unity. This just tells linux execute it. The "-batchmode" argument ensures it is run in headless mode, while "-nographics" ensures unity doesn't attempt to use a GPU. I'm not actually sure that both of these arguments are necessary, but this works well for me.

A few additional things to note here:

• during testing, it's going to be useful for you to "see" what is going on in your server application. For example, see what objects are doing in the scene. However, in production you wont be able to do this, nor will you want to. So, you'll want to make sure that when preparing your production version of your server application that you think about the resource cost of those objects
• the reason for this is even though you can't see those objects on your production server, their vertices, textures, shaders and other associated game-related elements still take up memory, and in some cases will still take up cpu. So it's a good idea to build production-server-versions of your object, which are versions that have little-to-know vertices in their meshes and no textures/materials etc

Hopefully this helps. Good luck!

 

donnysobonny That is a brilliant answer thanks. Luckily I have some Linux knowledge and spare computers I could use as a server too. During development I would probably use my local Windows machine as it has enough hardware to support small projects, but I guess I will see how that goes and expand if need be.

Right now I'm working with UNET in general, still discovering its tricks and playing around with it, but having much fun in doing so. Unity is really starting to show me why it is one of the best free engines out there and it might be sooner rather than later that I get serious and make money and get pro.

I will keep this in mind for the future so thank you so much for your answer.