Only a Game

Eden Concept Document (ihobo)

Several years back, I was working on a budget PS2 title called Eden. The project has been officially discontinued, but you can read the original concept document here on the ihobo site.

Outlands (Tabletop RPG)

I'm pleased to announce that after a decade of being out of print, my second tabletop RPG, Outlands (last published in 1995), is now available once again on the Discordia Incorporated website. You can find the PDF version of Outlands here. None of the illustrations are included, alas, but all of the text and tables are reproduced faithfully.

The purpose of Outlands was to take a variety of different classic science fiction sources - including Aliens, Angel Station, Blade Runner, Dune, Outland, Wetware and Blake's 7 - and merge them into a melange that would present a coherent science fiction setting, in the way that Dungeons & Dragons did with fantasy sources. Oddly, while D&D is usually not criticised for incorporated Orcs, Outlands was criticised at release for including the Fremen (from Dune) as a playable race, which makes me wonder if people are more open to amalgam backgrounds in fantasy than in science fiction.

Outlands is fairly mechanics heavy, and has a detailed character generation system that some players love (and play as a game in itself!) while others find it too complex and long. It's also the only game I know of which offers the possibility to play an animal species that has been artificially raised to sentience (with the possible exception of Paul Kidd's Albedo, but then, you can't play a human in Albedo!)

Some of the mechanics - such as those describing the singularity shots used to pilot from star system to star system - are effectively mini-games embedded within the larger framework. Perhaps the most interesting part of the background is the capacity for an individual to take a copy of their personality engrams via a wetdrive and upload them onto drones, or leave a copy at a Neozen temple so that they can still be spoken to after death. My favourite mechanics are those for generating stellar systems (p108-114), which I created while studying Astrophysics at Manchester University, and might be the most realistic rules of their kind.

My thanks to Peter Crowther for faithfully keeping the backup from which the game was rescued, Chris Keeling for an incredible repair job on the manuscript, and Neil for putting it up on the site.

Play with Fire: Post Mortem

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).

This post examines the many things that went wrong with this project – and also the many things that worked out nicely.
 

Problems

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.

 

Successes

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:

1. 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.
2.  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.
3.  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.
4.  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.

 

Conclusion

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!

Play with Fire at IndieCade

It's a great honour to report that Play with Fire was chosen as part of the IndieCade showcase, who recently put on a display of unusual and innovative independent games at GameCity in Sheffield, UK, along with many other fine works including our friends at Tale of Tales with The Endless Forest, who were picked as an example of the event by the BBC.

I was unable to make the event, but shared in some of the excitement the organisers had in trying to make the software chosen for the event run on the machines that had been rented. In the end, it all worked out for the best.

It's great that there are festivals like this showcasing and celebrating interesting projects from outside the high profile world of corporate -made videogames. Long may they continue.

Aquadelic GT

This is a new boat racing game, made in the style of a kart-racer - simple to learn, but challenging to beat. The game is Aquadelic GT, by the Czech Republic studio Hammerware under the Arcade Moon imprint of our Slovakian friends 3D People and published in Europe by JoWood. My team at International Hobo has been helping them out on the design and script, and the finished game should be on sale shortly.

The game has been quietly coming together in the background, and as if from nowhere we were suddenly delivered a master candidate (the last versions of a game before it goes into production) which we've been frantically playing for the last few days. There are a few rough edges, but I've been having a blast with this game - the most fun I've had with boats in a videogame since Wave Race 64 - and that was fifteen years ago. It's hard to believe this was put together on such a modest budget.

There are a few interesting things to note in the design. Following the latest trend in "embedded menus", we did away with a menu structure for tying together the main play, and instead placed the player directly into the world. So you begin with your little rusty bucket in Russia, and can run people around as a taxi for cash, or get started on your racing career by going to one of the race sites. By making "free ride" the main game mode (racing being accessed from this), we allow new players ample opportunity to practice controlling the boats, and to learn the layout of the areas as well. It's a small thing, but it was worth the extra effort.

The racing gets quite frantic! The weapons are a good mix, and satisfying to use. The physics in the game means that hitting someone with an exploding frog or a shark torpedo can send them rocketing off to nowhere, but the player can always tap "R" to respot themselves if they end up somewhere inconvenient. It starts easy, but gets much harder as the game goes on. Finishing was a challenge, but it must be said that the final boat outclasses everything, so players who struggle can keep saving their money until they can afford the ultimate vessel.

Since the player is free to move around the world between races, there are also other activities beyond racing, including running taxi rides, going on a yacht cruise for coins, and dropping humanitarian aid from a seaplane. I had great fun with these too! Although there is little money to be made from the yacht, the environments are so beautiful that I found it was satisfying just to pilot my way around the islands. Quite relaxing. The player can also buy houses in some of the locations - there is a gorgeous villa in one of the Greek ports which I fell in love with (pictured left, in the right of the background), although my million dollar mansion in the Caribbean is also quite appealing.

