Postmortem: American McGee's Alice

In April 2001, Game Developer Magazine's postmortem of the month and featured cover game was American McGee's Alice, a gothic, action-adventure take on the Lewis Carrol classic Alice in Wonderland. This PC game was American McGee's first solo venture following his start at id Software and would be the series he was most known for, embracing the dark fairytale edge that would also later be seen in Grimm, McGee's episodic retelling of Little Red Riding Hood. The reluctant auteur, who attributed his tastes to his religious upbringing, went on to release an Alice sequel, Alice: Madness Returns, which brought the games to console, but a fully conceptualized third entry in the series would be rejected by EA, prompting McGee to abandon game development altogether. This postmortem, written by Rogue Entertainment co-founder Jim Molinets, lays out what they felt went right and wrong with the original project and has been reposted here for the first time with its original artwork and photos.

For more insight into this iconic game and its unique place in development history, read our interview with American McGee from 2001, in which the developer discusses the influences and mindset that led to the game's concept. You can also take a look at the postmortem of McGee's retelling of Little Red Riding Hood, Grimm.

Alice, the Cheshire Cat, and the Mad Hatter in the Fortress.

What do you get when you take a successful independent developer, one of the world's largest game publishers, and a design inspired by a property that is both unique and familiar, Lewis Carroll’s Alice tales? You get Electronic Arts looking to make a huge splash with their first PC action title, Rogue Entertainment creating American McGee's Alice and a roller coaster ride of success and failure all wrapped up into one little black box with a girl and her enigmatic cat gracing the cover. 

American McGee's Alice is a tale of a young girl who is subjected to a tragic incident which leaves her severed from reality and locked away inside the safety of her own mind. Years later, the experience begins to attack Wonderland, turning it into a dark and threatening place, as broken and fragmented as Alice herself. We wanted to create a game that would combine the frantic elements of such legendary games as Doom and Quake with the adventure elements of a Tomb Raider. We were shooting for a game that would seamlessly combine those elements with an intriguing story and use the boundless freedom of Wonderland to create fantastic environments in which to present these features. Another goal was to create a strong female heroine devoid of the usual extremely overexaggerated female assets. Alice was to be a character that would cross the usual gender boundaries in action games and bring female gamers into the fold. 

The wireframe, model, and skin for the Alice character.

Rogue was prepared to carry out these goals through our extensive experience with the QUAKE technology, stemming from five years of working with id Software on mission packs for QUAKE and QUAKE 2, and the N64 port of QUAKE 2. We know the id technology inside and out, which was one of our greatest strengths when we started our discussions with EA. We had a team of nine dedicated professionals, ready to tackle the challenges of Rogue’s first full title since our introductory game, Strife, four years prior. We also felt that we needed to leave behind the “mission pack” company mantle and that ALICE would let us do just that. 

As a company, all of us were enthralled that we would be the ones to tell a new tale of Wonderland and our Alice’s adventures through them. The programming team was prepared to enhance and expand the technology to create a platform that would support the immense weight of the content assets. The designers were ready to shape a world so exciting that it would set new standards in level design. The artists were equipped with the ability to transfer the warped representations of a twisted world to the textures and skins of this world. Our modeler/animators wanted to stretch the preconceived notions of Lewis Carroll’s characters and add our own additions to the bestiary, with creative flair that would burn these characters into the minds of the players. Needless to say, we wanted Alice to be the best game that we could make it, and nothing was going to stand in our way of making this happen.

Concept sketch of Alice.

What went right

1. Company and team growth. 

While growth presented a challenge to Alice’s scheduling (discussed later in “What Went Wrong”), overall Rogue managed to avoid panicking and hiring warm bodies to fill empty seats. We waited and chose people we felt were right for the company and the team. This was not an easy task, but today we feel that we have one of the strongest, most talented teams in the industry. Just as important as making sure that you make your deadlines is the need to put talented people in place to help you do that. Hiring on a whim has gotten us into trouble before, and our shift to a more refined search paid off during this project.

2. The level of professionalism. 

This professionalism displayed by the team stretched across all aspects of design to include everyone. There are industry horror stories of teams that are ruined by egomaniacal people. This, for some reason, seems to have become the norm for developers. Rogue has always tried to stay away from that issue, and we feel that the team did just that. During the development of Alice, people were not interested in who got credit for what, or whose great idea something was, but simply that everyone was working to make the game stronger. This also applied to criticism, another area where egos can get in the way. The Alice team members openly critiqued each other’s work, and this was never viewed as malicious or hurtful, but again as something that would make the product stronger and help everyone.

