|
|
|
 |
|
|
 |
Keeping IV from the Wolves
Posted by Mark
on Fri Jul 03, 2009 11:24 am |
|
 |
| |
“Success in 2009 is survival.” I can’t remember who told me that, but it is a quote that I have found myself repeating a number of times this year. I would normally consider it weak leadership to set a goal so menial as simple survival, however it’s been a very rocky few months for Introversion and there are times when one needs to accept the reality of the situation and I think it would be foolish to continue to try to grow the business when we are clinging on to the cliff edge with our fingernails.
I’m going to come on to the steps we have taken to ensure that we can keep the lights on, but I also think it’s important to understand how we have ended up cash strapped and months from our next release. Introversion is founded on a very strong belief that maintaining creative integrity is the most important aspect of the business and that belief has informed our strategy and shaped our growth. We have avoided work for hire projects and have used the sales revenue from each previous game in order to fund the next. Rather than being paid by a publisher during the development process we have to wait until the game has shipped and whilst this puts a strain on the cashflow during dev, the upside is that we receive a much larger chunk of the sales post launch.
This method works as long as each previous game generates enough cash to complete the next title, but the whole thing goes wrong when a game doesn’t sell as many copies as expected. This happened to us in September last year when we launched Multiwinia. From our point of view we considered this to be Introversion’s fourth major PC title and we expected to continue our upward trend of game sales – each of our other three games had sold more than the previous and we really expected Multiwinia to do the same. Sadly that wasn’t the case and we found ourselves in September last year staring at day one sales data and realising that we were going to struggle to make it to the launch of Darwinia+ on Xbox Live arcade.
Now this is quite a scary situation to find yourself in and the temptation is to panic and whilst I’m going to present a rationale view of what we did it’s important to note that we suffered an enormous loss of morale and the team very nearly fell apart. When faced with this situation it’s critical that the top team are positive and support each other – if the board members are weeping with their head in their hands talking about the end, then the employees soon pick up on this and things just spiral down. Probably the hardest thing I had to do, but also probably the most important was to stay positive and get the other directors to do the same. In hindsight I think we handled it well, but my advice to anyone in this situation would be to surround themselves with impartial outsiders who can provide the perspective on the situation. It’s very easy to feel swamped and overwhelmed, but strangely things don’t seem so bad when your massive problem is dismissed as a “short term cash-flow issue” by your business advisers.
Keeping morale high is critical, but I also want to describe some of the practical steps that we took to stay afloat. So firstly it is important to obtain an accurate view of the problem. We run a monthly cash-flow projection that forecasts our income (from our back catalog of games and the other revenue generating projects that we run) and our outgoings (wages, rent, tax, project payments etc) at the end of each month is a number, if it is red (negative) we have an issue and if it is black we are fine. The size of the problem is indicated by the size of the number and if it’s big and black then everyone gets a bonus. The problem in September was that it wasn’t big and black instead it was small and black and it wasn’t long before it turned red. The important point to note was that we knew immediately how long we had before we couldn’t afford the wage bill. We also knew how long it would take before the next big cash injection (the launch of Darwinia+ on the Xbox 360), so the challenge was to make the cash last long enough.
So armed with detailed knowledge of the scope of the issue there are only two things that you can do, and you usually need to do both:
1. Increase the cash in
2. Decrease the cash out
We are quite a small organisation and we run pretty efficiently so reducing our spend is pretty tough. We went through the cashflow looking for lines to cut and the biggest related to our old office (a sexy townhouse near tower bridge) this was the first casualty. Sure we didn’t want to move out, but when we rolled up to our new rented office space it turned out to be better – we were now all together in a single room (before we had been spread around the house and never talked to each other) and it meant that we could communicate better and a stronger sense of team emerged.
The second largest outgoing in the cashflow represented the enormous sums that we pay to the British Government each month for the privilege of living and working in this glorious nation. Of course we had taken steps to minimise our tax liability (because we are smart and have a good accountant), but it’s also possible to agree terms to defer the tax to the end of the financial year. So we did exactly that it’s completely legal and the tax office were surprisingly lenient with us – of course we’ll need to pay it back, but we can defer it until after the launch of our next game and that’s what’s important right now.
The third big cash sink is the most important – salaries. We have a small highly motivated efficient team and I’m pleased to say that we didn’t need to lose any of the guys. Making people redundant is an important option that needs to be on the table, but I’m pleased to say that we didn’t need to push anyone out.
So then we looked at increasing the flows of cash into the firm. Firstly we redoubled our efforts with Multiwinia. We phoned up Valve and as always they helped us out. If you can get on a splash screen on steam then you see a massive increase in your sales figures. You usually need to drop the price, but often it can be a sensible move. It certainly was for us and in the run up to Christmas we saw a number of promotions that really helped to bring the money in.
Now Multiwinia is our newest game, but there are three others that we sell from our store in reasonable numbers every day. Our next big push was to try to increase the number of sales we were making of these games. Our web site is made up of separate sites for each game and the company home page – if we could increase flows between those sites or increase the conversions (number of people who bought from us after visiting one of the pages) we would be much better off. We realized that we were way out of date and doing the e-commerce thing really badly. It’s now possible to track traffic though a web site and optimize the site to result in maximum purchases. We launched a project (codenamed “Glengarry”) to metricate our site with Google Analytics and test two new Uplink sites to see which generated the best results. The project is still running and we haven’t seen massive improvements, but we know a lot more about e-commerce then we did a few months ago and I’m confident that as we keep improving the site our back catalog sales will continue to improve.
As well as trying to sell more we wanted to know if we could generate entirely new revenue streams based on our existing project portfolio and with a little networking it soon became apparent that there were a couple of opportunities that we needed to take advantage of. Firstly the same government who collects tax from all us serfs also gives it back to techno-serfs who conduct research and development. Remember what I said about Introversion’s Creative Integrity, well the reason we need that is because we like to push the boundaries and do stuff that has never been seen before. Now stuff that hasn’t been seen before = research and development so a quick call to the boys at Braithwaites and we’re looking at another chunk of cash coming our way.
Now as well as giving back tax on R&D conducted in the past, the government also provides funds to support projects that meet the right criteria and they really dig it when Industry jumps into bed with Academia. Being an ex Imperial College London graduate I had maintained links with that hallowed institution and we crafted a proposal based around our Subversion project. An august body known as the Technology Strategy Boardgranted us funding and away we went.
In September last year I looked at a cash-flow that said that Introversion was out of money by Christmas and a plan for Darwinia+ that said that we wouldn’t be able to launch until June. It’s now ten months later and I’m looking at a project plan forecasting the launch for September / October and a cashflow that runs out around the same time. It is certainly not the case that we are out of the woods and I’m currently trying to craft a proposal for a bank loan, but I think we’ve done a pretty outstanding job over the last few months. In sticky times like these we all need to stick together and I’m aware that the descriptions above are pretty brief – if you are a small developer in the same situation drop me a line and I’ll try to help you out as much as I can.
|
|
 |
|
 |
| |
|
|
 |
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.
|
|
| |
|
|
|
|
