Essential Game Designer duties and skills uncovered: part 2

In the second part of this series on the Game Designer profession, we delve into practical aspects of the role: dealing with documentation, reference boards and mood boards, technical considerations, narrative, and more.

In the first part of this series (which you can read HERE), we discussed the basics of a Game Designer’s (referred to as a “GD” from here on out) duties and some useful skills they should have. But, nevertheless, let me remind you: a game designer is a multidisciplinary specialist who participates in the creative and conceptual stages of a game’s development, formulating ideas and presenting them to producers.

In this installment, we’ll discuss more practical things that make up the GD workflow.

Disclaimer: as mentioned in the previous text, game development tasks can vary from company to company, and even from project to project within the same studio. That said, there are still some common elements across the board.

Dealing with documentation

This is a huge (and my favorite part) of game design. A lot of articles have been written on this topic, I studied game design myself using some of them. (There was even a stage in my career when I taught game design documentation.)

It’s important for a GD to love documentation, and to treat it with the utmost care. Accordingly, train yourself to work with it from the very beginning. You have to delve into Confluence, write documentation, collect reference boards, and so on.

So, why is documentation so important? This is because it forms the rules, collects all the critical information in one place and, ideally, gives answers to a big chunk of possible questions.

Depending on the type of documentation, the sections within will vary. However, a description of the content/feature goals, game mechanics, visual components, sound, FX, animations are needed almost everywhere.

For example, if you’re building a “house” for a base in a farm building game, describe the following:

• Why it’s needed, and in terms of meta house gameplay, how it will compete with other units
• Its function, its unique properties
• How it will work
• How the player will develop it
• How it will look, the animations and FX it will use (with references required)
• The sounds will it make
• The technical aspects you reuse and the ones that need improvement from programmers
• Localization keys and texts for translation

If you’re making a major feature, it’s important to ask QA for advice regarding the tools you may need in the future to perform QA. If you’re improving or creating a similar feature/unit of content, it’s possible to use existing tools. Support services have a similar situation: often, in order to operate with created content, certain tools are needed. And, in an ideal world, we, GDs, design these during the feature/content creation state, and then use them in the future.

So, to make future work easier for you and your team, create documentation templates. These will come in handy, especially when producing common content. Decompose the existing documentation, talk to the lead programmers, Support, QA, the art department — they can tell you which sections are needed, how to form them in the best way, and what information is requires posting.

For example, if you have one type of content that is produced with some regularity, make a template, add the necessary sections, and fix it so that each following document derives from it (left image). Ensure it doesn’t inherit the last written GDD (Game Design Document) to avoid errors and a telephone-game effect (right image).

When generating documentation, one should keep in mind an important detail: the GD does not adapt documentation for themselves, they adapt themselves to the established flow of documentation generation in the team, to its structure. You can’t just come in and immediately rewrite all the documentation as you’d prefer — this can break the workflow for a significant number of your colleagues. They’ll need to ask you questions regarding every issue. It’s always worth trying to make the team feel more comfortable. If there are any critical points in the documentation, change it gradually, updating existing documents.

For example, if an art component is missing in content GDDs, but this component is needed, try to fix it. In order not to shock your colleagues, tell them about your plans, add existing art to the existing documentation, and add an art section with instructions to the template — including the descriptions which should be added, where to add reference pictures describing the details, and where to attach a video.

Reference boards and mood boards

Both of these are equally important for documentation. First, for the creative side of things — as I wrote in the previous article, you can come up with interesting concepts based on real references (do you still remember the robocat?)

Second, without a good reference board and description, it’ll be difficult for artists to understand your idea. The level of necessary detail largely depends directly on the team: in some cases, artists ask for more room for their own creativity, in others — you need very clearly describe and indicate every detail of the content or feature that you want to end up with.

Don’t forget to provide a description to the attached pictures and specify what exactly you want to borrow from the reference, otherwise you can end up with a complete mess.

My favorite example is a horse in a coat. Everyone imagines this concept in their own way. So, if you give the artist a request and a reference board without clear instructions. The results can be quite unpredictable. Here are the references:

But someone can imagine a horse in a coat as an anthropomorphic figure, while someone else illustrates a coat on the actual animal.

This is a fairly simple case. If there are more details involved, it’s much easier to mess things up. If your expectations don’t correspond to artists’ results, you’ll have to spend real hours and resources to redo everything.

