Team: Awesome Possum
Game: Tunnel of Love
Members:
Taylor Holoiday #100422647
Alex Bedard-Reid #100423694
Connor McCarthy #100426175
Aaron Providence #100429531
Mackenize Sturrup #100429591
The goal of the wedding proposal game is to convey the pacing and feel of the Isaac's Wedding Proposal viral video. After brainstorming a few concepts we decided to give the player a semi-linear degree of freedom. The level takes place in a straight hallway with several doors to each side. The player is free to explore this hallway at their leisure, but the rooms unlock in a certain order, guiding the player to explore each one before progressing to the next. The player in our game is 'the guide', and symbolizes the car moving in the video.
At the end of the hallway the final door leads to the final room. This is where the wedding proposal takes places and all of the bride's friends are there waiting for her. The individual rooms each contain a different memory of their relationship as highlighted in the video. At the final door we feature our scripted npc movement and the culminating proposal. The four critical events are: first meeting, first date, proclaiming love, and moving in together.
The game takes place in first-person perspective, with WASD for movement and space bar for jumping. Moving the mouse will rotate the camera and clicking will interact with certain objects such as doors and the heart pieces. The controls are simple to keep the player focused on exploring the scenery around them.
The game play in the Tunnel of Love is to simply collect the four heart pieces to unlock the final door and enable the wedding proposal to take place. The pieces are generally easy to find but motivate the player to explore each room and observe the beauty within. Upon reaching the final proposal, the player must collect the completed heart to activate the 'Will you marry me?' line, thus completing the wedding proposal.
Our level design goals for the Tunnel of Love were to capture the emotion of each relationship event and emphasize the atmosphere of each. They serve as a timeline of Amy and Isaac's time together and lead up to the final wedding proposal. By separating these into individual rooms, each room feels very distinct and memorable. The hallway itself represents the linear path Amy takes in her journey to Isaac. It guides her along taking her to the various memories along the way. We planned to have Amy follow the player throughout the level but this feature did not make the final version.
The rooms do not literally convert the video's content but rather extrapolate the feeling of each to create a unique scenario displaying the interactions between Isaac and Amy. The first meeting takes place in a serene park with the pair both feeding ducks on a bench. This scene is calm and pleasant, focusing on the simplicity of the atmosphere.
The second room is a romantic restaurant scene in which the couple are enjoying a meal together. This is their first official date and it focuses on the intimate atmosphere and closeness between the couple. The third room is another romantic scene where the couple proclaims their love for each other. It takes place on a breathtaking beach and the couple are alone, with no one but each other. The final room features the couple moving in together; the next major step in their lives. It is not as exciting or romantic, but it is a very important step for the couple so we included it in the game.
Once the player has collected the heart piece from each room, they may open the final door and let the wedding proposal proceed. This is the end of the game, and coincides with the ending of the video. The Tunnel of Love has very simple game play elements and focuses more the aesthetics and atmosphere of the couple's interactions. It could be considered an art game because of these features.
Wednesday, October 31
Tuesday, October 9
Interpolation Techniques
This blog will spotlight the various linear, spline and slerp interpolations found in World of Warcraft. Being such a large game there are multitudes of interpolation uses found in the game. I will go over several of the more prominent and noticeable applications.
First, being an MMO there are thousands of enemies scattered throughout Azeroth and beyond. While questing out in the world your character is often beset upon by these monsters when you enter within a certain range of them. Once in combat, the enemy will proceed to move toward your character using linear interpolation pathfinding. They will find the most direct route and head toward you.
Lerp is also used for the thousands of character and object animations in WoW. A very good example of the lerp (with skeletal-based skinning) is the dancing animations for the various races of Azeroth. The model smoothly move from pose to pose in a rather intricate show of model morphing.
Another key feature (and important mechanic-wise) is the camera in WoW. It defaults as 3rd person but can be zoomed in fully to present you with a 1st person view. In almost every situation you're going to want it fully zoomed out though. It follows the same principle as a car: you want to be aware of your surroundings at all times. The camera is instrumental because it allows you to view the necessary areas around your character to keep you informed of what is happening.
This is just a few examples, but in a game of WoW's scale there are many different uses for interpolation and the World of Warcraft would not be the same without it.
First, being an MMO there are thousands of enemies scattered throughout Azeroth and beyond. While questing out in the world your character is often beset upon by these monsters when you enter within a certain range of them. Once in combat, the enemy will proceed to move toward your character using linear interpolation pathfinding. They will find the most direct route and head toward you.
Lerp is also used for the thousands of character and object animations in WoW. A very good example of the lerp (with skeletal-based skinning) is the dancing animations for the various races of Azeroth. The model smoothly move from pose to pose in a rather intricate show of model morphing.
Another key feature (and important mechanic-wise) is the camera in WoW. It defaults as 3rd person but can be zoomed in fully to present you with a 1st person view. In almost every situation you're going to want it fully zoomed out though. It follows the same principle as a car: you want to be aware of your surroundings at all times. The camera is instrumental because it allows you to view the necessary areas around your character to keep you informed of what is happening.
 |
