Game Engines - Roboy Phyre Engine 6

    An important aspect of the efficiency of our project is to further develop on the implementations of scripting. Ideally we need to use scripting efficiently to save a lot of overall time on compiling and tweaking, as well as implementing a proper design pattern for handling various monotonous updates, for example, different AI’s or simple door triggers and placements. 

    Working on understanding how Phyre works with scripts, we used 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 its own, we were misplacing our efforts to understand and learn things we did not need to at this point. In the end, scripting initialization turned out to be quite easy:

        TRY initialize scheduler (size of scripts memory in bytes, number of scripts, async options)

        Initialize type Script and initialize with data from asset processor //get's compiled script data
    
        Create a scripted component to be linked to an object
        Set script data for component
        Set interval for component
        Set the entry point function for the script on the component

        Pass the script scheduler into the component
        Initialize the script with the function

    In the initialization phase of the program we simply initialize a script scheduler that handles almost everything. Declaring a scheduler with the proper namespace and initializing it is very easy, as we just need to know beforehand the number of scripts and the size we need to allocate for the script’s usage in memory. 

    After including the script in the assets xml, the processor already compiles it and manages the script chunks for the engine. This means that we can simply declare a PScript and set the properties of it, such as the interval, and which function to call when the scripting sequences start running.

    And the lua counterpart of the script initialization, this simple script just utilizes the built in Phyre method of calling bound functions in C++ :

         function onEnter(self)
              local app = get phyre specific local function
              app.callTrigger()
         end

         function onExit(data)
              //leaving animation or door closing animation
         end

    The final step is to actually bind the functions that the scripts need access for to the Phyre engine in the define phase. We simply register the call-backs for the scripts via:

      Phyre Specific, start bind of class name
           bind function (function in class to be used by script)
      Phyre Specific, end bind

    We also 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 into pieces.