Bloom
Real-Time Strategy game.
Product Manager / Graphics / Gameplay Programmer
Made in C++ with a custom engine built by the team.
Bloom started as a 6 person 2 semester long project in our sophomore year. We were ambitious and wanted to do a genre that few groups have done in previous years, but our team dwindled to 3 people as some of my team members withdrew from the school. The large scope meant that we were unable to accomplish all we set out to do, but it was still a great learning experience with many takeaways. Below I will share some of the work I did and my experience, with code samples “HERE”. The final product might not be something I’m very proud of, but I gained a lot of experiences with engine development, and have certain things that I was quite proud of.
Graphics
Originally I was not responsible for any graphics implementation early in the project, but due to circumstances causing our team to shrink, we lost our graphics programmers. I downloaded a textbook to self study over the winter break so that I could take on the task. Over a month, I became fascinated by the possibilities and the "newer" features such as DSA so i wanted to experiment with it. I wanted a system that was easy to interface with and was robust. Throughout the project, I worked in indirect draw calls, compute shaders and integrating sprite atlases easily for designers. Some of that can be seen on the code snippets page.
We had issues with the artist workload, and in an effort to reduce the pressure, I was committed to ease the amount of vfx and other fluff the artist has to do. So we made use of renderbuffers, clever particle systems in order to create attack effects, leaves drifting with the wind, with minimal effort from the artist.
Gameplay
I was in charge of the bloom AI, and for that I made a behavior tree system governing each individual units, with an overarching AI based on a blackboard architecture. Since we were short on designers, I also had to test the game out, making sure the systems were balanced and fun to play. It was unfortunate that we had a loss of members, causing us to not have time to finish many of our gameplay goals, but we had a functional game loop by the end of the project.
The player is tasked with defending the sacred tree. Starting with just a hero, players gather resources to build units and defend against the machines. The player wins if they can destroy all of the machines buildings. If left unchecked, the machines will expand and become stronger. The original game concept had an emphasis on base defending with towers and walls, and the machines were meant to be more of a swarm. We had a tech demo of the original concept, with hundreds of entities swarming around some walls.
Editor
For the editor, we used IMGUI for the interface. I set up meetings with the artist to see what she would like in the editor, I wanted it to be as user friendly as possible, and was responsible for some of the integration with the engine. The reading and editing of entity components were done by me. I also wanted to have a behavior tree editor and be able to visualize the paths taken, but did not have enough time. I previously recorded a video showcasing some of it’s features.
Team management
When we were forming teams, there were only a few artists in the program. I wanted to secure an artist. I had my own ideas for gameplay wasn’t too particular about the theme so to entice one we pitched the game idea and asked if there was a theme they wanted. One artist was excited at the proposed game genre, and was how the plant/machine theme came to be.
The artist was initially afraid of having a very high workload so an early priority in meetings were to get down into the details of what the artist envisions, and how the tech programmers can make it easier, like particles with engine instead of having artist animate them. This eased their worries and I made sure that we were clear about the limitations of our engine.
On the programmers side, had separate meetings to detail engine architecture. We then split into teams and had regular meetings to check progress. I reduced as much codependency between the team as possible but had regular code reviews so people were kept up to date on progress and implementation.
We had some team dynamic issues and I resolved them by having 1-1 talks to discuss what they were unhappy with, and mediated discussions with the bigger group. When team became smaller due to people withdrawing from the program, we had to cut down on content and focus on the necessities.
Overall, although I was not very happy with the final product and it was a really stressful journey at times, I’m glad that I was able to try many different aspects of game engine development. While I was always interested in game AI, this was the project that made me interested in graphics and tools creation.