Dear Dr. Hogue:
It has come to my attention that I need to learn about prioritizing. As fun as these blogs are, they have become a nuisance and are cutting into time I would rather be programming. No offense as I don't mind blogging and personally I am a natural writer, but I really need to focus on getting the homework questions done.
With that said I have two different homework questions for you tomorrow. Its been quite a while since I handed in the 'blue' shader but I've been valiantly struggling with the obj lerp and particle system shaders. I slowly worked through all those awful errors (glMultiTexCoord and ESP stack pointer error argh) and got on a roll. Again I hit a wall and struggled to figure out the final touches of the programs (I'm a slow/inefficient coder) but here we are.
I will still try to maintain my blog posts but at the moment not being able to write the final exam is obviously my biggest concern. Lately I've been working on modelling/texturing for our game but I'm all shaders now. Hopefully I'll have lots more to show you soon. At this point I'm really not sure about my chances of getting 40exp, but I'm going to try my damn hardest until the very end.
I hope you can understand,
-Taylor
Monday, March 12
Tuesday, March 6
Ray Tracing vs Radiosity
Over halfway into the semester we've starting touching on subjects that I can't really wrap my head around, so this week I did some extra research on ray tracing and radiosity, and I'm going to compare the two. After I might look for some games with each style of lighting and see how they compare.
http://www.ultrashock.com/forum/viewthread/54289/
This forum thread helped distinguish the differences between the two and summarize how each method works.
The main difference is that ray tracing is dependant on the camera position, while radiosity works fine with any arbitrary camera in the scene. This means that any significant change in the camera's position will result in all the rays needing to be re-calculated again which is a relatively costly operation. Ray tracing sends the rays out of the camera and they bounce around a certain number of times before they are gone.
Radiosity can be considered an extension of ray tracing, in that they can both be used to make a scene look very good. It is calculated from the actual light sources, and the diffuse reflections of the light in the geometry of the scene. Calculating radiosity is very processor intensive but can produce more realistic results, and can be pre-calculated if the scene's light sources do not move.
An additional advantage of radiosity is that it can simulate colour bleeding from one surface to another. Since the calculations for radiosity only need to be done once, static scenes can take a lot less processing overall because you can freely move a camera around the scene after the calculations are performed. To get the best result, a combination of both methods will work but the best, but be the most taxing to compute.
http://www.gametrailers.com/user-movie/raytracing-vs-radiosity-tech/182176
This video demonstrates the major differences the two methods can produce.
http://www.ultrashock.com/forum/viewthread/54289/
This forum thread helped distinguish the differences between the two and summarize how each method works.
The main difference is that ray tracing is dependant on the camera position, while radiosity works fine with any arbitrary camera in the scene. This means that any significant change in the camera's position will result in all the rays needing to be re-calculated again which is a relatively costly operation. Ray tracing sends the rays out of the camera and they bounce around a certain number of times before they are gone.
Radiosity can be considered an extension of ray tracing, in that they can both be used to make a scene look very good. It is calculated from the actual light sources, and the diffuse reflections of the light in the geometry of the scene. Calculating radiosity is very processor intensive but can produce more realistic results, and can be pre-calculated if the scene's light sources do not move.
An additional advantage of radiosity is that it can simulate colour bleeding from one surface to another. Since the calculations for radiosity only need to be done once, static scenes can take a lot less processing overall because you can freely move a camera around the scene after the calculations are performed. To get the best result, a combination of both methods will work but the best, but be the most taxing to compute.
http://www.gametrailers.com/user-movie/raytracing-vs-radiosity-tech/182176
This video demonstrates the major differences the two methods can produce.
Monday, March 5
Examining Linearity
As with most weeks I like to brainstorm a topic in digital games and then delve into it, comparing its various aspects. During this process I saw my Skyrim map poster hanging up to my left and it got me thinking about a topic I don't fully understand: the difference between linear and open-ended games.
Well obviously I know the difference between them, but I'm trying to figure out the reasons that both of them are appealing to players despite being at opposite ends of the spectrum. Furthermore I want to examine the MDA's behind these reasons to really get an idea of why these two different styles both captivate their audience.
Most RPG's and nearly all MMO's fall into the category of being open-ended games, featuring a large game world to explore. Going to the core of the avocado, in an open game your character may navigate the world at your discretion and go where you want, went you want. You can run, jump, swing your sword/use magic, harvest raw materials, and interact with the world's inhabitants. This means that every action is your choice, from fighting a bear to climbing a mountain to simply wandering aimlessly.
These mechanics develop the major dynamics such as exploring the wonders of the world and fighting creatures along the way. For example the player could run into a gigantic elite monster or find a creepy cave system to traverse. In MMO's a bold player can travel to areas with higher level enemies to test his combat abilities, or group up to tackle even greater foes. The idea is that each player may play at their own pace and with their own methods and preferences.
The aesthetics that come out of it are visually stimulating game worlds with awe-inspiring locales and a strong feeling of being immersed within a living, fluctuating environment. The player makes a journey out of the game instead of going on the game's journey. Expansive worlds like this take a lot of detail and effort to create but done well they can give a player many hours of enjoyment. Tons of unique quests, environments, enemies, and items can give these worlds a lot of depth and replay value.
Players enjoy this sense of freedom and exploration because we are naturally curious. Secrets and unanswered questions push the player to continue searching and discovering new things. Many of the choices in open games are big and lead down very different paths based on where the player chooses to go. This can be said for choosing your character's class and skills as well, as there are usually many to pick from and will make a big impact on the player's experience in the game.
The true downside to a huge game world is that sometimes it feels like nothing is extra-special in it. A lot of time is needed to create that much content, so the highlights are few and far between. Comparing this to a game like Uncharted, and its on a whole different level.
Linear games usually involve moving to the next area, shooting everything/navigating through the level, and repeat. The mechanics are actually very similar to an open game in terms of player navigation and possible actions they can perform. The difference comes from how the player is able to interact with their world, and the pacing of the action.
A linear game does not wait around for players to discover things or find secrets; there is almost always something going on. The dynamics in a linear game are how players must fight against increased numbers of enemies in more enclosed environments, kind of like a funnel. An analogy is being on a water-slide compared to a wave pool at an amusement park. In both settings there is moving water (conflict), but it presented to you at a different pace and you may choose to leave the wave pool.
Because the player in a linear game cannot pick and choose what experiences they have in the game, they often contain more dynamic engagements and unique elements. The Uncharted series is based off very intense 'set pieces' which are basically scripted events on a large scale. Each set-piece will happen once throughout the game's story line and is a memorable experience for players.
This set piece piece occurs in a sinking cruise ship, and the goal is simply to escape with your life. The player only has one path to follow through the level, but the dynamic and frantic nature of the level makes for a very memorable experience. It is moments like these that linear games focus on to make up for not having sprawling environments for the player to explore.
The aesthetics of these levels are often designed with great attention to detail to really keep the player in the moment. Because the designers don't need to create as many elements, they can focus on certain parts of the game in order to perfect them. Players thrive on these moments as the adrenaline gets pumping and they must keep focused in order to beat the level. It is a very different experience from an open game, but it is equally as enjoyable.
Many players like a continuous stream of action and linear shooters/adventure games deliver this with abundance. From taking on scary bosses to fighting off waves of enemies, linear games are meant to take a player through the whole experience without ever slowing down. From personal experience I've played both types of games, and what makes each type special is mutually exclusive from the other. I enjoy both types of games equally despite the very different sides they take on pacing and level design.
 |
