Fizzles – Original Puzzle Rescue Game With Playable Level 1 Demo

[HPWsoft]

Hi everyone,

I'd like to share Fizzles, an original puzzle rescue game I'm developing under HPWsoft.

Fizzles is inspired by classic guide-and-rescue puzzle mechanics, but it does not use any Lemmings, Pingus or other existing game assets, characters, levels or code. The goal is to build something clearly independent, with its own tiny round creatures, visual style, abilities and mobile-first interface.

The first level is already playable. It includes animated Fizzles, music, sound effects, HUD, a digging mechanic, and a complete flow from entrance to exit.

Playable Level 1 demo:
https://hpwsoft.itch.io/fizzles

Kickstarter campaign:
https://kickstarter.com/projects/hpwsoft/fizzles-a-cute-puzzle-rescue-game

The campaign funds the next development phase: additional handcrafted levels and content, new shared Fizzle abilities, UI/onboarding polish, mobile testing, audio/presentation improvements, and preparation for a first public release.

Additional handcrafted levels are planned, but I am not promising a fixed total number of levels at this stage. The campaign is focused on funding the next development phase of Fizzles rather than overpromising a specific level count too early.

I'd be especially interested in feedback from people who enjoy this kind of puzzle rescue gameplay:

- Is the basic idea clear from the demo?
- Does the tap/select ability approach feel understandable?
- Does the digging mechanic feel readable?
- What would you expect from later levels and abilities?

Thanks for taking a look.

[Simon]

Welcome to the forums!

Random assortment of observations, feel free to drill into whatever interests you.

Instinctively, I clicked on the digger icon in the panel. This click has no effect. Then I remembered how Lemmings's skill-then-lemming (= skill-first) deviates from many games' object-then-operation (lemming-first). The next attempt was to click on one of the blue walking fizzles and see if that selects, and yes, it selects and offers the only existing skill. I understood that it was lemming-then-skill.

Clones (clonesgame.com, played with mouse and keyboard) has lemming-first, too. For its slower singleplayer puzzles, it's a matter of taste whether you prefer lemming-then-skill or skill-then-lemming. For real-time multiplayer, geoo and I recommended the Clones devs to implement skill-first in 2011 as an alternative. For the record: The strongest Clones player, rt, plays multiplayer with the originally implemented lemming-first.

By 2011, geoo and I had already played Lix multiplayer for a few years. Lix offers only skill-first. I have never gotten a bug report for Lix that wished for lemming-first. Lix has dexterity-free singleplayer (unlimited rewind, inserting skills into history, ..., effectively TAS) and real-time multiplayer. In multiplayer, it's more important to mine rightward immediately with some lemming than it is to mine with a given lemming that might even turn leftward before we finish assigning miner. In practice: We begin moving the mouse toward the assignee, we press the miner keyboard hotkey, we start holding the filter-right hotkey, and by now the mouse cursor has arrived on the (single, or bunch of several) lix and we click.

Neon Arcade (only multiplayer) has skill-first.

On mobile, you don't have the luxury of mouse and keyboard. Maybe lemming-first is optimal on mobile? I can't tell. At best, I can dig deeper into the design history of the real-time modes of Lix and Clones.


Fizzles's overall pace feels fast. This is fine as long as you remember it during level design. Even easy tasks carry unremovable execution cost. Playtest with people who haven't played multiplayer in Lemmings 1, Lix, Clones. See what kinds of mistakes people make on more complex levels at this pace. If you see, e.g., playtesters assigning too late and bashing into the wrong direction, consider other fixes than heavy-duty input tools: Should you remember every basher assignment until the assignee is in front of a wall? Should lemmings stop for a split-second before turning at a wall? Before falling off a cliff? Before walking onward after landing?

It's also a design choice. Do you want execution difficulty and puzzle difficulty? Or do you want only puzzle difficulty? What kind of pause feature are you going to offer?

The digger tunnel is hard to see against the earth.

