During the 4th block of my 2nd year at BUAS, I worked on the game Owlet. The game was developed in a team of 13 people, which contains designers and visual artists. The project was made with our own proprietary engine, Pepi Engine, which we developed in the previous block. The engine was chosen by the teachers to make a game with over the course of the last block of the year. It was an amazing opportunity to both develop an engine and make our own game using it.
Game Responsibilities
Developing unit behaviors
Worked on building actions (constructing and upgrading buildings)
Creating Pause Menu UI
VFX and SFX for different parts of the game
Engine Responsibilities
Maintaining serialization of actor/level data
Fixing any bugs that occur with our toolset
Created elaborate documentation of various systems for our designers and artists
Owlet taught me a lot about developing a game with your own proprietary engine. A challenge that me and the whole team faced was switching focus from engine to game development. We got caught up fixing lots of small bugs, adding features, as well as additional tools that our designer and artist teammates wanted added to Pepi Engine. We began working on those and a lot of time passed. However, in a few weeks time, we realized we are wasting precious time. In the end, we managed to switch our focus just on time and managed to produce a pretty good game in the end. I learned a key lesson from all of this which was that we need to prioritize what software needs to be developed. Requests from other disciplines are important but in this stage of developemnt, working on gameplay features was much more important.
Another challenge that I faced during the development of the game was learning to build gameplay features with other people's systems. While I was one of the eight developers that made Pepi Engine, some of the systems I had to work with were made as personal projects by some of our teammates before the engine came together. To make things go by faster, I spent time talking the creator of the given system I needed to work with, where they gave something like a "crash course" of how it works. From there, I dove in and figured out the rest through experimenting with their code hands-on. It was not an easy process, but it showed me how to work with other people's code, ask questions that come up and contribute to the project effectively. This taught me how to navigate large and unfamiliar codebases and build features on top of them, which is key when working inside a custom engine.
My main focus during this project was the behaviors of our units and buildings. I used the Finite State Machines to develop the behaviors and also implemented more functionality on top of our navigation system for the flocking behaviors.
Attacking behaviors for the 2 different unit types in our game
Added flocking behavior to the navigation system used by our units
Reworked their pathing behavior to ensure they reach their goal properly
Developed the building action and the ability to upgrade already existing buildings.
Apart from developing new features, a big chunk of my work hours were spent maintaining the engine and fixing any occurring issues. I also worked on documentation for the other team members that had to use the tools of our engine.
Maintaining the serialization of levels/actor data
Worked on elaborate documentation for designers and artists so they understand how to use the engine
Fixing issues with the actor's managers and AI behaviors
Working closely with our system designer, addressing any issues that he encounters with the gameplay features
Apart from my main role as a gameplay programmer, I had to take on other tasks like creating UI elements, implementing sound effects and visual effects.
Implement a pause menu for the game
Create a visual effect that shows the where the player has clicked on the terrain (the destination of the units) to ensure clarity. The visual effect was made in our engine using the particle system that other teammates developed.
Integrate different sound effects using FMOD.