WEBVTT

1
00:00:06.213 --> 00:00:09.975
Game Basics
SNG System Design and Reverse Design Documentation

2
00:00:28.049 --> 00:00:29.623
Hello

3
00:00:29.623 --> 00:00:33.488
I am Park Hyung-seon, and I will talk about SNG game system design

4
00:00:33.488 --> 00:00:36.067
I will explain SNG system design and how to write

5
00:00:36.067 --> 00:00:37.032
reverse design documents

6
00:00:38.428 --> 00:00:40.036
How to Write a System Design Document

7
00:00:40.036 --> 00:00:42.368
And the concept

8
00:00:42.368 --> 00:00:43.527
and tips for writing reverse design documents

9
00:00:44.294 --> 00:00:47.859
System Design Documentation

10
00:00:48.473 --> 00:00:50.790
The game development process includes

11
00:00:50.790 --> 00:00:54.699
planning, art resource creation, programming, and testing

12
00:00:54.699 --> 00:00:56.589
Each stage involves different roles

13
00:00:56.589 --> 00:00:59.431
depending on the job category

14
00:01:00.589 --> 00:01:02.396
The planning team writes design documents

15
00:01:02.396 --> 00:01:05.568
and passes them to the artists to create resources

16
00:01:05.568 --> 00:01:07.768
The programmers then handle the coding

17
00:01:07.768 --> 00:01:10.029
producing results for testing

18
00:01:10.029 --> 00:01:12.780
The planning team also collaborates on QA testing

19
00:01:12.780 --> 00:01:14.204
to fix bugs

20
00:01:15.719 --> 00:01:17.557
The job categories in game development include

21
00:01:17.557 --> 00:01:20.088
programmers, game designers, and art designers

22
00:01:20.088 --> 00:01:23.059
These are the three main categories

23
00:01:23.059 --> 00:01:26.238
Programmers are divided into client, server, and DBA roles

24
00:01:26.238 --> 00:01:30.288
Game designers focus on system design, content design, combat design

25
00:01:30.288 --> 00:01:34.498
level design, scenario design, and balance design

26
00:01:34.498 --> 00:01:37.891
Art designers handle concept art, animation, backgrounds,

27
00:01:37.891 --> 00:01:42.039
3D modeling, effects, UI, UX, and more

28
00:01:42.039 --> 00:01:44.029
Within a project, the planning tasks

29
00:01:44.029 --> 00:01:46.089
are not limited to a single type

30
00:01:46.089 --> 00:01:48.061
They can be subdivided into various fields

31
00:01:48.061 --> 00:01:49.716
and the same applies to programmers

32
00:01:49.716 --> 00:01:52.538
 and art designers

33
00:01:52.538 --> 00:01:56.029
The role of a game designer is to determine what to create

34
00:01:56.029 --> 00:01:59.887
before the game development begins

35
00:01:59.887 --> 00:02:03.370
They define the game system, content, balance, and storyline,

36
00:02:03.370 --> 00:02:05.617
among other elements

37
00:02:05.617 --> 00:02:08.256
Although there are many tasks,

38
00:02:08.256 --> 00:02:12.658
the ultimate goal is to clarify ambiguities

39
00:02:12.658 --> 00:02:15.646
The most important part of game development is

40
00:02:15.646 --> 00:02:18.318
providing enjoyment to the player

41
00:02:18.318 --> 00:02:20.999
This is called the "core fun"

42
00:02:20.999 --> 00:02:24.538
Running the game, entering the UI,

43
00:02:24.538 --> 00:02:27.584
and actively playing the game is referred to as

44
00:02:27.584 --> 00:02:29.939
gameplay

45
00:02:29.939 --> 00:02:32.536
The enjoyment experienced during gameplay

46
00:02:32.536 --> 00:02:34.569
is the core fun

47
00:02:34.569 --> 00:02:38.008
Many new games are created by benchmarking

48
00:02:38.008 --> 00:02:40.331
already successful games in the market

49
00:02:40.331 --> 00:02:42.078
to gather foundational data

50
00:02:42.078 --> 00:02:45.359
for new game development

51
00:02:45.359 --> 00:02:49.106
In the benchmarking process, analyzing the core fun

52
00:02:49.106 --> 00:02:54.427
is the most fundamental and essential analytical factor

53
00:02:54.427 --> 00:02:57.423
Let me explain core gameplay

54
00:02:58.898 --> 00:03:01.878
FPS, or First Person Shooting

55
00:03:01.878 --> 00:03:05.038
is a first-person perspective shooting game

56
00:03:05.038 --> 00:03:08.506
The core fun of FPS lies in shooting a gun (shoot)

57
00:03:08.506 --> 00:03:11.452
and killing an opponent (kill)

58
00:03:11.452 --> 00:03:13.838
It’s the fun of shooting and killing

59
00:03:13.838 --> 00:03:17.338
So, when thinking about how to define this core fun

60
00:03:17.338 --> 00:03:20.969
define this core fun

61
00:03:20.969 --> 00:03:25.734
it is important to first define the fun on a broad level

62
00:03:25.734 --> 00:03:29.518
and then break it down into smaller components

63
00:03:29.518 --> 00:03:32.540
For example, in FPS games, the fun of “shoot & kill”

64
00:03:32.540 --> 00:03:36.118
shooting a gun and killing the opponent

65
00:03:36.118 --> 00:03:40.560
can be broken down into pre-fire actions, suppressive actions, and firing

66
00:03:40.560 --> 00:03:43.694
You can further divide it this way

67
00:03:43.694 --> 00:03:45.658
and define it like this

68
00:03:45.658 --> 00:03:48.890
The fun of killing the opponent

69
00:03:48.890 --> 00:03:52.769
can be broken down into effects that occur when the opponent dies

70
00:03:52.769 --> 00:03:54.741
Thus, the actions in the shooting process

71
00:03:54.741 --> 00:03:57.614
and the outcomes when a kill occurs must be engaging

72
00:03:57.614 --> 00:03:59.258
for the game to be fun

73
00:03:59.258 --> 00:04:01.788
And if players achieve a high kill count

74
00:04:01.788 --> 00:04:03.603
they win the game

75
00:04:03.603 --> 00:04:05.538
For an FPS game to be enjoyable

76
00:04:05.538 --> 00:04:08.529
the shoot & kill mechanics must be fun

77
00:04:08.529 --> 00:04:10.663
When interpreting the concept of fun

78
00:04:10.663 --> 00:04:11.905
in that particular game genre,

79
00:04:11.905 --> 00:04:15.728
you need to define the actions players engage in most frequently

80
00:04:15.728 --> 00:04:18.560
then list and classify the factors

81
00:04:18.560 --> 00:04:21.978
that influence those actions

82
00:04:21.978 --> 00:04:24.082
This helps you map out the overall structure

83
00:04:24.082 --> 00:04:27.118
of the core fun

84
00:04:27.118 --> 00:04:31.589
Detailed components of FPS core fun

85
00:04:31.589 --> 00:04:34.551
The shooting process actions mentioned earlier

86
00:04:34.551 --> 00:04:36.994
and the effects upon a kill

87
00:04:36.994 --> 00:04:40.148
Breaking down pre-fire actions further

88
00:04:40.148 --> 00:04:42.279
we have predicting the opponent's actions, positioning,

89
00:04:42.279 --> 00:04:44.569
and securing visibility

90
00:04:44.569 --> 00:04:47.594
Suppressive actions can be divided into using secondary weapons

91
00:04:47.594 --> 00:04:49.080
Firing can be divided into

92
00:04:49.080 --> 00:04:51.809
shooting range and aiming position

93
00:04:51.809 --> 00:04:53.653
Effects upon death include

94
00:04:53.653 --> 00:04:56.489
blood splatter and screams

95
00:04:56.489 --> 00:04:58.752
Let’s analyze the core fun

96
00:05:00.178 --> 00:05:05.049
The fun of shooting and killing is the core fun of FPS games

97
00:05:05.049 --> 00:05:07.802
To maximize this fun,

98
00:05:07.802 --> 00:05:11.259
you analyze which components are arranged how

99
00:05:11.259 --> 00:05:13.208
and how they interact

100
00:05:13.208 --> 00:05:15.970
This is the approach for conducting the analysis

101
00:05:17.020 --> 00:05:20.453
Initially, express the core fun elements in simple

102
00:05:20.453 --> 00:05:22.669
broad concepts

103
00:05:22.669 --> 00:05:25.644
Then, practice breaking down each fun element,

104
00:05:25.644 --> 00:05:29.876
summarized as broad concepts, into smaller components

105
00:05:29.876 --> 00:05:33.629
Let’s look at a second example of core gameplay

106
00:05:33.629 --> 00:05:37.404
This is an example illustrating the components of a 1v1 fighting action game

