Game Design Documents

This week's topic will be about Game Design Documents. Game Design Documents, or GDDs for short, is essentially the game's bible. It can be physical or digital and it details every aspect of the game to the point where if anyone had a single question about the game, no matter how big or small it may be, there will be a section in the GDD that you can point them to. This would mean that the bigger the game, the thicker the document and most people don't want to go through hundreds of pages of text (be it physical or digital).

Now, I obviously can't speak for all studios. Everyone has their own way to deal with GDDs. But I feel that the bigger the studio, the bigger the document. My reasoning is that the designer(s) probably won't have time to answer everyone's questions personally or guide them in the right direction. So usually, they create a detailed enough document that they can simply give to the person for them to understand what they need to do.

Anyway, there are a few things I recommend doing or avoiding when it comes to GDDs.
 
Visual Aid
Pictures, pictures and more pictures. The more visual aid you use when describing something, the better. Because when you describe something using words, other people can misunderstand what you're saying. So it's best to use pictures as much as possible. I'll give you an example. I once created a document for a character I designed for an action, role-playing game. When it came to designing its attack animations, I photographed myself performing the actions to roughly show what it should look like to the animators.

1 of 6 attack animations

Blocking

Short and Sweet
Unless you really have to, use as few words as possible. No one likes reading walls of text, especially when they're not broken down into smaller paragraphs. This is especially true for most programmers and artists. So always be concise with your descriptions and explanations. You can also consider using bullet-points so it looks like a to-do list to whomever is working on that particular feature of the game. It will make their life easier.

Degrees of Separation
What I like to do with design documents is split them up into smaller documents. I feel that there is no need in putting everything into a single document, be it digital or physical. I have 3 reasons behind this.

First, is that some parts of the document are irrelevant to certain people. For example, programmers will care about how the battle system work, but not on what a character visually looks like or what the dialogue of certain NPCs say. So just split your document into smaller categories rather than forcing someone to have to go through a lot of irrelevant information just to get to the section that they only care about.

Second, I feel that your document becomes more organized and easier to manage. When you need to know about a character, simply grab the characters document. If you want to know about how the user interface works, grab the user interface document. It also makes updating the document more efficient because while you're updating one section, people still have access to other sections. If you're doing a physical document, you only need to print out the updated document, rather than re-printing out the entire document just because you updated one section.

Third, and this is highly unlikely, if you somehow ruined one document (like file corruption or something like that), you'll only be affecting that document while sparing the rest. Like they say, don't put all your eggs into one basket.

Well that's it for this week. Thanks for reading and see you all next week!

Controls

Welcome back to the Beige Designer! This week I'll be talking about controls.

This subject came to mind when I saw a game recently on the iPad that had a virtual analog stick and buttons. I know this isn't a bad thing, but I feel that it's a waste to develop a game where you don't take advantage of the technology of touch devices. The hardware should compliment the game and vice versa. Take a look at some popular games on touch devices such as Fruit Ninja, Angry Birds, Clash of Clans, Tiny Tower and Cut the Rope. One of the reasons they're popular, is because their controls are the same as how people operate touch devices in the first place - through tapping and swiping using their index fingers.

Now with that said however, remember that there are some game genres that doesn't work too well with some control schemes. For example, real-time strategy games is best controlled using a mouse and keyboard while fighting games are better suited on console controllers or a joystick and buttons. Of course, I'm not saying that these genres should only belong to a certain control scheme, but to develop a real-time srategy game for the console, for example, is very tricky to pull off correctly.

Of course, what you could do is design a controller best suited for your game like Nintendo did with their Nintendo 64 controller which was designed around Super Mario 64. At the time of the game's development, Nintendo needed to design a controller that allowed players to accurately control a character in a 3D environment. Thus, they decided to add an analogue stick to their controller. But anyway, let's move on.

Next, I'm going to side step a little and talk about how to properly assign actions to your controls. Now obviously, this varies since there are different types of controls, mechanics and game genres, so I'll try to just give a couple of advices.

First, your controls must be simple and natural enough that it becomes second nature for the player. The moment they need to remind themselves which button does what, or they accidentally press a button they didn't mean to, is the moment their immersion becomes broken. For example, in DotA (a popular Warcraft III mod) you control a hero with around four skills that you can activate by pressing certain keys on the keyboard (i.e. hotkeys). However, the location for these keys are different for most of the heroes. Now this could be a technical limitation but it is an example of non-immersive controls. This is why in DotA 2, they assigned the first, second, third and fourth skills onto Q, W, E and R, respectively. Any extra skills a hero had were implemented on keys near the original four keys such as D.

