FINAL BLAZE
GAME OVERVIEW
Final Blaze is a physics-based 3D platformer with fast-paced combat.
You play as Flint, the embodiment of fire, who awakens imprisoned inside an enormous facility built by the Grimblers, a civilization of sentient robots. As they drain his heat to power their machines, Flint must reclaim his strength and escape, fighting his way out.
Genre: Platformer - Action Adventure
Engine: Unity 6.0+
Team: 9 Weeks
Platform: PC
Duration: 9 Weeks
Role: Lead & Level Designer
SUMMARY
PROJECT LEAD
- Pitch the core idea
- coordinated with other developers
- Assigned tasks and deadlines to the team
- Set up plans to achieve milestones
COMBAT DESIGN
- Designed the core combat system
- Tested and balanced against enemies
- Polished combat after feedback
LEVEL DESIGN
- Went with an iterative workflow for levels
- Tested and balanced platforming
- Designed obstacles and hazards
- created levels from sketch to final version
CHALLENGES & TAKEAWAYS
Teamwork adaptation
Past game projects created expectations that collided with team members' workflow. Learned that not everybody works the same, and people might need different approaches to the workflow. As a lead, that was valuable, and I learned to adapt quickly when necessary.
Communication improvements
Having a clear vision and communicating it to multiple people simultaneously can be difficult. Having the task of organizing with other developers and communicating a shared vision was challenging but very rewarding. Another thing is you can't be too clear when expressing concepts to other members, so being forced (in a good way) to adapt and improve helps me to communicate better with the team.
Level Design production
We were only two designers working on this project, so we had many tasks to complete in such a short time. The mistakes I made during the project helped me better understand level design and how to improve production speed and level planning.
CORE DESIGN
Core Concept
I originally pitched it as a 3D puzzle platformer, but after evaluating our resources, skills, and ambitions, we shifted the concept to a fast-paced action game.
Changing the game's core had both pros and cons. We learned to be more flexible and adaptable as a team, but restructuring the project reduced production time and pushed us to aim for new goals.
Combat Design
I design a combat system that motivates the player to move fluidly and quickly.
Players can shoot at, jump on, dash through, and/or smash (ground stomp) enemies to interact with them. Enemies must be weakened before they can be eliminated.
This method gives the player multiple ways to approach the combat, even adding a pacifist playthrough if the player chooses to. I wanted to design a simple yet engaging combat system that encourages player freedom.
Simple but interesting
Players' attacks consume HEAT.
This is a resource that is consumed with the player's abilities. When an enemy dies, the player regains some of their heat.
HEAT works as health, mana, and ammo simultaneously. Players must be careful and strategic when using their abilities to avoid running out of heat.
COMBAT DESIGN
Inspiration
One of the games that we took inspiration from is Hades. I wanted to create a fast-paced combat where players can combine and chain different attacks.
I loved the freedom of choice that Hades gives the player; even if every run is different, there is always a new, interesting playstyle or combination to experiment with.
example from "Hades"
*Shooting and & projectiles in test room*
I went with this design to add complexity to the combat without adding new mechanics.
I knew that sometimes, to make something better, you can remove or simplify things rather than add stuff or increase complexity.
I wanted to give players the freedom to choose their approach to combat, while also making things spicier, since every action can directly or indirectly affect other actions.
*Dashing + Shooting in testing room*
*Dashing + Ground Pound in testing room*
LEVEL DESIGN
Inspiration
While working on the concept of a 3D isometric platformer, I started to remember having seen something like that before. Then it came to me. Super Mario RPG for the SNES. I used to play this game as a kid, so I knew that it had been done before.
This game worked as a reference in how to do the platforming, but also in what could be improved. It also gave suggestions on how to communicate the player's location in the world and how shadows behave in a 3D environment.
example from "Super Mario RPG"
Level Iteration
During level production, I created blockouts for each room, and later, people tested my levels and gave feedback. Took that information and applied it to the level to improve it.
In this example, when creating the platforms, people reported that the size was too small, and it was difficult to adjust mid-air to land on the next platform.
I adjusted the size of the platforms, gave the player more control mid-air, and adjusted the spacing between platforms to make them more consistent.
After the changes, people's feedback was that it felt nice and fluid on the platform; they even tried to find creative ways to approach the level.
Playtesting
As this game is not only a platformer but also a action combat game where the player must face multiple enemies at the same time, early in the development I created a test room where I spent time testing all the player's ability on simple environments but also against enemies.
I analysed the AI's pathfinding so I could quickly find bugs or glitches with the enemies and balanced the combat so it wasn't too difficult.
Played around with the enemy spawn wave system, where I could adjust the number of enemies and the frequency of their spawn.
Fixed Camera Restriction
We knew that having such a restriction of a fixed camera angle would make platforming awkward and not just difficult to design but also to execute some platforming, as the perspective could give strange optical illusions, but we were determined to try this out. After all, what better way to learn than to try things yourself and see how things actually work?
A small optical illusion in which objects appear to be beside each other when they are actually below.
To make things clearer for the player, I tried to use the restrictions to my advantage. Having limitations can be a good thing, because you know what you can and can't do. When making levels, we soon found that there was an optimal direction the player felt comfortable moving towards, and some directions were awkward.
As an example, we avoided placing platforms or walls between the main character and the camera, so the player doesn't lose sight of themselves and knows where they are standing.
When I wanted to change the direction of the level's path, I made the camera transition smoothly to the new ideal angle of view.
This way, the path forward is visible to the player, not hidden out of frame or behind an obstructing object.
Fixed Camera Restriction
Initially, when working on the level design, we had walls in the rooms. It is a natural thought process when considering a room: the walls are included. We noticed that having walls in an isometric perspective can cause issues, so we started thinking of ways to fix this.
One solution that stuck with us the most was having some kind of occlusion for the walls so players can see their character at all times.
Wall culling example from "The Last Stand: Aftermath"
*This is just for representing the problem*
After we implemented and tested the occlusion, I noticed multiple flaws with this approach. The player doesn't clearly see the path ahead, which can cause confusion or insecurity when pathfinding.
This also affected our goal of experiencing a sense of massive scale in the world, as the walls covered the environment, making it harder to get a sense of the area.
Another issue is that it was taking too long to improve the system, which was taking time away from other things that might need priority.
Then I thought: why not just have a small wall as a representation of the map's border, without blocking the view?
I tested, and it worked. Again, removing features/mechanics worked better than adding to fix the problem.
Changing from tall walls that block the view to small walls that act more like a fence freed the screen of unimportant detail, increasing the sense of scale, visibility, and foreshadowing the path forward. In this case, instead of adding to fix the problem, we noticed that removing elements helped even more.
CONTACT
FIND ME AT: