|
[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.
|
Printer-Friendly Version
http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php
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.
@Alex Champandard: I agree, I would love to learn more about making the simulation consistent/deterministic.
@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).