Hello everybody! I am still around believe it or not. I’m sure all 2 of you that saw my original post must have thought I’d withered away and gave up as soon as the real work needed to begin. Thankfully it’s just been a case of too much holiday season. Speaking of the holiday’s I hope you all had a very Merry Christmas! Also a happy Hanukkah, crazy Kwanzaa, a rad Ramadan, and enjoyable whatever other holidays I might have missed around this time of the year.

https://pixabay.com/en/christmas-merry-christmas-1816523/

Or happy holidays if you’re one of those people.

I recently returned from my very tiny holiday vacation back home in New York with the family. Less than a week but it’s my biggest vacation all year… Salaried work has its ups and downs. Despite this, I had a very nice time getting to see the family again. Lots of gingerbread, holiday specials, gifts, great food, and wine.

Only the 2nd post and already you get a face reveal! My grandparents look like deer caught in headlights.

I do want to say sorry about how delayed this post is. My original goal was to have this post live weeks before Christmas! While that was a bit optimistic to begin with, I definitely could have powered this out a little earlier than you’re getting. Despite how much I kept pushing it off, I just couldn’t bear to have it slip into next year so here we are! I tend to wait until the last minute for a lot of things but I’ll admit the last day of the year is kind of pushing it. With the new year right around the corner I definitely want to start ramping up my overall productivity. There’s something about the whole Christmas season that gets me really lazy, like I’m finally getting a break after all of the hard work for the past year.

https://pxhere.com/en/photo/840640

Literally me the past month.

With all those formalities out of the way, it’s time to get into what this post is all about! This is a game development blog after all. So, if you remember from the end of my last post, I mentioned that I wanted to start a “Let’s make a game” series. That’s exactly what today is all about, the start of of a game we’ll be making together from scratch. Exciting isn’t it? Now I’m sure a lot of you are ready to dive in before you even finish reading this post but that’s not exactly what we’ll be doing. Before we can put something together, we have to know what that something is going to be. An artist needs to envision their painting before they paint it. The same applies with games. Games are much larger in scope than a single painting though, so it’s hard to properly envision the whole thing in your head. We also want the ability to share our vision with others. This leads us to a very important tool any game developer needs to know how to make. The design document.

https://pixabay.com/p-158461/?no_redirect

This will be the foundation of your game. The thought that will eventually manifest into a reality.

It’s one thing if you want to just sort of play around with a pet project in order to improve your general skills. Maybe you have a specific little idea you want to quickly see come to life. Little things like that are fine to just jump right into, in fact I encourage you to do that. Naturally just having fun cobbling some stupid little thing together is a great way to improve your game development skills. However, when you have an idea that’s something more, something that’s so big you have trouble keeping track of all the ideas you’ll need to document it and plan it out before diving in otherwise you’re going to end up with a tangled mess in the end. Without exception, if you plan to make an entire video game that you want to see through to a completed state, it falls under this umbrella and needs a document. Even if you are a beyond human coding wizard, all you’re doing is increasing the difficulty for no reason when you jump in without making a document. So trust me when I say this, make a design document!

So, I bet a lot of you are now wondering “but Mike! How do I actually make one of these design documents?!” Don’t worry, that’s what this whole post is about so read on! Before we get into too much detail there’s a few things about design documents I want to say in general. Exactly what one is, is a document that describes every aspect of what your final game will look, sound, and even feel like (gameplay wise.) A perfect design document will go over every detail of every little thing about a game. Design documents for large triple A games can become entire novels! It’s definitely worth checking out some of the publically available ones for major games if you ever get a chance.

With that being said, it’s important to note that while you should aim to document as much as possible, don't feel like you're doing something wrong if every little detail isn't described. The purpose of a design document is to create something that you can use as reference throughout the lifetime of your project, not to create “the perfect document.” It’s not like this is something you need to submit to a teacher for a grade, it’s only for you to use. The exception being of course if you’re working on a team, in which case it’s also for everyone else to use. The more fleshed out your document becomes the more effort and time it takes to improve it. You don’t want to fall into the hole of never starting your game because you’re just bogged down trying to perfect your document.

https://giphy.com/gifs/skydiving-base-jumping-jumper-mjHAiGEBgFBKM

Be careful, for it is a deep, dark, and scary hole...

I say that in the context of the preparation phase though. You should always be tweaking it as you’re working on your game, if something changes along the way be sure to reflect that change in the document. But when initially preparing it, it’s almost like you’re drawing a sketch and then actually making the game is filling it in with colors. You only want to spend time putting the important edges in place, and as the project comes to life the colors will naturally fill in the gaps. Personally, I aim to get it into the 80-90% “perfect” phase. After that is when you start to get those diminishing returns.

