|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Instant Replay : Building a Game Engine with Reproducible Behavior Floating Point
Mathematics Different PC systems utilize different CPUs, and different CPUs have different FPUs. It may seem surprising, but different FPUs can produce marginally different results for some calculations, even though all units are IEEE compliant. This can be attributed to different internal representations within the FPU. In addition, different software builds can exhibit different behavior on the same hardware due to changes in the storage of floating point values. This means, for example, that a sequence replayed through a 'debug' build of a game may exhibit different behavior when played through a 'release' build. In any case, this leaves us with a problem if we wish to reproduce a game sequence on different PC to the one on which it was recorded. In this respect we wish must consider the results of PC based floating point calculations to be an external data source. The obvious solution to this is to use integer (fixed point) data to represent our game state. This may well be desirable for other reasons, for example if we are planning to port code to another platform which does not have a hardware FPU. Of course, output data (such as rendering data) is independent from the game state, and so free from this restriction. Using
Reproducibility for Networking Many techniques exist to deal with this problem, and almost all rely on the transmission of game state data. Once two different versions of the same world are different, it is generally only possible to re-synchronise them by sending absolute state data. Moreover, this must be an ongoing process, as de-synchronisation can occur at any time. The result is that most network games need to continuously transmit game state data in order to maintain the integrity of the shared game world. This necessarily incurs a large bandwidth penalty, seriously impeding performance across a low bandwidth connection such as a modem. Using a reproducible game engine offers some big benefits to networked games. Firstly, since the same sequence of inputs always produces the same result, participants can re-synchronise simply and reliably by transmitting and processing player inputs: If two game engines have started from the same state, and processed the same inputs, they will reach identical states. This reduces required bandwidth considerably, as no absolute game state information is involved. Secondly, a network model based on the transmission of player inputs is much simpler to implement. The data structure of all required messages is already clearly defined by the player input structures, and the game engine already has functions for processing received messages. This approach is sublimely simple, and in principal scales to any level of software complexity. For further reading on this subject, Peter Lindcroft presents an interesting account of a network game based on a reproducible game engine architecture in his article "The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter", including some of the problems encountered by his team. Using
Reproducibility for Debugging Some Final Words Despite some limitations, I have found reproducibility to be immensely useful in my own work, particularly as an aid to debugging. As a design-driven approach it is a classic case of working "smarter" rather then harder: a little planning at the start of development brings big benefits later on. It allows teams to easily add features that would otherwise have been problematic, and to consider other features that would not otherwise be possible. The key thing to bear in mind is that a game engine either exhibits reproducible behavior, or it doesn't. This means that reproducibility is easiest to implement at the start of development, but becomes increasingly difficult to add later on. If you would like to enjoy the benefits it has to offer in your own projects then it is important to apply some thought and preplanning at the start in order to reap the rewards later on. But then again, isn't that always the way with game development? References Peter Lindcroft,
"The Internet Sucks:
Or, What I Learned Coding X-Wing vs. TIE Fighter" ______________________________________________________  [Back
to] Instant Replay |
||||||||||||||||
|
|
Features
