Hi everyone! It's been a while since my last post and I apologize for that. But this may become the norm as projects and work has been creeping up on me.
Now I've recently started working on a small project that involves invoking terror into the player. When I was talking to a friend of mine about it, a question came up regarding the difference between horror and terror. Some people may think that these two words are the same but there is a difference between the two.
Horror is something that comes externally. It's something we see in the world that in turn gives us fear. But terror is something that comes internally. For example, when you get scared watching a film like Nightmare on Elm Street, Critters or Friday the 13th, that's horror. But when you get scared of the darkness after watching the film, that's terror. Basically, horror is something we see whereas terror is something that comes from our mind (such as the
fear of death).
Now you may argue that some people get terrified when they see spiders, and this is true. But the terror isn't from seeing the spiders, it's from imagining them up close and seeing their fangs, eight eyes and hairy legs. They're mind soon convinces them that the spiders are crawling all over them, making them shake, jump and go crazy. That's terror.
By now you may be wondering why I'm talking about this. Well it's more to help you determine what kind of fear you wish to invoke from the player when they play your scary game. Games that are considered horror are ones such as the Resident Evil series. But one game that may be considered terrifying is Amnesia: The Dark Descent. If you've played both, you'll understand the difference in experience between the two games.
Most of the time, to invoke terror, you let the player's imaginations fill the gap because you probably can't make something as scary as what their minds can think up. So don't think that in order to scare people, you need to put in scary monsters. Sometimes, the absence of monsters can instill more fear.
Anyway, that's all for this week. I'm hoping to do another post next week but I can't promise anything. Thanks for reading!
Wednesday, July 24, 2013
Sunday, May 19, 2013
Engage First, Monetize Second
Hi everyone. Before I begin, I'm currently busy working on a table top game so I may miss a week or two of posting on my blog (such as last week).
Now let's get on with it. This week, I want to talk about engaging the audience first before trying to monetize your game. Making profit from your game is fine, but you shouldn't make this the first priority. I know this sounds stupid and perhaps moronic, but what I'm trying to say is... your first priority is to make a game that is engaging. Design your game with the aim to engage, satisfy and hook your players. When you've figured that out, then you can think of how to monetize your game. If you haven't read it already, I previously made a post in the past where I talked about micro-transactions and the do's and don't's. I recommend reading about that before continuing.
So, engaging your audience first... if you can engage the player in your game and hook them in, they wouldn't mind spending more money on your game because they will see the game as worthy of the extra dollars. This is why some people are willing to pay extra for special editions or box sets of a game. This is also how you create game loyalty.
I'm sure you've heard some players asking developers to make a game available on certain systems or re-release a game. For example, some people want Square-Enix to remake Final Fantasy 7 and some want Konami to develop Suikoden 6 or at least make Suikoden II available on the PlayStation Network. These people are willing to spend more money on games that they most likely already played. But the reason why they want this is because they loved the games.
This is your main goal, make the players fall in love with your game. If a person loves something, they won't hesitate to spend money on it (just like partners and hobbies). The thing you want players asking themselves is "is this game worthy of my time and money?". However, be careful that you aren't using the Skinner Box method to falsely engage the players. You want them to truly like your game.
If you don't know what a Skinner Box is, you should watch this video:
Skinner Box
Anyway, I'll use myself as an example. I've played many MMOs and MMORPGs since I started with Ragnarok Online back in high school (back when Ragnarok was free to play). Each one I've played, there was always a Cash Shop where you can spend money to buy extra stuff. But I never did. Then DLC content became popular and even then I wouldn't spend money on them, despite me liking the games. But last year I broke my streak with Guild Wars 2.
I had spent not only around $270 on the Collector's Edition, but an additional $180 through micro-transactions (buying both convenience and vanity items) and I may spend more in the future. Guild Wars 2 is the only game where I have spent additional money on it on top of its retail price. That's how much I love the game. Mind you, the additional content are purely optional. You can do nearly everything else in the game for free from the exploration, living stories, PvP, WvWvW and so forth.
Anyway, that's it for this week. Thanks for reading!
Now let's get on with it. This week, I want to talk about engaging the audience first before trying to monetize your game. Making profit from your game is fine, but you shouldn't make this the first priority. I know this sounds stupid and perhaps moronic, but what I'm trying to say is... your first priority is to make a game that is engaging. Design your game with the aim to engage, satisfy and hook your players. When you've figured that out, then you can think of how to monetize your game. If you haven't read it already, I previously made a post in the past where I talked about micro-transactions and the do's and don't's. I recommend reading about that before continuing.
So, engaging your audience first... if you can engage the player in your game and hook them in, they wouldn't mind spending more money on your game because they will see the game as worthy of the extra dollars. This is why some people are willing to pay extra for special editions or box sets of a game. This is also how you create game loyalty.
I'm sure you've heard some players asking developers to make a game available on certain systems or re-release a game. For example, some people want Square-Enix to remake Final Fantasy 7 and some want Konami to develop Suikoden 6 or at least make Suikoden II available on the PlayStation Network. These people are willing to spend more money on games that they most likely already played. But the reason why they want this is because they loved the games.
This is your main goal, make the players fall in love with your game. If a person loves something, they won't hesitate to spend money on it (just like partners and hobbies). The thing you want players asking themselves is "is this game worthy of my time and money?". However, be careful that you aren't using the Skinner Box method to falsely engage the players. You want them to truly like your game.
If you don't know what a Skinner Box is, you should watch this video:
Skinner Box
Anyway, I'll use myself as an example. I've played many MMOs and MMORPGs since I started with Ragnarok Online back in high school (back when Ragnarok was free to play). Each one I've played, there was always a Cash Shop where you can spend money to buy extra stuff. But I never did. Then DLC content became popular and even then I wouldn't spend money on them, despite me liking the games. But last year I broke my streak with Guild Wars 2.
I had spent not only around $270 on the Collector's Edition, but an additional $180 through micro-transactions (buying both convenience and vanity items) and I may spend more in the future. Guild Wars 2 is the only game where I have spent additional money on it on top of its retail price. That's how much I love the game. Mind you, the additional content are purely optional. You can do nearly everything else in the game for free from the exploration, living stories, PvP, WvWvW and so forth.
Anyway, that's it for this week. Thanks for reading!
Sunday, May 5, 2013
Clones, Copies and Inspirations
This week, let's talk about developing games based on existing ones from downright cloning a game to games that are inspired from existing ones.
There are at least two ways to approach designing a game. The first is to design a completely original game, which can be difficult to do at times. Everyone has a great idea but pulling it off is an entirely different matter. This can lead people to the second approach, take an existing game and develop a new one based on said game. Now this approach has a few variants.
Some people can take the laziest route and simply clone a game. This usually involves keeping all the core mechanics and changing the visuals so it looks somewhat different. An example of this is Triple Town and Yeti Town with the latter being a clone of the former game. Don't EVER take this route because you're riding on the back of someone else's success. It's even worse when the cloners don't acknowledge the game they cloned.
The next route is improving an existing game. This involves developing a game similar to an existing one except the aim is to fix its flaws and leave alone what isn't broken. Another way of looking at this route is developing a game that's inspired from an existing game.
However, this can be tricky because it can be borderline cloning. But it depends on how you handle it. For example, recently, NimbleBit released a game called Nimble Quest. When it was released, several people accused them of cloning an existing game called Call of Snakes. However, NimbleBit has said during an interview that they were inspired by the Call of Snakes game (see link below for the interview).
In the end, Nimble Quest turned out to be a great game, some saying much better than Call of Snakes. Which is great because NimbleBit not only improved on an existing game's idea, but they gave Call of Snakes credit for their inspiration.
This is how our industry moves forward. As we improve on each other's idea, we bring new innovations to the table. Also, think about this... when people clone or copy a game, they will always add at least one new feature to avoid their game being seen as a blatant clone or copy. Though it's nearly always obvious to the public, the need to add at least one new feature can be positive, negative, a new innovation or be the foundation of something revolutionary.
I've placed an interesting video of a TED talk regarding the above but in the fashion industry.
Now, I'm not promoting cloning, copying or the like... I'm merely giving you another perspective to this subject. I know it can be painful to see a game based on yours becoming more successful, but know that without your game, it wouldn't be possible.
Well, that's it for this week. I hope I've opened your minds to this part of the gaming industry. See you all next week!
[Links]
TED - Lessons from fashion's free culture: Link
NimbleBit Interview: Link
There are at least two ways to approach designing a game. The first is to design a completely original game, which can be difficult to do at times. Everyone has a great idea but pulling it off is an entirely different matter. This can lead people to the second approach, take an existing game and develop a new one based on said game. Now this approach has a few variants.
Some people can take the laziest route and simply clone a game. This usually involves keeping all the core mechanics and changing the visuals so it looks somewhat different. An example of this is Triple Town and Yeti Town with the latter being a clone of the former game. Don't EVER take this route because you're riding on the back of someone else's success. It's even worse when the cloners don't acknowledge the game they cloned.
The next route is improving an existing game. This involves developing a game similar to an existing one except the aim is to fix its flaws and leave alone what isn't broken. Another way of looking at this route is developing a game that's inspired from an existing game.
However, this can be tricky because it can be borderline cloning. But it depends on how you handle it. For example, recently, NimbleBit released a game called Nimble Quest. When it was released, several people accused them of cloning an existing game called Call of Snakes. However, NimbleBit has said during an interview that they were inspired by the Call of Snakes game (see link below for the interview).
In the end, Nimble Quest turned out to be a great game, some saying much better than Call of Snakes. Which is great because NimbleBit not only improved on an existing game's idea, but they gave Call of Snakes credit for their inspiration.
This is how our industry moves forward. As we improve on each other's idea, we bring new innovations to the table. Also, think about this... when people clone or copy a game, they will always add at least one new feature to avoid their game being seen as a blatant clone or copy. Though it's nearly always obvious to the public, the need to add at least one new feature can be positive, negative, a new innovation or be the foundation of something revolutionary.
I've placed an interesting video of a TED talk regarding the above but in the fashion industry.
Now, I'm not promoting cloning, copying or the like... I'm merely giving you another perspective to this subject. I know it can be painful to see a game based on yours becoming more successful, but know that without your game, it wouldn't be possible.
Well, that's it for this week. I hope I've opened your minds to this part of the gaming industry. See you all next week!
[Links]
TED - Lessons from fashion's free culture: Link
NimbleBit Interview: Link
Saturday, April 27, 2013
2 Meaningless Words
First, I apologize for missing last week. I had a bit of a writer's block as well as some projects I've been busy with. Now, let's begin with this week's topic. When you're talking about your game, there are two words you should avoid using - "gameplay" and "fun".
First, let's talk about "gameplay". The word arose in the 1980s during the early days of video game development. It is used to describe the overall experience of playing a video game (usually excluding sound, visuals and other external factors). However, the word "gameplay" is too vague when describing a player's gaming experience. When I describe a game to someone, I don't use "gameplay". Instead, I just go straight to describing it's mechanics, purposes and goals.
Basically, describe the game with relevant details and then let the other person determine whether your game is fun or not.
My Game Design tutor even questioned the very word itself. He told his students that the word didn't make sense to him. It was like asking a person who had just read a book "so, how was the bookread?" In fact, my tutor told us that we were never to use the words "gameplay" and/or "fun" for the remainder of our time in tertiary school.
With that said, let's move on to the word "fun". When describing your game, never use "fun" because it's subjective. What I find fun may be boring to you or vice versa. Using this word shows that you're lazy and that you don't truly understand your game. The only times you should ever use the word "fun" is when you're the player.
When you want to describe your game, take a look at it and ask yourself why people would want to play it.
Remember that one of the things you need to keep in mind when developing your game is your target demographic. If you're developing a hardcore real-time strategy game, you're going to work on things that challenges the player and/or requires them to master certain micro/macro skills. So when you're describing said game, you wouldn't just say that the game is fun, you'd say that it's challenging and skillful so your target demographic will understand.
Well that's it for this week. Thanks for reading and see you all next week!
First, let's talk about "gameplay". The word arose in the 1980s during the early days of video game development. It is used to describe the overall experience of playing a video game (usually excluding sound, visuals and other external factors). However, the word "gameplay" is too vague when describing a player's gaming experience. When I describe a game to someone, I don't use "gameplay". Instead, I just go straight to describing it's mechanics, purposes and goals.
Basically, describe the game with relevant details and then let the other person determine whether your game is fun or not.
My Game Design tutor even questioned the very word itself. He told his students that the word didn't make sense to him. It was like asking a person who had just read a book "so, how was the bookread?" In fact, my tutor told us that we were never to use the words "gameplay" and/or "fun" for the remainder of our time in tertiary school.
With that said, let's move on to the word "fun". When describing your game, never use "fun" because it's subjective. What I find fun may be boring to you or vice versa. Using this word shows that you're lazy and that you don't truly understand your game. The only times you should ever use the word "fun" is when you're the player.
When you want to describe your game, take a look at it and ask yourself why people would want to play it.
- Is it engaging?
- Is it challenging?
- Is it addicting?
- Does it bring nostalgia?
- Does it evoke a certain emotion?
- Does it encourage mastering skills?
Remember that one of the things you need to keep in mind when developing your game is your target demographic. If you're developing a hardcore real-time strategy game, you're going to work on things that challenges the player and/or requires them to master certain micro/macro skills. So when you're describing said game, you wouldn't just say that the game is fun, you'd say that it's challenging and skillful so your target demographic will understand.
Well that's it for this week. Thanks for reading and see you all next week!
Monday, April 15, 2013
Micro-transactions
Welcome to this week's topic - micro-transactions. In case you don't know what micro-transactions are, they're basically transactions that you can make inside a game in order to get additional goodies. The cost of the transactions varies as well as the type of goodies. They can be clothes for your avatar, skins for your equipment, mounts and many others.
Currently, micro-transactions are found predominantly in casual games or "freemium" games (a portmanteau of "free" and "premium"). Developers allow players to download and play their games for free as well as offer micro-transactions for players who want premium content. If you have a smart phone, chances are, you've played a freemium game. These include Subway Surfers, Tiny Tower, Pocket Frogs, My Little Pony: Friendship is Magic and Clash of Clans.
Now, micro-transactions have recently gotten bad press due to some games being harsh on the players unless they opened up their digital wallets. So let's talk about the do's and don't's when it comes to implementing micro-transactions into your game.
Sell convenience, not power
First, let's define what convenience and power are. Convenience is anything related to saving time. In an adventure game, these are things such as more storage or a faster way to travel the world (the former saves time because you don't have to go back and store your items first before continuing on your journey). Power is essentially anything related to affecting another player's experience in the game. In a first-person shooter game, these are things such as a powerful weapon or the ability to go invisible.
If your game revolves around players competing directly against other players, then I highly recommend you never sell power. This is because if you do, you're turning your game into a pay-to-win model. You want your game to be fair and balanced for all players. If not, players who won't pay or can't afford to spend as much will simply stop playing since they know that anything they do will just get trumped by the people who are spending big money on the game.
In casual games, selling power should be avoided like the plague since its demographic is basically everyone. Is it fair for a child with no money to go up against a business man with money to dump? Don't think so.
If your game revolves around players competing indirectly against other players (such as competing for first place on a leader board), then it's more excusable to sell power. This is because you're not affecting another player's experience in the game.
Sell comfortably, not forcibly
If you are planning to implement micro-transactions into your game, don't purposely make the game frustrating in the off-chance that the player will be forced to spend money just in order to play your game normally. The benefits of premium content should not be the dominant factor in your game.
Premium content should be seen, not heard
The access to the premium-content in your game should be presented in such a way that it's not in the player's face nor should it interfere with their experience. Once you've taught the player how to access the premium content, place it passively in the game's flow where it will be seen and not heard. By heard, I mean actively reminding the player about your premium content such as through roadblocks or pop-up windows.
Think of it like the pit stop in a race track where the pit stop is the premium content and the track is the player's experience. While the player drives around the track, the pit stop doesn't make any effort to interfere with the player's driving. It just stays on the side where it is merely visible to the player. While driving, if the player ever wants to access the pit stop, they can simply enter it the same way they've been experiencing the race, by driving into it (thus not breaking the player's flow).
Clash of Clans does this very well by incorporating the access to its premium content into its user interface.
Sell vanity
One thing you can sell other than convenience or power is vanity. Vanity are things such as decorative items, clothes for your avatar or new skins for your weapons. They are purely visual and players will spend money on vanity because they either want to make a statement to other players or simply customize the look of their own game. This is why some people will spend a lot of money buying expensive clothes and jewelry.
Give premium currency for free
In most games, players must first buy premium currency in order to buy premium content. If you're planning to do this, I highly suggest allowing players the ability to earn premium currency by merely investing time into your game. This will allow players to set a long term goal in your game, thus encouraging them to spend more time playing your game, and not make it seem impossible for them to obtain the premium content. This ties in with selling convenience because if the player wants the game's premium content but doesn't have the time to earn the premium currency, then they can always spend money to obtain the premium content.
Well that's it for this week. Thanks for reading and see you all next week!
Currently, micro-transactions are found predominantly in casual games or "freemium" games (a portmanteau of "free" and "premium"). Developers allow players to download and play their games for free as well as offer micro-transactions for players who want premium content. If you have a smart phone, chances are, you've played a freemium game. These include Subway Surfers, Tiny Tower, Pocket Frogs, My Little Pony: Friendship is Magic and Clash of Clans.
Now, micro-transactions have recently gotten bad press due to some games being harsh on the players unless they opened up their digital wallets. So let's talk about the do's and don't's when it comes to implementing micro-transactions into your game.
Sell convenience, not power
First, let's define what convenience and power are. Convenience is anything related to saving time. In an adventure game, these are things such as more storage or a faster way to travel the world (the former saves time because you don't have to go back and store your items first before continuing on your journey). Power is essentially anything related to affecting another player's experience in the game. In a first-person shooter game, these are things such as a powerful weapon or the ability to go invisible.
If your game revolves around players competing directly against other players, then I highly recommend you never sell power. This is because if you do, you're turning your game into a pay-to-win model. You want your game to be fair and balanced for all players. If not, players who won't pay or can't afford to spend as much will simply stop playing since they know that anything they do will just get trumped by the people who are spending big money on the game.
In casual games, selling power should be avoided like the plague since its demographic is basically everyone. Is it fair for a child with no money to go up against a business man with money to dump? Don't think so.
If your game revolves around players competing indirectly against other players (such as competing for first place on a leader board), then it's more excusable to sell power. This is because you're not affecting another player's experience in the game.
Sell comfortably, not forcibly
If you are planning to implement micro-transactions into your game, don't purposely make the game frustrating in the off-chance that the player will be forced to spend money just in order to play your game normally. The benefits of premium content should not be the dominant factor in your game.
Premium content should be seen, not heard
The access to the premium-content in your game should be presented in such a way that it's not in the player's face nor should it interfere with their experience. Once you've taught the player how to access the premium content, place it passively in the game's flow where it will be seen and not heard. By heard, I mean actively reminding the player about your premium content such as through roadblocks or pop-up windows.
Think of it like the pit stop in a race track where the pit stop is the premium content and the track is the player's experience. While the player drives around the track, the pit stop doesn't make any effort to interfere with the player's driving. It just stays on the side where it is merely visible to the player. While driving, if the player ever wants to access the pit stop, they can simply enter it the same way they've been experiencing the race, by driving into it (thus not breaking the player's flow).
Clash of Clans does this very well by incorporating the access to its premium content into its user interface.
 |
| Clash of Clans - "Finish Now" is incorporated into the UI flow |
Sell vanity
One thing you can sell other than convenience or power is vanity. Vanity are things such as decorative items, clothes for your avatar or new skins for your weapons. They are purely visual and players will spend money on vanity because they either want to make a statement to other players or simply customize the look of their own game. This is why some people will spend a lot of money buying expensive clothes and jewelry.
Give premium currency for free
In most games, players must first buy premium currency in order to buy premium content. If you're planning to do this, I highly suggest allowing players the ability to earn premium currency by merely investing time into your game. This will allow players to set a long term goal in your game, thus encouraging them to spend more time playing your game, and not make it seem impossible for them to obtain the premium content. This ties in with selling convenience because if the player wants the game's premium content but doesn't have the time to earn the premium currency, then they can always spend money to obtain the premium content.
Well that's it for this week. Thanks for reading and see you all next week!
Sunday, April 7, 2013
Self-improvement through Video Games
This week's topic will be about how games can improve a player's knowledge as well as improve certain skills. Now, I'm not talking about educational games that are created for the sole purpose of teaching the player mathematics, English, history, science or so forth. I'm talking about those times when you had learned new words or had your reflexes improved simply because of a video game you've played in the past.
Below are some of the things a player can learn from playing video games.
With all this said, it is important then to keep your information as accurate as possible where applicable. This is rather tricky for me to explain as it varies from game to game. But for example, if you are inserting the Yakuza into your game for the purpose of portraying the Yakuza and using them as they are, then make sure you do your research about them first. If you are parodying them, change their name. If it's part of an alternate timeline, make sure that this is clear to the player.
I hope that made sense to you. Just remember that as game designers, you have the power to not only educate players, but change their perspective on certain things, good or bad. So just remember that the next time you develop a game.
Anyway, I'll stop here and leave you with a link to a news story about how a young boy saved his sister using skills he learned in World of Warcraft. Thanks for reading and see you all next week!
[LINKS]
Boy saves his sister
Below are some of the things a player can learn from playing video games.
- Knowledge of a certain topic such as history, weapons, myths, etc.
- Languages
- To never give up
- Co-operaticve tactics
- Strategic planning
- The difference between good and bad
- Virtues such as patience, loyalty, chivalry, etc.
- Hand-eye coordination
- Organizational skills
- Expanded vocabulary
With all this said, it is important then to keep your information as accurate as possible where applicable. This is rather tricky for me to explain as it varies from game to game. But for example, if you are inserting the Yakuza into your game for the purpose of portraying the Yakuza and using them as they are, then make sure you do your research about them first. If you are parodying them, change their name. If it's part of an alternate timeline, make sure that this is clear to the player.
I hope that made sense to you. Just remember that as game designers, you have the power to not only educate players, but change their perspective on certain things, good or bad. So just remember that the next time you develop a game.
Anyway, I'll stop here and leave you with a link to a news story about how a young boy saved his sister using skills he learned in World of Warcraft. Thanks for reading and see you all next week!
[LINKS]
Boy saves his sister
Sunday, March 31, 2013
Easy to pick up - Difficult to master
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!
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 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
Monday, February 25, 2013
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).
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).
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!
Sunday, January 27, 2013
Designing your first game - The Basics
So you're eager to get started on your first game. What will you make? A first-person shooter that takes place in a cyberpunk setting? Or perhaps an epic adventure game about a hero who battles monsters and saves the world? I'm sure you have myriads of ideas in your head but before you begin, below are some initial advices to designing your first game.
First, take a look at your team. What do you have to work with? Are you by yourself? Do you have help from programmers? What about artists? If so, how many of them do you have? The reason for these questions is that they will help you determine what kind of game you're capable of developing. For example, if you have more artists than programmers then you may want to design a small and simple game that uses a lot of artwork. However, if you only have one artist and he or she specializes in pixel art, then maybe you want to develop a 2D game. Either way, know your team and their skills and then design your game accordingly.
Second, keep the game's design simple. Even if you have multiple programmers helping, as a game designer you need to crawl first before you can walk. Design a game where the player only needs to remember a few core actions that you can teach them all in the beginning of the game. The rest of the game can have a myriad of obstacle types for the player to overcome, but what's important is that the player will still only need to remember those same core actions in order to overcome those obstacles.
This applies to the game's assets as well such as objects and enemies. Design a handful of basic and modular assets that you can use, combine and arrange with others to create new challenges and obstacles. Now I'm not saying that you shouldn't introduce new objects or enemies to the player as the game progresses, but the more you're able to use the same assets over and over again, the more time your programmers have to polish the game. Plus, it forces you to be creative by making new things while using the same pieces, sort of like LEGO.
Third, design a game with consistent visual rules. If you have a blue flower pot that can be smashed, ensure then that ALL blue flower pots can be smashed. If there are pots that can't be smashed, make them different by perhaps colouring them red. If you don't have consistent visual rules in the game, it can break immersion as well as the player's flow. Although players can't always see what's right, they can always see what's wrong.
Well, that's about it for this post. I'll go into more advanced game design topics in future posts but this should help you get started in designing your first game. Good luck and see you all next week!
First, take a look at your team. What do you have to work with? Are you by yourself? Do you have help from programmers? What about artists? If so, how many of them do you have? The reason for these questions is that they will help you determine what kind of game you're capable of developing. For example, if you have more artists than programmers then you may want to design a small and simple game that uses a lot of artwork. However, if you only have one artist and he or she specializes in pixel art, then maybe you want to develop a 2D game. Either way, know your team and their skills and then design your game accordingly.
Second, keep the game's design simple. Even if you have multiple programmers helping, as a game designer you need to crawl first before you can walk. Design a game where the player only needs to remember a few core actions that you can teach them all in the beginning of the game. The rest of the game can have a myriad of obstacle types for the player to overcome, but what's important is that the player will still only need to remember those same core actions in order to overcome those obstacles.
This applies to the game's assets as well such as objects and enemies. Design a handful of basic and modular assets that you can use, combine and arrange with others to create new challenges and obstacles. Now I'm not saying that you shouldn't introduce new objects or enemies to the player as the game progresses, but the more you're able to use the same assets over and over again, the more time your programmers have to polish the game. Plus, it forces you to be creative by making new things while using the same pieces, sort of like LEGO.
Third, design a game with consistent visual rules. If you have a blue flower pot that can be smashed, ensure then that ALL blue flower pots can be smashed. If there are pots that can't be smashed, make them different by perhaps colouring them red. If you don't have consistent visual rules in the game, it can break immersion as well as the player's flow. Although players can't always see what's right, they can always see what's wrong.
Well, that's about it for this post. I'll go into more advanced game design topics in future posts but this should help you get started in designing your first game. Good luck and see you all next week!
Sunday, January 20, 2013
Becoming a Game Designer
I thought I'd start off with this subject simply because it's still quite fresh in my head as I've only started my career as a game designer less than 2 years ago. First of all, let me talk about what it is to be a game designer.
As a game designer, you must have some knowledge of the other fields such as programming and art. The more you know, the better you'll be. Now, this is not to say that you must have 'extensive' knowledge of them, but knowing the basics will go a long way. The reason behind this is so that you can make smart, efficient and meaningful decisions.
Let's take the design of the character Mario (originally called Mr. Video or Jumpman) from Donkey Kong. Its designer, Shigeru Miyamoto, gave him red and blue clothes so they would contrast with one another and the background, making him easier to see on screen. The overall's straps made his arms visible. His cap was to avoid drawing and animating his hair and his mustache was to avoid drawing his mouth.
Now, if you were an artist at the time, you may not think of designing a character like Mario. But Shigeru designed him with the player, art and available hardware in mind. You see... game designers, unlike the other fields, always see the game as a whole and as such, they make decisions accordingly.
Think of game designers as architects. Architects will design buildings while keeping in mind the following things:
Now let's talk about what can help you become a game designer. In the past, game designers were actually the lead programmers. But as years went by and games became more complex, a person was needed to focus entirely on game design. You can now find schools that will educate you in becoming a game designer such as DigiPen and QANTM College (which is where I studied). However, I highly recommend you do research first before applying to any school. Ensure that the school can give you what 'you' need and have the resources to give you a head start in entering the industry. You should also read up on other helpful subjects such as mythology, mathematics, psychology and story-telling. Now I'm not saying you should get a degree in these, but again, knowing the basics will go a long way.
But the best thing you can do is to just start creating games. No matter how simple or small the game is, creating games allows you to see what it takes to create them. If you don't have any ideas for a game, clone an existing one and maybe give it a little twist. If you're not a programmer, you can use starting tools like Game Maker. Game Maker has a simple drag'n'drop system to teach you how coding works and to help you visually see and understand the step by step process of programming and how events in the game work. Then when you're comfortable, you can use Game Maker's programming language (appropriately called Game Maker Language) to do real coding. From here, you can move to other advanced programs like Unity 3D. Doing all this will help you learn essential skills like scheduling, designing within limitations, balancing, lateral thinking and problem solving.
Now, I think this post is quite long enough so I'll end it here. Also, I plan to get into some of those aforementioned skills and subjects in future posts so remember to come back. I'll post a couple of links below to get you started. Thanks for reading and I'll see you all next week!
[Links]
Gamasutra
GameCareerGuide (Try doing their Design Challenges)
Extra Credits (I recommend watching all their episodes)
Game Maker
Unity 3D
As a game designer, you must have some knowledge of the other fields such as programming and art. The more you know, the better you'll be. Now, this is not to say that you must have 'extensive' knowledge of them, but knowing the basics will go a long way. The reason behind this is so that you can make smart, efficient and meaningful decisions.
Let's take the design of the character Mario (originally called Mr. Video or Jumpman) from Donkey Kong. Its designer, Shigeru Miyamoto, gave him red and blue clothes so they would contrast with one another and the background, making him easier to see on screen. The overall's straps made his arms visible. His cap was to avoid drawing and animating his hair and his mustache was to avoid drawing his mouth.
Now, if you were an artist at the time, you may not think of designing a character like Mario. But Shigeru designed him with the player, art and available hardware in mind. You see... game designers, unlike the other fields, always see the game as a whole and as such, they make decisions accordingly.
Think of game designers as architects. Architects will design buildings while keeping in mind the following things:
- What the client wants (the players of the target demographic)
- The land and surroundings (the genre)
- Design of the building's exterior and interior (the visual style)
- Materials (hardware and to a certain extent, the programmers)
- Functionality (game play)
Now let's talk about what can help you become a game designer. In the past, game designers were actually the lead programmers. But as years went by and games became more complex, a person was needed to focus entirely on game design. You can now find schools that will educate you in becoming a game designer such as DigiPen and QANTM College (which is where I studied). However, I highly recommend you do research first before applying to any school. Ensure that the school can give you what 'you' need and have the resources to give you a head start in entering the industry. You should also read up on other helpful subjects such as mythology, mathematics, psychology and story-telling. Now I'm not saying you should get a degree in these, but again, knowing the basics will go a long way.
But the best thing you can do is to just start creating games. No matter how simple or small the game is, creating games allows you to see what it takes to create them. If you don't have any ideas for a game, clone an existing one and maybe give it a little twist. If you're not a programmer, you can use starting tools like Game Maker. Game Maker has a simple drag'n'drop system to teach you how coding works and to help you visually see and understand the step by step process of programming and how events in the game work. Then when you're comfortable, you can use Game Maker's programming language (appropriately called Game Maker Language) to do real coding. From here, you can move to other advanced programs like Unity 3D. Doing all this will help you learn essential skills like scheduling, designing within limitations, balancing, lateral thinking and problem solving.
Now, I think this post is quite long enough so I'll end it here. Also, I plan to get into some of those aforementioned skills and subjects in future posts so remember to come back. I'll post a couple of links below to get you started. Thanks for reading and I'll see you all next week!
[Links]
Gamasutra
GameCareerGuide (Try doing their Design Challenges)
Extra Credits (I recommend watching all their episodes)
Game Maker
Unity 3D
Sunday, January 13, 2013
Player 1 - Ready!
Welcome to "The Beige Designer".
This will be the first of, hopefully, many weekly posts that I'll be writing about game design and the development of video games. However, I'll also throw in some game reviews or miscellaneous posts about the world of video games.
Now, do keep in mind that I'll be writing about things from my own experience or about observations that I've made. So don't think that everything I write will be globally correct and absolute. If you agree about something I wrote, great! That means I actually know what I'm talking about and you should spread the word! If you disagree, well that's fine too. You can post a comment and tell me why. It's always good to see things from a different perspective.
Well, I guess that's about it for this blog's introduction. Before I go, you can visit my website here where you'll find more information about me as well as the games I've developed so far.
See you all next week!
This will be the first of, hopefully, many weekly posts that I'll be writing about game design and the development of video games. However, I'll also throw in some game reviews or miscellaneous posts about the world of video games.
Now, do keep in mind that I'll be writing about things from my own experience or about observations that I've made. So don't think that everything I write will be globally correct and absolute. If you agree about something I wrote, great! That means I actually know what I'm talking about and you should spread the word! If you disagree, well that's fine too. You can post a comment and tell me why. It's always good to see things from a different perspective.
Well, I guess that's about it for this blog's introduction. Before I go, you can visit my website here where you'll find more information about me as well as the games I've developed so far.
See you all next week!
Subscribe to:
Posts (Atom)