Linux dedicated server discussion

According to chat on the official irc, unity's networking can't manage FPS games with more than 20 players max (and start to lag before).
So some people told me to build my own network code with C++. But C++ coding in unity require 1500€ pro version...
I won't buy anything before i'm absolutly sure it will works perfectly.

So here are some questions :
How to build a linux dedicated server ?
How to make the dedicated server run with mono and unity's libraries ?
How to make the dedicated server physics ?
How to load unity's files with a linux dedicated server ?
How to code a full and efficient multiplayer networking with all lag compensation features and other stuff ?

Thanks.

 

I think we should start at the beginning here:

What are you doing, and why do you want to do it in Linux?

 

You could do it in C# as well, but I think if you have to ask these questions then rolling your own server is probably beyond your capabilities at this point. Why not look at other server options like Photon, SmartFox, etc.

 

I'm making an FPS spacesim targeting more than 64 players online, 128 or 256 would be better.
Linux is cheaper and is 99% of the time used by players to run dedicated servers.
Photon and Smartfox are designed for mmo and cost too much for players.
Yes it's beyond my capabilities, and this why I'm using a game engine instead of building my own AAA next gen engine.

 

Neither of those is really for MMO games, they may be used with MMO but are are more general purpose. An MMO engine is something like Hero, which was made for MMOs primarily.

 

Cool, can you provide more info on game mechanics?

How much $$$ are you willing to put into development and admin to save $ in hosting? Windows is not expensive [and in some cases costs the same]! And I'd strongly question your 99% figure.

Then consider other alternatives, for example uLink. Do note though that photon etc. might be able to offer redistributable licenses.

Then may we suggest rebuilding Unity3D as a Linux server may not be the smartest course of action?

 

Standard FPS. Each player controler a spaceship. Game last a few minutes until one team win. Then restart.

I don't spend any money in developpement, I do it myself.
Admin for what ?

I won't host games. I will host one game but players will have to host themeselves like in most FPS.

Is there any other way ?

 

The cost of running servers is not the initial setup cost of the operative system, it's the constant maintenance and support needed to keep servers running 24/7/365.

The whole Linux is cheaper then Windows is a red herring, yes maybe the initial cost of buying a VPS server is cheaper if it runs Linux instead of Windows, but this does not really matter. First of all if you're planning do buy a VPS you're screwed anyway, for latency sensitive games with a lot of players you need dedicated hardware, so you're pretty much going to have to buy your own server and put in some co-location spot. The difference of Windows vs. Linux in terms of OS pricing is almost non existent in the grand scheme of things already.

Then add that you're game is using an engine that is only available on Windows and OSX, even though Linux and OSX shares some heritage they are vastly different. Linux and Windows share pretty much nothing. Adding a third platform will just cause you troubles.

If you really worry about the cost of Linux vs. Windows for server hosting, you're in the wrong business or you have literally no idea where the costs in developing software really lies.

 

Figured I would answer your initial post also, and the questions you have there. First of, and I'm saying this not to be mean to but make you realize that scope: If you really need to ask these questions, you will most likely not be able to build your server. The stuff you're asking is elementary school stuff when it comes to networking and server programming.

Do you mean an actual server (as in hardware) or how to build a game server from scratch? The first one is simple, just buy hardware and put it together. The latter possibility is sort of like asking "I have a hunk of iron here, how do I turn it into a car?". I would recommend you to study some already existing and open sourced networking code like Quake or Mangos (open source wow server)

You build it in mono? You can't link the Unity libraries (at least not easily or obviously) in Linux (I know the uLink guys did something like this, but honestly I don't have the foggiest how they did it and their tech is proprietary).

You can't run a full blown physics simulation if you have a lot of players, the server will most likely not be able to handle it. Most (99%) of all MMOs run arcade based physics on the server which are very rough approximations of something that resembles real world physics, run the "real" physics on the client for the pretty stuff, but this is nothing more then eye candy.

