Forums → Programming Forum → A Word on Game Making

Seeing as the forum now has threads for free game making tools as well as an introduction to programming, I've decided to add what I'd call the missing link: a thread about the actual process of developing a video game.

A couple things to note before we start:
- I'll try to make this as platform independant as possible, simply to make it age more slowly
- I won't go into 3D specific things, since 3D games are significantly more complex and would probably atleast double the size of this post
- Programming knowledge isn't strictly required, but keep in mind it'll give you many more options, as well as other applications than just making games.
- This is by no means complete, as the whole topic is simply to complex to put into a single thread post. Even in a condensed form, it may still be too complicated for complete beginners.
- Sit down and do it! By far the best way to learn about game making is experiencing it yourself.

And with that out of the way, let's start with the theoretical stuff before we get to the actual implementation of a game.




Every game starts with an idea. It might be something like a unique game mechanic or concept you want to try, or maybe just an idea for a specific setting or a story. It doesn't even necessarily have to be something completely original. This may seem obvious, but nevertheless, it's important that you know for sure what *exactly* your idea is before you start making a game out of it.

So, in order to get you to properly think your idea through, your best bet is to simply write it down. Don't get carried away though, only a few short sentences should be enough to explain the gist of the game. Also don't be lazy and actually write it down instead of thinking up some sentences that sound nice in your head. That way, you'll have something to read as a little reminder, in case you run out of ideas in later parts of development or want to present your idea to other people.

Now, what about those that have a hard time coming up with ideas in the first place? Fortunately, coming up with good ideas isn't something that's exclusive to very creative people, but is a skill that can be trained just like most other things, assuming you put the time and effort into it. The simplest way would be to look at games you like in particular and putting your own twist on the concept. Alternatively, pick a verb from a dictionary, any verb will do, and think about how to make a game that centers around this particular verb. It's not the perfect way, but it's an easy one to get started.

One more thing to keep in mind is to not get carried away with your first few games and instead focus on making simple, but fun things. Once you gain more experience, moving up to more elaborate projects will be less difficult.


So now that you have a concrete idea, it's time to get down to the fun part and expand it. Game Design is the part where you have no other choice but to put down things on paper (or a text file for the fast typers out there), because I can guarantee you'll run into problems if you don't, especially when dealing with complex projects and additional team members, other than yourself.

So what's the game design exactly? It is similar to a movie script, which details
every piece of dialogue and the scenes of the movie. The game design has to do the same thing: explaining every aspect of the game in full detail. Think of it as the most indepth strategy guide ever when writing it. At the same time, you shouldn't think of it as a static document. A game design document should change according to development, with unfun elements being removed and new elements being added as needed.

Which brings us to the next important question: Just what *are* the different aspects of a game? In no particular order, (almost) every game has the following elements:

- a set of rules
- graphics
- sound
- story
- a platform it runs on

The ruleset is probably the first thing many people think of, since the rules of a game make up the entirety of the gameplay. It includes everything, from the various winning and losing conditions, to the various game modes and anything that depends on player input. For instance, some rules for a game like Super Mario Bros. could look somewhat like this:

- Mario can go left and right, jump, run and throw fireballs when using a fire flower
- You can kill enemies by jumping on them from above
- Mario gains a small boost from jumping on enemies
- Collecting 100 coins gives you an extra live
- You clear a stage by touching the flag pole or reaching the axe in a castle stage
- Mario can enter some, but not all pipes

And so on.

When designing gameplay, it also helps enormously to consider in advance how game elements tie into one another or compare to each other. For instance, when you're designing various weapons for a game, make tables that list and compare the various weapon attributes and abilities. This way you can already tell in the design phase if certain elements are unbalanced, which can save some time later down the line. This also helps in showing you game elements that are currently underused and need to be more fleshed out.

As for graphics and sound, these are especially important when working with multiple people in a team (say an artist and a composer). Your game design should cover how many and what kind of assets you need (both graphics and music/soundeffects), as well as the style they need to be in (since a dark horror game needs different art assets than a kid-friendly one). It's the basis from which an artist would make game assets for you, so being as thorough as possible helps in eliminating possible misunderstandings and time consuming re-designs.

Story is another important thing to cover in your game design, however a story isn't quite as mandatory as gameplay and graphics. However, it's still a good idea to explain the basic premise and setting of the game. Imagine yourself as being the person to write the promotional text on the back of the box and you have a good starting point. Of course, if you do have a complex story, you'll most likely need a script, story boards and all that other good stuff (which is a massive topic all on its own !).

