What is this thing we call game making? And how does it relate to other forms of design and manufacturing? Is there a better way to make games? These are few of the questions I hope to answer in this series about making games using systems engineering principles and disciplines.

WHAT IS SYSTEMS ENGINEERING?

IN THE SIMPLEST SENSE, SYSTEMS ENGINEERING IS MANAGEMENT OF A DESIGN PROJECT FROM AN OVERALL SYSTEM PERSPECTIVE.

Systems engineering is a process that focuses on customer needs and required functionality early in design stages. The systems engineering team designs for the complete lifecycle of the the system, from initial conception all the way to eventual disposal.

How does this relate to game design, or more specifically, game making? I say game making because taking a systems engineering approach goes far beyond just the design of the game and relates to disciplines such as art direction, publication, retail, etc. So, in this sense what is the system?

THE SYSTEM CAN BE DEFINED AS YOUR GAME, AND NOT JUST THE BASE GAME BUT YOUR GAME AND ALL INTENDED EXPANSIONS, PROMOS, VARIANTS, SUBSEQUENT EDITIONS, ETC.

Anything that will carry the same name now and in the future is the system.

Systems engineering is composed of a number of disciplines. These disciplines enable the systems engineer to look ahead within the lifecycle of the product and anticipate future requirements that may drive current design changes. These disciplines are illustrated in the following chart.

My purpose is to talk about game making and how the systems engineering disciplines of Requirements Definition, Solution Evaluation, Configuration Management/Interface Control, Risk Management, and Verification/Validation can assist with game making.

• 1. Requirements DefinitionIn systems engineering, requirements definition is the process of discerning what the customer wants and what needs are being met by the product. Requirements should be documented, actionable, measurable, testable, and defined to a level of detail sufficient to design a product. In game making this corresponds to that step of writing out all your goals for a game, figuring out theme and mechanics or identifying areas where new mechanics may be needed.Good requirements definition in game making will consider the following: how the designer wants a player to feel when playing the game; whether the designer wants to go from a theme down approach or a mechanic up approach or some combination of the two; what types of games are lacking in today’s marketplace; where are the holes that this design can fill. There are many more considerations but I think you get the feeling for what questions you are asking yourself during the requirements definition process. My friend and fellow writer here, Luke Laurie, has said when designing his game Replicant that one of his goals was to create a game “that would support a large group of players, with the feel of a traitor game, but one in which there were no teams and no elimination.” This kind of thought process is what I mean by requirements definition.
• 2. Solution EvaluationIn systems engineering, the solution evaluation discipline is about creating potential solutions to meet the requirements and testing them both in the computer modeling world as well as in real world tests. We as game makers do this by creating designs and prototypes and play testing. This is what most people think of when they think game design. And while this is an important aspect of game making it is just one small part of the overall system. It is not game making as a whole.One thing to keep in mind during the solution evaluation phase is test everything. Brainstorm ideas and test them all out. One thing that will ensure your success in this effort is keeping good records of tests and mechanics. Only change one small thing at a time so you know exactly how that affects the whole. In the engineering field we call this iterative development and testing. The general idea is don’t change too much because then you will not know which particular change affected which outcome in the testing. If you make incremental changes you can easily backtrack from those changes that did not work.
• 3. Configuration Management/Interface ControlConfiguration management is a process for establishing and maintaining consistency of a products function and physical attributes throughout its lifespan.Interface control is the discipline of documenting and maintaining consistency with regard to interfaces between the systems and subsystems or the system and the outside world.It is in this area that I feel game making can learn the most from systems engineering principles. Configuration management is what ensures that your ipad will always have the same charger through every subsequent generation. In game making, configuration management can be used when designing expansions or future editions of your game. Game makers need to implement careful thought and planning in making expansions and later editions so as not to obsolete or ruin their original designs or not to tarnish their good name.

  Consider for a moment the case of Thunderstone. The game was published in 2009 with subsequent expansions published in 2010 and following. Players of the game discovered that the expansion basically broke the original game causing AEG to redesign and reissue it as Thunderstone: Advance in 2012. In the process they rewrote most of the rules for the original Thunderstone. Another example of poor configuration management is the 2nd edition of Pandemic. While not a complete rule change like Thunderstone, the 2nd edition of Pandemic changed the artwork on the back of the cards. Now any new expansions like In the Lab are not compatible with the older version of Pandemic. Z-man games has since released another set of the base cards of Pandemic with the new backs so they are now compatible with the new expansion but with a little systems engineering knowledge and practice they would not have had to.

  What should you as a game maker watch for when designing and/or publishing games? Make sure all expansions are thought out before you ever go to print. They don’t have to be fully designed but at least know where your interfaces into your base game are, how they will affect the base game play. A good example of configuration management in game design is Dominion.

  DONALD X. VACCARINO HAD ALL 500 CARDS IN ALL DOMINION EXPANSIONS THOUGHT OUT BEFORE RIO GRANDE EVER PRINTED THE FIRST COPY OF DOMINION.

  That is configuration management! As a game maker just be aware of your game and how it will change with future expansion or editions. Plan for art changes and mechanics changes. Make sure you won’t have to reissue your entire game because you accidentally broke it with an expansion.

• 4. Risk ManagementIn systems engineering, risk management is the identification and prioritization of risks and procedures implemented to mitigate those risks. Systems engineers usually classify risks on two scales. One is probability that a certain risk will occur and two is the potential impact to the system should that risk occur. So, a risk that will cause catastrophic impact but is highly unlikely to occur may be prioritized lower than a risk that will cause moderate impact but will be assured to occur. In game making there are many risks present. Evaluating those risks and planning accordingly can increase the value of your games to the marketplace.What are some risks that can occur in game making? One big one I can think of is production delays. How do you mitigate this? Is there something you as a game maker can do to help streamline production? This should be thought of during the design process. How about the risk that your cherished game mechanic, the one you designed your entire game around, does not resonate with play testers? Do you have a backup plan? What would you do if you purchased a game and discovered that another designer had independently come up with the same mechanic you are working on? These are just some of the risks faced by game makers. I am sure there are many more.
• 5. Verification/ValidationFinally, your entire design and product needs to be validated against the original requirement. In game making this is that blind play testing stage. Does your audience have the same feel when they play the game that you had intended? Can a person pick up the game and play it out of the box without you there? Are all the components absolutely necessary? As you read feedback from play tests or watch play tests yourself, be open. Realize that these people are not trying to hurt you in any way. What they have to say will only make your game better in the end. Take what they say and go back to the beginning of the cycle and start over. Your game will thank you for it in the end.

There you have it – game making from a systems engineering perspective. One other thing I would add is that these disciplines are not implemented in a vacuum. Each one builds off of and influences the others so they should really be performed simultaneously. I will be back next time to discuss the key players in the systems engineering process and how they relate to the key players in game making. You will also get an understanding of why when we hear pitches from designers, Cosmic Wombat Games would rather you come to us with an unfinished game.

UPDATE: Click to read PART 2!