If you really want "real" physics on the server look into integrating Bullet, ODE, PhysX, etc. with C#

Short answer: You can't. Long answer: You can, but the file format is proprietary and not open or has any documentation, so it will be hard to reverse engineer it. Correct answer: Build an exporter from unity that exports what you need from inside the editor to some arbitrary format you specify (xml, binary, etc.).

This is just not possible to answer, first of all it's not very well specified "... lag compensation and other stuff ...", secondly it's just to open ended and diffuse. We're back at the "I have found an iron vein in some land I own, how do I turn it into a car?"-type of question.

 

I'm making an FPS not an MMO.
Have you ever eard about counter strike, battlefield, unreal tournament ?
Every time those games get a new release, peoples ask for dedicated linux server. There is a reason to this and they are not talking about hardware...
And as I said in my first post, unity's network CAN'T handle an FPS correctly.

 

You were talking about 128-256 players fighting eachother, most MMOs can't handle that many players in one area duking it out without craching. So no matter if you want to believe it or not, creating a 256 player fighting experience requires you to think like an MMO.

Also, you should appreciate the help people give you, instead of being rude.

You have to appreciate the HUGE difference between doing 32-64 players and doing ~256 players. Using FPS techniques for lag comp. etc, becomes almost impossible. There is a reason no FPS allows you to play 256 players. And that no (working) MMO FPS exists.

N^2 will bite your ass.

 

A standard FPS does not involve spaceships or 256 players - more detailed technical description would be nice.

Are you happy to spend, say 100 hours of your time, simply to make it Linux compatible? How much do you value it?

Then consider other alternatives, for example uLink. Do note though that photon etc. might be able to offer redistributable licenses.

Either use Unity3D to run your server... or create game logic Independence of the unity game engine. The latter is good if you don't use physics, or use simpler physics.

 

MMO = Massive Multiplayer Online [Game].

A FPS with 256 Players dueling it out in a single match qualifies as a MMO - Specifically a MMOFPS.

So what?

What's the business case for Linux?

Not saying that you shouldn't support it, but you should have a rationale reason for doing so.

 

The reason is that I'm designing my product for my customers. They want Linux dedicated server, I must provide it.
It would be like building the client only on mac when most players use windows.
It's less critical for dedicated server but I can't simply ignore it.

In my mind, MMO = thousands players on the same server.
256 players is not an mmo and is my highest target. 128 would be fine while 64 may be to small for a spacesim. Torque networking is supposed to handle 128 players in an FPS.

More technical details :

Each player drive a spaceship or a gunner seat.

Their is two spaceship type :

Starfighters are small ships (10 to 20 m) with one pilot and 0-3 gunners.
It's driven like an FPS player, Mouse for look, WASD for move plus 2 keys for move up and down (usualy space barr and left ctrl).
Mouse buttons for firing. Maybe several weapons.

Starcruiser are large spaceship (hundreds metters) with a pilot and N gunners.
They are driven with a special behaviour, a 3D gui sphere is rotated for direction and it can only move forward or backward.

I thought also to mid sized ships.

All spaceships got 4 powers : engine, shield, weapon and regeneration.
Each power can be modified at any time. Increasing one decrease the 3 others.

There is also temporary power boosts available, like a used skill, not pick ups in the map.

Starfighters spawn inside Starcruisers.
Basic game goal is to destroy all Starcuisers that are spawned at game start. Those ones cannot respawn.

The game must handle collision.

No environnement planned except 3D skybox.

I will try to build a webplayer tonight. At this time I use external xml for input config and it doesn't load in the web build.

Take a look at my gallery.

@fholm, I'm a bit rude, but you are not very smooth.

 

Says who?

The your information seems either to be wrong 'Linux is cheaper and is 99% of the time used by players to run dedicated servers.' or based on a the wrong audience 'counter strike, battlefield, unreal tournament '.

There's a massive difference between ignoring it, and making rationale decisions. This isn't to say one shouldn't support Linux [it may be a good idea], but you've got the wrong starting point.