| The expansive province of Skyrim; fully explorable from top to bottom. |
Most RPG's and nearly all MMO's fall into the category of being open-ended games, featuring a large game world to explore. Going to the core of the avocado, in an open game your character may navigate the world at your discretion and go where you want, went you want. You can run, jump, swing your sword/use magic, harvest raw materials, and interact with the world's inhabitants. This means that every action is your choice, from fighting a bear to climbing a mountain to simply wandering aimlessly.
 |
| If you can see it, you can go there. |
 |
| Ragnaros, a final boss in WoW. |
Players enjoy this sense of freedom and exploration because we are naturally curious. Secrets and unanswered questions push the player to continue searching and discovering new things. Many of the choices in open games are big and lead down very different paths based on where the player chooses to go. This can be said for choosing your character's class and skills as well, as there are usually many to pick from and will make a big impact on the player's experience in the game.
 |
| A few of the 15+ skills you can train in Skyrim. |
For
example in Skyrim there are various different questlines in different
guilds, and the player is free to do them (or not) in any order they
choose. I personally know that lots of players like to experience all
the other content before completing the main questline because it
usually contains the most intense set pieces and makes for a good
climax.
The true downside to a huge game world is that sometimes it feels like nothing is extra-special in it. A lot of time is needed to create that much content, so the highlights are few and far between. Comparing this to a game like Uncharted, and its on a whole different level.
 |
| Hellfire Peninsula is a big area...and it can get a little bland. |
Linear games usually involve moving to the next area, shooting everything/navigating through the level, and repeat. The mechanics are actually very similar to an open game in terms of player navigation and possible actions they can perform. The difference comes from how the player is able to interact with their world, and the pacing of the action.
A linear game does not wait around for players to discover things or find secrets; there is almost always something going on. The dynamics in a linear game are how players must fight against increased numbers of enemies in more enclosed environments, kind of like a funnel. An analogy is being on a water-slide compared to a wave pool at an amusement park. In both settings there is moving water (conflict), but it presented to you at a different pace and you may choose to leave the wave pool.
Because the player in a linear game cannot pick and choose what experiences they have in the game, they often contain more dynamic engagements and unique elements. The Uncharted series is based off very intense 'set pieces' which are basically scripted events on a large scale. Each set-piece will happen once throughout the game's story line and is a memorable experience for players.
This set piece piece occurs in a sinking cruise ship, and the goal is simply to escape with your life. The player only has one path to follow through the level, but the dynamic and frantic nature of the level makes for a very memorable experience. It is moments like these that linear games focus on to make up for not having sprawling environments for the player to explore.
 |