Fallers maintain some horizontal speed. This is interesting. Lemmings 2 had it for runners, but it's novel to have it for every faller. You can even design levels around this. On your only level, I managed to kill some lemmings by digging as far left as possible. Some fell leftward past the pole and walked into the abbyss.

The name Fizzles has odd connotation: If it fizzles, there won't be Fizzles.

-- Simon

[HPWsoft]

Hi Simon,

thank you very much for the detailed feedback. This is exactly the kind of perspective I was hoping to get from people who know this genre deeply.

The input model is indeed intentional at the moment: Fizzles uses creature-first, then skill. The main reason is the mobile-first direction. On touch devices, selecting a creature first and then choosing an available action felt more natural than selecting a skill first and then targeting a moving creature. That said, your first instinct to click the skill icon is very useful feedback. It shows that the demo should explain the interaction more clearly, especially for players coming from Lemmings-style skill-first controls.

The question of execution difficulty versus puzzle difficulty is also important. My current goal is to keep Fizzles more on the puzzle-readable side, not turn it into a high-dexterity game. The current pace may be too fast for more complex levels, so I will keep that in mind during level design and testing. A pause feature or a more forgiving assignment flow is something I will need to consider carefully.

Your suggestions about small timing buffers are interesting, especially around wall turns, cliff edges, and landing. I do not want to add heavy input tools too early, but small readability or forgiveness improvements may fit the mobile-first design very well.

The digger tunnel visibility is a very concrete point, and I agree. The tunnel needs to stand out more clearly against the earth. I will put that on the improvement list.

The horizontal movement during falling is currently part of the movement behavior. I had mostly treated it as natural motion, but your observation that it can become a deliberate level design element is interesting. The case where Fizzles can fall past the pole if digging too far left is also useful to know.

About the name: yes, the "fizzle out" connotation is something I am aware of now. The name was chosen because it feels small, round, light and playful, but I understand the double meaning in English.

Thanks again for taking the time to test the demo and write such a detailed response. This gives me several concrete things to think about for the next development phase.

[Simon]

You're welcome!

Even if you re-solve these design problems, it will be worthwhile to see your solutions. You have different constraints than the existing games. And you may well find a solution that blows everything out of the water, and we should all copy it.

For example: Lix and NeoLemmix have savestating frameworks for fast rewinding. That's for manual rewinding to undo a mistake, or for history editing, or to allow the multiplayer mode to react to delayed packets. Maybe you'll decide upfront that you don't need savestating. Your design choices for error prevention must now make sense in a world that can only ever go forward. Compared to Lix/NeoLemmix, this will be a new design restriction. Looking forward to your solutions!

-- Simon

[HPWsoft]

Hi Simon,

that is a good point. Fizzles will probably not go in the direction of a Lix/NeoLemmix-style rewind or savestate system. At the moment, I see it more as a forward-moving mobile-first puzzle game, closer in spirit to replaying and improving the solution rather than editing the past.

That said, some of the problems you mentioned are already being addressed in a different way.

I have now uploaded a new version of the demo on itch.io that includes several changes influenced by your feedback:

https://hpwsoft.itch.io/fizzles

Fizzles now fall vertically. The earlier horizontal movement while falling caused unwanted behavior, especially with floaters, where Fizzles could drift out of the visible level area. Vertical falling feels more predictable and fits the mobile-first direction better.

The selection behavior has also been improved. A selected Fizzle can now stay selected across harmless state changes, such as walking to falling, falling to walking, landing, or turning. This should reduce unnecessary timing pressure without adding a full pause or rewind tool.

I also added a short level information board after the intro. It shows the total number of Fizzles and the number that must be rescued. This should make the goal clearer before the actual gameplay starts and should make the HUD easier to understand.

The digging area has also been adjusted for better readability. The idea is still that the grass layer disappears and the underlying platform/rock material becomes visible, but the freshly opened path should now be easier to recognize.

For the public release, I am considering difficulty levels before starting a level. These could affect the overall pace of the level, from slower and more relaxed to faster and more challenging. Depending on how fair and playable that feels, a time limit could also become part of higher difficulty settings later.