| (servers are down so screenshots are not my own) |
The camera in WoW must use Quaternion Slerp for this as it is an essential tool for the player. In real time you can zoom in and out, and rotate the camera around your character to view anything you want. The rotations are smooth and there are no problems with Gimbal Lock (does not use Euler Angles!!) With an intuitive and flexible camera system, the world of Azeroth would be a much more difficult place to explore.
Spline interpolations are also found in many different parts of WoW. Because all projectiles in WoW will auto-hit their target regardless of its location, projectiles will often curve midair to reach their goal. Spline interpolation dictates that the projectile will follow a smooth curve from its target to its destination (ouch!). If the enemy moves, the spline is automatically re-calculated to compensate for all changing factors. Watch for the blue projectiles in the following video.
This is just a few examples, but in a game of WoW's scale there are many different uses for interpolation and the World of Warcraft would not be the same without it.
Wednesday, September 26
Defying Gravity
Since my group will have a paltry 4 minutes to present (1min 20 sec each), here is a more detailed description/walk-through of my puzzle level. Once again, I'll add a video walk-through next time I get the chance.
My level is called Defy Gravity and it is named as such due a very unique feature it contains. Lets begin from the start. On the left side of the chamber is the OR gate in my level. It works through a set of two timed pedestal buttons. Each is connected to a laser emitter, both of which will hit the central laser relay when activated. These are the two inputs in the OR gate; the output is the flip panel which is connected to the laser relay.
When either of the buttons are pushed, their respective laser is turned on which in turns activates the flip panel (for the duration of the pedestal timer). This is the primary means to travel between the main two sections in the chamber.
Once across the OR gate, you are confronted with a companion cube and and a reflection cube. This is the tricky part. The companion cube is needed for the rest of the level, but obviously can only be used for one purpose at a time. A set of indicator lights on the ground tries to hint player to set the reflection cube on the nearby piston platform. This is because the platform will be raised to the height of a laser emitter.
We have reached the point of no return. Prepare to defy gravity. The button featured above controls two different mechanisms: the piston platform, and the shown laser emitter. In its off state the piston is off and the laser is on. Inversely, when on the piston is on and the laser is off; this makes is a dual normal/NOT gate. It is hard to explain how this mechanic works so please refer to the youtube video.
As you can see, when the player steps off the button, the piston lowers and the laser turns back on. The trick is that the reflection cube will stay floating when the piston is lowered down again. I'm not sure whether this is an intentional feature or a glitch, but it can lead to some really interesting design possibilities and my level certainly takes advantage of it.
The laser emitter turns on a tractor beam which leads to the level exit. But to get there you must first head back to the first section of the level (via the OR gate). Using the OR gate is the only way to get back and still have the companion cube with you. You must then use the cube to raise a set of nearby stairs. This gives access to the pedestal button, which activates a flip panel. If you can't reach it, jump!
With the button pressed you can portal up to the flip panel and jump to the nearby faith plate. This leads to the tractor beam on the opposite side of the chamber; you are almost there!
If you remembered to take your companion cube with you, you can now place it on the final NOT gate button to deactivate the laser field. However if forgot it, there is a conveniently placed faith plate to send you back over the tall laser field into the main section. Now head through the exit and rejoice: you have solved this nefarious puzzle!
Hope you enjoyed Defy Gravity and I have a feeling I might continue making more awesome portal puzzles, I'm rather addicted :D
 |
| It can't be that bad...right? |
My level is called Defy Gravity and it is named as such due a very unique feature it contains. Lets begin from the start. On the left side of the chamber is the OR gate in my level. It works through a set of two timed pedestal buttons. Each is connected to a laser emitter, both of which will hit the central laser relay when activated. These are the two inputs in the OR gate; the output is the flip panel which is connected to the laser relay.
When either of the buttons are pushed, their respective laser is turned on which in turns activates the flip panel (for the duration of the pedestal timer). This is the primary means to travel between the main two sections in the chamber.
 |
| From the entrance. The first thing you notice is the pedestal button to your left. |
 |
| This is the activated pedestal button on the left side of the OR gate. |
 |
| The other side of the OR gate. |
 |
| The two cubes. (Companion cube has been moved onto the nearby button.) |
 |
| Make sure to place the cube on the center of the piston facing the laser receiver! |
 |
| Now you can access the faith plate which leads to the button. |
We have reached the point of no return. Prepare to defy gravity. The button featured above controls two different mechanisms: the piston platform, and the shown laser emitter. In its off state the piston is off and the laser is on. Inversely, when on the piston is on and the laser is off; this makes is a dual normal/NOT gate. It is hard to explain how this mechanic works so please refer to the youtube video.
As you can see, when the player steps off the button, the piston lowers and the laser turns back on. The trick is that the reflection cube will stay floating when the piston is lowered down again. I'm not sure whether this is an intentional feature or a glitch, but it can lead to some really interesting design possibilities and my level certainly takes advantage of it.
The laser emitter turns on a tractor beam which leads to the level exit. But to get there you must first head back to the first section of the level (via the OR gate). Using the OR gate is the only way to get back and still have the companion cube with you. You must then use the cube to raise a set of nearby stairs. This gives access to the pedestal button, which activates a flip panel. If you can't reach it, jump!
With the button pressed you can portal up to the flip panel and jump to the nearby faith plate. This leads to the tractor beam on the opposite side of the chamber; you are almost there!
 |
