Suffice to say, Subversion progress has been slow during this time. Despite being a Director I like to arrange lots of creative time away from everyone else, because I’ve found it just doesn’t happen if I’m in a house full of people. For whatever reason, Creation is a solitary pursuit for me. Thankfully things have died down a little now, most of the crises have been averted or postponed, and I’m back to a more regular schedule. There hasn’t been a strong theme to the Subversion work since the last update – but I’ve been working on a number of different ideas, so I’ll just run through them all and you’ll have to put up with the scattershot delivery.
One of my intentions is to create a really swish graphical user interface – the sort that everyone wishes computers really used, and the sort that you only ever see in films. One of my ideas is to do away with the traditional 2d interface and project everything onto the inside of a sphere. Focussed windows can be brought closer in 3d space, and you effectively have a huge desktop extending 360 degrees around you. Looks kinda swish, so long as you have 4xAA. Otherwise the jaggies get you. I’m not 100% sold on this interface idea yet, but it’s a fun experiment.
We’re using offscreen buffers for the individual windows now (openGL FrameBuffer Objects specifically), which means I can do whatever I want with them after they’ve been rendered as they’re simply textures. I’ve also experimented with Vertex Arrays for performance enhancements in the city generator (previously it was rendering pretty slowly – the result of 50,000 odd buildings) and found some pretty big speedups, but the big revelation is the openGL Vertex Buffer Objects extension. It basically lets you upload static geometry directly into super-fast memory on your graphics card, and then render the whole lot with just a few commands. I’m still experimenting but it’s extremely fast, rendering the whole city (about 1 million polygons) in around 10ms. This is the way I’ll be going in future I think.
Regarding the update from February where I talked about script systems, I’ve now made the decision to go with Lua and integrated it into the game. All game objects can now have a script running on them, and I’ve developed some basic debugging and exploring tools for the script state. In the screenshot above you can see the System Explorer – it’s basically a system engineer’s layout of the whole elevator system, showing how all of the individual components are connected. Scripts running on each component have their own independent state and can communicate with each other by passing messages down the connections – you can see the Signal Bus in the diagram which runs vertically down the elevator shaft, connecting every component on every floor to the master computer that controls the whole elevator system. The control computer itself has the most complex of all the scripts, handling button presses on the floors, sensor inputs from the elevator shaft, and controlling the doors and main motor. For those of you who are interested in scripting for Subversion, here’s a sample of script code from the Elevator Control Computer, which controls pretty much everything. Functions in scripts are called automatically – all objects can declare a function called Update, and it will be called once a second if it exists. Similarly, message handlers can be written with names matching the incoming messages – eg the Elevator Door has a function called ReceiveMessage.OpenDoor, which is automatically called when the door receives an OpenDoor message from the control computer.
For those not even remotely interested in scripting languages, obviously don't click on this incredibly geeky picture.
Regarding the quad-tree experiments from the last Subversion update, I’ve since concluded that they’re not a particularly good idea. Locking the game world to square blocks makes life easier for the map makers but pretty much everyone else suffers, including the players who are limited to a fundamentally blocky world. There are ways around it but eventually you just end up asking what’s the point – we’re going with arbitrary polygons and that’s it. It did make me realise how bad the existing map tools are though – lots of work is required here I think. Although I am planning to do a lot of procedural content generation, you can’t really beat hand-made locations and I’m thinking the most important bits of the game will almost all be hand made by Introversion. Procedural content will widen the experience by filling in all the less important surrounding areas. And if we get the script system and tools right, user made content will give a steady stream of cool new content after launch for everyone to get stuck into. That’s the dream – procedurally generated content, hand made special content, and user made content, all in one game.
)