The official Aquadelic GT site is here, and my web album for the game is here. It will be available in Europe very shortly, for PC only.

Play with Fire Reviewed in Denmark

Greg Costikyan passed me this link to a review of Play with Fire at a Danish website. I have no idea what it says!

Oh, and I'm honoured to report that we got mentioned on Jay is Games too.

Reluctant Hero: Story Mechanics

It’s been a little over four months since I last looked at the dynamic narrative design of Reluctant Hero, our next computer role-playing game project with 3D People. The last post on Dramatic Role Proxies summarised my position at the time, and the issues I was dealing with. Before proceeding, it is worth going over some of the (tentative) decisions I have made in the interim: 

• The game will be narrated by the player character, provided we have the budget to record both a male and a female voice over.
• All the game dialogue will be delivered as narration, although not all will necessarily be recorded.
• The narration will be written as if it were a journal entry: “I made it across the mountains” or “He told me where I could find the bridge.”
• We will likely use a role proxy system of some kind, but probably less extensive than previously outlined. In particular, the key Enemy (Nemesis) characters may be set and selected from a pool of options – generic foes run the risk of being narratively insipid.

The purpose of this post is to get straight in my head some of the main issues of the story mechanics, in order to lay down this framework of the game. Let us start at the top and work our way down, as top down design tends to be more robust. 

 

Chapters & Paths

Any game of Reluctant Hero is divided into a certain number of Chapters, according to the game length the player has chosen. Each Chapter must necessarily have its storyline – that is, each Chapter begins with the activation of a particular Scenario (or, if you prefer, Quest). This is vital: the player is free to do what they wish, but for players requiring instruction, there must be a general path for them to follow. Therefore, one of the first tasks is to establish the answer to the question: how are Scenarios selected?

(Why Scenario and not Quest? For a start, the term has greater RPG antiquity, but more importantly visiting your sister is a viable Scenario, but it doesn’t sound like much of a Quest!) 

The answer to this key question depends in turn to how the Scenarios can be grouped, and in particular whether or not there is a distinction between what we may call Arc Scenarios (those that form part of a wider story) and Incidental Scenarios (“one off” quests or stories). Let us presuppose this distinction, for we can surely eliminate it later if it becomes troublesome.

Arc scenarios must then be grouped into Paths, of which I can see four options: 

• The Adventurer Path is explicitly chosen when the player chooses to run away from their arranged marriage. It favours seeking lost relics and tomes, and the ultimate goal of finding the artefact that your father could not.
• The Noble Path is explicitly chosen when the player chooses to go along with their arranged marriage. If favours a more domestic life, trying to invest the family fortune in suitable businesses and defend them from the attacks of brigands, monsters, and the pitfalls of misfortune.
• The Family Path can go in parallel with either of these paths, and relates to the story of the protagonist’s Sister.
• The Parent Path can go in parallel with any of the other paths, and relates to the problems that will be encountered should the player try to conceive children.

From these four Paths, all the Arc Scenarios can be selected. (Note that the player can still find the relics and artefacts of the Adventurer Path as a Noble, and can still run businesses as an Adventurer; they are just not asked to do so). 

Additionally, we require Incidental Scenarios to fill the gaps between the Arc Scenarios. Most will doubtless be “Monster of the Week” stories, but there are certainly other possibilities such as journeys and curses.

But how will these many different Scenarios be sequenced? 

 

Acts

The easiest way to solve the sequencing problem is to specify an Act framework. Act I represents the story up to the point that the player either accepts or flees from their arranged marriage. Act II through IV are the main part of their life. Act V is about their death and, if they should cheat death, Act VI is about their life after death (where tragedy surely awaits). 

Act I, I already know, has 3 Chapters in it. The final Acts (V and VI) should be similar in length, although this has yet to be determined. It follows that depending upon the number of Chapters the player has chosen (i.e. the game length) there will be different numbers of Scenarios in each of the other Acts, as follows:

• The shortest possible game is 12 Chapters (3 in Act I, 2 in each middle Act, 3 in the final Act or final two Acts).
• With 3 Chapters per central Act we get 15 Chapters (3:3:3), with 4 we get 18 Chapters, with 5 we get 21, with 6 we get 24 and with 7 we get 27 (3:7:3).
• Finally, the longest game has 8 Chapters in each central Act for a grand total of 30 Chapters.

(It should be noted that the player will select the game length and approximate number of Chapters – some latitude may be inevitable.) 

On this schema then, the shortest game consists of just 2 Chapters per central Act. I have to wonder if 3 central Chapters (one each per central Act) will be enough to develop the main Path stories, or whether we will need all 6 central Chapters (both in each central Act) to get a reasonable story… More narrative design is needed to answer this question.