| The stairs only remain active while the button is pushed. |
 |
| Here we gooooo! (Don't forget your cube <3) |
 |
| Wubwubwub. |
 |
| Nicely done :) |
Friday, September 21
Animation Revisited
Well its early morning and I don't exactly have the energy to think of an interesting blog post, so I'll just recant you with a woeful tale of triumph and loss. Thus begins the Animation Chronicles (part 1 of 1).
Last year this Animation class scared me a lot, and not because of the math or 3D modelling. When Professor Hogue gave us the list of homework questions my brain shut down for a minute or two. But all was not lost. I slowly worked through the first couple easy questions on interpolation and managed to get it working. I started all my homework questions from scratch so I really got to know the proper steps in beginning an OpenGL project.
As I went through some of the easy questions I gained more confidence and was always very proud when I managed to accomplish things I never thought I would figure out. Time goes on and I get some more questions done. Then inevitably I run out of time at the end because lets be serious; I'm not that great at programming. I have to put a lot of time into simple programs just to get them working, and my OOP skills are awful.
Yet I somehow managed to get the 40exp by the end and write the exam. Now I wish I knew what mark I received on it, because I felt pretty good with the exam. Not great, but good. And then a meteorite (metaphorical, don't worry) hits and my GDW gets hammered for our graphics not working in our game. I kind of wish it was marked based on more than the visual because all the code was there for our animation etc.
Nonetheless between a mediocre exam mark (I guess?) and virtually getting 0 on the GDW 25%, here I am in Animation again. It is a prerequisite for Game Engines in Year 3 which is a prerequisite for nearly every course in the rest of this program.
Complaining aside, I'm going to totally kick butt this time around. I have nothing left to lose really. My GDW group is split up, I had to take a bunch of electives because there were no other Game Dev courses without Animation as a prerequisite, and I suppose I need the credits.
So here's to another semester with Animation: Algorithms and Techniques, this time with blogs. Cheers.
Last year this Animation class scared me a lot, and not because of the math or 3D modelling. When Professor Hogue gave us the list of homework questions my brain shut down for a minute or two. But all was not lost. I slowly worked through the first couple easy questions on interpolation and managed to get it working. I started all my homework questions from scratch so I really got to know the proper steps in beginning an OpenGL project.
As I went through some of the easy questions I gained more confidence and was always very proud when I managed to accomplish things I never thought I would figure out. Time goes on and I get some more questions done. Then inevitably I run out of time at the end because lets be serious; I'm not that great at programming. I have to put a lot of time into simple programs just to get them working, and my OOP skills are awful.
Yet I somehow managed to get the 40exp by the end and write the exam. Now I wish I knew what mark I received on it, because I felt pretty good with the exam. Not great, but good. And then a meteorite (metaphorical, don't worry) hits and my GDW gets hammered for our graphics not working in our game. I kind of wish it was marked based on more than the visual because all the code was there for our animation etc.
Nonetheless between a mediocre exam mark (I guess?) and virtually getting 0 on the GDW 25%, here I am in Animation again. It is a prerequisite for Game Engines in Year 3 which is a prerequisite for nearly every course in the rest of this program.
Complaining aside, I'm going to totally kick butt this time around. I have nothing left to lose really. My GDW group is split up, I had to take a bunch of electives because there were no other Game Dev courses without Animation as a prerequisite, and I suppose I need the credits.
So here's to another semester with Animation: Algorithms and Techniques, this time with blogs. Cheers.
Thursday, September 20
Noopsie Ball
Today I was part of team B and we designed (Extreme) Human Foosball. The idea began to formulate when team members were discussing limiting movement for players in the game. This combined with the idea that you could only hit the ball and not catch it, was the basis for our game.
Team A came up with Chaos Ball, which at first seemed a little dangerous. Risk of physical injury aside, their approach used the level design well by creating chair obstacles. It seemed to be a bit more low-key than Human Foosball but was similar in simplicity and movement constraints.
The rules for Human Foosball are as follows: two teams have 2 rows of offense and a row of defense. The goal is to score/keep the other team from scoring in the plastic bin. The players are only allowed one step the side in each direction and may not turn out. The ball cannot be caught; it must be bounced off the player. If the ball hits the ground or goes out of bounds, the player which dropped it must throw it to the other team to get the action started again. The team with the highest number of goals after a specified time limit is the winner.
In the diagram below, the green team's wants the ball to go to the right and thus they can only face to the right. This means the offense wants to get the ball in the goal (grey box) while the row of defense wants to hit it away from the goal to prevent the opposing team from scoring. The principal is the same for the blue team, except they face to the left.
Human Foosball takes advantage of the players as part of its level design. Originally we considered having 6 players per row but that would lead to players further out never getting a chance to play, as move of the action is centered around the plastic bin goal. With 6 rows of 4 players, the 'level' was evenly distributed so that each player would have an opportunity to attack/defend.
The advantage of having the players define the level boundary is that Human Foosball can be played virtually anywhere there is enough room; it does not have to be in a classroom with tables and chairs.
In Chaos Ball each team had a set number of players distributed throughout the classroom. They had to remain on the tables and never touch the floor. To make a successful pass to a team-mate, the player must bounce the ball off an object at least once before it reaches its destination. Each ball pass, every player is allowed a maximum of 3 steps on top of the tables. To score, a player must throw the ball into the plastic bin goal; this is unique in that it does not require a bounce first. The players are allowed to block shots made by the opposing team.
The level design in Chaos Ball is constructed randomly:at the start of the match each player in the game gets to set a chair on a table anywhere on the playing area. This creates a maze-like level and can lead to certain strategies being formed by the teams. For example, they could coordinate where their chairs are placed to effectively block off a certain area from play.
The advantages of Chaos Ball are its strategic depth (placement of chairs) and that you may never play the same game twice. The fluidity of the level design gives players constant new opportunities to try new tactics and maneuvers. This gives it elements of both strategy and skill and can potentially be more emotionally rewarding to play than Human Foosball.
Team A came up with Chaos Ball, which at first seemed a little dangerous. Risk of physical injury aside, their approach used the level design well by creating chair obstacles. It seemed to be a bit more low-key than Human Foosball but was similar in simplicity and movement constraints.
The rules for Human Foosball are as follows: two teams have 2 rows of offense and a row of defense. The goal is to score/keep the other team from scoring in the plastic bin. The players are only allowed one step the side in each direction and may not turn out. The ball cannot be caught; it must be bounced off the player. If the ball hits the ground or goes out of bounds, the player which dropped it must throw it to the other team to get the action started again. The team with the highest number of goals after a specified time limit is the winner.
In the diagram below, the green team's wants the ball to go to the right and thus they can only face to the right. This means the offense wants to get the ball in the goal (grey box) while the row of defense wants to hit it away from the goal to prevent the opposing team from scoring. The principal is the same for the blue team, except they face to the left.
Human Foosball takes advantage of the players as part of its level design. Originally we considered having 6 players per row but that would lead to players further out never getting a chance to play, as move of the action is centered around the plastic bin goal. With 6 rows of 4 players, the 'level' was evenly distributed so that each player would have an opportunity to attack/defend.
The advantage of having the players define the level boundary is that Human Foosball can be played virtually anywhere there is enough room; it does not have to be in a classroom with tables and chairs.
In Chaos Ball each team had a set number of players distributed throughout the classroom. They had to remain on the tables and never touch the floor. To make a successful pass to a team-mate, the player must bounce the ball off an object at least once before it reaches its destination. Each ball pass, every player is allowed a maximum of 3 steps on top of the tables. To score, a player must throw the ball into the plastic bin goal; this is unique in that it does not require a bounce first. The players are allowed to block shots made by the opposing team.
The level design in Chaos Ball is constructed randomly:at the start of the match each player in the game gets to set a chair on a table anywhere on the playing area. This creates a maze-like level and can lead to certain strategies being formed by the teams. For example, they could coordinate where their chairs are placed to effectively block off a certain area from play.
The advantages of Chaos Ball are its strategic depth (placement of chairs) and that you may never play the same game twice. The fluidity of the level design gives players constant new opportunities to try new tactics and maneuvers. This gives it elements of both strategy and skill and can potentially be more emotionally rewarding to play than Human Foosball.
Friday, September 14
My First Portal Puzzle
I started playing around with the Portal 2 Puzzle Maker on Wednesday. At first I was lost and had no idea where to start, but eventually I discovered a design process which worked for me. I will discuss this process after I explain my awesome level!
Here is the Workshop Chamber link to my puzzle:
(tweet me @taymanh if it doesn't come up)
http://steamcommunity.com/sharedfiles/filedetails/?id=95968310
As you can see, there are a lot of elements packed into one little deadly-goo filled room. Here's a quick walkthrough so you get the idea of it. I will upload a youtube walkthrough when I get the chance.
1) Portal yourself to the centre island using the portal-able ceiling tile. Place the reflection cube to activate the laser receiver on the left side of the room. This activates a light bridge connecting the 2nd level platform to the flinger platform near it.
2) Portal the conversion goo so that it covers the 2nd level platform near you (using a portal-able wall panel, and momentum), and your own platform, as it is the only way to get back from your island.
3) Cross the light bridge to the flinger which sends you to the button pedestal. Activate it to make a cube dispense from the far corner dispenser. Use the nearby flinger to get back to the starting corner.
4) Portal to the far cube and bring it back to the square cube button near the entrance. This deactivates the death laser guarding the exit door.
5) Make your way back across the light bridge and drop down, then exit to freedom.
Now it sounds very simple hearing a walkthrough and it also seems very easy to me, my friends that play-tested it told me a different story. What looks like a very straightforward puzzle actually took others between 5 and 10 minutes to complete. I believe a large reason for that is the need to use the conversion goo for multiple purposes. This made the puzzle tricky to figure out but not impossible. My best advice for the players was to observe their surroundings carefully before asking for help.
As to the design process, I had a lot of trouble trying to make the puzzle from the start by just adding things. Instead the first part I added was the laser wall blocking the exit. I then thought of how I wanted players to deactivate it. From there, I made a puzzle element which blocked the player from getting to the pedestal button, and then made an element to prevent them from reaching it (toggled light bridge) and so on.
Using this reverse process I was able to break down the puzzle chamber into its base challenges and chain them together from there. Once I felt satisfied about a puzzle element I made sure to playtest it myself and with others to find any loopholes. At this time I hadn't read the article Dr. Nacke had posted, but now I realize I was going through the same process the Valve team does when creating new puzzles.
The rapid iterations of playtesting and tweaking helped iron out all the problems and boring parts of the puzzle. A big problem for me was deciding on the proportion of portal-able tiles to regular tiles. I found that starting with all regular tiles and then adding portal-able ones as I went helped to streamline the process and provide players with visuals clues as to their next step.
With even a few more portal-able tiles a playtester was able to go straight to the pedestal button and skip half of the puzzle. This was more than just a smart shortcut; it ruined all problem-solving in the first half. To solve this puzzle you only need to place a few portals, but each one requires careful thought and observation.
With that said, I'm going to begin working on the Puzzle Maker assignment, so happy portaling!
Here is the Workshop Chamber link to my puzzle:
(tweet me @taymanh if it doesn't come up)
http://steamcommunity.com/sharedfiles/filedetails/?id=95968310
As you can see, there are a lot of elements packed into one little deadly-goo filled room. Here's a quick walkthrough so you get the idea of it. I will upload a youtube walkthrough when I get the chance.
1) Portal yourself to the centre island using the portal-able ceiling tile. Place the reflection cube to activate the laser receiver on the left side of the room. This activates a light bridge connecting the 2nd level platform to the flinger platform near it.
2) Portal the conversion goo so that it covers the 2nd level platform near you (using a portal-able wall panel, and momentum), and your own platform, as it is the only way to get back from your island.
3) Cross the light bridge to the flinger which sends you to the button pedestal. Activate it to make a cube dispense from the far corner dispenser. Use the nearby flinger to get back to the starting corner.
4) Portal to the far cube and bring it back to the square cube button near the entrance. This deactivates the death laser guarding the exit door.
5) Make your way back across the light bridge and drop down, then exit to freedom.
Now it sounds very simple hearing a walkthrough and it also seems very easy to me, my friends that play-tested it told me a different story. What looks like a very straightforward puzzle actually took others between 5 and 10 minutes to complete. I believe a large reason for that is the need to use the conversion goo for multiple purposes. This made the puzzle tricky to figure out but not impossible. My best advice for the players was to observe their surroundings carefully before asking for help.
As to the design process, I had a lot of trouble trying to make the puzzle from the start by just adding things. Instead the first part I added was the laser wall blocking the exit. I then thought of how I wanted players to deactivate it. From there, I made a puzzle element which blocked the player from getting to the pedestal button, and then made an element to prevent them from reaching it (toggled light bridge) and so on.
Using this reverse process I was able to break down the puzzle chamber into its base challenges and chain them together from there. Once I felt satisfied about a puzzle element I made sure to playtest it myself and with others to find any loopholes. At this time I hadn't read the article Dr. Nacke had posted, but now I realize I was going through the same process the Valve team does when creating new puzzles.
The rapid iterations of playtesting and tweaking helped iron out all the problems and boring parts of the puzzle. A big problem for me was deciding on the proportion of portal-able tiles to regular tiles. I found that starting with all regular tiles and then adding portal-able ones as I went helped to streamline the process and provide players with visuals clues as to their next step.
With even a few more portal-able tiles a playtester was able to go straight to the pedestal button and skip half of the puzzle. This was more than just a smart shortcut; it ruined all problem-solving in the first half. To solve this puzzle you only need to place a few portals, but each one requires careful thought and observation.
With that said, I'm going to begin working on the Puzzle Maker assignment, so happy portaling!
Wednesday, September 12
Guild Wars 2 Animation Techniques
The game I decided to play (and have been a lot lately) is Guild Wars 2. It is a new MMO which was released on August 28th, just a few weeks ago.
Being an MMO with a very diverse world, there are many different player and npc character models running about. I complement ArenaNet on a job well done with all the character animations in the game. From the very beginning, I noticed how smooth my character transitioned from idle, to walking, to a running animation. There was no jumpy movements; just a seamless flow of movement which looks very natural.
Pictured above is my Sylvari Ranger. In the picture you can also see the vividness of the world I am exploring. The grass and trees blow in the wind, creatures mill about, and npc's interact with each other. Great care was put into each animation to make sure it is smooth and organic.
In the screenshot you can also note the various particle effects going on around my player. There is sparkly dust and fireflies in the air, and a water portal in the distance to the left. All these particle systems are dynamic and have their own properties. Each adds atmosphere to the game world and helps bring it alive.
A majority of the characters in GW2 are bipedal, and as such ArenaNet put a lot of working into making convincing movement and animations. There is no feet-skating present so your character very rarely clips through objects or the environment. The following screenshot is very good example of these systems at work.
Due to the huge variety in poses a character in GW2 can do, I believe all these animations are done using a skeletal system. Each races /dance emote makes the character perform a very complicated dance with a large number of different poses. These animations are on their own though, meaning they cannot be blended to or from a running animation.
One of the first things I noticed about my character when I started playing was how their clothing moved as they did. In the video above if you watch carefully you can observe the bottom of the tunic moving with the character. All the cloth and hair animation is done real-time using a physics engine. It moves and sways with the wind and with the movement of your character.
As a ranger, my character uses a shortbow and longbow as their primary weapons. Early on I noticed that every shot I took was affected by gravity. The arrows would arc towards targets which were further away. This effect has a major impact on game play, as it can be a true tactical advantage to having the high ground. When trying to shoot an enemy up on a keep wall, often the arrow will not reach its target because of the arc path it flies on. Conversely, on top of a wall, it is easy to shoot at enemies down below, and from a fairly long range.
Its a little difficult to tell from the video, but each arrow fired is affected by gravity on its way to the target. It is a subtle yet important detail that is often missed in these types of games. ArenaNet really focused on making Guild Wars 2 both look good and play good, and this all comes about from consistent and effective animation techniques. If you go look at WoW for example, you'll notice a large difference in the fluidity of the character animations.
Guild Wars 2 has been proclaimed as a 'beautiful looking game' and players definitely notice the high quality of the many different animations present in the game.
Being an MMO with a very diverse world, there are many different player and npc character models running about. I complement ArenaNet on a job well done with all the character animations in the game. From the very beginning, I noticed how smooth my character transitioned from idle, to walking, to a running animation. There was no jumpy movements; just a seamless flow of movement which looks very natural.
Pictured above is my Sylvari Ranger. In the picture you can also see the vividness of the world I am exploring. The grass and trees blow in the wind, creatures mill about, and npc's interact with each other. Great care was put into each animation to make sure it is smooth and organic.
In the screenshot you can also note the various particle effects going on around my player. There is sparkly dust and fireflies in the air, and a water portal in the distance to the left. All these particle systems are dynamic and have their own properties. Each adds atmosphere to the game world and helps bring it alive.
A majority of the characters in GW2 are bipedal, and as such ArenaNet put a lot of working into making convincing movement and animations. There is no feet-skating present so your character very rarely clips through objects or the environment. The following screenshot is very good example of these systems at work.
Due to the huge variety in poses a character in GW2 can do, I believe all these animations are done using a skeletal system. Each races /dance emote makes the character perform a very complicated dance with a large number of different poses. These animations are on their own though, meaning they cannot be blended to or from a running animation.
One of the first things I noticed about my character when I started playing was how their clothing moved as they did. In the video above if you watch carefully you can observe the bottom of the tunic moving with the character. All the cloth and hair animation is done real-time using a physics engine. It moves and sways with the wind and with the movement of your character.
As a ranger, my character uses a shortbow and longbow as their primary weapons. Early on I noticed that every shot I took was affected by gravity. The arrows would arc towards targets which were further away. This effect has a major impact on game play, as it can be a true tactical advantage to having the high ground. When trying to shoot an enemy up on a keep wall, often the arrow will not reach its target because of the arc path it flies on. Conversely, on top of a wall, it is easy to shoot at enemies down below, and from a fairly long range.
Its a little difficult to tell from the video, but each arrow fired is affected by gravity on its way to the target. It is a subtle yet important detail that is often missed in these types of games. ArenaNet really focused on making Guild Wars 2 both look good and play good, and this all comes about from consistent and effective animation techniques. If you go look at WoW for example, you'll notice a large difference in the fluidity of the character animations.
Guild Wars 2 has been proclaimed as a 'beautiful looking game' and players definitely notice the high quality of the many different animations present in the game.
Monday, March 26
A Little Texturing Tutorial
Well its been a few weeks but I can proudly say I've gotten a whole bunch of shaders done lately. With that said, I'm much more confident texturing with shaders now, so I'm going to give a simple tutorial on how to slap on some textures for your models.
Lets start with the basics, you're going to need a variable to hold the texture itself. (Make sure the texture is in your project file!) Preferably this variable should be off in your global header somewhere to keep your main from getting cluttered.
static GLuint textureName;
This variable holds the information for whichever texture you choose. Loading the texture is just as simple. **Make sure you have all your DevIL libs included, and initialized** DevIL pretty much takes care of this step for you with:
textureName = ilutGLLoadImage("nameOfTextureFile.extension");
You can throw this function in main or maybe somewhere in your code where it can be dynamically changed on the fly. Its up to you, but for this tutorial the texture is loaded in main as that is all which is necessary.
Next you'll want to make sure all your CG stuff is initialized properly. I'll assume you know the basics of setting up a context/program/profile etc so I'll just show you how to get the parameter. Note that it can be a vertex or fragment parameter, it doesn't make a big difference for a simple program like this.
cgVertexParam_textureMap = cgGetNamedParameter(vertexProgram, "textureMap");
Now that you have the texture initialized, your shader will need to know where to get the texture coordinates. These come from the actual drawing of your shape/obj. Somewhere in your code you must have
glTexCoord2f(0.0,0.0);
for each texture coordinate your shape/obj has. This is crucial because your shader program will use these valuables when it has the correct semantic.
There's one more important thing to add in your main code, but I'm going to jump ahead to the shader itself for now. In the vertex or fragment shader, you will need a variable called
float2 texCoord : TEXCOORD0
This variable is varying, so it will automatically take in the values you specified with glTexCoord2f().
If you put this variable in your vertex shader, you should just pass it along to the fragment shader by specifying an out variable like so
out float2 oTexCoord : TEXCOORD0
Now in your fragment shader, you will need both the texCoord variable and a new one to specify the textureMap which the shader will use. Remember that textureMap parameter we set? Now it finally gets to be part of the action. The variable goes as such:
uniform sampler2D textureMap : TEXUNIT0
The uniform states it is a constant variable set by the program, the sampler2D is what grabs the actual texture, and TEXUNIT0 tell the shader which texture is going to be applied.
Lets go back to the program itself for a moment, and set the texture that will be applied in the shader. This code should be in the display function after you bind your programs and enable the shader profiles.
glActiveTextureARB(GL_TEXTURE0_ARB);
glBindTexture(GL_TEXTURE_2D,textureMap);
These two lines of code tell the shader which texture is being used, and then binds it to the textureMap variable. Note the TEXTURE0 will match up with TEXUNIT0 in your fragment shader. **I do not think glEnable(TEXTURE_2D) is necessary because the shader itself handles all the texturing instead of OpenGL**
Now back to the fragment shader to put it all together. As long as there is some form of lighting in your program (ambient is fine) then the following code should make your shape/obj nice and pretty:
float3 mappedObj = tex2D(textureMap, texCoord);
This applies the texture you loaded and matches it up with the texture coordinates you have specified. Now you can multiply this with your ambient colour (make sure its white) and output your final colour. Voila, you have a beautifully textured object; not that difficult eh?
**As a side note, if you want to blend multiple textures its as easy as setting more texture parameters, then lerping them in the fragment shader.**
:D
Lets start with the basics, you're going to need a variable to hold the texture itself. (Make sure the texture is in your project file!) Preferably this variable should be off in your global header somewhere to keep your main from getting cluttered.
static GLuint textureName;
This variable holds the information for whichever texture you choose. Loading the texture is just as simple. **Make sure you have all your DevIL libs included, and initialized** DevIL pretty much takes care of this step for you with:
textureName = ilutGLLoadImage("nameOfTextureFile.extension");
You can throw this function in main or maybe somewhere in your code where it can be dynamically changed on the fly. Its up to you, but for this tutorial the texture is loaded in main as that is all which is necessary.
Next you'll want to make sure all your CG stuff is initialized properly. I'll assume you know the basics of setting up a context/program/profile etc so I'll just show you how to get the parameter. Note that it can be a vertex or fragment parameter, it doesn't make a big difference for a simple program like this.
cgVertexParam_textureMap = cgGetNamedParameter(vertexProgram, "textureMap");
Now that you have the texture initialized, your shader will need to know where to get the texture coordinates. These come from the actual drawing of your shape/obj. Somewhere in your code you must have
glTexCoord2f(0.0,0.0);
for each texture coordinate your shape/obj has. This is crucial because your shader program will use these valuables when it has the correct semantic.
There's one more important thing to add in your main code, but I'm going to jump ahead to the shader itself for now. In the vertex or fragment shader, you will need a variable called
float2 texCoord : TEXCOORD0
This variable is varying, so it will automatically take in the values you specified with glTexCoord2f().
If you put this variable in your vertex shader, you should just pass it along to the fragment shader by specifying an out variable like so
out float2 oTexCoord : TEXCOORD0
Now in your fragment shader, you will need both the texCoord variable and a new one to specify the textureMap which the shader will use. Remember that textureMap parameter we set? Now it finally gets to be part of the action. The variable goes as such:
uniform sampler2D textureMap : TEXUNIT0
The uniform states it is a constant variable set by the program, the sampler2D is what grabs the actual texture, and TEXUNIT0 tell the shader which texture is going to be applied.
Lets go back to the program itself for a moment, and set the texture that will be applied in the shader. This code should be in the display function after you bind your programs and enable the shader profiles.
glActiveTextureARB(GL_TEXTURE0_ARB);
glBindTexture(GL_TEXTURE_2D,textureMap);
These two lines of code tell the shader which texture is being used, and then binds it to the textureMap variable. Note the TEXTURE0 will match up with TEXUNIT0 in your fragment shader. **I do not think glEnable(TEXTURE_2D) is necessary because the shader itself handles all the texturing instead of OpenGL**
Now back to the fragment shader to put it all together. As long as there is some form of lighting in your program (ambient is fine) then the following code should make your shape/obj nice and pretty:
float3 mappedObj = tex2D(textureMap, texCoord);
This applies the texture you loaded and matches it up with the texture coordinates you have specified. Now you can multiply this with your ambient colour (make sure its white) and output your final colour. Voila, you have a beautifully textured object; not that difficult eh?
**As a side note, if you want to blend multiple textures its as easy as setting more texture parameters, then lerping them in the fragment shader.**
:D
Sunday, March 25
Fun Fun for Everyone
This week I'm going to take a look at two very different games that I consider a lot of fun, and see if I can match them to some of the fun categories from the lecture. I really liked the BrainHex model because of how it relates to the parts of the brain used for different feelings. I will use that model and see how these games fit in.
The BrainHex model takes into account how different parts of the brain control different states of mind which video games can create in a player. The seven states listed below are not mutually exclusive, as often a player can be of multiple types. There are also several exceptions which take into account things a player really dislikes in a game.
 |
