A Word on Game Making
Posted May 16, '13 at 2:44pm
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:
And with that out of the way, let's start with the theoretical stuff before we get to the actual implementation of a game.
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 what's the game design exactly? It is similar to a movie script, which details
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
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
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.
- How does the game handle the player input? Do the controls change when certain conditions are met?
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).
1) Get Input from the player
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.
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.
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.
Posted May 17, '13 at 7:39am
This is a great article your making here :D
Posted May 20, '13 at 8:41pm
It appears you are skilled at this kind of stuff. My friends and I are planning to make a small game this summer its not going to be very good as its our first game, but hopefully with lots of effort and tutorials we'll make it.