Andrew Lim’s job is funded by a research and development grant from the Technology Strategy Board – a UK government body set up to promote innovation and research in the commercial world. Part of their mandate is to strengthen the bonds between industry and academia, and we’ve always maintained strong ties with our university of Imperial College London. We’re doing so much R&D in Subversion that we were able to think of several really interesting research areas right away, and the TSB agreed to help fund the project with us, with Dr Simon Colton acting as our liason at Imperial College.
So Andrew has been working on the project of Data Driven Generation. What this means is that he’s working on ways to specify the generation of content (specifically for Subversion) through data files rather than hard coding. Currently the city and building generation is written as a number of C++ generator functions, which makes it difficult to expand, especially for people who don’t work for Introversion (ie modders). Once Andrew has finished, we’ll be able to specify the generation rules for a city, the buildings in the city, and the areas within the buildings, all using generic data files. We’ll be able to expand the generation simply by adding more data files that specify more content in further detail.
Here you can see an example of his initial work, replacing the standard building generation rules with a general-case data rule that generates Pyramids. The Pyramid is pretty much the simplest hierarchically defined shape you can make (you Contract, then Extrude, then Repeat), and an obvious starting point. I’ve got high hopes for this project.
On top of that, Gary spent his first day on Subversion this week. He’ll be working on the editor that we use to make all the custom hand-made content. His ultimate objective is to craft a tool that will mix the best of procedural generation with the uniqueness of hand-made content – so for example you might generate a 30 storey empty building, then manually edit the 29th floor with some really cool stuff, then tell the editor to fill in the rest using the existing Geometry Generator. These two systems combined have a lot of potential.
Continuing on from Part 14, I’ve been attempting to write a generic Forces simulation system for the game world. My aim has been to handle all the basic collisions and forces that you naturally find in a game world – ie I want to stop people walking through walls, or each other, and I want people to be able to walk into Elevator cars and be lifted up when the car lifts up, that kind of thing. There is a ton of work already done in the area of real time physics, and I’ve no intention of writing a full physics simulation system – it’s not required for Subversion, and it’s the kind of job I could just vanish into for a year and emerge at the other end with some software that pretty much every other games company under the sun has already written. I believe a simpler solution is appropriate for Subversion. Nevertheless, I’d always been curious how hard it would be to bring some rigid body physics to the game world, and I’d been investigating a free 3d physics library called BulletPhysics.
Integrating the BulletPhysics library into Subversion took less than two hours. I’m actually very impressed. The set up is very simple – you tell the library the basics like the ground plane and the force of gravity, and then you feed in your static geometry. In the case of Subversion, I simply fed in the entire triangle mesh for the ten storey building I’ve been using as a testbed. No organisation required, no hierarchy of data, just a giant pool of triangles. You then attach BulletPhysics simulation data to your world objects, and tell the library what shape they are, how heavy they are, etc. BulletPhysics supports basic cubes (which I’m using in this test), but also loads of other primitive shapes like Cylinders, Spheres etc, and even complex triangle mesh models. Every frame you call the Bullet Physics update command which progresses the physics simulation a small amount, and then you simply read the positions and orientations of all your world objects directly from the Bullet Physics API. This is my kind of API design.
I spent less than a day on this in total, and got some pretty exciting results even from that brief investigation. I’m not entirely sure how it fits into Subversion yet – I still don’t actually want real physics simulated in the game world – but for visual effects, explosions, dropped objects etc, this might be an extremely useful capability for the Subversion engine to have in its back pocket.
In this video, all of the large red boxes that you see tumbling over each other are being handled by the Bullet Physics library. All the rest of it - the tiny bouncing particles, the gun shot simulation and the opening and closing doors, are all using Subversion's internal engine.
In case it’s not obvious to anyone reading these blogs, Subversion is a really massive project. I think it’s fair to say that it’s too big for us, beyond our scope as just the next game launch. There just isn’t going to be time to complete Subversion to the 100% Gold Plated solution that we have in our minds. So one of the things I’m really keen on is making Subversion very expandable, and thinking of the game launch as the start of the process. I find the Dwarf Fortress project to be fascinating and hugely inspiring. These guys released the first version of this game years ago, and they continue to add new features and capabilities to the engine as the years go by. They deepen the quality of their simulation with every new version, expanding their game inwards. It looks terrible and the interface is appalling, but the depth of their simulation is staggering. If we could make the business model work, this gradual release and improvement over several years could be a huge winner for Subversion.
), but Valve had the liberty of being able to spend goodness knows how many years developing the initial release. Going back to Dwarf Fortress, there's a terrifyingly in-depth 
