I made quite a big leap in terms of integrating the local Site with the wider City views, and everything now has much more of a sense of scale. Here's a lovely new screenshot, my favourite from Subversion so far. The man in this picture is only there for scale purposes and won't be playing any part in the finished game (especially since I stole his image from Google Sketchup).
I want to design a system in which I can build highly complex systems made up of lots of smaller Common Components. I took a shot at this with the Elevator Systems last year, but I was too focussed on getting the script system working well. So in the elevator system almost every component is running a custom script – the Sensors, the Doors, the Buttons, and of course the control computer. I now believe I can build almost any system for Subversion out of a few standardised components – specifically Sensors, Actuators, Emitters, and Controllers. Sensors detect an object or event in their zone – such as Motion, Proximity, Heat, Light, whatever. Actuators are basically motors, and move other objects around. Emitters are things like lights, lasers, speakers. And finally Controllers are the computer systems that make everything work – and these are the only objects that really need custom LUA scripts.
Rather than messing with the working Elevator system, I decided I’d first create those four basic components, and then build a new system using just them. I picked a supermarket Sliding Door as a good system to try to build. This is basically a pair of glass sliding doors (moved by Actuators). The system is triggered by a motion sensor pointing at the area in front of the doors. That motion sensor sends its trigger message to the controlling computer, which activates the Actuators controlling the doors. The doors open, and Proximity Sensors tell the control computer where the Doors are at any point so it can tell the Actuators to stop once the doors are fully open/closed. A perfect example of a complex system, built up out of simple standardised objects, with just a single (very simple) script running the whole thing. This Sliding Door object could then be packaged up and deployed in any other building as a stand-alone system.
Here’s a video of this new stuff in action. The first half shows the Sliding Door operating in the testbed building (a simple 10-storey office). You can see the Actuators moving the doors, and the Proximity Sensors lighting up as the doors pass in front of them. I then open up the WorldObject Inspector, which shows all of the state variables in the Control Computer (controlled by Lua code). The second half of the video shows the same systems (Elevator and Sliding Door) deployed in an actual site in a city. Still tons of work to do to get the systems at the right place, so if you look closely you’ll see objects in crazy locations.
(xvid codec required)
Why am I doing this? Why on earth am I simulating sliding doors down to the level of proximity sensors and actuators? Buildings are hugely complex beasts, full of lots of different overlapping systems – doors, locks, elevators, cameras, computers, networks, phones, fire control, air control, security guards, staff. Ultimately the Subversion game world will be more real, more controllable, more interesting, and more packed with possibility the more detail we simulate the objects in it with. If you look at modern blockbuster videogames, the number of possible interactions with a world is usually extremely small – and usually involves a gun in your hands – and that’s because the design team had to create every interaction by hand. By simulating complex systems in high detail, I don’t need to think of all the ways the world can be changed – it will just work.
For example – smash one of the Actuators with a hammer, and one of the doors will stay where it is, while the other door continues to open and close. Smash one of the outer sensors and the Actuator will push the door of the end of its slide. Cover the motion sensor with a plastic bag and it wont send any detection messages to the computer, leaving the doors closed. Stick some chewing gum over the inner proximity sensors and they will think the doors are already closed, thus the control computer will leave the doors open. Push a bin in-between the two doors and they will close on it, and sensors on the insides of the doors will detect this obstruction, and the doors will open slightly, then try to close again. The doors will be stuck in an open/close/open loop, constantly hitting the bin and re-opening, just as you’d see in real life. Cut any of the signal wires, or short-circuit them to set a high or low value. Or just plug straight into the control computer and tweak the status variables in memory, making the system do whatever you want whenever you want. None of these are activities or opportunities that I have explicitly created, but all are possible because I’ve simulated the system in sufficient detail. The possibilities for amazingly complex systems and interactions – from Introversion AND from the Subversion community – is kind of breathtaking.
? Still wondering tho how he's going to make this whole world feel alive with this clean look of the buildings and such, I can remember an old screenshot: 
