Virtual Life in Crags

I was hired at Media Station, Inc. (MSI) in 1997 as Senior Producer/Designer for multiple game titles. At the time, MSI specialized in children’s titles developed for Disney and Hasbro, among others. Although they had just finished a core game title (Extreme Tactics), they wanted to make improvements in the design and process for their second core game.

The company owner had an idea of what he wanted: a 2D RTS similar to Warcraft 2, in which two races fought for control over the huge mountain on which they lived. Crags were typical fantasy-style dwarves, cranky but loveable fellows who mined in the mountain for resources. Garcs (Crags spelled backward) were Crags who had turned evil and gained magical powers. In its orginal design, Crags was a standard RTS game, modeled after Command and Conquer and Warcraft.

Differentiation Is Key

I wanted to get a publisher’s attention with MSI’s next big step into mainstream, core games, and I didn’t like a Warcraft clone would get us there. The market for RTS games was beginning to get crowded. MSI had difficulty selling Extreme Tactics because of the sheer number of RTS games coming on the market at the time. Personally, I’d started to feel confined by single genres, and wanted to create a design that blended several different game types. I considered a cross between RPG and RTS, but decided against it because I really liked the head-to-head gameplay, and I didn’t think the deep backstory needed for a good RPG had a place in Crags. In the end, I chose to combine RTS elements with sim elements, following in the footsteps of Peter Molyneux and Dungeon Keeper.

I was also intrigued by Cyberlife’s game Creatures, and its elements of artificial life. Although actually creating DNA and physiology for the Crags was way beyond the scope of the project (and unnecessarily complicated for the design), I began considering what we could add to the game to invest the Crags and Garcs with life and personality. The core question was: how can I bring these little guys to life without creating a headache for the programmers?

Finally, I decided to move the entire project to a real-time 3D engine. At the time, Populous 3 was the only sim/strategy game in development using a 3D engine. Although we’d have to license an engine to stay ahead of the RTS crowd instead of developing our own, it would also help us get to market more quickly. We did a quick a 3D engine evaluation, and chose NDL’s NetImmerse combined with MultiGen Creator for art asset development.

Warfare on Many Levels

I designed the game to have many different levels of competition between the two players (or the single player versus the computer). To win the game, you must eliminate all of your opponent’s Crags, but how you accomplish this goal is up to you.

On the first, most basic level of competition, you have direct warfare between the two sides when they encounter each other by tunneling through the mountain. On a second level, you wage war through economic competition. Gold and silver are found in pockets in the mountain, and you can concentrate on mining those pockets out. In addition, the village produces resources (including Crag apprentices) at a fixed rate, so you can buy all of the resources and leave your opponent stranded.

Where’s the Game?

Crags run their own lives. They stop working and go to the dining hall when they get hungry, and they head to the dorm when they get sleepy. They decide what buildings they want to build based on what they need at the time. In essence, they are individuals who react to their environment, not to direct orders from you.

crags stages

As the design became more robust and we first got the world up and running, I was frequently asked by people on other development teams, “What does the player get to do?” In the initial design, the player controlled the purchase of resources, but little else. As we got further into development, I began adding elements that would give the players more strategic control. My goal was to give the player more to do without taking away from the Crags’ autonomy.

The first addition to the design was the ability for the Crags and Garcs to research weapons of war and implements to aid production. The second addition to the design was Leaders. Leaders are special Crags or Garcs who supervise various tasks. Sending a Leader to supervise a task affects the speed and efficiency of the Crags assigned to that task.

mountain setting

Finally, I gave the player governor-like responsibilities for allocating Crags to certain tasks and determining priorities. Once a month in game-time, the Leaders would all meet in the town hall and make their recommendations for allocations. You could over-ride these allocations and directly assign Crags to certain tasks. You could also prioritize their actions within these tasks. For example, you could assign 30% of your Crags to mining, and tell them to spend 90% of their time mining stone and 10% mining gold.

With these elements in place, the gameplay began to take shape. Now the player was constantly busy, watching the Crags go about their lives and trying to keep a handle on resource usage, then allocating Crags to tasks and helping to design and build machines.

From Design to Code

Taking the design into code was a challenging task. An important step was to turn a concept (e.g. “Crags get hungry and tired”) into a methodology (e.g. “Crags have various states that range from 0-10 and diminish at a certain rate based on things happening in the environment”). I took advantage of the time the engineers had to invest in learning the 3D engine to translate all of the conceptual information into tables, systems, rules, and other methodologies that would underlie the entire game.

This system clocked a Crags’ life span, his moods, his states, and any flags attached to him. It determined how he responded to the environment, how quickly the village produced resources, and the effect an under- or over-supply would have on prices. The completion of this system before coding even began meant the engineers could focus on implementing and enhancing the system instead of figuring out how a Crag knows when it needs to eat.

The end result of this planning was the crags.ini file. I knew the numbers in the design document were educated guesses at best, and that we would need to continually tweak them to balance gameplay and create a functioning, believable world. The lead engineer and I created an .ini file that set parameters for the rule system. We planned to include economy and other factors in this file as well.

Where We Left Off

Media Station decided in mid-1998 to focus primarily on broadband technology. More and more of the company’s resources were pulled in this direction over a period of six months, leaving those of us working on Crags stranded and chronically short-handed. By the time the team was reduced to one artist and two programmers (with no adjustment to the delivery date!), the end result was clear: even if we continued development, there was no way to do the game justice on that small a scale.

The final build of Crags included player camera control (moving a camera around a huge conical mountain in a predictable fashion is a challenge), user interfaces, and Crags who went about their lives and reacted to their environment. For the first time, it looked and played like a game. The lead engineer, art director, assistant producer and I played the build the day before I left Media Station. As night fell, all of the Crags snapped on their headlamps and the beams of light illuminated the pathways up and down the mountain. It was a bittersweet moment, listening to them gripe as they bumped into each other, announce they were hungry, and whistle as they built a brewpub. Turning off the machines and walking away that night felt like leaving behind a world that had only just started to come alive.




Crags Credits

I can’t remember the names of everyone on the team so if I missed you, please let me know.

Laralyn McWilliams

John Van Roekel

Jonathan Eves

Chris Klimecky

Related Posts

Storify on being a game designer

Prompted my a news story back in September that Halfbrick had laid off the last of its designers, I chatted on Twitter about some of the challenges in being a designer. I’ve been updating the

Read More »

Example of FSM Building: Combat

A past side project included building Wizardry-style combat. That’s a very specific kind of turn-based combat, best displayed in Wizardry VI and Wizardry VII. I call this phased combat. The player enters orders for each of

Read More »

Segmenting (and not repeating) FSMs

I’ve been talking a lot on Twitter lately about creating my solo game, and I’m going to start saving them here as well. Today, I talked about why you often want FSMs on stand-alone gameobjects,

Read More »

Don’t get stuck on copy

Staring at an empty dialog window? Trying to mock up UI? It sounds absurd, but I’ve seen many designers get hung up on placeholder text. If you have text space to fill, grab some lorem

Read More »

Overcoming game dev resistance

Over the years, I’ve developed what I call the “We’re Guessing” voice. It’s this little whisper in my head, when I’m hip-deep in theory or debate over a feature, that says, “You’re guessing what will work.

Read More »