At the other end of the scale, the longest game will consist of central Acts of (say) 2 Chapters from the main Paths, 1-2 Chapters from the side Paths, and then another 4-5 Incidental Scenarios. That requires at least 5 Incidental Scenarios for each central Act, but on the other hand almost all of these will be quite simple to implement. 

It strikes me from examining this that we can have broadly linear sequences of Arc Scenarios (with some parallel or contingent elements) that occur at the start of each Act, and then again near the end of each Act, if there are two per Act. The Arc Scenarios from the side Paths can be randomly allocated to the central Chapters in each Act, with the remaining Chapters filled with Incidentals.

Incidental Scenarios can be chosen more or less at random, although some contingency as to the nature of the player’s current Location (and the Culture they are living in) along with the Act should be taken into consideration. A minimum of 15 are needed; I suspect we’ll make more like 45-60 or more (although many will be variants of one another). The important thing is that there needs to be enough to allow every game to be sufficiently different. 

(I’d also like to give some Incidental Scenarios “sequels” in later Acts, as I suspect players would enjoy that).

This should all have the desired effect of making each game of Reluctant Hero something akin to a season of a TV show, with a mix of long running and “one-off” stories.

 

Chapter Prologues 

Before looking at the Scenarios themselves, an aside on the prologues is in order. Each Chapter will need to begin with dialogue (strictly speaking, monologue) that sets the scene. The Scenario that is chosen can specify either a Domestic Prologue or a Peril Prologue, which in turn will vary according to game state, the season or the month.

A Domestic Prologue might be something like: “I have not seen my sister for some time now, and I wonder how she is doing,” or “My son has grown so much these past few years”. 

A Peril Prologue might be something like: “Spring has brought fresh tragedy,” or “I guess it was too much to hope that Summer would pass without incident.”

These would then follow with the Scenario introduction. I need to plan this out some more, but this isn’t the place to do it. 

 

Scenarios 

How are the individual Scenarios to be specified?

Firstly, each must specify a Problem, which becomes an entry in the Journal, and also a topic for conversation with other characters. The Problem may be “How do I open the gate to the Reliquary?”, “What can be done about the blight in Corwenth?” or “What is attacking the merchants on the west road?” Without getting too sidetracked, this token can be used to initiate conversations which in turn will guide the player to a solution through perseverance and finding the right people to talk to. 

But below this, we need to specify the atomic elements of the story.

 

Events 

Anything that happens, from a line of dialogue to the setting up of a future battle can be considered an Event. Events can be in three essential states – inactive, active and occurred. Only certain Events are active at any given time, the others are inactive (haven’t yet become active) or occurred (have already taken place).

Events will need to consist of the following elements: 

• A unique ID that identifies this particular Event.
• The Condition that triggers the Event (if any). When an Event is activated, it will sit in a “watched list” until its Condition is fulfilled; then it ‘occurs’.
• The Line of dialogue (if any) that plays when this Event occurs.
• Any Actions that take place when this Event occurs (such as the placing of new monsters, the addition of locations to the map and so forth); probably a LUA script.
  
• The Next Event, that is, the ID of the Event (or Events) to activate (enter the watched list) after this Event has occurred.
• A Deadline (when applicable) that determines when this Event expires (becomes inactive again).
• The Expire Event, that is, the ID of the Event (if any) to activate after this Event expires.

Note that sometimes the Next Event will be ‘Chapter End’, that is, the current Scenario is concluded, and that many different Events may lead to ‘Chapter End’.

Without getting into too much detail, looking at the Conditions will help clarify how Events will function: 

• Unconditional Events just take place automatically
• Destination conditions initiate a Event when the player goes to a certain place.
• Persona conditions initiate an Event when the player goes to the place where a specific Persona can be found, or begins talking to said Persona.
• Item conditions initiate an Event when the player acquires a specific item.
• Practice conditions would initiate an Event when the player uses a specific ability (currently known in the game as ‘Practices’)
• Neutralise conditions initiate an Event when the player befriends, kills or causes to flee certain Monsters or Personas.
• Wait conditions initiate an Event at a specific juncture, such as dawn, dusk, or the start of a particular season.

We are now ready to explore these ideas in practice. 

 

Example Scenario 

Let us take for our example something very simple, namely an infestation of parasitic hexapods near a farmstead (a type of vicious insectoid critter peculiar to the Heretic Kingdoms). Initially, the player will not know what the cause is, they will only find out the nature of the problem, which in this case is that the crops are being eaten by something.

The Problem is “What is eating the rye?” 

The first Events to be activated are as follows:

