dotnetmud: spacegame: Timing Loops 1: Client / Server timing loop

imageI feel stalled in my project.  It might be that I need to write about the important stuff done so far before I continue to redo/optimize the game; setting the stage to understand the need for some of those optimizations.

Reference code for this post (tag): https://github.com/sunnywiz/dotnetmud2015/tree/blog20160302.

The playable game (which might be updated, not frozen to this post) is: http://dotnetmud.azurewebsites.net/Home/SpaceClient

Game state at this time:   Multiplayer, can shoot missiles, missiles hit things, score is kept.

There are 3 interacting timing loops:

Client / Server Update Loop

I made the client “in charge” of this.  Starting in Javascript, the client requests an update from the server:

image

image

Along with the request for game data, the client is also sending the state of controls for the user.  I went with “how many ms has the thrust key been pressed” as my input – there’s a separate set of handlers which watch key-up and key-down events and long how long keys have been pressed for.

This then travels up through Signal/R, and shows up at the server 20-50ms (an eternity) later:

image

The SIgnal/R side of the hub takes the connection, looks up which server-game-object that connection is tied to, and asks that game object (which happens to be a Ship.cs) to craft what it thinks the world looks like.

The Ship has several things it has to do. 

First is to look at the keypresses and turn those into thrust amounts.  I went with a % of thrust:

image

There is similar code for “can I fire another missile yet” (not pictured).

Then, it makes a copy of all the stuff that the client needs to draw the world:

image

It records itself, all the other 2D objects in space, some scores, and what the current “Server Time” is (and rate of change of server time, which is a YAGNIY for when the server gets overloaded and has to go into bullet time).

It packages all that into a return (of type object, which gets JSON-serialized), and SpaceHub happily sends it back to the client:

image

Then, 25-50ms later (another eternity), the client receives the game-update:

image

  • Green – the client updates what it knows about what’s going on on the server.   I tried to keep this in its own “object space”, to indicate that the server is the authority here.
  • Blue – the client updates various things that are of interest to the client
  • Purple – there’s some bulk copying going on that isn’t very sexy and is very network-inefficient.
  • Red – and the client immediately requests another packet.

Places to Improve: Network Traffic.

The server sends ALL the data, ALL the time.   A network packet looks like this (raw, pretty printed):

image image

There is a LOT of stuff in there that is needed once (like image URL’s), and then does not change.   Also, many property names, while nice for humans, is not optimal for network traffic (words like “ClientREquestsPollFromServer”) for example.

“No Big Deal?”  — Doing a test, holding down the fire button and shooting the planet, for a few minutes, in Azure Data:

image

Doing some math:

image

If I have a successful game, and there’s about 1 combat going all the time, we’re looking at $18 per month.

The solution for this is to only send diffs across the network.  That’s on my list for pretty soon.  But it will require some hand-crafting detail.   And some before/after testing.  This will be its own blog post.

Places to Improve: Network Lag

This model is similar to how Kermit used to work – there is a LOT of dead time between updates.   

One way to improve this might be to have the client keep track of the lag between server updates, and then, in its request to the server, ask “please give me additional packets at the following times, until you hear from me again”.    So, the server could send 2 game-updates for every 1 client-inputs-update.     Its on my list, sometime after sending diffs.   Have to be careful and mark the intermediate frames as intermediate, so that only the major frames cause the cycle to continue.

Another direction we could go is completely decouple the client-input from the server-response.   I’m not going to do that, because I like how the client has to constantly remind the server of its existence – if the client goes haywire, I don’t need to write additional server code to detect that and shut down the server sending stuff to the client.   I’m also lazy. Smile 

In Conclusion

So, there’s the ugliest timing loop in the game so far.   The other two are relatively easy, may not get written about soon. 

Tagged with: ,
Posted in Code, Games

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories
Tags
.net 3d 3d-printing 4k abc15 algorithms ames android anonymous types asp.net audio editing aws backup basecamp beatunes biorhythm bittorrent blender blog boston marathon bpm c# caffeine campfire candycrush car carmax charity chiropractor cities-skylines clog clone codelouisville codepalousa coding coffee collaboration color run ComputerElbow ComputerVision configuration consulting cooking crash course crashplan crestwood cycling dabda dan dapper DataSet ddl diabetes dictation dotnetcore dotnetmud downtown e-cycling elite excel exercise expiration facebook feature-branching firefall flipflops Flow FL Studio focus food forecastle fortresscraft franklinplanner gadgets game-design games git github google docs google maps gopro gps grandpa greenshot hack half marathon headless health heart rate hiren ignew integration testing interop inventory ios ipad itunes javascript jobs karma kdf keyboards keys kittens lamont laptop lavalamp lego life lifehack linq linqtotwitter linux los angeles louisville mandelbulber massage therapy mastery-teaching maths merge metformin Minecraft miniature modeling monitor mud muhammad ali institute music mvc mycartracks netfabb nexus10 node nostalgia nutrition nwipe oldham county grand slam opal openjscad openscad owin pacedj paper mockup pepakura performance photoscan politics pomodoro postgresql powershell premiere prius process product-management project-management qa resharper review rmi roman road 5k RSI rubiks running samsung 700t sandals schedule scooter scribblelive selenium service shapeways sleep slic3r sneakersync snot software software-engineering solidoodle soylent spacegame speaking sql sqlite SSDT SSIS standing state-machine stayfocusd stonehearth sunset tablet teaching team teamcity teamtreehouse terraform testing tfs time timelapse torque touch tracks trs80 Tuple tutor twitter ubuntu unit testing utilities video video editing visual studio vscode vsvim warp stabilizer windows 8 windows home server wordpress wpf xml
Archives
%d bloggers like this: