It helps to understand what the game programmer’s overall goals are. When I was a game programmer, my primary goal was always to make the game follow the rules the game designers came up with. Game design skills help a lot because it gives the programmer a greater insight into what the designer is asking for - not the specific implementation, but the desired experience. Understanding that helps provide additional perspective that the designer may lack, and helps temper the designer’s creative vision with important technical and user-facing constraints. I’ve often used the “90% solution” example where the system is not exactly what was asked for, but still provides the intended experience, but today I’ll use an example that’s a little different.
ALTOne way that a design-savvy programmer will use this insight is to extrapolate and predict unspoken details and potential requests that the designer will likely want in the future based on the current request. This helps with architecting the code because the programmer can plan support for those potential future requests into the system when making decisions about how to build the system. A design-savvy programmer will also be able to see potential edge cases and future conflicts with a particular implementation - not just technical, but gameplay issues. Figuring out how to handle edge cases before starting implementation is much better than running into them later, after everything is built, because there’s less wasted work.
ALTOne recent example I have for this is when I was working with a strike team on a boss system. One of the goals for this boss system is for the bosses to have elite guards spawn with them. The initial design request was just to have the designers able to designate a range around the boss for the elite guards to prefer while in combat. The gameplay programmer on the team had some design experience and suggested that, in addition to caring about the boss’s position when it came to pathfinding, the elite guards and the boss would feel a lot more like a cohesive unit if the guards had designer-controllable targeting choices. Some elite guards could be set to provide covering fire for their boss by engaging with other targets, while others might prefer to target the boss’s target and focus fire. The design team liked the idea and it was green lit as part of the elite guard behavior.
ALTThe design team may very well have come up with that idea or something similar later on, but the existing elite guard system may have needed to be rebuilt in order to handle both behaviors. Instead, the design-savvy programmer saw the issue and brought it up early, such that they could design and build the code system that could easily support both behaviors at once. Having more perspectives to help solve design problems is good - it provides additional considerations and exposes additional vulnerabilities that should be addressed. A programmer who is skilled in design can provide two different informed perspectives simultaneously.
[Join us on Discord] and/or [Support us on Patreon]
Got a burning question you want answered?
- Short questions: Ask a Game Dev on Twitter
- Long questions: Ask a Game Dev on Tumblr
- Frequent Questions: The FAQ
