CAGD 377: Postmortem

 

ePortfolio

Blog Postmortem: We did it.

Publication - 5/10/26

The Goal

            By May 7th, my team, L.F.G., will have developed and released a mobile game titled LightFall's Reign. During the development process, we needed to include roguelite elements as per instructions from our professor. To introduce the elements of a roguelite, we needed to implement meta-progression between rounds in the form of upgrades. The only way that my team would be able to meet all the requirements set by our professor would be to effectively follow the iterative design process while applying agile scrum principles.

Vision Statement

            Forge your ship through increasingly perilous battles, risk it for greater power, and take down LightFall.

Game Summary

            LightFall's Reign is a single-player sci-fi extraction shooter where players customize a ship, fight through enemy forces, and decide when to extract or risk everything for stronger rewards.

The Role

            Our team, L.F.G., consists of four members: a lead designer, a producer, a lead programmer, and a programmer. I am the team's lead designer. My role consists of providing a clear and concise vision for the game to the team. From the information I provided, my producer would then create a series of tasks that would be delegated to each team member to complete over a period of 7 total sprints or 14 weeks. It's crucial that I create coherent and concise information in all documents that I produce; if any aspect is unclear, it can lead to development issues later down the line. The goal is to have all members read the documentation and have a collective vision in mind that's as similar to mine as possible. If all members share the same vision, development will go smoothly with little difficulty. This was the case for most of this project, with some emerging issues at the start, but after the halfway point, we had no issues regarding uncertainty about the game's overall design. Even though I encountered very few issues during the development process, I will continue striving to improve myself, as I believe continuous learning and growth will benefit me most in the future of this industry.

Overview

Paper Playtest

 

Paper Playtest Rulesheet

            While creating the paper playtest, I had one goal: to keep it simple and easy to understand. The main purpose of the playtest was to determine whether the extraction mechanic was fun, so there was no need to fully recreate the digital concept in paper form. The rulesheet underwent multiple revisions to ensure it remained simple and concise. In the first version, I copied the digital game too closely, which added unnecessary complexity during testing. In the second version, I removed unnecessary details and focused only on the core mechanics. This made the rulesheet much clearer and easier to follow. 

            To help explain the game mechanics, I used tables for damage values and assigned dice to card types to avoid overly complex wording. The playtest used two decks of playing cards and a set of DnD dice. I chose playing cards because they were easy to use and familiar to everyone. Card ranks represented different enemy and weapon tiers. 

            Playtesting beforehand was very helpful because it revealed issues I had overlooked. After reviewing feedback, I made changes that allowed the final in-class playtest to progress smoothly. Players experienced little confusion with the rules or gameplay compared to the first version and compared to other teams. The results of the paper playtest successfully showed that the game’s core looter-shooter and extraction mechanics were enjoyable.

Weapons

            Since this game's loot is centered around weapons, my goal with the designs was to create something that would evoke something when they saw it in the weapon selection or inventory.

Initial Weapon Development

Weapons

            Each weapon class developed for this game was designed around a unique gameplay role while still fitting within the same sci-fi visual language. The laser turret served as the standard energy weapon, the missile launcher focused on delayed high-damage attacks, the EMP turret specialized in stunning enemy ships, and the bomb turret acted as a highly accurate explosive weapon.

            Since this game is designed with a top-down perspective, I understood that readability was one of the most important design considerations. I focused heavily on creating strong silhouettes that could be quickly identified during gameplay. This design philosophy was most apparent with the design of the bomb turret, where I intentionally avoided a traditional circular bomb shape in favor of something that was more visually unique.

            During this phase, I also experimented with emissive materials and planned out the usage of visual effects for several weapon classes. Weapons such as the laser and EMP turrets were intended to use emissive materials to represent their energy output, while VFX inside Unreal Engine would be used as a fallback solution if the materials alone were not visually effective enough in-engine.

High-Poly Workflow

High-poly weapons

            Once the initial weapon concepts were completed, I moved on to creating the high-poly versions. Most of this process entailed extruding and beveling, which would add a level of surface detail that would improve both the visual readability of the weapons and the quality of the texture baking process

            As I progressed through this workflow, I became more comfortable and entered a "flow state" while modeling, where many smaller surface details developed naturally through experimentation. This was especially noticeable on weapons like the missile and EMP turrets, where additional paneling and surface shapes gave the models more visual depth.

            During this stage, I spent the most time with the bomb turret due to its unique design language. Since the weapon needed to stand out during gameplay, I focused on preserving its silhouette while adding high-poly details to ensure it remained visually striking from above.