3. Creative freedom. 

We never closed the door on creative freedom on any design aspect. I have seen some developers who start with something as a base for an idea, and the team members responsible for the implementation of those ideas are not allowed to deviate from that path. I am not suggesting that people are or should be able to make any change they feel is right, but what worked for us on Alice was to use the design as an overall goal of what had to be accomplished with an asset or portion of the game. While the actual work was being done, we encouraged experimentation and creative input so that the entire team could share every aspect of Alice, not just the individuals responsible for the original ideas. This translated to higher-quality assets and the kinds of inspirational touches that make games really shine.

4. “Guerilla” meetings. 

The Chesire Chat.

Due to the tight time constraints of Alice, there came a point when team meetings stopped being called; e-mail summaries were sent out instead. After a short period of time, it became obvious that we needed to have meetings regardless of the schedule. 

To keep the things on track, small “guerilla” meetings were set up where key people met and ironed out any issues on the table quickly. This proved to be a great way to solve major problems without incident. These meetings also served to keep people informed as to what other departments thought might be problems in the future. 

For the engineers in particular, guerilla meetings became an invaluable tool. They were short meetings, with only the key people from each department, and they stayed very focused, allowing those in attendance to get back to their work quickly.

5. The Alice intellectual property. 

I saved this one for last, but most people around the Rogue offices will agree that this was one of the best parts, if not the best part about the project. Most developers look to create something that is new and exciting for their next intellectual property. Sometimes this works out wonderfully (Age of Empires, Starcraft, Doom, The Sims). Sometimes it does not (Battlezone, Interstate ‘76). All of those are great games that I have enjoyed playing, but the latter group did not strike the same chord with consumers that the others did. 

When we first heard that Alice was available, we were concerned that this would be something that could go very wrong. Instead, the original body of works inspired the team to try to create something that would do Carroll’s works justice. The IP also gave us unfettered creative freedom. Who’s to say what works and does not work in Wonderland? 

This is one of the issues with using real-world settings. No matter how fanciful you make the differences between the real world and your game world, people still ground their knowledge in what should work in the real world. The scope of this freedom was upheld by EA, and we let the team tear into it, creatively speaking. This was also something that has been noted by reviewers as one of Alice’s greatest strengths.

Top left: Alice in action in the garden. Bottom left: Alice using one of her weapons in the fortress. Above right: Alice battling the Queen of Hearts’ minions.

What went wrong 

1. Scheduling.

The Jack-in-a-Bomb.

No schedule survives the first milestone intact. There were many factors that forced us to rework the schedule, but the most important was growth. We started the project with nine developers thinking that we could complete a title that, by the end, required about 25. Our first mistake was to think that one modeler/animator could complete the Alice character and all her animations in three weeks. By the end of the project, our young lass had 180 sequences with about 12,000 frames of animation. Some of that didn’t make it into the game, but you can tell by those numbers that we were off, way off. Without a doubt, main characters in third-person- perspective games require dedicated artists from start to finish. 

Underestimating the amount of time it would take to complete one entire level was another factor that hurt our schedule. In Quake 2, it would take one designer about one-and-a-half to two weeks to create and populate a level, if the level was laid out in advance. In Alice, it took nearly a month. That also did not include the scripting or cinematics, which added at least another week. We were prepared to make Wonderland all it could be, we just didn’t have a correct idea as to how long that would take. 

These errors, combined with other, similar factors threatened to push Alice into the “another late software title” category. In order to minimize this impact, we asked the team to go into the infamous Crunch Time about four months before we were supposed to ship the product. (I use capital letters because anyone who has been through one of these knows that it simply requires that kind of respect.) That amount of effort burned out everyone, and to no one’s surprise, when we needed to ask even more from people at the end, they couldn’t push themselves any more than they already were.

Concept art of Tweedle Dee.

2. Communication. 