Then you need to work on that mindset. You're going to be using techniques and technologies from the MMO branch [in fact you're going to have bigger rooms than some MMO's]. Thinking of it as a simple FPS is wrong because it simply won't scale.

Thanks for that.

I'd talk to the guys at uLink and see if you can build a simple prototype that can scale to the numbers you want - otherwise you're looking at smartfox/photon/DIY which will suck time. The key will be keeping computation [read physics] to a minimum.

 

I think that physics is not a major issue. There is a lot of space in... space
Collisions will rarely happens. There will be more computation around weapons raycasting.
But when collisions happens it shouldn't freez the server.
I've planned a render to texture zoom displayed at the bottom of the screen so players can aim at long range.

 

The problem with an MMO is not the amount of players on one server, you can easily support 10k players on a simple machine if they don't interact with each-other. The problem arises when a lot of players are in the same area, fighting or doing stuff together. Most modern MMOs will not handle 256 players in the same area, with 128 players on each side attacking the other team, healing/buffing their own team and running around.

The core of the problem is simple: N^2, where N is the amount of players in reach of each-other, the fact that you need to send updates for each player to every other player in the same area is what will cripple your server.

Let's make an example, say you have 256 players in one area and every state update for the player (position, spells cast, etc.) is about 32 bytes (it will probably be more in reality, especially for an FPS), for an FPS game you will probably need around 20 updates per second (a tick rate of 50ms).

256 x 256 x 32 x 20 = 41943040, or ~40 mb.

This means you need to send 40 megabytes of state, PER SECOND out from the server. This requires a ~400mbit connection, each client will receive about 160kb/s in stream. A lot of people have connections that can't even handle this.

There is a reason pretty much no FPS game in existence allows for more then 64 players.

 

Thanks for the info, fholm, but I already know all this.
What I dont know is how to do this with optimization. There is ways to minimize bandiwdth usage. Unity don't do any.
Movement = 6 inputs bools for translation and 2x32 bits floats for rotation, plus 2x4 bits for powers change and 2 bools for weapons.
It result in 80 bits sent 20 times per seconds for 128 players : 128x128x80x20 = 26214400 bits. 25Mb/s for the server and 200Kb/s for client to download. The 80 bits are sent only if a player move in 6 directions, pitch and yaw, fire both weapons and change all powers at the same time, witch is impossible.
Less updates could be done if the other player is outside the FOV or at very long distance.

 

Rotation only requires 16 bits (1 byte per axis), not 64 bits (4 bytes per axis) as you say.
Also it's not as easy as just "send data if the player does something", for example you're always going to need to send the movement data for each axis no matter if the player is moving on that axis or not. Best possible world you could probably do:

8 bits (6 for movement + 2 for weapons)
16 bits (8 bits of rotation for two axes)
8 bits (powers change)

This would put it at 4 bytes per update for each player. You also have to account for IP+UDP overhead (28 bytes per packet), and all the other data the server WILL need to send (this depends on your game, interface, etc. a lot). It's not as clean cut as one might wish.

Sure, it might be do-able, but I will repeat: There's a reason most FPSes limit the max player count to 64 people, and it's not because they can't create larger maps.

 

Ok, but we still far from the usual 100Mb bandwith usualy allowed on dedicated servers.
You can compare linux/windows prices from this one.

 

Windows servers generally are more expensive than Linux servers. The price list you've linked, I've found, is pretty representative of the cost difference, Windows is about 20% more expensive.

Anyway, its admirable that you want your clients to have low hosting costs, creating a dedicated server from scratch that plays nice with Unity is a daunting task, which involves..

Setting up a custom communication layer with a non-unity process, using something like socket connections
Replicating any Unity-like functionality you may be used to, such as physics, etc
Handling complexities between importing any needed unity assets (meshes, for collision)

All this, on top of the daunting task of actually creating a server that can handle a high amount of players in a small radius.

