Essential Game Designer duties and skills uncovered: part 1
In the first part of this series on Game Designers, we define the role itself, identify necessary skills for prospective Game Designers to consider, and shed some light on the essential duties that come with the territory.
If someone wants to break into the gaming industry, perhaps the job title that first comes to mind is “game designer”. But, it might not be totally clear what people with this role actually do. (This can be especially true for mobile live projects.) And further — what skills do game designers need to have?
Hello! My name is Dmitrii Gelunov. I work on War Robots as a Game Designer at Pixonic, MY.GAMES. I have experience working in game support services, working with a development team as an Operation Producer, and also experience teaching conceptual game design and game design documentation.
I’ll be talking about the topic at hand from my point of view as an experienced professional. For junior positions, this article will be useful for understanding some general things: what Game Designers (referred to as a “GD” from this point on) face on the job, what they have to do, the skills that should be perfected and the tools to use. For those in middle (or higher) positions, I’ll try to analyze specific situations relevant to the work of a GD and explain how I deal with them.
For convenience, this article will be divided into two parts. In the first section, we’ll uncover the very basics of the profession: what a GD does, and the skills that will be useful for them. Then, in the next article we’ll touch on more practical topics. Let’s jump in.
What a GD actually does
A GD “creates a game” — at least, that’s what’s commonly believed. And this sounds very abstract and difficult to pin down conceptually. Are they in charge of the game plot? The general style? A specific element of gameplay, or for the gameplay in general? Do they work on their own, or do they manage a team?
Well, the reality is that, for the most part, a game designer is a multidisciplinary specialist, so they deal with almost all of the above to one degree or another.
For me though, in terms of the tasks they face, a game designer is very similar to a product owner. There are some overlapping points to consider: for example, supervision of a particular feature and responsibility for that feature (for its implementation). They both also share responsibility for presenting concepts to the producer and the business, and of proving their effectiveness.
One way or another, a game designer is engaged in similar basic functions — creative work, concept creation and pitching, and documentation.
On the other hand, a GD has many responsibilities that differ, not only from company to company, but also from project to project within the same studio. In some companies each GD has to think about monetization and deal with it, while in others, there’s a separate team for this.
In some projects the meta gameplay and core-balance must be created from scratch and a GD must have certain skills for this. Still, in other projects, the legacy of the game is so great that you can use some preexisting groundwork and simply improve it. Sometimes you need to know Unity or some other game engine, but other times — it’s all about good storytelling and narrative skills.
In small teams, a GD may have management skills to lead development and thus save resources. Often all this is described in the job posting, and sometimes it’s explained to the applicant at the interview itself. But, in general, the potential GD’s skill level, in the areas necessary for the team, should be indicated in advance.
All these skills form your own personal “hexagon of power”. The image above is my personal description. And, indeed, it will certainly be different for you, but the principle will be the same. It would be great if you at least roughly define your skills and highlight the skill set that you’re most interested in further developing.
GDs and creativity
It may sound trite, but creative problem solving is one of the core, and most difficult, tasks for a GD.
Usually, new idea generation for projects which are already several years old, happens according to some “request” from the top, taking into account the needs of the audience and the budget. On the other hand, starting from scratch is usually fairly difficult — but we have a set of tools and sequences to help us with that.
It’s always worth talking to the person who made the request: the producer, the product manager, or your lead, and to let them clarify what they want from this or that piece of content, what issue the feature should solve. Always remember: the right question is 50% of the answer. Once you specify the initial data, you can get to work using several long-established “tools”.
Let’s look at three such tools that I use all the time.
Outlining ideas
When it comes to outlining ideas, you have to work alone. So, choose a time, turn on some special music to prime your brainstorming activity and generate ideas. (You can create a special playlist for use during your “thought generation” moments, for example, I like to work while listening to techno or Japanese trap/bass.)
Try using visual or narrative combinations. For example, if you’re creating a robot using some real-world reference — for example, a robocat — then you can give it some feline characteristics. It’s amazing how multifaceted our imagination can be and how effective it is to take a starting reference point and start development from there.
Brainstorming
If you need more unique ideas, try a team brainstorming — work out some creative chaos together. Gather a team, brainstorm for an hour or a bit more and generate ideas, then the feature owner will select the suitable ones for further development.
Brainstorming is as easy as outlining ideas — the only advantage is that the whole team helps you. To facilitate the proceedings, use Miro; there is already a pre-set frame for brainstorms. Set aside 10–15 minutes for idea generation, then start discussing them. The idea authors will describe their concept in a few words, and the rest of the team will ask questions and try to identify potential pain points.
Remember not to criticize someone else’s idea. Brainstorming is about generating ideas, not criticizing them. The absence of an immediate response allows brainstorm session participants to share ideas more openly, without fear of failure or disapproval.
Note the thoughts you like, leave them to “brew” for a day, and, the next day, select and develop those that you like.
Discussing and Voting
Let’s say a game designer (that is, you) has selected 3–4 ideas that, in theory, are worthy of further development. Now you have to make the final choice — and this is hard.
Here, advice and tips from more experienced colleagues are always useful. Ask them to discuss these ideas with you. Listen to their questions and give answers where possible. Take into account the concerns; you can work them out later. Then, carry out voting for the ideas.
Basically, all three tools can be perfectly used one after the other. Generate ideas, listen to the team’s ideas, discuss them with experienced colleagues, and answer uncomfortable questions.
We have introduced a Feature Owner (FO) system within our team. We like it, but other teams might have different systems in place. In our case, the final decision is always up to the FO, who bears full responsibility for it. If colleagues (leads and seniors) express concerns, and the FO believes that this idea should have a shot, they will definitely work it out in more detail. The ability to stand up for your idea is an important skill to have when working in the GD profession.
As soon as the ideas are selected and approved, the next stage begins: the concept stage.
The concept stage: giving shape to the ideas
The concept stage is usually quite short, but incredibly important. In terms of art, it’s always clear what a concept is: it’s a sketch that gives the customer some initial ideas about the form of the future artwork. In general, whether with features or content, it’s about the same. With the help of a concept, you show the basic idea and forecasts, supported by analytics. The concept is the pre-documentary stage. In fact, this is the presentation of your original, slightly formalized, idea (or ideas) to the team or the customer.
Create a small document, highlight the objectives of the content/feature and its goals, work through the analytics by comparing the resulting content (or feature) with other similar content in your game or in similar games. To do this, by the way, you need to play a lot and be aware of what competitors are doing and why that works or doesn’t work. A GD who doesn’t play games is, frankly speaking, nonsensical.
If you have access to numbers, great. If not, try to predict and find as much information as possible. Visual aids are always perceived better, so attach graphs or maps as you can. Then describe the idea in more detail, take into account the necessary factors (approximate balance, monetization capacity), describe what goes well with the content or how players will play your feature (according to your forecast). Add some small visual references. At the concept stage, there shouldn’t be a lot of those, but the ones you should clearly reflect the essence of what you’re going for.
At this stage, the work of a GD, which was quite abstract before, has become more tangible. You already have a rough understanding of how everything should work, what the team thinks about it, and what difficulties may arise.
In the next article, I will talk about what is, perhaps, the main tool of a game designer: a game design document. And also, we’ll discuss why it’s important to know your own game, and to have at least basic technical and narrative knowledge.
