Pepi Engine

< Owlet

⚒️Language: C++ 🗓️Duration: 2 months 👨‍💼Team Size: 7-8 (All programmers)

⌨️Code: GitHub

Beetle Brawl >

Overview

Pepi Engine is a custom engine that I worked on during the 3rd block of my 2nd year in BUAS. I worked in a team of 8 programmers, developing an engine for RTS games. During this block, all programmers were developing custom engines, from which the best ones would be chosen to go into the next block, where a game would be developed with it. Pepi Engine was one of the chosen engines. With it, we developed our game, Owlet.

Key Responsibilities

Development of the asset explorer and actor editors
Serialization of actor and level data
Development of the core unit architecture
Actor managers for managing lifetime and updates of different actors
ECS maintanence

Asset Explorer and Actor Editor
Unit class architecture and AI

Challenges & Lessons Learned

During the 2 months in which I, along with my teammates, made Pepi Engine, we faced various challenges and problems that we had to tackle. Our greatest ambition was to make the engine as good as possible so that it could be selected to go through to the last semester where we would make a game with it. In order for it to go through, it would also have to accommodate the needs of designers and visual artists. For that reason, we decided that a good toolset would give us a big advantage since it would allow for better collaboration across the different disciplines. This made us think beyond code and consider actual usability of those tools for our teammates.

I was directly involved in the development of our asset explorer and actor editor, which were key for making the process of creating levels and actors (units, structures and props) as fast and easy as possible. The asset explorer gave us direct access to all our assets (e.g., textures, models, materials) and allowed us to drag and drop them in the appropriate fields, making the tool intuitive to use. The actor editor allowed for the fast and easy creation of new units, structures or props. Inside it, you could tweak any values you want/need, easily switch models, materials or even Finite State Machines. Both of these tools were created with the help of ImGUI, an external library that we used for our UI. In the creation of the actor editor, the initial creation and further maintenance of the units and other actors that I made proved beneficial since it allowed me to easily add/remove new data to the different actors. Developing all this together with some of my teammates taught me a lot about splitting up work. I learned how important it is to communicate early about the different tasks, anticipate possible dependencies and build flexible systems that can be expanded later on.

Ultimately, those tools, along with the others that our engine has, like the Finite State Machine Editor or the Terrain Editor, proved invaluable because in the end our engine was selected for the next semester. Making this engine taught me how valuable it is to build tools that can accommodate other disciplines and make their work easier. To make things easier for our designers and artists, we made a thorough documentation of all the engine features, which you can check out here. During that semester, we created our RTS game Owlet.

AssetExplorer - Made with Clipchamp.mp4

Asset Explorer & Actor Editors

Inside our engine, we had an editor that contained various valuable tools that were used during development. Two of the tools were the asset explorer and the unit editors. The asset explorer gave access to all files that we had in our "assets" folder, allowing others to easily interact with whichever file they need to use. The actor editor allows you to create new actors of each available type or edit already existing ones.

My Contributions:

Working with others to design and then implement these complex systems.
Implementing the backend for our unit editor and asset explorer that would be used in our level editor.
Serialization (saving and loading) for levels in our level editor, alongside actor data (stats, position, mesh, model, etc.)

Units

I worked on developing the core logic of the units in our game, setting up all the classes and other data that we needed. I worked with other teammates to develop the units so that everything was structured properly and cleanly, and that it worked together with the ECS and other systems the units needed to communicate with. I also set up the relevant data they possessed.

My Contributions:

Implementation of core architecture of the units such as:

- Inheritance structures and encapsulation of core logic for the units (e.g. spawning and destruction)
- Managing pipelines related to the units that handled their initialization, update and life cycle

LargeScaleBattles - Made with Clipchamp.mp4

Initial Unit Structure - How the class structure of our units looked like at the beginning of the development of Pepi Engine.

Final Unit Structure - How the class for our units evolved in complexity and structure at the end of development.

Other Contributions

One of the pillars of the engine was the actor-managers for our units, buildings, and props. They all handled creating, initializing, and destroying the various actors so that we could easily add/remove them from the scene. This was all done using EnTT and in a data-oriented way, prioritizing performance. Apart from that I had a signifcant role in maintainig the core systems and tools that the engine had.

My Contributions:

Implementing and maintaining the functionality of the managers such as loading and unloading data using the ECS and handling updates of relevant components of the different actors
Maintaining the ECS that our engine uses
Fixing bugs with the various tools in the editor