Tag: game design

Adapting your design doc for different readers

[NOTE: This was originally published on Medium, and has been reposted on this blog for posterity]

One major challenge that Game Designers face when working on design documents for new games, or for new features, is writing them with a particular audience in mind. I’m not talking about the target audience for the game itself, but about other stakeholders who will be reading the document: Artists, Engineers, Producers and publishers — not always in that order of priority.

In fact, it’s not unthinkable that you’ll find yourself writing the same design document over and over again multiple times: first, you might write something high-level aimed at informing or getting feedback or approval from a publisher, then elaborate on the details for the benefit of your Producer, and finally flesh out the design to make it implementation-ready for Engineers, Artists, and Designers.

Being able to write for each of these kinds of audience is a skill that can be learned over time, from document to document, based on the feedback and questions asked about the designs, guidance from more experienced Designers, and… well… a lot of practice.

That doesn’t mean you can’t get a head start, though. Read on for some tips and general best practices for writing with these different audiences in mind! Does this align with your own experience? Let me know in the comments!

---

Writing for Publishers

When the primary audience for your design document is a publisher, or the equivalent of a publisher — like a third party with a lot of influence on how your game is made/shared with the world — you need to approach the task a bit differently to writing for other members of your development team.

Generally speaking, you should be writing high-level designs that highlight the important points of the game as a whole. The writing should be to the point and concise, laid out in bullet-point form and with few (or no!) distractions, side-notes, or anything else that might hamper you in getting your concept across.

While your Designer brain (or heart) might want to pile on the details to make everything super clear and leave no room for any misunderstandings, in this case you should reign yourself in! The publisher normally doesn’t need to know about the ten potential edge cases for a particular mechanic and their every possible solution. They normally don’t want to read page after page of plot details, background lore, and detailed descriptions of every single object in the game.

Instead, their focus is directed at the overall, big-picture stuff:

• Does your design align with the interests of your game’s intended audience?
• (If platform owner) Does it cover the platform’s default requirements for feature X, Y, Z?

They’ll also want to know the risk factors of the design, especially when it comes to…

• Anything that touches on real-life cultures and groups
• Conforming to the privacy laws and regulations of every region where the game will be published
• How it could affect the game’s age rating: You don’t want a game targeted at young kids to be unexpectedly rated 12+ because you included too graphic violence or explicit language.

By thinking about and covering these aspects in the design document from the start, we can help ease the game’s approval process and reduce the chances of friction in the working relationship between the development studio and the publisher.

Depending on the publisher — and the project — they might want more detail or less detail, but that’s something you’ll learn based on the feedback they provide, the questions they ask, and any potential requests they make for additional information.

However, working with external partners on third-party IPs can drastically change the picture here, as there’s a high chance they’ll want a say in anything that directly relates to their IP, requiring more elaborate approval processes, more iterating on designs (and art!), more meetings, and more reviews.

Writing for Producers

To some extent, Producers tend to think along the same lines as Game Designers when it comes to reading and interpreting design documents. (Chances are, a given Producer was also a Game Designer at some point in their career!)

They will compare the design to other games with similar implementations; they’ll attempt to poke holes in the design to see where improvements can be made, and they will pull at loose threads to see if the design unravels.

However, their primary focus will be on the product side, and with, y’know… producing:

• How long will this design take to implement? Does it fit into the allotted time in the production schedule, or does the design need to be adjusted/cut down to fit? Will there be enough time for QA testing?
• What kinds of resources need to be allocated to make it happen? How many Engineers can be spared, how much is on the Art team’s plate already?
• How complex is the implementation? Is this something the team has had experience doing before, or is it something completely new, with unknown factors that could affect implementation time?
• What potential impact does the feature/mechanic have when it comes to player retention, player ratings, player’s willingness to spend money on the game, etc.?
• What are the risks involved in this design, and how can those risks potentially be mitigated/avoided? Can the design be simplified to eliminate some of these?

As Game Designers, we can also make the lives of Producers slightly easier by keeping the below considerations in mind while writing our design documents:

• We can divide the design into logical sections/versions that can be considered (and implemented) independently of one another. Version 1 of the design includes X, version 2 includes Y, and version 3 expands on X and Y to provide Z.
• We can offer several levels of granularity so the design can be read both from a high-level perspective and from a more in-depth one. Depending on the tools used for writing the designs, this can be achieved by: colour-coding different sections of the text; using spoilers or toggles that hide extreme details for someone just wanting to skim over the document; using sub-pages; or by having dedicated sections that summarise the most important parts of the design.
• We can consult Engineers/Artists up front about the feasibility of certain aspects of the design, including what kind of effort would likely be required to realise them, and either include these estimates in the design or adjust the design accordingly.
• We can think about the potential risks of the design up front and provide our own initial thoughts on how to mitigate them.

