5 Useful Facts about Game Design
5 Useful Facts About Game Design
Or, Stuff You Never Thought You Wanted to Know Until Just Now
Do you ever feel like there’s a gap in your personal knowledge database when it comes to game design? Have you ever wondered about the day-to-day life of the average game designer, or what they do when observed in their natural habitat? Fret not, for today is the day that you can fill that gap and cease to wonder!
Read on and you will learn (at least) five facts about game design and game designers that you can dazzle your friends and family with, or simply use as conversation starters when in polite company.
Just imagine… You’re attending a dinner party, cocktail in one hand and hors d’oeuvre in the other, and you’re not sure how to keep the conversation going with the arms dealer and/or distinguished diplomat standing nearby… No problem! Just whip out one of the facts from this article! Example:
You: “Did you know that 2 out of 3 professional game designers know how to use VLOOKUP in Excel?”
Arms Dealer and/or Distinguished Diplomat: “Whoa! That IS interesting! Haha, you’re so funny and knowledgeable!”
1. Game designers are not the only source of ideas for new games or game features!
OK, so technically this is first fact is mentioned quite often, but it Bears repeating as it’s Mighty important to get across and may not be obvious to everyone.
We work in a creative industry, and in most cases the pitching of ideas for new games — or new gameplay features/content — is not a practice reserved exclusively for game designers. Everyone on a game development team is a potential source of ideas, whether they are a designer, an artist, a programmer, a QA tester, the CEO, or the CEO’s 7 year old nephew.
Ideas can come from anyone on the team (or even from outside the team), and depending on the studio might be assessed and chosen through pitching contests, brainstorming sessions, discussions, painstaking market research, or any combination of the above.
2. Writing a design for “a game” is not the same as writing a design for “a game feature”
I recently wrote about this topic in another article, Game Design vs Feature Design, but the gist here is that writing a “game design document” for an entire game can be very different than writing design documents for specific features found in a game.
General game design documents (or GDDs) are often written as outlines, with overviews of features and systems, often with the intention of aligning the development team on the game concept they’re going to work on, or to document for a publisher the full extent and scope of the game — which may then end up forming the basis for milestones and deadlines along the way!
Rarely do these documents go into extreme detail on individual features — at least in its initial draft. (As the development process unfolds and the details of each feature are fleshed out and nailed down, the specifics might however make their way back into the general GDD.)
Design documents written for specific systems or mechanics, on the other hand, go into much more detail. They are written to provide a blueprint and path forward for the implementation of the design, with sufficient detail to provide answers to any questions that might arise during implementation, whether they’re from the designers themselves, UI/UX designers, or engineers. They also cover edge cases and outline design risks, so that informed decisions can be made on these throughout the process.
Fact 3. Writing design documents is not the only thing a game designer does!
Yes, the rumours are true: Game designers DO play games! Not all day, as some might have you believe, but it comes with the territory that designers play games spanning a wide variety of different genres and platforms. This isn’t just to keep up with the trends and behaviours of the game industry, but also to research how specific features or mechanics are handled in other games, to find inspiration for tweaks and changes that can be ̶c̶o̶p̶i̶e̶d̶ applied in their own games, and to gain additional insight into what works — and what does not.
It’s not all fun and games, though! With more games released every week than any one game designer could possibly keep up with, they must sometimes make sacrifices when it comes to choosing which games to play — or how long to play them. Instead of sinking 150 hours into the latest open-world survival game, it’s usually better to divide one’s attention across multiple titles, playing each one for a capped number of hours or long enough to see the positives and negatives before moving on to the next title to as you build a wider sense of industry trends.
Game designers also need to test the games and game features they’ve been working on extensively and relentlessly. Not unlike (but still less than) our colleagues in QA, we’ll be play portions of the game over and over again ad nauseam, until we’re so sick of them we start dreaming about retiring to some remote cave as far away from video games and the whole of civilisation as possible.
Depending on the individual designer, day-to-day activity may also extend to other tasks:
- Game designers are often responsible for the implementation of gameplay content in the game engine being used to create a game, meaning they need to be familiar with working in engines such as Unity, Unreal Engine, or perhaps other, proprietary ones developed in-house at a given studio.
- Using scripting tools or languages to hook up state machines, AI behaviours, quest functionality, dialogue trees, player/NPC abilities, boss battles, and beyond.
- Placing NPC/item spawn points, quest objectives, setting up story triggers, adding in-zone teleporters, etc., to the game world — or writing quests, coming up with storylines, and designing the game’s narrative.
- Depending on the studio or team setup, a game designer’s job scope can also extend to UX design, including the creation of page flows and wireframes to detail the user experience, though this might just as likely be handled by more specialised UI/UX designers/artists.
- Some game designers are generalists who do a little bit of everything as required. The smaller the studio, the more useful a generalist designer can be. In larger studios, however, designers often specialise in very specific areas of game design that even come with specialised job titles, like: System Designer, Economy Designer, Gameplay Designer, Content Designer, Quest/Narrative Designer, Level Designer, AI Designer, Scripter.
Some of these particular roles might be held by people who walk a knife edge between the fields of design and art (UX design/level design), design and programming (system design/scripting), or design and writing (quest/narrative design), depending on where their strengths lie and on the needs of their project/studio — but they are all designers!
4. A good portion of the average game designer’s time is spent nose-deep in spreadsheets
The extent of this varies from designer to designer, and can range from nearly non-existent in the case of Level Designers and Scripters to nearly all-encompassing for System Designers and Economy Designers.
Still, whether it’s to plan out player progression, to balance economy or combat systems or to simulate item-drop rates and and monster spawn tables, chances are that almost every game game designer will at some point or other find themselves starting down spreadsheets full of numbers, formulas, graphs, and charts!
Actually, here’s a free #protip for any would-be game designers: Look up and learn how to use VLOOKUP, INDEX+MATCH, and pivot tables.
Although there are many other tools at your disposal, these form the backbone of everything you’ll need to do in spreadsheets as a game designer, and they work the same across all major spreadsheet software.
In fact, many job listings for game design positions specifically highlight knowledge of and experience with these spreadsheet tools as must-have skills!
5. Game designers care about the WHAT and the WHY, but (ideally) leave the HOW to engineers and UI/UX designers!
As game designers, we are not there to tell the UI or engineering departments how the technical implementation of a game system or mechanic should be carried out.
Our job is to inform them of what feature should be implemented, why it should be implemented, and how (OK, technically there’s one “how”) the game/system/feature/mechanic should work, either from a player’s point of view or from a system point of view (or both). Some simple examples:
- Every time the player kills a Foozle, they receive XP. Every time they gain enough XP to max out the XP bar at their current level, their level increases and the XP bar resets. Once the player reaches max level, stop giving them XP.
- Ability A needs to have a cooldown of X seconds. If the player attempts to use the ability while it is still on cooldown, disallow using the ability and instead play an annoying audio clip of a voice that goes “That ability is not ready yet.”
- First, each player gets to move between 1–3 tiles, in order from player with the highest initiative to player with the lowest initiative. Once all players have made their move, each player gets to attack a target (if any) on an adjacent tile, in the same order as before. Repeat until only one player remains alive.
However, we don’t tell the programmer to implement the XP/level system using a particular feature of a programming language, or instruct them to store persistent player data in one type of database over another. No programmer wants to hear a game designer utter advice like…
“What if, instead of storing this data as a string in Unity’s player preferences, we store it as a quantum blockchain matrix in a cloud-enabled Beowulf cluster data centre in the sky? As a bonus, we could allow the player to sell the string as a unique NFT!”
Similarly, we don’t tell the UI artist to make ability button A 20 pixels tall and 15 pixels wide, or direct them to setup a UI prefab in a particular way in Unity.
Instead, we leave the fine details of technical implementation to the people best qualified to handle them, and focus on getting the intended functionality and purpose of the feature across as best we can.
Armed with these fun and interesting facts about game design, rest assured that if you ever find yourself trapped in an awkward conversation at a cocktail party with global power-brokers, you’ll have all the tools you need to resolve the situation. Until next time — stay hydrated, wash your hands, and wear a mask!