Student Game Postmortem: Space Lion's Cowboy Bebop at Full Sail University

Howdy Space Cowboy!

"You are Spike, a 'cowboy', living your every day life of gunfire and bounties. Watching your favorite show, Big Shot, you hear of a private bounty put out by one of the largest weapons maker in the solar system. Its lead designer was killed the night before while carrying blue prints of a new secret weapon. To collect the bounty, you must bring back both the blue prints and whoever killed the weapons designer. Spike must now travel to his home planet, Mars, and risk death in a blaze of glory from both the bounty that you are hunting and some old enemies."

Cowboy Bebop: Happiness is a Warm Gun (HWG) was the final project for a small team of game designers under the name Space Lion Software. The project was completed in about two and one half months at Full Sail University in Orlando, Fla. with a team of four programmers dedicating 40-plus hour weeks at school and many more hours at home. The hours were grueling and the troubles we had daunting, but in the end, we all made a project that we could be proud of even through its many shortcomings.

So you wanna be a Cowboy?
At Full Sail, your last class is your Final Project. It's supposed to be a summation of everything you've learned and accomplished at the school. You come in, get a lecture once a week on development techniques, then get to work Independent Game Studio style. Before all this, the teachers were supposed to evaluate you and place you in group of people they feel would be most beneficial to the learning experience and the final project group as a whole. For some reason or other, this didn't happen so we ended up choosing our own groups. Most groups were picked through friendship loyalties while some unexpectedly embraced othersiders. There were fifteen people in our class with four group's dividing it up (three groups of four and one of three). I kind of fell into my group thanks to a few friends I made in the beginning of our core classes. We had already tossed around ideas of what we could do for final project including doing a game based on the awesome 3D Animated show ReBoot. I had my heart set on creating an engine based on 3D billboarded sprites as the main display entity (similar to the system used in the recent Gamasutra article Indie Game Jam Inverts Dogma 2001), but after careful negotiations (seriously!), we all decided on an excellent idea; Cowboy Bebop.

We were all incredible fans of the show and it was the logical choice at that point. If you haven't watched any Bebop I'll just mention now that this show is absolutely amazing! If you like Anime, or maybe just deep storylines with engrossing characters, you will love CB! The animation is gorgeous, the music perfect, and the stories amazing with a finale that will change your view on how a story should end. It was a mini-series of 26 episodes that came out October 23, 1998 in Japan and ended April, 24, 1999. It was finally broadcast here in the US last fall (2001) on Cartoon Network at midnight on Mondays. It's definitely not a kids cartoon and I don't recommend it for the weak hearted.

So after deciding on what we would do, my teammates Chip Etgeton, John O'leske, and John Bustamonte began preparations for the story and gameplay mechanics while I began to implement the basic engine features that we would need, although basic is
probably not the right term. We had numerous sessions addressing all our concerns including what we thought essential, possible, and nice, but probably not doable. The game ended up being designed as a 3D cel-shaded third-person action/adventure game (emphasis on adventure) mixing elements of a Lucas Arts adventure game with a hybrid between Westwood Studios Blade Runner and the Resident Evil series. We created a basic game design document and started a task list; We had learned from previous Full Sail projects that no matter how painful it may be, design and document first, then implement. The task list would eventually grow to 101 tasks as the projects scope quickly expanded. If only it were possible to plan for everything that actually happens; we would have had well over 200 tasks!

What Went Right

"Everybody's got a story." Game Design

