|
|
|
 |
|
|
 |
Moving on
Posted by Byron
on Mon Jun 29, 2009 9:57 am |
|
 |
| |
Some of you already know this but with great sadness I am moving on - leaving Introversion. The good news is that I am starting at Sega Sports Interactive in the middle of July 
Thank you for your messages of support, it's been great interacting with you!
I want to thank Introversion for the opportunity of working for them - it's been interesting and certainly educational and I wish them the best for the future!
|
|
 |
|
 |
| |
|
|
 |
It's all in your head, Part 17
Posted by Chris
on Tue May 26, 2009 3:27 pm |
|
|
| |
I started working on some new security systems for the test building and quickly ran into problems, prompting a slight rethink of the Electrical Systems part of the project. I designed the system to support complex multi-part systems – specifically an Elevator system, which is made up of many components duplicated on every floor, with some quite complex controlling logic written in Lua script. But an Elevator system is about as complex as it gets, and many systems in a building are much simpler. In fact, the Sliding Doors are a much more sensible example – an entirely self-contained system, made up of a handful of sensors, motors, and maybe a control chip of some kind. In my previous design I was supporting complex stuff like elevators at the expense of making simple stuff like Sliding Doors _much_ more complex than they needed to be. Fundamentally, a sliding door doesn’t need anything as complex as a Lua script to drive its logic.
In fact, you can build a sliding door with quite a simple circuit layout.
The way it works is quite simple. The two motion sensors have a Circuit Pin, which carries a value. A value of 1 means “yes”, and a value of 0 means “no”. When the motion sensors detect movement in their zone, they set their pin to 1, and when there is no movement they set their pins to 0. Similarly, the Actuators are controlled by a Circuit Pin – set it to 1 to make the actuators open, and set it to 0 to make them close. The actuators are the cogs that drive the doors to open and close. So by wiring the motion sensors into an OR gate (so either motion sensor can trigger both doors simultaneously), then wiring the OR gate into the actuators, you have a basic “Motion Activated Sliding Door” circuit.
However there is a small problem – as soon as both motion sensors are off, the 0 value from them is passed to the Actuators, and the doors close. Typically you’d expect sliding doors to stay open for several seconds, even if no further movement is detected – otherwise you’re likely to close the doors on people who are still walking through. So by adding a “Low Delay” Circuit Component to the system, we can fix that problem. A Low Delay component allows a value of 1 through immediately, but a value of 0 is delayed by (say) 5 seconds. Adding this component to the circuit causes the doors to open immediately on detection of movement, then once no further movement is detected they will close after a 5 second delay.
I designed this entirely in paint shop pro (the images here are the actual designs I was playing with – paint packages are excellent for rapid prototyping). Once I had an obviously working design, I decided to try to make some other circuits using the same basic components, plus a few others. The more circuits I designed, the more convinced I became that this would be perfect for most of the simple systems in a building.
I’ve seen a similar system before, in ‘WireMod’ : a mod for ‘Garry’s Mod’ which is itself a Mod of the source engine. They use a similar system of pins and wires to send zeros and ones around, and manage to control some fairly complex systems using it. I think Eskil has been working on something similar in his game Love as well, using simple signals and connections to model complex systems. I think a system like this would suit Subversion very well.
Here are some pics of the new Circuit system working in the sandbox building. The first shows the sliding door arrangement, the second shows a test set of laser trip wires connected to a security light. The Laser emitters are on the left of the picture, and the laser Sensors are on the right, along with the logic gates and the security light. I used some nice Bezier curves to show the circuit wires, and the colours indicate their state: green for 1, red for 0.
This new method of building systems has the advantage that it’s conceptually very simple, and also easier to work with as a developer. Using the previous system, even something simple (eg a laser trip wire) would have required a control computer chip with a Lua script to run the logic. Using this new system, circuit tampering becomes a very valid way to progress – every one of these circuits can be bypassed or broken with careful cutting of the right wire, or setting a pin to a 1 or 0 at the right moment. Furthermore, this could lead to an awesome crafting system for the game. Want your guys to set explosives with a 30 second timer? No problem, you can build the circuit yourself. Want your guys to bypass a four digit Keypad Lock? No problem, you can build a device that rapidly enters every single 4 digit code until the door opens. Or maybe you are securing something valuable in a locked room, and you want to build a custom security system, with moving laser tripwires, pressure sensors under the floor, motion sensors in the roof, temperature sensors, cameras, the whole thing, all wired into a control panel in a different room, with automatically locking doors to capture intruders. Not everyone is going to want to take on projects like this, but some will, and this system will make it possible. And bypassing such a system would be a ton of fun.
I haven't removed the Lua script integration - I think its still going to be required for more complex systems. Ultimately any complex system is going to have a control computer, which connects to all the components, and runs Lua logic to make it all work. But you shouldn't need it for simple stuff like this. And with just a few general case components (logic gates, timers and counters, sensors, actuators, emitters) we should be able to build almost anything.
When your guys open the safe on the 25th floor and find this time bomb inside, and the timer is ticking down from 30 seconds, that’s how long you have before the whole thing explodes in your face. Do you cut the red wire, or the blue wire? Cutting the right wire will stop the timer and disarm the bomb, cutting the wrong wire will set it off. With the system described above, this would become a genuine choice based on the actual operation of the components used to build the bomb. A little bit of rapid research will tell you this particular type of detonator is activated by sending a 1 signal to the 2nd pin. So you cut the 2nd wire, stop the timer, and complete the mission.
Or if you’re feeling lazy or you aren’t interested in all this electrical engineering nonsense, you could just pick up the bomb and throw it out the window. We have the physics for that now too.
I have no idea how many government red-flags I’ve accumulated writing this blog entry and drawing these diagrams, but it’s got to be a few. If we get black flagged and one day “disappear” in some unmarked vans, you’ll know what’s happened.
|
|
| |
|
|
| |
|
|
|
It's all in your head, Part 16
Posted by Chris
on Thu May 21, 2009 5:51 pm |
|
|
| |
Seven weeks ago, the Subversion project team size doubled. We hired a very smart fulltime undergraduate from Imperial College called Andrew Lim, and he’s been working on Subversion for the past few weeks as a Summer Placement. This is quite a big development for Subversion, and I must say it’s quite a relief to not be alone on this massive and epic project any longer.
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.
|
|
| |
|
|
| |
|
|
|
Darwinia+ deep and dirty Part 2
Posted by Byron
on Wed May 20, 2009 11:03 pm |
|
|
| |
It has been a few weeks since the last entry on optimising Darwinia+ on the Xbox 360. Most of that time has been spent hunting down any possible areas to speed up the code base and basically shaving as many cycles as I can from the frame time in order to get above the threshold of 30 frames per second. It’s been a tough time but the speed-freak inside me loved every minute of it. There are many ways that Darwinia+ can be optimised but one of the most obvious is to make use of the three cores that the Xbox 360 has, currently the game is just using one of them. Rather than go gung-ho and turn everything you can find into a thread on a different core I sat down to look at the areas of the game for something that could be easily broken onto a separate thread without major impact (and therefore less risk) and would reap the most benefits.
It may not seem like it but Darwinia+ has hundreds of sound effect files. There are many variations of each type of effect so that when you are listening to the game playing you get a broad range of sound rather than the same old sound playing over and over again. As a consequence of this we can’t store all of the sounds in memory at the same time so we employ a caching system that reads in the samples, decodes them from OGG to native format ready to be played. As it turned out the actual act of decoding from OGG was appearing quite high in each of the PIX trace runs. This became my top target for breaking out into a thread because it satisfied the criteria of least risk and highest reward. Thankfully the sound system was quite well designed and it took less than two hours to get the sample decoder working in its own thread on another core and much to my surprise it worked first time.
Of course refinements were added over the next couple of days once numerous tests were done to make sure it didn’t kill thegame. After running PIX on the outcome it became clear that this one small act that took two hours to complete had a massive impact on the speed of the game and we were much closer to the 30fps target. As well as tackling potential speed bottlenecks using multi-core techniques a lot of analysis has been done on each of the games sub-systems with each area eliminated one by one. This is a very laborious task and it’s very easy to fall into a paranoid state where you are absolutely convinced that an engineer deliberately wrote the code just to make your life hell. Of course the reality is that the next generation of coders being pumped out of university don’t appear to ever have the need or inclination to look at what the compiler produces or consider the actual impact on the CPU that a small innocent looking piece of C++ has. I was shocked to learn that at least one of our engineers had never done any assembly language – probably not needed in a Java dominated computer science course.
This brings us neatly to the education side of optimisation work. It’s fine to speed up the game but that is useless if all that is going to happen is your engineers will find evenmore imaginative ways to make it slow again – albeit not on purpose but it will happen. So, as a know-it-all speed freak part of the job spec is to try and educate the masses into how not to undo all of your hard work. This is made even more fun by the various shades of ‘glazed over’ that each of your engineers can muster when you start to explain the intricacies of cache lines and why they should re-order the member variables of a class into most used and least used.
You have to keep trying though because the alternative is yet another round of the same thing on the next game.
|
|
| |
|
|
|
|
