On Programmer-Designer Hybrid
Introduction
I always see myself as a programmer-designer hybrid in the game development field and it's hard for me to let go either of them - there is something charming about being able to do both, but I wasn’t sure what it is exactly.
There is an evidence for why programming knowledge is invaluable for designers and their reaction. It’s not hard to come up with a list of great designers who were/are also programmers: Shigeru Miyamoto, Sid Meier, Jonathan Blow, etc. In this article, I will try to answer the question of how I think programming and design complement each other with my experience. Hopefully, part of the answer can apply to those legends, too.
Creative Process - Inspiration and Speed
One reason why the two disciplinaries help each other is closely tied to the creative process of making games. The process varies for each studio and each person, but here is the way how I make games:
- Find the core idea of this game. It’s the most high-level, usually one sentence description of the game. Some examples are: “An emotional journey where two players help each other”, or “An infinitely large world where you shoot and fly at a high speed”.
- Decide the design pillars. Pillars will then be used as the guideline of future detailed design decisions. They usually look like this: “Each mechanic should facilitate player-to-player interactions”; “Player should get complete freedom for deciding where to go next”; “or “Each mechanic should be used in at least three places”.
- Prototype mechanics and gameplay. This step goes in circle: design a small mechanic -> implement it -> playtest it -> good? keep it / bad? fix it or throw it on a shelf -> design a small mechanic. The reason why a shelf exists is that some mechanics could be used at a later stage.
- Combine and polish the prototypes. Yeah, I usually don’t have a formal “development” phase. Things just come together naturally. And a game would be born after some stitching and polishing work.
This process looks very design-centric, but programming knowledge helped me in each of the stages.
1 - Ideation
Some ideas are directly inspired by programming experience. The “infinitely large world” game idea originated because I wanted to make a game centered around procedural generation techniques. This idea then leads me to more ideas related to dynamic systems and procedural generation like dynamic difficulty adjustment through the dynamic enemy generation and power-up generation (you can try the game here by the way, it’s called “You”).
While for the industry in general, it’s not uncommon for technology to inspire game ideas. In the late 1990s, the advancement in 3D graphics pushed development of games like Quake and Unreal, and RTS games were made better because of 2.5D orthographic projection techniques. If we generalize programming to include technology in general, we can see that more powerful hardware provides the ground for more and better open-world games in recent years. Takuhiro Dohta explicitly said Breath of the Wild was only made possible because of advanced hardware [1].
2 - Design pillars
Design pillars are influenced by the programming the least because it’s more about design philosophy.
3 - Iterations
This is where programming skill is the most helpful and makes the process of game development more enjoyable. As I’m the person who programs gameplay, I’m also the person who experiences it first. The minute I finishes programming, I can immediately compile it and try it out. Because I’m also the designer, I can make design changes and implement them on the fly. This process brings super fast iteration speed and as we all know, faster speed leads to more iteration cycles and probably also better results. The experience of making a game better and better every time I play it is also part of the reason why game development is addictive for me - sometimes it’s just an almost infinite positive feedback loop.
Apart from fast iteration speed, programming also brings a lot of new ideas. As stated in the process, I only had a rough idea of what the game should look like and several design pillars when I start prototyping, so most designs emerge from the process of actually implementing and playing the game. To some degree, the process of making the game facilitates the creation of its remaining part. For example, the grids in “You” was inspired when I was playing the game and found it very fun to squeeze between two blocks. I only get the luxury of doing so as a result of my capabilities of doing both programming and design. If I had a programmer as a partner and I only worked as a designer, it’s not hard to drive the programmer crazy with this process.
4 - Polishing
The main advantage of programming skills here is still fast speed. As I know how the code works, it’s easy and fast to find the piece of code which influences the feel of control in this game and modify that.
In a word, working as a programmer-designer hybrid, I get the privilege of faster iterations speeds and resource of inspirations for design.
No Communication Barrier
A lot of advantages mentioned in the former section comes from the removal of communication barriers. Making games is an inherently interdisciplinary process where expertise from every single domain has a large influence on the end result. However, it’s inherently hard for people from a different domain to communicate with each other smoothly. They typically think in vastly different ways and have different goals. As a simple example, artists want to make the game look great while programmers want the game to run smoothly without any bugs. The differences bring the communication barrier and make it challenging to get a whole interdisciplinary team working on a single shared goal.
With programming skills, a designer can push the game forward without intervention from programmers and vice versa. Sometimes, it’s hard to describe a design to another person precise enough so that a programmer can precisely deliver what you had in mind. Sometimes, the design you have in mind is just almost impossible to convey without showing the actual gameplay. In such situations, a programmer-designer would be invaluable. A programmer who has design capabilities has the instinct to implement the game in a way that contributes to the design goals. This prevents a single task from going back and forth between different disciplines and will save a lot of development time. Also, a good programmer is not equivalent to a good game programmer. I have experience working with a hardcore CS student with strong programming skills who sucks at game programming. The systems he programmed were robust and his code was clean, but the game feels bad. Because most efforts went to coding itself instead of making the game better.
I’m not saying communication isn’t important and interdisciplinary cooperation sucks. On the contrary, I think we should do anything possible to simplify communication and make it as fluid and effective as possible - it’s the only way people can make big games. One of the best ways to facilitate communication is to get some expertise of the other party you are communicating to. In the context of game development, it means that if you are a designer, you should know how code, music, sound, art, production, and business work on a primal level. This is also the kind of person that companies like Valve are looking for - T shaped employees [2].
Figure 1. T-shaped Employee
However, I think it’s worth pointing out that there is another type of communication - communication with one’s self. This time it’s not about cooperation. It’s more about listening. In most cases, one’s self knows what’s the right thing to do and what can make the game better. Sometimes listening to it is not easy but we should all pay close attention to that as designers.
Closing thoughts
Apart from inspiration, faster iterations, and no communication barrier, this is one another thing - freedom. It means that once I have a game idea in mind, I can immediately start prototyping without help from other people. What about art? Compared with design and programming, art is much easier to substitute later in the process, so I usually wouldn’t worry about art. This freedom means a lot to me: I can really make the game I want to make, anywhere, anytime. Well, at least I can make a fairly good prototype and use it to gather a team or pitch to others. I treasure this freedom, and it’s the reason why I am always pushing myself to do both. I hope other people can join me and share the joy. And I hope one day it will become a norm in the industry.
References
- Nintendo (2017). The Making of The Legend of Zelda: Breath of the Wild Video – The Beginning. [YouTube Video]. Retrieved from https://www.youtube.com/watch?v=30jGWna4-Ns.
- Valve (2012). Handbook for New Employees. Retrieved from http://media.steampowered.com/apps/valve/Valve_NewEmployeeHandbook.pdf