| The stakes don't get any higher than this! |
Many players like a continuous stream of action and linear shooters/adventure games deliver this with abundance. From taking on scary bosses to fighting off waves of enemies, linear games are meant to take a player through the whole experience without ever slowing down. From personal experience I've played both types of games, and what makes each type special is mutually exclusive from the other. I enjoy both types of games equally despite the very different sides they take on pacing and level design.
Monday, February 27
Reflecting on Flow
Well obviously as an avid gamer I know about the flow.
What was said in the audio lecture about getting into the game flow state really connected with me. Especially in high-pressure moments in games like Guitar Hero and 2D twitch-shooters (kind of like asteroids but crazy), all my focus is on the game and surviving the level.
With respect to the flow chart, the major example that came to mind was Guitar Hero. It was an early birthday present for me several (quite a few) years back to get my mind off of getting dumped by my girlfriend. I started on easy and went through the entire game start to finish, then did the same on medium, then on hard. A whole month shot by as I gained GH skills and was eventually playing on expert.
I remember at the time that it was the only activity which could get my mind off sad thoughts. Despite everything going on in my life, when I got into the flow state playing GH it all disappeared (thankfully), as I lost all self-awareness. From this example I could see how often I've experienced the flow state without every knowing what it really was. The hours of dungeon-grinding and adventuring throughout the years didn't seem like much time at all.
Recently in my spare time I found a little game called Scoregasm to get my mind off things. It is the aforementioned twitch-shooter, and it certainly is crazy. The level of concentration needed to survive requires the flow state. Anything less and your brain cannot process the information fast enough for you to react and dodge the incoming enemies and lasers.
It doesn't apply just to these types of games though. Any game that can keep me interested and engaging will have me whittling away the hours in a flow state. I think its a really cool theory and that game designers should really focus on striving that perfect balance between the flow chart axes. This will keep gamers entertained and coming back for more.
What was said in the audio lecture about getting into the game flow state really connected with me. Especially in high-pressure moments in games like Guitar Hero and 2D twitch-shooters (kind of like asteroids but crazy), all my focus is on the game and surviving the level.
With respect to the flow chart, the major example that came to mind was Guitar Hero. It was an early birthday present for me several (quite a few) years back to get my mind off of getting dumped by my girlfriend. I started on easy and went through the entire game start to finish, then did the same on medium, then on hard. A whole month shot by as I gained GH skills and was eventually playing on expert.
I remember at the time that it was the only activity which could get my mind off sad thoughts. Despite everything going on in my life, when I got into the flow state playing GH it all disappeared (thankfully), as I lost all self-awareness. From this example I could see how often I've experienced the flow state without every knowing what it really was. The hours of dungeon-grinding and adventuring throughout the years didn't seem like much time at all.
Recently in my spare time I found a little game called Scoregasm to get my mind off things. It is the aforementioned twitch-shooter, and it certainly is crazy. The level of concentration needed to survive requires the flow state. Anything less and your brain cannot process the information fast enough for you to react and dodge the incoming enemies and lasers.
Part Two
Since I don't really have much else to talk about right now, I will continue to talk about my programming woes and triumphs. Firstly I'd like to say I have my object loader working perfectly fine, and things are good on that front. It can load in multiple objects in different viewports, so now I just need to get lerping!
On the other hand, the particle system is...halfway there. I got glMultiTexCoord working as it is supposed to, but this resulted in a rather nasty runtime-check error. I've googled it for a depressingly long amount of time, and have surmised that it involves the difference between how c++ and c function calls work.
The difference comes down to __stdcall and __cdecl, and because glMultiTexCoord works off a dll which uses c, it is corrupting the stack pointer when it tries to clean up the memory. I have found a way to force the program to run anyways, but after 5 particles on the screen the stack pointer becomes corrupted so...not much of a particle system. Oh they are all there...you just cant see them -.-
With a little help from the game dev group I've learned how CG shaders actually get their input parameters from the program. Certain opengl functions such as glTexCoord and glVertex are automatically used by variables in shaders with certain semantics, TEXCOORD and POSITION respectively.
As for the 'uniform' variables, they are explicitly set in the actual program with functions such as cgSetParameter#. In the shader the uniform identifier states that the program will take this variable, and these types of variables stay the same across all vertices/pixels. The aforementioned variables are implicitly called as varying, because they are different for every vertex on the screen.
So that's my little shader variable wrap-up, until next time!
On the other hand, the particle system is...halfway there. I got glMultiTexCoord working as it is supposed to, but this resulted in a rather nasty runtime-check error. I've googled it for a depressingly long amount of time, and have surmised that it involves the difference between how c++ and c function calls work.
The difference comes down to __stdcall and __cdecl, and because glMultiTexCoord works off a dll which uses c, it is corrupting the stack pointer when it tries to clean up the memory. I have found a way to force the program to run anyways, but after 5 particles on the screen the stack pointer becomes corrupted so...not much of a particle system. Oh they are all there...you just cant see them -.-
With a little help from the game dev group I've learned how CG shaders actually get their input parameters from the program. Certain opengl functions such as glTexCoord and glVertex are automatically used by variables in shaders with certain semantics, TEXCOORD and POSITION respectively.
As for the 'uniform' variables, they are explicitly set in the actual program with functions such as cgSetParameter#. In the shader the uniform identifier states that the program will take this variable, and these types of variables stay the same across all vertices/pixels. The aforementioned variables are implicitly called as varying, because they are different for every vertex on the screen.
So that's my little shader variable wrap-up, until next time!
Sunday, February 19
Unexpected
/rant
You would think that with a course focusing on shaders, that shaders would be the biggest challenge one faces. But I for some reason don't have much of a problem with them, its just the darn setup that goes along with it.
First of all there's not many resources for actual setup code for this stuff (that I can actually understand), and when there is its usually not quite what I'm looking for. I'm not clever or intuitive enough with programming to know how to adapt such things, so I work largely based on trial and error.
For example I've been working through the code to morph 2 obj's with a shader. The shader itself is fairly simple, it takes the source and destination vertices and perform's the lerp function between them at the specified intervals. That's all fine and dandy, and it makes sense to me, but I can't figure out how to get an obj loader to load 2 obj's -.-
I've been working off the TA's code but its more meant to load in a single object and then draw it. So I've been trying to figure out how to many an array or vector list to work with loading in several objects. And of course this naturally involves stuff like pointers and etc, meaning I suck at it. I still can't wrap my head around pointers, or why they are needed or what they really do (I get the theory behind it).
And then for the particle shader, I know the physics calculation and how to output the vertices based on the calculation, and the difference between uniform and varying, and how to use the TEXCOORD# semantic to get values for position, velocity etc. But there is this function in the CG examples called glMultiTexCoord, which is undefined no matter what version of glut and opengl I use. I know it can be used to pass in multiple values to the shader, but as it is I'm using glTexCoord and I'm fairly certain it just overwrites the value each time it is passed to the shader.
So on that front I'm stuck and looking for workaround solutions as well. In both cases I get the shader and how it works, but I don't understand the connection between the base code and it very well. So here's to more research and asking peers for help and whatnot, I know I'll get it sooner or later.
/endrant
You would think that with a course focusing on shaders, that shaders would be the biggest challenge one faces. But I for some reason don't have much of a problem with them, its just the darn setup that goes along with it.
First of all there's not many resources for actual setup code for this stuff (that I can actually understand), and when there is its usually not quite what I'm looking for. I'm not clever or intuitive enough with programming to know how to adapt such things, so I work largely based on trial and error.
For example I've been working through the code to morph 2 obj's with a shader. The shader itself is fairly simple, it takes the source and destination vertices and perform's the lerp function between them at the specified intervals. That's all fine and dandy, and it makes sense to me, but I can't figure out how to get an obj loader to load 2 obj's -.-
I've been working off the TA's code but its more meant to load in a single object and then draw it. So I've been trying to figure out how to many an array or vector list to work with loading in several objects. And of course this naturally involves stuff like pointers and etc, meaning I suck at it. I still can't wrap my head around pointers, or why they are needed or what they really do (I get the theory behind it).
And then for the particle shader, I know the physics calculation and how to output the vertices based on the calculation, and the difference between uniform and varying, and how to use the TEXCOORD# semantic to get values for position, velocity etc. But there is this function in the CG examples called glMultiTexCoord, which is undefined no matter what version of glut and opengl I use. I know it can be used to pass in multiple values to the shader, but as it is I'm using glTexCoord and I'm fairly certain it just overwrites the value each time it is passed to the shader.
So on that front I'm stuck and looking for workaround solutions as well. In both cases I get the shader and how it works, but I don't understand the connection between the base code and it very well. So here's to more research and asking peers for help and whatnot, I know I'll get it sooner or later.
/endrant
Dumbing it Down
There's a couple things that really bug me about some game franchises; a main one being when a sequel is much simpler or 'dumbed down' compared to the original. To this effect (ha) I will be looking at a couple examples: Mass Effect and Supreme Commander.
Lets start with the largely popular Mass Effect 1. Right in the opening mission you are exposed to several different weapon types, and over the course of the game you get literally hundreds of different weapons of various types (lots of duplicate models but that's not so bad). On top of this, each weapon can be customized with special properties such as extra fire or poison damage. Additionally there are many different types of armour for your character which has its own customization options.
 |
| Comparing weapon stats. |
Moving onto ME2, I got my first assault rifle in the opening mission of the game. I got the second somewhere half into the game, and that was about it. I personally enjoy using assault rifles and there was maybe a max of 3 different kinds in the game. To me this was a heart-breaker, as it took away one of my favourite aspects of the original. I would spend tons of time tinkering around with weapons to get awesome combinations, and it was all taken away for the sequel. Even the number of abilities was drastically reduced and it all felt a bit too simple.
There was no longer much choice involved, and being an RPG this was not good. Any of the choices between weapons in ME2 were either obvious or meaningless, because there wasn't really many choices to make at all. Even the armour customization was made into a cosmetic feature, so it added nothing to the actual game play experience. To be fair the game play and mechanics still held up well, but the whole experience felt a bit shallow in comparison to the endless possibilities in ME1. From what I've seen in ME3 previews, people wanted back their customization enough for Bioware to take the original's route. Hopefully they get it right!
 |
| How will I ever choose..? |
There were 2 resources in the original and you collected them like a usual RTS. But the way building things worked was radical in that it wasn't a one-time affair; resources were fluid and your rates increased/decreased depending on how many things you were doing at once. For example, building a shield generator with 20 engineering units at once would be much faster, but it would drain your energy and mass very quickly. Once at 0 in a resource, your build speed was capped to your positive resource generation. This made managing your resources very important and you had to make important decisions on what to build and when.
 |
| Note the +1 and +4 at the top; they are the net resource usages. |
Apparently people thought this system was too punishing if you got into an economic rut, so the developers changed it back to the typical RTS style for the sequel. This completely trivialized this aspect of the game, as it became a matter of 'do I have the resources or not?' and the presence of a choice was largely removed. You either built the unit/building or you didn't. Since every other RTS works this way, it took away the uniqueness of SupCom that I really enjoyed.
The second and more damaging aspect is the Tech system change between 1 and 2. The original boasted 4 tech levels, and units in higher ones cost exponentially more. This meant needing to upgrade your resource collection and unit-building structures. The effect was that at higher tiers you could pump out low tech units/structures like it was nobody's business. The game continually progresses over time until you hit tech 4 and began building the huge experimental units (Oh, I need to talk about these too!).
 |
| The potential for massive armies and bases in SC1 are limitless. |
Back to SC2 and the whole Tech system is completely removed. Instead of around 50+ units/structures for each faction, it gets dumbed down to a uniform tech system with possible upgrades. The number of units was cut down to about for each faction and the variety suffered terribly. You could now upgrade all your units but none of them felt very powerful or exceptional in any way. By comparison, a Tech 3 Titan in the original could wipe out a whole army of Tech 1 walkers.
With all the units being equalized, none of them felt powerful anymore. This combined with lower unit counts and smaller maps made SC2 a major disappointment. Even the awesome experimental units were dumbed down in the sequel; they had 2-3min build times and could be taken out by a dozen normal tanks. An experimental in SupCom took 5-30min to build and could annihilate everything in its path, and it accentuated the large-scale epic feel of the game.
This is the original SupCom trailer. It tells you everything you need to know about the game. I hope the developers take note of the community's outrage at SC2 and (hopefully) think twice before continuing to ruin what made the original amazing. Complex games aren't for everyone, but when you make a game that tailors to these types of players, don't go back on everything for the sequel. I played SC2 to the end and never touched it again...
Friday, February 17
Homework 5: Skill vs. Chance in Games
Part 1) Sum War
Players: 2-4
Materials Needed: Normal card deck (no jokers)
Setup: Shuffle 1-2 decks and give each player their portion of the cards.
Progression: Each round players may look at their next 3 cards and decide whether to play 2 or 3 of them. If a third card is not played, it is put back into the bottom of the player's deck. When the cards are put into battle, the highest sum wins that battle and the winner receives all the cards in the battle. This means players must decide whether to risk losing an extra card in order to increase their chances of winning.
Wars: When a war occurs, both player put 3 cards face-down as usual. Next they take two cards from the top of their deck but cannot look at them. Simultaneously each players puts their 2 cards face-up on the 'battlefield' and the first player to call out the total sum of the 4 cards wins. Each player only has one chance so they must make sure the answer is correct before yelling it out. An ace is one, and jack, queen, king are 11, 12, and 13 respectively.
In the case that both players incorrectly guess the answer, all cards involved in the war are taken out of the game permanently. The winning player in a war gets all the cards as per usual. This war variant combines a risk vs reward decision factor, as well as a quick-thinking component for winning wars.
To illustrate the war system: The players put down their 3 face down cards, then at the same time put down 2 more cards face up. The cards add up to 28 but the first player incorrectly blurts out 27. The second player now can take his time to make sure he gets it right. The influence of a speed-based war system means that these moments are very intense and should get the players really into the game.
Resolution: The game ends the same as per the original version.
Results: I played a match of Sum War with my little brother (since we used to played War a lot when we were younger) and it went over fairly well. We both liked the choice of being able to play all 3 cards because it was awesome when it paid off. On the other hand it was a major upset when 3 cards lost to 2 better ones, but that was all part of the game. The wars themselves were really tense moments and were definitely enhanced by the manic-nature of competing to get the answer right first. My brother is a math wiz as well so we were pretty evenly matched.
Part 2) Tic-Tac-Throw
Players: 2
Materials needed: Special tic-tac-toe board with notches for where the pieces go, and coin-shaped game pieces (X on one side, O on the other side).
Setup: Each player receives 5 game pieces, and stands several feet from the game board (can be on a table, floor, etc).
Progression: The players can decide who goes first, then taking turns they must toss their pieces onto the game board into one of the slots. If the pieces bounces out of the board, the player gets his piece back and then the other player may take his turn. It works similar to pool in that the first player to get a piece on the board will be X or O depending on which side landed face-up. From this point on the players take turns throwing their pieces onto the game board.
Skill: A player who practices throwing the piece onto the board could get very precise (much like improving at any sport), making the outcome dependent on their throwing skill. The core game remains the same but a player with experience will have better aim and consistency than someone playing for the first time. A new player could end up getting the wrong side of the piece and making their opponent win!
The Twist: Since there is both luck and skill present, this game could be similar to other drinking games for adults such as the popular Beer Pong. The loser of the game (or best 2 out of 3 games) would have to drink upon defeat. Also bets could be placed on X or O winning, making this variant into a gambling game since there is still a degree of luck involved in most cases (unless someone gets really good!).
Resolution: The game ends when 3 in a row is made or a draw when the board is full.
Results: Since the game board I envision is fairly tricky to make, I didn't really play-test this one. I assume it would be fun at parties though because it is similar to Beer Pong and those types of activities. The concept is pretty simple, its just a matter of spicing it up with adult-oriented rewards.
Part 3) You First, I Insist!
Players: 2
Materials: Game board and 4 game pieces
Setup: Each player chooses their colour then rolls to see who goes first (lowest goes first)
Original Game: The original called You First! was made by my group, consisting of myself, Alex-Bedard-Reid, Thomas Coupland, and Connor McCarthy in the second week.
Game play of original: You First! is a simple race to the end board game with the twist that the first player to reach the end loses, and vice versa. Each turn the players roll a die to see how many spaces their game piece moves. Certain tiles on the board have special conditions when the player lands on them, the most important being the pink 'switch places' tile.
Variant: In my revamped version there are a higher number of special tiles scattered throughout the board, and instead of rolling a die to see how many spaces you move, you get to choose to move between one and six spaces. The idea is that if one player gets further behind (winning) by only moving one space each turn, another player can choose to land on a pink tile and switch the two. This is made possible by the tweak to the pink tile, which would be changed to "Switch with the player closest to the beginning." The game becomes a balance of keeping a slow pace and trying to not stray too far from the rest of the players.
Results: Adding this variation to the movement rules made the game a lot more compelling but not necessarily more fun. While it was amusing to be able to choose when to mess somebody up by switching with them, the game largely played as it normally would. It was still a good bit of fun but became a little bit predictable by the end. The original in my opinion was a bit more exciting because of its chance-based nature, where anything could happen. I think to make this variant more exciting, new special tiles would have to be added with even more game-changing effects.
Players: 2-4
Materials Needed: Normal card deck (no jokers)
Setup: Shuffle 1-2 decks and give each player their portion of the cards.
Progression: Each round players may look at their next 3 cards and decide whether to play 2 or 3 of them. If a third card is not played, it is put back into the bottom of the player's deck. When the cards are put into battle, the highest sum wins that battle and the winner receives all the cards in the battle. This means players must decide whether to risk losing an extra card in order to increase their chances of winning.
Wars: When a war occurs, both player put 3 cards face-down as usual. Next they take two cards from the top of their deck but cannot look at them. Simultaneously each players puts their 2 cards face-up on the 'battlefield' and the first player to call out the total sum of the 4 cards wins. Each player only has one chance so they must make sure the answer is correct before yelling it out. An ace is one, and jack, queen, king are 11, 12, and 13 respectively.
In the case that both players incorrectly guess the answer, all cards involved in the war are taken out of the game permanently. The winning player in a war gets all the cards as per usual. This war variant combines a risk vs reward decision factor, as well as a quick-thinking component for winning wars.
To illustrate the war system: The players put down their 3 face down cards, then at the same time put down 2 more cards face up. The cards add up to 28 but the first player incorrectly blurts out 27. The second player now can take his time to make sure he gets it right. The influence of a speed-based war system means that these moments are very intense and should get the players really into the game.
Resolution: The game ends the same as per the original version.
Results: I played a match of Sum War with my little brother (since we used to played War a lot when we were younger) and it went over fairly well. We both liked the choice of being able to play all 3 cards because it was awesome when it paid off. On the other hand it was a major upset when 3 cards lost to 2 better ones, but that was all part of the game. The wars themselves were really tense moments and were definitely enhanced by the manic-nature of competing to get the answer right first. My brother is a math wiz as well so we were pretty evenly matched.
Part 2) Tic-Tac-Throw
Players: 2
Materials needed: Special tic-tac-toe board with notches for where the pieces go, and coin-shaped game pieces (X on one side, O on the other side).
Setup: Each player receives 5 game pieces, and stands several feet from the game board (can be on a table, floor, etc).
Progression: The players can decide who goes first, then taking turns they must toss their pieces onto the game board into one of the slots. If the pieces bounces out of the board, the player gets his piece back and then the other player may take his turn. It works similar to pool in that the first player to get a piece on the board will be X or O depending on which side landed face-up. From this point on the players take turns throwing their pieces onto the game board.
Skill: A player who practices throwing the piece onto the board could get very precise (much like improving at any sport), making the outcome dependent on their throwing skill. The core game remains the same but a player with experience will have better aim and consistency than someone playing for the first time. A new player could end up getting the wrong side of the piece and making their opponent win!
The Twist: Since there is both luck and skill present, this game could be similar to other drinking games for adults such as the popular Beer Pong. The loser of the game (or best 2 out of 3 games) would have to drink upon defeat. Also bets could be placed on X or O winning, making this variant into a gambling game since there is still a degree of luck involved in most cases (unless someone gets really good!).
Resolution: The game ends when 3 in a row is made or a draw when the board is full.
Results: Since the game board I envision is fairly tricky to make, I didn't really play-test this one. I assume it would be fun at parties though because it is similar to Beer Pong and those types of activities. The concept is pretty simple, its just a matter of spicing it up with adult-oriented rewards.
Part 3) You First, I Insist!
Players: 2
Materials: Game board and 4 game pieces
Setup: Each player chooses their colour then rolls to see who goes first (lowest goes first)
Original Game: The original called You First! was made by my group, consisting of myself, Alex-Bedard-Reid, Thomas Coupland, and Connor McCarthy in the second week.
Game play of original: You First! is a simple race to the end board game with the twist that the first player to reach the end loses, and vice versa. Each turn the players roll a die to see how many spaces their game piece moves. Certain tiles on the board have special conditions when the player lands on them, the most important being the pink 'switch places' tile.
 |