A lot of projects credit miscommunication or lack of communication as factors in causing delays in the product development cycle and missing the original ship date. Alice, unfortunately, was no different. Rogue started as a nine-person team in one office, a war-room atmosphere which fostered the “Rogue attitude” of community and a stream-of-consciousness design flow. That works for a very small group of people, but simply does not work for a team of 25. We knew that moving to new offices during Alice’s design cycle meant changes to the team’s organization, allowing for more structure and better information flow. Initially, we tried to leave our style of open office communication in place at the new offices with the expanded team. This did not work as planned, and when coupled with growing to three times the original team size and having an extremely tight timeline, caused a fundamental breakdown in communication. Information that should have been given to all team members about design changes was not disseminated correctly, and sometimes not at all. This led to a “blurred” management structure as we tried to insert people into a new management hierarchy. We also had problems with training new personnel, as the veterans of the company were trying to sort out their new positions, train new people, and keep to the already tight schedule.

3. Lack of predesign time and assets. 

There are some in the industry that use the “fly by the seat of our pants” design path. That was something that we were able to use when we were a smaller team, but again, as a company grows, it cannot afford to fall prey to this mistake. With a full team, everyone needs to understand all aspects of the game, and any allowances here only make every other aspect of managing the team and creating the product exponentially harder. We started with a great high concept and some very detailed character information, but when we started to develop the levels and overall structure fully, milestone pressure began to loom, and we had to speed up development to make sure that we would meet our obligations. 

While this took care of the short-term issues, it left the team without fully developed goals for the long term. This hurt us most during crunch, when time is of the essence, and several design elements ended up needing to be reworked or tweaked at the last minute. Spending the time to develop the ideas and assets would have saved weeks of work towards the end of the project. Fully developing your ideas before you start asset creation also helps communication flow, because then everyone knows what is supposed to be completed by when and can track the schedule individually. This in turn allows the team to have much more personal flexibility in their asset creation and working schedule. 

The caterpillar.

4. No time allotted to prototype new gameplay innovations. 

The entire team had one goal in mind when we started this project, to make the best game for the PC in 2000. Most developers have that in mind when they start working on a title, but we felt that by combining powerful technology with our intellectual property and a strong team, there was a very good chance that we could do this. We also knew that in order to reach this mark, we were going to have to introduce some new and interesting game elements that had not been seen on the PC before, or which had been accentuated for Alice. Consumers and reviewers alike are always seeking the holy grail of innovative gameplay combined with cutting-edge technology. At the beginning, we knew that the schedule was ambitious. As the development progressed, however, slippage in other areas created an inability to prototype these new innovations fully. We had to fall back on the tried but true action/adventure elements, and if you have been following the reviews of Alice, you know that this is something that has been seen as an issue with the title. Some of the more interesting elements that were not developed or fully explored were sliding (à la Mario), flying, swimming, and most importantly, more specialty puzzles designed to fit the Wonderland theme. 

5. Outside “help.” 

I will be honest here and say that we did have some incredible help on the title by people outside of Rogue. When that worked, it was poetry in motion. However, when it went wrong, it went very wrong. There were instances of work created that had to be redone by internal team members, which pulled them away from more important scheduled items due to the fact that those assets were needed for a more immediate milestone. There was an overall problem getting one particular set of assets from outside that should have been done months before we shipped, but instead they were done by a single contractor with only weeks to go. I am a firm believer in asking for help when you need it, but make sure that the people you are asking to help will really make a difference. If you plan on using them to fulfill milestone requirements, and they miss their milestone or give you assets that cannot be used as is, then you have wasted not only money, but also that more valuable commodity, time. 

Left: Blown away. Right: Checkmate; a chess game ending in Alice‘s favor.

Lessons from the trenches 

Game development is about taking the good with the bad and the fortitude necessary to realize creative solutions to challenges. It was this credo that kept Alice chugging along and made its eventual release only one month late. We completed the product on our original budget, built a team, moved during production, and had issues with internal communication, outside contractors, and a lack of predevelopment. If someone were to ask what the single biggest lesson that we took away from the development of Alice was, without hesitation I would say that it is the need to plan out the entire product in advance, before anyone begins production. Working out the complete game flow and details would have greatly reduced the impact of the problems that arose during Alice. 

Also, as a producer I would tell anyone interested in running a project, no matter what size, to learn how to work in Microsoft Project. It is by no means a magic bullet, but it definitely allowed us to realize very early on exactly where we were going to need assistance and let us start planning our path before it became critical. 

The last lesson, and one that we feel the entire team was part of, is that no matter what the problem, there is a solution. It may not be the best or most graceful solution, but it’s one that will get the job done. Creativity in this industry is not limited to designing games, but is also an essential part of any successful development process.