https://pxhere.com/en/photo/623093

You’ve all used coloring books before, right?

Now that you have a good idea of what a design document is, let’s move on to the real action of this post. Remember, we’re going to be making this game together and that includes the design document. Part of what’s been delaying this post so long is that I’ve been putting one together for exactly that! It may not be too huge and probably could have been put together in less time than I took, but I really wanted to make sure it was in a good state for this post. The game itself is pretty simple, we’ll be making a 2D action platformer where you play as a starfish trying to recollect his arms. Each time you collect a new arm, you gain a new ability you’ll use to traverse more and more of the level. We'll be breaking down each section of the document and why it is important. I'll explain it in a way that will hopefully allow you to apply the knowledge to whatever your game idea is. If you're here to seriously learn how to make games, I recommend putting together your own document along the way. You can either use the same idea that way it’s easier to follow along, or you can come up with your own original idea. Depending on how experienced you are with the technical side of things, you may not want to diverge too much. Either way, be sure to try and put your own twist on the overall design!

https://www.flickr.com/photos/hollyclark/412543317

These guys are way more expressive than people give them credit for!

Google docs is a great place to manage your design doc, it's not the fanciest word processor but it's more than enough for what's needed. It also has the benefit of cloud access and being free. Here's the document I'll be using, you'll definitely want it open for reference as we go through this post.

With all of that said and done, time to dive in!

https://upload.wikimedia.org/wikipedia/commons/0/04/Salto_ornamental_-_UnB.jpg

Thankfully we don’t have to worry about things like “the shallow end” in game development!

Main descriptions

These are the big main descriptions that quickly and generally describe the game. They are broad but serve as a good first look of your game for anyone who might be reading this for the first time. Chances are you won’t be needing to go over these too often as you get immersed in development, but it’s important to still go over them when you can to make sure the project is moving along in a way that is faithful to what you originally wanted, or to make a change if that is what you feel needs to be.

Synopsis

It is important to be able to quickly and concisely describe the entirety of your game in a focused manner. Keeping it short and sweet helps for a variety of reasons. It helps you the designer focus on what is important in your game. By forcing yourself to summarize it in as short of a block of text as possible, you can really narrow in on what the core of your game is. Because it's likely you'll share this document at some point (like I am right now) having this part be the opening serves as a strong first impression. It allows readers to get the valuable details in a digestible way. Sure, it could be a huge 20 page wall of text that covers it all, but that could easily bore and turn off readers to the idea of your game. That would be a real problem if that reader was the person from the publishing company you're desperately trying to get to sponsor your game.

In my description, I let you know what type of game it will be and what it will be about. I describe the hook briefly but accurately, and by mentioning you are a starfish, that tells plenty about the setting of the game.

The Hook

A hook in a game is what initially draws the players attention and ultimately keeps them interested. Just like a fishing hook, it allows us to reel them in to our game. Every game has a hook and it is possibly the single most important detail of a game. It is like the spine of a game, it is the main mechanic that all other aspects of the game are built around. It is critical that you are able to identify what your game's hook is, and that is why we have this part so high up in the document. A hook needs to either be fresh and unique, or very well made. In general, the more unique a hook the more likely it will grab the public’s attention.

In my case, my hook isn't exactly the most original idea ever I'll admit, but I believe it will still make our game fun. I didn't want to do anything too crazy because I don't want this tutorial series to be too hard to follow. Let's break down how the rest of the game is going to be built around this hook:

Because you need to collect your 5 abilities, this means we need to come up with 5 fun abilities in the first place.

Because they will be collected progressively throughout the level, our entire level design needs to take this into account.