107
00:05:37.404 --> 00:05:40.359
represented in a sample diagram

108
00:05:40.359 --> 00:05:45.657
For instance, you can categorize into three major factors

109
00:05:45.657 --> 00:05:49.480
the opponent's attack, my defense, and my attack

110
00:05:49.480 --> 00:05:52.129
These are the primary categories

111
00:05:52.129 --> 00:05:54.980
What kinds of opponent attacks could there be?

112
00:05:54.980 --> 00:06:00.089
Left attack, right attack, top-to-bottom, bottom-to-top

113
00:06:00.089 --> 00:06:03.179
jump attack left, jump attack right, dash attack

114
00:06:03.179 --> 00:06:05.540
These can be categorized accordingly

115
00:06:05.540 --> 00:06:10.404
My defense can include dodging left, dodging right, blocking,

116
00:06:10.404 --> 00:06:14.128
magic defense, countering attacks, and left/right positioning

117
00:06:14.128 --> 00:06:16.959
They can be divided in this way

118
00:06:16.959 --> 00:06:23.362
My attack can be subdivided into strikes, heavy attacks, scratches, misses

119
00:06:23.362 --> 00:06:28.609
blocks, combos, and finishing bonuses

120
00:06:28.609 --> 00:06:32.208
Various components contribute to the core fun

121
00:06:32.208 --> 00:06:34.794
and the offensive actions I can perform

122
00:06:34.794 --> 00:06:37.664
can be further broken down into upper body attacks, lower body attacks,

123
00:06:37.664 --> 00:06:40.045
and the cost of executing these actions

124
00:06:40.045 --> 00:06:42.777
These can be detailed and categorized this way

125
00:06:42.777 --> 00:06:45.664
Cost refers to aspects like the duration

126
00:06:45.664 --> 00:06:47.868
of preparation motions being long or short

127
00:06:47.868 --> 00:06:50.171
The defensive aspects can also be

128
00:06:50.171 --> 00:06:54.403
categorized into upper blocking, lower blocking, and crouched blocking

129
00:06:54.403 --> 00:06:59.138
Each can be segmented and analyzed

130
00:06:59.138 --> 00:07:02.038
To understand the game's system and structure

131
00:07:02.038 --> 00:07:05.009
you need to play the game extensively

132
00:07:05.009 --> 00:07:06.801
Whether it’s a mobile game, PC game,

133
00:07:06.801 --> 00:07:09.069
console game, or web game,

134
00:07:09.069 --> 00:07:11.594
the game you wish to analyze

135
00:07:11.594 --> 00:07:15.219
must be installed and played thoroughly

136
00:07:15.219 --> 00:07:19.799
If you were to set a standard for how much to play

137
00:07:19.799 --> 00:07:22.297
for mobile games at least,

138
00:07:22.297 --> 00:07:24.478
spending about 4 weeks

139
00:07:24.478 --> 00:07:26.379
with approximately 3 hours per day

140
00:07:26.379 --> 00:07:30.629
should suffice to understand the game to some extent

141
00:07:30.629 --> 00:07:33.453
However, when playing,

142
00:07:33.453 --> 00:07:37.238
play naturally as a regular user would

143
00:07:37.238 --> 00:07:39.646
but focus on understanding how each system operates

144
00:07:39.646 --> 00:07:41.506
To do so,

145
00:07:41.506 --> 00:07:44.190
take numerous gameplay screenshots

146
00:07:44.190 --> 00:07:46.278
and organize them into diagrams

147
00:07:46.278 --> 00:07:52.178
to map out the connection structure of each screen

148
00:07:52.178 --> 00:07:56.421
Here’s an example diagram for mapping the main game content

149
00:07:56.421 --> 00:07:59.438
and the flow of resource acquisition and consumption

150
00:07:59.438 --> 00:08:04.519
This example is based on a fictional MORPG game

151
00:08:04.519 --> 00:08:07.113
In the context of an MORPG game

152
00:08:07.113 --> 00:08:10.624
you can categorize content into combat, character progression, raid content

153
00:08:10.624 --> 00:08:14.499
guild features, real-time co-op, and PVP

154
00:08:14.499 --> 00:08:18.708
These can be divided into major categories

155
00:08:18.708 --> 00:08:22.611
For instance, in combat, story mode

156
00:08:22.611 --> 00:08:25.337
progresses through stages 1, 2, 3, and so on,

157
00:08:25.337 --> 00:08:27.894
with players clearing dozens or hundreds of stages

158
00:08:27.894 --> 00:08:29.338
Each stage may include

159
00:08:29.338 --> 00:08:31.819
multiple waves

160
00:08:31.819 --> 00:08:34.908
As players clear these story modes

161
00:08:34.908 --> 00:08:40.359
they acquire items like rubies, gold, weapons, EXP, mana potions, and upgrade stones

162
00:08:40.359 --> 00:08:44.108
Like this, various items and experience points can be obtained

163
00:08:44.108 --> 00:08:46.602
Then, map out where these acquired resources

164
00:08:46.602 --> 00:08:49.859
are consumed within the game

165
00:08:49.859 --> 00:08:53.334
For example, mana potions are used to restore mana

166
00:08:53.334 --> 00:08:57.929
skills are upgraded, stats are enhanced,

167
00:08:57.929 --> 00:09:01.533
and upgrade stones are used to enhance equipment

168
00:09:01.533 --> 00:09:06.148
And the experience points were allocated for overall level-ups

169
00:09:06.148 --> 00:09:07.945
The resources obtained in this way were used for

170
00:09:07.945 --> 00:09:12.852
character growth, synthesis, evolution, limit breaks, and awakening

171
00:09:12.852 --> 00:09:14.378
Additional raid content includes

172
00:09:14.378 --> 00:09:17.238
boss raids, special stages, and ranking battles

173
00:09:17.238 --> 00:09:21.082
Guild content includes guilds, guild points, and guild wars

174
00:09:21.082 --> 00:09:25.263
Real-time co-op and PVP include real-time co-op missions, time attack missions

175
00:09:25.263 --> 00:09:28.046
and real-time duels as part of the content

176
00:09:28.046 --> 00:09:31.195
By creating an overall structure diagram like this,

177
00:09:31.195 --> 00:09:33.468
you can analyze resource acquisition and consumption

178
00:09:33.468 --> 00:09:36.348
and examine the economic structure

179
00:09:36.348 --> 00:09:39.397
Next, let’s look at a structure diagram

180
00:09:39.397 --> 00:09:42.353
that connects each UI menu in a 1v1 fighting action game

181
00:09:42.353 --> 00:09:44.449
as an example

182
00:09:44.449 --> 00:09:48.237
When you enter the menu, you have the intro, tutorial battle screen

183
00:09:48.237 --> 00:09:51.105
intro video, and lobby start screen

184
00:09:51.105 --> 00:09:55.550
You can navigate through the map, battle, map, and battle screens

185
00:09:55.550 --> 00:09:56.970
in this order

186
00:09:56.970 --> 00:09:59.483
allowing you to encounter and battle bosses

187
00:09:59.483 --> 00:10:02.013
In the menu, you can also view rankings, achievements, characters, and more

188
00:10:02.013 --> 00:10:04.648
Various UI menus are available

189
00:10:04.648 --> 00:10:06.335
Now, let’s look at an example of a

190
00:10:06.335 --> 00:10:09.380
complete structure diagram of the game system

191
00:10:09.380 --> 00:10:12.129
A specific system in the game is represented in the UI

192
00:10:12.129 --> 00:10:14.608
allowing users to interact, take actions

193
00:10:14.608 --> 00:10:17.689
and observe the states and outcomes that result

194
00:10:17.689 --> 00:10:20.959
These are represented as states and drawn into a structure diagram

195
00:10:20.959 --> 00:10:22.926
A key point to note here is that

196
00:10:22.926 --> 00:10:26.349
instead of branching based on user decisions

197
00:10:26.349 --> 00:10:28.744
like yes or no

198
00:10:28.744 --> 00:10:32.316
the flow should follow the natural progression

199
00:10:32.316 --> 00:10:34.308
of gameplay and be illustrated accordingly

200
00:10:34.308 --> 00:10:37.268
In the game system, you can define the quest types,

201
00:10:37.268 --> 00:10:40.945
opening conditions, quest completion requirements, and reward types

202
00:10:40.945 --> 00:10:44.168
Here’s an example table showing the values of these rewards

203
00:10:44.168 --> 00:10:46.921
This can later serve as a data table

204
00:10:46.921 --> 00:10:49.779
For example, if you’re creating a quest

205
00:10:49.779 --> 00:10:54.564
you would define the quest number, category, title, and opening conditions

