Series Info...Storms on Cloud 9 #38:

What Went Wrong

by Scott Holliday

It's been more than two years since I started the "SoC9" column. More specifically, it's been more than two years since I introduced the concept of building a text-based life-sim game based upon fairy tales (Soc9 #1). At the time, the checklist schedule that I had laid out would have had the game complete and ready to play in one year. So, I think I will pause for a moment in the discussion of how to make games for players, and instead look at how to make games.

In effect, Orphan Crown development has now been on hiatus for almost a year. I've done bits of work on various aspects that I liked, but the original idea hasn't moved forward at all since then. I wanted to present this article to players and fellow developers as an analysis of what went wrong. My hope is that others who are dreaming of making their own game will read this and make wise decisions as they go forward.

On December 12th of 2002, I received confirmation from Skotos that my proposal looked good to them, and that I had the go-ahead to begin development. One of their main concerns was that our plan to build a life-sim game would require extensive coding efforts, but they were pleased with our background, our world, and our plan. At the time, I had five people on my team and things looked grand. We already had a plan written out listing who would do what, so within a week everybody had settled into their role and things were cooking. Our roster looked something like this.

  • Code Development, Design Lead (Me)
    • Learn Skotos' languages and get our game's new systems up and functional.
    • Make sure everyone's project was on schedule, especially those that were interdependent.
    • Keep everyone's designs and work thematically together and sensible so the game would present a single world concept rather than a mishmash of different ideas.
  • Art Development
    • Create artwork to match the feel of the game, primarily for the purpose of outside hooks, but also as the framework for the text, and as specialized places/rewards for the players.
  • Builder Lead
    • Learn Skotos' systems for item/room/character creation and begin putting the world together.
    • Teach other builders so that they learn more quickly to contribute toward the goal.
    • Research material and act as an additional level of thematic control.
  • Sim-Game Design
    • Design an interlaced set of jobs, goods, and services for the life-sim aspect of the game.
    • Enter this information into an outside database to facilitate easy drops into Skotos' database.
  • Game Design, Writing
    • Use experience with the genre to put together stories/puzzles for use in the active game.
    • Note further ideas and explore the theme for additional concepts to enhance the experience.
We thought we had our bases covered, and so it began. The whole team was made up of personal contacts. We'd known each other for years. We knew each others' strengths and weaknesses. We met at least once a week, usually even more often. We each had our task, and the job was big and scary, but once I had looked in to how well the Skotos languages would serve our plans, none of us were really concerned. So, during the next month or two we made leaps and bounds in development.

Orphan Crown City

The entire city and all the room connections (as seen in the CC2 graphic above) was assembled programmatically using some outside programs that I made and Skotos (Merry) code. At this point, it was all empty rooms and featureless directions (NESW) to move, but the builder quickly learned how to put in content and began churning out the room, object, character, and feature descriptions. Within a short time, I had added the game-specific commands to handle the interaction with the simulation aspects of the game, and the in-game role-playing rewards that players could distribute (similar to that described in SoC9 #8). By this time, our artist had put together some absolutely beautiful artwork (as the sample seen at right).

Orphan Crown Logo And so came our first point of failure. You'll notice that only three of the members were mentioned in the paragraph above? The remaining two weren't doing anything. Admittedly, initially they couldn't do much except jot down ideas and put together plans of how things were going to work. In the case of the Sim-Game Designer, we needed a list of objects and charts for how they would interact. Unfortunately, not even this was happening. Thinking he needed to see it ready to go, I made an offline database for his use so that he could enter information in quickly, and dump it all through Merry later. Still nothing. A month passed, and then after a pep-talk, a little data was added, but then stopped again after much complaint. Looking at what had been done, and realizing that the pieces I had wouldn't fit, I gave up and slated this part of the project later for myself.

In the meantime, the Game-Design/Writer had nothing written, but could pour out thematic ideas faster than I could say "no". Most anyone will tell you there is nothing wrong with ideas, though ideas are a dime-a-dozen. The problem is that the theme was already fairly solid. No, I didn't want crazy faeries that would fly around grabbing players and dropping them randomly somewhere else. No, I didn't want men sitting on a bench who would comment on the appearance of any female characters that walked by. No, I didn't want shape-changing vampires wandering the city at night. I wanted puzzles. I wanted riddles. I wanted challenges. I wanted things to do. This would require writing and serious thought. However, all I was getting was verbal ideas for entirely differently themed games. And when I wasn't there to listen, nothing was happening. So once again, I gave up and slated the live-game challenges for my own later development.

At this point, I should have looked for outside help. But these were close friends, and we hoped that over time they might become more interested. Likewise, I didn't want to make an appeal to the Skotos community before we at least had something worth-while to show for our efforts. So we continued. By this point, the artist had crafted enough artwork that we thought it was more than enough to handle the game's release. If the game was popular, then we could ask for more art in the future, and hopefully even pay a very, very small commission.

By this point, I had the player "heartbeats" for the simulation aspect of the game working, such that they would automatically consume food, proceed at their job, craft items that they were working on, teach students, learn, and produce and use up resources. Unfortunately, the project was beginning to wear on me. I had too many hats, especially since I was also now also helping the builder aiming for the minimum we'd be willing to show.

We asked a builder from another game to come assess one of our rooms while we looked at one of his. I forget who this was, please forgive me, but it was a real eye-opener. We realized that our level of detail was sparse to non-existent for the text environment. Apparently, in our experience in text games, we'd never honestly taken a good look at our surroundings. Rather we played the game for the game's sake. Sure, we had basic descriptions, and features, and objects... but we hadn't really considered the depth of detail necessary to give a game life. We'd never thought about all the features of features of features present in most games. Likewise, there were common objects and descriptions which we'd just left out. As one of many examples, players might want to look at the doorframes themselves and we hadn't even considered them. Regardless, it was getting to be too much for us, and we aimed to get up basic descriptions, then invite the community in "later" to help fill it out.

The city was just too big. It was beginning to look like an ever-growing Gordion knot. We had more than 100 rooms to fill, just for the city itself, and we only had basic descriptions for maybe 25. The lead builder was getting so frazzled that some of the room descriptions were coming back very strange. For instance there was the friendly neighborhood butcher shop that with descriptions somehow became what I like to call, "the cruel animal slaying pit of rotting gore and pooled blood". We had also considered the quests and adventures available outside or in the maze below, but once again slated that for "later".

In the end, realizing that it was just the two of us, we slated the whole project for "later" and tried to pick up the pieces. We had a short stab at producing a much smaller environment (shown below) with a focus on the magic system that I had mentioned in SoC9 #7. In our minds, it was to be a magic dueling society. Or, as described by others, it was professional wrestling with spells. This went well for some time, and we even had a short play-test with some of the Skotos crew. Naturally, despite our testing it over and over, during the test, the code failed such that only two people could be in the room or it just wouldn't work. Unfortunately, with just the two of us, there was no way we would have noticed that error beforehand. Regardless, although the play-test overall went well, we were starting to get depressed. Even with only 20 rooms in the school, it was just too much. We still had bunches of objects to do, and we'd already wasted most of our energy and creativity on the previous city design.

Orphan Crown School

So shortly thereafter, we decided to just give it a rest. We took several months off, which later turned into more than a year. We got married somewhere in the middle of that. So, in that sense, the project was a success! In the meantime, we decided to instead just play online games for a while instead of making them. We knew that we'd failed and we needed some time to reassess what to do about it. The decision was to come back "later" and build something smaller to start off with.

I didn't intend to ramble on this long without reaching conclusions. Regardless, I'm hoping those reading can see the errors that we made, and so plan ahead to avoid them.
  1. Although coders are required if you want to make specialized game-systems, the world-builders (or world-describers) are absolutely critical. Good coding may be a specialized skill, but creative writing is just as difficult and perhaps even more tiresome.
  2. Just because someone is enthusiastic does not mean they will do the work required to reach the goal. Something more is required - I think I would call it devotion. Unfortunately, this is a difficult thing to assess until work has begun. It's easy to say you're excited, it's harder to prove it.
  3. Devotion can take you a long way, but if you bite off too big a piece, you'll still choke. We had the interest, and we were making progress, but it was just too big a job for two people.
  4. Losing team members can be depressing, but you still can't take on all the jobs yourself. It is obvious now that I should have immediately tried to replace them. Not only was it important to the game, it was important to our remaining enthusiasm for the project.
  5. At least for your first project, aim small - make sure you can reach your goal easily, so that the next project will be easier. Get a few successes under your belt. Learn the system. See what works. Then make your dream-game. In fact, I would seriously suggest that anyone who wants to make a Skotos game, first spend some time as a Builder/Coder for one of the other S7 games in production.
As the tally stands, Orphan Crown is no longer in development. Someday, I'd love to pick it up again. The concept is still a lot of fun for me, and I'm going to keep coming back to it until I'm ready. I'm a game-designer by nature. I want to make games. I need to make games. However, not this one right now. On the other hand, now that I've had some time to rest, I've started up the spell-dueling concept again using PHP with the intention to make a graphics style competition game. I expect to have it working by the end of February. However, I'm saving the graphics work (Javascript or Flash) for after that, so "working" and "playable" are two entirely different things.

This time, it's a one-man project. This is an interesting arrangement, because I make the game (all by myself), while my team (my wife) writes a novel instead. That way, it's easier for both of us to avoid aiming for the sky, because we know it's all going to be our own effort. We can still sound ideas off of each other, or get a quick play-test or proof-read, but the creation is all up to one person. Obviously, this is not the way to do big projects, but as I said before, "start small".

[ <— #37: Filling the Sandbox | #39: Consequences and Death —> ]