Game Engines - Roboy Phyre Engine 3

    Going over the third installment of our Phyre engine adventures, this one will be go over a few and little outdated notes about our development, since we got caught up in all the work that needed to be done for the game. First of all, at this point we were focusing on adding and instantiating components in Phyre properly, as we needed to utilize our own editor and importer. 

    We were also focusing on understanding how Phyre actually handles the importing of their own editor type, and with limited documentation and tons of work trekking through the source we were able to learn enough about how the engine works to continue development on our game with our own tools.

    Starting off, we did a lot of reading about and trial and error tests on the physics component for Clusters in Phyre. This was part of looking into adding dynamic properties to components, we first needed to understand how the actual component was working via the source. We looked into how the Phyre engine actually added the components when loading in the .plv (Phyre) levels to help us understand how the components were working. 

    We found out that the importer works at a very low level and reads the tags in the editor data regarding the class descriptor, and instantiates items based on the class name and link hierarchy. 

Modified Phyre level editor export data

    Going over some options for actually adding physics components and rigid bodies to our objects, at first we thought it was fine that we could set up a rigid body in Maya and have Phyre read it in and initialize the proper components and associate them with the cluster, but after brainstorming how we were going to set up and design our levels, we decided we need to create and link the rigid bodies to any item we need to, and this would be a requirement that would help us greatly in developing our own tool for importing. 

    Working through the tiny documentation on the rigid bodies, we had enough information to go about trying to create one and setting it up with the right information and pointers to physics world. After tons of working with break-pointing and checking values to see if everything was being assigned properly in our rigid body component, we finally had one working with the Phyre physics world. 

   Fortunately, since there is limited debug error messages, we were able to step through each line in the debugger while the object was being created in the Phyre core, and found exactly which member variable it was crashing on when trying to use. 

   Meanwhile, we were multitasking and also working on understanding how Phyre works with scripts. Using the build in importer to track how .lua scripts were passed in from a reference in some pre-made XML, to being compiled and working in the engine provided a great foundation for the knowledge of scripting handles. Luckily there was a perfect sample for scripting, and a lot of the manual script compiling and linking that we were trying to do manually, was actually handled within a scripting component that was much easier to initialize. The documentation provided little detail regarding setting up script schedules and compilers, but since the component handles this on it's own, we were misplacing our efforts to understand and learn things we did not need to at this point. 

    While also going through all this information, we found useful information such as built in function names for scripts that Phyre knows to call, casting objects and retrieving data in scripts, and how triggers are handled via script. We found that in scripts with trigger components, Phyre specifically looks for an object that has a quarry component attached, which they describe as an object that can trigger triggers. Given how everything is set up in the engine, it is very easy to group these quarries together and handle each trigger type in groups that make sense to break down.