Introversion

[Chris]

I’ve started working on some of the simulation aspects of Subversion. It’s a huge and daunting area, and a big part of the problem with taking on such mammoth tasks is often not knowing where to start. The building generator in the previous blog post generates relatively simple external facades based on the traditional tapered Manhattan skyscraper, then fills in some minimal structural detail on each floor – the floor itself, the steel supporting columns that run up the centre of the building, and an elevator shaft.

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.

[shinygerbil]

*craps self with excitement*

That is really awesome. Every post just gets deeper and deeper.

[NeoThermic]

Chris wrote:

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.

[...]

Chris wrote:

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.

Are spiders and explosives being a requisite of Lua not enough?

NeoThermic

[Feud]

My word, it's a 3d version of SimTower!

[mcnicholls]

Game objects in scripts definitely sounds like the way to go for a game like this and the ability to sub-class and add game object code would make it very dynamic and extendible

Only really used it for a bit of Ruby on Rails, but have you considered Ruby?

I found it quite nice to use and it feels more OO than Python does. I am not sure how easy it is to embed though. I have looked at embedding Python in the past and found quite a lot of documentation on it, but didn't turn up as much documentation for Ruby.

Anyway really excited by the progress

[djspiewak]

Ruby has almost trivial interop with C/C++. Basically the language API is written entirely in C, which means you can make calls and operations to Ruby stuff in C almost as naturally as you would other C functions (if that can be considered natural). The inverse process is actually even easier, allowing virtually zero-conf calls from Ruby to C (you have to run a special script to generate the proper makefile). You *require* the relevant .{so,dll} by name directly in Ruby and then call the functions directly as Ruby methods.

To be honest, the script-embed-in-C++ scene is pretty limited. Most of the innovation in that department has been focused on more "enterprise" languages like Java.

[briceman2]

FYI, you might already know, but embedded Python has some nasty memory management issues (which are due to be ironed out in a future release I think, or maybe have been just recently -- does anyone know?).

I watched the delevopment of the open source Game of Life viewer, Golly. It has a Python script engine tacked on. There are serious memory issues in that Python won't return memory to the global pool until the interpretr instance exits. Since Golly's performance is memory bound this can become a limiting problem in certain cases.

I think the basic issue is philisophical -- Python objects are immutable, and garbage collection is automatic. Lua forces you to think closer to the machine, more like C. It is also much more lightweight than Python, and often faster, certainly less memory intensive (see Great Computer Language Shootout, etc.).

Take this with a big grain of salt, but I think Python is top heavy for your application. Lua was the first language that came to mind when I started reading your post.

[Pentadact]

Garry talks a bit about how he found LUA to use in making Garry's Mod, here on his blog:

http://www.garry.tv/?p=346

He didn't like it, but he doesn't seem to know of an alternative.

[desktopsimmer]

Probably very interesting stuff about the programming aspects of subversion, If I could program and at least understand it Something I'll start to pickup when I have time.

The only issue with elevators is that most are staged in really high skyscraper, as the the weight for the counter weight and the cable would causes problems for the motor. So if you want to 'simulate' a building in 'New Subversion' city, you'll have to look into the routes that a person would/could use to get from ground to floor 92 via 3-4 elevators, plus all the delays.

[martin]

Ok, so I seem to be picking on the area no one else is talking about but surely you could make that lift in a much simpler way, without simulating sensors and control computers etc? I'm beginning to think this is some kind of totally awesome version of uplink what with all this anonymous corporatism, the entire world being simulated, virtual computers contolling everything... either that or a totally cool wargame

anyway, I'm also excited about this scripting stuff, personally I prefer lua because it's more similar to languages I already know, but meh - I can learn a new syntax for when I'm modding subversion

[The GoldFish]

Man, who didn't play Simtower? There's some elevator simulator if ever you needed some!

Also, I'm glad to hear you're looking at scripting languages, although I'm unsure as to at what stage they transform from being a production aid into a stumbling block. Maybe you could talk to the bitblot guys - they used a lot of Lua in Aquaria.

I get the impression that a lot of the code familiar guys here are going to promote python, but uh, I suggest you decide for yourself, and it would be interesting to see why the bb guys chose Lua over it.

[dudecon]

Quote:

Some may even go so far as to infer suggested gameplay from said media...If you feel any of the above happening to you, please listen very carefully. You are mistaken.

Okay, so ignoring for a moment the above, I'm going to take a stab at where this is headed.
From the very name "subversion" it is clear that this is not trying to be a city simulator. From the shots we've had earlier of interior spaces, and the continuing work on them, we know that Subversion is headed toward a large scope, but with very fine granularity. Now we're seeing visual representations of completely extraneous control circutry, unless the user will interact with the basic infrastructure controls. The scripting extension means that objects can be programed in some way.
We also know that Introversion is about comprimising computer systems (both in Darwinia and Uplink), as well as all-out large-scale warfare. Why do the buildings have generated structural members, unless we can interact with them?

I'm getting the feeling that Subversion is trying to be a game about the covert intrusion (and possible comprimise) of urban infrastructure and landscape. It will be about how an attacker can enter and conquer a city, perhaps without being seen. It will be about how the fine details can be leveraged to accomplish far-reaching goals. Observing and hacking into elevator controls is only the begining. Air conditioning? Traffic lights? Setting up snipers to control whole square miles of city? Setting demolition charges and bringing down whole skyscrapers? The detail level at this point is immense, and only appears to be increasing, which makes no sense unless the user interacts with the enviroment at all of these levels.

But really, the only thing we know for sure is that I am mistaken.

[Artman40]

And so, "Subversion Collection" is created. Seriously, this engine seems very good for multiple different game genres.

[Montyphy]

martin wrote:

Ok, so I seem to be picking on the area no one else is talking about but surely you could make that lift in a much simpler way, without simulating sensors and control computers etc?

Sure, there are simpler ways but I'm guessing Chris is hoping that by using such realism it may make it easier to add new interfaces for objects and users to interact with the system.

[Mickiscoole]

The GoldFish wrote:

Man, who didn't play Simtower? There's some elevator simulator if ever you needed some!

I remember reading somewhere that SimTower started as a lift simulator