Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
Opinion: Costly Production Decisions to Avoid
Reid covers bad production decisions that turn projects into nightmarish clusterf*cks.
*WARNING: This post has been rated M for Mature for language.
11 Min Read
Introduction
Throughout my career I have experienced and heard from others production decisions that negatively impacted the quality of a game. The problem is, they keep happening again and again when they are easy to identify and fix.
Challenges
These common production mistakes can be costly because they hurt production efficiencies, create low morale, guarantee the game will slip behind schedule and ultimately lower the shipping quality of the game. Here are the some costly production decisions that need to be avoided to ensure the highest quality game possible.
One Team for Both Single and Multiplayer
If a game has both single and multiplayer components, sometimes the developer/publisher will try to share resources between the two components, such as code, assets and personnel.
This often leads to compromises between the two teams and gameplay modes that prevent either mode from reaching their true potential. It’s done to save development costs, mostly by keeping the multiplayer team small since it’s expected they can use singleplayer assets easily. It’s never that simple if you want to make a top quality game with both singleplayer and multiplayer modes.
Clint Hocking wrote in Game Developer’s March 2009 issue a post-mortem on Far Cry 2. In the What Went Wrong section, under “Managing Single-player and Multiplayer Teams”, Clint specifically points out, “...the realities of a multiplayer versus single-player game are very different, and this creative vision in itself may have been fundamentally flawed.”
Farcry 2
Only later did they decide to split the multiplayer team off to be managed separately. From the article, it sounds like they weren’t properly staffed to handle this new structure of being separate from single-player. He further states, “This led to conflict, inevitable compromises, and ultimately cascading failure of the entire multiplayer design.” Later, they had to bring in a consultant to get the game back on track.
In my own previous experience, the multiplayer team was only six people, three designers and three engineers. The amount of work we had to do was overwhelming, in addition to working with a new engine and tools being built from scratch. It was expected that we would share gameplay code and art assets with little need for heavy modifications.
The singleplayer level designs were not built to suit our style of multiplayer. Repeated attempts to discuss this with the singleplayer designers resulted in no change in design of the levels. The level artists were stretched between providing art for both modes, though most of their time was dedicated to providing art for the singleplayer levels. This required the multiplayer team to base our designs around what was planned for singleplayer, however unsuitable they were.
For a quality multiplayer experience, we needed the addition of a blocking ability to introduce more skill and dynamic gameplay, otherwise whoever attacked first won due to the auto-targeting system. Because a change in multiplayer meant a change in singleplayer, the singleplayer system designers balked at the idea of a block ability. We felt so strongly about it that we fought for the addition for months.
Only after repeated playtests where players commented that both single and multiplayer would benefit from a block ability did the system designers approve it. In the end though, because our team had so few resources we were forced to cut over two years of our work from the game and move to helping singleplayer ship on time.
Stress
Singleplayer and multiplayer are vastly different games each with their own engineering and content requirements. It doesn’t make sense for one team to build an RTS and an RPG game at the same time, sharing the same resources, does it? If you’re going to do it right, do it separately.
Not Enough Time for Gameplay Pre-production
It’s absurd how often pre-production is given an arbitrary amount of time for exploring gameplay mechanics. A game will have a list of gameplay features and the team is given maybe six months to prototype them. Most teams probably need at least a year to prototype all the gameplay features planned.
But most production pipelines don’t allow proper pre-production time and when the date for entering production arrives, the managers expects everyone to be ready, assuming all the answers needed for a smooth and efficient production have been discovered.
Smooth and efficient production rarely happens because the game mechanics are not fully explored. During production, gameplay metrics such as jump heights are tweaked constantly. A programmer creates a bug that inadvertently creates a cool gameplay experience that according to the project lead now needs to be incorporated into every level.
These constant changes force level designers to play catch-up, modifying their collision geometry, which causes level artists to join in this ever-expanding game of catch-up. It’s so fun that the schedule often slips and the whole team is asked to join in by putting in lots of overtime. The deadlines don’t change, increasing stress on everyone to work faster or longer hours. Usually both.
Office Space spoof
Ideally pre-production is done independent of a games’ production schedule. Gameplay designers need to have the freedom to explore all kinds of ideas. The smallest change in the mechanics can have a huge cascading impact on the whole game. Once all the mechanics are set in stone, then production can begin and roll much more efficiently.
Developing Game and Tech Simultaneously
This is one of the worst offenders and it happens all the damn time. You are guaranteed a world of pain if you develop technology and the game at the same time. It’s a mind bogglingly stupid thing to do.
Here’s an apt analogy. Imagine you are the racecar driver and you and your team of mechanics must finish the race under a specified time to win. Now imagine that 5 minutes before race time you find out that you don’t even have a car to drive. It has to be built first.
All mechanics and engineers scramble to put together the bare necessities of a car to get you started. The owners and advertisers are made aware of the situation and they explain they can’t do anything to help. The required finish time will not change! You, in your mangled mess of a car, if it can even be called a car, can’t go top speed because doing so causes the airbags to inflate.
Instead, you drive as fast as possible, but no faster.
In the middle of the race the car breaks down and the mechanics have stop what they were doing to trod into the racetrack, pick up the car and carry you for the remainder of the laps. But then some clever engineer comes up with a miracle plan to build jet packs for the mechanics carrying your car so they can move faster! Heroically, the whole team pitches in and finishes the race on time.
Even though the team finished, money was lost, tempers flared and reputations burned.
Car crash to finish line
To explain the above analogy, in game development production slows to a crawl because content creators are waiting for the game engine and development tools. The tech developers do an admirable, though naturally rushed job and release buggy tools.
This only adds to the already frustrated and stressed content creators. Producers put even more pressure on tech/tool developers to work faster and better because now the game is a month behind schedule.
Then features get cut or at least their scopes are drastically reduced. Open world? How about open city block? Morale is the hardest hit at this stage as developer’s dreams of making a great game are crushed because their favorite features are slaughtered by incompetence and a clusterfuck of circumstances. Such is the way of life for a game developer.
But it shouldn’t be. There are plenty of engines built for a variety of genres that can be licensed. If a brand-new engine needs to be developed, do it separately from trying to produce the actual game. During the pre-production phase might be the best time to build an engine so that it can be tailored for the game’s specific needs.
Hiring a Writer too Late
Story is becoming more and more important to the success of a game. A screen of text at the beginning and end of a game don’t measure up to the players’ expectations anymore.
Unfortunately, the people that know story best are often brought in much to late in the production cycle to shape the game into one that fuses the gameplay and narrative into a cohesive whole.
A game design director who came up with the game concept may flesh out some characters, mechanics, worlds, a basic plot and then design levels and art assets to flesh out their vision. When the writer joins, they are walking into a production that already has an existing world full of characters and locations and are told to improve on them.
There’s something deeply spiritual and personal about writing. It’s next to impossible to create cohesion on a game concept thought up by a game designer and then written by someone else. The writer may have a certain tone and themes they want to express through the gameplay, characters and art of the world, but because someone else designed those aspects, the expression may feel incompatible.
Additionally, the game may not have room for the writer to express the themes they want the player to explore. As the previous production decisions noted earlier are made, such as not enough pre-production time for gameplay maturation or simultaneous development of game and tech, level content gets cut and story elements bleed with it. No one likes blood, so band-aids (because it’s quick) are used instead of actual stitches. It’s messy and games ship with a scarred ludonarrative experience.
Hiring a writer earlier will make for a better game. In the near future we’ll see game designer/writer teams working together to create new games even before pre-production begins. The two will go on to create wonderful works of art because they treat each other with mutual respect. They understand that gameplay is story and story is gameplay. They are the Yin and the Yang, fighting against one another, feeding off one another, transforming each other to higher and higher levels of artistry. Their efforts emerge as a cohesive entity, one that stands alone with a reverberating soul that touches the lives of millions.
The Yin Yang
Conclusion
In the end, each of these production disasters harms the final quality of a game. With games costing millions to produce and the many millions of lives that invest dozens of hours into the fruits of our blood, sweat and tears, don’t we owe it to ourselves to eliminate these inexcusable production decisions? Don’t owe it to the very people we want to challenge and inspire, our players?
The industry is still struggling to enter a new age where games are respected by the public and mass media as an art form, capable of changing people’s lives for the better. But we can’t do that just yet. Not when boneheaded production decisions stand in our way time and time again, preventing our games from reaching their full potential.
Also posted at my personal blog Reiding...
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
Latest News
Trending
Featured Blogs