High-Tier Variants

            Later in the development pipeline, I was assigned to create a unique mesh for higher-tier variants of the four weapon classes. But before I could work on creating the high-tier weapon variants, I had to revisit the existing weapons to improve their readability, baking quality, and overall visual identity. This mainly affected the laser, missile, and EMP turrets.

Laser Turret (High-Poly)

Left: Old, Right: New

            The laser turret received subtle adjustments to its barrel geometry to fix baking issues that regularly appeared around the tip of the weapon.

Missile Turret (High-Poly)

Left: New, Right: Old

            The missile turret underwent more substantial changes, which ultimately altered it's shiloutte from above.

EMP Turret (High-Poly)

Left: Old, Right: New

            The EMP turret required the largest redesign as the original version had issues when transferring between Maya, Substance Painter, and Unreal Engine. I rebuilt the model using techniques I learned throughout the term after the initial version was created, resulting in a much more stable and reliable asset.

            The methodology behind the creation of the high-tier variants was designed around the idea of creating visual opposites to the lower-tier weapons while still retaining a recognizable connection between them. Instead of scaling up the original designs, I explored contrasting silhouettes and shapes to better separate weapon progression visually.

            The laser turret moved from a boxy design to one that was more rounded.

            The missile turret shifted between inward and outward body shapes.

            The EMP weapon evolved from rounded forms into more angular silhouettes with V-shaped energy rails.

            The bomb turret transitioned from boxier designs into more triangular aesthetics. 

            Using approaches like these helped make each high-tier weapon feel more advanced while still belonging to the same weapon family. The consistent application of material usage helped unify the weapon systems visually. With most weapons sharing titanium, platinum, and aluminium materials for the body, secondary, and trim. Each weapon class received its own distinct color identity to improve readability during gameplay.

New Weapon Classes

            At the same time, the high-tier weapon meshes were assigned to me. My producer approved two new weapon classes: the Beam weapon and the Lightning Chain weapon. Unlike the original four classes, these classes were designed from the start with both low-tier and high-tier variants in mind. This made the workflow much more efficient, as the designs were planned for scalability and optimization from the start instead of being adjusted later.

            Designing both variants simultaneously helped establish a stronger and more consistent design language across each weapon class. It also improved optimization, with some details being modeled directly onto the low-polygon meshes rather than relying entirely on high-poly baking.

            The Beam weapon class focused on channeled energy through a central core and mechanical arms

        

            The Lightning weapon class enphasized lighting-bolt sihoulettes and exposed energy rails.

            Both weapon classes expanded naturally from their low-tier and high-tier forms by exaggerating shapes, increasing complexity, and strengthening their silhouettes. Since these weapons were developed later in production, they benefited heavily from the techniques and workflow improvements that I learned while creating the earlier weapon classes.

            Of all the weapons created during this project, the Bomb and the Lightning weapon classes became my personal favorites due ot how strongly their final silhouettes and high-tier variants communicated power and identity during gameplay.

Enemies

            The enemy design in this game follows the same core principles as the weapon design: color, scale, and silhouette. Enemies needed to be instantly readable during fast-paced encounters, while bosses were designed to feel imposing and clearly signal a higher level of threat.

Standard Enemies

            The standard enemies were designed to fill the fast-paced combat encounters by fulfilling specific gameplay roles within each level. I focused on silhouette differentiation and escalating threat levels rather than individual visual complexity.

            The base enemy was designed as a low-threat, high-volume unit. Its simplified silhouette and optimized geometry help it appear in large groups without impacting performance. Subtle red accents were used in the final textured version to maintain readability while reinforcing its lower threat level.

            The shooter enemy introduced ranged pressure, with a more angular and aggressive silhouette to distinguish it from the base unit. Its visual distinction helps reinforce it as a mid-tier threat, using more red in the palette ot increase on-screen presence.

            The suicide enemy was designed around speed and collision-based gameplay. Its silhouette emphasizes forward momentum through a combination of wing-like and missile-inspired forms. The design itself prioritizes directional readability so players can quickly understand its behavior during combat.

