Constraint Driven Game Design

(I'm going over some old material - this was written in September 2014, but hopefully there's still something useful to you. I think at the time I was loosely employed to help with a small Facebook finance app, using gamification to drive usage/data/activity.)

If you search for "Constraint Driven Design", you'll find discussion on engineering. I think about this all of the time when it comes to game design.

In a lot of design work, you're expected to have a brainstorming session, where nothing is voted down. The goal is to come up with as many creative ideas as possible, and that negativity shuts down the creative process. CDD starts off by fencing away that open land.

Maybe it starts off like this:

1. We need to make a game that plays on a tablet, cross-platform.
2. Games need to last no more than 3 minutes.
3. Multiplayer, with very little AI automation
4. We would like a battle game with leaderboards.

If you're going to be a professional, you will need to adapt. It is incredibly rare that a designer has carte blanche to put out whatever they want. Embrace the constraints as a challenge to your creative talents.

Things That Aren't on You
That said, there are things that should NOT be on your radar, unless you are taking on more than just a design role. You shouldn't need to worry about resources. If you are not involved in a triple-A title, you won't be expecting that much in resources. I find it useful to know how big the team is, so we know what to expect..would the team grow if we needed more artists or programmers?

Another thing to lose concern about is cost. There's going to be some way in which the company recoups its expenses, and hopefully makes a profit. It's fair for a product manager to say "This is a freemium game from day 1" or "It will start off at $5 for 3 months, and then become freemium." Is it up to you to make the game for less than $5 a unit? Not likely. Are you expected to personally deliver 100,000 units in sales? No. But your group should deliver a product worth purchasing, and a method where players can pay, if it's supporting in-game transactions.

How to Win at Constraints
Some constraints like "play on a tablet" are straightforward. Skip ahead to the constraints that aren't locked down. Battle game is entirely open...pretty much every game will be a battle or a race in some fashion. Taking things like "games last no more than 3 minutes" SEEMS like it is obvious. What would happen if the results of those mini-games trickled over into bigger games? You could choose to play the bigger game if you had more time, or the smaller games in less time.

...and How to Lose at Constraints
If the constraints are constantly changing, you will lose. It's fine to have constraints in the beginning. Adding constraints later, kills the forward momentum of the design. "Okay, you need to optimize this game for a specific tablet, as a selling point for the tablet". All of a sudden, your zippy first-person shooter fails because the tablet you're designing for can't handle the frame rate.

If you don't establish constraints early, you can fail easily. The lead designer needs to tackle this early on, or as early as possible. Nail the limitations down so that a dozen more don't crop up unexpectedly. You only get one artist, and who has only done 2-D work? Good to know. You have 2 months to go gold? Scales down your expectations a bit. A product manager might be unwilling to give you limitations - but it also means that they could skip communicating necessary constraints.

The Takeaway

• Find constraints
• Identify how constraints are open or closed (determining what you can design)
• Verify the constraints (check with other stakeholders)
• Design the actuals

Good luck!