You can use Google to create reference boards, but there are many handy free tools, too: These include Artstation and Pinterest, or you can try to draw the result you’re after by yourself. (Personally speaking, I draw comic-style sketches or mock-ups; this helps get on the same wavelength as the artists or UI designers.)

Just type in your query, and if it’s difficult to find something, decompose that request into separate nouns, adjectives, verbs. Art references are worth taking seriously if you want to create cool and high-quality content — and don’t forget about your project style.

Oh, and another little tip: use the color circle to tell the artists which color scheme to use. This will help speed up work and save you additional iterations.

The importance of proactivity and knowledge of the current project

A common problem I faced while working as a GD (and in other positions too) is that developers don’t actually play the games they develop very much.

From the GD point of view (and, perhaps, this is also true for support and Community Manager) you need to play — and play a lot. Think about your target audience, the people you’re developing the project for. If it’s midcore or hardcore genres, you need to get to the highest levels, try to compete with top or near-top players in order to understand how they actually play your game, and how they utilize the game abilities that you came up with.

Personally, I think it’s better to do it using your own money and with your own effort. That is, don’t take shortcuts to get into the top leagues, don’t experience only top content, and try to reach high levels on your own. You’re unlikely to understand the feelings of a “whale” (a player who pours a lot of money into the game), but you’ll definitely get closer to understanding an average player.

It’s very important to understand how much this or that thing costs in dollars and emotions, and how difficult it’s to get to the big leagues. Since my support days, I’ve made it a habit to go from FTUE (First-Time User Experience) to high-end competition as a player. It seems that, this way, you begin to better understand player pains and needs.

If you encounter any bugs, or logical or technical inconsistencies within your project, it’s very important to bring this to the team and offer solutions. Some might say that QA is there for this, but it’s in your best interests to monitor the quality of the project.

Here’s a kind of health check that can help detect a large number of problems: sometimes testing fails to detect problems when testing a feature, content, and so on. After the release of the next patch, try to play a few matches and spin the loot boxes. Don’t hesitate to push the issue of any detected problems until they’re resolved.

In general, it’s better to allocate one working hour to play your own game. I understand that all of the above sounds very obvious, but, unfortunately, after several months of work on thae project, or after passing the first levels, many begin to ignore this simple truth. Because of this, strange content may appear, as well as useless, not interesting features for players. And all this simply because the people working on the game don’t understand how users actually play the game.

One last thing on this topic: don’t forget that, despite the above advice, first and foremost, you’re still a developer. There is a balance to keep in mind. This means you should keep your distance from players, don’t get too involved in the game and keep in mind the project business task. This doesn’t mean “only think about money.” Think about how to create a game on the highest possible quality level.

The technical aspects

If you look at the GD market, you’ll notice that employers are increasingly looking for people who, among other skills, know how to work with game engines or operate some server things (launch events, change the chest contents, and so forth). Personally, I’m happy about this change, because this part of development has always attracted me. (Although this opinion is not generally shared by other GDs.)

It seems that for a person entering the game design sphere, it’s really necessary to have basic experience with Unity or UE. And additional skills will never be redundant, they will expand your opportunities in work or in your job search. It’ll definitely be useful to go through basic Unity tutorials, and watching YouTube guides or tutorials is definitely a good step.

It’s important to remember that basic Unity will have almost nothing in common (except for the main functions) with the Unity that you’ll actually have to work with. Large teams often adapt everything for themselves and create tools and scripts that will be useful in a particular project.

A general understanding of working with algorithms and functions will definitely help you a lot. Algorithmic thinking, obtained via game engine study, will be of great use, both to novice applicants and experienced game designers.

Let me repeat a point: it’s not always necessary for a GD to work with the engine, but having such an opportunity and some basic skills is a good addition to your core skill set. And, this also includes work with version control systems — always useful to have, do not neglect it.

Narrative/script writing

At the start of my career, for some reason, it seemed that to me this narrative or script creation would be the easiest part of game design. Many GDs that I know first came to the profession dreaming of creating worlds, writing stories, and coming up with new, unique, and attractive characters. Everything turned out to be a little bit more complicated than expected.

Everything always rests on your visual “stockpile of experience”: It’s impossible to predict all potential workplaces and what kind of background will be required at each.

