Game Engine Tools Development

Throughout my Game Engine Development class (CSCI 522), I encountered several flaws with the engine’s initial architecture which made developing content with it quite onerous. After hearing about my professor’s class on Game Engine Tools (CSCI 424), I knew this was my chance to set things straight and overcome many of the obstacles which make working with Prime Engine such a challenge.

Building on Past Experiences

My first project involved creating a simple build system which synchronized with Perforce, and reported any compilation issues with the build.

Previously, I had written several small tools and a game (Frogger) in Maya. Since Prime Engine’s editor relies  heavily on the Maya viewport, I knew I’d have more opportunities to get familiar with writing Maya tools.

Demolition Time

Teaming up with Ahmad Fauzan Umar, we started dismantling the old tool-set and writing our own. Besides the build system, we added the option to compile and run the engine from the editor, a settings page to manage the engine build type and Perforce credentials, the ability to open the project in Visual Studio, load specific levels, and launch pyClient (a python program which manages the connection between editor and engine).

Flowchart of our game object pipelineIn addition, we started extending the engine’s object pipeline to handle our own data and logic. Our plan was to create structs (saved as json objects) and lua scripts and then pass these lua scripts, along with some generated C++, on to the engine. As a result, we could now use our new struct definition to assign custom variables to objects and then make use of them from within our script editor.


A Real Editor

For our second milestone, we considered features offered by other game engines, and decided that a visual scripting system was a good way to make working with Prime Engine more approachable to designers. Fauzan started writing function wrappers, and making the pipeline more robust, and I set to work setting up a node editor.

Overview of our visual scripting systemAt first, Professor Kovalovs advised us to just use Maya’s built-in node system, but we quickly realized that this would allow users to define any number of relationships both inside of the engine and in Maya. In order to keep everything contained, we opted to create our own node editing environment. In the end, I used a Qt canvas and simple shapes (circles, rounded rectangles, and lines) to create our own node editor viewport. I tried to keep navigation within the viewport approachable, adding in many controls and shortcuts that Maya and Unreal users would find familiar.

We then altered the pipeline to generate snippets of lua from the node structure. Finally, it was possible to use visual scripting to define per-object, as well as global logic within a scene.


Who Doesn’t Want More Features?

As the semester was coming to a close, we realized that the engine was lacking a few features which we wanted to showcase. Namely motion paths and custom object collisions. This time through, Fauzan set off; creating an attachable collider system (along with its own editor), and I started adding spline support to the engine.

Once this was done, we added the new features and functions to our scripting system in addition to polishing and expanding it further. Now it was possible to have objects moving around and colliding in more interesting ways.