Watch me break down a game idea into a game design bible (not doc)
Gamedev Dairy #92
I used to think that Pong would be the perfect game for a beginner game developer. Not because it turned out to be difficult, but simply because there are simpler games to create. For example, Snake is one such game.
It doesn't require a second player or “complicated” math for rebounds. Everything can be simplified, of course, but there's no need to bother with unnecessary thinking. Hence, the idea of making Snake the first game.
When you have little time for hobbies and can only spare an hour at most for skill development, there's no point in rushing it! A plan is needed, and not just any plan. It has to be detailed, broken down into even the most atomic tasks, sometimes to the extreme. The hour during the day that some of us find (or not) requires a seamless transition to deep work, with as little wondering, 'Where was I? What should I do now?'
But I don’t start with tasks. The first result of such preparation is what I call my game design document. However, I seem to perceive it slightly differently than most tutorials on the Internet, where it appears that the document is an excuse to mix a pitch deck, lore, storylines, dialogues, marketing plan, and some references to the game project 😉
Each of these aspects is essential but doesn't necessarily have to be part of a single document. For my own needs, I decided to reinvent the wheel.
Writing down a game’s vision and later breaking it down into the smallest tasks is an underestimated and crucial aspect of any project. Over 10 years in various IT projects have taught me this, as well as the fact that few people know how to do it 😉
For simple games like Snake or Pong, it will look easy because there are examples to make them seem simple and achievable 😊
I treat the following breakdown as if it were Newton's laws of physics. It's not a task list yet. It's the Bible for the game that's being created. The dependencies outlined in it are the reference point for everything: task breakdowns, quality assurance, etc.
Here it is:
SNAKE
BOARD
the board is defined by two parameters: width and height
when the snake reaches Y=0, it reappears at Y=MAX and vice versa
when the snake reaches X=0, it reappears at X=MAX and vice versa
FOOD
takes the form of a dot
appears in a random location
there is one food item at a time
after eating, a new one appears in a random location
does not appear where the snake is
does not appear in front of the snake
TIMING
For every 1T (tick), the snake moves one square in its current direction
1T = 3s (seconds)
POINTS (number of eaten dots)
SNAKE
The snake consists of at least one point.
The player controls can influence the snake's direction of movement
If the snake collides with its own body, the game ends.
If the snake eats a dot, it elongates by one square.
What do you think? Did I forget something?
You might’ve noticed that some aspects are bold (as in font, not as in beautiful 😉). These are highlighted because these can be easily parametrized in the future, as Sakurai-sensei taught.
Now, all that's left is to break it down into tasks.
But maybe next time. I'm still in the process of organizing my knowledge after the tutorial. I don't hide the fact that it's not the only reason, but that may be something to talk about another time (once I know how to diagnose it).
Recommendations
Here’s an interesting interview clip - Is It Still Possible To Be A Solo Dev?
Making strategies simpler - Thronefall (feat. Jonas Tyroller, already mentioned some issues ago).