GameNetworkingResources
Backroll
GameNetworkingResources | Backroll | |
---|---|---|
9 | 2 | |
6,782 | 120 | |
- | - | |
5.3 | 0.0 | |
about 2 months ago | over 2 years ago | |
C | C# | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
GameNetworkingResources
- A Curated List of Game Network Programming Resources
- Q: How are online games like Street Fighter 6 able to synchronize inputs from two players at a high frame rate? (60fps)
-
Useful resources and guidelines for Multiplayer and Networking? (PvE)
The list maintained here favors content for actual game developers: https://github.com/ThusSpokeNomad/GameNetworkingResources
- Where to start with online multiplayer?
-
How to become a Game Network Programmer?
Here is a list of resources: A Curated List of Game Network Programming Resources
-
How often should i send packets of data to the server/client?
Check these articles here to learn how game netcode works. The answer to your question (and a lot more) will come naturally after a bit of reading. https://github.com/ThusWroteNomad/GameNetworkingResources
- Resources for writing game servers
-
How Do Video Games Stay in Sync? An Intro to the Fascinating Networking O (Cont)
Honestly this is all largely a completely solved problem space. The article is just way out in left field seemingly fully oblivious to how game netcode currently works, which certainly isn't with AI prediction.
Look at actual game engine docs like this one from Valve https://developer.valvesoftware.com/wiki/Latency_Compensatin... or this one from Halo https://www.halowaypoint.com/news/closer-look-halo-infinite-...
But tldr is the only thing a client ever predicts is their own inputs, which of course can't really ever end up wrong later on. There's no other prediction happening (eg, the position of other players is not predicted)
And then for anti-cheat/optimization purposes the server also only sends positions for enemies that could be visible soon, which is done by taping into the same map chunking logic that would be used for asset streaming.
There's a ton of other great resources on this topic here https://github.com/ThusWroteNomad/GameNetworkingResources
But you'll find they all largely do the same basic thing. There's nuance in some of the rules and what state is replicated and what isn't (such as server side or client side ragdolls), but the general architecture tends to be the same. And without a fundamental shift in connectivity, seems pretty unlikely to change.
-
In what order would you add features for an MMO?
https://github.com/MFatihMAR/Game-Networking-Resources (This is a list maintained by someone else, and it has some amazing things in it, and far more technical leaning than what I maintain).
Backroll
- Stuff to learn for game development?
-
Making a Fighting Game
What most state of the art fighting games nowadays implement is rollback netcode (an implementation on top of lockstep based p2p netcode). This works when the amount of concurrent players in a game is low (2-4). Although I don't see a reason why there couldn't be an authoritative server solution like many other games have it, but then you also had to simulate the authoritative logic on the server instance. The upside is that you can realistically support more concurrent players. Comig back to rollback netcode, for this to work you need a determinisitc simulation. Each simulation on any hardware you support has to play out the same if the same input is provided over the duration of the simulation. Depending on which set of hardware you want to support, this can mean to completely throw out all relevant game systems that use floating point math and replace them with fixed point number types, since different processors might yield different float calculation results, or there are some differences in how compilers choose to optimize calculations. One additional problem for p2p networking is actually to connect with the other player. I recommend having a matchmaking server for this, that just pairs up players. More often than not, every player is in their own internal network and it's hard to connect to the PC over the network then. It would be possible to open map a port from your public IP of your router and re-route incoming messages to your PC in the internal network using port forwarding. This however requires manual setup and can leave you open to some attacks from outside. Having a public external server for matchmaking/pairing up can try to bypass those issues with punch-through). GGPO is popular transport library for rollback based netcode, It has gone open source a while ago too. If you look for an implementation for Unity/C#, I recommend checking out Backroll. Even if you use it, there will be a lot of things you still have to implmenet yourself to actually support rollback. Like making sure that input data representation is the same for every client, having a deterministic simulation, being able to serialize or temporary store a whole copy of your dynamic game state, applying such a stored game state back to the game simulation, and fully running several logical game frames with the call of a method, where input might be provided from historical records of real or predicted inputs of the players. For this reason, a lot of fighting games run the actual logical simulation completely outside of the rendering step. This all sounds pretty complex, but there are also benefits that naturally emerge from a rollback netcode or lockstep implementation: Network bandwidth requirements are very low since the most data you will need to send are inputs, and state hashes to make sure that the game simulations stayed in sync. When you store the history of inputs for a game in a file, and various other inputs you might have (seed for deterministic random generators etc.), you basically have all you need for a replay file, and just can run the simulation on those inputs (a problem is that this will break if you make changes to the simulation though).
What are some alternatives?
UnityDoorstop - Doorstop -- run C# before Unity does!
UnityGGPO - A DLL that lets you access the ggpo library easily from Unity, and an example project using it.
2DGD_F0TH - [CC BY-NC-SA] A compendium of the community knowledge on game design and development
ggrs - GGRS is a reimagination of GGPO, enabling P2P rollback networking in Rust. Rollback to the future!
Riptide - Lightweight C# networking solution for multiplayer games.
Game-Networking-Resources - A Curated List of Game Network Programming Resources [Moved to: https://github.com/ThusWroteNomad/GameNetworkingResources]
netmon_cli - A simple and lightweight terminal packet sniffer.
2DFPhysics - 2D fixed-point physics for Unity (WIP).
unity-libs-nuget - Template for generating stripped Unity game libs nugets
rpfload - PF firewall config loader for OpenBSD and FreeBSD with automatic backup rollback and logging
mc-mesher - marching cubes mesh generator for c++, c#, and unity
com.fightcade.Fightcade-ARCHIVE - ARCHIVED - go to flathub/com.fightcade.Fightcade