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.

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. 

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.

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. 

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.

What went wrong 

1.
Scheduling.

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.

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. 

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. 

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.