POST MORTEM

Postmortem

Developing Jumpy Adventure was both a technical and creative learning experience, especially when integrating physics as the central component of the gameplay. Throughout the project I encountered several obstacles that required problem solving and experimentation, and each challenge taught me something new about designing responsive, physics-driven interaction in Flowlab. This postmortem reflects on what worked well, the difficulties I faced, and the lessons I learned while building this game and meeting the assignment expectations for physics mechanics, interaction design and polish .

One of the earliest issues I ran into involved the player character unexpectedly falling through the floor. At first, I could not understand why the character ignored the ground completely and slipped straight through the bottom of the level, continuing to fall indefinitely. To resolve this, I had to think logically about why physics behaves the way it does in Flowlab. The ground itself was visually present, but it was not functioning as a physics object. Without being designated as solid and non-movable, it simply offered no collision surface. Once I realized this, the fix became much clearer. I set the ground tiles to be solid physics objects, and I also created a hidden layer of spikes beneath the visible terrain. These spikes do not appear to the player, but they serve as a safety net so that if the character accidentally finds an opening in the level design and falls downward, the player will collide with an object and either take damage or restart the game instead of drifting infinitely into empty space. This small but important addition taught me the importance of establishing clear rules for physics interaction, and it made me more attentive to how objects need to be configured to communicate properly with the physics engine.

Similar observations appeared in other parts of the game. Any object that I wanted the player to collide with needed to be set as a movable or solid object. Spikes and monsters, for example, both had to be configured to physically interact with the player so that collision detection would work correctly. Coins, on the other hand, were meant to be collected, so they did not need to be solid at all. Understanding how to categorize game objects according to their intended gameplay behaviors was a valuable lesson that helped me approach level construction more systematically. I also had to place rocks at the far left and far right edges of the world so the player could not run off the screen. These acted as invisible boundary walls and reinforced my understanding of using physics to control the playable space.

Another major learning moment came from working with animations. I initially had trouble with the monster, player and coin animations because I did not know how to make them begin playing immediately or loop correctly. I discovered that animations can be triggered either through the player’s movement or through a once block at the beginning of the game. This allowed coins and monsters to animate continuously, while the player’s walk cycle triggered only when moving. I also learned how to edit and sequence sprite frames directly inside Flowlab. Since the animation editor works similarly to Aesprite, the learning curve was manageable, and I grew more confident in assembling my own animation sequences. Naming each animation clearly ensured that I could reference them easily in my behavior logic later, which improved organization and readability.

Level linking presented another challenge. I knew I wanted the first level to lead into a second level, but I also wanted part of the second level to loop the player back to the first. While designing this structure, I discovered that Flowlab does not allow direct copying and pasting of node networks across levels. Unlike engines such as Unreal Engine, I had to rebuild the switch and door interaction from scratch in the second level. This was frustrating at first, but reconstructing the logic helped reinforce what each node was responsible for. By the end, I felt more confident in understanding message-block communication, collision-based triggers and how each piece fit together to create a consistent progression system between levels.

The final notable hurdle came from playtesting. My initial version of the game was too difficult, mostly because I placed too many enemies and hazards too close together. The health bar would drop quickly, which made the game feel overwhelming instead of fun. To fix this, I had to repeatedly test the game from start to finish, adjusting spacing, enemy placement and terrain height until the balance felt fair. I also paid careful attention to platform distances to ensure that jumps were achievable without feeling trivial. These adjustments improved pacing and overall player experience and reminded me how essential iteration is in game design.

Despite the challenges, many parts of the development process worked well. The physics interactions behaved consistently once configured correctly, and building logic through behaviors became more intuitive as the project progressed. The combination of gravity, collisions, impulses and raycasts created a world that felt reactive and alive, and these systems allowed the game to meet the assignment objectives for physics mechanics and interaction design. This project strengthened my problem-solving skills, improved my understanding of Flowlab’s workflow and gave me experience in tuning game difficulty through thoughtful playtesting.

Creating this game taught me that physics-based gameplay requires careful attention not just to visual design, but to the foundational rules that determine how every object behaves. Each challenge I encountered ultimately helped me build a stronger and more polished game, and it gave me a deeper understanding of how to integrate physics meaningfully into interactive environments.