Game Basics SNG System Design and Reverse Design Documentation
Hello
I am Park Hyung-seon, and I will talk about SNG game system design
I will explain SNG system design and how to write
reverse design documents
How to Write a System Design Document
And the concept
and tips for writing reverse design documents
System Design Documentation
The game development process includes
planning, art resource creation, programming, and testing
Each stage involves different roles
depending on the job category
The planning team writes design documents
and passes them to the artists to create resources
The programmers then handle the coding
producing results for testing
The planning team also collaborates on QA testing
to fix bugs
The job categories in game development include
programmers, game designers, and art designers
These are the three main categories
Programmers are divided into client, server, and DBA roles
Game designers focus on system design, content design, combat design
level design, scenario design, and balance design
Art designers handle concept art, animation, backgrounds,
3D modeling, effects, UI, UX, and more
Within a project, the planning tasks
are not limited to a single type
They can be subdivided into various fields
and the same applies to programmers
and art designers
The role of a game designer is to determine what to create
before the game development begins
They define the game system, content, balance, and storyline,
among other elements
Although there are many tasks,
the ultimate goal is to clarify ambiguities
The most important part of game development is
providing enjoyment to the player
This is called the "core fun"
Running the game, entering the UI,
and actively playing the game is referred to as
gameplay
The enjoyment experienced during gameplay
is the core fun
Many new games are created by benchmarking
already successful games in the market
to gather foundational data
for new game development
In the benchmarking process, analyzing the core fun
is the most fundamental and essential analytical factor
Let me explain core gameplay
FPS, or First Person Shooting
is a first-person perspective shooting game
The core fun of FPS lies in shooting a gun (shoot)
and killing an opponent (kill)
It’s the fun of shooting and killing
So, when thinking about how to define this core fun
define this core fun
it is important to first define the fun on a broad level
and then break it down into smaller components
For example, in FPS games, the fun of “shoot & kill”
shooting a gun and killing the opponent
can be broken down into pre-fire actions, suppressive actions, and firing
You can further divide it this way
and define it like this
The fun of killing the opponent
can be broken down into effects that occur when the opponent dies
Thus, the actions in the shooting process
and the outcomes when a kill occurs must be engaging
for the game to be fun
And if players achieve a high kill count
they win the game
For an FPS game to be enjoyable
the shoot & kill mechanics must be fun
When interpreting the concept of fun
in that particular game genre,
you need to define the actions players engage in most frequently
then list and classify the factors
that influence those actions
This helps you map out the overall structure
of the core fun
Detailed components of FPS core fun
The shooting process actions mentioned earlier
and the effects upon a kill
Breaking down pre-fire actions further
we have predicting the opponent's actions, positioning,
and securing visibility
Suppressive actions can be divided into using secondary weapons
Firing can be divided into
shooting range and aiming position
Effects upon death include
blood splatter and screams
Let’s analyze the core fun
The fun of shooting and killing is the core fun of FPS games
To maximize this fun,
you analyze which components are arranged how
and how they interact
This is the approach for conducting the analysis
Initially, express the core fun elements in simple
broad concepts
Then, practice breaking down each fun element,
summarized as broad concepts, into smaller components
Let’s look at a second example of core gameplay
This is an example illustrating the components of a 1v1 fighting action game
represented in a sample diagram
For instance, you can categorize into three major factors
the opponent's attack, my defense, and my attack
These are the primary categories
What kinds of opponent attacks could there be?
Left attack, right attack, top-to-bottom, bottom-to-top
jump attack left, jump attack right, dash attack
These can be categorized accordingly
My defense can include dodging left, dodging right, blocking,
magic defense, countering attacks, and left/right positioning
They can be divided in this way
My attack can be subdivided into strikes, heavy attacks, scratches, misses
blocks, combos, and finishing bonuses
Various components contribute to the core fun
and the offensive actions I can perform
can be further broken down into upper body attacks, lower body attacks,
and the cost of executing these actions
These can be detailed and categorized this way
Cost refers to aspects like the duration
of preparation motions being long or short
The defensive aspects can also be
categorized into upper blocking, lower blocking, and crouched blocking
Each can be segmented and analyzed
To understand the game's system and structure
you need to play the game extensively
Whether it’s a mobile game, PC game,
console game, or web game,
the game you wish to analyze
must be installed and played thoroughly
If you were to set a standard for how much to play
for mobile games at least,
spending about 4 weeks
with approximately 3 hours per day
should suffice to understand the game to some extent
However, when playing,
play naturally as a regular user would
but focus on understanding how each system operates
To do so,
take numerous gameplay screenshots
and organize them into diagrams
to map out the connection structure of each screen
Here’s an example diagram for mapping the main game content
and the flow of resource acquisition and consumption
This example is based on a fictional MORPG game
In the context of an MORPG game
you can categorize content into combat, character progression, raid content
guild features, real-time co-op, and PVP
These can be divided into major categories
For instance, in combat, story mode
progresses through stages 1, 2, 3, and so on,
with players clearing dozens or hundreds of stages
Each stage may include
multiple waves
As players clear these story modes
they acquire items like rubies, gold, weapons, EXP, mana potions, and upgrade stones
Like this, various items and experience points can be obtained
Then, map out where these acquired resources
are consumed within the game
For example, mana potions are used to restore mana
skills are upgraded, stats are enhanced,
and upgrade stones are used to enhance equipment
And the experience points were allocated for overall level-ups
The resources obtained in this way were used for
character growth, synthesis, evolution, limit breaks, and awakening
Additional raid content includes
boss raids, special stages, and ranking battles
Guild content includes guilds, guild points, and guild wars
Real-time co-op and PVP include real-time co-op missions, time attack missions
and real-time duels as part of the content
By creating an overall structure diagram like this,
you can analyze resource acquisition and consumption
and examine the economic structure
Next, let’s look at a structure diagram
that connects each UI menu in a 1v1 fighting action game
as an example
When you enter the menu, you have the intro, tutorial battle screen
intro video, and lobby start screen
You can navigate through the map, battle, map, and battle screens
in this order
allowing you to encounter and battle bosses
In the menu, you can also view rankings, achievements, characters, and more
Various UI menus are available
Now, let’s look at an example of a
complete structure diagram of the game system
A specific system in the game is represented in the UI
allowing users to interact, take actions
and observe the states and outcomes that result
These are represented as states and drawn into a structure diagram
A key point to note here is that
instead of branching based on user decisions
like yes or no
the flow should follow the natural progression
of gameplay and be illustrated accordingly
In the game system, you can define the quest types,
opening conditions, quest completion requirements, and reward types
Here’s an example table showing the values of these rewards
This can later serve as a data table
For example, if you’re creating a quest
you would define the quest number, category, title, and opening conditions
along with the values for those conditions and description text
These can all be created
The reason for having a quest number is
so that the client and server
can recognize the unique value of the quest
This ensures proper identification
For example, if the quest number is 1001, the category might be combat
If the quest requires clearing
all stages in Episode 1,
the description text would state: "Clear all stages
in Episode 1"
In this case, the quest type could be "Clear all stages
in Episode N"
If N is replaced with other values
such as 1, 2, 3, 4, or 5,
various quests can be created
Additionally, there is an achievement metric,
a reward type, and a reward quantity
For instance, reward types could include
crystals, friendship points
or 2 to 4-star weapon tickets
The reward quantity specifies
how many of each type you can earn
For example, if the quest is to clear stage N times
and the achievement metric is 30,
you must clear the stage 30 times
to earn two 2 to 4-star
weapon tickets
Create a table for dialogue used in the game
to track which characters appear,
what dialogue they deliver,
where the character appears when speaking,
when they appear,
whether the dialogue is part of a quest
or used in another scenario
This is an example of such a table
For example, if the dialogue includes
both a speaker and a listener
various text scripts
can be organized and displayed in a table
Additionally, there are portraits
and in games, 2D portraits are
referred to as "portraits"
Whether these portraits appear on the left or right
should be organized in a table
along with the corresponding dialogue
The background can also be changed accordingly
Additionally, if a quest number is entered here
the dialogue will be linked to the quest
After taking screenshots of all the game UI
you can use tools like PowerPoint shapes, Photoshop, Figma, or Illustrator
to create example game UIs
This allows you to create sample UI
For beginners,
taking screenshots and directly drafting the plan
is a quicker approach initially
Once you gain some skill,
you can use PowerPoint shapes
to recreate UI examples
If certain shapes are challenging,
using PowerPoint's point editing feature
can help you create more flexible shapes
When using colors,
try not to use more than three colors
Colors like white, gray, dark gray, and light gray
It is better to stick to neutral tones like these
Next is numerical analysis and data collection
There are two ways to analyze data
The first is by actually playing the game
and recording all the stats in Excel
For example, if you want to know
a character’s stats,
you can note the attack power, HP, and defense stats
displayed in the game UI whenever the character levels up
Simply write them down
If this process takes too long
for popular games
especially those from abroad
like in North America or Europe
you can search for them on Google for their wiki pages
and you will be able to find a lot of data there
For instance, search for the wiki page of a specific game
in English,
and you can find raw data
uploaded by users
Then reorganize it into a data table format
and use it for reverse engineering
For example, on a game’s wiki page,
you might find stats for
a single RPG character
However, you can’t directly apply them to the game
A game’s data table
doesn’t just have data for a single character
It includes data for 50, 100, or even 200 characters,
all organized
into one table
Therefore, take the data for a single character from the left side
and structure it on the right with details like character name, ID,
rank, attributes, level, attack power, and HP
This is how you should organize the data
It’s fine if the table grows vertically,
but avoid letting it expand too much horizontally
Adding too many attributes
should be avoided
Attributes are referred to as columns in the data table
In numerical analysis and data collection,
here’s an example of data table columns
For instance, in a battle SNG composite table
you might see the following data
Barbarians and Archers are listed by level
with corresponding stats
For example, the same Barbarian with ID 1001
has multiple levels,
and their attack power and HP increase with each level
Additionally, there are stats like
vision range and attack distance, and so on
First, organize these into a table
and then incorporate them into the game design document
You need to create the character system based on this
Character progression aspects
can also be structured into a table
Here is an example of a data table
As mentioned earlier
some tables only contain numbers
but you need to define
what those attributes mean
For example, ID, unit level, HP
you must specify what these represent
in Korean, English, and with a description
and include all three in your design document
This is because what’s delivered to the programmer
is the English column content
It will be used as variable names in the code
However, since designers might not understand it
or when a new hire joins later
handover could become difficult
Therefore, you need the Korean labels, descriptions
and details about the data values in the table
to be well-organized
If you’re analyzing level design
you can organize information like which monsters appear
on which stages and in what patterns
This can be structured systematically
Level design refers to elements like monster placements
or other environmental arrangements
and these can be recorded in Excel like this
If you’re designing a puzzle game
you need to understand the concept of fixed blocks
versus random blocks
For instance, puzzle games adjust difficulty by
controlling the ratio of fixed to random blocks
If 70% of the blocks are fixed
and 30% are random
this relatively high ratio of random blocks
with it being 30%
Players might find it easier
to clear levels
If they’re lucky with the random blocks
they can clear levels
without using items
However, if you want to make
the game harder
you could increase the fixed block ratio to 80%
and decrease the random block ratio to 20%
Adjusting randomness this way
makes the game more challenging
Now, let’s talk about reward and economy system analysis
To analyze reward items
and gacha items
record the in-game currency rewards you receive
such as those from quests
stage clear bonuses
and login rewards
Track all sources of cash currency
As you progress in the game
record and organize where and how much
game money and cash currency you earn overall
based on playtime
System Reverse Design Document
Let me explain what a reverse design document is
A reverse design document involves taking a launched,
commercial game as a sample
and creating a design document as if you were developing
a new game or an update for it
The purpose is to showcase your ability to plan
new games or updates
That is the goal
For example, if you're creating a reverse design document for Anipang,
imagine the game doesn't exist yet
Think about how you would write a design document
if you were developing Anipang for the first time
From the perspective of an Anipang planner
you would create a design document
that could lead to its development
So, how do you write a reverse design document?
Many aspiring designers write reverse design documents
by copying others’ reverse design documents
This leads to some issues
A poorly written reverse design document
essentially carrying over bad practices
For instance, writing details like class names or variable names
that programmers should handle
with excessive effort
Or creating a document filled with flowcharts and text
that focuses solely on intent
while neglecting
development functionalities, etc
Realistically, this is a limitation created because you don't get access
to professional design documents
Professional design documents are company secrets and kept private
Common Mistakes in Writing Reverse Design Documents
Here are nine common mistakes
First, choosing a topic that’s too broad
People try to write reverse design documents for the entire game
For example, if you write "Combat System"
it is prone to failure
The combat system is highly detailed
but without knowing that, they label it as just "Combat System"
and quickly give up when overwhelmed
They also fail to address specific details
Second, misunderstanding combat system design documents
as merely listing 100 skills
This happens due to a lack of understanding
between systems and content
The difference is this
systems are rules + UI,
while content fills in the quantity
For example, when we say "quest"
the rules, UI, and play flow required to implement the quest
constitute the system
while creating hundreds of quests
falls under content
Regarding the combat system
the rules and UI needed for combat implementation
should exist
but people instead look up skills on a wiki
and list hundreds of them in PowerPoint
essentially creating a content design document
They then call it a system design document
However, this is a content design document
not a system design document,
and, honestly, anyone can do this
Thus, it doesn’t demonstrate the ability
to design a combat system
The flow and controls for starting and ending combat
must be included for it to be a system design document
Of the common mistakes in writing reverse design documents
the third mistake is mixing up primary and secondary elements
As I mentioned earlier, spending too much time naming variables
classes,
or image resources
is a waste of time and resources
This is unnecessary
Also, writing excessively about planning intentions
can result in a document filled only with intentions
This often happens with university students
or members of game development clubs
who focus less on implementation
and more on dreamy, conceptual ideas
leading to overly verbose documents
Instead of focusing on intentions
define, structure, and detail the system for implementation
Another issue from blindly copying old design documents
and following outdated templates
is that some reverse design documents consist only
of flowcharts and text
In the past, MORPG design documents
were often written as Word files
and were 100 to 200 pages long
which was excessive
Back then, there was little focus on UI, UX, or play flow
Rather than focus on the visuals
there was more emphasis on
flowcharts and text
Seeing those old documents
leads to reverse design documents made entirely of flowcharts and text
which are less readable today
People find it easier to understand visuals first—videos, images
and then text in that order
Additionally, being overly passionate about a game
without considering your audience
simply thinking you know everything about the game
and starting directly with the main content is problematic
For example, it should be easy for a first-time reader to understand
What is the guild system?
What is the quest system?
What is the Yo-Yo Dungeon system?
These should be defined as "this is ~"
Without such definitions, jumping straight into detailed rules
and content makes it difficult for newcomers
to understand
Similarly, enthusiasts often make the mistake of
using obscure terms unique to the game
For instance, "BB skill is…"
without explaining what a BB skill is
is not a good practice
Also, copying unrelated data tables
and including them is highly discouraged
If you're writing a design document for a quest system
only tables related to the quest system are needed
Including character tables
or skill tables, for example, is unnecessary
Another issue is misunderstanding small elements as systems
and writing reverse design documents about them
For instance, writing about something like the "swing skill"
or creating a design document titled
"Swing System" that’s 50 to 100 pages long
or "Gem System" that's 50 to 100 pages long
is an example of this
These are not core systems that make up the game’s framework
They are just minor details within the content
Thus, basing your topic on this
is not appropriate
Let me explain the concept of a game design document's table of contents
A game design document
is a document created to develop a game
Just like how blueprints are made to construct a building
and the building is built based on those blueprints,
a game design document serves as the blueprint
for a game
So, when is a design document needed?
In small game development projects with fewer than five people
development can proceed without a design document
The programmer plans and codes directly
However, for medium-sized or larger teams
with 10 or more members
developing a game without a design document
carries significant risks
This is because there’s no organization
and everyone has different ideas
The smaller the development scale, the less need there is for a design document,
but once the team exceeds 10 members, organization becomes essential
For medium to large projects
a design document can help minimize errors
and guide the team in the right direction
So, how can we create an efficient and clear
game design document?
Here’s the table of contents for a game production proposal
Game Overview, Game Concept, Worldbuilding
Game Structure, Key Interfaces
Core Gameplay Elements, Production Schedule
Required Personnel, and so on
Setting up the overall table of contents is extremely important
because if you skip outlining
and jump straight into writing the document
you may not know how to organize the content
and without clear criteria
the information could become jumbled
or redundant content might appear everywhere
This can lead to a worst-case scenario
The table of contents for the entire game design document
should be divided by game systems
and structured into main headings, subheadings, and sub-subheadings
For example, if "Combat System" is the main heading
the main heading, subheading, and sub-subheading
could be written like this:
Main Heading: Combat System
Subheading: Combat Rules
Sub-subheadings: Damage Formula, Turn Rules, Attribute Definitions
and Damage Handling by Attribute
Separate the table of contents into large, medium, and small categories
to maintain a hierarchical structure
Here’s how to divide the table of contents
for game systems
Quests, Character Growth, Combat System
Inventory, Special Dungeons, and Guilds are examples of headings
Dividing it by game systems
creates a clear structure
The reason for this division
is that in software development, client developers
often work on one system
or multiple related systems
For a developer to work efficiently
features should be organized by system,
making it easier and more effective to develop
It’s less efficient for one developer to handle 50% of the guild system
and 50% of the quest system
than for one developer to fully handle the guild system
and another to fully handle the quest system
This approach
is much more efficient
Therefore, there should be separate design documents
for the guild and quest systems
When creating the table of contents, keep the following in mind
If the headings are too broad
it will be hard to write the content
On the other hand, headings that are too specific are also problematic
For example, "Character System"
is too broad of a heading
to be appropriate
It would mix up various aspects of characters
making it unclear what to write
You should break it down further
For example, divide it into Character Roles, Character Stats,
and Character Growth
Similarly, headings like "Gem System" or "Swing Skill System"
that focus on one specific item or skill
should not be considered system design headings
These are too narrow in scope
and are not appropriate
For example, "Item Enhancement"
where you use the same items to level up
or strengthen using gems
is not a "Gem System"
Here are some tips for structuring your table of contents
Avoid "Character System"
Instead, use "Character Growth System" or "Character Stats"
You should set it like this
Avoid "Gem System"
Use "Inventory System" or "Mailbox System" instead
Let me explain an example table of contents for an RPG reverse design document
For MORPG games
you can divide into sections such as Game Introduction, Menu Structure, Currency Types
Experience Definition, Item Type Definition
Loading Screen, Lobby Screen
Character Classes and Stats, Character Information
Character Growth Level-Up, Character Advancement, Character Acquisition
Equipment Definition and Stats, Equipment Equipping, Equipment Enhancement, Combat Overview
Skills, Status Effects, Scenario Gameplay, PVP, Dungeon Challenges
Infinite Tower, Raids, Social Features,
Guild, Mailbox, and UI Types
Attendance Check Events, Storage, Inventory, World Map Structure
and so on
This essentially outlines the entire structure of an RPG game
Let’s break down the combat system further
Previously, we touched on combat briefly
but combat design is often detailed enough to require
a separate combat designer
The overarching section is Combat Overview
which explains how combat works
It includes Combat Gameplay, Combat Controls
and the start and end of a combat session
You would also cover Combat Rules, Damage Formulas, or Turn Rules
as well as Basic Attack Damage Calculation
Attributes, Affinities, Status Effects, and Crowd-Control Skills
can all be broken down as well
Organize Combat Modes, World Map
Story Mode, Challenge Dungeon, Infinite Tower
and divide them into these subcategories
Additionally, you can have Raid Event Dungeons, Skills
Monster Type Classification, and Monster AI
as further breakdowns
If you plan to host in-game events
you should outline the Event Purpose, Event Conditions, and Event Participation Methods
You’d also detail Event Pages, In-Game Banners and Text
Web Page Banners and Text, Duplicate Event Handling,
Participant Management, and Expected Event Outcomes
These can all be divided into sections
If you’re designing a Stage Puzzle Game
you can divide it into Game Overview, Gameplay, Core Gameplay Rules
Puzzle Block Types, Regular Item Types, Premium Item Types
Game Modes (Mode A, Mode B), Stage Composition
Currency Types Explanation, Premium Shop
and Social Features, for example
If you’re designing a Character Collection SNG game,
you’d include sections for Loading Screen, Gameplay Screen, Shop Features
Construction, Movement, Sales, Information Checking, and Egg Hatching
Feed Production, Growth, Breeding, and Harvesting
Habitat Movement, Sales, Nickname Changes
Monthly Rank System, Event Triggers
Quests, Social Activities, and Community Features
It would also include Regular Events, NPCs, Notification Messages
Sound Design, and Tutorials
Writing a Reverse Design Document for Systems
Reverse design documents for systems
involve defining, structuring, and detailing
Let me explain the concept and examples of game systems
Combat Systems, Stage Structures, Friend Social Systems
Enhancement Systems, Character Stats and Growth Systems
the entire game is composed of various systems
Game system design involves planning the game UI
and the game rules
Content design, on the other hand, comes after establishing this framework
and involves filling in the details
Game rule designs are integrated into pre-drawn UI
followed by defining, structuring, and detailing the system
Now let’s talk about definitions
The definition briefly explains what the system is
and helps users recognize its purpose
This part doesn’t delve deeply into the system’s details
but gives just enough information for recognition
It should be concise and straightforward
Here’s an example image of the definition section in a reverse design document
For instance, if there’s a guild exploration feature
it should explain where it starts and where it leads to
It should also briefly describe the preparation and execution process
using text and images
You can start by defining the system’s concept
and including actual in-game screenshots
to visually demonstrate what the system is
Include key sentences to define it further
For simpler systems, a concept outline like this
may suffice for the definition section
This can complete the definition part
However, for complex and large-scale systems
concept outlines alone may not suffice
In such cases, divide the system into Preparation, Execution, and Result phases
into three phases
and structure your documentation accordingly
Now, let’s discuss the structure of a reverse design document
When creating a reverse design document
you might feel overwhelmed about where to start
Here’s how to approach it
For example, if you’re designing a quest system
there could be quests initiated by NPCs
and those where conditions are fulfilled directly via the UI
In any case, every quest has a beginning and an end
First, capture all the quest processes
by taking screenshots
If rewards are claimed through the quest UI
note which button leads to which rewards
Then, outline how gameplay fulfills the conditions
and completes the quest
Visualize this gameplay flow in your mind
and list all the steps
Then document them in sequence
For example, specify what happens when a certain button is pressed
or how the game progresses when another button is clicked
Mention the resulting states
Follow the gameplay flow
to create screens in order
and organize the associated features
Capture game screenshots
and highlight the areas where changes occur
Additionally, you need to create a more detailed UI section
Initially, after taking screenshots
or creating UI screens
when a button is pressed
you may have outlined what happens and how the system functions
At this stage, within the UI section
pop-ups, filters, detailed exceptions
or toast messages might have been omitted
To organize this further
review all UI elements again
and assign numbers to each UI
Specify which UIs exist and their depth levels
You should detail the UI components once more like this
However, be cautious not to include rules here
Only include information related to the UI
and explanations regarding its assembly
Add game screenshot details, UI descriptions
and additional UI explanations in this manner
Lastly, for the detailed section
it is essential to include these data tables
and their definitions in the planning document
Create a flowchart
A flowchart demonstrates how a system operates
and where branching occurs
For example, it shows what happens when resources are insufficient
and what happens when resources are sufficient
When state values change
the flowchart explains this to the programmer
To do this, you draft it according to each branch
In a reverse design document, the flowchart represents the workflow
In the reverse design document, describe how the analyzed system
flows and in what sequence
Document how it branches depending on the state
A flowchart includes the start, end,
outcomes, and three key elements:
Decision points are crucial
They are represented by diamonds
They show what happens under specific conditions
These are expressed as 'yes' or 'no'
Additionally, as mentioned earlier
organize the numerical values into data tables
For example, quest tables
or enhancement and evolution tables
should be tabulated if needed
Let’s discuss UI planning
UI refers to visible elements like layouts and text
while UX pertains to user experience
Start with the UI section
by capturing screenshots
then recreate it as closely as possible
One thing to consider is, ensure button sizes and layout proportions
resemble the actual game as much as possible
For example, unit information, feeding systems
or habitat relocation and return systems
Organize them as text first
and plan how to translate your ideas into UI
Use tools like PowerPoint or Figma
to create shapes
and design buttons and layouts
After defining the system
just because numerical planning is done
it doesn’t mean the system planner’s role is complete
Information on how the system progresses
must include UI and UX details
for developers and designers to work effectively
Thus, system planners must handle
not only numerical planning
but also UI and UX aspects
Here’s an example of a reverse design document for UI and UX
It details character enhancement and evolution
replicating the original system
On the right, UI elements are explained
Additionally, you can isolate transparent character images
by removing the background
Using a site like remove.bg
you can easily achieve this
Thank you
System Design Document Game Development Process: Planning, resource creation, programming, testing Role of Game Designers: Define game system, balance
clarify ambiguous aspects Core Fun The enjoyment felt during gameplay Core fun analysis process Define user actions in sentences
list and classify factors affecting actions design an overall core fun structure
Game System & Structure Analysis Take numerous screenshots during gameplay Organize screenshots into charts create connection flow diagrams
UI Design Tip Use screenshots to draft design documents Recreate UI examples using PowerPoint or design tools Limit to three neutral colors
Game Metrics Analysis Record all metrics in Excel during gameplay Use game wiki pages for reference
Reverse Design Document Choose a Game already in the market Mimic the creation of a new game Purpose is to showcase planning and update abilities
Common Mistakes Choosing overly broad topics Confusing system and content design Overwriting intentions neglecting execution details
Relying on flowcharts and text without visuals Ignoring audience when writing Using unexplained game terms & unrelated data tables
Mistaking details for the system
Game Design Document Blueprint for game development Game Design Document Content Outline by dividing into systems Structure with main, sub, and subsub
Note not to make the content too broad or too detailed
System Reverse Design Document System definition section Define the system concisely for recognition
System Composition Section Use screenshots to list all quest processes, including button functions, achievement conditions, and test completion
System Detailed Section Provide in-depth explanations of system using flowcharts Include data tables that outline actual applied metrics for clarity
UI Planning UI: visible layouts, text, and various informational or design elements UX: user's experience and progression from interating with UI