The game I'm looking at for this exercise will be Sacrifice. Published by Interplay and developed by Shiny entertainment.
This is a real-time third person strategy game that puts players in the role of a wizard who can summon creatures and cast spells based on which god they decided to ally themselves with.
The progression mechanics in the single-player campaign are very clear and visible to the player. The player does 10 missions for any god they choose. Based on their decisions, they will get different spells and creatures for each mission they complete. Creature types you get are stronger in stats like damage, range, health and abilities, and spells you get are progressively stronger, although cost more to cast.
Now that the basic progression mechanics are explained, below is a chart explaining all the resources I thought were relevant, and their relationships to each other:
This may seem complicated, and I'm planning on explaining this graph to the TA in detail. Although in basics, each colour represents a string of related resources. For a simpler example, Mana and Souls are directly related to creatures, as both resources are required to be consumed in order to get a creature. Each colour represents a direct link, or otherwise some sort of relationship between a group of resources, as several resources are often linked together for similar purpose.
The central resource, as can be guessed, is the amount of souls you have. Everything related back to souls in the end, as this is the deciding factor in a victory or defeat. Without souls, you can't do much of anything, as your wizard doesn't pose much of a threat to an entire army. Most, if not all, resources are there to help you acquire new souls, or protect your souls (creatures) from capture. A very important thing to note is that this is a zero-sum resource.
Every single soul gained is taken away from the tallies of another
player. This makes this an extremely important resource, but yet is given too much control over the outcome of the game.
Changes
As stated before, souls have a tremendous impact on the outcome of the game, much more so than any other resources. The grasp souls have over gameplay can be quite unbalanced at times, as losing one encounter early on can cost you the entire game. This is amplified by the fact that most later missions begin with heavy assaults on your army very early in the mission, most of the time when you are not yet ready.
One way I would improve this is make souls more interchangable between players, so there could be hope for retaliation when you've lost your first battle. The resource relating to this is time. There needs to be less time to acquire the resource, because gathering souls takes quite a while. For the player with the upper hand, he can afford to spend the time required casting the spell, and waiting for the soul to get converted. However, the player that is frantically trying to re-build his army has absolutely no time to both rebuild and recapture the souls that he has lost.
Tuesday, January 31, 2012
Friday, January 13, 2012
Game Design II
This blog is now for the Game Design II class that I have for the semester, and any blog posts from here on will relate to that course's material. For this post, I will be discussing the board game activity we did in lecture 1.
Rules of the game
The name of the game I played was Ligretto. This is a very fast paced card game where things get much more hectic with more players playing the game. The minimum number of players is 4, and the max is 12. Each round takes approximately 10 minutes.
Each player picks a stack of 40 cards with a unique back-suit design to call their own. Each deck contains 4 sets of coloured cards, with each set containing cards numbered 1-10. 10 random cards are put face down into a deck, and 3 more are put face up next to the deck. The rest of the cards become the player's hand.
To begin playing the game, a player must shout 'Ligretto start' once all players are ready. Players must build stacks of cards of the same colour ranging from 1-10 in sequential order. Whenever a player encounters a '1' card, they may place it on the playing area. The players may discard 3 cards at a time into a stack form their hand at any time, and can only play the topmost card. If they run out of cards in their hand, the stack is shuffled and put back into the hand. Players may also play cards from the 3 'slots' they have available to them beside their deck. If a card is played this way, the player must draw a card from their deck and replace the played card. The winning condition of the game is when a player gets rid of both their deck, and the remaining cards in their 3 'slots'. When this happens, the player shouts 'Ligretto stop'.
The score is counted up by however many cards that player has put into the piles, and each card is worth 1 point. However, any remaining cards in their deck are worth -2 points.
The rules of the game are very easy to learn, and are simple enough to be quickly picked up by anyone. This opens up the accessibility of the game to a very large amount of people, so that anyone from a circle of family/friends can easily enjoy this game without struggling to find people to play with. Not only that, but the excitement and enjoyments arrives much faster once everybody is caught up and knows the rules.
This brings me to the next thing I liked, which is the ability to accommodate a very large amount of players. I rarely see card/board games accommodate more than 6 to 8 players, which forces people to split if they are in a large group. Having the ability to support 12 people creates a single experience that can be shared between a larger group of friends, which increases the enjoyment for all. Given the accessibility the game possesses, supporting 12 players capitalizes on that and makes sure there is enough room for newer players to join in and try out a few rounds.
The pacing of the game is very quick, with short rounds offering a small energetic burst of fun. I think this is really awesome because it lessens the time investment needed from players, and becomes much easier to play the game more often. With other, longer games, people often have to plan around the fact that the game might take anywhere from 30 minutes to 2 hours to finish. Having short rounds gives people more of a chance to play this game with a larger group when not everybody can afford to drop a significant amount of time from their schedule.
Ligretto also stands out from most other card games by exercising a different skill set from players. More often than not, card/board games exercise strategic thinking, and reward thought out and well planned moves. It is a nice change of pace to have something faster that rewards good reflexes and hand-eye coordination.
Things I didn't like
The score gap between winner and losers of a round is too large. The person who shouts 'Ligretto stop' usually wins by a large amount of points, compared to all other players because they have no penalties. There were some instances where people were in a near-tie, but even then, all other players went negative. Having a -2 penalty is too harsh in my opinion, as this essentially kills any intense competition and near ties unless both players happened to dominate and be at the top of their game. If you were not leading the round, it felt like there was nothing you could really do to gain an advantage or to stop other players from depleting their decks very quickly. In all of our rounds, the person who shouted 'Ligretto stop' is the one that won, even though the rules hint at the fact that depleting your deck first may not necessarily cause a victory.
I didn't like the fact that there were no stack limits. Even between 5 people, the amount of stacks that could crop up would really slow down the pace of the game, since there was so many opportunities for people to place their cards. The over saturation of opportunities also caused players to not even notice some stacks were in play, while other players took this to their advantage to quickly get rid of their cards without anyone noticing and having a chance to react or stop them. If there was a stack limit based on the number of players, then this would bring more focus to the game.
Ligretto is very messy. Card piles often don't get cleaned up by players who finished a stack, and stacks themselves end up in a large pile which takes up quite a lot of room. Not to mention that players usually have 20+ cards in their hand, so cards tend to fly around everywhere and make a mess.
The rules of the game don't have much depth. Simplicity is a double edged sword, where in this case its easy to pick up, but also easy to put down, and forget about it completely. I could see this being fun for a couple of games, but the lack of any extra rules, special conditions or anything of that sort quickly dwindles the excitement due to repetition. Couple this with the large score gap between winners and losers, and you have a recipe for frustration. Although this is supposed to be a fast-paced game, it does not hurt to give players some sort of rule or condition to keep in the back of their minds as they play.
Cards are easy to damage. Although this is more of a nitpick than anything, it brings up the question of how durable is this game? I know for a fact that in the heat of the moment, I bent some cards (sorry prof. Nacke!) as I was trying to lift them off the table. Given the speed of play, these cards are going to go through a lot of abuse. Having them either made out of a more rigid and durable material could help prevent card damage.
One thing I would change
I would change the penalty system that is applied for players who still have cards in their deck. Out of all the things I didn't like, this was the one that bothered me the most. In the 5 games I played, 3 of them I ended up have a score of lower than -20, while the other 2 I had a score of at least 18+. This very large (almost 40 pts!) gap prevented any sort of real competition between the 5 of us.
Instead of having a 'deck' and a 'hand' I would change it so that you only have to care about the 1 pile of 40 cards that you are given at the beginning of the game. In other words, you start out with just 1 deck on the table and nothing else. At this point, players can only play cards from one source, the discard pile. However players could still utilize the 3 slots to place any cards there that they think are going to be useful soon . Players only have 3 slots however, and if their slots are all full, they can remove a card from a slot and place it face down next to their original deck, forming a secondary 'penalty deck'. If a slot gets free, players can either draw from their penalty deck and place that card into the empty slot, or put a card there from their discard pile. When the game ends, any cards in a player's slot and penalty deck are worth -2 points.
Obviously, the winning condition needs to change. The winning condition would instead rely on the amount of stacks that have been finished and the number of players that are in the game. So let's say in a 5 person game, 8 stacks need to be completed to finish the game (5*2 - 2). Some stat collection needs to be done to make this change. For example: how many stacks do players finish on average in the original game? The formula would then need be tweaked to make sure the game is long enough for people to enjoy themselves.
The idea behind this change is that players are responsible for their own penalties, rather than just be given -26 right off the bat (3 slots + 10 cards in the deck), and having to crawl out of it. This way, there is a sacrifice to be made. Initially, players only have 1 place to play their cards from, and playing only from this pile is very limiting, as you don't have a lot of options. While putting cards in their slots opens up options, it also potentially brings about penalties if you're not careful. This trains players to both look for opportunities to chain together points, and looking past their own cards to strategize. Good players will know when is the right time to put cards into their slots, and management of slots is essential to victory.
Rules of the game
The name of the game I played was Ligretto. This is a very fast paced card game where things get much more hectic with more players playing the game. The minimum number of players is 4, and the max is 12. Each round takes approximately 10 minutes.
Each player picks a stack of 40 cards with a unique back-suit design to call their own. Each deck contains 4 sets of coloured cards, with each set containing cards numbered 1-10. 10 random cards are put face down into a deck, and 3 more are put face up next to the deck. The rest of the cards become the player's hand.
To begin playing the game, a player must shout 'Ligretto start' once all players are ready. Players must build stacks of cards of the same colour ranging from 1-10 in sequential order. Whenever a player encounters a '1' card, they may place it on the playing area. The players may discard 3 cards at a time into a stack form their hand at any time, and can only play the topmost card. If they run out of cards in their hand, the stack is shuffled and put back into the hand. Players may also play cards from the 3 'slots' they have available to them beside their deck. If a card is played this way, the player must draw a card from their deck and replace the played card. The winning condition of the game is when a player gets rid of both their deck, and the remaining cards in their 3 'slots'. When this happens, the player shouts 'Ligretto stop'.
The score is counted up by however many cards that player has put into the piles, and each card is worth 1 point. However, any remaining cards in their deck are worth -2 points.
Things I liked
This is the only card game that I've seen that has no turns. I think this is a really nifty feature of this game where everyone plays at once. This means that people aren't waiting for most of their time as others get to play their turns out before they actually get to do anything. With everyone playing at once, all are engaged and no one is bored. This also opens up a new opportunity for skill-testing. Games with clearly defined turns make it easy to pay attention to other player's moves, and think of how to react to them. With this game however, it is an entire skill-based mechanic to watch what other players are doing with their cards. For people who are good at this mechanic, they may be able to chain together combos as soon as a desired card is played by a certain player that hey were observing. This is a very fast way to deplete your deck, and often nets you lots of points.The rules of the game are very easy to learn, and are simple enough to be quickly picked up by anyone. This opens up the accessibility of the game to a very large amount of people, so that anyone from a circle of family/friends can easily enjoy this game without struggling to find people to play with. Not only that, but the excitement and enjoyments arrives much faster once everybody is caught up and knows the rules.
This brings me to the next thing I liked, which is the ability to accommodate a very large amount of players. I rarely see card/board games accommodate more than 6 to 8 players, which forces people to split if they are in a large group. Having the ability to support 12 people creates a single experience that can be shared between a larger group of friends, which increases the enjoyment for all. Given the accessibility the game possesses, supporting 12 players capitalizes on that and makes sure there is enough room for newer players to join in and try out a few rounds.
The pacing of the game is very quick, with short rounds offering a small energetic burst of fun. I think this is really awesome because it lessens the time investment needed from players, and becomes much easier to play the game more often. With other, longer games, people often have to plan around the fact that the game might take anywhere from 30 minutes to 2 hours to finish. Having short rounds gives people more of a chance to play this game with a larger group when not everybody can afford to drop a significant amount of time from their schedule.
Ligretto also stands out from most other card games by exercising a different skill set from players. More often than not, card/board games exercise strategic thinking, and reward thought out and well planned moves. It is a nice change of pace to have something faster that rewards good reflexes and hand-eye coordination.
Things I didn't like
The score gap between winner and losers of a round is too large. The person who shouts 'Ligretto stop' usually wins by a large amount of points, compared to all other players because they have no penalties. There were some instances where people were in a near-tie, but even then, all other players went negative. Having a -2 penalty is too harsh in my opinion, as this essentially kills any intense competition and near ties unless both players happened to dominate and be at the top of their game. If you were not leading the round, it felt like there was nothing you could really do to gain an advantage or to stop other players from depleting their decks very quickly. In all of our rounds, the person who shouted 'Ligretto stop' is the one that won, even though the rules hint at the fact that depleting your deck first may not necessarily cause a victory.
I didn't like the fact that there were no stack limits. Even between 5 people, the amount of stacks that could crop up would really slow down the pace of the game, since there was so many opportunities for people to place their cards. The over saturation of opportunities also caused players to not even notice some stacks were in play, while other players took this to their advantage to quickly get rid of their cards without anyone noticing and having a chance to react or stop them. If there was a stack limit based on the number of players, then this would bring more focus to the game.
Ligretto is very messy. Card piles often don't get cleaned up by players who finished a stack, and stacks themselves end up in a large pile which takes up quite a lot of room. Not to mention that players usually have 20+ cards in their hand, so cards tend to fly around everywhere and make a mess.
The rules of the game don't have much depth. Simplicity is a double edged sword, where in this case its easy to pick up, but also easy to put down, and forget about it completely. I could see this being fun for a couple of games, but the lack of any extra rules, special conditions or anything of that sort quickly dwindles the excitement due to repetition. Couple this with the large score gap between winners and losers, and you have a recipe for frustration. Although this is supposed to be a fast-paced game, it does not hurt to give players some sort of rule or condition to keep in the back of their minds as they play.
Cards are easy to damage. Although this is more of a nitpick than anything, it brings up the question of how durable is this game? I know for a fact that in the heat of the moment, I bent some cards (sorry prof. Nacke!) as I was trying to lift them off the table. Given the speed of play, these cards are going to go through a lot of abuse. Having them either made out of a more rigid and durable material could help prevent card damage.
One thing I would change
I would change the penalty system that is applied for players who still have cards in their deck. Out of all the things I didn't like, this was the one that bothered me the most. In the 5 games I played, 3 of them I ended up have a score of lower than -20, while the other 2 I had a score of at least 18+. This very large (almost 40 pts!) gap prevented any sort of real competition between the 5 of us.
Instead of having a 'deck' and a 'hand' I would change it so that you only have to care about the 1 pile of 40 cards that you are given at the beginning of the game. In other words, you start out with just 1 deck on the table and nothing else. At this point, players can only play cards from one source, the discard pile. However players could still utilize the 3 slots to place any cards there that they think are going to be useful soon . Players only have 3 slots however, and if their slots are all full, they can remove a card from a slot and place it face down next to their original deck, forming a secondary 'penalty deck'. If a slot gets free, players can either draw from their penalty deck and place that card into the empty slot, or put a card there from their discard pile. When the game ends, any cards in a player's slot and penalty deck are worth -2 points.
Obviously, the winning condition needs to change. The winning condition would instead rely on the amount of stacks that have been finished and the number of players that are in the game. So let's say in a 5 person game, 8 stacks need to be completed to finish the game (5*2 - 2). Some stat collection needs to be done to make this change. For example: how many stacks do players finish on average in the original game? The formula would then need be tweaked to make sure the game is long enough for people to enjoy themselves.
The idea behind this change is that players are responsible for their own penalties, rather than just be given -26 right off the bat (3 slots + 10 cards in the deck), and having to crawl out of it. This way, there is a sacrifice to be made. Initially, players only have 1 place to play their cards from, and playing only from this pile is very limiting, as you don't have a lot of options. While putting cards in their slots opens up options, it also potentially brings about penalties if you're not careful. This trains players to both look for opportunities to chain together points, and looking past their own cards to strategize. Good players will know when is the right time to put cards into their slots, and management of slots is essential to victory.
Friday, March 25, 2011
Raptor Racers Week 10
I skipped week 9 by accident, but there has been quite a bit of progress since I last posted. The animation system is mainly done, and looks a lot smoother because I cut out the 'secondary Pose' and interpolating parameter entirely. It was not needed at all, and the animations actually look smoother and work better without it, especially transitions from pose-to-pose.
Now, with lots of help from Brent Cowan (our Graphics TA), I've developed a proper cel shader which looks totally awesome! Cel shading tutorials online (like lighthouse3D for GLSL) also helped, and provided me with information and know-how to understand how a cel shader does what it does.
Above is an image contrasting my shader vs OpenGL default lighting. There are actually 2 separate shaders working to achieve this effect.
The first shader is a shader that does the outlines. The shader file itself is actually very, very simple. All it's doing is moving a vertex along the normal to 'fatten' the model. I'm telling OpenGL to disable lighting (so that it's one solid colour), and to cull faces that face the camera, as opposed to away from the camera before the shader is actually used. The back-face colour is what makes the colour of the outline, the shader can take that as a parameter (colour) and also line width. That way, we can have different line thicknesses and colours for each object, or even a different state of the same object.
The second shader takes care of the lighting, and actually draws another teapot inside the 'fattened' version. Depending on the angle between the normal and the light, the shader just clamps diffuse/specular (etc.) values in a certain range. This can be done for a variety of light types, not just diffuse.
Small white highlights for something shiny (like a robot raptor!).
I'm not sure what the glassy effect would be used for, but I modified Brent's code for edgeGlow and fillLight to be cel shaded. It's there if we need it. All of these effects are under the lighting shader. Our game can pass a parameter to the shader and tell it to use/not use different effects (diffuse is required, obviously).
The darker areas look a bit gray due to the ambient value, I'm not sure if either looks better.
Without the ambience, the black outlines blend into the teapot, so we're going to stick with ambience for now.
Now, with lots of help from Brent Cowan (our Graphics TA), I've developed a proper cel shader which looks totally awesome! Cel shading tutorials online (like lighthouse3D for GLSL) also helped, and provided me with information and know-how to understand how a cel shader does what it does.
Above is an image contrasting my shader vs OpenGL default lighting. There are actually 2 separate shaders working to achieve this effect.
The first shader is a shader that does the outlines. The shader file itself is actually very, very simple. All it's doing is moving a vertex along the normal to 'fatten' the model. I'm telling OpenGL to disable lighting (so that it's one solid colour), and to cull faces that face the camera, as opposed to away from the camera before the shader is actually used. The back-face colour is what makes the colour of the outline, the shader can take that as a parameter (colour) and also line width. That way, we can have different line thicknesses and colours for each object, or even a different state of the same object.
![]() |
This would be something like a 'selected' effect |
The second shader takes care of the lighting, and actually draws another teapot inside the 'fattened' version. Depending on the angle between the normal and the light, the shader just clamps diffuse/specular (etc.) values in a certain range. This can be done for a variety of light types, not just diffuse.
![]() |
Diffuse + Specular cel shading |
![]() |
'Glassy' + Diffuse + Specular |
The darker areas look a bit gray due to the ambient value, I'm not sure if either looks better.
Without the ambience, the black outlines blend into the teapot, so we're going to stick with ambience for now.
Saturday, March 12, 2011
Raptor Racers: Week ... 8? I think
Wow, it's been quite a while since I last blogged, I guess my excuse would be midterms and my internet being out for two weeks, but mostly it's just me forgetting. Anyways, let's get down to business.
I remember mentioning a while ago that I wanted to implement a better animation system in our game that can support multiple blend poses (secondary and primary poses), and for the most part, I am done this system now. It works fairly differently than what we had implemented before. What happened earlier is that all the animation system would do when called is set what the next pose would be, and let the drawing function for each raptor determine the actual positions of the vertices & normals that correspond to the model. Each raptor would call this drawing function one at a time, and all of the code used to be in main, and it looked fairly ugly. The new system takes up a bit more memory, but I hope it proves itself to be more useful and flexible down the road. This new system, first of all, cleans up all of the animation code out of main, and in a special function in RaptorClass that gets called by the player and each raptor AI. I have an OCD-like tendency to clean up main as much as possible, and seperate everything into classes. Unfortunately this is a luxury when trying to code something up really fast, and this is the reason why our original animation code was all over the place. RaptorClass also recieved a couple of new member variables. One of which is fairly huge, which is an ObjLoader object. There are several huge arrays for storage of vertex/normal/texture information, and I'm not sure why they are this way. Apparently messing with the max values completely screws up our texturing, and sometimes our normals. I have a suspicion that not all the arrays need to be that huge (10,000+ max size!!!), and that only one array needs to be big enough to store all the information related to faces. I don't know though, I'd have to bring this up at the next group meeting. The other variables are pretty insignificant, and are just integer values.
One new function was written to take care of just the interpolation. The theory is that instead of drawing the object as soon as you interpolate it (our old system), you do all of the blending in one place multiple times to achieve in-betweens of different poses and store that in memory. All you'd have to do in the render function is just to draw the information that is in the variable stored in the RaptorClass (our new system). I'm hoping this will be somewhat more efficient, because the actual math is all being done in one place, and in bulk, separate from the drawing.
A pretty significant downer I did not anticipate though, is that when blending multiple poses together the latest pose often takes precedence. This produces a result that looks almost exactly the same as the previous animation system. Maybe it's just the way I'm blending, because the theory sounds to be correct.
I may tweak the code in the future for the animations to be more dynamic. Right now, I'm going to try to focus more on shaders, getting a proper HUD to work, our very simple 'level creator' or maybe trying to fix textures (using PNG's instead of BMP's due to size issues).
I remember mentioning a while ago that I wanted to implement a better animation system in our game that can support multiple blend poses (secondary and primary poses), and for the most part, I am done this system now. It works fairly differently than what we had implemented before. What happened earlier is that all the animation system would do when called is set what the next pose would be, and let the drawing function for each raptor determine the actual positions of the vertices & normals that correspond to the model. Each raptor would call this drawing function one at a time, and all of the code used to be in main, and it looked fairly ugly. The new system takes up a bit more memory, but I hope it proves itself to be more useful and flexible down the road. This new system, first of all, cleans up all of the animation code out of main, and in a special function in RaptorClass that gets called by the player and each raptor AI. I have an OCD-like tendency to clean up main as much as possible, and seperate everything into classes. Unfortunately this is a luxury when trying to code something up really fast, and this is the reason why our original animation code was all over the place. RaptorClass also recieved a couple of new member variables. One of which is fairly huge, which is an ObjLoader object. There are several huge arrays for storage of vertex/normal/texture information, and I'm not sure why they are this way. Apparently messing with the max values completely screws up our texturing, and sometimes our normals. I have a suspicion that not all the arrays need to be that huge (10,000+ max size!!!), and that only one array needs to be big enough to store all the information related to faces. I don't know though, I'd have to bring this up at the next group meeting. The other variables are pretty insignificant, and are just integer values.
One new function was written to take care of just the interpolation. The theory is that instead of drawing the object as soon as you interpolate it (our old system), you do all of the blending in one place multiple times to achieve in-betweens of different poses and store that in memory. All you'd have to do in the render function is just to draw the information that is in the variable stored in the RaptorClass (our new system). I'm hoping this will be somewhat more efficient, because the actual math is all being done in one place, and in bulk, separate from the drawing.
A pretty significant downer I did not anticipate though, is that when blending multiple poses together the latest pose often takes precedence. This produces a result that looks almost exactly the same as the previous animation system. Maybe it's just the way I'm blending, because the theory sounds to be correct.
I may tweak the code in the future for the animations to be more dynamic. Right now, I'm going to try to focus more on shaders, getting a proper HUD to work, our very simple 'level creator' or maybe trying to fix textures (using PNG's instead of BMP's due to size issues).
Friday, February 18, 2011
Raptor Racers: Week 5
Progress on the game has slowed somewhat, there are random fluctuations in progress each week. Some weeks we get together, figure out what needs to be done and actually program something that sort of works. Other weeks, like this week, the whole group mainly just focuses on assignments and generally does not touch the game code or discuss much about the game.
Although comparatively, last semester the real heavy lifting started right around after midterms. The moment we were done, we went into a sort of panic, and our group meetings increased twofold, and productivity went up substantially. I have a feeling that this will happen again, as we only have pretty much 1 month and a bit to complete the requirements for our game. We only have 3 midterms to study for though, and that will put a substantially lower amount of stress on the whole group as a whole.
A new group member has also joined us a while back. This is a new unexpected twist that we will have to work around. It is quite difficult to assign tasks to this group member because a lot of context needs to be provided to him in order for him to be an effective group member. All of our group members already have specific roles that they fulfill, and adding one more group member in is giving us a more difficult time than it should.
Another thing that is giving me issues is that we definitely need to start learning how shaders work. At this point in time we have no idea how difficult they are going to be to implement. From what I hear and have researched, it could be as easy as telling OpenGL to run a separate piece of code during it's rendering stage, or as difficult as writing your own shader code that effectively simulates real world materials. It's great that various teachers are telling us to prototype and plan out before setting out to program and create art for the game. I agree, and this works well with people who already know at least some of what they are doing. Unfortunately for students, this is not the case. We are learning as we go, and we have no idea how long some aspects will take to implement, or how difficult it will be to even implement simple game mechanics (like jumping for our Raptors). This makes planning, brainstorming and idea generation in general incredibly difficult.
Although comparatively, last semester the real heavy lifting started right around after midterms. The moment we were done, we went into a sort of panic, and our group meetings increased twofold, and productivity went up substantially. I have a feeling that this will happen again, as we only have pretty much 1 month and a bit to complete the requirements for our game. We only have 3 midterms to study for though, and that will put a substantially lower amount of stress on the whole group as a whole.
A new group member has also joined us a while back. This is a new unexpected twist that we will have to work around. It is quite difficult to assign tasks to this group member because a lot of context needs to be provided to him in order for him to be an effective group member. All of our group members already have specific roles that they fulfill, and adding one more group member in is giving us a more difficult time than it should.
Another thing that is giving me issues is that we definitely need to start learning how shaders work. At this point in time we have no idea how difficult they are going to be to implement. From what I hear and have researched, it could be as easy as telling OpenGL to run a separate piece of code during it's rendering stage, or as difficult as writing your own shader code that effectively simulates real world materials. It's great that various teachers are telling us to prototype and plan out before setting out to program and create art for the game. I agree, and this works well with people who already know at least some of what they are doing. Unfortunately for students, this is not the case. We are learning as we go, and we have no idea how long some aspects will take to implement, or how difficult it will be to even implement simple game mechanics (like jumping for our Raptors). This makes planning, brainstorming and idea generation in general incredibly difficult.
Wednesday, February 9, 2011
Raptor Racers: Week 4
The pace has definitely picked up since last week, we are having coding sessions at our group meetings which tells me we are on the right track. Even if we may not necessarily have the design of the game completely done yet, it is a good idea to start coding early. We are starting to talk about our code in more detail and depth, and I'm starting to understand more and more of the code base, and understand what needs to be improved. I've revised the animation system slightly, but I'm afraid I might have to gut the entire system and start from scratch. While the animation system Dan Cortens wrote for last semester was functional for the game and produced a relatively good looking result, the code was a little messy. Given that we were under pressure to complete the game as fast as possible, we didn't have time to make the code more efficient and neat.
Now that I am trying to add more animations to our Raptor (the ones I mentioned in week 2), I found out that the code for the animation system is not very extensible. Part of this was because my old method for animation was to spit every single frame out from Maya as an .obj file. This turned out to be 48 different .obj files for the running sequences alone (each sequence was 16 frames long). After figuring out that this was silly, I cut down the amount of files by a factor of 4. My key-frames in Maya happen every 4th frame, so it is only logical that I only export those out instead, which cuts down our loading time. The system doesn't really account for these new number of frames, not to mention it has to handle the interpolating parameters differently. For example, if the player just taps a key to turn right, the animation always finishes interpolating to the next frame before moving back (the Raptor completely swings its neck around, as if it is making a sharp turn). I want it so that the system only interpolates a percentage to the next frame, and if the key is released before it reaches it's target frame, it interpolates back to the original pose. This will make the Raptor look more natural when it is turning, or doing anything else for that matter. This way I also have much more control if I can manipulate the percentage of the animation, instead of just the next pose.
The goal for the next week or two is to have at least a working animation system, after I'm done that, it's time to implement all of the animations themselves and play around with the movement mechanics and see what feels right. After all, the animation and game play have to be matched at least somewhat or else it will look silly.
Some things that are still on our to do list: Fixing textures, lighting, figuring out shaders, completing the design, particle systems, shadows(?), and a whole bunch of other stuff. I want to make our animations as nice looking as possible before we move on to harder things that are required (mainly shaders, and other business/design docs that are requirements).
Now that I am trying to add more animations to our Raptor (the ones I mentioned in week 2), I found out that the code for the animation system is not very extensible. Part of this was because my old method for animation was to spit every single frame out from Maya as an .obj file. This turned out to be 48 different .obj files for the running sequences alone (each sequence was 16 frames long). After figuring out that this was silly, I cut down the amount of files by a factor of 4. My key-frames in Maya happen every 4th frame, so it is only logical that I only export those out instead, which cuts down our loading time. The system doesn't really account for these new number of frames, not to mention it has to handle the interpolating parameters differently. For example, if the player just taps a key to turn right, the animation always finishes interpolating to the next frame before moving back (the Raptor completely swings its neck around, as if it is making a sharp turn). I want it so that the system only interpolates a percentage to the next frame, and if the key is released before it reaches it's target frame, it interpolates back to the original pose. This will make the Raptor look more natural when it is turning, or doing anything else for that matter. This way I also have much more control if I can manipulate the percentage of the animation, instead of just the next pose.
The goal for the next week or two is to have at least a working animation system, after I'm done that, it's time to implement all of the animations themselves and play around with the movement mechanics and see what feels right. After all, the animation and game play have to be matched at least somewhat or else it will look silly.
Some things that are still on our to do list: Fixing textures, lighting, figuring out shaders, completing the design, particle systems, shadows(?), and a whole bunch of other stuff. I want to make our animations as nice looking as possible before we move on to harder things that are required (mainly shaders, and other business/design docs that are requirements).
Sunday, February 6, 2011
Formal Critique of Dead Space 2
Dead Space 2 is a sci-fi survival horror game that is developed by Visceral Games and published by Electronic Arts. The player takes control of Isaac Clarke, a former space engineer in the 26th century who is now a mental patient. Imprisoned on The Sprawl, a dense urban city on Titan (Saturn's largest moon), Isaac must escape death and dementia in time to destroy the marker responsible for the necromorph outbreak.
Main 4 elements
Story
To give a brief context of the story: Isaac wakes up in an insane asylum and is being interrogated. He has flashbacks of his dead girlfriend who was serving on the ship called the USG Ishimura. We are informed with her video log that Isaac encouraged her to serve aboard the Ishimura, where a horrible outbreak of necromorphs killed the entire crew. She then commits suicide at the end of the video log. This feeling of guilt is the main driving force that pushes Isaac on to continue the fight against the most recent necromorph outbreak. He isn't exactly mentally stable, as his hallucinations sometimes try to forcibly make him commit suicide. These apparitions act as a mirror, where by observing them we get a glimpse into Isaac's perception of other characters, particularly his dead girlfriend. I feel that this is a very effective way of developing a character without using dialogue, as visual and auditory cues give you some feedback about Isaac's insanity.
At first, it isn't known how, or why a necromorph outbreak is happening which gives a sense of mystery around it, and at the same time a sense of confusion. This approach to storytelling sometimes feels cheap, because you tossed right into a dark and empty world without being given much context. The reason why this applies especially to this game is because Isaac is located inside of a once-sprawling metropolis which is now devoid of life. If the outbreak happened moments ago, where did everybody go? Where are the civilians and other members of society who were going along in their daily lives? There is no way an evacuation could have happened that quickly in a place that huge. I found this rather confusing, and every time I looked out the window to see an entire cityscape of well lit skyscrapers, all with no signs of life in or around them. Perhaps this was the intention, but again, the player needs to be provided some sort of context to compare his/her current state to. An example would be looking out the window to see chaos emerge from around your surroundings, as evacuation dropships scramble to shuttle people out of the vicinity. To follow up, in a later scene, the outside world would be shown as devoid of life, and only you are left behind to face the menace.
![]() | |
I doubt the city would look this intact if it was inhabited entirely by necromorphs. |
The story is the main driving force of the whole game, and the player always wants to know what's going to happen next. There are unexpected betrayals by a few NPC's, and the fact that there are so few other people you can actually interact with, this does impend a desperate will to survive.
The NPC's never actually fully interact or help you in any way, except with a few scripted sequences. There is a certain encounter that you actually get to see them physically, rather than by your RIG communicator (it provides visual data of the speaker on the other end). By doing this, the story does teach you to be more of an independent player, because companions definitely make the scene a lot less terrifying if you have someone by your side. However this does feel like a cheap shot at some points, if Isaac is really just an ordinary engineer, then how come there are barely any other survivors? Surely the security personnel were actually trained in combat, and have heavier body armour than Isaac.
In video games the player is usually a very powerful entity to be reckoned with, but most games don't bother explaining why this particular person is so good at what they do (Ex. Gordon Freeman, you are an MIT graduate, how does theoretical physics translate to exceptional physical ability?). I feel as if Dead Space 2 somewhat falls into this trap. Isaac is supposed to be a 43 year old systems engineer, but somehow feels as if you are some sort of trained biological hazards soldier. This isn't a gamebreaking story loophole, but it does raise a lot of questions later on in the game. Particularly when you are caught by surprise by at least a couple dozen soldiers trying to kill you. You manage to escape and shut off the power, causing necromorphs to break into the facility. But those dozens of armed men can't deal with a few necromorphs? Isaac alone must have taken down an entire town's worth of necromorphs throughout the course of the game.
In conclusion, the overall story was of a cinematic quality, and we see a pretty dramatic character change in Isaac towards the end. The ending was put together in a satisfying way, and even added a bit of comical relief by mimicking the ending of the previous game, but with less horrifying results. Overall, it is an interesting experience that shines light onto the human psyche, and explores themes of loss, fear and acceptance.
Aesthetics
The visuals in Dead Space 2 always have a moody and atmospheric feel to them. Lighting is the key component of creating atmosphere in a horror game. To create a sense of dread, or fear, the lighting designers have manipulated light in such a way that it is either your 'friend' or your 'enemy'. In many scenarios, well lit rooms are a welcome sight when you've been in dark corridors, being ambushed by monsters. Softer, warmer colours are used for 'safe' areas, as the light bleeds on to every surface, revealing that there are no threats in this room. Other more hostile rooms are harshly lit, creating long ominous and looming shadows that envelop the room, as if trying to swallow you whole. The colour of the light has an 'industrial' feel in more hostile areas, giving off a cold, unforgiving feeling to the atmosphere.
Sometimes the lighting is purposely absent, gone entirely so the only thing you see is whatever your flashlight illuminates. This amplifies the intensity in the scene, as you are usually swarmed with monsters shortly after.
Creating atmosphere can't be done by visuals alone, but a good sound design philosophy can have just as much impact as visuals. Dead Space 2 certainly does not lack in the sound department. Every single room has some sort ambient sound, there is always a hissing of gas, crackling electronics or even whispering voices. This makes the environment feel alive, and at the same time feels as if it is dying. You can really get a sense of damage when walking by and hearing lots of electricity sparkles, metal groans, shards of broken glass under your feet, and litter being kicked around on the floor.
Comparatively, the various shrieks and groans the necromorphs produce have a certain chilling quality to them. If you are exploring a room, certain sounds can sometimes be mistaken for a low hiss or growl of a necromorph, which always keeps you on your toes. However, a lot of the monsters do sound similar. With a few exceptions, the distinctions between the different monster types can only be differentiated by visual cues.
Monster designs in this game offer a certain disturbance to them once that you realize they entirely consist of morphed human beings and body parts. It's not just your typical 'zombie' look either, they have all sorts of mutations and horrifying modifications done to the original host body.
I noticed though that this monster design philosophy is a common occurrence in triple A horror titles. I feel like this is a compensation for giving the player weapons. Once you give the player a means of defeating his foes, a very large chunk fear is lost. This empowers the player, and makes him/her feel less vulnerable, and in turn makes the player less fearful of the environment. In contrast, a game like Amnesia: the dark descent has absolutely no means of defeating your foes, and this certainly intensifies the fear tenfold, which is horror done right. However, the actual game isn't that fun after the first playthrough. Dead Space 2 approaches horror with guns blazing, and by the end of the game, instead of feeling fear, you are slightly annoyed by the occasional monster or two.
The environment itself is an empty place, and devoid of life, but the designers made sure it feels like it had a history. Shopping malls have all sorts of garbage laying around on the floor, store lights and advertisements are still on. There is a scene where a surgery was abandoned halfway through, and you have to help the patient free. You can also feel a sense of damage when walking around infested areas. Some doorways are lit on fire, walls have massive holes in them, wires are hanging out and sparking in every which direction.
The art assets and visual effects are fantastic, and very highly detailed. There are also a very large variety of effects, one of the cooler ones that I distinctly remember is that once you enter zero-G, you could actually see blobs of liquid and all sorts of particles floating around, suspended in the air. Little things like that really immerse you in the environment, and really feel as if you are there.
What increases immersion further is lack of any sort of 'menus' and GUIs (besides the pause menu of course). All the information you need to know are neatly visualized on Isaac's suit itself. His health appears as a tube on his back, and the stasis meter is right beside it. When reading your weapon, the current amount of ammo is shown holographically on the weapon itself. The crosshair is represented by blue laser pointers. Nothing feels out of place, and every piece of information the player needs to know is presented in a very believable way. Even the inventory screen is projected in front Isaac, and as the player makes selections, Isaac's head looks at the item. Again, it's the small things like that that really show the amount of effort that went into the development of the game.
![]() |
An example of Dead Space 2's GUI in gameplay |
Mechanics
The main gameplay mechanic revolves around dismemberment. You will waste a lot of ammo simply trying to shoot necromorphs dead. In order to effectively take down any creature, you have to dismember it to make it useless. This holds true for smaller and larger monsters alike, and even Isaac himself. In various execution moves that the enemies can achieve on you, Isaac is usually torn apart limb from limb, which is sort of a twisted sense of irony.
![]() |
If a monster grabs you, tapping the action button will break you out of the hold. If you are low on health, then you are out of luck. |
The tools at your disposal are various industrial machines, and one military grade assault rifle. Each weapon has a primary and an alternate fire. Both types of firing mechanisms consume from the same pools of ammo, which handy because your inventory usually can only hold a limited amount of items. A lot of the tools strangely seem to be almost too useful for dismembering limbs. It is never really explained in gameplay how these tools are actually useful for the engineer. For example, what exactly is the line gun used for? It fires a wide beam of plasma, and is almost too suitable for dismembering limbs.
Another strangely suspicious 'industrial tool' is the detonator, where it shoots a proximity mine on the floor (alt fire disables the mine). What use would a proximity mine be to an engineer? It's more of a military tool if anything. It would be nice if instead of collecting schematics for different weapons in a random order, you would find them in sequence. Once you buy the weapon, you would have to solve a puzzle that teaches you how to use the weapon correctly. Before I provide an example, I'm going to change the mechanics of the detonator slightly. Instead of laying down a 'proximity mine' the detonator would instead remotely detonate the mines (as the name suggests). Place a mine anywhere you want by pressing the primary fire, and you could put down as many as you have ammo for. Tap the alt-fire button to detonate the first mine in the sequence, or hold to detonate all mines. If you want to acquire your mine back, just walk up to it and press the action button to pick it back up into your inventory. This now mimics a useful tool for a miner, or an engineer by resembling either TNT to blast apart rocks, or a demolition tool. When the player acquires this weapon, there could be a small puzzle, like blasting apart obstructing debris for example. It could be placed in such a way when detonating the mines right away would be a poor idea, like in an elevator shaft. Let's say it is zero-G and an elevator is blocking your way up the elevator shaft. To get rid of it, you need to blast apart the emergency brakes in order to make it mobile, and attach a thruster rocket to the bottom to move it out of the way. This simultaneously gives the player a context for the weapon/tool to be in existence, and teaches the player the mechanics of the weapon, so that they can use it against the enemy correctly later on.
Speaking of puzzles, these are usually there to break pace from the constant anticipation and fear, with something that is engaging and usually less threatening. The actual puzzles themselves usually only utilize the stasis feature of the suit, where any object/enemy is slowed down significantly, or kinesis, where you can pickup objects from far away with a bolt of energy. There are some that also use a thruster rocket, where when it can be attached to various objects. Most of these puzzles are fairly obvious and don't require much timing/thought. It would be nice if the puzzles incorporated the use of your industrial tools to solve it, like in the example above. Of course ammo would have to be provided somehow in case the player has trouble figuring it out.
![]() |
Sometimes a hacking mini-game is also used in puzzles |
Another neat feature is that the player can use environmental hazards to defeat his enemies. There are stasis and explosive canisters that can be thrown at enemies using kinesis. There will sometimes be a pane of glass that can be shot in order to create a vacuum. The resulting force sucks everything out of the room, and this can include you if you don't shoot an emergency switch in time which activates a door shutting mechanism. If you don't do it in time, the door will crush you, providing a trade-off to using this environmental hazard.
The resource systems in this game are fairly standard, and don't offer too much in terms of innovation. The player has health, stasis and air. Stasis is used to slow down objects/enemies, which can be useful when getting swarmed by monsters, and air is used to put a limitation on the time a player has by putting him/her in a vacuum. The suit provides you with a limited amount of oxygen, where usually at the same time you have to solve a puzzle or run to an adjacent room that contains air. Health is pretty self explanatory.
There is a standard concoction of items that can be found lying around either in the open, hidden in a crate, or inside a monster (pops out after defeating it). Usually it's things like health packs, ammo, power nodes (used to upgrade your armour and weapons), schematics (used to 'invent' new things to buy), and credits. Schematics are neat because in order for you to buy anything at the shop, you have to have a schematic for it first. The shop 'downloads' it, and presumably makes it for you right there on the spot. This encourages players to explore, as they are usually hidden out of view or in hard to reach areas. Credits are a pretty obvious resource that player usually scrounges for, especially on higher difficulties where items are less likely to be found or dropped by monsters.
Overall, the mechanics of the game form a simple system that complements itself well. There is a lot of room for improvement in terms of player experience, puzzles and minor issues with the weapon sandbox design. Otherwise it is a solid experience that can hold its own against other major triple A action/horror titles.
Technology
Dead Space 2 is available on the PC, PS3 and Xbox 360, and from the looks of it, it continues to push the boundaries of what consoles and modern PC's can accomplish. Lots of shader effects, particle systems, dynamic lighting and other technologies are implemented. The lighting effects are phenomenal, and a dedicated lighting team was used to specifically light every scene the player encountered in the 12-hour single player mode.
To get a better grasp of what the lighting is like in Dead Space 2, here is a perspective from the dev team themselves:
Subscribe to:
Posts (Atom)