The initial design of the game was fantastic. At the end of the project, the final game document ended up being over 50 pages which was actually a record at the time for Full Sail games (most of the other game doc's just used lots of source to pad the manuals). I even did two little white papers on the technique I used for cel-shading and the work involved in creating our custom scripting language. We had our completion criteria list prepared by the end of the first week of planning and weren't kidding around; we wanted this project to be as professional as possible, and in many ways, it was. Everyone clearly knew their responsibilities and was ready to do their part. I was responsible for the engine we used, another teammate for the GUI and menus, another for artwork, and the final group mate was to program the sound components and game scripts (using the scripting engine I was to write).

There's lot's to say about such a system and unfortunately I'll have to save that for what went wrong section. Overall though, through this clear subdivision of responsibilities and thorough game doc, things were incredibly efficient in the beginning of the project. I would say an astounding 50 percent of the project was completed within the first few weeks of production. We were always ahead of schedule and often met deadlines days before they were due. Unfortunately though, progress slowed down exponentially as the project lingered on and people got tired both physically (we planned it out good and we still got no sleep; dedication, that's what its about), and mentally (working in a group of people with contrasting idea's for no pay, benefits, or breaks for probably 60 hours a week can be a precarious situation. People burnout easily and you have to look out for that).

The one sad thing was that even though we had this kick-butt game doc with everything planned out, every teammate still didn't have the same view of this game! I've learned that this is completely essential! I thought we were making an adventure game like my favorite Lucas Arts games, another group mate thought we were making Resident Evil, another Final Fantasy, and yet another something completely different (although I could never figure out what). It's impossible to work on the same project and to accomplish the same goals when you don't share the same vision of what you are creating. If you have to spend two sleepless nights arguing (not screaming!) your idea of what it should be like to your team, do it. In the long run it will create a consistent gaming experience that focus's more on fun than genre.

So overall the planning of this game was an incredible success, and I urge everyone to at least jot down a few things about your game before even starting up your compiler. I would go as far as to say actually plan out your software architecture and how your modules (please use OOP) will interact with each other, but I can also be realistic and just say, have an idea of what you want (I strongly recommend the book Game Architecture and Design by Andrew Rollings and Dave Morris. This book is everything a Game Designer will ever need).

"3, 2, 1, LET'S JAM!" Scripting Language/Engine
Towards the very beginning of the project I decided that time should be invested in creating some sort of scripting language for us to use. It was very obvious that we would need in-game cut scenes and the only way to do this was by scripting (no full time animators, doh!). In the very beginning the specifications called for the scripting language/engine, titled BScript, to handle entity positioning, movements and conversations, camera control (through B-Splines), and item recovery and use. It looks a lot like C code which was great since every group mate knew C++, but the greatest thing about the architecture I used though was that it allowed me to expand BScript to its very limits! In the end we scripted the above mentioned things as well as a Communicator (Cowboy Bebop characters gave you clues through it), AI, battle sequences and dynamic music and sound effects.

The scripting engine would link directly through our input system so it was perfect just to route the input from say, the keyboard or AI through the script which would possess an entity and allow it to carry out script commands. I look back on the system now and the fundamental flaws in it but it got the job done at the time. I would definitely do it different now, but that's experience speaking. I also would have researched perhaps using other scripting languages for use by our project, but I truly believe that in our situation, making a scripting engine was really the wisest path to take, even though it can be a difficult process.

What Went Wrong

"The work, which becomes a new genre itself, will be called..." Scripting Language/Engine

Well, it won't be called BScript. Isn't it great to start off the bad were we left off on the good. BScript was definitely a versatile system that, in the long run, reduced production time significantly, but it took time to make it that way. We were in heavy production of the game in early December, and I needed to have the BScript Module at least 50 percent complete before we left for vacation at the end of the month. If I didn't accomplish this, no work could be accomplished by our scripter, leaving the game looking vastly incomplete. Luckily I did, but there was one thing I didn't have time to do; document it! Our scripter pretty much just went through my code and test scripts and just picked out commands he found useful. There was a definite learning curve and if I had just taken a few minutes to document what I created, this would probably have been alleviated.

Also, BScript had bugs. Big bugs and debugging without a debugger is painful to say the least. I created a whole system that allows an entity to move around, and communicate, but as soon as I added a second entity, all hell broke loose; the system had to be reworked and tweaked at that point. I underestimated the complexity involved in making a system that is versatile yet easy to use and that works with little possibility of syntax errors. After all, you might not notice floating point errors on a Euler Integration scheme, but in a script where actions must be precise, the smallest slip-up has characters running through walls or each other, which effectively "breaks" the script (collision detection breaks a script as well so we had to disable it in a lot of places).

I'll once again reaffirm that BScript was an overall success (marginal victory in Panzer General terms, or at least a draw), but had a few more things gone wrong, it could also have been the downfall of the project.

"It's all… a dream…" "Yeah… just a dream…" Group Conflicts/Distractions
Grand Theft Auto 3, Final Fantasy 10, Medal of Honor and lots more games came out during the development of this project. If you like to make games, you probably at one time or other liked to play them. Well, so did we. It's certainly easy during the course of such a pressure heavy development cycle to seek escape and so everyone in the group at times needed a break. I think in the end everyone pulled through and got the job done but at times we certainly did lose some focus at what we were trying to accomplish. I think perhaps if we had more clearly delineated specific tasks and broken them up into smaller sub-tasks it probably would have been much easier to handle instead of having generic goals that dragged on without clear results. Towards the end of development I think this feeling of an unbalanced task list demoralized the group a bit.

This demoralization shifted into some resentment and I think unnecessary conflict was created because of it. Arguments get heated and logic likes to leave at that point as well. Sometimes it's just all a game of appeasement. Even if three people agree on a point, if the fourth doesn't, it shouldn't mean you should override that person, there need's to be a compromise, even for unreasonable requests. It's the trickiest team dynamic I've found to date and the biggest one to stall you project. Empathy needs to be shown in volatile situations where you could be stomping all over someone's "great" idea (maybe it's great to them, but not to you. Or maybe you're too proud to admit how great an idea it really is. Be willing to accept that). It's amazing how much you can plan, and prepare, and leave time for things, but really a small argument can set you back so much. If something threatens the livelihood of the project, steps should be taken, but there needs to be an understanding that everyone is on the same boat, and it only takes one person to sink it.

"We also have Cub Sushi, but that expired a year ago." Content and Graphics
I've actually had a few college classes involving 3D Studio MAX and about three years experience (including an Independent Film I was involved in which got second place in a student showcase). Unfortunately though, I had no time to model in this project. We had one group mate with strong 2D artistic talent and so (unfortunately for him) he bit the bullet and was our content producer. We had actually had some reassurance from two students from the Animation Dept. at Full Sail (one of them Valedictorian) that they would be able to help us out providing us with a few models. Unfortunately, they weren't able to dedicate as much time or resources as we needed.

So our content producer took some of the things they gave us and tweaked them a bit and then began work on the one game city/level we had planned on. His only experience though was in a 3D Modeling Package called Multi-Gen Creator, and we were using the 3D Studio MAX .3ds file format. This led to quite a few conversion and integration problems but by the end we had figured out a quick export/import scheme for our models. Although he didn't have any trouble with the models (I think he did a good job actually), he had little to no experience texture mapping, which is evidenced in some of the strange texture anomalies you might encounter in the game world.

We also left an essential element of a game to the very end; character animation. We had many discussions about how we would go about implementing this and in the end decided it was just so late in the development cycle we didn't have the time to implement a comprehensive solution. Because of this we ended up with a very basic system that just iterated through a list of models. I had to animate the character in MAX, and then export every frame I wanted as a model. It was an extremely inefficient method and very inaccurate; breaks in the animation can be seen because of it.

I also think a little too much time was invested into the GUI and menu system. It actually ended up being some of the largest code in the game with its own AVI player and vast amounts of states to change. The saddest thing of all was that it wasn't even completed (most options in the menu don't work). We did try to keep the interface consistent though, which was a plus, but it still doesn't justify the time spent on what most consider a null feature. If only we had allocated more time to mini-quests and general gameplay I think we would have had a much more enjoyable game.

