Gamethink

The story

Dino Island, PC, 2002

Dino Island was the last game I worked on while at Monte Cristo. Back then (2001), I was working as a producer, and due to a strategy shift, we were to develop 4 games in parallel, but there were only 3 project managers. That’s how I got to set up my team and work on the game.

Why 4 games? Well, MC’s CEO believed, then, that the "home strategy" segment was the fastest-growing sector of the game industry. By home strategy, he meant strategy games which were not pure war games. In other terms, games where people had to build stuff, earn money, etc. The fact is, the Sims, who was in full swing by then, explained by itself much of the growth of the sector. Anyway. Our boss further segmented the "home strategy" market, between games which had a building component or not, and games which featured fighting or not. I had the building but no fighting slot, and our team consisted of one coder, one graphist and one animator. Our first assignment was to propose 3 game ideas.

By then, the coder, who was mostly interested in AI aspects, had studied extensively park-like games (Roller Coaster Tycoon, Theme Park) and the behaviour of the "agents" (visitors, staff) which, he thought, could be greatly enhanced, and had written a very interesting paper on the subject. The graphist, who was to become our lead artist, was basically frustrated with 2D and sprites, and wanted to express his very strong cartoon style in the world of real-time 3D. The animator wasn’t very interested in the concept aspect of games, but was definitely the most talented individual in the company, if not in the industry.

Roller-Coaster Tycoon was always present in our discussions with management, because it was the typical example of a golden "garage" game. It was supposed to be the proof that strong design does sell, no matter the budget.

So logically, we started thinking about how we could take the park-game concept further, and soon enough, we were writing the specs of a zoo management game, which seemed to be the obvious candidate for what we were doing. We presented our work to our boss who welcomed the idea with enthusiasm. Conceptually, it was a safe choice, and we were well-positioned to deliver a good game. By the time we left his office, Microsoft officially announced the development of Zoo Tycoon. That meant: back to the drawing board.

Welcome to the park

We started thinking in different directions, but, with Jurassic Park just around the corner, we thought we could make a great dino park game, instead. Surely, we thought, that was a game idea still unexplored! (wrong) Eventually, our boss was happy with the idea and we started working. A couple of weeks after, he told us he went to an open-air zoo that week-end and that their biggest issue was that animals could get bored, which could have both health and psychological adverse effects. To address that, staff would organize events to keep animals (and visitors) entertained, such as throwing meat from a high bridge for the lions, putting up little shows with the ape, etc. So, we had to include something like that in our game.

As we began our pre-production, the issues I was facing were:
 team far from complete (we were still 4 at this stage);
 extremely low budget ($700000), which I couldn’t even use as I saw fit, as decisions would be regularly overridden by the head of studio, and aggressive deadlines;
 lack of a common vision of the game;
 many technical challenges ahead.

Fortunately, we hired our lead coder very soon and we could get the person we wanted. We then hired an extra artist. The final hire (3rd coder) didn’t quite go as planned, as our management didn’t agree with our choices and we could only complete our team well into production.

There was little I could do about the budget. Most of it was spent on our salaries anyway. I don’t believe in voices for that type of game, especially considering the localisation cost penalty they include. Speaking of localisation, the game was built from day one to be as localisation-friendly as possible - the text was easily accessible, semantically correct, and reasonably concise. We also planned to use our own graphists to do the FMVs after their production job would be finished. All in all, we reduced to the max what we had to purchase. Unfortunately, we were never allowed to spend the extra on another developer, who would have been more than welcome, as the code department would endure most of the pressure throughout the project.

When we started fleshing out the game design, we (fortunately) soon realized that each of us was talking about a very different game. So the first efforts, meetings and formal documents were aimed at unifying the vision for the game. In this phase, having the lead artist helped tremendously, as a good sketch can make abstract concepts much clearer.

Our subsequent brainstorming meetings gave birth to a first list of features, written in a non-technical language. When the lead programmer joined us, we translated that document in a long, detailed list of programming tasks. For each individual task, we knew:
 its estimated length;
 its pre-requisite and dependents;
 the feature it was supposed to implement, and the milestone it belong too;
 the resource that was assigned to it;

and, when we started using it on a daily basis,
 the percentage of completion of each task and the amount of time spent on it.

It was the core functions of a project management software in a spreadsheet, which would allow us to answer quickly questions such as:
 is it worth it to develop this or that non-essential feature, is this means missing our deadline? on the contrary, shouldn’t we spend more time on this important feature, because the results would be visible?
 what will be the workload of the various coders in the next few weeks? Is there a way to smooth it out?
 does it make sense to keep this or that task within this or that milestone, when we could execute it much sooner (or later)?
 What percentage of the next milestone is completed? How much do we have to do to finish the game?