| A visual representation of the 7-pointed BrainHex model. |
My scores were:
Conqueror: 19
Daredevil: 16
Achiever: 14
Mastermind: 8
Socialiser: 7
Seeker: 6
Survivor: -6
Now for the games; first up is Diablo 2. This RPG features fast-paced dungeon crawling action, pitting your character up against the minions of hell. You begin by choosing one of 5 unique classes and then progress through the game's five-act storyline.
While the basic enemies in the game can be mowed down in waves, taking down a boss is extremely different. They have up to 1000x more health than a regular enemy and some of them can kill you in 1-shot at higher difficulty levels. Leading up to each boss is usually a multi-level dungeon which must be traversed. It contains hordes of regular enemies which you must carve a swath through to reach the end boss.
In order to facilitate the defeat of these powerful demons, your character gains experience and levels up by defeating enemies. This gives you stronger spells and abilities. Combine that with the thousands of different items enemies can drop, and it becomes all about getting the best loot. With the right equipment and spells, any previously impossible boss can be taken down with some effort.
The two core elements found in Diablo 2 match up with my main BrainHex types. Conquerer is found in Diablo 2 with the arduous boss fights; I died many times to Duriel and Diablo in particular. The feeling of fiero when finally defeating one of these challenging bosses is a thrill and really made the game fun for me. It also encourages players to go back to previous bosses, enhancing its replay value for the fun-inducing boss fights.
Taking into account my Daredevil type, smashing through a dungeon at high speeds is quite the thrill in Diablo 2. With the proper spells you can take out a dozen+ enemies at once and just keep on moving. Blizzard designed the dungeons to have low-downtime to keep the epinephrine pumping and keep the player engrossed in the game world. Its a lot of fun to go through dungeons at high speeds and obliterate everything in your path.
In contrast, Super Smash Bros. Melee has a whole different set of game mechanics. There is no levelling up, no stats, no equipment sets, no real bosses, and no largely different levels. The game play is comprised of picking a character and using combinations of controls to perform various attacks. Every character has unique attacks and properties (ie., agility and power) which affect how they are played. A skilled player can use these properties to their advantage and defeat their enemies.
SSBM focuses on the multi-player aspect because at its core it is a fighting game. When playing against my friends I noticed I enjoy the game most when I am fighting others that are also skilled and prove to be a challenge to defeat (this also ties to the flow theory!). My Conquerer type comes out when I am fighting a skilled opponent, as I enjoy the level of difficulty and it feels great to defeat them when I am trying my hardest.
You'll note I also had 7 points in the Socialiser type, showing that most people are a mix of 6 or 7 of all the personalities. This is prominent in a multi-player situation where you are physically with all the other players. Fighting against NPC's in Smash Bros is boring because they are both too easy, and not as interesting as fighting real people where social dynamics can come into play.
The fact that tournaments are still held for SSBM 11 years later shows that the developers really hit the mark for creating a fighting game which keeps players interested. The video shown is in real time, and as you can see both players are moving with extreme speed and precise control. The Daredevil personality in me really enjoys the fast paced nature of Melee and the role skill plays into being good at the it.
Being able to concisely control your characters movements is absolutely crucial to winning in Melee, and that embodies the personality of a Daredevil. To prove my point, just look at the differences between Melee and Brawl. My friends and I have boycotted Brawl because its just too sluggish in comparison, and the matches seem much slower. Even the gravity is reduced and overall its not nearly as fun. Maybe I'm saying this from a more experienced perspective, but the below video is so much less interesting than the previous one.
To summarize, the BrainHex model is based on 7 different gamer (not necessarily) personalities which tie into various types of games. Different genres of games can be fun for the same types of personalities despite much different game play mechanics. My type was Conquerer-Daredevil and the two games I presented prominently displayed these personalities. Despite them totally different genres, they are both very fun to me because they suit me in a way that satisfies my psychological needs as a gamer.
Monday, March 12
Priorities
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
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
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
Subscribe to:
Posts (Atom)