Lastly, the platform, i.e whichever system or hardware your game will run on. I'm giving this its own little section because just the choice of platform will (and should) greatly influence the game's design. For instance, making a smartphone game has different requirements from a AAA console game, since smartphones not only have a lower resolution, but are also mostly touch controlled, which means you'll not only need menus that are easy to navigate, but the basic controls also need to be touch centered (which is a whole lot different from even standard mouse controls!). Always be mindful of the platform you want to make a game for, look at certain advantages and standard conventions the platform has and design accordingly.


The technical design can be part of a game design document, but it's important enough to atleast warrant an extra section on here. The purpose of the technical design is to outline the actual implementation of the game, i.e how the whole thing is structured in terms of program code, and serves as the basis for the programmers to start turning the game design into an actual game. You don't necessarily need to write down actual source code though, just simple pseudocode should be enough. The sooner you try and figure out exactly how your game is going to work from a coding perspective, the sooner you'll be able to spot bugs in your code (and trust me, there will be atleast some).
Here's a few things a technical design document would detail, just to give you the general idea:

- How does the game handle the player input? Do the controls change when certain conditions are met?
- How does the games collision detection work?
- How does enemy and player AI work?
- How does the games camera work?
- How is the game loop set up?
While a technical design is a useful thing to have, it'll probably be slightly less important if you don't code the game yourself and let a game engine (like Stencyl) do most of the heavy lifting.

Lastly, before we get to the second big part, the implementation process, I want to briefly touch on a few technical details (which can be safely ignored if you don't feel like reading it), specifically the game loop.

If you've been playing games for a while, you've no doubt heard of the term fps, frames per second, which is the number of images it draws to the screen in one second. The game loop and the framerate have a close relationship with each other, because the game loop is the central component of any game (atleast programming-wise).
The game loop is essentially an endless loop that runs as long as he game is active and does the following things in every frame:

1) Get Input from the player
2) Update the game world and game objects accordingly
3) Draw the resulting scene onto the screen

As a result, a game's framerate is the number of game loops you can execute in a single second. There's a bit more to it than that (there's a few different ways you can approach designing the game loop), and this simple 3-step approach actually has its own disadvantages: it's vastly dependant on the hardware of whatever platform you're using, which is why some very old PC games can sometimes run unplayably fast when played on todays hardware. Regardless, I feel knowing the basic idea behind the game loop can be very helpful in understanding how video games in general work from a technical perspective. If you're interrested in reading more (and don't mind getting a little bit more technical), I recommend this article.

With that out of the way, let's get to work!



So now that you have a solid game design, you might be asking yourself where to go next, other than the obvious advice of "just start coding/scripting away". Truthfully, I can't be super specific about that, because it mostly depends on what you use to make the game. If you're a non-coding person you use different tools than a programming, so giving general advice is somewhat difficult. Instead, I'll go over a few principles that can help you while you're working on the game.


Making games takes a pretty long time, especially to get the first playable version. As such, any developers biggest fear is investing a bunch of time into a project, only to find out the game he's making just isn't any fun. Prototyping is a way to get around this little problem and notice early on if something doesn't work out.
The idea is this: you look at your game, take the most important mechanic and try to make a small prototype that focuses on just this mechanic. No need for fancy graphics, menus or anything like that. Just something quick and simple you can make as soon as possible. If your very simple prototype turns out to be fun, there's a good chance that the actual game will be too. If it's not fun, you need to evaluate your prototype and idea: What's fun about it and what isn't? Is there something specifically that keeps you from enjoying the prototype?
If you find answers to these questions, change or add things to your prototype and see if it's fun. However, if you still can't find a way to solve the problem, you might need to realise that the idea simply may not be fun.

You don't even necessarily need to make a "video game" prototype. Depending on the game you're making, it could be possible to make a simple prototype on paper, similar to a board game. This type of prototype can be especially handy to use, since paper board games are cheap and easy to make.

One last thing to note about prototypes: Don't build your game on top of them. Throw away the prototype. The main reason for this is that the prototype is meant to be thrown together very quickly. By starting over from scratch, you can fix all the problems you noticed in the creation of the prototype, which'll result in a much better game.


As you're working on the game, it's important to regularly make sure the game is still fun and new elements add to the game in a meaningful way. However, it's equally as important to ask for the opinion of other people and get feedback on the game. After all, they're the ones that'll hopefully be playing your game later. Make sure you get feedback from as many different people as possible and try to consider every piece of feedback you get (even if it's negative), because it'll only make the game better in the long run.

The same principle also applies when bug testing, as someone outside of development might find different ways to break the game than you, letting you find more bugs than on your own.



And that's basically the whole process, albeit in super condensed form. Once you're at this point, you're ready to release your game out into the wild!
Once again though, keep in mind that just reading this thread alone won't produce games. Only sitting down, putting in effort and gathering the experience yourself can do that.