All in all, it was a very efficient tool. While we had a similar list for the graphists, it was much less useful, because graphical assets tended to follow a well-established workflow: design, mesh, texture, animation.

On the technical challenges department, it’s commonplace to think that every game includes something new that no one in the team (and oftentimes, no one in the industry) has ever developed. We had more than our share.

Eventually, all roads became straight...

... and cut at right angles.

The lead artist wanted to break completely free from grid-based design. He wanted players to have complete freedom: roads could curve, enclosures could come in all shape and sizes, players should be able to place the camera anywhere they saw fit. Moving from a discreet (tile-based) to a continuous world was extremely expensive. Fortunately, we took that decision at the very beginning, and made concessions as we went along (roads are straight and cut at right angles, enclosures are rectangles), and not the other way around (start from a safe assumption and make wild bets as we go).

The breeding screen

The biggest challenge was the dinosaurs. We wanted the player to, well, play with them to the fullest, which meant breeding them and letting them interact with each other. Now how can a 8-ton Giganotosaurus and 50-kilo Troodon interact with each other in a convincing way? And what would their children look like? How can we model and animate a "generic" dinosaur?

Impossible Creatures, PC, 2003

Polar bear + Lobster = Lobstar bear

At this point, we were aware that Relic, with Sigma (which is now known as Impossible Creature), was trying to do something similar, once again with animals instead of dinosaurs, although we didn’t know the details. It turns out that once more, our solution was more ambitious (read: perilous) than theirs: in Sigma, it was possible to combine "pure" parts of different animals (the head of a crocodile and the body of a bull), while in Dino Island, each member was a mix between that of the parents.

The solution we used was as follows. Each dinosaur belong to one of 6 families: great carnivorous (T-Rex, Giganotosaurus, etc.) was one, heavily armored (Triceratops) another, etc. Each family had one consistent set of approximately 100 animations. With 600 animations, we were able to provide consistent, believable animations for all of our creatures. That was quite a relief. Then, each "member" (arms, legs, body, head, tail) was a mix of that of the parents, according to some complex criteria (there were "dominant" and "recessive" genes... well). The mix affected the shape, the size, the skin and the potential ornaments of the children’s member. Mixing shape and sizes is easy, this is what 3D is for. We came up with rules for mixing different skin types (what happens to the child of a dinosaur with very thick plates and one with soft skin?). Moreover, each member had a certain number of slots, which could "grow" things like horns, spikes, feathers, etc. once more according to complex genetic rules. On top of that, mutations could affect the final result. All in all, there were billions and billions of results. While from a strict educational point of view, species such as this Mummysorus below cannot be found in a museum, the breeding process was as biologically accurate as possible.

The final challenge was to design the games for dinosaurs.

This is a race arena.

The concept was original, probably too much. Eventually, we came up with a set of tiles that the player could set up in arenas to create their own game. This was certainly more complex that what many players could ask for. Technically, the challenge was to model the behavior of dinosaurs, while letting the player control them to some extent. Some dinosaurs were more aggressive than others, some were smarter. All of that could be affected by breeding them, just like physical characteristics such as strength, speed, etc. In games, dinosaurs interacted with each other. It was difficult to model complex interactions, especially between creatures of varying sizes. That’s why we cheated a lot and used many particle-based effects. All in all, this was technically correct. But while we were working on that, we were wondering whether it would be fun to play or not? The players of such games sure like to go into much detail to make sure that their operation is profitable - see Roller Coaster Tycoon’s roller coaster building options! We already introduced complexity with the dinosaur breeding module, and now even more complexity with the dinosaur games. Somehow, those two "heavy" modules completed each other: breeding dinosaurs made them perform better in games. But would players enjoy this in the end?

Meanwhile, our project was advancing steadily. We were finding solutions to most of our technical problems, and were rationally ignoring the others by discarding expensive but uninteresting features, in order to focus on what we wanted to put forward in the game. We had a complete team and the work in pre-production paid off, as our formal documents were really useful and helped to put us on tracks. There was plenty of work, but we were delivering milestone after milestone and we were rather looking good, we were becoming the darling project of the company. I was trying to get some extra resources to add some polish to the game, but to no avail...