206
00:10:54.564 --> 00:10:57.176
along with the values for those conditions and description text

207
00:10:57.176 --> 00:10:58.378
These can all be created

208
00:10:58.378 --> 00:11:01.622
The reason for having a quest number is

209
00:11:01.622 --> 00:11:03.412
so that the client and server

210
00:11:03.412 --> 00:11:05.017
can recognize the unique value of the quest

211
00:11:05.017 --> 00:11:07.688
This ensures proper identification

212
00:11:07.688 --> 00:11:11.082
For example, if the quest number is 1001, the category might be combat

213
00:11:11.082 --> 00:11:12.933
If the quest requires clearing

214
00:11:12.933 --> 00:11:15.092
all stages in Episode 1,

215
00:11:15.092 --> 00:11:17.420
the description text would state: "Clear all stages

216
00:11:17.420 --> 00:11:19.448
 in Episode 1"

217
00:11:19.448 --> 00:11:22.300
In this case, the quest type could be "Clear all stages

218
00:11:22.300 --> 00:11:24.614
 in Episode N"

219
00:11:24.614 --> 00:11:27.144
If N is replaced with other values

220
00:11:27.144 --> 00:11:28.889
such as 1, 2, 3, 4, or 5,

221
00:11:28.889 --> 00:11:31.788
various quests can be created

222
00:11:31.788 --> 00:11:34.443
Additionally, there is an achievement metric,

223
00:11:34.443 --> 00:11:37.401
a reward type, and a reward quantity

224
00:11:37.401 --> 00:11:39.325
For instance, reward types could include

225
00:11:39.325 --> 00:11:41.398
crystals, friendship points

226
00:11:41.398 --> 00:11:44.178
or 2 to 4-star weapon tickets

227
00:11:44.178 --> 00:11:47.087
The reward quantity specifies

228
00:11:47.087 --> 00:11:49.813
how many of each type you can earn

229
00:11:49.813 --> 00:11:53.565
For example, if the quest is to clear stage N times

230
00:11:53.565 --> 00:11:55.869
and the achievement metric is 30,

231
00:11:55.869 --> 00:11:59.691
you must clear the stage 30 times

232
00:11:59.691 --> 00:12:01.999
to earn two 2 to 4-star

233
00:12:01.999 --> 00:12:04.069
weapon tickets

234
00:12:04.069 --> 00:12:07.991
Create a table for dialogue used in the game

235
00:12:07.991 --> 00:12:09.994
to track which characters appear,

236
00:12:09.994 --> 00:12:12.056
what dialogue they deliver,

237
00:12:12.056 --> 00:12:14.949
where the character appears when speaking,

238
00:12:14.949 --> 00:12:16.658
when they appear,

239
00:12:16.658 --> 00:12:18.392
whether the dialogue is part of a quest

240
00:12:18.392 --> 00:12:20.602
or used in another scenario

241
00:12:20.602 --> 00:12:22.919
This is an example of such a table

242
00:12:22.919 --> 00:12:24.930
For example, if the dialogue includes

243
00:12:24.930 --> 00:12:28.822
both a speaker and a listener

244
00:12:28.822 --> 00:12:30.655
various text scripts

245
00:12:30.655 --> 00:12:33.228
can be organized and displayed in a table

246
00:12:33.228 --> 00:12:35.084
Additionally, there are portraits

247
00:12:35.084 --> 00:12:37.674
and in games, 2D portraits are

248
00:12:37.674 --> 00:12:39.984
referred to as "portraits"

249
00:12:39.984 --> 00:12:43.401
Whether these portraits appear on the left or right

250
00:12:43.401 --> 00:12:46.389
should be organized in a table

251
00:12:46.389 --> 00:12:48.230
along with the corresponding dialogue

252
00:12:48.230 --> 00:12:50.518
The background can also be changed accordingly

253
00:12:50.518 --> 00:12:53.487
Additionally, if a quest number is entered here

254
00:12:53.487 --> 00:12:56.449
the dialogue will be linked to the quest

255
00:12:56.449 --> 00:12:59.803
After taking screenshots of all the game UI

256
00:12:59.803 --> 00:13:03.240
you can use tools like PowerPoint shapes, Photoshop, Figma, or Illustrator

257
00:13:03.240 --> 00:13:05.264
to create example game UIs

258
00:13:05.264 --> 00:13:08.178
This allows you to create sample UI

259
00:13:08.178 --> 00:13:09.612
For beginners,

260
00:13:09.612 --> 00:13:11.971
taking screenshots and directly drafting the plan

261
00:13:11.971 --> 00:13:14.579
is a quicker approach initially

262
00:13:14.579 --> 00:13:16.658
Once you gain some skill,

263
00:13:16.658 --> 00:13:19.003
you can use PowerPoint shapes

264
00:13:19.003 --> 00:13:21.664
to recreate UI examples

265
00:13:21.664 --> 00:13:24.629
If certain shapes are challenging,

266
00:13:24.629 --> 00:13:28.228
using PowerPoint's point editing feature

267
00:13:28.228 --> 00:13:31.759
can help you create more flexible shapes

268
00:13:31.759 --> 00:13:34.076
When using colors,

269
00:13:34.076 --> 00:13:36.262
try not to use more than three colors

270
00:13:36.262 --> 00:13:39.992
Colors like white, gray, dark gray, and light gray

271
00:13:39.992 --> 00:13:43.817
It is better to stick to neutral tones like these

272
00:13:43.817 --> 00:13:46.569
Next is numerical analysis and data collection

273
00:13:46.569 --> 00:13:49.750
There are two ways to analyze data

274
00:13:49.750 --> 00:13:52.622
The first is by actually playing the game

275
00:13:52.622 --> 00:13:55.402
and recording all the stats in Excel

276
00:13:55.402 --> 00:13:57.504
For example, if you want to know

277
00:13:57.504 --> 00:14:00.297
a character’s stats,

278
00:14:00.297 --> 00:14:02.650
you can note the attack power, HP, and defense stats

279
00:14:02.650 --> 00:14:06.061
displayed in the game UI whenever the character levels up

280
00:14:06.061 --> 00:14:07.768
Simply write them down

281
00:14:07.768 --> 00:14:11.360
If this process takes too long

282
00:14:11.360 --> 00:14:13.044
for popular games

283
00:14:13.044 --> 00:14:14.987
especially those from abroad

284
00:14:14.987 --> 00:14:17.529
like in North America or Europe

285
00:14:17.529 --> 00:14:19.867
you can search for them on Google for their wiki pages

286
00:14:19.867 --> 00:14:21.787
and you will be able to find a lot of data there

287
00:14:21.787 --> 00:14:24.253
For instance, search for the wiki page of a specific game

288
00:14:24.253 --> 00:14:25.829
in English,

289
00:14:25.829 --> 00:14:27.090
and you can find raw data

290
00:14:27.090 --> 00:14:29.265
uploaded by users

291
00:14:29.265 --> 00:14:31.292
Then reorganize it into a data table format

292
00:14:31.292 --> 00:14:34.649
and use it for reverse engineering

293
00:14:34.649 --> 00:14:38.492
For example, on a game’s wiki page,

294
00:14:38.492 --> 00:14:41.743
you might find stats for

295
00:14:41.743 --> 00:14:43.189
a single RPG character

296
00:14:43.189 --> 00:14:46.884
However, you can’t directly apply them to the game

297
00:14:46.884 --> 00:14:48.671
A game’s data table

298
00:14:48.671 --> 00:14:51.857
doesn’t just have data for a single character

299
00:14:51.857 --> 00:14:55.214
It includes data for 50, 100, or even 200 characters,

300
00:14:55.214 --> 00:14:57.525
all organized

301
00:14:57.525 --> 00:15:00.109
into one table

302
00:15:00.109 --> 00:15:03.336
Therefore, take the data for a single character from the left side

303
00:15:03.336 --> 00:15:07.308
and structure it on the right with details like character name, ID,

304
00:15:07.308 --> 00:15:10.995
rank, attributes, level, attack power, and HP

305
00:15:10.995 --> 00:15:13.989
This is how you should organize the data

306
00:15:13.989 --> 00:15:17.953
It’s fine if the table grows vertically,

307
00:15:17.953 --> 00:15:19.650
but avoid letting it expand too much horizontally

308
00:15:19.650 --> 00:15:21.556
Adding too many attributes

309
00:15:21.556 --> 00:15:22.838
should be avoided

310
00:15:22.838 --> 00:15:26.554
Attributes are referred to as columns in the data table

311
00:15:26.554 --> 00:15:28.350
In numerical analysis and data collection,

312
00:15:28.350 --> 00:15:31.499
here’s an example of data table columns

313
00:15:31.499 --> 00:15:36.158
For instance, in a battle SNG composite table

