Ian Schreiber Talks Design: Rapid Prototyping and Game Balance


This week, Ian Schreiber, game programmer, designer, and co-author of Challenges for Game Designers, visited the Telecommunications, Information Studies, and Media department here at MSU to discuss the field of game design. With many years of industry experience, Schreiber has produced open online courses on game development, produced games for two Fortune 500 companies, and taught game design at several universities. He enjoys mentoring game design students and helping them prepare for and connect with industry. Schreiber’s experiences culminate in a wealth of advice for game designers.

Game design is about planning, not building. Designers can be in charge of creating core systems, game writing, content design, level design, game balance, and rapid prototyping, these last two being the central focus of Schreiber’s talk. In such a young field, game balance is something that just happens for most game designers, who are generally self-taught in the subject. These designers often feel insecure about what they know on the topic, perhaps picking up a few things here and there from forums. And since there are no books on game balance, it’s challenging for a game designer to learn and put to work. Schreiber believes collaboration with other members of the team expert in different subjects can help designers grow in this area and find novel solutions, through programming, for example, to implement and create game balance.

“Game balance is about player psychology, so it has all these touchy, feeling, creative inscrutable elements to it. So it has that right brain creative aspect to it, but also a technical, mathematical aspect.”

Rapid prototyping, on the other hand, should be the game designer’s go-to practice for creating games. Schreiber encourages designers to create early prototypes of games in order to know whether or not it’s an idea worth pursuing to the end. On the other hand, he also suggests creating prototypes as often as possible, to cycle through and eventually land at a great concept. Should every designer or student create a prototype every week over the course of a year, Schreiber believes they could potentially have some very strong game pieces to show in a portfolio or fully develop.

In general, the designer should strive to be a well-rounded member of any team, having knowledge outside of their main field, in programming, art, or other skills. For many student designers, Schreiber points out that learning programming can be a fearsome task. As a remedy, he suggests students begin designing and studying non-digital games to study the basis of what makes games good. Learning game development tools for design work is also desirable, and a good way to work up to learning a programming language such a C++. He stresses dipping in programming for the designer as a way for them to be able to understand and communicate ideas and concepts more efficient to their programming team, which can also help designers realize what can be easy or difficult for a programmer to create.

Schreiber believes that there is a three step process to making good games. First, you have to make bad games. From there, figure out why the game is bad. And lastly, repeat the process until you get a good game. Schreiber encourages failure and the idea of “failing faster.” That’s where prototypes come in. As a strong advocate of game jams, Schreiber encourages game designers to look at game jams as a chance to practice their skills and create those prototypes, as many as possible, as often as possible.

Comments are closed.