| Concept of the original You First! game board. |
Results: Adding this variation to the movement rules made the game a lot more compelling but not necessarily more fun. While it was amusing to be able to choose when to mess somebody up by switching with them, the game largely played as it normally would. It was still a good bit of fun but became a little bit predictable by the end. The original in my opinion was a bit more exciting because of its chance-based nature, where anything could happen. I think to make this variant more exciting, new special tiles would have to be added with even more game-changing effects.
Sunday, February 12
Big Burly Bosses
I didn't really have an idea for this blog so I brainstormed a bit and came up with a topic that I tend to think about sometimes and have an opinion on. The topic in question is the prevalence/necessity of bosses in video games.
What first got me thinking about this topic was playing Skyrim back in November. The Elder Scrolls series does many things and does them on a huge scale, but there's always a small voice in the back of my head yelling that the games could be more enjoyable with big boss battles. I realize that Alduin is pretty epic and all, and maybe for some he was a challenge, but at any decent level he's a pushover and the experience feels a bit lacking. The fight mechanics are basically the same as fighting any other standard dragon in the game. (note the comments almost always relate to the easiness of the fight)
I know that playing at your own pace is a staple of that series' game play, but would it really be that difficult to scale Alduin's difficulty higher based on the player's level? Again I realize that there is a feature right there in the game to adjust the difficulty at any time, but this doesn't really make the game much harder or easier; numbers that you don't even see are changed. It does not add to the game play in any way.
Let's contrast that sense of 'well that was cool guess' to the awesome and creative boss battles in the God of War series. The first major boss in GOW1 is a giant sea serpent, which you defeat by jumping around on a ship and impaling its head. Many of the boss fights in the game are complex and multifaceted, giving the bosses a strong presence and leaving the player with a lasting impression.
The game play in Skyrim is supposed to reflect that the player can choose how to take down the boss in many different ways, but I think a boss with many unique attacks and interesting movement patterns is superior from an immersion standpoint. As Kratos you truly feel heroic when taking apart a huge boss piece by piece.
Another game series that comes to mind is Prince of Persia. The boss battles also have that immeasurable scale to them which really opens up so many different opportunities for boss mechanics. Yet another is Shadow of the Colossus, which features many giant (hundreds of feet tall) bosses which you must climb and slowly take down. While I haven't personally played it, I've heard that it is an excellently designed game which is fun from beginning to end.
This is not to say that 'boss fights' have to always involve fighting a big enemy of some sort. Many adventure games feature platforming or skill-based challenges other than beating up a bad guy. A good example is Super Meat Boy, where boss levels follow the same mechanic as usual levels, but you must dodge and jump your way to victory, thus defeating the boss.
 |
