The magic of writing game simulation code

Let me start by explaining what I mean by game simulation code. I couldn’t find a suitable explanation from wikipedia (this being the closest thing, but covers far more than games) This is my description:

Game simulation code: The code that describes and performs all rulesets of a gameplay system. It also will read and write to a model that describes the current gameplay state. Typically the simulation is iterative, executing logic in ‘steps’. Inputs include: user input from local and remote connections, data describing rulesets, and data describing gameplay state. Outputs include: data describing a new gameplay state, changes in state from a previous one. Usually referred to as: simulation code, gameplay code, ‘the sim’. Can ‘drive’ other game systems (such as audio, so triggering music for example) or provide inputs to other game systems (such as graphics, drawing the current locations of objects for example)

SimulationMagicImage2

All games contain simulation code, but the level of complexity and the frequency it runs can vary widely. A turn-based game will run simulation code once per turn, while a real-time strategy game might run at a fixed 10 ‘frames’ (updates) per second. MMORPG games run simulation code on their servers, again at some fixed rate.

That ended up being a rather long explanation and if it still doesn’t make sense, please let me know in the comments so I can elaborate further!

So far I’ve had the opportunity to write code in almost every category of game programming, and they all have their perks, but simulation code can be magical. What makes writing this kind of code special?

The two main areas that I find most special about simulation code are: life and emergence.

SimulationMagicImage1

Life

Many games take place in a world similar to the one we live in. Entities live and die, can move, perform actions, react, and make decisions. The difference is that in a game, the gameplay programmer crafts all of those rules. In the real world, we theorize and experiment in order to discover and explain the rules that govern our reality, but in a simulation, as the programmer, we write them. Gravity doesn’t exist in the game until we write the code that describes it.

While it can be exciting (for me, anyways) just writing the rules of an entire virtual reality, witnessing the simulation, well, simulate is the definition of awesome. That is, to bring about awe. Think about a game like Simcity, where you build a city, and see all your little citizens moving around, and the feeling you get. Then imagine you wrote the code that actually simulates all of that. You created a living reality! It’s a much less complicated reality than the one we live in, but a reality nonetheless.

Even in turn-based games it can be interesting to see how the artificial intelligence (AI) (which usually falls under the category of simulation/gameplay code) reacts and behaves in the system of rules you programmed. What you see is still a microcosm you brought into existence.

I’d like to also say that this phenomenon isn’t just limited to AI code, which some people might assume, because personally I find the rulesets of the reality to be more exciting than AI living within that reality. This is evident when you’ve written simulation code for a multiplayer game that is played by humans – and watching them interact with the reality and each other through it.

Emergence

So you’ve written some code, where a world lives, things move around perhaps, interact based on the rules you wrote, but then… something unexpected happens. What was that? How did that happen? The combination of rules created an outcome that you didn’t anticipate and didn’t write explicit support for. You’ve just witnessed emergence.

Emergence in games one of the most immersive and magical things a game can have. As the author of the rules that govern the system, you are essentially seeing the system take on a life of its own, and if you are the player, and it was your action that caused the new behaviour, you experience a feeling of contribution and discovery. You just bent the rules in some way, creating new outcomes, and discovered this facet of the system that not even the system designers knew about, because they didn’t even write code for it!

This is why I get excited when I’m finished the first version of a playable game – seeing a new reality ‘live’. Watching it do things on its own, and then witnessing what happens when a player interacts with it. Maybe it’s similar to some other scientific endevour where you are creating real life, but for me as a software engineer, it’s an incredibly magical experience.

“Conway’s Game of Life circuitboard” image courtesy of http://www.flickr.com/photos/wespeck/4574733303/

“LIFE” image courtesy of  http://www.flickr.com/photos/oskay/2472727681/

Posted in tech Tagged with: ,
4 comments on “The magic of writing game simulation code
  1. As I read your entry the only thing that was going on in the back of my mind was Laplace’s grand vision according to which an intellect that knows the cause of every past, present and future movement of every atom in the universe would in fact be able to meet with certainty at all times.

    If we as humans can’t handle as many as a couple of hundred variables then it makes you think how everything around us is kept together doesn’t it

    • Karl says:

      It does certainly make a pretty good case that we live in a simulation 😀

      That is also probably why creating a simulation and then watching it … simulate, is so wondrous to us, since we aren’t able to do it all in our brain at once.

  2. Bruce Chia says:

    This is something which is also very relevant to real-time action games, which is something I had to learn the hard way. I used to write a bunch of game logic in various objects and in collision events but my team’s game designer found a lot of bugs due to the unordered nature of events or the update sequence of entities. Having the game simulation code organized in phases, like a board game, certainly helps to preemptively remove many unwanted game logic bugs that could happen in real-time. I’m curious to know more of your thoughts on organizing game simulation code and your strategies on dealing with sequence and order.

    • Karl says:

      I would probably recommend organizing updates and even centralizing some logic (having single ‘objects’ responsible for various behaviour updates, especially if ordering is important). For things like collision events, you could go through a ‘physics update’, but then just mark things as they collide, then in a separate pass (in the same frame) go through and do something with the resulting marked objects. It’s a bit hard to talk about it in a non-specific manner. Hopefully that makes some sense 🙂

1 Pings/Trackbacks for "The magic of writing game simulation code"
  1. […] a blog post, Schmidt noted that game simulation code is the ruleset for gameplay. Gameplay states are written […]