Then, disaster stroke. A contractor, that I had personally recommended to do a job for Monte Cristo, had not been paid and was getting angry about that, putting me in a very difficult position. Because his complaints were legitimate, I wrote to my management asking them to solve the situation and that under such circumstances, I could no longer recommend anyone to work for the company. At the end of the day, I got a very short email from the CEO saying that I will have to face the consequences of what I said. What did I do wrong? The message, as my supervisor told me the next day, was very clear. As a manager, I was expected to be fully supportive of any decision made by the company. Therefore, I should formally apologize, or resign. I thought about this over lunch. There was no way I could back up and agree with such blatantly unfair practices. And if I did, chances are that the pressure on our team will increase drastically and that our status of star project will be a thing of the past; we’d never have extra resources. But I will still have a job in the very uncertain French videogame industry. On the other hand, if I did resign, I would have enough time to finish the production phase and maybe find another job (I had to observe a 3-month leave). Plus, that would be an excuse to allocate more resources to the project. But who knew what tomorrow would be made of?

When I handled my resignation letter to the CFO that day, he told me I had one hour to pack my things and go. What a shock! Ironically, while they did pay the contractor during the following week, they didn’t pay me! That was the beginning of a 4-year legal battle that I eventually "won" (quotes added, because the only clear winners were our lawyers and Monte Cristo could have used the enormous cost of the lawsuit to develop games). Still, I’m quite bitter about the incident, and remember that day as the worst in my career in games.

For the record, my team did get extra resources: a level designer (whom I knew from high-school, incidentally) and an intern coder. The lead coder stepped up to my position, and the game shipped on time. The press reviews were mixed: some were very enthusiastic, while others were extremely harsh. Still, the gamers’ feedback was very positive. From what I can tell, this had been a great learning experience for the team.

Lessons learned - 1: was Dino Island a good game?

It’s hard to tell from the press, where opinions are split. Even as we worked at it, we weren’t too sure about the outcome. To be honest, both of this is usually not a good omen.

I’d like to say that Dino Island was probably the best we could have done with the budget and time on hand. To some extent, this is true: we have used our resources to the fullest, no asset has been created in vain, nor line of code was unused, and the whole team has been very busy right until the release of the game.

So we went full-speed ahead, even if we had a very small ship. But did we only go in the right direction?

A (somewhat distorted) view from above

3D versus 2D. 3D allowed us to do things we can’t do with 2D, and makes animation much easier. Yes. But we were heavily constrained by Monte Cristo’s 3D engine, which was designed for 16Mb video cards - that is, 4 or 5 generations less than the GeForce 3, which then ruled the market. While this means 3D for the masses, players with high-end systems - and that includes the press - were disappointed to see the capacity of their computers so much under-used. On top of that, it was the first generation of Monte Cristo’s 3D games, which means that we didn’t have the expertise to make it look good. So that’s true that the models were well done so that polygon count remained efficient. But they looked very blocky if zoomed. Besides, we allowed too much camera freedom: the proof is, the camera view angle is weird on most of the screenshots.

In conclusion, sticking to 2D would have been the rational choice. This decision was not possible, for political reasons (my bosses wanted to showcase our internal engine, the graphists wanted to go 3D) and for resources reasons as well (we didn’t have the talent to make a beautiful 2D game).

Some peaceful dinosaurs in their enclosure

Some reviewers hated the graphics of the game. Some players found them excellent. They were just what they were: basic 3D made by 3 people over 8 months with a very low polygon budget and a very basic engine.

The game focus. Initially, the game was a plain park management game with dinosaurs. Breeding them was definitely in our plans. Then that idea of events came, which was heavily suggested by Monte Cristo’s CEO. Breeding dinosaurs and planning events were very complex and, in a way, justified each other: dinosaurs would be mixed so that they could be better at events. That meant that the focus shifted from the management game that players could expect to a much more obscure game of breeding dinosaurs (which basically happened on one screen) and designing those events (which could only appeal to the more detailed-obsessed gamers).

I discovered that, in the final version of the game, the park management aspect was even lighter than I expected: there were now very few buildings left, the staff management aspect was also reduced to a minimum... This will come to a disappointment to all players who legitimately would expect a park management game, especially in comparison with the wealth of options offered by Theme Park, Roller Coaster Tycoon, Zoo Tycoon, etc.

Originality rewarded? It’s fair to say that in videogames in general, despite a tenacious myth, originality doesn’t pay. We try hard to develop something unique, but at the expense of other more conventional parts of the game. In the end, players who expect to see such standard components work well in our game are disappointed. Some reviewers said that the game was just not creative on the development side, some others felt there was more to do in Zoo Tycoon: Dino Digs because it had features that lacked in Dino Island, such as putting foliage or terrain in exhibits.

