Creating My First Video Game: Part 1 – The Design Doc


I’m going to make a video game! And I’m going to write about my experience of doing so!

Creating video games has always been my dream. We’ve all heard the cliche of people drawing out Super Mario levels on graph paper when they were kids, but I guess it’s a cliche for a reason because I totally did that. Ever since I found out that games were made by real people and weren’t just these magical pictures on the TV that were sent from the heavens by some supernatural force, I wanted to be the guy that made them.

Unfortunately, life gets in the way sometimes, and as a result, I have absolutely no experience or skills required to create a video game. However, recent years have been kind to the untrained, and things like Game Maker and the community and documentation behind it make it easier than ever to jump in and get your feet wet. I’ve dabbled in some tutorials and I’ve got the basics of the basics (of the basics) down, so OBVIOUSLY I’M GOING TO START CREATING A GAME FROM SCRATCH ‘CAUSE I’M SO SMART!

I have no idea how to make a game, if it wasn’t clear, but life has taught me that you have to plan everything out first (not to mention I’ve heard the term “design doc” mentioned quite a few times), so I decided to create an outline of the game as the very first step. Everything here is obviously subject to change and should be updated based on any progress I make or challenges I face.

I’m aware that the schedule at the end is stupid and unrealistic. I have no idea what goes into making a game and I know that I have a full time job and personal commitments that are going to take up the vast majority of my time, but I feel like that’s a good place to start and I can always change it.

Realistically, this game will probably never get finished. If it gets finished, it probably won’t be any good. If it’s any good, nobody will play it. If people play it… Well, I guess everything’s good at that point. It’s unlikely, but I guess crazier things have happened, right?

This post and the newfound ambition that comes with it is thanks mostly-in-part to Tom Francis, the creator of Gunpoint. He was in a similar situation as I am — no coding/art experience, full time job — and he made an incredible game that went on to become incredibly successful. You’re an inspiration, Tom! I thank you.

So this inaugural post doesn’t really have any actual development work in it. That, I assume, will come a few weeks from now once I actually get started working on it. And even then there won’t be a fixed, regular schedule of when these posts will happen, or even when the game will get worked on. I am not in a position in my life where I can make either a priority, but I hope I do find a decent chunk of time to carve out for them. Let’s see where it goes.

Wish me luck!

Here is the design document in its entirety:

Arr (working title) Design Document



Arr is a 2D side-scrolling platformer heavily inspired by 16-bit era classics like Super Mario World and the Donkey Kong Country series (especially 2). The game will be created with the Game Maker: Studio engine. The player controls a captain of a pirate ship that has been attacked by a creature at sea, scattering him and his crew to a mysterious island where the members of the crew have been kidnapped by the local natives. It is your job as the captain to traverse dangerous environments and battle capable foes to reach the other end of the island and rescue your crew members along the way, while leaving plenty of time to excavate the land for treasure.




The game is a traditional, challenging platformer with tight controls. Variety will be added not based on the player’s ability, such as powerups or items, but level variation. Each level with carry it’s own theme and challenge — no two levels will be alike.



The game will feature very basic and simple controls. The character will not receive any extra abilities outside of what he starts with. The variety in the game will be based around the variation in the level design, not in the capabilities of the character.


  • Left and right movement. A set speed with no run button.
  • Jump. No delayed response, heavy (but slightly restricted) air control.
  • Attack. A swing/stab of a sword that is instantaneous and can be repeated as fast as a button press.
  • Hang/grab. Holding the attack button (or perhaps a separate button) will allow the player to hang/grab onto certain surfaces such as vines or monkey bars. This feature was in Donkey Kong Country Returns but was not utilized enough, in my opinion, and I would like to focus the game more around this ability.


Levels (to be updated):


Enemies (to be updated):


Potential Features:


  • Customizable Difficulty:

When the player starts the game, an option menu will appear allowing the player to adjust gameplay features that will make the game easier or more challenging such as: maximum health, player damage dealt, enemy damage dealt, number of checkpoints in a level, etc. While there will be a “recommended” setting, there will be options for all types of play styles.


  • Secret Level Paths and Story Collectibles:

Similar to secret exits in Super Mario World, several (if not all) levels will have a separate hidden path. These paths will be a far more challenging way through the level. The player will be rewarded with a collectible at the end of this path which will unlock backstory to the characters in the game. These collectibles will also be used to unlock postgame levels. The post-game levels will be the most challenging levels in the game.


  • Revisitable Checkpoints:

Since several (if not all) levels will feature hidden paths, the ability to start a previously completed stage from any checkpoint will be implemented. This way, players can explore the levels for the hidden areas or replay their favorite parts without being required to play through the entire level.


Ideas/Thoughts (to be updated):


Creation Schedule (tentative/to be updated):

  1. Create the player and the controls first. Since the controls in the beginning are what the controls will be at the end, once this is created and perfected I never have to touch it again.
  2. Design the layout of each level. At the very least, get the basic environment (floors, walls, platforms) implemented and run through them with the hazards and enemies in mind.
  3. After getting a sense of how the player would run through each level, design and implement each level’s theme/environment hazards/challenges.
  4. Design and create the enemies. How important will they be to each level? Will the game feature an even split of enemies to environmental challenges, or will it favor one over the other? After writing this out, this might actually be better swapped with #3. I’ll think about it.
  5. Graphics/sound. Everything up until this point will be placeholder. If I get a game mostly developed with placeholder graphics and sound, I will have a better leg to stand on when I ask for artists to contribute.
  6. Polish/bugfixing.


About the author

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *