One of the projects I worked on was in development for 3 years before being ultimately scrapped between Alpha and Beta. When it happened, the development team initially pushed all the blame onto the publisher, claiming that the game was only a handful of bugs from completion and that the publisher knew nothing about the industry. Removed from the project and looking back, we did a lot of things right, and I still feel it was the wrong time to cancel it, but there were things we as a development team could have done differently that may have changed the course of our history. A lot of these are common sense, but when you are in the trenches sometimes things creep in without a lot of notice.
Learn from experience
Our studio had struggled to make a first person shooter, after coming together from a variety of unrelated genres. It was a struggle from the tech side understanding the major issues involved in a first person engine. Design had growing pains trying to lock down a coherent story that would support interesting gameplay elements. Art struggled with processes and iteration. We needed someone with experience to take the reins and push us in the right direction. We got this, and by the end, we finally felt we were coming into our own and were ready to apply lessons learned. Then, our next project was an action RPG, and the same thing happened again. We didn’t play to our strengths, which wasted a lot of time. We built tools ill suited for overlapping quests and an open world, and our build process didn’t scale well for the sorts of level and asset dependencies we encountered. Eventually we hired people into key decision making roles who had experience with action RPGs and things started to turn around. But this had to happen earlier on in the project. Which leads me to my second point.
Know what you are building
Seth Godin talks about thrashing early and then locking down and finishing the project. While this may seem like an uncreative approach to a creative endeavor, at some point major decisions need to be locked down, and the more they have been iterated on the more solid they are likely to be. Preproduction serves a number of important purposes, including but not limited to: proving out technical risks, prototyping gameplay systems and environments, and locking down the main story. These cannot happen in isolation, as the main story will dictate what world is needed and what gameplay elements support it. Without those designs locked down somewhat, technical risk cannot be evaluated. We went into production without a solid story, which meant that when new story elements were introduced, new gameplay elements came with them. With new gameplay elements came new world requirements, which stressed our streaming system. New, more complex quests stressed our quest system and our scripting system. And a more complex story stressed our dialogue and audio systems. We had proved out these systems in preproduction, but against a target that had now changed drastically. We also didn’t get an early blockout of our world until after “Game Complete”. Without being able to walk through the entire game, every group is stuck working blindly. No metrics can be finalized, no flow or pacing work can happen, and memory budgets and footprints cannot be locked down. This needs to be done early, and while the world will definitely change somewhat during production, if at least you’re in a ballpark to begin with, it’s easier to evaluate changes against your baseline.
Build a game first, not an engine
If you have the luxury of a great studio reputation, or an investor with deep pockets, or a long term plan that involves many games on the same engine, then you needn’t necessarily subscribe to this. For a two team studio that is not sharing technology, and only one game under our belts, we spent too much time focusing on a clean, reusable engine and not enough time making our game. First and foremost, we needed to ship a product. We weren’t shipping an engine, nor being evaluated on our code interfaces. We needed to get our hands dirty and clean up the mess later. At the time it felt like it would pay off, generalizing our tools and our processes, and it was great technology to work on, but at the end of the day, everything we do is for the player, and we didn’t make that our number one priority. As well, it hurt our toolset somewhat, as this generality restricted various things we could do in our editors. And the other main client for the engineering team are the content creators, so we also hurt that relationship by not giving them the best tools possible to make the game.
Be able to iterate and get easy and fast feedback
This is especially true when delivering tools to content creators. They should be able to get the latest version of the tool suite with one click and no ambiguity as to whether it was successful or not (ie. don’t rely on them synching in source control, or running multiple steps). The tools should be thoroughly tested before releasing, and should be shielded from breakage, whether from code or from bad data. We had separate Main and Stable branches for our code development and tools releases, so we were good about not releasing unstable tools from a code point of view. But everyone was still susceptible to bad data checkins. On that topic, don’t make everyone build every piece of data in the game. One of the big killers on our project was long cook times for data that was required by everyone who wanted to run the game. We partially solved this by doing network caching, but the dependency checking and network copying still had a lot of overhead. And if someone checked in bad data, the cook would fail and content creators were left with inconsistent builds. Check in built data as much as possible and ensure it is difficult to submit bad data. Content creators should be able to do their work, preview it quickly either in the tool or via live tuning, and error messages should be necessary, clear, and nontechnical. In fact, just follow a previous AltDev Post on 5 Steps to Better Tools and you’ll be well on your way.
Don’t pay lip service
Milestones, while they seem like something “The Corporation” does to interfere with our “Creative Art”, do serve a purpose if taken seriously. If all they do is create busywork and artificially boost confidence, then they are a waste of time and can hinder more than help. Missing deadlines are something to be taken very seriously. We missed a number of important goals, and nothing much was done about it. We changed the benchmark a number of times, until “Game Complete” meant “This One Section of our Game has All the Art and One Half Baked Feature”. When you miss multiple game complete deadlines and your publisher isn’t yelling at you, it causes ambivalence, which is a dangerous state to be in. Overtime is a contentious issue in our industry, but at the end of the day, people will work the OT if they feel they’re doing it to further the game in a tangible way. If milestones mean nothing, then crunching to meet a useless goal will lead to resentment.
Enable individual responsibility
Don’t make a small number of people responsible for every little feature change. You’ve hired some of the best people in the industry, so you should trust them! Set boundaries you feel comfortable with, and then give people the power to make decisions. Have a process for getting Directors’ eyes on things, and have a process for involving them in big decisions, but let people do what they do best. Having to wait for signoff on the smallest of changes does two things: it makes people inefficient and it makes them less creative. If a team member has to wait every time they want to get a small change request approved, they’ll likely stop bringing up changes they feel might make the game better. And if people feel that their manager doesn’t trust them, it may breed resentment. This suggestion of course is not all encompassing. Those boundaries you’ve set should include locking down things for milestones, and beyond Alpha things may change as well.
Play the game!
Everyone on the team needs to be on the same page when discussing features. If your world artists don’t know how to fight enemies, or your programmers don’t know how to get to mission X in level Y, then you have a problem. Everyone needs to be able to talk about the major features and locations in the game with a base level of familiarity. If not, misunderstandings will occur when decision making. Levels will be built that don’t support the correct size of area for combat, for example. Or missions won’t work in production levels because they were only tested in black boxes. The other reason to do this is to get feedback. You’ve hired the best talent in the world, and the best way to utilize that talent is to get all eyes on the whole game. We know we get too close to our own work, and bias ourselves about it in one way or another. Having people outside the feature give objective feedback is vital to iteration and ensuring features are consistent and balanced with respect to the game as a whole. Plus, the end goal is fun, and people play the game and it’s not, that should be good motivation! A bit too late, we did a number of playthrough days where we divided up the team and played through the entire game for an entire day, gathering feedback. This brought people together, showed off the good work that was being done, and gained a lot of great comments and feedback that would’ve been useful at all stages of development.
As a caveat, these reasons are mine alone, and may not be entirely correct or complete. I was just one small part of a large team, and so my goal is not to place blame, or rag on the team. It was the best team I’ve ever worked on, and we did so many things right. But such is the state of our industry, where shelf space is tight and success is never certain, that mistakes need to be learned, and quickly.