Second, if you have actions which can be combined with other actions, ensure that these can be easily pressed together with ease. Sometimes, it is best to separate them onto different fingers. Although our fingers are long enough that we can press two buttons simultaneously with the same finger, depending on the game, this can be uncomfortable and non-intuitive. For example, if you're designing a first-person shooter game where you move with the left analogue stick using your left thumb and look around with the right analogue stick using your right thumb, you wouldn't put the shoot action on one of the four buttons on the right hand side of the controller. Why? Because you'll need to be able to shoot while moving or looking around and since your left and right thumbs are already occupied with them, respectively, let one of your other fingers do the shooting.

I'll give you an example for the above. In Resident Evil 6 on the Playstation 3, the player is taught that if you move the left analogue stick while holding down the X-button, your character will dash (see image below and I apologize for the size). This is bad design in my opinion simply because your right thumb is already required to move the right analogue stick which moves the camera which affects the direction you're moving towards. Now I guess this would be fine if the game doesn't involve you changing directions while dashing. But there are a few events that requires you to do so. One such event requires the player to dash across a non-linear harbour while a helicopter launches missiles at you (which can result in you dying if you're not fast enough).

Resident Evil 6 - First time you're taught how to Dash (Leon)

Luckily, I didn't have to bother with holding down the X-button as I found out in the beginning that you can simply click the left analogue stick while moving it to make your character dash. But I only figured this out because this is what past shooter games that I've played did. However, with that said, don't think that that dashing by clicking the left analogue stick is the best way. I personally prefer assigning the left bumper as my dash button when possible.

Well, I think that's enough for this week's topic. I've posted links below to some interesting reads about video game controls. Enjoy and see you next week!

[Links]

20 Unusual Control Schemes
History of the Game Controller
Evolution of Game Controllers
Video Game Controller Chart

Consistency in Design

Consistency is very important when designing a game. It helps players immerse themselves into your world better as well as understand it more easily.

When you create a rule in your game, ensure that that rule remains the same throughout your game. For example, let's say you have a blue ball that can be picked up and thrown. In this case, ensure that all blue balls in your game behave the same. Don't suddenly have a blue ball that the player can't throw. The reason for this is because you have just taught the player one of the rules in your game: "Blue balls can be thrown". It would be bad design if you were to suddenly break that rule, especially without informing the player.

Imagine you're in maths class and the teacher has taught you that 1 plus 1 equals 2. But one day, during a test, when you put 2 as the answer to the question "What's 1 plus 1?" your teacher suddenly tells you it's wrong. Wouldn't you get annoyed or feel betrayed? Well that's basically the same with video games.

Now, you may be thinking "what if my game involves breaking/bending the rules?" or "what if I need to break/bend my own rules?"

Well for the former question, that's still a rule of your game, no matter how you slice it. Whatever type of game you're creating, you will have to teach the player the rules of your game, no matter how weird or bizarre they may be (after all, what is a game without rules?). For example, one of your game's rules could be that in each level, the ball that can be thrown changes colour. Usually, games that appear to be breaking/bending their own rules will still have at least 1 core rule underneath it all that will still help the player.

I'll give you an example. In Assassin's Creed 3, there are objects that you can jump into and hide in. One type of object that you can hide in are 'pile' objects (the haystack being the famous one in the series). But when you get to the forest, you'll notice that the pile object has changed to a pile of tree branches rather than a haystack. This may look like they're breaking their own rules, but in fact, they still have at least 1 core rule regarding these objects that will still help the player determine whether or not they can hide in them. This is the fact that all pile objects are shaped like a mound that is roughly the same size and have a 'noisy' texture, which in this case are a messy collection of hay or tree branches.

Assassin's Creed 3
(TOP: haystack in a cart; BOTTOM: pile of tree branches in the forest)

For the latter question, ensure then that you give some contextualized reason. I highly recommend a visual one over a text-based one. Rather than having the game tell you that a particular blue ball cannot be thrown... instead, have the ball be made out of steel or some sort. This way, the player can see that something has changed to the blue ball, thereby telling him that something must be different about said ball. This brings me to my next point.

Consistency doesn't only apply to mechanics. The visuals of your game must also be consistent. It must be clear to players whether something is A or B because players interact with your game through visuals more than text.

For example, let's say you're making a third person shooter with no jumping. However, there are low objects in the game that when approached, will cause the hero to hop over it. Now, for the sake of this example, let's say said objects are 1 meter high. This means that all objects that the hero can hop over must be almost exactly 1 meter high. If an object cannot be hopped over, make it obvious to the player by, for example, making the object 2 meters high instead (as oppose to making them only 1.1 meters or 1.2 meters high). If the difference is too small, the player may never notice and it may break their immersion or worse, they might think it's a bug.

Basically, if you look at an object and your immediate thought is whether it's A or B, then unless that's a rule in your game, you may want to re-design it. For example, this wouldn't apply in a "spot the difference" game.

Well, that's it for this week. I hope this post was clear and wasn't too confusing for everyone. It's quite late here and I'm a bit tired *yawn*. Anyway, see you all next week!

