For this week, I'm going to talk about one approach to designing a game, especially casual games. The approach is to design a game that's easy to pick up, but difficult to master. This will give your game a very low barrier of entry but at the same time, provide longevity, a challenge and perhaps addiction (in the good sense of course). A few examples of games that uses this approach are Tetris, Bejeweled and Angry Birds.
Anyway, let's break the approach into two pieces.
Easy to pick up
As previously mentioned, designing a game that's easy to pick up gives the game a low barrier of entry. This allows the game to reach out to a much larger demographic ranging from the young to the old. But how exactly do you design a game that's easy to pick up? Simple... keep the controls and goals very basic. Let's use the aforementioned games as examples.
Tetris
Controls - Left - Move block to the left
Right - Move block to the right
Down - Move block down faster
Button 1 - Rotate block
Goals - Create a solid horizontal line of blocks
Bejeweled
Controls - Swap 2 adjacent tiles with one another either through selecting them or sliding them
Goals - Make a connection of 3 or more tiles of the same type
Angry Birds
Controls - Use your finger to pull back a slingshot and launch the birds
Goals - Kill all the green pigs
Now before I continue, I just want to be clear that when I speak of controls, I'm not talking about the physical controls of the game, but rather, what the player can do in the game. Anyway... as you can see, these games have very basic controls and 1 clear goal for the player to achieve. This gives the player less time to learn and more time to play.
I used this approach for one of my games, Bubbly, which you can download from my website. Bubbly is essentially a platform game but with only one control - jumping - and the goal is to just reach the top. I gave it to some of my friends to play and they all enjoyed the easy to pick up controls but the difficulty of mastering some of the levels.
Difficult to master
Now, let's talk about giving your game difficulty. I'm just gonna touch on this very briefly because I plan to talk about difficulty in a future post. But for the sake of this week's topic, difficulty should be given to the player via introducing new obstacles that challenges the player's mastery of the game's controls rather than introducing new controls for them to learn. The player should only need to overcome any obstacle by using the same controls they had learned from the beginning of the game.
That's it for this week. Thanks for reading and see you next week!
Sunday, March 31, 2013
Sunday, March 24, 2013
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.
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!
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!
Monday, March 18, 2013
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).
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
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
Monday, March 11, 2013
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.
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!
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!
Sunday, March 3, 2013
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:
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
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:
- Who is running the competition?
- What is the competition for?
- What are the judges looking for?
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
Subscribe to:
Posts (Atom)