Since we've been discussing the many uses and functionalities of game engines, this blog I will go over the tools my GDW group plans to create in TwoLoc, in conjunction with the GDW and Capstone. Our group (Gallium Gaming) has been working on a multiplayer game over the summer using HeroEngine; for GDW we have been approved to create tools for our game engine instead of a whole new game. This also ties into our Capstone Project, as creating and marketing the game will make up our project parameters.
The tools we make will be created using OOP and Game Engine concepts. We have planned to make tools which will provide extra functionality our project needs to help streamline the production process. With that in mind, our first tool will be a batch image converter. HeroEngine prefers textures be in .DDS (Direct draw surface) format because it uses DirectX for rendering, and .DDS files can be used in several different ways. .DDS files are also readily useable in OpenGL via the ARB texture compression in GLSL.
We chose this as our first tool because we will need to convert all our texture files to .DDS prior to uploading them in the HeroEngine repository. A batch converter will remove the tedious process of saving files as .DDS in photoshop (only after installing the proper plugin from nVidia). The idea is that because a game engine excels at processing and converting data, we can use this functionality to convert any number of texture file types into .DDS's. Polymorphism will be very useful because we can use a virtual function like Convert(); on each input file and they will all be converted, even if there are several different image formats.
The next tool we are planning to create is a HeroEngine model viewer. There is already an existing one, but it only features the geometry and base texture of the model. HeroEngine uses .HGM mesh files to represent objects instead of the standard .OBJ format. .HGM's are special in that they tell HeroEngine the exact shape of the mesh (whether concave or hollow) for collision purposes. We plan to create our model viewer with additional functionality such as applying shaders and post-processing effects to the models.
Once again polymorphism will help keep this tool efficient, as we can Load(); any model and then manipulate it however we want. This can include characters, objects, and any other 3D art assets. We are building this advanced model viewer so we can preview the look of our assets without going through the whole process of getting a model into the game world. This consists of uploading the model to the repository, importing it into the HeroEngine library, and finally loading it into the game world.
Finally, we are planning to create a couple smaller export tools for Autodesk Mudbox and Google Sketchup. The exporters will convert their respective file formats into .HGM files that the HeroEngine can then use. These tools will have a single purpose each, and thus are smaller and lower priority for the game. Like the first two tools, they are primarily designed to streamline the asset production process. We plan to have a large variety of weapons and objects in our game, thus need to be able to develop them rapidly. Once built, these tools will decrease production times in the long run.
Thursday, September 26
Wednesday, September 18
Learning from Errors (Argh!!)
The past two weeks we have focused on setting up all the necessary components of the TwoLoc game engine. In hindsight it was fairly simple but it at the time it felt like there were a million steps and errors along the way. In the end I actually had to delete everything related to TwoLoc and restart the process, my laptop nearly breaking in the process. This will be a short story of the setup process and what I learned along the way.
To begin, we got two links for BitBucket, a file-sharing program with an online server. In conjunction with TortoiseHG, we used the two links provided in the tutorial to clone repositories onto our local machine. There were two main files: The dependencies and the engine itself. The dependencies are all the files which the engine requires to run, while the engine executes the programs itself. After a lengthy process (everyone was cloning at the same time), we now had a client-side version of the engine and dependencies.
The next step was to install the PATH directories for the dependencies. We opened up a .bat file which performed this task. To make sure everything worked properly, we installed the Rapid Environment Editor, a program to easily manage file paths. The key is to ensure the environment path matches your local files. Everything is going well so far, but it soon went downhill.
With the paths setup properly, we went into the dependency solution and performed a build (making sure it is set to Debug, not Debug_dll). At this point the errors began. The errors indicated that the program could not find a file called dhinput.cpp. Saad and I looked through and found the file, so it was definitely there. After a bit of investigating, we discovered one of the file paths in the include directory was missing a backslash. We made sure to fix this in the REE as well.
With that done, a new build of the dependency solution proved more successful. The rest is simply repeating the process for the TwoLocEngine. After clicking the install.bat file, the path setup only took 2 seconds which seemed suspicious. Upon trying to build the engine, there were missing file and linker errors all over the place. Checking back to the REE, I found the path did not get set up properly for the engine. Fixing that, I tried again and got a corrupt library error. At this point I asked Saad for help and we fixed it, but the error was reoccurring.
Getting very frustrated, I deleted everything to do with TwoLoc and started from scratch. A couple blue screens and a Windows Recovery later, I re-cloned the repositories and rebuilt all the solutions. This time I checked every path before-hand, ensuring nothing went wrong along the way. Sure enough the 2nd attempt was much smoother and I could actually try out some of the engine samples.
Once in the engine, you must first select a project and set it as the Startup Project. This means it will open all pertinent files for only that project when you try to debug. One final step is to copy the linker directories into the debug working directory. This makes sure all the files end up in the proper location once you run the project.
Yay! The projects ran and I played around with the samples. Unfortunately the physics cannon was broken, and Saad walked us through using the call stack and break points to debug the issue. The culprit was an overflowed buffer, and a quick increase in buffer size was sufficient to fix the error. It was a rocky start, but I can finally get to blowing things up with a physics cannon.
To begin, we got two links for BitBucket, a file-sharing program with an online server. In conjunction with TortoiseHG, we used the two links provided in the tutorial to clone repositories onto our local machine. There were two main files: The dependencies and the engine itself. The dependencies are all the files which the engine requires to run, while the engine executes the programs itself. After a lengthy process (everyone was cloning at the same time), we now had a client-side version of the engine and dependencies.
The next step was to install the PATH directories for the dependencies. We opened up a .bat file which performed this task. To make sure everything worked properly, we installed the Rapid Environment Editor, a program to easily manage file paths. The key is to ensure the environment path matches your local files. Everything is going well so far, but it soon went downhill.
 | |
