Gamasutra: The Art & Business of Making Gamesspacer
Networks With Letters

Printer-Friendly VersionPrinter-Friendly Version
arrowPress Releases
April 18, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Networks With Letters

August 12, 2009 Article Start Page 1 of 3 Next
 

[In this technical piece, Introversion's Knottenbelt discusses the 'discrete event simulation' approach to multiplayer in the upcoming Darwinia+ for Xbox Live Arcade, in which player movements and button presses are sent over the network, instead of actual positions of the thousands of in-game objects ]

Introduction

Not many people know this but Introversion's IGF award-winning title Darwinia was released incomplete: Darwinia was originally conceived as a multiplayer game.

Initially codenamed "Future War", the main game design centered around players who could take control of a massive sprite army, that could then be pitched against another players armies in massive battle-epic style. The trouble is, we ran out of money spectacularly.

As the finances at Introversion dwindled the original multiplayer component for Darwinia was hastily dropped. It wasn't until some months later, reveling in the unexpected kudos of winning those IGF awards that the opportunity for us to revisit the earlier multiplayer idea was revived.

Microsoft wanted to bring Darwinia to XBLA, and with that came the need for a multiplayer component - this would in time develop into an entirely new game called Multiwinia, which IV launched on PC at the end of 2008. Multiwinia, along with Darwinia will be released on Live Arcade as Darwinia+ this summer, a momentous occasion for us as Introversion's first release onto a console.

By the time we started work on Darwinia+, multiplayer networking was not entirely new to us - as mentioned we had dipped our toes into the water when first developing Darwinia, and although unsuccessful we had learnt an important lesson; it was better to integrate multiplayer functionality into the core of the game early on.

Nevertheless, the networking we had started with Darwinia proved useful in our later multiplayer titles, such as Defcon released in 2006, and Multiwinia released last year.

Our approach to multiplayer networking has had its advantages and drawbacks, some of which I will explore in further detail here, along with a greater insight into how we approached this key-programming problem.


Article Start Page 1 of 3 Next

Related Jobs

TapZen
TapZen — Los Angeles, California, United States
[04.18.14]

Database Engineer
Fun Bits Interactive
Fun Bits Interactive — SEATTLE, Washington, United States
[04.18.14]

Senior Engine Programmer
2K
2K — Novato, California, United States
[04.18.14]

DevOps Engineer – Core Tech
2K
2K — Novato, California, United States
[04.18.14]

Senior Graphics Engineer - Core Tech Team






Comments


m l
profile image
Isnt this the same as how Age of Empires did their networking?

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_
network_.php

Thierry Tremblay
profile image
Yes, this is pretty much how all RTS games work. This is known as a deterministic / lockstep simulation.

Jonathon Walsh
profile image
Interesting article, I do believe this is what other RTS games do as well but it's still a very good explaination of how the system works. I'm curious what strategies you used to ensure validity of the game data and synchronization between clients.

RJ Martin
profile image
I'm also curious since I've never tried to implement this. If you are just recording the order of these, but not the time, won't that affect the outcome? For example, Player A could have given a command at a certain time and then that event is recorded and simulated on other clients, the results of that command might be time sensitive (e.g. - changing velocity while moving puts you at a different spot depending on when you changed velocity). For the movement command you give as an example, you give the source and dest locations, so make it independent of time in a sense. Is that your method for all the commands?

Linus Tan
profile image
I used a similar lockstep simulation method for multiplayer in node-def (http://www.node-def.com). I've found that the main challenges with this method, apart from the floating-point computation issues is ensuring that your game logic is fully deterministic. For example, at one point I had some of the pointers to in-game entites stored in a hash map. The problem was that since the pointer's numeric values would be different on another computer, the order of the pointers in the hash map would vary from instance to instance. This led to rare and subtle bugs where a certain target would be attacked in one instance, because it was at the top of the hash map, and wouldn't get attacked in another instance, because it occupied a different position in the map.



Another disadvantage of lockstep simulation is that input on the client will always be subject to a delay before the client perceives the results. This is because the client has to ask the server for permission to execute any game-changing command. For example, if you issued a move command in an RTS as a client, and the round-trip latency was on the order of 500 ms, you would experience a substantial delay between clicking and seeing your troops move. Of course, the effect of this can be mitigated with good a good UI design, for example, giving immediate and obvious feedback that the troops will in fact move by placing a visual effect at the move destination.

raigan burns
profile image
Trying to get floats to behave identically across different platforms sounds terrifying; is this something that you have working (i.e for Multiwinia/PC)?! Seems like a great solution for the XBLA version though since you know everyone's on identical hardware.

Alex Champandard
profile image
You should definitely write another article about the process of making the simulation deterministic -- as you mentioned in the disadvantages. That's the key challenge here! :-)

William Meehan
profile image
@raigan burns: I might be wrong on this, but I believe consoles only guarantee hardware consistency to a point. I mean, they will have the same system architecture, but I'm pretty sure you can get differences in performance on consoles. I'm not just talking about differences between a PS3 and a PS3 Lite. I was under the impression that as time goes on, and they refine the manufacturing processes, there may be subtle hardware differences between an original PS3 and one made Recently.



@Alex Champandard: I agree, I would love to learn more about making the simulation consistent/deterministic.

filip sound
profile image
One thing seems to be obvious to me: The simulation must not use any random numbers (if they are not spread at some point). I'd love to know more details too.

Adam Prall
profile image
@RJ Martin: What's recorded is the sequence, not the exact time, which is about the best you can do in a multi-machine environment. Since all clients are "locked" onto the same "step" in the simulation, it doesn't matter what exact time every command occurred in, just at which step and in which order the server received it in. And at 100Hz, you're not likely to notice little errors, mostly just the huge latency errors. Also, you can accommodate latency by actually recording and sending/synchronizing timestamps, making that a transaction that occurs solely between the player sending the event and the gameserver.

@Alex Champandard: yeah this article definitely calls for this and would lead very naturally for a part II, especially addressing @filip sound's very relevant concern about creating deterministic random numbers… I use my own generator instead of the native rand calls because it's the only way to work with random data (because of course the actual, physical universe isn't really random, it just looks that way).


none
 
Comment: