First Festival Submission

The Big Festival is the most significant games festival in Brazil. Over the years, I've loosely followed it. I wasn't planning on sending the game to the festival. I thought it would be a nice challenge to have it as a milestone for February.

Everything was moving along fine. I playtested to improve the game and raise the quality of the first minutes. The due date was on the last Tuesday of February. Because I only work on the game on weekends, Sunday before that was the deadline. 

I made an awful decision to wait until Sunday morning to make a build. Up until then, I had been playtesting on the editor only. It had been a while since I made one. At first, a few issues appeared that were easy to fix, but then critical problems popped up. The progression wasn't working. To fix that, I decided to block features entirely.

Build Profiles

Gladly I already had a system that allowed me to toggle global flags for specific builds. I call them Build Profiles. I have one for the editor, one for a development build, and one for a release build. 

For each profile, I can configure which features I want or not. For example, I can block entire areas of the game. Aside from the three standard profiles, I can create additional ones. In this case, I wanted one for the Big Festival. I could modify one of my default ones, but this is more organized. This way, I configured a specific profile for the event without touching the default profiles.

Ingame Debugger

Up until now, I only had an in-editor debugger. For 99% of issues, a debugger on the editor is enough for me. Sometimes you are in an actual build and want to unlock an area to test. Or maybe you want to capture footage on a specific stage. All of this without making another build.

Since I already had the debugger for the editor, implementing this ingame debugger was straightforward. I treated it as a different "UI" that calls another class that it's responsible for the action. 

Small Wins

Suppress Audio

• I wanted to lower the music volume when going into the pause menu. I didn't want to mess with the volume directly. I added a modifier that affects the final volume. The modifier is not stored when the game saves. It's set when entering the pause menu and cleared afterward.

Screen Shakes

• I added different screen shake strengths based on the attacks. If the boss hits me, the screen shake is stronger than if I touch a hazard in the game. The player can understand better how much damage the attack caused.

Different Music

• Now there is different music that plays when facing the boss. I also change the pitch of the music when on an "ambush" wave. It's a bit more fast-paced to increase the pressure on the player.

---

For March, the plan is to lock all narrative and UI. 

For narrative, it means I want to have it all written (first draft), and I can't change it later. It can be adjusted, but I can't introduce a character or need to implement a feature afterward. 

For UI, it means that all screens should have their final layout integrated. So all buttons and labels should be in the right place. They don't have to look nice yet or have animation. But again, their position and features to support that should not be changed later.

Thanks for reading all the way. Keep an eye out on Twitter @brightflask.