Building Game Engines: FLY Engine
Engine Architecture Diagram
Link to Engine
Post Mortem
I welcome you to the FLY Engine, a collaborative game engine project from the minds of Gwen Cranton, Jared Weinstein, Gitonga Waigwa, and Andrew Panzone. Through this post-mortem, I will walk you through our design philosophies, scheduling methodologies, future implications of this project (of which there are many), and unfortunate setbacks.
Before we can get into the intricacies of what could be added to our engine, let us first discuss the systems that we currently have in place, along with how we were able to develop them over the course of the past four weeks. Although the design philosophies that inspired this project were mostly spelt out for us via rubric, we were still able to interpret these requirements with the freedom to develop an engaging engine that allows for users to create and modify game objects and their respective components before or during play. From the starting level that we have designed as a launching point for developers using our engine, users can modify the scene however they would like by adding game objects, editing them (I will go into further detail on this), or deleting them if they are displeased. When editing an existing game object, users can select from various components (controller, health, rigidbody, sprite, tilemap, and transform), all of which have their own modifiable fields that can be edited in real time.
In order to showcase the capabilities of our engine, we have developed PHROG (Pretty Hype Really Original Game). In PHROG, you play as George, a cheerful, pixelated frog who loves to catch super sized flies that attempt (and most often fail) to slowly escape his reach. Once George has caught enough flies to satisfy his hunger, he wins and can finally rest! Although this gameplay structure is quite exciting, we could certainly have improved on it given eight more weeks of time. Some ideas included incorporating a projectile component in order to allow for a shooting mechanic, further fleshing out additional and more challenging levels in order to extend gameplay, and adding interactive elements such as non playable characters with fully customizable decision trees.
Now that you have a short summary of our final product, you may be wondering how it is that we got there. Due to this project being constrained to four weeks down the final stretch of the semester, we collaboratively came up with a plan to gradually move elements of our project across the finish line. This involved initially breaking up tasks by epics (engine, implementation, polish, bug fixing) and their underlying features (physics system, resource manager, game object & component structure, etc.) in order to get a full scope of what our engine and game would entail. From this point, we would individually grab tasks from our backlog in order to chip away at these features until we would eventually topple epics! Although we would have liked for this plan to have worked all the way through to the finish line, our perfect plan had become somewhat jaded by unforeseen and unfortunate circumstances that had hindered development in some areas, and in essence, our team had been down one member for almost two weeks of a crucial time in development. Even though slightly disheartened by the setback, our team righteously resurged to collaboratively patch holes and put the finishing touches on our engine and game, which you now have the chance to create and play!
Jared Weinstein Games 