| The paths look good! |
With that done, a new build of the dependency solution proved more successful. The rest is simply repeating the process for the TwoLocEngine. After clicking the install.bat file, the path setup only took 2 seconds which seemed suspicious. Upon trying to build the engine, there were missing file and linker errors all over the place. Checking back to the REE, I found the path did not get set up properly for the engine. Fixing that, I tried again and got a corrupt library error. At this point I asked Saad for help and we fixed it, but the error was reoccurring.
Getting very frustrated, I deleted everything to do with TwoLoc and started from scratch. A couple blue screens and a Windows Recovery later, I re-cloned the repositories and rebuilt all the solutions. This time I checked every path before-hand, ensuring nothing went wrong along the way. Sure enough the 2nd attempt was much smoother and I could actually try out some of the engine samples.
Once in the engine, you must first select a project and set it as the Startup Project. This means it will open all pertinent files for only that project when you try to debug. One final step is to copy the linker directories into the debug working directory. This makes sure all the files end up in the proper location once you run the project.
Yay! The projects ran and I played around with the samples. Unfortunately the physics cannon was broken, and Saad walked us through using the call stack and break points to debug the issue. The culprit was an overflowed buffer, and a quick increase in buffer size was sufficient to fix the error. It was a rocky start, but I can finally get to blowing things up with a physics cannon.
Monday, September 9
Hero Engine: An Overview
To start this round of blogging, I will begin with a quick look into an engine several classmates and I have been working with over the summer break. A group of us have been working on a multiplayer game called They Stole My Sheep. It has been designed to not take itself too seriously while tuning the game play to promote a competitive atmosphere. We chose to use Hero Engine because of its relatively easy to use interface and multiplayer capabilities.
Hero Engine features a full graphical UI as well as a script editor, similar to how Unity is displayed. The Engine comes with several pre-loaded base scripts which the user must adapt to work with the game they are creating. The game world itself is constructed through the use of a height map editor and various terrain tools such as Speed Tree. These features combined with importing custom characters and models, you are able to build a fully functioning game with prominent multiplayer features. One such example is the MMO Star Wars: The Old Republic which was released at the end of 2011 with positive reviews.
The engine contains two main programs: Hero Blade, which runs the scripts and houses the game world, and the Repository Browser, which enables easy transferring of files from your computer or shared network storage over to the server-side storage of Hero Engine. Both of these systems form the basis of Hero Engine and creates an efficient pipeline to gets assets into the developer's game world.
Within Hero Blade, several key systems provide the functionality of the engine. These include: Terrain Editor, HeroScript Editor, physics tools, and editors for lighting, GUI, post-processing, water, and particles. In addition it provides helpful error messages in the chat panel to accelerate the bug fixing process. The Repository Browser primarily syncs files to and from the client and server.
After learning more about the nuances of Hero Engine, we have come across many of its pros and cons. While it does boast many different networking capabilities, we have found that some of its functions are tricky to use effectively, let alone find them. This steep learning curve is also hindered by the low level of documentation for Hero Engine. There is a wiki for the engine but it is not very comprehensive and the forums often don't have the concrete answers we are looking for.
With all that said, Hero Engine has provided us with handy world editing tools with which we rapidly set up a full game level. The process to set up the art pipeline takes a few minutes, but after that the artists can sync files to the server with ease. The asset pipeline has also been very beneficial for the artists, as any model can be transferred and updated in real-time while the engine is running, allowing for immediate feedback in the game world.
Though our team has been presented with many challenges, we are determined to unlock the potential of Hero Engine and fully utilize all its built-in features. I will continue to add updates of our progress as we continually build on the game world we created. Hopefully we will soon have a game play video to showcase and let everyone see what you can accomplish with Hero Engine.
Hero Engine features a full graphical UI as well as a script editor, similar to how Unity is displayed. The Engine comes with several pre-loaded base scripts which the user must adapt to work with the game they are creating. The game world itself is constructed through the use of a height map editor and various terrain tools such as Speed Tree. These features combined with importing custom characters and models, you are able to build a fully functioning game with prominent multiplayer features. One such example is the MMO Star Wars: The Old Republic which was released at the end of 2011 with positive reviews.
 |