A small dinosaur in a big cage

Our management wanted us to focus on unique selling points, which we certainly did. In the end, Dino Island has the most complex creature-merging system ever and animations work great. This is certainly unique, but is that useful? It doesn’t help create the game that players expect.

Lack of balance. As we were not used to managing complex games like this, especially with such limited resources and time, we candidly believe that making the game was just a technical challenge, and little else. My supervisor’s mantra was, "we don’t develop games, but tools to build a game." Yes, but, who builds? The quality assurance process was extremely simplified, as our tester’s (yes, singular) mission was limited to hunting bugs. Gameplay was never validated (were we too afraid?). The result is a game that lacks balance. Levels can be too hard or too easy. The economics of the game are completely flawed: it’s very easy to earn money, the game doesn’t reward good strategy, nor does it penalize inefficient parks. This is ironic: we started out with plans for a better park game, built on smarter behaviors of the agents of such system, but in the end, the system fails to impress.

Conclusion: on one hand, it was not possible to make a better game with the budget and the timetable on hand, given the company’s preferences. Without their feedback, would it have worked? possibly better, by removing the dino games component, improving the park management aspect and simplifying the dinosaur breeding section. I also have to conclude that a beautiful 2D game would have been more efficient than our very crude 3D.

Lessons learned 2 - on game production in general

My mission was to make a game according to specs, within time and budget constraints. Mission accomplished. So what?

Out of the other 3 games, one just never happened, one got cancelled (despite a promising concept and many good ideas) and the last one didn’t do well. So, trying to make it big with 4 small games was not going to work.

Still, I was convinced from the start that a game in the vein of Dino Island had a chance - after all, some of its competitors have had the rare privilege of becoming million-sellers. As I begged my management for more resources, I was rebuked with that explanation: the project manager’s mission is not to make the best game ever, but to make the best possible game with the resources at hand.

I can understand the logic: everyone hates a project manager who fails to deliver what’s agreed because they try to do something more on their own initiative, and who blames this failure on lack of resources. Indeed, arguing that a game could not work without editorial adjustments or without extra resources is rather the producer’s job, while the project manager and the development team should concentrate on executing the plan as well as they can.

But, in internal studios (i.e. the company acts as its own publisher), even more so in smaller companies, no one acts as a producer. That definitely leads to a certain blindness.

What’s the point of making the best possible game under strict budget constraints? Do gamers care? Once in the store, will they pity the smaller development shops and chose their games? Do they think, "I’m sure they would have implemented great features if they had just a few extra weeks."? Not a chance.

In today’s very competitive game industry, working on a game that will not meet people’s basic expectation is wasting that development money in vain. You don’t save money by developing a cheaper game that cannot stand up to its competitors.

That’s even more preoccupying given that adding features which would have made Dino Island viable in the market would have been relatively cheap, once the fundamentals of the games had been implemented. Adding content, for instance, in the form of extra buildings or decoration options, extra models, extra levels, wouldn’t require any code modification, fine-tuning the economic model was also rather easy, albeit time consuming.

Lessons learned 3 - the pros and cons of old-school production

The project deadlines were simple: the game was to be finished in 8 months. Out of that, 1 month was dedicated to pre-production, 6 months to production, and 1 month for post-production.

In 2001, many development houses were still sceptical about the importance of pre-production and thought that the game really "happened" during production. This opinion may not be optional with drastically short deadlines. Fortunately, the role of pre-production is now better understood and most studios will devote much more time defining the game than they used to.

Pre-production has three goals.
 preparing the project ahead. This is what traditional pre-productions are limited to. This is done best through a set of formal documents. Some studios boast that they don’t need them, but that’s just not defendable anymore. such documents include, but are not limited to:

• a high-level planning, highlighting milestones,
• a list of coding tasks,
• a list of art assets,
• a budget document,
• a list of risks and contingency plans,
• naming conventions (variable and file names, directories to use, etc.)
• sketches of the assets to model,
• description of the interface,
• and, last but not least, a game design document which comes in two flavours: detailed ("bible"), for developers, and concise, for communication about the game.