314
00:15:36.158 --> 00:15:38.300
you might see the following data

315
00:15:38.300 --> 00:15:41.014
Barbarians and Archers are listed by level

316
00:15:41.014 --> 00:15:42.798
with corresponding stats

317
00:15:42.798 --> 00:15:45.630
For example, the same Barbarian with ID 1001

318
00:15:45.630 --> 00:15:47.399
has multiple levels,

319
00:15:47.399 --> 00:15:51.079
and their attack power and HP increase with each level

320
00:15:51.079 --> 00:15:53.266
Additionally, there are stats like

321
00:15:53.266 --> 00:15:55.849
vision range and attack distance, and so on

322
00:15:55.849 --> 00:15:58.241
First, organize these into a table

323
00:15:58.241 --> 00:15:59.928
and then incorporate them into the game design document

324
00:15:59.928 --> 00:16:03.139
You need to create the character system based on this

325
00:16:03.139 --> 00:16:05.553
Character progression aspects

326
00:16:05.553 --> 00:16:08.979
can also be structured into a table

327
00:16:08.979 --> 00:16:11.040
Here is an example of a data table

328
00:16:11.040 --> 00:16:14.794
As mentioned earlier

329
00:16:14.794 --> 00:16:16.906
some tables only contain numbers

330
00:16:16.906 --> 00:16:19.087
but you need to define

331
00:16:19.087 --> 00:16:21.519
what those attributes mean

332
00:16:21.519 --> 00:16:25.185
For example, ID, unit level, HP

333
00:16:25.185 --> 00:16:27.951
you must specify what these represent

334
00:16:27.951 --> 00:16:31.150
in Korean, English, and with a description

335
00:16:31.150 --> 00:16:34.118
and include all three in your design document

336
00:16:34.118 --> 00:16:38.353
This is because what’s delivered to the programmer

337
00:16:38.353 --> 00:16:40.012
is the English column content

338
00:16:40.012 --> 00:16:43.599
It will be used as variable names in the code

339
00:16:43.599 --> 00:16:47.273
However, since designers might not understand it

340
00:16:47.273 --> 00:16:49.859
or when a new hire joins later

341
00:16:49.859 --> 00:16:51.859
handover could become difficult

342
00:16:51.859 --> 00:16:54.174
Therefore, you need the Korean labels, descriptions

343
00:16:54.174 --> 00:16:57.053
and details about the data values in the table

344
00:16:57.053 --> 00:16:59.649
to be well-organized

345
00:16:59.649 --> 00:17:03.427
If you’re analyzing level design

346
00:17:03.427 --> 00:17:06.831
you can organize information like which monsters appear

347
00:17:06.831 --> 00:17:09.108
on which stages and in what patterns

348
00:17:09.108 --> 00:17:11.009
This can be structured systematically

349
00:17:11.009 --> 00:17:14.598
Level design refers to elements like monster placements

350
00:17:14.598 --> 00:17:16.566
or other environmental arrangements

351
00:17:16.566 --> 00:17:20.089
and these can be recorded in Excel like this

352
00:17:20.089 --> 00:17:23.530
If you’re designing a puzzle game

353
00:17:23.530 --> 00:17:25.350
you need to understand the concept of fixed blocks

354
00:17:25.350 --> 00:17:27.308
versus random blocks

355
00:17:27.308 --> 00:17:29.032
For instance, puzzle games adjust difficulty by

356
00:17:29.032 --> 00:17:31.371
controlling the ratio of fixed to random blocks

357
00:17:31.371 --> 00:17:34.292
If 70% of the blocks are fixed

358
00:17:34.292 --> 00:17:37.639
and 30% are random

359
00:17:37.639 --> 00:17:38.995
this relatively high ratio of random blocks

360
00:17:38.995 --> 00:17:41.540
with it being 30%

361
00:17:41.540 --> 00:17:43.729
Players might find it easier

362
00:17:43.729 --> 00:17:45.819
to clear levels

363
00:17:45.819 --> 00:17:50.205
If they’re lucky with the random blocks

364
00:17:50.205 --> 00:17:51.994
they can clear levels

365
00:17:51.994 --> 00:17:53.699
 without using items

366
00:17:53.699 --> 00:17:55.081
However, if you want to make

367
00:17:55.081 --> 00:17:56.764
the game harder

368
00:17:56.764 --> 00:18:00.230
you could increase the fixed block ratio to 80%

369
00:18:00.230 --> 00:18:02.928
and decrease the random block ratio to 20%

370
00:18:02.928 --> 00:18:05.651
Adjusting randomness this way

371
00:18:05.651 --> 00:18:09.119
makes the game more challenging

372
00:18:09.119 --> 00:18:12.722
Now, let’s talk about reward and economy system analysis

373
00:18:12.722 --> 00:18:14.932
To analyze reward items

374
00:18:14.932 --> 00:18:17.169
and gacha items

375
00:18:17.169 --> 00:18:19.158
record the in-game currency rewards you receive

376
00:18:19.158 --> 00:18:20.929
such as those from quests

377
00:18:20.929 --> 00:18:22.731
stage clear bonuses

378
00:18:22.731 --> 00:18:23.930
and login rewards

379
00:18:23.930 --> 00:18:27.218
Track all sources of cash currency

380
00:18:27.218 --> 00:18:29.265
As you progress in the game

381
00:18:29.265 --> 00:18:30.678
record and organize where and how much

382
00:18:30.678 --> 00:18:32.708
game money and cash currency you earn overall

383
00:18:32.708 --> 00:18:34.868
based on playtime

384
00:18:35.542 --> 00:18:39.037
System Reverse Design Document

385
00:18:39.542 --> 00:18:41.720
Let me explain what a reverse design document is

386
00:18:41.720 --> 00:18:44.705
A reverse design document involves taking a launched,

387
00:18:44.705 --> 00:18:46.487
commercial game as a sample

388
00:18:46.487 --> 00:18:49.419
and creating a design document as if you were developing

389
00:18:49.419 --> 00:18:50.809
a new game or an update for it

390
00:18:50.809 --> 00:18:52.788
The purpose is to showcase your ability to plan

391
00:18:52.788 --> 00:18:55.144
new games or updates

392
00:18:55.144 --> 00:18:56.630
That is the goal

393
00:18:56.630 --> 00:18:59.898
For example, if you're creating a reverse design document for Anipang,

394
00:18:59.898 --> 00:19:02.759
imagine the game doesn't exist yet

395
00:19:02.759 --> 00:19:04.788
Think about how you would write a design document

396
00:19:04.788 --> 00:19:07.195
if you were developing Anipang for the first time

397
00:19:07.195 --> 00:19:08.970
From the perspective of an Anipang planner

398
00:19:08.970 --> 00:19:10.765
you would create a design document

399
00:19:10.765 --> 00:19:14.215
that could lead to its development

400
00:19:14.215 --> 00:19:16.423
So, how do you write a reverse design document?

401
00:19:16.423 --> 00:19:18.939
Many aspiring designers write reverse design documents

402
00:19:18.939 --> 00:19:21.324
by copying others’ reverse design documents

403
00:19:21.324 --> 00:19:23.967
This leads to some issues

404
00:19:23.967 --> 00:19:25.629
A poorly written reverse design document

405
00:19:25.629 --> 00:19:28.314
essentially carrying over bad practices

406
00:19:28.314 --> 00:19:31.019
For instance, writing details like class names or variable names

407
00:19:31.019 --> 00:19:32.819
that programmers should handle

408
00:19:32.819 --> 00:19:35.333
with excessive effort

409
00:19:35.333 --> 00:19:39.033
Or creating a document filled with flowcharts and text

410
00:19:39.033 --> 00:19:40.793
that focuses solely on intent

411
00:19:40.793 --> 00:19:42.387
while neglecting

412
00:19:42.387 --> 00:19:45.413
 development functionalities, etc

413
00:19:45.413 --> 00:19:47.355
Realistically, this is a limitation created because you don't get access

414
00:19:47.355 --> 00:19:50.254
to professional design documents

415
00:19:50.254 --> 00:19:53.393
Professional design documents are company secrets and kept private

416
00:19:53.393 --> 00:19:55.880
Common Mistakes in Writing Reverse Design Documents

417
00:19:55.880 --> 00:19:58.145
Here are nine common mistakes

418
00:19:58.145 --> 00:20:00.272
First, choosing a topic that’s too broad

419
00:20:00.272 --> 00:20:03.710
People try to write reverse design documents for the entire game

420
00:20:03.710 --> 00:20:06.502
For example, if you write "Combat System"

421
00:20:06.502 --> 00:20:07.918
it is prone to failure

422
00:20:07.918 --> 00:20:10.402
The combat system is highly detailed

