• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Wizzard97

Game state synchronization techniques

8 posts in this topic

I've been reading through a couple open source game projects: RakNet, Cube, and The Mana World.

These projects use different methods to synchronize the game state, but I feel like all of them are subpar.

Here's my very rough summary of each (these may be a little off because the projects' sources are not made to be readable)

* RakNet uses delta compressed reliable packets in its ReplicaManager3 to synchronize variables (uses UDP instead of TCP... why?)

* Cube seems to use reliable packets for everything except movement (positions of every movable object sent every tick in an unreliable packet)

* The Mana World also uses reliable packets similar to RakNet (though they switched to ENet from their working TCP implementation... why?)

 

In this article, the snapshot system of Quake 3 is described.

I really like the idea of delta compression with unreliable packets, but storing snapshots per-client makes scaling up a pain on RAM.

 

Instead, I currently have the server storing the last one second of positions from each tick.

The server rewinds to the last tick the client recognized in an ACK and generates a delta snapshot from that state to the current.

This is convenient because I plan on implementing lag compensation later anyways (which requires storing the last one second).

 

However, I feel like I've not gotten a thorough idea of all the various game state synchronization techniques,

and finding more articles on the subject is fairly difficult for me. What are some other ways fast-paced games synchronize the world?

 

[b]Edit:[/b] About the UDP instead of TCP stuff - I'm under the impression that, if one is going to use only reliable packets on a single stream, TCP is much more optimized.

Edited by Wizzard97
1

Share this post


Link to post
Share on other sites
If one requires reliable, in-order, derlivery of all packets, then one might as well use TCP.

If that's what you do, though, you should know that the network subsystem will delay any newer packets that come in while it's waiting for older packets. For twitch-sensitive FPS games, that is generally not what you want. Hence, why most games end up with UDP for movement.

storing snapshots per-client makes scaling up a pain on RAM


I don't quite see it. Could you calculate out the RAM cost for illustration? (How big is a snapshot? How fast is your network tick rate? How many clients are you talking about?)
0

Share this post


Link to post
Share on other sites

I believe that unless you have a large amount of changing data on the objects (in which case you'd likely have a bandwidth problem), the RAM needed for the per-client snapshots is not going to become a serious problem for scalability at first.

 

Rather, the problem is the CPU processing needed to determine for each client, what data is relevant and what needs to be sent. Assuming that it's typically the other clients' player character state that needs to be examined for changes and to be sent to all interested parties, this becomes an O(n^2) problem for n clients.

 

As long as the client count is that of typical FPS multiplayer games (something like 32-64 max), even that isn't likely going to be a serious problem. But for scaling beyond that it'd be ideal to be able to just blindly send the same data to several clients, without doing any per-client rewinds or inspection of "what this client needs to know".

1

Share this post


Link to post
Share on other sites

Trivia : To keep so many gamestate for each players consumes a lot of memory: 8 MB for 4 players according to my measurements. - http://fabiensanglard.net/quake3/network.php

A few things I note here

* Quake3 does not have a system of relevant sets

* I expect to network many dynamic entities (Quake3 syncs only players and power-ups)

* My entities have less states than Quake3 (position and angles only currently, health later for more prediction)

* Currently, I run the server at 66 tick (CS:GO), but when testing on 30 (Unreal), I seem to get decent results

 - Quake3's 20 tick doesn't live up to current games' standards in feeling (too much leading shots, at least in my engine [no extrapolation])

* Player states shouldn't take up the majority of my memory usage

* Also, most importantly, while not being a strict requirement of my project, I'd like the game to be structured for as large of battles as possible (4000+ dream)

So, more-or-less, I think current hardware could handle this based on this qualitative junk,

but I see no advantage to it over my current implementation of server snapshots.

 

 

But for scaling beyond that it'd be ideal to be able to just blindly send the same data to several clients, without doing any per-client rewinds or inspection of "what this client needs to know".

I've already implemented what Unity calls relevant sets to remedy this partly. The world is quite big and players generally are not in one another's potentially visible set.

However, you bring up an important point that sometimes it may be better not to use the snapshot system to delta compress objects - and to instead blindly send them.

I think there exists some type of optimization to help alleviate this, but that would get really specific to the game. I'm just looking at different techniques currently.

 

 

Thanks for the responses! I'm sort of pleased if nobody has a better answer than what I currently use, but at the same time, snapshots feel sort of sloppy.

Edited by Wizzard97
0

Share this post


Link to post
Share on other sites

Player states shouldn't take up the majority of my memory usage


Again, could you do the math for this? To me, even two seconds of 60 Hz state for 1000 players doesn't seem like a big deal.
What are your restrictions, and how big is your state?
0

Share this post


Link to post
Share on other sites

[Dynamic Object] (26 bytes total)

* Id (2 bytes)

* Position (12 bytes - can be lowered by not using floats)

* Angles (12 bytes - can be lowered by not using floats)

 

[Static Object] (2 bytes total)

* Id (2 bytes)

 

Each snapshot contains all the static objects in the scene and all the dynamic objects in the scene that are in the clients' range.

I feel like a safe estimate is that there can be 50 dynamic objects and 50 static objects in a players' view on average.

If I have 1000 players, each storing 60 snapshots with 50 dynamic objects and 50 static objects (while not including container pointers and such)

I get that ~80 megabytes are used by the per-client snapshot system.

A worst-case scenario is that 1000 players are actively fighting each other.

Each player then sees maybe 1050 dynamic objects and 50 static objects.

I get that they will take ~1.5 gigabytes. That's a pretty generous estimate too.

The point is that storing one set of snapshots seems more effective, but maybe I'll benchmark it one day instead of guessing at it.

0

Share this post


Link to post
Share on other sites

Why have to store 1 sec/60 frames worth ?

 

Why not nearest 6th of a second?  (store 6 snapshots back)  as youre going to lag compensate anyway and its all transitory data you dont need perfect catchup animations for.

 

With this  much shorter set of snapshot data you might be able to make your per client store static (ditch the container overhead and use pointer rnath on the server)    Snapshot variable sizing just requires circular indexing maths...

 

Depending on how often this ACK-fail retransmit happens, couldnt you also have the per client snapshot on server be pointers/index to one full (common) set of snap data set (stored per actual object) to minimize the server memory?

If the failure+retransmits are chronic then all this overhead doesnt gain much over just forcing through current data state.

 

-

 

It also might be good to compress the object angles from float to Int16  to cut down you primary update data (65000 angle increments should be more than sufficient).

 

0

Share this post


Link to post
Share on other sites

... couldnt you also have the per client snapshot on server be pointers/index to one full (common) set of snap data set (stored per actual object) to minimize the server memory?

This is sort of what I do. The client has an integer reference to the last server state it ACK'd, and then a delta snapshot is generated from that server snapshot to the current.

0

Share this post


Link to post
Share on other sites
You don't need to store snapshots on a per-player basis. The state of object X at type Y is the same, no matter who is viewing that object.

Thus, with 1000 players and 1000 static objects, and 32 bytes per snapshot, and 120 snapshots total (for 2 seconds at 60 Hz,) I get that to less than 8 MB.

Additionally, you only need to snapshot the states that are actually sent as network ticks, and 60 Hz network ticks is not a good idea for games with 1000 players in the same area.

Also, if 1000 players fight each other, you're going to have other problems than snapshot memory cropping up much earlier. Physics, collision detection, rendering frame rate, client video RAM (assuming 3D), size of each packet you send, ...
1

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0