Post Game Engines: Gamma Gears Analysis

This semester, we had one class in which we as students would be learning more in depths ways to program using engines.  This class was Game Engine Design and Implementation.  At the start of this class, we were introduced to Ogre and Havok and were given full use of these tools in the TwoLOC engine provided by our Teaching Assistant Saad.  Now, my team had created a great engine last year and were slightly upset that we were not able to transfer it over to this years GDW project.  After coming to terms with the fact however, we approached our Doctor Hogue, about possibly taking on something more challenging and unique in comparison to everyone else.  We did not dislike the great drawing abilities of Ogre, or the incredible physics provided by Havok, we just wanted to take on a different approach.  So, in response Dr. Hogue provided use with the Phyre engine that Sony uses on their systems.  Needless to say, we were very excited at the possibilities that were provided by this engine.  

After examining the code structure of the sources provided, and playing around with included level editor, our team started to formulate ideas as to what type of game we hoped to create.  I personally suggested a survival horror game, but the team discarded the idea rather quickly.  Then we stumbled upon the idea of possibly creating a isometric 3D arena brawler game.  After some ideas were thrown around and we came up with a general concept, Gamma Gears was born.  

Now we knew as a team that creating this game with the Phyre engine would not be an easy task.  Since the engine is very focused towards being used by those would helped design the engine itself, we found that it was difficult to find documentation through our search of the assets.  However, we were fairly confident that our programmer James would be able to dissect the assets and get us to a working prototype.  While James was working on figuring out how we would use the engine, Bobby, Vincent and I got to work on creating the assets needed in the game.  This required many stages from concept art, to modelling, then to rigging and texturing the models.  By this point, James was able to get models loading into the engine, so it was time to start animating the models.

The concept of animating for the Phyre engine was very similar to how we would have accomplished the task with TwoLOC, however there were some slight differences worth noting.  In the same fashion as previous years, the characters animation can be set using keyframe animation in Maya.  Whats different about getting these animations to Phyre however, is when the animated model is exported.  Included with our version of Phyre was a plug-in for Maya named the Collada exporter.  What this exporter does, is instead of exporting a standard obj. or maya binary file, Collada exports our animated models as a Phyre compatible .dae file format.  From here, we needed to ensure that our models were being exported to a location that Phyre could work with.  We found that the easiest location for our purposes was the contained Media folder in our Phyre folders.  Once this had been discovered, we as a team were able to implement our main character Alex into the scene.  There was an issue however, as Alex would only sit in his idle position as we had not character controller set up for our asset.  This is when we as a team realized how useful the Lua included scripts in the Phyre engine would be.

Alex in his idle stance in our scene

After the group spent some time reviewing the included Lua scripts in the Phyre sub folders, we realized that we had a choice to make when it came to make our character move around the game space.  Our first choice was to attempt to use the included Character Controller lua script that provided all of the functionality we were looking for in terms of movement, however the script was lacking collision detection.  After searching for some sort of collision script to use, we were unable to locate anything that may assist us, so we attempted to implement raycasting techniques that we had implemented in our game last year.  These techniques also ended up failing as we tried to implement them.  That is when we stumbled across the Physics Character Controller in the media scripts.  This controller allowed us to control everything from velocity to jump height, as well as gravity and the size of the collision capsule that was now attached to the character.  We were very excited as we now had a fully animating character!  However, the character was animating across an empty game world.  So we as a team got to work putting together our scene.

Alex with the physics controller implemented

The Phyre level editor is one of the most fantastic assets for constructing scenes for our levels, as it works in a similar fashion to Maya.  Although we constructed the bulk of the scene in Maya, after implementing it into the Phyre level editor, we realized that micro changes needed to be made to allow for level fluidity and function.  In other engines, this would require movement back and forth between Maya and Phyre, but the level editor allowed us to change and test these options on the fly.  After some hard work, we now had our character animating within a scene! 

A screen shot of our scene in the early stages of development!

Our next gameplay focus could not have been more perfectly timed, as it tied directly in with the homework assigned for the class.  This was of course the trigger system that we had been in need of since production began.  Since our game have different power-ups that the character needs to collect in order to become stronger and faster, we needed some form of triggering to occur to signify that the item needs to disappear from the screen.  How this works in the engine involves the use of included lua trigger reciever and quarrys scripts, as well as trigger bounding boxes that are also provided in the engine.  The first step is to link the trigger receiver to the bounding box that is created around the object we wanted Alex to collect.  From this point, we are able to add the quarry to Alex's physical collision body.  This allows the engine to recognize not only when something has collided with the trigger, but also check that it is Alex's physical body colliding.  From this point, the item in question will disappear when the proper bounding box makes contact with the proper trigger.  It was a very difficult task to figure out, but it helped not only with the game progress, but also with our class workload as well.

