Thinking Like a Programmer, Thinking Like a Designer

Jul 23, 2009

Learning gameplay design will make a gameplay programmer a better gameplay programmer.

Learning gameplay programming will make a gameplay designer a better gameplay designer.

The ancient Greeks espoused an ideal of balanced unmatched in modern civilization. Every adult should have experience and developed skill in carpentry, playing an instrument, participating in athletics, speaking persuasively on legal and political matters, dancing, and so on, quite independent of any individual’s particular profession or path in education.

Although “equality” is a word that has profoundly positive connotations in the modern world (to the extreme that I expect this sentence will anger some readers), one downside that has come with it is the false notion that to gain ability in one area somehow hinders ability in another. To a literal extent, if every hour of the day were occupied with productivity and learning, this might be true; I contend that this is the case for no one, except perhaps the sort of person that drags out whatever tasks are on their todo to sparsely fill whatever time is afforded for the work to be done.

If you’ll put the time and energy into learning design that designer A does, and you’ll put the time and energy into learning programming that programmer B does, you’ll be far better off in your abilities than either person A or person B.

For the lone videogame development hobbyist, this sort of thinking essential to unblock progress and minimize the risks of depending critically on others. For the professional in a team environment, this can aid tremendously in communication by improving understanding in the languages and mindset of other workers and their processes.

A downside of the information age is that there’s an over-emphasis on what people know, with much less attention given to how people think. There’s much more to what differentiates an musician from an automobile engineer than simply what they know, or what they practice. The ways of thinking are different – affected and formed, no doubt, by practice and knowledge – but it isn’t just a wikipage plus repetition.

Likewise, to be acquire skills in both design and engineering isn’t simply a matter of knowing what both know. It’s important to learn the differences in how specialists from both disciplines think, and how to switch gears to fit the needs of different situations.

What follows are generalizations. “Design” is a huge field covering many different areas of expertise, and “Engineering” comes with just as much history and complexity. Since the purpose of this newsletter is to help provide perspectives and information relevant to videogame development, what is said about design and engineering in this table (and in these newsletters in general) is based on how I have seen these roles play out during team and individual videogame projects.

Gameplay Design Software Engineering

Answers what to do, and why Determines what’s possible, how to make it work, then makes it work

Decides features, invents the systems of interaction, lays out interfaces, prepares missions/levels/scenarios, balances units/items/weapons/characters, evaluates potential alternatives… Plans, programs, tests and fixes programming code for gameplay systems: player input, artificial intelligence, level formats, network functionality, graphics rendering…

About tradeoffs and compromises About exactness and robustness

Accounting for many things at once Isolating, solving 1 problem at a time

List of parallel goals/constraints Ordered todo list

Exploring many variations to pick the best one(s) to finish Thorough planning to minimize rework or redundant effort

Done poorly, the game isn’t enjoyable, or fails to stand out as original Done poorly, the game crashes, or fails to impress with novel tricks

Done well, the game sells itself to anyone that takes the time to try playing it Done well, the game runs smoothly, is stable, and may accomplish what others don’t know how to do

Which answers are “best” tends to be subjective, though fundamental principles make certain solutions far more or far less desirable than others An optimal answer usually exists, although compromises may be made from consideration of time, skill, or prior experience

Human feedback takes place throughout, and taking stock of the needs by all groups involved (business, technical, player, peer designers) is a significant part of the work Requirements are handed over at the outset, and clarity or efficiency of implementation may be judged after completion; while working, machine feedback (as errors) is constant

Often involves inventing a novel discipline (new jargon, concepts, groupings) around the task at hand Builds upon generations of patterns, systems, and generalizable solutions

More like art or writing, in treating most problems as one-of-a-kind, though understanding and considering historical approaches More like legal drafting, in often solving complex problems rigorously via a mixture of previously solved problems and some particulars of the case

Focused on player’s overall impression, employing consistency and polish to create expectations then fulfill them Focused on whether each isolated detail works as expected, including how the overall systems connect the parts

Although good process distinguishes a good designer from a bad one, end results are what the world cares about Although good process distinguishes a good engineer from a bad one, end results are what the world cares about

Special Abilities from Multi-Classing

The application of software engineering thinking in design work is technical design.

The application of design thinking in software engineering is architecting.
(…in the programming/technical sense. This has nothing to do with buildings.)

The combination of software engineering thinking and design thinking is useful in discovering new forms of gameplay by playable prototyping. It brings together the thought process of what’s worth doing with an applied understanding of what’s possible with the technology.

(Originally posted as part of GameDevLessons.com Vol. 4 Sec. 2)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



Comments are closed.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.