Blog Post

5 Useful Facts About Game Design

• by Admin
• 5 Comments

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.

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…