Bosses

            Bosses in this game act as a progression gate between weapon rarity tiers, appearing every five stages across the 30-level structure. Each boss represents a clear difficulty spike and is designed to feel immediately imposing once it appears on the screen. All bosses share a consistent visual identity using matte black bodies, red vertical lines, and titanium trim. This creates a consistent visual language across ecnouters while allowing the designs to evolve in shape and complexity.

            The first boss establishes the core visual language for all future encounters. Inspired by FTL ships, it sets the standard for scale and threat while introducing the recurring red accent system. This ship was originally intended to be the only boss, meaning the design language was not initially built to be modular or expanded into multiple variants. It prioritizes readability and establishes the baseline silhouette and enemy faction identity.

            Inspired by the NASA Space Shuttle, this boss builds on the foundation with a more recognisable aerospace silhouette. The overall design reinforces a clear separation between wings and body while maintaining consistency with the established visual style.

            Based on the Boeing X-48, this boss introduces blended-wing concepts and more abstract geometry. The design begins shifting away from traditional aircraft forms while maintaining structural readability.

            Inspired by the North American X-15, this boss focuses on high-speed aerospace design. Wing proportions and body flow were adjusted to better fit a deep-space interpretation, increasing visual distinctiveness within the lineup.

            Based on the Boeing X-45, this boss features a more angular, functional design language. Straighter edges and sharper geometry communicate increased difficulty and a shift toward a more combat-focused aesthetics.

            Inspired by the Northrop B-2 Spirit, the final boss is designed to feel stealthy and highly threatening. Compared to earlier bosses, it used few accent lines and reduced visual noise to create a more controlled and intimidating presence. This reinforces its role as the ultimate encounter in the game.

            The boss system communicates progression through increasing silhouette complexity, shifting real-world inspiration, and gradual escalation in visual intensity. With earlier bosses remaining grounded in familiar aircraft forms, while later designs become more abstract and militarized. Each boss feels meaningfully stronger while maintaining a consistent visual identity across the entire system, which was the goal after the second ship was created.

Ships

            To expand player customization and gameplay variety, I created additional player ship variants alongside the original starter ship. Each ship was designed with a unique gameplay identity in mind, with abilities planned for a later sprint. A major challenge in developing was ensuring all ships maintained similar proportions despite their different silhouettes, preventing gameplay and UI issues caused by inconsistent screen space usage.

            This is the first ship developed, and it takes cues from FTL's Stealth Cruiser. This ship design was envisioned from the start, as the mock-up art uses it as a placeholder. I believed it bridged a gap between aircraft and spacecraft beautifully. It was repainted from an originally dark color to this white and blue color scheme, which made it easier to highlight the ship's silhouette in deep space.

            This is the second ship developed; it was inspired by the Lockheed F-117 Nighthawk, focusing on an angular and futuristic silhouette suited for a stealth-based role. The production of this craft is unique, as unlike previous models, the high-poly workflow relied more on lighting and sharp-edge manipulation rather than heavy extrusions and beveling. This helped recreate the appearance that's associated with stealth aircraft. In texturing, I did have some issues with baking, but the final result preserved the sharp, aggressive silhouette I envisioned. Alongside it is the drone ship that is used for abilities. I chose a rather simple look since it would be small on the device screens.

            This is the third ship developed, it's inspired by the McDonnell Douglass F-15 Eagle and designed around speed and agility. To preserve its sleep appearance, most details added in the high-poly workflow were in the rear of the craft. The enlarged engine section highlights emissive elements that emphasize propulsion and movement. Despite its distinct silhouette, the ship was carefully scaled to remain consistent with the other ship variants.

            Towards the end of development, I created a large-scale backdrop to help unify and sell the hangar environment. Inspired by the hangar scenes in FTL, I arranged the three main ships alongside several drone ships to create the feeling of an active, lived-in space with ships both docked and under maintenance. To keep the scene visually detailed while remaining performant, all ships were created as high-poly models and baked down onto flat planes, significantly reducing processing costs. I spent a considerable amount of time refining this piece, and I’m extremely happy with how effectively it brought the entire hangar scene together.

