NEWS
COMMUNITY
STORE
LABS
ROKOJORI
NEWSLETTER
SIGN UPLOGIN
LOGOUTNEWS
COMMUNITY
STORE
LABS
Networked applications or multiplayer games are terms describing programs that can connect to other programs via network mechanisms to experience (portions of) games and apps with the same, shared states in real time.
This programs can be on the same device or on other devices. Additionally, the devices can be in the same network (LAN) or on different ones (Non-LAN).
Networking is usually done on top of the internet protocol. In this system, every network interface controller (e.g. cable network card, wifi adapter, mobile phone) gets an unique number to identify the controller. The identification is called IP adress and can be in 2 versions: IPv4(128.0.0.1) or IPv6 (2001:0db8:85a3:08d3:1319:8a2e:0370:7344). IPv4 is still in use, but has not enough adresses for all humans, that's why the bigger IPv6 was created.
Network controllers connected in a home network have typically 2 associated IP adresses: One IP adress in a local network (LAN) given by a router (mostly IPv4) and than an IP adress the router has on the internet (IPv4 or IPv6). All devices connected in the LAN of the router have the exact same IP adress for the internet but a different IP adress for the LAN. The router's job is to route all outgoing and incoming connections, so that the right devices send or receive the right information. Mobile phones can also function as routers and can connect directly to the internet.
IP adresses can be static or dynamic. Websites and hardware servers for games usually have a static IP adress. If you are wondering, why you type names and don't have to type IP adresses in the browser: The DNS was invented for this purpose, to redirect "names" to IP adresses.
LAN participants get their (LAN) adress from the router, which tries to give devices the same adress, but this is not guarenteed. Routers and phones get their world-wide IP adress from the internet providers which can be dynamic and changes frequently (on restart/cell movement for phones, daily for "DSL" in Germany) or static ("Cable"/special DSL in Germany).
However, the IP adress is not enough, since network controllers can connect to multiple other controllers simultaneously. That's why every connection to a different target is done with ports. Ports allow networking participants to seperate programs and also to standardize the expected communication form. There are several ports reserved for common use cases, which should not be used for anything than their intended purpose. Putting everyhing together, an IP adress and port 80 look like this: 128.0.0.1:80
Since the internet protocol roughly only defines adresses, protocols on top are used to communicate. They define how data which is send from to another needs to be handled.
In most real-time networking applications UDP is used. TCP is only used if the constrains for syncing are not that hard, e.g. not a lot of data is continously sent.
Here, it refers to a program that takes the administrive, authoritive, connecting or data-providing role in networked communication - e.g in multiplayer the server side of a game or an HTTPS server for serving websites.
A remote computer that is controllable by a developer, where programs (like software server) are run, is also called a server. Often those remote computers are actually running in parallel as a virtual server on real computer. In this case they share resources with the other virtual servers. Virtual servers are cheaper than fully unshared servers.
Named collections of chats on the Discord platform are also called servers. Probably for historic reasons, but actually, they are not servers (in any relevant technical meaning).
Here, everybody is in the same local network (LAN) and is using the LAN adress. No external hardware server is needed to establish the network session. Typically, one of the players starts as a server with an IP adress and a port in the LAN, which allows all other players to connect as clients. In a LAN everybody can quite easily use any incoming or outgoing connection. The only problem is to know the IP adress and port of the others. Back in the early days, this was done by hand - but there also exist techniques to do that automatically. Usually it's ok, when everybody connects with everybody, the limits of how much and fast data can be transmitted depends on the number of players and the hardware and settings of the router.
This is mainly what people (mis-)understand as peer-to-peer. Technically it would be possible to connect everybody directly on the internet, but often the settings of the routers and the contracts of internet provider disable this possibility. One big problem is, that most router/user settings don't allow incoming connections (messages from other peers) because of security concerns. Only the answer of established outgoing connections are allowed. This can and must be bypassed with mechanisms like hole-punching, which uses tricks to re-route connections, but still will not work for all devices.
To be very clear: Non-LAN peer-to-peer only with players does not work. You will at least always need another third party (other known server) to do a handshake for establishing IP adresses & ports and than to re-route those connections. And than still a big portion won't be able to this at all and this is why most implementation use a relay server.
This is how peer-to-peer is usually implemented. Since Non-LAN peer-to-peer does not work, at least one hardware server is used as central hub to connect the players. Since it is not always possible to connect all players directly, the server is used as a fallback to relay the messages for players that are not able to connect directly. The server doesn't know anything about the application or the game and only creates sessions/rooms where the data is distributed for the players. The game logic server/authority would be handled by one player.
This type of server is very cheap (performance wise), since nothing has to be simulated on the remote hardware server. Only the communication data for sessions is distributed. Since there is already a server in use, it can also be used for the task of match making.
Depending on the implementation of the relay logic and CPU/RAM this allows to handle lots of concurrent players (potentially hundreds of players). However, the limiting factor is most likely the bandwidth limitation of the server (and how effective the rate of peer-to-peer connections is). In the best case it has almost zero traffic, in the worst case it has quadratic-to-number-of-players traffic costs, check the traffic info on the bottom.
In this type, the whole game is run on a server. This means that all participants send and receive their data always through one server which is also simulating and managing the state of all players together. So, different than the relay server, the dedicated server is also run as game logic server.
Traffic-wise, the worst case of the relay server is - in a typical unoptimized scenerio - the standard case in a dedicated server: quadratic to the number of players.
Reading through all paragraphs should have clarified, that it's not possible to create a multiplayer without a server. There are however different flavors of solutions for getting a server. They differ in features, costs and needed own effort/skills.
Steam allows to use their relay/peer-to-peer services for free for games on their platform. That means, a steam development account and a steam game needs to be created. This is a very comfortable and technically well-proven solution, but only works on Steam.
Photon offers a cross-platform solution for relay/peer-to-peer networking. Photon Realtime should be useable on most game engines, but I couldn't test it yet in Godot. It has a free tier for developing and commercial offers for releasing. This can be a very comfortable and good solution, when the platforms and costs are fine for the game.
Nakama is an open-source self-hostable solution. It offers a lot of features for ONE relay/peer-to-peer server. The main loop of the server can be customized with TypeScript/Lua/GO, so that a bit of game server logic can be implemented. It offers integration for multiple engines from Godot 3, Godot 4, Unity, Unreal, Defold and more. Some people on reddit complained about "not being scalable", but I could not verify that yet. Their commercial offerings start from 600$/month which is way out of league for most indies (36000$ for 5 years). But I think it is possible to just scale yourself by adding more virtual servers which would be independent.
The cost of one virtual server is somewhere between 1€-50€/month, depending on the provider and configuration. The more cores/cpu and ssd, the more expensive. The traffic (how much data) and bandwidth (how fast is the data transmitted) of a server is usually not without a limit. Both are usually throttled and need to be calculated to match the needs. The offers for virtual servers I checked had a limit of 1 GBit/s but unlimited traffic.
In a unoptimized scenerio (or in case all see all moving/rotating) the traffic needed for distributing one message from one to all is quadratic to the number of players. Games in which the transform data of players (or player owned moving objects) need to be distributed to all other players are the most traffic hungry games.
Not all players buying a game are playing it at the same time. The exact relation ship is depending on the type of game, but it is somewhere of 1 in 100-1000 players. So if your game sold 10000 times, roughly 10-100 players will be playing at the same time. So don't buy 100 servers, yet.
Games usually have 2 types of data: Continous data and event data.
Continous data is used for synchronizing positions, rotations and other things that constantly change.
Event data is for non-continous things like "change health", "play sound", "open door", "start jump animation" etc.
If you have a game where the player uses 40 bytes (e.g. 10 floats/ints) in average for one update message and the update rate is 10FPS, one player creates 400 bytes/sec "raw" information, which is 3200 bits/sec or 3.2 MBits/sec.
The overhead that is generated for every message that is sent can get large if lots of messages are sent. It's better to combine multiple informations into one big message instead of sending multiple tiny ones. In the calculations underneath the message overhead is NOT included. It can have some bytes per message.
What does the worst case (quadratic to the players) mean? Using the average player data from above and assuming a server has 1GBit/s or 1000MBit/s available, the following statements about the network multiply (quadratic to the number of players) can be done (without message overhead):
Network multiply: 4*4 = 16.
Means for one game: 16 * 3.2MBits/sec = 51.2MBits/sec.
Max #games on a server: 1000/51.2 = 19.
Network multiply: 5*5 = 25.
Means for one game: 25 * 3.2MBits/sec = 80MBits/sec.
Max #games on a server: 1000/80 = 12.
Network multiply: 8*8 = 64.
Means for one game: 64 * 3.2MBits/sec = 204.8MBits/sec.
Max #games on a server: 1000/204.8 = 4.
The traffic needed for partial peer-to-peer communication is different, since the peers will take over some traffic. The formula for the network multiply of a partially relayed network game is (without message overhead):
Network multiply: 4 + 1 * ( 4 - 1 ) + 3 * 1 = 10.
Means for one game: 10 * 3.2MBits/sec = 32.0MBits/sec.
Max #games on a server: 1000/32.0 = 31.
Network multiply: 8 + 2 * ( 8 - 1 ) + 6 * 2 = 34.
Means for one game: 34 * 3.2MBits/sec = 108.8MBits/sec.
Max #games on a server: 1000/108.8 = 9.