Our final stages for this semester was to implement an attack animation and then transfer all of this data to our Phyre project that we had designed and set up in Visual Studio 2012.  To implement the attack animation or our character, we used the same method as all of our other animations, but with a special twist thrown in at the end.  Since we needed to ensure that the player makes contact to the NPCs in the game to do damage, we needed to add a separate trigger to the gamespace occupied in front of Alex when he attacks.  Once this trigger was set, we added quarries to all of the NPCs to allow them the ability to recognize when they are getting hit/taking damage.  Since we had already figured out the trigger systems in the Phyre engine and how they functioned, this task was accomplished very quickly and efficiently. 

From this point, the team just needed to export the Phyre level editor information, into the Base Phyre project we had set up to accommodate the incoming files.  Although our first several attempts had some issues with animation and triggers, we were able to make the necessary adjustments needed to have a fully functioning prototype for the due date.  

Gamma Gears in its current stage is in no way a completed title ready for release.  We as a team are aware of the work that remains before we can successfully call our title a game.  With the base framework set and our newly gained knowledge of the Phyre Engine however, we all feel that the new semester will be a productive period for all of us working on Gamma Gears.  

The Camera Systems of God of War III!

God of War III is a hit title released by Santa Monica Studios and Sony Computer Entertainment.  As the third title in the God of War series, GOW III was released back in 2010 for the PlayStation 3.  As a third person action adventure game, GOW III falls into a category that is filled with great titles from various AAA developers.  Because of this reason, the developers of the GOW series needed to differentiate themselves in a way that had not been seen in the current market by players.  The main way the developers chose to do this was through the cinematic feel they imbued in the franchise, via their in game camera systems.  Since I have already covered the basics of camera systems in games in my previous blog post, this post will focus more on how GOW III designed, tweaked and implemented into their game to create these breathtaking cinematic experiences that have helped to cement this series as one of the greatest third person action titles of all time.

At the beginning of the development of the GOW III camera system, Sony Santa Monica realized that one of the main reasons their games have been so successful, is because of the camera systems that they have implemented in their two previous titles.  For this reason, SSM wanted their third title to have the most epic feelings possible for the player experience.  To accomplish this task, four of the 120 team members working on the title were given the sole tasks of creating and implementing this intricate scripted camera system for GOW III.  The teams theory behind having a completely scripted camera system tied in with their already outstanding gameplay mechanics that had been working for the past many years.  They felt that if the gameplay in a game is solid and fluid, why should the camera be focused solely on the characters close vicinity, when it could pan across a beautiful scene while the player hacks and slashes their enemies.

This scripted camera system is unlike most traditional third person games where the player is given control of camera movement, since in GOW III the player has no influence on camera position.  For this process to be successful in game however, there must be a significant amount of time put into each cameras exact position.  For the GOW III team, this whole process started out with simple level design sheets being provided to the camera team.  With these design sheets in hand, the team is able to figure out the best locations for camera placement based on enemy locations, where the player needs to be moving towards, and unlockables that need to be visible for the player.  Once all the cameras have been implemented and playtested, the camera team sends their work to the art department.  This is where the majority of the level and camera design time is spent, as the artists are required to create these massive and epic scenes around the camera design of the level.  Before the completion of a level, the art department will send the level back to the camera team, as many cameras will need micro adjustments to work within the level being designed.  This is a very tedious process for the team, but it is necessary to accomplish that cinematic feel that everyone looks for in a GOW title.

What the camera team sees while designing a level!

Now, since a scene can have anywhere form a few, to dozens of camera locations, the design team needed a way to keep everything within the frame, while simultaneously showing the landscapes and epic designs that the artists had spent so long working on.  The first system that I discovered while learning about the GOW III camera system was the rail/dolly system they used.  This system was mainly introduced in the GOW III as the technology had advanced enough to allow for this.  Usually this system was used in long linear sections of the game.  How this system works, is that the designers would set a NURBS curve along the path they want the character to take.  A camera is attached to this curve, as well as many points that the camera can smoothly interpolate towards.  The animations are mapped to the rail as well, and during each frame, the system calculates the nearest point on the rail in relation to the character model, and interpolate the camera to that point, making for a movie style dolly effect.  Now this works great for following the character, however the designers needed to implement what they called the boom of the camera as well.  This boom was used for calculating the look vector of the camera, starting at the dolly and ending at the target position (generally the character model).  This boom would allow for panning in and out of the scene, as well as up down movement of the camera to allow for showcasing of the beautiful environments of the game, while still keeping the player in the viewport.  