Electronic Playtesting

            The internal playtesting focused on creating a complete gameplay loop despite many systems still being unfinished. The overall result of the playtest was that it was successful, with positive feedback highlighting the game's premise and UI design. The feedback helped cement the idea of the project's foundation being strong.

            During this playtest, it highlighted several issues such as weapon rarity balancing, automated combat, and bugs caused by weapons defeating enemies too quickly. Our team used this data and created a pipeline of fixes that were fixed in the upcoming sprint. Although most assets were still untextured due to earlier resolution issues, the playtest was valuable in identifying both the strengths of the game and the areas that needed further iteration.

            The alpha playtest featured a more complete version of the game, with textured ships and environment to improve overall presentation. Due to time constraints, some planned features and weapon implementations were delayed or removed, leading to a few quality and UI clarity issues.

            Despite that, the playtest results were also positive, with no major bugs being discovered. Most of our feedback this time was directed towards clarity, particularly regarding extraction decisions, weapon equipping, and the lack of a VFX for the bomb weapon class. A new feature for this was the addition of manual aiming, but most didn't realize it due to the strength of the auto-aim.

            The feedback we received aligned closely with the team's internal development goals, and most issues that were identified were already planned for improvement in the following sprint. The playtest successfully showed that most issues present in the internal were largely resolved through interactive feedback and testing.

            The beta playtest was the most important testing phase of development for us, as it represented the first time the full game experience was evaluated together. This was composed of the core gameplay loop, inventory system, and newly added ship abilities. At this stage, the game was largely complete aside from remaining balancing issues, minor bugs, and visual polish.

            A major focus during this sprint was increasing the number of playtesters through Kleenex testing with players unfamiliar with the game. This resulted in 24 total playtesters, providing valuable feedback from more casual audiences.

            This playtest showed that most systems functioned well, with the main issues involving weapon balancing, UI clarity, and minor bugs. The largest issue we faced, similar to the alpha, was overall gameplay clarity, particularly surrounding extraction and end-of-level choices, which many casual players struggled to understand. This feedback helped us identify areas that required further refinement and clearer communication.

            The final version of the game cannot be fully evaluated until the end of the semester, but based on our internal testing, we addressed the major issues identified during the beta as effectively as possible within the remaining timeframe. All necessary SFX and VFX for gameplay clarity were implemented, and the “How to Play” section was redesigned to better explain the game’s systems. 
            Due to time constraints, we were unable to implement a fully guided walkthrough, which we identified as the best long-term solution for resolving clarity issues. Despite this limitation, the team worked to improve the experience as much as possible before final submission.

Marketing

            When I was tasked with creating the game’s poster, I was already under a significant time constraint. The poster needed to be completed within two days so the game could be submitted to an award ceremony. Since I did not consider myself a particularly strong 2D artist, I decided to instead create renders in Maya using the assets I had already developed for the game. This approach allowed me to produce polished visuals efficiently while still maintaining the game’s established visual style and identity.

            This was the initial version of the poster, which I spent about a day creating. I tried to keep it visually consistent with the game by using the same top-down perspective. However, the more I refined it, the more cluttered it began to feel. I struggled to clearly convey movement and combat between the ships, and attempts to add laser beams and other effects only made the composition feel busier.

            With only 12 hours left to complete the poster, I decided to scrap the initial version and pursue a new direction that better utilized the 3D nature of the assets. I kept the core idea of the player ships advancing toward enemy forces, but approached it in a more cinematic and less cluttered way. I reduced the number of laser effects to improve readability and removed the weapons entirely, as they felt visually out of place. Although this version was less faithful to the game’s top-down presentation, it worked far better as marketing material and made the game feel more dynamic and exciting. I’m very happy with how the final poster turned out.

Icon

Feature Graphic

            I was responsible for creating the marketing material for the Google Play Store, including the game’s icon, screenshots, and feature graphic. For the icon, I wanted something simple but instantly recognizable as our game. Using what I learned while designing the poster, I used Arnold Render in Maya to create the starting ship flying through space at an angle away from the camera. The result was a simple image with a strong visual identity tied directly to the game. For the feature graphic, I followed a similar approach, repositioning the ship to the side to leave space for the game’s title and additional text.

            I also created a loading screen for the game that took visual inspiration from the final poster design. Although it was never implemented due to technical issues preventing it from displaying correctly in-game, it still served as an additional piece of marketing material and helped further establish the game’s visual identity.

What went right