Writing for Engineers

When the time comes to prepare your design documents for implementation, you’ll be writing with Engineers as your target audience. That means you need to think like an Engineer, seeking more detail, more thought put into edge cases, and more specificity about the needs of the design:

• What kinds of support tools are needed for the design, if any?
• What kind of format should be used to store data for use by Designers?
• What are the potential edge cases of the design, and how should they be handled?
• If the design of a multiplayer game says a shop timer should reset once every day, should it reset at the same time for all players globally or regionally, or should each player have their own individual timer, independent of others?
• What happens if a player has reached max level and gains additional XP? Should the game cap the additional XP, or let the player hoard it for later?
• If a player claims a reward but then closes the game or restarts before the reward animation/FX are over, what should happen the next time the player starts the game?

Don’t be shy: Engineers are detail-oriented by nature, and not being clear enough about how something should work will prompt them to ask more questions anyway, potentially even delaying the implementation if an answer cannot be provided straight away.

Don’t rely on them to figure it all out on their own, however. If details aren’t treated in enough depth, Engineers might implement the design based on assumptions made off the back of your vague design, in a manner you didn’t intend, and you’ll either be stuck with that implementation (if there’s no time to redo), or you’ll have wasted precious Engineer time that could have been put to better use — not to mention the time it’ll then take to redo the work in the “correct” manner instead.

Writing for Artists

It’s perhaps rare that you’d write a design document aimed at Artists alone, but invariably there will be sections of your document that are more important to your Art team than others. In order to allow them to accurately scope the work needed to support the design, you need to be specific about what you ask for:

• Instead of saying “The player will be able to choose from various different cosmetic options”, you might be better of going a bit more in depth: “The player will be able to choose between 10–15 different types of hats to wear. The hats will all be animated, and the player’s choice will be on display both in the main menu lobby and in-game, visible to both themselves and other players.”

The Art team can then scope out how much time and effort it would take to prepare the assets, which they can then adjust for when planning other work. Maybe they’ll get back to you and say “Sorry, in the given time frame we’ll only be able to provide X hats, and only Y animated ones — the rest will be static.” Then you can update your design accordingly, or negotiate with Art team/producer on how to get the most out of their time.

If a character ability requires a special effect to convey to the player what the ability does, the Artists might need to know details such as:

• Should the ability button itself have an effect, or should there only be an effect on the character?
• Does the ability have an activation time, and if so does should effect play from the start, only kick in once he activation time is over, or be separated into multiple stages, e.g. build-up -> activation -> lingering effect?

Being specific is also important when it comes to UI: For example, the UI/UX designer will need to know that the design requires buttons X, Y and Z, that button X brings up a popup with a confirmation dialogue, that button Y should be disabled under certain circumstances, and that button Z should cause an explosion of confetti on the player’s screen.

• The design doesn’t need to state where all these buttons are down to the exact coordinates of each pixel, but creating a simple mock-up on your own (Designer art is the best art!) can help get the general idea across and ensure that what the Artists deliver is aligned with what’s in your head.

Since the Artists will find information about these things more helpful than, say, the handling of edge cases surrounding match-making or detailed rules for how leaderboard resets affect player points, it can be a good idea to separate out art-specific details of the design document into their own sub-sections so that all relevant information can be found in one place.

But… What about writing for Designers?

You may have noticed I didn’t mention anything up above about writing for other Designers. The reason for that is quite simple: As a Game Designer, you should not be writing design documents targeted specifically at other Designers! Like yourself, those other Designers should already be capable of reading and grokking the essence of a design regardless of whether it’s written for an external third-party publisher or the Engineering team.

Even if your design is still in its very early exploration stages, when you’re still writing the outline of the design and you find yourself in need of some input from fellow designers on how to proceed with the design — you’ll still not be writing the design with those other Designers in mind.

At that point, you’ll effectively be writing the document for yourself so that you can fully get to grips with the design, and while this might make it easy for likeminded Designers to grasp its essence, they should still not be thought of as the intended audience.

You should already at this point start to think about who is going to read the design document, and about how you can ensure that the message you want to convey comes across as clearly as possible.

---

Well, that’s all from me. If you found any of the above tips helpful or insightful in any way, or if you have your own thoughts or best practices for how to write game design documents targeted at specific audiences, feel free to leave a comment below!

Or, Stuff You Never Thought You Wanted to Know Until Just Now

[NOTE: This was originally published on Medium, and has been reposted on this blog for posterity]

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.

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!