423
00:20:10.402 --> 00:20:13.052
but without knowing that, they label it as just "Combat System"

424
00:20:13.052 --> 00:20:16.423
and quickly give up when overwhelmed

425
00:20:16.423 --> 00:20:18.819
They also fail to address specific details

426
00:20:18.819 --> 00:20:21.897
Second, misunderstanding combat system design documents

427
00:20:21.897 --> 00:20:24.630
as merely listing 100 skills

428
00:20:24.630 --> 00:20:26.824
This happens due to a lack of understanding

429
00:20:26.824 --> 00:20:29.898
between systems and content

430
00:20:29.898 --> 00:20:32.565
The difference is this

431
00:20:32.565 --> 00:20:35.031
systems are rules + UI,

432
00:20:35.031 --> 00:20:37.175
while content fills in the quantity

433
00:20:37.175 --> 00:20:39.668
For example, when we say "quest"

434
00:20:39.668 --> 00:20:42.019
the rules, UI, and play flow required to implement the quest

435
00:20:42.019 --> 00:20:44.868
constitute the system

436
00:20:44.868 --> 00:20:46.946
while creating hundreds of quests

437
00:20:46.946 --> 00:20:48.937
falls under content

438
00:20:48.937 --> 00:20:51.099
Regarding the combat system

439
00:20:51.099 --> 00:20:53.914
the rules and UI needed for combat implementation

440
00:20:53.914 --> 00:20:55.888
should exist

441
00:20:55.888 --> 00:20:59.526
but people instead look up skills on a wiki

442
00:20:59.526 --> 00:21:02.017
and list hundreds of them in PowerPoint

443
00:21:02.017 --> 00:21:04.630
essentially creating a content design document

444
00:21:04.630 --> 00:21:06.967
They then call it a system design document

445
00:21:06.967 --> 00:21:09.817
However, this is a content design document

446
00:21:09.817 --> 00:21:11.089
not a system design document,

447
00:21:11.089 --> 00:21:13.096
and, honestly, anyone can do this

448
00:21:13.096 --> 00:21:15.495
Thus, it doesn’t demonstrate the ability

449
00:21:15.495 --> 00:21:17.967
to design a combat system

450
00:21:17.967 --> 00:21:20.441
The flow and controls for starting and ending combat

451
00:21:20.441 --> 00:21:23.928
must be included for it to be a system design document

452
00:21:23.928 --> 00:21:26.471
Of the common mistakes in writing reverse design documents

453
00:21:26.471 --> 00:21:29.531
the third mistake is mixing up primary and secondary elements

454
00:21:29.531 --> 00:21:31.794
As I mentioned earlier, spending too much time naming variables

455
00:21:31.794 --> 00:21:32.926
classes,

456
00:21:32.926 --> 00:21:34.838
or image resources

457
00:21:34.838 --> 00:21:37.165
is a waste of time and resources

458
00:21:37.165 --> 00:21:38.937
This is unnecessary

459
00:21:38.937 --> 00:21:41.733
Also, writing excessively about planning intentions

460
00:21:41.733 --> 00:21:44.046
can result in a document filled only with intentions

461
00:21:44.046 --> 00:21:45.940
This often happens with university students

462
00:21:45.940 --> 00:21:47.597
or members of game development clubs

463
00:21:47.597 --> 00:21:49.393
who focus less on implementation

464
00:21:49.393 --> 00:21:53.380
and more on dreamy, conceptual ideas

465
00:21:53.380 --> 00:21:56.769
leading to overly verbose documents

466
00:21:56.769 --> 00:21:58.868
Instead of focusing on intentions

467
00:21:58.868 --> 00:22:03.027
define, structure, and detail the system for implementation

468
00:22:03.027 --> 00:22:07.896
Another issue from blindly copying old design documents

469
00:22:07.896 --> 00:22:10.660
and following outdated templates

470
00:22:10.660 --> 00:22:12.837
is that some reverse design documents consist only

471
00:22:12.837 --> 00:22:14.809
of flowcharts and text

472
00:22:14.809 --> 00:22:17.095
In the past, MORPG design documents

473
00:22:17.095 --> 00:22:18.430
were often written as Word files

474
00:22:18.430 --> 00:22:20.878
and were 100 to 200 pages long

475
00:22:20.878 --> 00:22:22.164
which was excessive

476
00:22:22.164 --> 00:22:25.365
Back then, there was little focus on UI, UX, or play flow

477
00:22:25.365 --> 00:22:27.145
Rather than focus on the visuals

478
00:22:27.145 --> 00:22:29.044
there was more emphasis on

479
00:22:29.044 --> 00:22:30.383
flowcharts and text

480
00:22:30.383 --> 00:22:32.899
Seeing those old documents

481
00:22:32.899 --> 00:22:35.027
leads to reverse design documents made entirely of flowcharts and text

482
00:22:35.027 --> 00:22:37.333
which are less readable today

483
00:22:37.333 --> 00:22:39.800
People find it easier to understand visuals first—videos, images

484
00:22:39.800 --> 00:22:42.135
and then text in that order

485
00:22:42.135 --> 00:22:45.128
Additionally, being overly passionate about a game

486
00:22:45.128 --> 00:22:46.838
without considering your audience

487
00:22:46.838 --> 00:22:49.001
simply thinking you know everything about the game

488
00:22:49.001 --> 00:22:51.581
and starting directly with the main content is problematic

489
00:22:51.581 --> 00:22:55.512
For example, it should be easy for a first-time reader to understand

490
00:22:55.512 --> 00:22:56.983
What is the guild system?

491
00:22:56.983 --> 00:22:58.769
What is the quest system?

492
00:22:58.769 --> 00:23:01.397
What is the Yo-Yo Dungeon system?

493
00:23:01.397 --> 00:23:03.799
These should be defined as "this is ~"

494
00:23:03.799 --> 00:23:06.204
Without such definitions, jumping straight into detailed rules

495
00:23:06.204 --> 00:23:07.531
and content makes it difficult for newcomers

496
00:23:07.531 --> 00:23:10.512
to understand

497
00:23:10.512 --> 00:23:14.284
Similarly, enthusiasts often make the mistake of

498
00:23:14.284 --> 00:23:16.739
using obscure terms unique to the game

499
00:23:16.739 --> 00:23:18.957
For instance, "BB skill is…"

500
00:23:18.957 --> 00:23:20.868
without explaining what a BB skill is

501
00:23:20.868 --> 00:23:22.937
is not a good practice

502
00:23:22.937 --> 00:23:26.758
Also, copying unrelated data tables

503
00:23:26.758 --> 00:23:30.531
and including them is highly discouraged

504
00:23:30.531 --> 00:23:33.720
If you're writing a design document for a quest system

505
00:23:33.720 --> 00:23:36.363
only tables related to the quest system are needed

506
00:23:36.363 --> 00:23:38.944
Including character tables

507
00:23:38.944 --> 00:23:42.046
or skill tables, for example, is unnecessary

508
00:23:42.046 --> 00:23:44.346
Another issue is misunderstanding small elements as systems

509
00:23:44.346 --> 00:23:47.284
and writing reverse design documents about them

510
00:23:47.284 --> 00:23:49.979
For instance, writing about something like the "swing skill"

511
00:23:49.979 --> 00:23:52.017
or creating a design document titled

512
00:23:52.017 --> 00:23:53.718
"Swing System" that’s 50 to 100 pages long

513
00:23:53.718 --> 00:23:56.025
or "Gem System" that's 50 to 100 pages long

514
00:23:56.025 --> 00:23:57.680
is an example of this

515
00:23:57.680 --> 00:24:01.343
These are not core systems that make up the game’s framework

516
00:24:01.343 --> 00:24:03.918
They are just minor details within the content

517
00:24:03.918 --> 00:24:06.006
Thus, basing your topic on this

518
00:24:06.006 --> 00:24:07.621
is not appropriate

519
00:24:07.621 --> 00:24:11.215
Let me explain the concept of a game design document's table of contents

520
00:24:11.215 --> 00:24:12.281
A game design document

521
00:24:12.281 --> 00:24:14.779
is a document created to develop a game

522
00:24:14.779 --> 00:24:16.689
Just like how blueprints are made to construct a building

523
00:24:16.689 --> 00:24:19.027
and the building is built based on those blueprints,

524
00:24:19.027 --> 00:24:20.738
a game design document serves as the blueprint

525
00:24:20.738 --> 00:24:22.720
for a game

526
00:24:22.720 --> 00:24:25.403
So, when is a design document needed?

527
00:24:25.403 --> 00:24:28.612
In small game development projects with fewer than five people

528
00:24:28.612 --> 00:24:31.928
development can proceed without a design document

529
00:24:31.928 --> 00:24:34.581
The programmer plans and codes directly