Left: Proper Bake Right: Bake Issue

            All assets for the game followed a three-step workflow: low-poly, high-poly, and texturing. This production taught me a great deal about the high-poly baking workflow. Early on, I was unsure of the best approach, but through experience, I became much more comfortable creating assets that appeared naturally modeled into the surface rather than simply baked on. During the first sprints, I encountered several baking issues, particularly with the bomb and EMP turrets, which produced visual artifacts during the bake process. These problems were later resolved through reworking and refinement. As I grew more confident with the workflow, I began to see the significant visual and performance benefits it provided, and I plan to continue incorporating high-poly baking into future game projects.

            Texturing each asset was often a challenge, as I needed to balance visual detail with optimization. Despite this, I’m very proud of how the assets turned out, especially the ships, which maintained strong visual quality even with lower-resolution textures. Earlier in development, there were concerns that the textures would appear pixelated, as we experienced that issue during several sprints without a clear cause. Fortunately, the final results allowed the ships and weapons to remain visually distinct while still showcasing smaller surface details. I also experimented with using trim sheets to improve texturing efficiency, but the high-poly baking workflow made that approach difficult to implement effectively. In future projects, I plan to make greater use of trim sheets whenever the workflow allows for it.

What went wrong

            Looking back on some of the models, I believe I could have improved the overall optimization of the meshes by removing more unseen faces and reducing unnecessary geometry. While I did optimize the weapons before implementation, I feel there was still room for improvement. I also relied too heavily on high-resolution textures, commonly using 1K and 2K texture sheets when 512-resolution textures would have been more appropriate for a mobile game. This increased the game’s file size and likely impacted performance more than intended. Moving forward, I plan to be far more disciplined with optimization and performance budgeting, as I would rather follow proper development practices than rely on luck for acceptable performance results.

            Later in development, I created high-tier weapon variants, but before doing so, I had to revisit and redesign many of the original weapons. The initial models were not created with upgraded variants in mind, which made it difficult to visually differentiate the stronger versions while maintaining a consistent design language. Reworking the original assets ended up taking several days and was far more time-consuming than expected. Through this process, I learned the importance of planning asset progression early in development. In future projects, I would design base weapons with upgrade paths already in mind, allowing defining characteristics of each weapon class to be expanded upon more naturally in higher-tier variants.

 

            Most models in the project follow a particular design style that helps the game feel visually cohesive, though some assets fit that style better than others. This was not an issue with the weapons, as those were entirely original designs created without direct references. The inconsistency was more noticeable with the enemy ships. For example, the suicide ship has a far more angular appearance compared to the boxier designs of the base and shooter enemies. Some of the bosses also stand out stylistically, particularly the first and fourth bosses, as they do not follow the same delta-wing-inspired shape language used throughout the rest of the game. When compared alongside the other designs, these differences can feel visually jarring. Looking back, I believe that with more upfront planning and exploration of the game’s visual direction, I could have developed a stronger and more cohesive design language across all assets.

What would I do differently?

            In the pre-production phase of development, I believe it would have been beneficial to create an asset priority list divided into “needs,” “wants,” and “wishes.” This would have given the art team a clearer understanding of which assets were essential, which could be added later if time allowed, and which were lower-priority additions. Establishing this structure early would also have supported stronger design planning by encouraging the collection of references and the development of a more consistent visual direction. With clearer planning, artists would spend less time experimenting with designs during production and more time creating assets that fit cohesively within the game’s established style.

Baking Workflow

           During the first few sprints of development, I was still learning the limitations of the high-poly workflow, which often led me to push the technique further than it could effectively handle. As a result, some assets appeared underwhelming and later required additional touch-ups and reworking. If I had understood the workflow’s limitations earlier, I could have avoided revisiting those assets and spent more development time creating new content instead.

            When assets were imported into Unreal Engine, I encountered difficulties getting them to match the visual quality they had in Substance Painter. Identifying and resolving these issues took considerable time through researching forums, watching tutorials, and seeking guidance from professors. Looking back, I believe that gaining a stronger understanding of Unreal Engine’s asset and material workflow earlier in development would have significantly accelerated this stage of production and reduced time spent troubleshooting.

The Result

            The final result of LightFall’s Reign is something I am extremely proud of, as it closely reflects my original vision for the project. The features we set out to create at the start of development were successfully completed with a level of polish and professionalism that makes the game feel far beyond a typical student project. The gameplay delivers a strong sense of fun and replayability, while the visuals help create an immersive experience.

            I am especially proud of my team, L.F.G., as this project demonstrated how effective a passionate and hardworking team can be when communication and transparency are prioritized throughout development. Seeing everyone genuinely care about the quality of their work played a major role in the success of the project. Overall, this is easily my proudest achievement so far within this major.