Why an elevator shaft? It’s the simplest type of “room” to generate right now, being composed entirely of a vertical shaft nearly always located at the centre of the skyscraper, and always in the same place on every floor (of course). It’s a much simpler subset of the general problem of generating building interiors, and lets me lay a lot of the framework that will eventually be used for the difficult stuff.
It also gave me a starting point for simulation : Elevators! While at first they may seem pretty trivial, a working elevator system is actually a fairly complex state machine made up of several components and independent parts. Even a simple model contains:
- Elevator car with door and buttons for each floor
- A separate door on each floor of the building
- A “call” button next to each door
- A motor on the top floor raising/lowering the car by cable, with a counter-balance
- Sensors inside the shaft to determine the car location
- A computer system that controls everything
- Not to mention independent safety brakes on the car to stop it falling.
A perfect system to get started with. I’ve thrown together a quick prototype system to try to get my head around what data will be stored where and when. In this screenshot you can see the elevator shaft and all its components and connections (in red), and on the right of the picture is the current state of the Elevator Control Computer. There are four components for each floor : the Button (to call the elevator), a Low Sensor and a High Sensor (at the bottom and top of the door, to detect the elevators presence), and the Door itself. They all report back to the computer on their status, and the computer issues commands to the motor and the doors to control the system. In this shot the car is on the 1st floor (notice the two sensors on Floor 1 lit up, and the Door sensor reporting it as open.) As the Elevator rises up the shaft you can see the sensors lighting up and the logic of the computer driving the motor to move the car. It’s actually kinda fun, like playing with an extended Lego set.
In past games we would have just created a bunch of C++ objects that represented each component, and written code to control how they behave. It’s served us well in past games, but it’s not going to be good enough for Subversion. Firstly we’re looking at many times more objects in Subversion than previous games, and secondly we’re really hoping to foster a strong Subversion community and open up the system to user made content. So with all that in mind, let’s talk about Script Languages.
Writing our game object logic and behaviours in script gives us tons of advantages and blasts opens the scope of Subversion. Firstly it makes it very quick and easy for us to write new game objects, by basing new objects on existing objects and building up a hierarchy of scripted behaviour code. Secondly it makes Subversion wonderfully extensible. In the past our games have supported mods to varying degrees of success, but we’ve never gone “all the way”. Ultimately mod makers will put up with ropey systems and manual editing of files, but regular game players will not. For any mod system to be truly successful, the integration of user made content has to be seamless for the regular user – he clicks what he wants in game, and it just works. This is our aim in Subversion.
Johnny and myself have worked on a couple of script systems in the past, and we’ve never been truly satisfied. It’s not uncommon for a script system to require extensive and often horrendous glue code built using supporting libraries, in order to get C++ talking with your scripts and vice versa. We’re looking for a language that is elegant and pleasing to look at (which rules out most), is easily embeddable in C++, and has decent documentation and support available. We also want a language that is as “readable” as possible and easy to learn – we’ve no interest in writing our scripts in what is essentially C++ (i’m looking at you, Un**al Sc**pt).
Python is a strong contender. Python has been around for a while, is extremely well supported and documented, and is essentially a fully functioning modern programming language. You could write an entire modern game in python, by writing your core engine in C++ and calling it from within Python. Numerous games make extensive use of Python, including Eve Online and Civ IV. In my experience over the last few days, Python is not particularly easy to embed, and essentially requires additional libraries such as Boost before it becomes genuinely useful to the C++ programmer as an embedded language. Johnny also believes Python to be quite slow, even by scripting standards. It does however have excellent built-in support for Objects, Classes, and all those modern programming features we computer scientists love so much.
Here’s an example Python script, so you can see what the syntax looks like. I’ve never been wild about Python’s style, to be honest.
http://www.amk.ca/python/simple/letters.html
Lua is the next contender. Lua is also used by some fairly impressive commercial games, including SimCity 4, World of Warcraft, FarCry, Psychonauts and a ton more. Lua is relatively new compared to Python, and this does cause it some problems. The API is still changing and being rewritten yearly, meaning a lot of the documentation and examples on the internet are already out of date and refuse to work. In my experiments Lua has proved to be much simpler to embed in C++, however it is much more down to the wire – Lua requires the C++ programmer to directly manipulate a shared stack to communicate with your scripts, which is analogous to programming while sitting on a pile of volatile explosives while spiders crawl over your body. Fundamentally Lua is designed to be embedded and controlled by C++, whereas Python wants to embed and control C++ in itself. Lua also falls over itself when you start thinking about classes and Object Oriented programming – it can do it, but only through some tricks and hacks. When combined with a couple of extra libraries – Boost and LuaBind, Lua starts to become much more interesting, and takes on much of the power of Python.
Here’s an example Lua script, so you can compare. I find it to be more “readable” than Python, but that’s just a subjective opinion I think.
http://lua-users.org/wiki/SciteCleanDocWhitespace
Ultimately there isn’t much between the languages, and it comes down to requirements and gut feeling as much as anything. Right now I’m going to keep working on prototypes using both languages until one of them does something so stupid that it makes my mind up for me.