530
00:24:34.581 --> 00:24:36.220
However, for medium-sized or larger teams

531
00:24:36.220 --> 00:24:38.423
with 10 or more members

532
00:24:38.423 --> 00:24:41.711
developing a game without a design document

533
00:24:41.711 --> 00:24:43.066
carries significant risks

534
00:24:43.066 --> 00:24:44.688
This is because there’s no organization

535
00:24:44.688 --> 00:24:47.007
and everyone has different ideas

536
00:24:47.007 --> 00:24:49.977
The smaller the development scale, the less need there is for a design document,

537
00:24:49.977 --> 00:24:53.383
but once the team exceeds 10 members, organization becomes essential

538
00:24:53.383 --> 00:24:55.201
For medium to large projects

539
00:24:55.201 --> 00:24:57.660
a design document can help minimize errors

540
00:24:57.660 --> 00:25:00.135
and guide the team in the right direction

541
00:25:00.135 --> 00:25:01.935
So, how can we create an efficient and clear

542
00:25:01.935 --> 00:25:04.403
game design document?

543
00:25:04.403 --> 00:25:06.957
Here’s the table of contents for a game production proposal

544
00:25:06.957 --> 00:25:09.307
Game Overview, Game Concept, Worldbuilding

545
00:25:09.307 --> 00:25:11.799
Game Structure, Key Interfaces

546
00:25:11.799 --> 00:25:14.902
Core Gameplay Elements, Production Schedule

547
00:25:14.902 --> 00:25:17.116
Required Personnel, and so on

548
00:25:17.116 --> 00:25:20.581
Setting up the overall table of contents is extremely important

549
00:25:20.581 --> 00:25:22.219
because if you skip outlining

550
00:25:22.219 --> 00:25:24.185
and jump straight into writing the document

551
00:25:24.185 --> 00:25:25.534
you may not know how to organize the content

552
00:25:25.534 --> 00:25:27.333
and without clear criteria

553
00:25:27.333 --> 00:25:29.858
the information could become jumbled

554
00:25:29.858 --> 00:25:31.847
or redundant content might appear everywhere

555
00:25:31.847 --> 00:25:34.056
This can lead to a worst-case scenario

556
00:25:34.056 --> 00:25:36.455
The table of contents for the entire game design document

557
00:25:36.455 --> 00:25:38.650
should be divided by game systems

558
00:25:38.650 --> 00:25:41.838
and structured into main headings, subheadings, and sub-subheadings

559
00:25:43.571 --> 00:25:47.363
For example, if "Combat System" is the main heading

560
00:25:47.363 --> 00:25:48.677
the main heading, subheading, and sub-subheading

561
00:25:48.677 --> 00:25:51.333
could be written like this:

562
00:25:51.333 --> 00:25:53.177
Main Heading: Combat System

563
00:25:53.177 --> 00:25:56.145
Subheading: Combat Rules

564
00:25:56.145 --> 00:25:59.747
Sub-subheadings: Damage Formula, Turn Rules, Attribute Definitions

565
00:25:59.747 --> 00:26:02.215
and Damage Handling by Attribute

566
00:26:02.215 --> 00:26:04.331
Separate the table of contents into large, medium, and small categories

567
00:26:04.331 --> 00:26:07.848
to maintain a hierarchical structure

568
00:26:07.848 --> 00:26:09.451
Here’s how to divide the table of contents

569
00:26:09.451 --> 00:26:12.175
for game systems

570
00:26:12.175 --> 00:26:14.663
Quests, Character Growth, Combat System

571
00:26:14.663 --> 00:26:18.403
Inventory, Special Dungeons, and Guilds are examples of headings

572
00:26:18.403 --> 00:26:20.944
Dividing it by game systems

573
00:26:20.944 --> 00:26:23.937
creates a clear structure

574
00:26:23.937 --> 00:26:25.773
The reason for this division

575
00:26:25.773 --> 00:26:28.957
is that in software development, client developers

576
00:26:28.957 --> 00:26:30.352
often work on one system

577
00:26:30.352 --> 00:26:32.918
or multiple related systems

578
00:26:32.918 --> 00:26:34.630
For a developer to work efficiently

579
00:26:34.630 --> 00:26:36.898
features should be organized by system,

580
00:26:36.898 --> 00:26:39.769
making it easier and more effective to develop

581
00:26:39.769 --> 00:26:42.516
It’s less efficient for one developer to handle 50% of the guild system

582
00:26:42.516 --> 00:26:44.868
and 50% of the quest system

583
00:26:44.868 --> 00:26:47.753
than for one developer to fully handle the guild system

584
00:26:47.753 --> 00:26:49.253
and another to fully handle the quest system

585
00:26:49.253 --> 00:26:50.700
This approach

586
00:26:50.700 --> 00:26:52.333
is much more efficient

587
00:26:52.333 --> 00:26:55.284
Therefore, there should be separate design documents

588
00:26:55.284 --> 00:26:57.244
for the guild and quest systems

589
00:26:57.244 --> 00:26:59.494
When creating the table of contents, keep the following in mind

590
00:26:59.494 --> 00:27:02.155
If the headings are too broad

591
00:27:02.155 --> 00:27:04.165
it will be hard to write the content

592
00:27:04.165 --> 00:27:08.205
On the other hand, headings that are too specific are also problematic

593
00:27:08.205 --> 00:27:09.831
For example, "Character System"

594
00:27:09.831 --> 00:27:11.716
is too broad of a heading

595
00:27:11.716 --> 00:27:13.264
to be appropriate

596
00:27:13.264 --> 00:27:15.821
It would mix up various aspects of characters

597
00:27:15.821 --> 00:27:17.799
making it unclear what to write

598
00:27:17.799 --> 00:27:20.363
You should break it down further

599
00:27:20.363 --> 00:27:23.261
For example, divide it into Character Roles, Character Stats,

600
00:27:23.261 --> 00:27:25.928
and Character Growth

601
00:27:25.928 --> 00:27:29.680
Similarly, headings like "Gem System" or "Swing Skill System"

602
00:27:29.680 --> 00:27:32.210
that focus on one specific item or skill

603
00:27:32.210 --> 00:27:34.957
should not be considered system design headings

604
00:27:34.957 --> 00:27:37.084
These are too narrow in scope

605
00:27:37.084 --> 00:27:38.373
and are not appropriate

606
00:27:38.373 --> 00:27:40.196
For example, "Item Enhancement"

607
00:27:40.196 --> 00:27:42.650
where you use the same items to level up

608
00:27:42.650 --> 00:27:44.705
or strengthen using gems

609
00:27:44.705 --> 00:27:46.185
is not a "Gem System"

610
00:27:46.185 --> 00:27:49.215
Here are some tips for structuring your table of contents

611
00:27:49.215 --> 00:27:51.373
Avoid "Character System"

612
00:27:51.373 --> 00:27:53.310
Instead, use "Character Growth System" or "Character Stats"

613
00:27:53.310 --> 00:27:54.858
You should set it like this

614
00:27:54.858 --> 00:27:56.462
Avoid "Gem System"

615
00:27:56.462 --> 00:27:58.977
Use "Inventory System" or "Mailbox System" instead

616
00:27:58.977 --> 00:28:02.205
Let me explain an example table of contents for an RPG reverse design document

617
00:28:02.205 --> 00:28:04.244
For MORPG games

618
00:28:04.244 --> 00:28:06.514
you can divide into sections such as Game Introduction, Menu Structure, Currency Types

619
00:28:06.514 --> 00:28:08.799
Experience Definition, Item Type Definition

620
00:28:08.799 --> 00:28:10.204
Loading Screen, Lobby Screen

621
00:28:10.204 --> 00:28:12.997
Character Classes and Stats, Character Information

622
00:28:12.997 --> 00:28:16.680
Character Growth Level-Up, Character Advancement, Character Acquisition

623
00:28:16.680 --> 00:28:20.640
Equipment Definition and Stats, Equipment Equipping, Equipment Enhancement, Combat Overview

624
00:28:20.640 --> 00:28:25.700
Skills, Status Effects, Scenario Gameplay, PVP, Dungeon Challenges

625
00:28:25.700 --> 00:28:27.829
Infinite Tower, Raids, Social Features,

626
00:28:27.829 --> 00:28:29.680
Guild, Mailbox, and UI Types

627
00:28:29.680 --> 00:28:32.135
Attendance Check Events, Storage, Inventory, World Map Structure

628
00:28:32.135 --> 00:28:33.680
and so on

629
00:28:33.680 --> 00:28:37.373
This essentially outlines the entire structure of an RPG game

630
00:28:37.373 --> 00:28:39.403
Let’s break down the combat system further