Conclusion

It's amazing how difficult a real project can be. When you get a job in the game industry it might not be with old friends but complete strangers with different goals, philosophies, training, style, and even virtues. It's these things that make life so wonderfully interesting and it's these things that help promote the exchange of ideas in our growing industry and society as a whole. This project was possibly the greatest learning experience of my entire life and because of it, I have as a person grown (older and wiser in a way). I've learned that a good design for a game is essential, but even a good design can't account for everything. For large projects, a good source control system needs to be in place. We learned this the hard way. Provisions also need to be taken for the unexpected. If I had failed with the scripting engine, the project would have almost certainly been a failure. We depended on that feature to much, and although the dependency was warranted, the same could have been accomplished through code (without the overhead of the time required writing a scripting language, but also without it's time saving ability).

Through all the good and bad experiences, I still believe there is no job better in the world than making games for a living. I get the same satisfaction out of making a cool new feature for a game I am working on as I do from playing a new AAA title. It's about commitment and passion and things that you don't normally expect out of cold sterile technology. It's also about people and the interactions created in such a small personal environment. Most importantly though, it's about learning from your mistakes and being able to admit your defeats. Hopefully the next Postmortem I do will have a much smaller "What went wrong" section. If not I just hope more things go right!

Special Thanks

My Groupmates: Chip Etgeton, John Bustamonte, John O'leske. Bill Galbreath, all the Full Sail lab instructors and teachers, Full Sail, Heather, Rosie, Ciro, and Chris, TKE's of U.C.F., Gamasutra.com, and GameDev.net