So instead of solving mistakes through rewind, I am currently looking at error prevention and readability: clearer onboarding, preserving selection, predictable falling, configurable pacing, clearer level goals, improved visual feedback, and level design that avoids unfair timing traps.

Thank you again for these detailed observations. Your feedback already had a direct influence on the updated demo. That is exactly why I want to stay close to the community while building Fizzles: the demo shows the foundation, but the best solutions will come from testing, discussion, and iteration.

[HPWsoft]

Since Fizzles is designed as a mobile-first puzzle rescue game, I am also considering a small Android test build for people who are specifically interested in testing the game on real mobile devices.

The browser demo remains the easiest way to try Level 1:
https://hpwsoft.itch.io/fizzles

But mobile feedback would be very useful, especially for things that are hard to judge properly in a desktop browser:

* touch selection: tap a Fizzle first, then choose an ability
* readability of the HUD and ability popup on smaller screens
* timing and pace on a touch device
* whether the digging mechanic feels clear enough
* overall comfort when playing without mouse and keyboard

This would not be a general public release yet, just a small test build for interested testers.

[HPWsoft]

I'm currently thinking about a possible progression system for Fizzles and would like to get some feedback.

The basic idea is to keep the core gameplay the same: each level still works like a classic Fizzles rescue level. Fizzles spawn, walk automatically, and the player assigns available abilities to individual Fizzles when needed.

The difference would be a new layer around the levels.

Instead of every level always giving the player a fixed set of abilities, the player would earn points by completing levels. These points could then be assigned to abilities before entering certain special levels, called instances.

For example:

* A normal level gives points depending on how many Fizzles were rescued.
* These points are not consumed.
* Before entering an instance, the player distributes the available points between abilities such as Digger, Climber, Floater, etc.
* The instance only shows the normal rescue goal at the beginning, for example: 10 Fizzles / rescue 5.
* The player does not know in advance which abilities are needed.
* While playing the instance, the player may discover that a Digger is needed to progress.
* If the current ability setup is wrong, the player can leave the instance without penalty, redistribute the points, and try again.
* Later in the same instance, the player might discover that several Climbers are also needed.
* The player can again leave, adjust the ability setup, and return.

So the gameplay loop would be:

Play levels → earn points → assign points to abilities → enter an instance → discover what is needed → adjust setup → solve the instance.

Normal levels and instances could both be replayed. A level would not give endless points, but could offer a limited number of points based on rescue performance. For example, rescuing the minimum number of Fizzles gives 1 point, rescuing more gives 2 points, and rescuing all Fizzles gives 3 points.

The goal is not to turn Fizzles into a complex RPG, but to add a light progression and preparation layer while keeping the actual level gameplay simple and familiar.

The main question is:

Would this kind of system make the game more interesting, or would it feel like unnecessary extra management between levels?

[Simon]

* If the current ability setup is wrong, the player can leave the instance without penalty, redistribute the points, and try again.
* Later in the same instance, the player might discover that several Climbers are also needed.
* The player can again leave, adjust the ability setup, and return.
Play levels → earn points → assign points to abilities → enter an instance → discover what is needed → adjust setup → solve the instance.

First hunch: Leaving levels for such redistribution is boring. We want to play Lemmings, not Excel.

Detailed investigation: Consider what a single puzzle really is under this design. Each of your puzzles is now a skillbar-configuring mechanism for a level, and the level itself. You can remove the level-exiting (to reconfigure the skillbar) from the flow entirely, as follows. Let the player carry the total points into the level. Each skill is available at all times, and each skill usage costs points. Skills become unavailable when their cost exceeds the remaining points. Restarting levels refills points, and exiting refills points.

The superpuzzle becomes: You have 30 points, and unsolved levels A, B, C, D, and clearly level D takes 70 points, but you don't know which of A, B, C are solvable with 30 points. You merely know that at least one of them is solvable with 30.

-- Simon