For example, let’s say you’re passionate about Tolkien’s work, but your current job requires you to come up with a story for some James Bond-related game. You may simply lack experience in this case, and so that’s why you’ll have to dive into the topic and learn some new things. In this case, by the way, you must study the references that customers provide you with, and in an ideal world, they should exist and help you broaden your internal visual library.

It’s even more difficult to join a project which already has a developed story. In such a project, characters need to be created based on existing lore and canon.

To solve this task, I would like to highlight a chain of actions to be taken:

1. During an interview, it’s worth deciding whether or not you like a topic, and if you’re ready to dive into it or not. If you believe you can’t make yourself like it, it may be worth giving up at this stage.
2. During the onboarding process in a new company, it’s worth studying narrative references: read books, watch series and films, play games. If there are no references, try to find them. In this case, similar topics and overlapping genres might do the trick for you. In a nutshell, try to study everything that will help fill your brain with patterns that will later help you in your work. And don’t hesitate to contact your new colleagues; they can suggest a lot of useful things.
3. Refactoring and reproduction of accumulated experience. Often what’s old is new again, but in some reworked manner. You learn new information, digest it, mix your knowledge, take something out of it, and come up with something that suits your project.
4. You can use standard tools:
5. Basic scripting courses will help, if you’re working on a big story.
6. Basic techniques for writing short stories, if you work with those.
7. And don’t neglect the tools we talked about in the creative section, like brainstorming — they’re great, too.
8. You can also use some non-standard tools. For example, currently, neural networks are popular, and they can significantly help you with your work based on your input data. It’s clear that they won’t give you a ready-made solution, but they can give you some kind of a starting point on your path to a cool idea.

Game Design management

In some companies, it happens that the GD, in addition to performing the huge number of functions described above, also manages the team in some way, (which is perhaps closer to the Product Owner functions, as I wrote in the first part of the article).

Let’s consider a simpler option. You are a game designer. One day a producer (or some other person who “orders” the idea) comes to you, you offer a solution, it gets approved.

Further, the implementation side of things falls on you. Setting tasks isn’t so difficult as they can often be created automatically. But to leave the decision-making process unattended is a bad idea. Yes, your colleagues from neighboring departments (and, most likely, you will have to work with departments like UI/Dev/Art) are great professionals; they know their stuff. But it’s critical to always monitor the results of task execution, synchronize it with your expectations, and give detailed and tangible feedback.

There should be a balance between “they know what’s best” and “I know what’s best”. Imagine a common ground that sounds like this: “As a GD, I like the result. Meanwhile, they, as professionals, highly appreciate the result in their way.” Professionals have their own evaluation criteria, and if you like a huge red button in the middle of the screen, and UI professionals say that it won’t work well, you should listen to them, discuss and find a common ground.

Conclusions and advice

Finally, let’s briefly go over what’s been said in this and previous parts in order to sum everything up.

• A GD is a multidisciplinary specialist who, in many ways, serves as a link within the development team. Correspondingly, it’s important not to become a “bottleneck”.
• It’s always worth keeping an eye on what’s going on in your game. To do this — surprise, surprise — you have to play it a lot.
• It’s important to have at least some basic knowledge in the areas where a GD might be involved: narrative, working with the engine, and even monetization in some cases, if the project has monetization mechanics planned. And once you’re on the project, you can start actively improving the skills required on that project. And, of course, those skills that you’re personally interested in. (If you do something out of your interest area, you can lose your mind very quickly.)
• Feel free to use third party tools, programs, and tricks to make your game-design life easier; they were created exactly for this purpose. Of course, it’s never good to pass off other people’s results as your own, but drawing inspiration from your industry colleagues is a normal and healthy process.
• If you want to be a professional, you have to constantly learn new things, so don’t disregard new tools and methods. If everyone is using neural networks, why not give it a try, too? Try to apply them in the workflow — it may suit you (by the way, neural networks are only presented here as an example; they could be replaced by something else).
• Pay attention to project numbers and key indicators if you have access to them (and if not, think about how to get access!). These will tell you a lot about the state of the feature/content and the project as a whole.
• While looking at numbers, don’t forget about the people who play your game. Stay up to date with the status of the project/meta from the inside: what players do, why they do it, and so on. What are they complaining about? Think about how to improve the situation.
• When solving a problem or creating a project, always approach it comprehensively and thoroughly. You can’t make a good feature if you don’t understand what, why and for whom you are doing it.

I hope these articles were useful for you and helped understand the tasks GDs solve and what is most often required of them — good luck!