On this, we did good, and we did it in one month. The problem is - that’s all we did, while there were two other critical goals of pre-production:
 creating throw-away prototypes. Instead of assuming that every line of code should remain in the final program, pre-production is the right time to face the technical issues and try to mimic the final game with prototypes. A successful prototype gives everyone a better idea of the game. One should not build prototypes to reuse them in the final code, rather, they can be written the quick and dirty way. Once a final, agreed prototype is developed, production is much easier, faster and more predictable. Unfortunately, writing prototypes takes time. While this time is generally a sound investment, doing so in an 8-month project is barely possible.
 validating the concept. It’s often difficult to do on paper, hence the use of prototypes. Still, you can use my framework: consistency, fiction, depth, fairness, tension. You can see I hadn’t developed it back then because if Dino Island gameplay was consistent with itself, while there was definitely a public interest for dinosaurs, and while Jurassic Park made the idea of managing a dinosaur zoo acceptable, the style of Dino Island wasn’t consistent with that message. Speaking of depth, while targeted at casual gamers, it required them go master the nuts and bolts of the game. It could have been fair if the economic model was better, but it wasn’t, and as for tension, we never knew if we were on the right track (usually not a good sign). If we had had this framework, we would have adopted a more classical art style and oriented the game towards park management fundamentals.

Lessons learned 4 - about Zoo Tycoon vs Dino Island:

So we had the same idea than Microsoft? that told us a lesson. Some people think that good game ideas are the exclusive property of the genius who had them first. It’s not true: good ideas hang around in the air for everyone to see, because they are logical answers to a known situation.

A few years down the road, we know that Zoo Tycoon did extremely well and sold over 2 million copies. Could we have done that if they didn’t publish their game? Not a chance. Why?
 Zoo Tycoon had a sober, clean graphical style, while Dino Island had a very pronounced cartoon style, much less consensual.

Zoo Tycoon, PC, 2001

A true management game

How come that a style that has more character is not as efficient as the choices of Zoo Tycoon? More generally, cartoon-influenced games have never worked well after the eighties. Zoo Tycoon’s interface, while closer to that of a non-game software, was much more legible, while Dino Island’s was a bit too busy. While we made it, we thought it was better than those traditional management interfaces. For once, it was prettier. This was a big appreciation mistake. Our stylish icons required more interpretation time. Because so many things were not square in our interface, the result didn’t look as polished as if we had used a more conventional approach.

Zoo Tycoon, PC, 2001

Poor deer...

Dino Island was designed to look like a fun game. Everything was caricatural: shops, visitors, dinosaur models, their moods, trees, etc. But in fact, like every management games, it could be quite tedious. Zoo Tycoon, much like Roller Coaster Tycoon, Sim City, the Sims, and similar highly-successful games, have a much more standard design, with more neutral interfaces, characters, etc. However, they all can be hysterical! Some situations in these games, either created by the player or random events, can be really fun. And they are even more fun because they happen in a neutral universe: the game doesn’t seem to bully the players into laughing.

 Zoo Tycoon had a much simpler concept, but much more content.

Zoo Tycoon, PC, 2001

Make your animals happy - lots of objects to buy...

It was much easier to grasp than Dino Island, and perceived as a much richer game, as it featured lots of animals. Dino Island had several focus points, none of which was really clear to a potential user: the park building/management aspect was one, but rather light; then, one could breed dinosaurs to create unique species; and, finally, one could design games and events for the dinosaurs. Dino Island gameplay sure was consistent. You bet I followed that closely. But the game didn’t do what people who could enjoy that type of game would expect, contrary to Zoo Tycoon. In that sense, the fiction aspect of the game was deficient. But the worst component was multi-level gaming: we forced the players to play a much deeper game that what they expected. Not everyone would enjoy going in as much detail as understanding the dinosaur mutation mechanisms.
 Technically, Zoo Tycoon was not ambitious. It didn’t use 3D or anything fancy, but what it did, it did well. The zoo and animals looked crisp and detailed, in their 2D glory. The isometric view was clear and usable.

Dino Island, in comparison, was much more arrogant. It used our in-house 3D engine (a requirement), which was designed to run on every PC (which meant, by then, a 10,000 polygons per scene limit). Despite the good will of our graphists, those lo-polys were very visible. OK, one could turn and zoom and pan. So what? This only meant we had less control on the viewpoints, and 95% of the time, the resulting image was seriously distorted.

As an aside, all of the efforts we’ve done to create a more "advanced" game, such as the use of 3D or the dinosaur breeding module, have been very much appreciated by some reviewers. At the same time, this was close to useless to our players. OK. Once you’ve started to understand its complexity, breeding dinosaurs can be fun. But was it really what a Roller Coaster Tycoon fan want? This is a great example of the distortion that may exist between the press and the players’ viewpoints.