| I don't think the giant chainsaw wants to be friends. |
On the other end of the equation is games without any major boss-type mechanics. I won't go into as much detail because usually these games rely on different mechanics to stand out. Most action-adventure types don't have bosses because they don't need them. A game that does well without many big bosses is the Halo series because its action flows smoothly throughout each level, and each level usually ends in a cliffhanger/leads well into the next level. This way it doesn't require a climatic boss fight at the end of a level to keep the player interested.
Personally I don't mind whether a game features boss battles or not, but if you're going to add this mechanic, make sure they are designed to be engaging and spectacular.
Say What?
Alright this is probably going to be the craziest thing I've ever said but here it goes: Shaders aren't all that bad.
Now this isn't just a random outburst caused by smashing my face off my laptop too many times; there is a story behind this. It all began when I felt all traces of happiness exit my body and soul, right around the time when Hogue revealed his 'new and improved' exp system. Before I go on: If you don't know me, I'm rather terrible at programming. And moving on.
Being the (relatively) hard working student I am, I delved straight into this shader stuff, spending the first weekend setting up a framework for the homework questions as was suggested. Now remember that whole thing where I suck at this stuff? Yeah well I certainly hit a brick wall; I fought and struggled just with the shader setup stuff. I think I had a hernia upon seeing the code in the 'vertex transformation' CG tutorial. Eye twitches, tears of liquid pain, hating life, all that jazz.
It frightened me enough to put it off a couple weeks (I had rational excuses I swear). But with the easy question deadline looming, I forced myself to get back into it. Of course by this time a good majority of the easy questions were worth 0, and despair was increasing. So I got all steely-eyed and said "Whatever, I'll just work on a more difficult one" D:<
Thus I began picking my way through the particle system tutorial code, adding it to my framework line-by-line, making sure I understood it every step of the way. It was a long and arduous process, but there was no choice; all the (easiest)easy questions were worth 0 by now. Once I got to the end I began changing things one at a time, gaining a deeper understanding of each function and etc. I was starting to get it!
Then at long last Hogue realizes that his ridiculous exp system is a bit flawed and changes things. All hope has returned! Now at this point I'm feeling pretty badass working with easier shaders. I go back to the first easy question to turn the screen blue. Bombshell: It's easy as cake. I know exactly how to implement it and it shouldn't take much time at all. It turns out delving straight into the tougher shaders made the easy ones..actually easy :O (Edit: Maybe Hogue planned this...!!)
Ok so maybe it was a pretty lame story, but really I'm feeling so much better about shaders. The whole first month was a stress-fest of knowing that my inadequate programming skill was going to cost me the chance of getting any exp. But now there is hope, there is a chance. I will prevail. I'll even reveal my dirty secret: I kind of like programming shaders (now that I understand them).
BUT DON'T TELL ANYBODY.
Now this isn't just a random outburst caused by smashing my face off my laptop too many times; there is a story behind this. It all began when I felt all traces of happiness exit my body and soul, right around the time when Hogue revealed his 'new and improved' exp system. Before I go on: If you don't know me, I'm rather terrible at programming. And moving on.
Being the (relatively) hard working student I am, I delved straight into this shader stuff, spending the first weekend setting up a framework for the homework questions as was suggested. Now remember that whole thing where I suck at this stuff? Yeah well I certainly hit a brick wall; I fought and struggled just with the shader setup stuff. I think I had a hernia upon seeing the code in the 'vertex transformation' CG tutorial. Eye twitches, tears of liquid pain, hating life, all that jazz.It frightened me enough to put it off a couple weeks (I had rational excuses I swear). But with the easy question deadline looming, I forced myself to get back into it. Of course by this time a good majority of the easy questions were worth 0, and despair was increasing. So I got all steely-eyed and said "Whatever, I'll just work on a more difficult one" D:<
Thus I began picking my way through the particle system tutorial code, adding it to my framework line-by-line, making sure I understood it every step of the way. It was a long and arduous process, but there was no choice; all the (easiest)easy questions were worth 0 by now. Once I got to the end I began changing things one at a time, gaining a deeper understanding of each function and etc. I was starting to get it!
Then at long last Hogue realizes that his ridiculous exp system is a bit flawed and changes things. All hope has returned! Now at this point I'm feeling pretty badass working with easier shaders. I go back to the first easy question to turn the screen blue. Bombshell: It's easy as cake. I know exactly how to implement it and it shouldn't take much time at all. It turns out delving straight into the tougher shaders made the easy ones..actually easy :O (Edit: Maybe Hogue planned this...!!)
Ok so maybe it was a pretty lame story, but really I'm feeling so much better about shaders. The whole first month was a stress-fest of knowing that my inadequate programming skill was going to cost me the chance of getting any exp. But now there is hope, there is a chance. I will prevail. I'll even reveal my dirty secret: I kind of like programming shaders (now that I understand them).
BUT DON'T TELL ANYBODY.
Subscribe to:
Posts (Atom)