Competitions

Let's talk about competitions this week. Entering competitions is a great way for you to become a better game designer. It helps you practice designing within limitations, scheduling and learning how to develop games specific to your client.

First of all, don't be afraid of entering any competition. Some people may get intimidated or think "other people's games are going to be much better than mine. Why should I bother entering at all?" This isn't healthy. Unless you don't have the time, always take every opportunity to enter competitions. Doing so also shows your confidence. One of my good friends once told me that entering competitions shows that "I'm confident enough in my work to brave the slings and arrows of the public in a competition."

When you enter a competition, don't just submit any game that just happens to meet the requirements. Study the competition and ask yourself a few questions like:

1. Who is running the competition?
2. What is the competition for?
3. What are the judges looking for?

Also, take a look at the past winners of the competition you're entering (if any). This will let you know the kind of games the competition favours. If the competition is the type where it does a different theme each time, you can still look at the past winners to see how their games dealt with the theme.

Another great lesson you can learn from entering competitions is learning how to develop a game specific to your client (in this case, the judges of the competitions). This will help you to look at your game from a different perspective. Remember that if you want to be a game designer, you'll be developing games for other people... not yourself.

I once entered a competition called "Games for Netbooks" which was sponsored by Intel. At first, I mistakingly decided to submit a game which I just thought would be great way to show off my design skills. However, I quickly realized that this wasn't the way to go. So, I did research on the competition and fortunately, there was a page explaining what the judges were looking for in the submissions. After that, I developed a new game that met all the criteria and a few months later, I had won first place for "Best Gameplay".

In case you are interested, you can find the article about it here.

Anyway, that's all for this week. I'll put up a few links below to some game competitions. There's a lot more out there so remember to look around. Good luck and all the best. See you next week!

[LINKS]

IndiePubGames
IGF
DreamBuildPlay
IndieGameChallenge
GlobalGameJam

Here is another one thanks to Zace

CompoHub

Scheduling

For this week's topic, I thought I'd talk a bit about scheduling. Setting up a schedule can be very tricky since a lot of things can happen between when you start and when you finish. So don't expect to be able to follow your schedule perfectly. Below, I'll briefly give some advice when creating a schedule.

First of all, if you don't have any sort of deadlines such as a competition or the like, you may want to create a schedule anyway. It can prevent you from making excuses to yourself for pushing work to a later day.

Your Team
As mentioned in one of my previous posts, when you want to start on a game, take a look at your team. Knowing your team will help you with your scheduling. For example, if the person who will be programming your game is new or still a beginner, then you should give some time in your schedule for them in case they need time programming a certain feature or mechanic... which brings me to my next advice.

Prototyping
Once you've decided on a game design, prototype it. Now, in regards to scheduling, prototyping allows you to see an estimate of the amount of work required to create your game. Now, what I suggest is to get your programmer(s) to implement not only the core mechanics, but the core experience as well. Get them to program as much of the game as possible in one week and at their own pace, with the latter being the most important.

Think of it this way, if your programmer(s) can achieve a lot when their being lazy, imagine what they can achieve when they work hard. So when you create your schedule while taking into account your programmer(s) comfortable pace, you may be able to finish work ahead of schedule and get more time for polish.

Polish Time
Speaking of polish, make room in your schedule for it. I tend to assign a quarter of the schedule to polish at least. Some companies can be polishing their game for years, so make sure you give yourself time for it.
 
Milestones
Once you have an idea of the size of the schedule, create small milestones for it. These are checkpoints that will help you achieve your schedule by splitting it into smaller, bite size pieces. For example, you may opt to create a milestone every month. Now, what these milestones are depends entirely on what kind of game you're developing. But generally, milestones should be the important features of your game such as getting enemies to work in an first-person shooter or a basic battle system for an adventure game.

Well, I hope that has been helpful for you. Remember that no schedule is perfect. You may end up finishing ahead of schedule or behind. But as with anything, the more experience you get, the better you'll become. Thanks for reading and see you all next week!

Also, if anyone has a suggestion for a topic they'd like me to talk about, please feel free to email me at ckamarga@gmail.com (along with any comments or criticisms you have).

Tutorials

This week, let's talk about tutorials in video games. Tutorials are very tricky to pull off and there isn't a formula that you can apply to all games, even if they are in the same genre. The way a tutorial is presented often depends on the type of game it's in. Theoretically, the simpler the game, the less need you have for a tutorial. Below, I'll list four of the main types of tutorials used in nearly all form of games. I could be horribly wrong though so if I missed some types, feel free to correct me.

Billboards
This type of tutorial involves the game displaying information on screen independently from the player. The 'billboards' can be contextualized (such as an actual billboard in the world) or simply be as a piece of UI. Nevertheless, they just display information about controls or a mechanic for the player to try. Almost every game that uses this method will accompany the tutorial with a corresponding obstacle. There is also a slight variant of this where instead of automatically showing the information on screen, the player must interact with an object to display/hide the information.

