CAGD 377: Sprint 1
ePortfolio
Blog Post 1: Here we go again
Publication - 2/8/26
The Goal
By the end of the semester, my team, MLG, will display to the world a shipped mobile game called LightFall's Reign. The game is required to have roguelite aspects. The production process will test my team's ability to follow the agile development process and the iterative design process.
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
For the duration of this project, I am MLG's lead designer, a role I am familiar with at this point after having this role twice in previous CAGD classes. As a lead designer, my goal is to ensure that my team can understand the vision that I am pushing for. This means that all descriptions and explanations must be clear and concise to not confuse them. After other experiences as a lead designer, I figured that pushing for clarity at the start would help in the long run, preventing confusion in later moments that could be detrimental to progress. I started this push early, as the same day MLG formed, I created an informal game design document (GDD), expanding on my vision with more concrete structuring. The design document highlighted all the formal and dramatic elements, painting the full picture. Within the document are sections that highlight combat, weapons, and the extraction feature. Creating this document helped get the ball rolling quickly, as essential cards were assigned to each member in less than a day, so production could begin.
A small snippet of the informal GDD, all aspects of the game are within this document for each team member to read and analyze. Any adjustments are made public and brought up to ensure everyone is on the same page.
The Sprint
Sprint 1 started with a strong start, moods were high, the team seemed very capable, with my programmer being one of the best I knew, and my producer being a carryover from CAGD 370. In the first few days, we met frequently to talk about the game's ideas and how it could be improved or adjusted to fit the requirements. During this time, I was drafting the GDD for them to read. After it was ready, I answered all the questions they had. My programmer was already in high-gear knocking out the main setup for the digital prototype, while I worked on the paper prototype.
Paper Prototype Rulesheet
While creating the paper playtest, I wanted to emphasize two things: simplicity and conciseness. Paper playtests were meant to test if a feature was fun or not. The mechanic we aimed to test was the extraction mechanic. This meant we didn't need to completely replicate the digital game into paper form. In my first version of this rule sheet, I tried to transfer the digital to the paper 1:1; this failed dramatically during a group meetup, where playtesters got so confused and lost in both the rule sheet and the playing itself. The final version of the rulesheet was its second iteration, where I removed the fluff from the digital, leaving only the bones to simplify it. Reducing the fluff created a rulesheet that became very concise. To simplify explanations, I used tables to explain damage and assigned dice to card variations to prevent complex and confusing wording. The physical aspect of the paper playtest was with two decks of cards and a set of DnD dice. I used playing cards, as it was less effort than creating customized cards, and everyone would be familiar with playing cards. I assigned tiers for both weapons and enemies, determined by the card's rank.
The Result
Playtesting beforehand helped greatly, as it highlighted issues that I overlooked. The information I gained from those playtests had me make alterations, which benefited the final product. During the in-class paper playtest, we faced minimal issues as players didn't struggle with the rule sheet or play session compared to our first iteration and compared to other teams. The results of the playtest showed that our game was fun and that I had done a proper job at designing a playtest that was easy to understand with minimal confusion.
Player Starting Ship
Most of the sprint was spent on me perfecting the paper prototype. After I was able to complete that task, I began work on the digital prototype in the form of asset models. The first model I created was the player's starting ship, as we are planning to have different ships, each with different abilities. While designing this ship, I took inspiration from airplanes more than spaceships, as I wanted something more streamlined than bulky. Within the game, there are currently four planned weapon classes, so I created four weapon slots on this ship. Since LightFal's Reign is a mobile game, I'm keeping the tri-count down and utilizing high-poly baking for extra detail. During battle, we plan for it to be top-down, while in the hangar, it's 3D.
Laser Turret
After I completed the ship, I began working on weapon models. This one here is the laser turret, pretty self-explanatory. I have the beam modeled, too. I plan to put emissive on it during texturing and see how it works in the engine. A fallback if that doesn't work out is to use the engine's VFX.
Missle Launcher
The missile launcher is another class of weapon within the game; this one is planned to do the most damage in a single strike, but it will take the longest to hit the enemy ship. This missile inside the barrel is a separate model, as it will travel across the screen to the opponent.
Missle
Here's the modelled missile in all its glory, pretty standard as missiles go. I created it using a cylinder and a bunch of bevels and extrusions.
EMP Turret
This is the EMP turret, a very special weapon in the game, as this class only stuns a ship, no damage. I took inspiration from a railgun to create the shape and ran with it. The ammunition is going to follow a similar path as the lasers, with emissive in Painter and testing it in Unreal, and the fallback being VFX.
Bomb Turret
In terms of design, the most interesting is the bomb turret. Since the game is top-down, I wanted to create something different from a round object for a bomb. I'm envisioning the bomb to teleport to opponents, increasing accuracy, and having similar damage to the missile. The plus shape is the bomb itself, with the rest of it being a holder for the bomb.
The Wrap
The conclusion of Sprint 1 already showed me what my team is capable of, and it's motivating me to work harder on the cards I have assigned for Sprint 2. My programmer has done lots for the digital variant, putting us ahead of most groups. And any issues we have within the group are dealt with professionally, with strives to improve ourselves. The paper playtest worked great, giving my team valuable insight as we headed into the digital prototype. I'm very proud of the rulesheet I created. The models I've done this sprint, I'm also proud of.
The Path Ahead
Leading into Sprint 2, I'll be working on the high-poly variants of the models I did here, along with texturing those same models. Other cards lined up for me are the creations of different enemy ships, which will most likely take the remainder of the sprint. Something I already got done was a series of images that gives my team an idea of what I want for the home screen, battles, and hangar.
Sprint 2 Work Teaser
I created the starting screen for my programmer and producer to have an idea, as in this sprint, we're going to expand into these areas if progress keeps going at the rate it is.
Combat Visualized (Contains content found on the internet)
Combat was visualized mainly for my programmer, as he's currently building the cycle of play, and it would help to know what you're aiming for at the end.
Hangar Visualized (Contains content found on the internet)
Ship hangar visualized, the hangar is essential to the rougelite mechanics, so giving imagery towards this helps the creation process. This section will be worked on much later, but getting a head start on planning isn't bad.
Comments
Post a Comment