Developer's postmortem: Enter The Story
First posted on 01 April 2011. Last updated on 15 August 2011.
|
| I am an indie game designer and the creator of Enter The Story. |
|
| Managing the many digital assets in Enter The Story often makes for a programming challenge. |
Enter The Story
Enter The Story is a series of adventure games created by Chris Tolworthy based on classic literature. First released in January 2009, the series has since expanded to include 5 games (or stories): Les Misérables, The Divine Comedy, Genesis of The Gods, A Tales of Two Cities, and The Count of Monte Cristo. In addition, Tolworthy is seeking to raise funds through the sales of his games for his research to end global poverty.
Enter The Story is a 14-year project to convert 100 classic novels into a single vast gaming world. This project is not really about novels; it is really about ideas—the novels are merely the foundation. So far, I have managed to convert 5 novels into 5 games, but I still feel like I have not even begun this project.
10 rules for making insanely ambitious games
Do you have hopes and dreams? Do you have a vision of some project you like to complete that is completely new and insanely ambitious? If so, maybe my experience can help you. I have come up with 10 rules that will save you years of work and possibly your sanity as well.
Looking back at the years since I first planned this project, I fathomed I could have saved nearly a decade in time so if I had known then what I since learned.
Rule 1: decide how far you want to go
You want to make a game, but you have yet to decide how far you want to go. Do you just want to make a game that other gamers may buy to earn some money? Or do you want to make a game that can change the world?
If you want to just earn some money, then you make the same kind of games that other developers make but make your game a tiny bit better. If, however, you want to change the world, then you need to learn from my mistakes (I have made plenty!) before venturing on your own to make your game.
I began Enter The Story in 1997 as a personal project. I was tired of waiting for the kind of games that I wanted to play, so I decided to make a game myself. I had many ideas. I spent the next 3 years planning a game that was, both figuratively and literally, bigger than the physical universe. It was essentially a big database that operated with an equally big set of rules. All graphics in this game world were constructed from those rules. For example, a door would be drawn as a rectangle with a circle for a handle, just like in the classic 8-bit adventure games. If you clicked on the door, then the game would decide what was behind that door and save it to the database in case you ever chose to return. You could open any door, fly out of any window, and go up into space and beyond. You could also zoom into the door and see the wood grain in close-up. You could zoom in even further to see the plant cells and then the molecules, the atoms, the subatomic particles, ad infinitum. Each of those particles would be a separate universe. I had sections of the game devoted to constructing galaxies from the stars, star systems from the planets, and planets from the continents, and so on. Every element was just a shape with some properties, in that if you looked close enough you would see that it contained smaller shapes. The clever moment stuck me when I realized that the game could be constructed in the same way that it created universes and life forms and behaviors.
There were a couple of problems: I did not know how to program, and I did not have any money. I was unemployed at the time, so I took a government sponsored distance learning course in Pascal first and C++ eventually. I secured a copy of Borland C++ Builder from a magazine cover disk. Almost 3 years later, I had a skeleton of my game. Those were exciting times! Alas, I then realized that it would take me decades to complete it. By that time, I might be dead (I was in my mid 30's)! I decided that I had to scale back my plan. I found an existing game engine that was license free and began adapting my plan to a more modest scale. If I had done this earlier, I could have saved nearly 4 years.
Rule 2: multiply all time forecasts by a factor of 8
The challenge about making huge and new games is that they are, for a lack of better descriptions, huge and new. If a project is huge, then it will always take twice as long as you think even if you have already allowed for its hugeness. There is an old proverb saying to the effect that the first 90% of the task takes 10% of the time, and the last 10% takes the other 90%. This is not an exaggeration. It is always wise to double your time estimate. If your idea is new, then you need to double it again. This is because there are more ways for new ideas to go wrong than you can possibly imagine.
The mere fact that you dare to try out crazy new ideas implies that you are an oddball of a game developer. You probably do not have any prior training in programming, and you are likely working now in a low paying day job. You also do not have access to the kind of costly development software that the established game studios can afford. To this end, do not dare to think about pirating software! Developers pirate if they do not expect their games to ever sell. If you expect your games to sell big someday, then you just avail yourself to a lawsuit eventually when you pirate.
I have found that doubling, then doubling, and doubling again (that is, multiplying by a factor of 8) the time for all forecasts is about right. This is true at least for the first few years of the development cycle.
For example, Les Misérables, my first story, contained about 10 months of finished work but actually represented about 6 years of actual work. The first build of the game included literally thousands of scenes and hundreds of prebuilt worlds. Early testing, however, found that many players hated the game's art style. I listened to them and changed it all, even though this meant dropping nearly 90% of the content which I had already created. This was a long-term project, so losing a couple of years early was not a major problem if it would save time later. Yet, when the new build of the game was almost complete, I discovered a serious memory leak in the game engine which I then used. In the end, the only solution for me was to change the engine. The new engine worked differently so that I had to drop a lot of the codes and halved the number of scenes (from about 160 to 80 scenes) in that story. Later, I also had to drop the "walking between games" code which wasted about a year further—the game engine might handle it in theory but could not in practice.
Rule 3: ignore most advice
I changed the game's art style because of negative feedback from early testers. In hindsight, this was a bad move. The benefit in nicer art needed to be balanced against the cost in time. If I had stuck with the ugly art, the game would have been completed 2 years earlier.
This, of course, only applies to new ideas for a game. Constantly restarting the development process can quickly drain your enthusiasm of the project.
Rule 4: decide what market you are in
It is marketing 101 to know what business you are in. For me, Enter The Story is in the business of stories, not games. I often get fan requests to put in more video game references or to make the puzzles more varied. However, I believe these additions just get in the way of the story. Rather, I need puzzles that are as easy as turning a page, with references to William Shakespeare and John Milton rather than Ron Gilbert and Roberta Williams. Of course, it is ideal to include both, but often you have to make a choice.
In the past, I had spent a lot of time trying to please fans who were happy with existing games. That time was generally wasted and should have been spent instead on making the kind of games I wanted.
Rule 5: do not advertise
What madness is this? How are gamers supposed to learn about your game? No sane developer will ever say that!
Wait, hear me out! This applies only to new kinds of games early in their development. I speak from experience. Also, I am not against talking about a game online. Some gamers will be intrigued by early exposure to the game and will love it, quirks and all. You then use their feedback to improve later releases. However, spending extra time looking for sales at this early stage can be a mistake.
Gamers who visit gaming web sites do so because they like what they see. If they do not like what they see, they will soon stop visiting. In other words, they all have certain expectations and can be easily disappointed if they find your game to be too different. Further, if your game is truly meant to bring in a new kind of experience, early builds are likely to be spoiled by all kinds of mistakes. Existing game styles have been polished for years, so gamers who have adapted to them are less tolerant of rough edges. Worst of all, if some fans see an early build of your game and come away to think of you as yet another developer who makes bad games, they will not likely pay any further attention to the game even when it improves later on. Your game has lost the novelty effect.
Good testers are hard to find. Thorough and serious testing of a game is hard work. There will come a time when you have no testers left who is willing to test your game again (without pay at least). At this point, if you cannot find any bug on your own, you are left with no choice but to release the game. However, with any game release, it is guaranteed that some players will find a new bug. If you have not advertised your game early on, you can fix that bug quickly for the few gamers who have purchased it, apologize to them profusely, or even offer a refund to them if they have already paid. No lasting harm is done. On the other hand, if you have already advertised your game heavily to ramp up sales at launch, you now face a massive product recall that can leave your reputation in tatters. Taking it slow and steady is the best way to grow a market.
Rule 6: be in for the long haul
Making a new kind of game work well takes years. The more novel the idea, the more ways the game can go wrong, and the more cautious you have to be.
For Enter The Story, there were at least 4 development problems had added a year or more to the schedule: scaling back the plan, fixing the memory leak, implementing the new art, and dropping the "walking between games" code. Other development issues also put the project back in other ways. For example, as Les Misérables sold reasonably well, I felt emboldened to make The Divine Comedy, my second story, even more daring and different. I chose a completely different type of story—not a melodrama but a medieval poem. I thought that gamers would appreciate a completely faithful adaptation of this classic that would nevertheless focus on ideas and explore different possibilities. For a game, it was very off the wall—basically a pair of characters walking in a straight line and talking philosophy. Players hated it. By the time I received feedback for it, however, I was already half way through the development of Genesis of the Gods, my third story, which was even weirder and more quirky! A Tale of Two Cities, my fourth story, was more conventional, but it lost a year of momentum because of this detour.
Incidentally, Les Misérables and A Tale of Two Cities were promoted mostly by word of mouth, and both of them sold well. By contrast, The Divine Comedy and Genesis of the Gods were promoted heavily via regular channels (such as sending out demo disks to print media), and the extra effort was largely wasted. The game needs to be right before it is advertised.
Rule 7: have a sound business concept
Even if your game is released as freeware, it still costs you money to develop: the time you have spent on developing the game can be spent elsewhere earning you money flipping burgers or stacking shelves. A game can take many years to get right.
I know of many developers who put in years of effort but never hit the big time. Their games are good, but they do not stand out. When you start making your own game, you need to have a good idea of why your game will be different compared to your competitors. What makes your game so different that it can succeed even if you make a lot of mistakes during its development? The unique selling point? The heroin content? The copper bottom guarantee?
With Enter The Story, it is classic books. Classic books will always have a market. The idea of transforming the complete works of Shakespeare to games will always be marketable.
From a business perspective, the unique strength of this project is the ability to reuse content during development. Each new story reuses more and more code, characters, music, and other assets from previous stories. Eventually, I will be able to release a full length game with only months, rather than years, of development time.
Rule 8: measure progress, not profit
Mainstream media will take notice of your game, sooner or later: all you need to do is get it right. I almost never look at sales figures for my games. If the figures are good, then I become complacent and spend less time on them. If the figures are bad, I become discouraged and spend less time on them. I may then decide to spend more time on advertising, which adds little value to but takes more time away from the games. Instead, a much better strategy to gauge success, at least in the early days, is to measure efficiency.
Enter The Story is designed to have a rapid game development cycle. My goal is to add a new story every couple of months and to be able to change almost any content in a game within a couple of days. When this happens, I can quickly respond to feedback, ensuring that the game improves constantly and rapidly. Sales will look after themselves from there onward.
A decade ago, major problems added literally years to my development schedule. Nowadays, major problems would unlikely add more than a few months. A decade ago, adding a new character took over a month because of the complexity of the sprites. Nowadays, adding a new character it would take much less than a week. A decade ago, coding a scene took a day or more due to the bug prone codes. Nowadays, coding a scene would take much less than a day.
I still have a way to go before I can add a new story in such a short timeframe (which will be, by itself, a powerful advertisement). From my perspective, however, I can see the plan coming together. It is indeed exciting!
Today, I can finally concentrate on the story instead of the code. I call this real progress.
Rule 9: catch the vision
Enter The Story will at least a 30-year project. I still have years of work before it hits the sweet spot.
How do I keep myself motivated? Easy! I do not look at what the stories are now; I look at what the stories will be in the future. Making a major game project like mine is akin to climbing a high mountain: you sometimes focus on the eventual mountain peak, and you sometimes concentrate on the next few steps, but you never look back.
I have a vision. There will be a digital bookshelf packed full of books to explore, with so many stories that the shelves will have to scroll up and down and where all of mankind's most amazing ideas and knowledge are found. There will be a new story appearing every couple of months, and the quality of the stories will constantly improve, with characters who are beloved by the reader. Any profit from the books will go toward researching solutions to global poverty. When the project is finally complete, most of it will become open source, so that new stories can be freely added, and the collection will grow and expanded forever. Contemporary authors will license their works to be included in the collection, including books and comics. By that time, my games will be widely available and widely played.
This vision is what motivates me. You may have your own vision of your perfect game. You just need to visualize it, whatever it may be.
Rule 10: enjoy the work
If you enjoy your work, then others will likely enjoy it too.
Me? I love it.