631
00:28:39.403 --> 00:28:41.581
Previously, we touched on combat briefly

632
00:28:41.581 --> 00:28:44.260
but combat design is often detailed enough to require

633
00:28:44.260 --> 00:28:46.462
a separate combat designer

634
00:28:46.462 --> 00:28:50.028
The overarching section is Combat Overview

635
00:28:50.028 --> 00:28:52.333
which explains how combat works

636
00:28:52.333 --> 00:28:54.132
It includes Combat Gameplay, Combat Controls

637
00:28:54.132 --> 00:28:56.324
and the start and end of a combat session

638
00:28:56.324 --> 00:28:59.355
You would also cover Combat Rules, Damage Formulas, or Turn Rules

639
00:28:59.355 --> 00:29:01.254
as well as Basic Attack Damage Calculation

640
00:29:01.254 --> 00:29:03.717
Attributes, Affinities, Status Effects, and Crowd-Control Skills

641
00:29:03.717 --> 00:29:06.868
can all be broken down as well

642
00:29:06.868 --> 00:29:09.006
Organize Combat Modes, World Map

643
00:29:09.006 --> 00:29:10.621
Story Mode, Challenge Dungeon, Infinite Tower

644
00:29:10.621 --> 00:29:12.730
and divide them into these subcategories

645
00:29:12.730 --> 00:29:14.690
Additionally, you can have Raid Event Dungeons, Skills

646
00:29:14.690 --> 00:29:17.403
Monster Type Classification, and Monster AI

647
00:29:17.403 --> 00:29:18.720
as further breakdowns

648
00:29:18.720 --> 00:29:21.680
If you plan to host in-game events

649
00:29:21.680 --> 00:29:25.116
you should outline the Event Purpose, Event Conditions, and Event Participation Methods

650
00:29:25.116 --> 00:29:27.650
You’d also detail Event Pages, In-Game Banners and Text

651
00:29:27.650 --> 00:29:30.220
Web Page Banners and Text, Duplicate Event Handling,

652
00:29:30.220 --> 00:29:32.868
Participant Management, and Expected Event Outcomes

653
00:29:32.868 --> 00:29:34.274
These can all be divided into sections

654
00:29:34.274 --> 00:29:36.601
If you’re designing a Stage Puzzle Game

655
00:29:36.601 --> 00:29:39.695
you can divide it into Game Overview, Gameplay, Core Gameplay Rules

656
00:29:39.695 --> 00:29:42.769
Puzzle Block Types, Regular Item Types, Premium Item Types

657
00:29:43.838 --> 00:29:47.917
Game Modes (Mode A, Mode B), Stage Composition

658
00:29:47.917 --> 00:29:49.728
Currency Types Explanation, Premium Shop

659
00:29:49.728 --> 00:29:51.868
and Social Features, for example

660
00:29:51.868 --> 00:29:54.185
If you’re designing a Character Collection SNG game,

661
00:29:54.185 --> 00:29:57.890
you’d include sections for Loading Screen, Gameplay Screen, Shop Features

662
00:29:57.890 --> 00:30:00.429
Construction, Movement, Sales, Information Checking, and Egg Hatching

663
00:30:00.429 --> 00:30:03.126
Feed Production, Growth, Breeding, and Harvesting

664
00:30:03.126 --> 00:30:06.262
Habitat Movement, Sales, Nickname Changes

665
00:30:06.262 --> 00:30:08.551
Monthly Rank System, Event Triggers

666
00:30:08.551 --> 00:30:11.185
Quests, Social Activities, and Community Features

667
00:30:11.185 --> 00:30:12.930
It would also include Regular Events, NPCs, Notification Messages

668
00:30:12.930 --> 00:30:15.848
Sound Design, and Tutorials

669
00:30:16.574 --> 00:30:20.485
Writing a Reverse Design Document for Systems

670
00:30:20.485 --> 00:30:21.862
Reverse design documents for systems

671
00:30:21.862 --> 00:30:23.284
involve defining, structuring, and detailing

672
00:30:23.284 --> 00:30:26.432
Let me explain the concept and examples of game systems

673
00:30:26.432 --> 00:30:29.112
Combat Systems, Stage Structures, Friend Social Systems

674
00:30:29.112 --> 00:30:32.036
Enhancement Systems, Character Stats and Growth Systems

675
00:30:32.036 --> 00:30:35.551
the entire game is composed of various systems

676
00:30:35.551 --> 00:30:38.284
Game system design involves planning the game UI

677
00:30:38.284 --> 00:30:40.759
and the game rules

678
00:30:40.759 --> 00:30:43.511
Content design, on the other hand, comes after establishing this framework

679
00:30:43.511 --> 00:30:45.195
and involves filling in the details

680
00:30:45.195 --> 00:30:48.967
Game rule designs are integrated into pre-drawn UI

681
00:30:48.967 --> 00:30:52.314
followed by defining, structuring, and detailing the system

682
00:30:52.314 --> 00:30:54.858
Now let’s talk about definitions

683
00:30:54.858 --> 00:30:57.179
The definition briefly explains what the system is

684
00:30:57.179 --> 00:31:00.294
and helps users recognize its purpose

685
00:31:00.294 --> 00:31:02.340
This part doesn’t delve deeply into the system’s details

686
00:31:02.340 --> 00:31:03.918
but gives just enough information for recognition

687
00:31:03.918 --> 00:31:06.611
It should be concise and straightforward

688
00:31:06.611 --> 00:31:11.215
Here’s an example image of the definition section in a reverse design document

689
00:31:11.215 --> 00:31:14.098
For instance, if there’s a guild exploration feature

690
00:31:14.098 --> 00:31:16.294
it should explain where it starts and where it leads to

691
00:31:16.294 --> 00:31:19.736
It should also briefly describe the preparation and execution process

692
00:31:19.736 --> 00:31:21.997
using text and images

693
00:31:21.997 --> 00:31:25.126
You can start by defining the system’s concept

694
00:31:25.126 --> 00:31:27.272
and including actual in-game screenshots

695
00:31:27.272 --> 00:31:30.809
to visually demonstrate what the system is

696
00:31:30.809 --> 00:31:34.730
Include key sentences to define it further

697
00:31:34.730 --> 00:31:37.873
For simpler systems, a concept outline like this

698
00:31:37.873 --> 00:31:39.621
may suffice for the definition section

699
00:31:39.621 --> 00:31:41.165
This can complete the definition part

700
00:31:41.165 --> 00:31:44.465
However, for complex and large-scale systems

701
00:31:44.465 --> 00:31:46.690
concept outlines alone may not suffice

702
00:31:48.106 --> 00:31:51.331
In such cases, divide the system into Preparation, Execution, and Result phases

703
00:31:51.331 --> 00:31:53.165
into three phases

704
00:31:53.165 --> 00:31:55.413
and structure your documentation accordingly

705
00:31:55.413 --> 00:31:57.373
Now, let’s discuss the structure of a reverse design document

706
00:31:57.373 --> 00:31:59.662
When creating a reverse design document

707
00:31:59.662 --> 00:32:02.056
you might feel overwhelmed about where to start

708
00:32:02.056 --> 00:32:03.244
Here’s how to approach it

709
00:32:03.244 --> 00:32:07.017
For example, if you’re designing a quest system

710
00:32:07.017 --> 00:32:10.868
there could be quests initiated by NPCs

711
00:32:10.868 --> 00:32:14.759
and those where conditions are fulfilled directly via the UI

712
00:32:14.759 --> 00:32:17.492
In any case, every quest has a beginning and an end

713
00:32:17.492 --> 00:32:19.938
First, capture all the quest processes

714
00:32:19.938 --> 00:32:21.809
by taking screenshots

715
00:32:21.809 --> 00:32:26.314
If rewards are claimed through the quest UI

716
00:32:26.314 --> 00:32:29.185
note which button leads to which rewards

717
00:32:29.185 --> 00:32:33.440
Then, outline how gameplay fulfills the conditions

718
00:32:33.440 --> 00:32:34.591
and completes the quest

719
00:32:34.591 --> 00:32:37.462
Visualize this gameplay flow in your mind

720
00:32:37.462 --> 00:32:39.414
and list all the steps

721
00:32:39.414 --> 00:32:41.799
Then document them in sequence

722
00:32:41.799 --> 00:32:44.383
For example, specify what happens when a certain button is pressed

723
00:32:44.383 --> 00:32:46.789
or how the game progresses when another button is clicked

724
00:32:46.789 --> 00:32:47.947
Mention the resulting states

725
00:32:47.947 --> 00:32:50.075
Follow the gameplay flow

726
00:32:50.075 --> 00:32:52.046
to create screens in order

727
00:32:52.046 --> 00:32:54.898
and organize the associated features

