Game Dev Lessons - Dream On
People who dream big have a starring role in game development. They’re largely the reason we have originality and newness in games. They’re one of the reasons we have outliers--games that people talk about for years because they’re so different. They’re one of the reasons we have diversity in genre, mechanics, and aesthetics. But working with dreamers presents challenges. Keep in mind that the challenges I’m going to discuss by no means originate exclusively from dreamers. They can come from anyone on a team. I’m simply saying that I’ve seen these issues come up a lot in most teams because most teams have at least one dreamer.
Games are born from creativity, from new ideas that should flow easily in any game development process. But is there a wrong time during development to entertain or implement ideas? I would argue yes.
Brainstorming is critical for a game and should be a safe place for generating new ideas. Teams should use any sort of inspiration/prompt they like in this process: drawing, toying with legos, or mocking something up with paper. But there is a point when teams need to sift through these ideas, choose a direction, and settle on core features for their game.
Team members frequently fall into a trap of dreaming up ideas later in development, when features should be locked down. Sometimes team members will abruptly bring up new ideas that they’ve put a lot of thought into. What happens next can make or break a game. If the team adopts the new addition to their planned feature set but haven’t scoped for that kind of feature in the game, this can be the beginning of a downward spiral. Tagging on extra features can quickly become a bad habit, pulling the vision of the game in different directions and throwing off momentum. The biggest danger is the distortion of core verbs/mechanics in the game design. In other words, more isn’t always better. Dreamers are the biggest culprits of this kind of behavior. They tend to take a lot of ownership of their game ideas, so they 1) constantly think of “more” that will make their design “better,” and 2) have a hard time killing their ideas off for the greater good of the project.
Again, new ideas aren’t bad. But restriction is necessary for a healthy development process.
Building a House
I’ve both fallen into the trap of “scope/feature creep” and also felt the frustration of trying to control the scope when I disagree with these new additions. Here’s a rough analogy for this problem:
Someone wants to build a house from the ground up, so he hires a team of builders. .The employer knows how he wants the house built. And the builders know how to make the employer’s vision a reality. First, the builders pour a foundation--something that anchors the structure and provides vital support in the long run. But as they’re pouring the foundation, the employer says, “Oh, by the way, I want the house to be divided into 5 sections.” The builders note this and continue their process. But once they’ve put one or two of the outer walls up, the employer insists they start on the rooms inside. “We need the basic structure before we start on the inside,” the builders explain. But the employer wants them to start on it anyway, because he thinks it would make the structure better. The builders obey, although they disagree with the proposed process. Then, after haphazardly setting up the inner walls that slant and slump, they attempt to finish the core outer walls. But before they can finish, the employer says, “I think it would be cool if the walls were purple. Can we paint them right now to see how that looks?”
You get the point. The employer is in a dreamer role here, and his additions to the original plan threw off the project completely.
No matter how cool a dreamer’s ideas are, if the ideas are proposed at an inopportune time during development, a team should carefully evaluate their addition. Before adopting a new idea, a team should focus on core mechanics and structures and strategically consider scope, milestones, and the backlog. Add-ons can cripple a project. If you want more, make sure that you have the important stuff done first that you have the time to spend. Let the dreamers dream, but for the good of the team and the project, don’t be afraid to say no.
8/17/2016 11:56:05 am
Well put Spencer! If I may elaborate a little... you need to be careful to do what Spencer proposes while also taking care to NOT send the message of "no changes allowed". The problem with games is that they are infinitely more complex than physical structures (which are very complex but the laws of physics pretty quickly makes decisions for you). To stick with your analogy, here is the problem in reverse. The house when finished has no door into the kitchen. One bedroom is way too small to be functional for anything but the cat. The plumbing falls 20 feet short from where it needs to connect and the front of the house has no windows, no curb appeal. So no-one wants to buy it. The team did notice these during construction but they know that new ideas arent welcome. Indeed, the project followed a perfect plan, came in on time and budget and no-one worked any overtime. The point is, a plan for its own sake is pointless and unlike a house, with games it is often hard to understand what we have until it is somewhat functional. To your point, being open to new ideas is good, planning for meaningful iteration upfront - assuming it will need to happen so becomes part of the plan - is better: encourage improvements to what you're building not wholesale new features (which should always be noted and set aside for a sequel). Plan for prototypes early to get a sense of core game elements such as gameplay or aesthetics. Thus you can have a solid plan and allow for meaningful improvements without blowing the time or money budgets. Plan to build great dont just plan.
4/10/2023 11:48:33 pm
Thank you for writing thiss
Leave a Reply.
I'm a games lover, designer, and producer; Beatles freak; fishing enthusiast; and music researcher. It's tough to have so many good things in life!