• An unconditional event creates new hexapods and places them into a Lair (a type of Site in the game world) near the farmstead. This in turn triggers a Neutralise event (see below).
• A Destination event is activated for the campfire in the field at the farmstead. If the player camps at this point, it will trigger an event that waits until the early hours of the morning and moves some hexapods into the field, and updates the Problem to “Where is the hexapod lair? (This simulates the player camping out to try and catch whatever is responsible).
• A Destination event is activated for the Lair which updates the Problem to “Eliminate the hexapods”. In effect, if the player discovers the Lair (which they may do by exploring on the map), they deduce the critters are eating the rye and they become the new focus of the Problem.
• The Neutralise event for the hexapods has as its Next Event ‘Chapter End’. If the player eliminates them by whatever means (including hiring someone to do so), that will suffice for this Chapter. This event has a deadline of one year, with an Expire Event which waits until the next winter and kills them all off in a harsh winter frost. (All Chapters must end eventually).

This is a simple example, and omits the details of how the player could also investigate in dialogue (as this concerns the dialogue engine, not the story mechanics), but it demonstrates how this Event system can be used to build Scenarios. 

 

Conclusion 

The dynamic narrative system proposed here is not especially ground breaking; certainly more ambitious and impressive proposals could be conceived. But it is a realistic proposition to implement such a system, it should be comparatively robust, and it is not much more work to execute than a conventional static quest system. Yet it does allow for some dynamic narrative, and any amount of this that can be placed into a cRPG without excessive development overheads is, I believe, worth considering.

Much of what will make it interesting will be the nature of the Scenarios themselves, but I will need to pin down the mechanics confidently before this work can be done, and I need the okay from 3D People on the basic approach. Oh, and naturally I won’t be sharing the main story details on the blog, of course – you’ll have to play the game to find out the whole story! 

Naturally, I welcome discussion in the comments. Let me know your thoughts and opinions!

Play with Fire in Wired and Elsewhere

I'm not enormously familiar with Wired magazine, but I'm guessing in a glossy publication with 300,000 subscribers and just one page dedicated to videogames that it's a rarity for a game made on the budget the size of a sneeze to be featured. Yet the April 2007 issue of Wired has a review of Play with Fire in it! It's a schizophrenic piece; it praises the "clever concept" yet complains that "the addiction factor is missing." Notably absent is the requisite explanation of why the reviewer felt it was worthy of inclusion in the magazine in the first place - it left me scratching my head. I'm grateful for the publicity, but ultimately perplexed.

Elsewhere, Will Willing's Casual Game Design blog is running an interview with me about Play with Fire which you can find here. There's probably nothing new in it for regular readers of Only a Game, but it's a nice piece about the game for anyone not familiar with its story. My thanks to Will for taking both the time and the interest in the project.

Play with Fire Promotional Double Bill

A few things happened while I was unblogged...

Firstly, Gamasutra published the game design document for Play with Fire, which I hope will prove to be a useful resource for people normally starved of such things. You can find it here. (If it gets us a few extra downloads as well, that couldn't hurt either).

Secondly, the US's only independent computer games magazine, simply called Computer Games Magazine, published a rather nice review of Play with Fire in its Alt.Games column, April edition. It concludes:

Play with Fire is a captivating game that will challenge even the most experienced maze master [while] the Fun mode just lets you burn stuff, appeasing the firestarter in all of us.

My thanks to Troy Goodfellow for providing us with our first review of the game! Sadly, the news is that Computer Games Magazine's publisher has decided to axe it - Greg Costikyan has more on the story.

Play with Fire - On Sale Now!

Ready to burn things to the ground? You can now download the demo of Play with Fire from Manifesto Games here!

You can turn the demo into the full game by buying an unlock code - and please do! If you want to see more original, unusual and inventive games, you need to support the indie developers who are the only people in a position to make these sorts of games (see the Indie Games Bazaar in the sidebar).

Most mainstream developers are now locked into a vortex of spiraling development costs where risk-averse publisher buying strategies dictate making more of the same but with fancier graphics and licensed IP. A few new things manage to survive the system, but they tend to get rarer each year. Let's try something different for a change!

Oh, and just so you know, we made Play with Fire for less than 1% of the budget of a typical game. For every humdrum videogame film tie-in you see, publishers could have funded a hundred games like this.

Also, if you blog, please help pimp Play with Fire for us. You can get screenshots from the Manifesto site. We need your help!

A few minor issues... the Manifesto page doesn't currently show the Fantasy Labs logo - they are the developer of this game, International Hobo are just the design team. Will get this fixed as soon as I can. Also, a couple of versions of Windows XP shipped by Microsoft are inexplicably missing a key dll for directX 9.0c. If this affects you, the missing file (d3dx9_30.dll) can be downloaded from here.

I hope you enjoy the game, and if you do - tell your friends!

Regular blogging will resume on Tuesday - see you then!