| HeroBlade program showing a small portion of our game world. |
The engine contains two main programs: Hero Blade, which runs the scripts and houses the game world, and the Repository Browser, which enables easy transferring of files from your computer or shared network storage over to the server-side storage of Hero Engine. Both of these systems form the basis of Hero Engine and creates an efficient pipeline to gets assets into the developer's game world.
Within Hero Blade, several key systems provide the functionality of the engine. These include: Terrain Editor, HeroScript Editor, physics tools, and editors for lighting, GUI, post-processing, water, and particles. In addition it provides helpful error messages in the chat panel to accelerate the bug fixing process. The Repository Browser primarily syncs files to and from the client and server.
 |
| Repository Browser has synced three files to the Hero Engine server. |
After learning more about the nuances of Hero Engine, we have come across many of its pros and cons. While it does boast many different networking capabilities, we have found that some of its functions are tricky to use effectively, let alone find them. This steep learning curve is also hindered by the low level of documentation for Hero Engine. There is a wiki for the engine but it is not very comprehensive and the forums often don't have the concrete answers we are looking for.
With all that said, Hero Engine has provided us with handy world editing tools with which we rapidly set up a full game level. The process to set up the art pipeline takes a few minutes, but after that the artists can sync files to the server with ease. The asset pipeline has also been very beneficial for the artists, as any model can be transferred and updated in real-time while the engine is running, allowing for immediate feedback in the game world.
Though our team has been presented with many challenges, we are determined to unlock the potential of Hero Engine and fully utilize all its built-in features. I will continue to add updates of our progress as we continually build on the game world we created. Hopefully we will soon have a game play video to showcase and let everyone see what you can accomplish with Hero Engine.
Wednesday, October 31
Tunnel of Love
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.
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.
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.
Subscribe to:
Posts (Atom)