Summary

• First attempt at a 3D game
• Inspired by XCOM: Enemy Unknown (2012)
• Main programmer in charge of graphics
• Also in charge of game design

Personal Highlights

• Started to develop ways of managing engine assets and creating pipelines
• Learned how integrating assets into an engine looks like from an artist perspective and how it connects to graphics programming
• Built debug tools to improve development of other tools like a terrain editor

Video

Project Description

For my junior year at DigiPen Europe-Bilbao, I pitched making a squad tactics game imitating Firaxis’ XCOM: Enemy Unknown. The game really absorbed my attention when I first picked it up and my team members also really liked it when they tried it out. It felt like a reasonable challenge to try to copy it and change the aesthetics of it for a student game. The art team proposed to make it Italian Mafia themed with robots living in flying cities instead of humans. The main hero unit is a “godfather” that the other units have to protect, a rifleman unit, an explosives expert, and a tank that can turn itself into cover. At first, the project started out strong and we got to a place that made us feel pretty confident about finishing something reasonably fun by the end. Our ambitions were too high for an eight month project, and although we got extremely far, we weren’t able to dedicate enough time to it for polish and stability improvements. The end result was a game that worked but that is difficult to follow. The gameplay needs better feedback through animations and camera work, and the environment needs better reactivity. The fog of war system also never worked like we wanted it to. That said, we succeeded in including things like animated 3D meshes (all through affine hierarchical animations, no skinning), terrain analysis and editing, importing meshes and textures easily, and a robust UI system.

I took up the role of graphics programmer for the project. We had taken a 3D rendering class during the summer, which made us a lot more confident about what we were doing in 3D. This project was the point in which I started to really understand how to make game assets be data driven rather than hardcoding values and behaviors everywhere. The engine we built is capable of loading scenes described in json files, which were parsed at runtime and helped us have better iteration times. It also has an archetypes system (also known as prefabs or blueprints) to be able to quickly reuse definitions of individual units or specific objects. The files can also specify which material they use, which defines the shader, texture, and other visual properties of a game object. Lighting uses simple Blinn-Phong shading, and deferred rendering for more flexibility. The rendering side was also able to draw debug line segments, which was extremely useful when building the map editor. It allowed the programmer in charge of it to check that the terrain generator code split up the maps into tiles correctly, and tweak parameters of the terrain generator to fix any issues before importing the data into the terrain editor and cleaning up the map. The project was a great introduction to how much pipelines make a difference when building a 3D game.

Overall, I think the project would have been better if we focused on satisfying the grading rubric requirements first, and then try to add all the bells and whistles and polish we wanted. The scope was too large for an 8 month project that we worked on while also juggling the rest of our degree. We lost time, but we also didn’t account for the mental and physical load of having to deliver things for our other classes. Many things had to be done the “hard way” and would be a lot easier to tackle with modern tools. Back then, graphics debugging tools like RenderDoc didn’t exist, and what was available was very unstable or wasn’t useful to debug why things weren’t rendering as expected. A library like Dear ImGui would have made our lives a lot easier by lowering the barriers to create editor UIs to make scene files and tweak shaders in real time. I carry the experience of building this game with me to this day, and I try to think of ways to improve the pipelines and dev experience of the teams I work with when I can. A team is only as effective as the tools they have access to. They can go very far with ad-hoc and improvised solutions, but even the projects that have extremely strong starts will fail to have a strong finish and to carry that momentum if developers have to go through convoluted processes to make tiny adjustments to the game, or if they are unable to examine the effects of what they change.