Code to Make Your Game Designers Life Easier
When learning game development, especially the gameplay coding side, there’s a bit of a trap. When learning you often end up keeping everything in code, especially documentation, as it’s just faster to get through the learning. When coming from enterprise coding this is also just the norm as the majority of the work is done by coders and any documentation will be right there in code.
The reality of the job of a gameplay programmer is very different though, as you are working with a lot of non-coders. Team members from UI artists, Game Designers, and Level designers are going to be using your code and components to be able to do their job. Some might even know basic coding but they really don’t want to have to go into your code unless it’s the last-ditch options.
Luckily Unity makes exposing variables fairly easy to do with [serializedfield] but that alone doesn’t make their life easy. Exposing all the variables for example would be a nightmare for a designer to comb through. So you have to actively work towards making things easier for them. Having a system in place to work with your team, variable norms, and systems named in a way a non-programmer can deduce its use. And this is a major aspect that schools and courses honestly do not teach enough of.
As at the end of the day as a coder your often more coding a toolbox of abilities for your team, so you can focus on coding new features instead of tweaking settings to be just right. So they need to not only get but enjoy using those tools.
How to Code in Intent by Using Attributes
The biggest help you can be to a team member is with the idea of coding with Intent, making sure that with names and default settings alone you can communicate the Intent of a class, a variable, a prefab. In college or work, they might have said “Self-documenting code” but I find the idea of “Communicating Intent” is easier to ensure you actually follow through and ensure that intent is understood by non-coders.
This is a hard process to get right, and proper naming is the starting point. Giving a designer a player.cs object with “Movement” and “Movement2” variables both taking any float value in doesn’t really explain what it does. Maybe in code, you know how it’s used especially as you commented on them but this would drive a designer crazy to figure out.
Instead, if we named the first variable “BaseSpeed” and make the second variable a read-only field with a property drawer called CurrentSpeed suddenly this tells them the Intent of these fields instantly. Adding additional attribute fields like Range can also help ensure designers don’t put in invalid numbers like negative or zero speed, and using ToolTips can open up ways to explain Intent even better like saying BaseSpeed is only used at OnEnable so editing it at runtime will do nothing without disabling & re-enabling the object.
So purposefully sit down and refactor your code now and then to be more Game Designer friendly. A major benefit even if your working alone is it will be easier to maintain and work with yourself.