This is all very tough! Is it worth the 20% reduction in cost to your potential users?

One possible option is to build the dedicated server using Unity, and run it headless mode under WINE or something and hope it works...

 

All this do not explain how to build an efficient dedicated server for a Mid MOFPS.

 

That is because there is no such description to give, we can give hints and tips like how to compress data (that I already gave) and general advice, but it's so game dependent that it's impossible for us to explain how to build one to you.

 

My honest opinion is you should make a simple 8-16 player version using your custom code, then see how it performs and work up from there and cut out inefficiencies discovered through unbiased metrics. Then go for 32 and 64. One problem with a space game is visibility, so you can't easily create update zones which only tell about players who could possibly see each other.

 

Take a look at Badumna 2. It scales very well and is very linux friendly. I found it a breeze to setup from the included examples / docs. Pricing get's a little expensive as you scale up but I would assume your user base would cover it at this point.

Video

 

It use p2p.
I need authoritative server .

How much raknet API is accessible by C++ in unity pro version ?

 

None of it.

 

The only rudeness I've seen was from you fholm. I don't think acropole was rude at all, but you on the other hand... And Photon Server does not support Linux period. They decided only to support multi billion dollar corporations.

 

RakNet can be used in none web player version of unity using C#. Now that unity can export to Linux if u use uLink (recommended) or built-in networking you can host on Linux.
a x session is required so in commandline only headless servers you need some virtual video sessions but can run unity in -batchmode and don't render anything.

@fholm You talked on MuchDifferent guys somehow loading unity libraries in Linux. They never did it.

Previously unity had a custom Linux build before releasing it to public if you are talking on their post about it which is a few months old and if you are talking about uServer which Aidin talked about it in their forums it's another story.

 

By "unity's network CAN'T handle an FPS correctly", do you mean your gear is not up to snuff?

i develop on a desktop and laptop (only on the go or on lazy days when id like to code in bed) and my laptops crap but still runs unity/mp pretty well.

unitys built in server stuff is actually not that bad out of the box.

other questions: are your game objects overly huge in tris? quads? etc?
have you optimized your assets? or are you just downloading freebies from unity asset store? the quality of your models affects how the game runs to.

 

I've been following the discussion on optimizing bandwidth for Unity game servers and would like to contribute some insights, particularly in the context of Linux-dedicated servers like those provided by Servers.com.

The challenge, as outlined, involves reducing bandwidth usage while maintaining game integrity. For a game with 128 players, each sending 80 bits of data 20 times per second, the bandwidth can indeed become a concern. Here's a breakdown:

• Data per player: 80 bits
• Frequency: 20 updates per second
• Total players: 128

This results in 128×80×20128×80×20 bits per second, equating to approximately 25Mb/s for the server and 200Kb/s for each client.

However, there are several optimization strategies that can be implemented, particularly when you have control over a dedicated server environment:

1. Selective Updates Based on Relevance: Only update players about the actions of other players that are in their field of view (FOV) or in a certain proximity. This significantly reduces the number of updates sent to each player.
   
   
2. State Compression: Utilize state compression techniques to reduce the size of each update. For example, if certain actions are mutually exclusive (a player can't move in opposite directions simultaneously), you can encode this information more efficiently.
   
   
3. Delta Compression: Instead of sending the entire state each time, send only the changes (delta) from the last update. This is particularly efficient in scenarios where many of the state variables (like position, orientation, etc.) change infrequently.
   
   
4. Rate Control: Dynamically adjust the update rate based on network conditions and player activity. If a player is stationary or in a less dynamic environment, the updates can be less frequent.
   
   
5. Prioritization of Data: Prioritize critical game data (like player position) over less critical data (like cosmetic changes). This ensures that the most important data is always updated first.

In summary, by applying these bandwidth optimization techniques and utilizing the capabilities of a dedicated server, you can significantly reduce the bandwidth requirements for your Unity game without compromising the player experience.