What do game engines, Matrushka Dolls, Stackless Python, and your children have in common?
Python is a programming language often used to script games. Scripts are the bit of code where most game developers romp, it is the stuff separating the 'game engine' from the elves-in-tights that dance across your screen. Scripts make the elves dance and protect developers (somewhat) from the detail of the orcs-turning-creaking-cranks in the game engine.
Stackless Python is a variant of Python characterized in geek-terms by "continuations," "frame stacks," and "non-local jumps" (excellent detailed description here)... For discussion purposes, think of Stackless Python as a type of Python that allows developers to write lots of little-bits-of script without having to worry as much about how it is organized in terms of some really annoying computing constraints (e.g. event-driven coding styles). What Stackless Python promises game developers (from Eve-Online FAQ) is:
[to free game logic scripters] from many of the mundane tasks associated with models... The creative process of writing interesting game behavior is no longer bogged down by software or system limitations.
What does this mean? Well to some its about acting and actors, and this is where Harry Kalogirou steps in. He recently wrote a thoughtful piece about programming in Stackless Python ("Multithreaded Game Scripting with Stackless Python"), but embedded in the canons of his technology how-to is also a religious statement. It goes like this:
In most current game engines there is a fundamental flaw in the way the game engine and game code are viewed. The game engine is not viewed like a concrete system... Instead it is viewed at best as a library. It is viewed as a collection of functions...
Instead the game engine should be the operating system of the game, and the game entities should be like the processes running in it... the game code should run at a different “level” than the actual game engine, so that the game engine can have complete control...
...In a game engine, a process will be an “actor”. The “actor” will be the fundamental game creation block. The design tries to make everything an “actor”. The player is an actor, the objects in the game are actors and even the game world and the game itself is an actor. These actors are autonomous entities actually running in the game engine. The actor must be totally encapsulated and never has to directly worry about other actors.
To many of you reading this now, comparing game engines to 'operating systems' might seem underwhelming. Thank Microsoft for equating the computer with the desktop for most people. It wasn't always so.
The comparison of the game engine to an 'operating system' is interesting for its possible long-term implications. It suggests a process and a path based on *letting go.* It is saying that there are some parts of the game presentation (where we're at now) and the game world (where it may end-up) that I cannot directly control (except under great pain and a chance of dire mishap). Just as you now care very little how or where your documents on your computer are actually physically stored, so too might game developers come to care less about the actual motion, pathing, and ultimately perhaps behavioral detail about their characters. It would be as if to create a virtual world for your play developers will negotiate with another virtual world inside... Pull apart a Matryoshka doll and find another.
If you believe this, in the long-run it may force game developers to rethink their relationship with their design and code. Ultimately this will then affect the law governing players.
It has been said that parents often profoundly misunderstand their role in their children's lives: that children are just travellers passing through into their adulthood. So too perhaps with future game worlds. They will be less platforms that are owned than stages for actors, synthetic and real, upon which developers might have more or less influence but rarely complete control. And maybe that is okay too.