How to be helpful

It’s often stated that a game designer needs to be helpful and understanding (listening is the most important skill for a game designer according to Jesse Schelle). Indeed this year, in a workshop in my class, I heard something that really stuck with me: “the game designer needs to have the complete vision of the game, not to impose it on others but to understand what’s important, what can be cut and what can be achieved in a way that is easier for the team to accomplish”. The idea is that by knowing the objective of your game, you can help reduce the workload of your colleagues if you discover that the same objective can be reached in a different and easier way. As game designers, we primarily work with words, and I know our words are powerful and difficult to write but admittedly, not as powerful or difficult to write than what programmers write in their code. If you see it this way, it becomes obvious game designers are the centerpiece of a team not because they dictate their ideas without making compromises, but because they are the best at compromising the means without compromising the goal. If this is an important skill we should concentrate our efforts to improve it as much as possible. So today I want to share some ways I discovered to become more useful to the team as a whole and to better understand their necessities. Before going further, I have to admit that my biggest problem for a while was that I didn't fight enough for my ideas, so I didn’t have this problem as much as its opposite: I compromised too much. But learning about other people's necessities and priorities as well as their workflow has helped me design with a better idea of what is easy for the others and to better understand what could help them without having to always renounce my ideas. In a sense I thought I was good at compromising because I did it often, but I didn’t do it in the right way as I didn’t understand how I could make everything work out without renouncing any of my ideas. So without further ado, here are the things I do to become a better member of a team.

Ask

This should be obvious but for a variety of reasons we can often forget to ask if something is difficult or if it creates problems. Of course people can express their problems to you, but, in my experience, often they trust what they read in the game design document and try to execute it as it is. A simple question can help you a lot in understanding their method and their workflow, which brings us to the next point.

Discover the implementation

This is a thing I started doing recently which I found extremely useful. Especially after some parts of the GDD that were hard to write, I began to ask the exact way in which those things were implemented. Usually there is a difference between the way you imagined it would be implemented and the way it actually was and programmers can usually explain it in a way even a designer brain can understand. After I started doing this I noticed two main advantages:

• For that particular feature, I knew what were the easy ways in which it could be expanded and which things were impossible

• In general, I started to understand how to write documentation in a more effective way, similar to the way they actually code

This little exercise can help to get a grasp of the logic behind high level programming even if it’s something you have no idea how to actually do, and it’s especially useful for designers without an IT/programming background. Which obviously brings us to…

Code

I am not a person who loves coding, and I think many game designers fall into this category, but I found that coding and visual scripting (which I do like) can help you better understand the way a programmer thinks and the way a code is structured. I recently started to program with Unreal blueprints something I designed some time ago without knowing that I would be the one to program it, and it was a really enlightening (and humbling) experience. While I prototyped, I noticed many little things that I could have designed differently that wouldn’t have affected the end result but that would have really simplified the life of my programming self. Obviously a good programmer doesn’t have the same kind of issues as me, but it has helped me understand that we really can simplify a lot by changing little. 

Stay close

Something that should not be overlooked is how much you can understand about other jobs by simply being near them while they work or taking a beer with them in the evening.  People love to talk about things they're passionate about or to vent about their problems and you can learn a lot by listening (of course, it's also a fun activity to do in general).

Think about the consequences

Another useful exercise is to think about all the ramifications and consequences of your choices when you design. We use to do this for repercussions in the design, but doing it for the other departments can go long way to simplify other people's job. Does this fit thematically? Can this be acclomplished by making small tweaks? Can I solve this problem through level design?

In the end

That's all for today. I know I said some pretty obvious things for the most part, but these (as many other in this job) are the kind of suggestions that one easily forgets along the way. So it's important to sometimes stop for a moment and doing them intentionally. I know it helped me.

As always let me know what you think or if you have any suggestions on this topic. See you next week for another article, bye!

Credits

Image by Freepik