Because you will be losing your 5 abilities at the start of each level, we need a way to explain what is going on. This lead to me thinking of using a starfish as our player. (Yes I know they can't technically "reattach" their arms, they regenerate them. But the nice thing about making your own game is you can make up whatever rules you feel like!)

Because we are now a starfish, this cascades into our entire underwater theme.

The list can go on, but as you can see, the core of it all was our hook. I'll flesh out the exact points I mentioned above throughout the document so don't worry if you wanted me to talk more about them! Coming up with a hook is always the first thing I do when thinking of a game idea and it's always a great place to start with yours. Even if you don't specifically think of it first, identify it as soon as possible.

The Elevator Pitch

The elevator pitch is similar to your synopsis, except now instead of just describing your game, you're trying to actively sell it. The reason it's called the elevator pitch is because of the following scenario. Imagine you're at some office building and step into an elevator and you're on your way up. It stops at a floor and in steps someone that holds a lot of influence in the gaming industry. Someone like John Carmack, or Gabe Newell. It can be anyone really, but the point is that they have the ability to make your dream game happen. The only reason they haven't written up a contract for you yet is because they don't know about your game. However, you don't know how long this moment will last. It may be less than 30 seconds. You need to pitch them your idea in that time in such an appealing way that it's all they need to hear and they're on board. Even if a similar situation occurs and you have much more time, you need to have a way to quickly and concisely pitch your game. As brutal as it sounds, until they hear your great idea it's just another boring idea in a sea of literally thousands if not millions of ideas. People like this hear them all the time from aspiring developers. Sadly, until you prove otherwise your idea defaults as a bad one. Drone on too long and you'll quickly lose their attention and any hope of your game being produced.

Now you're not putting together an elevator pitch just to be prepared for this specific scenario. In all honesty there is a very slim chance of this ever actually happening. That's just the reason it's called “an elevator pitch.” Just like with summarizing your game, it's just as valuable for yourself to put together an elevator pitch. It will also likely become your go to when people (any people) ask what your game is about and you're short on time.

With my pitch, I try to grab the listeners attention and then give a brief description of what the game will be about. A platformer where you play as a starfish. Always assume that your listener knows nothing. What I mean by this is to avoid comparisons with something that might seem obvious to you. I could have said "It's just like Mario!" but if they somehow don't know about the game Mario, now my sentence means nothing. The same goes for any other gaming lingo you might be tempted to use. Still, you are describing a video game so to a certain degree you will have to mention some gaming terms. Just keep it as simple as you can.

The Small But Important Details

These are all of the details that are pretty straight forward and self explanatory. There's not too much to say about them other then that it's important to document them.

Genre

Chances are the game you're making falls under an already existing genre. These are games that share a set of core mechanics and at their roots are very similar to each other. Examples of genres: Puzzle game, platformer, rail shooter, beat em up, first person shooter, etc. It's very unlikely you'll be coming up with a whole new genre with your game. These days new genres tend to be branches of existing genres with a small but important change that gain a lot popularity. If you can't think of what your genre is, just try to think of some games that are similar to yours and look up what their genre is.

My game's genre is a 2D platformer because we are only operating in 2 dimensions, and the gameplay revolves around jumping around on platforms. Because there are combat mechanics involved, I also flagged it as an action game. Genres can be daisy chained together so long as they make sense. Good luck making a 2D platforming first person shooter.

Win/Lose Condition

This is an often overlooked part of designing games. What makes a game a game is that you are aiming to somehow win, and if along the way you fail then you lose. Now I know many of you are ready to start pointing out that not all games are like this. Some games are more open ended like minecraft but these are considered "Sandbox games." Don't get me wrong, I do love sandbox games and they certainly are considered games, but they are a whole different kind of beast. I'll probably talk more about them at a later point in time. Chances are that your game will have ways to win and ways to lose. It's important to know what these conditions are so that we don't lose focus. These tend to also be pretty straightforward and simple.

In my game, you win by collecting all 5 of your abilities and defeating the boss of a level. Once you do that on the last level, you win the whole game!

You lose when you sustain too much damage and run out of health. This will cost you a life and send you back to a checkpoint. Run out of lives, and you start the level over. Lose conditions don't mean permanent lose conditions, the nice thing about games is that you should have as many chances to try again as possible. It is up to you to decide how badly you want to punish players for mistakes.

Controls

When thinking up your game it's easy to just imagine your player running around the level doing whatever you want. The reality though is that players can't just use their minds for total control. (yet...) This means we'll have to eventually decide how the controls for our game works. Coming up with the general scheme beforehand is always a good idea. For a platformer like Star, the controls are pretty standard and simple. Just movement, jumping, and an action button. There are also controls for more general things like pausing the game listed. Note that I have a scheme for both keyboard and controller. I plan to only release this game on the PC and these are the 2 most common ways to play on PC. Be sure to come up with your controls for whatever your target market is!

Engine

I was debating if I should put this in the design document because this is a more technical detail but I figured I may as well. The engine is what you will be using to bring your game to life. I already mentioned that I will be using the Unity engine for this, but there are plenty of other great ones out there you can go with instead if you'd like.

Core Mechanics

A game mechanic can be thought of as a component in an engine like a gear or a pulley. It is a single "thing" in the game that acts as a piece of a larger whole. The engine in this case, being our whole game. Mechanics vary in size and importance but each one can be isolated and described. Some are more reliant on others, and because of this all games have a set of core mechanics that are critical for the game to work. What really makes a mechanic a core mechanic basically means that if this isn't in the game, our game can't really function.

For example, let's look at 2 iconic mechanics from Mario. Jumping, and collecting coins. Which one do you think is the core mechanic? Jumping of course! Without jumping, so many parts of Mario just stop working and the game is no longer playable. However, without coins Mario can still be the game we know it is. Sure it'll be different not seeing them all over the place to collect, but you can still complete all of the levels and eventually win the game. Removing coins also doesn't remove major challenge making the game too easy. Sure you can still beat the game by removing all enemies, but then you lose a lot of the challenge.

The reason we need to identify our core mechanics is that these are top tier priority to get up and running when it is time to develop the game. If you don't prioritize the correct mechanics to work on, chances are you're going to burn yourself out working on a difficult to implement mechanic that doesn't even bring much to the table.

As you can see, the mechanics that I listed out here are the very core of what Star will be about. I also go into as much detail as I can about what each end product will look like. I don’t have much else to say here about the mechanics but you should definitely go over them thoroughly in the document itself.

Obstacles

Obstacles are likely going to be a part of any game. To me, an obstacle is anything that gets in the way of the player's win condition. It's not designed to prevent the player from winning in the most efficient way possible, it should be more like a hurdle that the player must overcome in order to progress. This overcoming of challenges provides a satisfaction to the player and is one of the fundamental reasons humans enjoy playing games.

Obstacles are the building blocks we will use to create scenarios that will pose the real challenges. On their own, each obstacle will be relatively trivial for the player to overcome. This means that you should always consider how your obstacles are going to work together. On their own, crumbling platforms are harmless. On their own, spikes are very easy to avoid. Place some spikes below a crumbling platform, and we've now created an interesting dynamic between two obstacles.

The two types of obstacles I described in the document are terrain and enemies. Terrain simply exists and does its own thing, if the player happens to get caught in them that is on them. The terrain itself is neutral about whether or not the player wins. Enemies are creatures with AI that are actively trying to harm the player. However, at the end of the day both serve the same purpose. To challenge the player and make it more difficult to complete a level.

You'll notice I went into quite a bit of detail with the enemies. This is probably a good time to mention that it's not likely that everything I wrote out will be in the final product. This will likely be the case for a lot in this document. It's much easier to design a large product and chip away the features you don't need than to design a small product, finish, and realize you need to throw on more things. The key is to know that when designing the large product, not to get too attached to every little feature. This is called feature creep and has been the cause of death for a lot of potentially great projects. Feature creep is when you get too bogged down trying to implement every little thing and either get sick of your project and quit, or run out of time and or money. If you're too deep in feature creep, the only solution is to harshly cut big chunks away. It's like suddenly bringing down a sledge hammer on a marble statue you've been working on. It's much better to gradually chip away as you go along with your project than to suddenly cut big chunks. It's much easier to do this if going in, you know things will be cut. This goes back to what I was saying about not everything will likely be in the final product. The vast array of enemy designs are one example of the things I will likely chip away at down the road. Besides most of the core mechanics, literally anything has potential to be chipped away at. It's definitely something you'll want to keep in mind as you design your game.

Collectibles

Collectibles are all of the fun little things you can pick up as you play the game. A perfect example of these are coins from Mario. Mario also has lots of other collectibles like mushrooms and flowers. Exactly what a collectible does is always going to be different. The main point of what makes something a collectible is that it's a minor little thing we can use as a reward all over the place in our levels. Because I came up with a whole variety of collectibles, each one has a different level of rarity and usefulness to the player. This means different collectibles will be more valuable to the player than others.

We can use that to our advantage to influence the player with a technique called breadcrumbing. Imagine laying out a trail of breadcrumbs on the floor throughout your house. If you have a dog and it finds the first one, it will likely then find the next one in the trail as its right there in front of it. This pattern will repeat and the dog will walk along the path you defined because it just wants to eat the bread crumbs. In our case, the dog is the player and the bread crumbs are our collectibles. We use bread crumbing to help steer the player in the correct direction.

Let's say we have 2 platforms, one that goes up to the left and one that goes up to the right. At the end of the platform on the right is one of the player's Arms, a very important thing they'd want to find. However, it is not in view from where the player starts so they don't know about it. If we were to put a little coin on the edge of that platform and nothing on the other, the player will naturally be drawn to it. On its own it's not too important but players will naturally choose it over nothing. Because the player had to move over to collect the coin, the camera pans with them and the arm is now in view. We basically told the player what to do but without making it too obvious.

The reason we want to tell them what to do is to help avoid frustration. It can be easy to build a huge maze of a level and without any breadcrumbs it can drive anyone insane as they have no idea where they're going. At the same time, if we make it too obvious such as a big sign saying "Arm is up here, dummy" then the player might feel like the game is too easy. This then takes away the satisfaction of finding the arm in the first place. We can then spin this concept on itself by hiding non essential but still useful collectables in hard to find areas without any breadcrumbs. These will serve as rewards for the players that go the extra mile and go exploring on their own. They get the satisfaction of going above and beyond, and the players who didn’t find it don’t really mind because they’re still able to enjoy the rest of the game without it.

As for the collectibles I came up with, they're pretty standard stuff in platforming games with a few unique ideas. The main reason I have them is for breadcrumbing and to keep things interesting and appealing. Most collectibles are also very simple and easy to implement so it won't be hard to throw them into the game.

Level Design

It might be a bit early to be talking about level design but I wrote down what I did because I had the ideas in my head when I first came up with the game. Like I mentioned in the document, it's way too early to design entire levels for a variety of reasons. The main being that until the core mechanics and obstacles have been created and we have a chance to feel what they're like, who knows what's going to stay and what's going to be cut. The last thing we'd want to do is spend a bunch of time designing a level with a feature in mind, create the feature only to find out it's not fun so we scrap it, and now we just wasted all that time we put into the level. Levels are like paintings to me and I want to make sure we have a full pallet ready to go before we work. The game mechanics are our paints in this case.

That being said, there are still general themes I want to stick to with each level which is mostly what I talk about. I also talk about a lot of the visual and general aesthetic concepts in this part, something I haven't gone into much yet. Aesthetics are something to keep in mind as you develop but aren't really important until you have things working under the hood. This of course varies case to case, if you're on a team and you have a tight schedule, you'll want your artists working on day 1 of course and this would mean deciding on aesthetics from the get go. Thankfully this isn't the case. Star will of course need to have its aesthetics talked about at some point, but that will be a blog post farther down the road.

Closing Notes

One very important thing to note, is that there is no truly correct way to make or structure a design document. You can discuss none of the points I've mentioned and it would still be possible to make a document that can help you put together a game. What I showed you is just what I put together for the game I'm trying to make. It's not even a template that I always use or anything. The document needs to match the game like a scabbard matches a sword. A lot of the sections are sections for things related to the kind of game I'm making. Depending on how different your game is, you'll want different sections. For example, if this were a first person shooter game, I'd probably want a section describing the types of guns in my game. If this were a car racing game, I'd want a section describing my cars. The 2 main points I want you to get out of this are:

Don't feel like your document needs every section mine has. Make sure all details of your game are found in some sort of relevant section.

Like I mentioned near the beginning, the design document is never truly finished. I will likely be adding to it throughout the lifetime of this project. Anytime I do this I will of course let you all know and explain what the changes are. What we currently have is a good starting point and that is exactly what it needs to be right now. If any of you put together your own document based off of this post, please share it with the rest of us and we can talk about it below in the comments!

Now that we have a clearly defined goal of what we want our game to be, it might be tempting to just jump in and start developing! We're almost there but not quite yet. Just like we needed to design the game itself, we need to design our plan of attack for putting it together. For my next blog post, I'm going to talk about putting together a schedule for building your game, along with techniques like user stories to help you manage time. We'll break down our game into different milestones we want to see happen. It'll be done in a way that will allow flexibility while still keeping us rigid and focused. We'll also setup all of the back end overhead stuff needed so we can dive right in to actual game development afterwards.

Also a heads up, if you aren't yet familiar with C# I recommend you start taking some crash courses now. I say this now because if you get started, you can easily be familiar with it by the time I start talking about it more. There is certainly a lot to learn, even I'm learning more and more each day, but thankfully we're only going to need to know the basics for the scope of this game. I won't bog down this blog with a whole C# tutorial just yet. Maybe farther down the road that's something I'll want to do but not quite yet. To be honest, there's already plenty of very strong C# tutorials out there and there's not much I can say that hasn't already been said. I recommend just diving in as soon as you can. If you are completely new to programming, it may better to start with a simpler language. Just know that my Unity tutorial series is going to be using a lot of C#.





Thank you for reading!