The Rail Driven system used in GOW III

 

Now the system shown above works great in many of the level traversal aspects of the game that are critical to the gameplay.  However, the team needed to design a system that would work for when the main character Kratos is fighting multiple enemies in a large, wide open setting.  For the camera system to work well, Kratos needs to always be in frame and the focal point, but the team also needed to keep all enemies visible for the player as well.  To deal with this dilemma, the team implemented a weighted average camera system.  How this functions is that each character is given a weighting of "importance" in the current scene.  Generally Kratos is the highest weighted the team wanted to keep him as the central atom of the camera.  These weighted positions are all added together and then divided by the sum of all the actual weightings of each character.  This gives the team a value that they can then feed to the boom system to use as the boom target, effectively keeping every character within the viewport of the scene.  An important note is how the team gets these weights for each character (ranging from 0 - 1).  We already mentioned the base weight of the character (how important the character is), but the team also takes into account the distance weight (distance from the hero, not the camera), as well as the activation weight of each character.  This activation weight is used to smoothly transition the camera when an NPC is spawned into the scene (a high weight) or when they are killed off (a low weight).  This value helped to remove the jerking around that occured with the camera when an enemy was killed and the cameras boom target value would change drastically from one from to the other.

This system worked great when the team was testing large battles with a plethora of enemies, but when testing one on one fights, they stumbled across an issue with the weighted average system.   

As seen in the image above, the camera is too far away from the action then the designers had originally planned.  So they decided that instead of implementing the weighted average system throughout the entirety of the fight scenes in the game, they would also implement a new system which they called prioritized framing.  Along with the weighted average system, the prioritized framing system is used in the majority of the large scale battle sequences in GOW III, so I felt it was important to cover the basics of this system as well.

The main focus of this new system, was to ensure that the highest priority entity (in this case Krators) is always remaining in the frame of the scene.  From here the system would work outwards by priority level, doing its best to include as many of the less important entities as possible, while still keeping an acceptable frame distance.  The system worked on an algorithm that functioned as followed five steps to function, the first being centering the camera on the heroes location.  From here, the algorithm calculates the extents of  the lowest of the priority levels.  Now that we have these extents, we can minimally track to frame extents of the current priority level we are focusing on.  Step for is variable in time to complete, as the algorithm must work its way through each priority level completing steps two and three of the process. Once all the priority levels have been completed however, we can calculate the delta to the Azimuth and the elevation that will be needed for the booms target location.  For a visual representation, the framing would begin as this: 

And end up as this, where the red is the out of frame area with NPC's still inhabiting the space:

It was a truly ingenious fix to the problem the team was having, as they came to the realization that not all of the enemies are relatively important enough to be on screen at all times.  Also, if we remember the zoomed out screenshot shown above, the fix implemented by the team showed through as the scene now looked like this: 

Zoomed in more and framed correctly!

The cameras implemented in God of War III are truly works of art that shine through in the gameplay.  Creating these epic cinematic sequences is no small feat by a team, and the work is definitely evident when a player takes control of Kratos.  Not only does that camera work as a viewing mechanism in the game, but it also becomes the players ally at times, giving hints on different unlockables, as well as panning slightly to reveal where the player must go next.  Its a truly remarkable system that I would personally love to see carried into more games in the future.  Hopefully the God of War team can bring this technology to a next-generation game and further prove to us how versatile and amazing a camera system can make a game! 

God of War IV would be pretty nice!

PVP Fight! Bobby Muir's GDP Portal Level

Portal 2 is a great game introduced by Valve to follow up their widely successful and extremely innovative Portal title.  The game involves the player using two portals, one orange and one blue, to solve various puzzles laid out before them.  Unlike the predecessor however, Portal 2 took to the new approach of introducing the idea of Co-op gameplay, as well as furthering the use of the steam workshop to promote the public into building their own levels.

Game Design and Production II has introduced what I believe to be one of my favourite school assignments I have come across to date.  Building a Portal 2 level for marks.  Its a great idea to promote level design and I personally found it to be an assignment with purpose, that also promotes fun.  This blog post however will not be focusing on the levels I have created.  Instead, I will be playing one of my classmates levels, reviewing and critiquing as I play.  For the assignment I have chosen Bobby Muir's classically named "Bobby Muir's GDP Portal Level" to review.  So get your Portal gun ready, and lets go on an adventure.

