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.