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).
Monday, February 25, 2013
Sunday, February 17, 2013
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.
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.
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.
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
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
Sunday, February 10, 2013
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!
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!
Saturday, February 2, 2013
Design Review - Klonoa: Door to Phantomile
For this week's post, I thought I'd do a small design review on one of my favourite 3D platform games - Klonoa: Door to Phantomile on the Playstation and Nintendo Wii. The reason why this is one of my favourite platform games is because of the simplicity in its design. It offers simple mechanics for the player yet is able to deliver challenging environmental puzzles, enemies and bosses.
Now, this design review (and future ones) is mainly about me analysing certain features or mechanics of a game. As such, I'm not going to go through every single detail about the game. Just things I find worth noting for or some things for you to think about or be aware of. Anyway, let's get started.
First, let's talk about movement for the hero in Klonoa. Despite the game being rendered in 3D, the player can only move the hero in a two-dimensional fashion, left and right. Now, you may think that this defeats the purpose of the game being rendered in 3D but what's fascinating is that the path which the hero walks on can curve up and down as well as towards and away from the camera. This allows the designers to:
You may be thinking "well, if left and right moves the player... what does the up and down buttons do?" Well I'll tell you. Pressing the up or down button causes the hero to look at the background or foreground, respectively. This allows the player to interact with objects outside their path and allows the designers to use perspective for some of their puzzles.
Now let's move on to the hero himself. Aside movement, the hero has only 2 actions - attack and jump. As you may guess, this means that the player only has to deal with 2 other buttons. The jump button is obvious but let me explain to you about the attack button. In the game, when you press the attack button, the hero will fire a "Wind Bullet" out of a large ring he carries (in whichever direction he is currently facing). This allows the player to interact with cetain objects like switches. But if the "Wind Bullet" s an enemy, the enemy will inflate and the hero will lift them above his head like a balloon (if the hero gets damaged, they lose the inflated enemy). Now this is where it gets interesting.
When the hero is carrying an inflated enemy, the jump and attack buttons receive new functionality. Pressing the attack button again will launch the inflated enemy towards which ever direction the hero is currently facing. Launching an enemy allows the player to interact with objects from a farther distance as well as destroy other enemies or inflict damage to a boss. Once an enemy has been launched, the player must find another one to inflate. As for the jump button, pressing it twice while carrying an inflated enemy will cause the hero to perform a double jump while launching the enemy downwards (giving the same effect as if you were launching it normally).
This is by far my favourite mechanic. The fact that you need enemies in order to perform advanced actions as well as interacting with certain objects means that enemies play a much more significant role in the game rather than objects that you merely avoid. Enemies can serve as pieces to a puzzle and/or as puzzles themselves (i.e. trying to obtain an enemy could be a puzzle in itself). This also allows the designers to create a wide variety of interesting enemies. Below are a few examples (I can't find a list of their names, so I'll have to make them up):
Alright, that should be enough on this topic. I hope you enjoyed this design review. I highly recommend getting a copy of Klonoa and playing it. It was re-released on the Nintendo Wii so it shouldn't be too difficult to find this game. See you all next week!
Now, this design review (and future ones) is mainly about me analysing certain features or mechanics of a game. As such, I'm not going to go through every single detail about the game. Just things I find worth noting for or some things for you to think about or be aware of. Anyway, let's get started.
First, let's talk about movement for the hero in Klonoa. Despite the game being rendered in 3D, the player can only move the hero in a two-dimensional fashion, left and right. Now, you may think that this defeats the purpose of the game being rendered in 3D but what's fascinating is that the path which the hero walks on can curve up and down as well as towards and away from the camera. This allows the designers to:
- Design clever and interesting puzzles and levels
- Simplify the movement for the player
- Have more control in designing the each level
You may be thinking "well, if left and right moves the player... what does the up and down buttons do?" Well I'll tell you. Pressing the up or down button causes the hero to look at the background or foreground, respectively. This allows the player to interact with objects outside their path and allows the designers to use perspective for some of their puzzles.
Now let's move on to the hero himself. Aside movement, the hero has only 2 actions - attack and jump. As you may guess, this means that the player only has to deal with 2 other buttons. The jump button is obvious but let me explain to you about the attack button. In the game, when you press the attack button, the hero will fire a "Wind Bullet" out of a large ring he carries (in whichever direction he is currently facing). This allows the player to interact with cetain objects like switches. But if the "Wind Bullet" s an enemy, the enemy will inflate and the hero will lift them above his head like a balloon (if the hero gets damaged, they lose the inflated enemy). Now this is where it gets interesting.
When the hero is carrying an inflated enemy, the jump and attack buttons receive new functionality. Pressing the attack button again will launch the inflated enemy towards which ever direction the hero is currently facing. Launching an enemy allows the player to interact with objects from a farther distance as well as destroy other enemies or inflict damage to a boss. Once an enemy has been launched, the player must find another one to inflate. As for the jump button, pressing it twice while carrying an inflated enemy will cause the hero to perform a double jump while launching the enemy downwards (giving the same effect as if you were launching it normally).
This is by far my favourite mechanic. The fact that you need enemies in order to perform advanced actions as well as interacting with certain objects means that enemies play a much more significant role in the game rather than objects that you merely avoid. Enemies can serve as pieces to a puzzle and/or as puzzles themselves (i.e. trying to obtain an enemy could be a puzzle in itself). This also allows the designers to create a wide variety of interesting enemies. Below are a few examples (I can't find a list of their names, so I'll have to make them up):
- Bombers - Begins to countdown to an explosion when approached (can be used as delaying an action like hitting a switch)
- Rollers - Body is inside a round shell that allows it to roll back and forth (must wait for it to stop and pop its head out)
- Fire Magician - Surrounded by a circle of flame which spreads outwards every so often (hero must jump over flames in order to get the enemy)
Alright, that should be enough on this topic. I hope you enjoyed this design review. I highly recommend getting a copy of Klonoa and playing it. It was re-released on the Nintendo Wii so it shouldn't be too difficult to find this game. See you all next week!
Subscribe to:
Posts (Atom)