I don't mind this type of tutorial because they don't stop players from playing the game and if they were to replay it one day, they can simply ignore them completely. If you are using this type of tutorial, I suggest not putting this in a special tutorial level (especially if the game has a high re-playability value) and instead put them in the first level of your game. One of the main reasons for this is to prevent the game from forcing the player to replay a useless level.

Dragonica (PC)

Mentor
This type of tutorial involves the game explaining the controls and mechanics to the hero whom the player is controlling. The mentor can be anything, though it's nearly always a character in the game. In rare cases, the game instead is explaining everything to another character while the hero is nearby. This is rare because when the game is teaching the controls and mechanics, they must break the fourth wall by mentioning the buttons on the controller. If this is said to a character that the player is not controlling, it can make the player feel like they're being ignored. Plus, the game's focus is primarily on the player's hero so you have to give your attention to them.

Anyway, this tutorial is often used because it's easy to contextualize it within the game's world. For example, in a first person shooter game, the player could be controlling a new recruit who is undergoing training on how to operate firearms and other weapons. When using this type of tutorial, try to not make it too long or contain too many text. If you have a lot to teach, spread them out in the beginning of the game so the player has a chance to breathe between each lesson. It's better to take a lot of small bites than to take one big bite in one go.

Tales of the Abyss (3DS)

LAYP - Learn As You Play
This is my favourite type of tutorial where players simply learn as they play the game. It allows players to experiement and discover things by themselves. Plus, it's a great feeling for players when they're faced with an obstacle and are able to overcome it by themselves without any help. It makes them feel smart and that is a wonderful feeling for gamers. Now you may argue that "learn as you play" isn't really a tutorial. However, I disagree. The tutorial lies in the design of the first level the player starts with. For example, a cliche one would be teaching the player to jump by putting a short blockade in front of them to jump over.

But, as I briefly mentioned, this method of teaching the player lies in the design of the first level. Therefore, if you are using this method, make sure you put effort into your first level.
  

Directed
This is a type of tutorial where it involves the game basically holding your hand and showing you (often using a pointing arrow to do so) to do one action at a time until the tutorial is over. The player has no freedom until they have completed the directed tutorial. Though this ensures that the player understands the game's basic mechanics, it can get quite annoying if the tutorial is too long. Plus, if you need to put a directed tutorial into your game, then perhaps you should re-evaluate your game's design.

Directed tutorials can be found on many freemium games on touch devices and Facebook.

Magic Land (Facebook)

Alright, I'll end this week's post here. I'll put a link below to a video which analyses the level design in Mega Man games as well as the introductory level of Mega Man X with the latter doing a great job teaching the player as they play the first level. Enjoy and see you all next week!

[Links]

Sequelitis

Narrative in Video Games

This week's topic will be about narrative in video games. Specifically, the do's and don't's and the effects it can have on both video games and players.

First of all, don't develop a game entirely around a detailed epic story that you've come up with. This is a rookie mistake some aspiring designers do. The reason being is that as you develop the game, you'll be heavily constrained by the details of the story you've invented. This can cause your game to be a mess and ruin the player's experience.

Instead, come up with an overall narrative that you wish for players to experience. Then, without getting into the details just yet, design mechanics that will reinforce that experience. For example, in Suikoden II, the developers wanted players to experience the story of a young boy who is caught up in the middle of a war who ends up becoming the leader of the liberation army. Therefore, for players to experience this kind of story, the developers created mechanics which reinforced both the narrative and the experience. One such mechanic is their 'map battles' which involves the player controlling groups of units on a grid-based map. This is similar to strategy rooms where you see high officers planning their strategy on a map using toys to represents unit types for both sides.

Just remember that narrative is very flexible and can be warped and shaped to fit into any part of the game.

Second, narrative, when used correctly, can be a very powerful ally in your quest to develop a game. It gives the player context, reason, justification, rationalization and can even be used to manipulate the player as well. So be careful when you insert narrative into a game. If used incorrectly, it can spell doom!

I'll give you an example. Take the MMORPG Star Wars Galaxy and the adventure game Bioshock. Both games have a re-spawn mechanic which works the same way. However, each game gave a different narrative behind the mechanic. In Star Wars Galaxy, it's explained that when a player dies, they are brought back to life through cloning technology whereas in Bioshock, the player is brought back by being 'revitalized' in a vita-chamber. The results? Well, despite the mechanic working exactly the same in both games, some of the players in Star Wars Galaxy became angry because they wanted to play the characters that they've made, rather than clone versions of them. It may sound crazy, but that's the power of narrative.

Well, that's it for this week. Thanks for reading and see you all next week!