Back in 2005, I began to have ideas about how to make very stripped down, cheap to develop games that would be interesting enough that they might make some money in the budget market. Of the many “verb game” ideas we originally had, one of them stood out as the easiest to get under way, and that was Fireball, the game that would become Play with Fire. (We weren't able to use the name Fireball owing to an IP conflict with a curmudgeonly fellow on the Isle of Man).
post examines the many things that went wrong with this project – and also the
many things that worked out nicely.
1. No Money
By far the biggest problem that the project faced was the lack of budget. Now even from the outset, the plan was to develop cheaply – but I had originally been thinking $50,000 for a budget PS2 title (coming in at the end of the PS2’s life cycle, when there is the maximum possible installed base and a great opportunity for budget titles). In fact, we did have a deal with a European publisher to fund us for the full $50,000 – but for reasons that we will touch upon shortly, we never saw this money, the PS2 version had to be scrapped, and at that point the project was somewhat doomed.
The version we made had a budget of about $5,000. On the whole, it is miraculous that we delivered anything!
2. No Passage to India
We set up a new developer in India – Fantasy Labs – to work on this project, and began working with Sony in London to find a way to get a PS2 devkit to India. This turned out to be monumentally difficult! Sony wasn’t the problem – they were actually tremendously helpful and supportive – Indian customs were the point of tension.
Perhaps if we’d been a larger company we could have greased the wheels better, and found a way, but without getting the devkit into India we couldn’t get the budget for the PS2 version, and eventually the battle had gone on for so long that the publisher in question had to break the news that it was too late to develop a budget PS2 title.
We were disconsolate, but at least we could ship the PC version.
3. No Tweaking Phase
Yet there was a major problem with the PC version: we didn’t have the money to finish it. The most important stage in any game is tweaking and blind testing, when you sit it down with players and observe their reactions to the game. This phase allows you to eliminate any confusion on the part of the player, smooth any rough edges, and generally streamline the play of the game.
AAA games get months and months of tweaking time – in Nintendo and a few other places, games have the luxury of not being released until they are just right.
We had a zero-length tweaking phase. I conducted three blind trials with the game – but without the budget to pay for the programming work to fix the problems found, it was pointless continuing. Despite knowing we had problems that needed to fix, there was nothing that could be done about it.
(One particular problem haunts me: the Puzzle Path, which many players will struggle to enjoy, is directly in front when the game begins. Most players end up trying this Path first, and get very confused. I really wanted to make the Fun Path be directly in front – this Path is easiest to understand, and comes with essentially no risk of failure. But without the money, we couldn’t get even this simple fix made).
4. Spiraling Code Base
Additionally, we had a problem with the code base. Fantasy Labs had another development contract at the time, which was helping meet the bills. But this project required a much more complicated code base than Play with Fire, and sadly a decision was made somewhere to keep both projects on the same code base. This meant that the project was constantly being remade as the code base for the other project was refined, giving no end of development problems.
5. Too High Spec
By far the most devastating of the problems resulting from the spiraling code base was that the final game turned out to be too high spec for players in our target audience to be able to play the game! Ironically, the development tool set ran on any more machines than the final game – some people who worked on the project have never seen the finished game running!
Depressingly, this has had the most negative effect on the project. While we have had many downloads from Manifesto Games, the vast majority were unable to get the game to run.
1. Verb Game Method
The basic idea of the “verb game” methodology was to identify some unusual verbs with playful aspects, and develop these in isolation into a game. I believe this worked brilliantly, and I’d do it again if we had the budget.
The original plan – to be developing games in less than six months, and to have a portfolio so we were not dependent upon the success or failure of any one title – was completely sound. But of course, without the money we couldn’t follow through.
Nonetheless, I believe the strategy was sound, it was simply the implementation which let us down.
2. Arson IS fun!
Burning things to the ground in Play with Fire is tremendously entertaining once the player knows what they are doing. I believe there’s potential for a future game to build on this mechanic, although I very much doubt it will be done by us.
The play of the game is really quite original. Although some of the platforming elements work similarly to conventional platform games, this is the only game I know of that has serious consequences when you jump around indiscriminately, since the platforms you touch can burn to the ground shortly afterwards, along with any others that are connected to them!
Just watching the flames spread through a big object like the Trojan Horse in ‘Helen’, or the Houses of Parliament, or a WWI biplane is inherently satisfying.
3. Multiple Paths
The multiple paths to allow for players to play in different ways was a sound idea – but alas no information is provided to the player to judge how to approach this. This was a product of the lack of tweaking phase, already mentioned. Despite this, the basic idea of structuring the game to be played in different ways while using the same engine emerges as a sound concept.
Anyone can play the Fun Path and get some enjoyment from it, while Fiero-seeking players have the Challenge Path, and players who prefer cerebral riddles have the Puzzle Path. Despite the problems, I’m still pleased with how this worked out, although doing it again I might be tempted to offer a more explicit mode select screen.
4. Open Pool
The reason the multiple paths approach worked to some extent was the tremendous talent of the Open Pool – a group of non-professional level designers who worked on the project in return for a share of revenue (at least on paper – in practice, without the PS2 version we were never going to see good numbers).
The open pool method worked something like this:
- Firstly, we invited people to get involved, specifically looking for people who had not worked professionally in videogames before. About two dozen people registered, signed the license agreement, and were given the tools.
- Of these people, only about a quarter actually produced anything like a working level. But those that did get to grips with the tools immediately started producing interesting material.
- Just three or four of the members of the Open Pool contributed 60% of the material in the final game (I made 40% of the levels myself), but the quality of the best levels submitted were far better than anything I could have made.
- We gave letters to the biggest contributors promising them a share of revenue proportional to their contribution to the project.
This basic method is a brilliantly simple (and cheap!) way of developing game materials, and one that I believe has further potential. Patrick Dugan (who was one of the most productive members of the pool) dubbed it “the Bateman Method”, which as a Brit I find slightly embarrassing, but it underlines the confidence we have that this approach could be used successfully.
I want to take this opportunity to thank Maurizio Pozzobon, Patrick Dugan, Ian Tyrrell, Marc Majcher, Wil Evans and Toby Everett once again for their contributions to the project – you were the best part of the development process, by far, and I loved seeing your ideas come out in the game! I also want to thank ihobo troubleshooter Neil Bundy for getting involved in the level design late in the game, and also my wife, Adria, for making a simple level!
5. Recognised as Art!
And finally, it is a cause for minor celebration that Play with Fire was featured at IndieCade in Sheffield. We may have lost money making the project, but it’s nice that what we made has been recognised as being artistically interesting.
Although there were many problems that dragged this project down to the point of commercial obscurity, I don’t regret pursuing it for a second. This was the first time I have controlled every aspect of game development, from production and design through to marketing and legal, on a single project – and the first time I’ve used my own money to fund a project. I learned a lot from having this opportunity, and more than that, I am actually really pleased with Play with Fire despite its problems.
There is a great game, buried under the hardware problems and the confusing initial experience, one that I hope will be fondly remembered by the small audience the game has received. If you have a machine that has the necessary spec, and you haven’t tried Play with Fire, why not give it a go? The demo is available from the Manifesto Games site, and is free. (It’s $20 to unlock the full game). You really need to see the game running to appreciate it – screenshots don’t capture the carnage of watching the flames spread! (Just remember to try the Fun Path first - it's on the left when you start!)
I’m glad to say that we set out to make a game about burning things to the ground, and with the help of the Open Pool, the good people at Manifesto Games and a bit of luck, we succeeded.
My infinite thanks to everyone who helped on the project!