As shown by the screenshot above, the entrance area to the level is a little underwhelming.  In the distance I can see two droppers, with a fairly lengthy drop to where they land.  After looking above and below and seeing portable walls, my initial thought is that I will have to use a momentum jump here to complete a task.  Sure enough, after using the cube to trigger a pressure plate, an angled plate appears on the upper deck of the jump area, now allowing me to use momentum to jump with the ball over to the ball pressure plate.  It was fairly easy to figure this jump out and I felt as though it set an off tone so early in the level.  I feel as though a different location would be better suited for this jump, as it is seems very out of place and possibly added at the last minute.  

An issue I had with this area occured while trying to launch myself towards the pressure plate suited for the ball.  After gaining too much momentum, I became entrapped in the cage holding the pressure plate, shown in the image above.  Since there was no portable walls around me, I had not choice but to restart the level.  This did not make for a very pleasant start to the level at all.  A simple fix that could have been added, was a room behind the plate with a single portable wall.  This would allow for an escape path, should the player become entrapped in the cage.

Overall however, the room was pretty entertaining.  I can see what the designer was going for, making the player feel as though they are doing a slam dunk with the ball into a hoop!

The Central Hub

As I moved forward in the level, I came to what seemed to be the central hub of the level.  With two adjacent rooms, it seemed like this area was at one point meant to be the starting zone for the character, but was changed at the last moment.  In the one room, I found a room filled with tractor beams, as well as a couple floor and pedestal buttons.  I decided that since I had already solved the slam dunk puzzle, I would move into this room next.

After carefully examining what each button was responsible for, I realized that this zone was going to require careful portal placement, as well as precise timing with the buttons.  What this room require was for portals to be placed on opposite sides of the room, a portal in front of each floor button.  The player must then press both pedestal buttons as quickly as possible.  One triggers the turning on of a timed tractor beam, while the other drops the cube into the first tractor beam.  The player must then portal to the other side of the room to trigger a floor pressure plate, triggering sensitive beam that move the cube to the next position.  In one swift movement, the player must then move through the portal on to the other floor button, grabbing the cube as it falls and moving it to the final position.  From here, the cube is grabbed by the tractor beam triggered by the pedestal button earlier, and moved to the button where it comes to a rest.  Once I moved back into the main hub, I realized that this puzzle had disabled another one of the traps preventing me from exiting (The first being disabled by the slam dunk.)

 

This room really fell short in my mind compared to the slam dunk room introduced to the player earlier in the level.  It was quite easy to complete (only taking me a couple of minutes to solve)  and the reward is not granted to the player in an entertaining fashion like the slam dunk.  I feel as though more of the in game items could have increased the skill needed for this zone, as well as the fun factor.

Next up in my adventure was what I believed to be the final act of Bobby's level.  Since there was only one trap left before the exit was safe, I thought I would be out in no time.  I was wrong.  As I entered the next room, I noticed a few interactive items before me.  I had a laser cutting off my path, a laser cube close by, and a laser receiver high out of reach.  I also noticed that on the far end of the level, the laser receiver led to a lift that would bring me to an unknown area.  I knew that I had to somehow transfer the laser on to the wall across form the receiver to activate the lift.  So, after some carefully placed portals the lift was up and running, without me on it.  To solve this little issue, I found that placing the portal ONLY while I was on the lift was the way to go.  

The lift brought me up to a solitary pedestal button.  Being the overeager person I am, I pressed the button, only to discover that it led around the corner to the trap preventing me from leaving.  So, I headed back to the main room, only to find that the trap had reactivated before my eyes.  It was here that I was hit with the solution, and the reason as to why he had a speed gel spawner in the middle of the room!  Through the use of portals, I was able to hit the button, enter through the portal I had created from the button to behind the speed gel, and speed my way through the trap, just narrowly escaping death!  It was a great finish to the level that left me tense and excited.  

It was a very well executed level by Bobby, but there was one issue that I found.  It was too short.  It was entertaining while I player, but just as I was getting into the level, it was over.  After timing my first run I completed the level in under 5 minutes.  To help add some more depth to the level, I would suggest that Bobby add another room to the central hub.  I really enjoyed escaping the last trap, so I suggest that he utilize this throughout a whole room, creating a constant feeling of excitement and near death experiences for the player.  For his first level however, I was very pleased with how it turned out and I would definitely recommend Bobby Muir's GDP Portal Level to all who play the game.

Escape never felt so good!