728
00:32:54.898 --> 00:32:57.601
Capture game screenshots

729
00:32:57.601 --> 00:33:01.680
and highlight the areas where changes occur

730
00:33:01.680 --> 00:33:05.423
Additionally, you need to create a more detailed UI section

731
00:33:05.423 --> 00:33:06.988
Initially, after taking screenshots

732
00:33:06.988 --> 00:33:09.611
or creating UI screens

733
00:33:09.611 --> 00:33:11.359
when a button is pressed

734
00:33:11.359 --> 00:33:14.363
you may have outlined what happens and how the system functions

735
00:33:14.363 --> 00:33:16.271
At this stage, within the UI section

736
00:33:16.271 --> 00:33:20.215
pop-ups, filters, detailed exceptions

737
00:33:20.215 --> 00:33:22.799
or toast messages might have been omitted

738
00:33:22.799 --> 00:33:25.155
To organize this further

739
00:33:25.155 --> 00:33:28.581
review all UI elements again

740
00:33:28.581 --> 00:33:30.849
and assign numbers to each UI

741
00:33:30.849 --> 00:33:33.274
Specify which UIs exist and their depth levels

742
00:33:33.274 --> 00:33:35.531
You should detail the UI components once more like this

743
00:33:35.531 --> 00:33:38.215
However, be cautious not to include rules here

744
00:33:38.215 --> 00:33:40.118
Only include information related to the UI

745
00:33:40.118 --> 00:33:45.314
and explanations regarding its assembly

746
00:33:45.314 --> 00:33:47.246
Add game screenshot details, UI descriptions

747
00:33:47.246 --> 00:33:49.819
and additional UI explanations in this manner

748
00:33:49.819 --> 00:33:52.635
Lastly, for the detailed section

749
00:33:52.635 --> 00:33:55.343
it is essential to include these data tables

750
00:33:55.343 --> 00:33:57.987
and their definitions in the planning document

751
00:33:57.987 --> 00:33:59.314
Create a flowchart

752
00:33:59.314 --> 00:34:02.512
A flowchart demonstrates how a system operates

753
00:34:02.512 --> 00:34:03.819
and where branching occurs

754
00:34:03.819 --> 00:34:06.591
For example, it shows what happens when resources are insufficient

755
00:34:06.591 --> 00:34:08.621
and what happens when resources are sufficient

756
00:34:08.621 --> 00:34:10.748
When state values change

757
00:34:10.748 --> 00:34:13.738
the flowchart explains this to the programmer

758
00:34:13.738 --> 00:34:16.412
To do this, you draft it according to each branch

759
00:34:16.412 --> 00:34:19.491
In a reverse design document, the flowchart represents the workflow

760
00:34:19.491 --> 00:34:22.150
In the reverse design document, describe how the analyzed system

761
00:34:22.150 --> 00:34:24.560
flows and in what sequence

762
00:34:24.560 --> 00:34:28.530
Document how it branches depending on the state

763
00:34:28.530 --> 00:34:31.189
A flowchart includes the start, end,

764
00:34:31.189 --> 00:34:33.748
outcomes, and three key elements:

765
00:34:33.748 --> 00:34:35.124
Decision points are crucial

766
00:34:35.124 --> 00:34:37.699
They are represented by diamonds

767
00:34:37.699 --> 00:34:40.471
They show what happens under specific conditions

768
00:34:40.471 --> 00:34:42.679
These are expressed as 'yes' or 'no'

769
00:34:42.679 --> 00:34:44.402
Additionally, as mentioned earlier

770
00:34:44.402 --> 00:34:49.035
organize the numerical values into data tables

771
00:34:49.035 --> 00:34:51.063
For example, quest tables

772
00:34:51.063 --> 00:34:52.695
or enhancement and evolution tables

773
00:34:52.695 --> 00:34:55.026
should be tabulated if needed

774
00:34:55.026 --> 00:34:58.392
Let’s discuss UI planning

775
00:34:58.392 --> 00:35:01.398
UI refers to visible elements like layouts and text

776
00:35:01.398 --> 00:35:03.679
while UX pertains to user experience

777
00:35:03.679 --> 00:35:05.550
Start with the UI section

778
00:35:05.550 --> 00:35:08.045
by capturing screenshots

779
00:35:08.045 --> 00:35:11.006
then recreate it as closely as possible

780
00:35:11.006 --> 00:35:14.885
One thing to consider is, ensure button sizes and layout proportions

781
00:35:14.885 --> 00:35:18.857
resemble the actual game as much as possible

782
00:35:18.857 --> 00:35:22.010
For example, unit information, feeding systems

783
00:35:22.010 --> 00:35:24.295
or habitat relocation and return systems

784
00:35:24.295 --> 00:35:26.125
Organize them as text first

785
00:35:26.125 --> 00:35:30.570
and plan how to translate your ideas into UI

786
00:35:30.570 --> 00:35:33.253
Use tools like PowerPoint or Figma

787
00:35:33.253 --> 00:35:34.339
to create shapes

788
00:35:34.339 --> 00:35:36.699
and design buttons and layouts

789
00:35:36.699 --> 00:35:38.050
After defining the system

790
00:35:38.050 --> 00:35:39.296
just because numerical planning is done

791
00:35:39.296 --> 00:35:42.194
it doesn’t mean the system planner’s role is complete

792
00:35:42.194 --> 00:35:44.884
Information on how the system progresses

793
00:35:44.884 --> 00:35:46.849
must include UI and UX details

794
00:35:46.849 --> 00:35:49.540
for developers and designers to work effectively

795
00:35:49.540 --> 00:35:51.120
Thus, system planners must handle

796
00:35:51.120 --> 00:35:52.217
not only numerical planning

797
00:35:52.217 --> 00:35:54.867
but also UI and UX aspects

798
00:35:54.867 --> 00:35:58.818
Here’s an example of a reverse design document for UI and UX

799
00:35:58.818 --> 00:36:02.416
It details character enhancement and evolution

800
00:36:02.416 --> 00:36:04.769
replicating the original system

801
00:36:04.769 --> 00:36:08.085
On the right, UI elements are explained

802
00:36:08.085 --> 00:36:12.637
Additionally, you can isolate transparent character images

803
00:36:12.637 --> 00:36:14.501
by removing the background

804
00:36:14.501 --> 00:36:16.591
Using a site like remove.bg

805
00:36:16.591 --> 00:36:17.946
you can easily achieve this

806
00:36:19.075 --> 00:36:19.748
Thank you

807
00:36:19.867 --> 00:36:21.386
System Design Document
Game Development Process: Planning, resource creation, programming, testing
Role of Game Designers: Define game system, balance

808
00:36:21.386 --> 00:36:22.781
clarify ambiguous aspects
Core Fun
The enjoyment felt during gameplay
Core fun analysis process
Define user actions in sentences

809
00:36:22.781 --> 00:36:23.851
list and classify factors affecting actions
design an overall core fun structure

810
00:36:23.851 --> 00:36:25.398
Game System & Structure Analysis
Take numerous screenshots during gameplay
Organize screenshots into charts
create connection flow diagrams

811
00:36:25.398 --> 00:36:26.663
UI Design Tip
Use screenshots to draft design documents
Recreate UI examples using PowerPoint or design tools
Limit to three neutral colors

812
00:36:26.663 --> 00:36:27.841
Game Metrics Analysis
Record all metrics in Excel during gameplay
Use game wiki pages for reference

813
00:36:27.841 --> 00:36:29.126
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

814
00:36:29.126 --> 00:36:30.254
Common Mistakes
Choosing overly broad topics
Confusing system and content design
Overwriting intentions 
neglecting execution details

815
00:36:30.254 --> 00:36:31.252
Relying on flowcharts and text without visuals
Ignoring audience when writing
Using unexplained game terms & unrelated data tables

816
00:36:31.252 --> 00:36:31.851
Mistaking details for the system

817
00:36:31.851 --> 00:36:34.801
Game Design Document
Blueprint for game development
Game Design Document Content
Outline by dividing into systems
Structure with main, sub, and subsub

818
00:36:34.801 --> 00:36:35.871
Note not to make the content too broad or too detailed

819
00:36:35.871 --> 00:36:36.838
System Reverse Design Document
System definition section
Define the system concisely for recognition

820
00:36:36.838 --> 00:36:37.783
System Composition Section
Use screenshots to list all quest processes, including button functions, achievement conditions, and test completion

821
00:36:37.783 --> 00:36:38.752
System Detailed Section
Provide in-depth explanations of system using flowcharts
Include data tables that outline actual applied metrics for clarity

822
00:36:38.752 --> 00:36:39.772
UI Planning
UI: visible layouts, text, and various informational or design elements 
UX: user's experience and progression from interating with UI