Quote from: Guigui on July 01, 2026, 11:48:49 PMI think it'd be better to continue the discussion on the 5 levels demo in the correct thread.

Quote from: HPWsoft on July 01, 2026, 04:56:37 AMFor Fizzles, I still want to keep the core direction mobile-first and more real-time than NeoLemmix. I do not currently plan to make paused skill assignment part of the main gameplay, because that would change the feel of the levels quite a lot.

But your concern about the moving skill popup is very valid. If later levels offer four or five possible skills at once, clicking the correct icon above a moving Fizzle could become too fiddly, especially on touch devices. That is something I need to handle carefully.

Possible solutions could be larger skill buttons, a more stable popup position, better spacing, limiting the number of visible choices depending on context, or another mobile-friendly selection layout. The goal should not be to make players fight the interface. If a level is difficult, it should be difficult because of the puzzle decision, not because the correct icon is hard to tap.

So I will keep the pause design as a separate question, but I fully agree that the skill selection UI must stay readable and reliable once more abilities are available.

Another solution to make assigning skills easier may be to allow to assign skills from the non-moving bottom skill bar in addition to the popup above fizzle ?
Select a (moving) fizzle, have the (non moving) bottom bar highlight which skills are currently available to that fizzle, click on the bottom bar to assign skill to the selected lemmings.
This could be a flow different from Lemmings and not too prone to wrong assignements.

That is a good suggestion, and I can see why it might help in some situations.

However, I also see a possible downside with a fixed skill bar. The player would select a Fizzle in the play area, but then the actual ability menu would appear somewhere else on the screen. That could become confusing, especially on mobile: the player has to keep watching the selected Fizzle, find the correct UI area, move the finger or mouse there, choose the correct ability, and then return attention to the moving level.

In faster levels, that could create its own coordination problem. The player would have to track the Fizzle and interact with a separate UI area at the same time.

The current popup has a reason: it keeps the available actions visually connected to the selected Fizzle. You select a Fizzle, and the possible actions appear directly at that Fizzle. Hitting the correct ability button is part of the gameplay, as long as the buttons remain large enough, readable enough, and fair to use.

I also test every newly designed level myself. If I cannot solve it reliably, or if it feels more like fighting the interface than solving the level, then I adjust the balancing, speed, ability counts, layout, or UI until it works.

So I see the fixed skill bar idea as one possible option among several. I will think about whether it makes sense, maybe as an alternative input method or for specific situations, but at the moment I still think the current popup approach fits the intended Fizzles gameplay better.

The important goal for me is: the controls must stay fair and readable, but Fizzles should still keep its own creature-first, mobile-first interaction style.

Thank you, that is still very useful even without a video.

The Level 5 planter bug description helps. If only one Fizzle turned around at the end point of a plant while all others passed the same point correctly, then it may be related to a very specific position, collision edge, or state of that individual Fizzle. The note that it may have been the same Fizzle that created the plant is especially interesting. I will keep that in mind when checking the planter / bridge logic.

It sounds like the end of one bridge segment may sometimes be treated like a solid edge or blocker for one Fizzle, while the path is valid for the others. That is definitely not intended. Even if it is rare, it is the kind of bug that can become annoying in later levels, so I will investigate it.

About pausing: I understand your point much better now. Coming from NeoLemmix, assigning skills while paused is a very natural habit, and I can see how Fizzles feels different or awkward from that perspective.

For Fizzles, I still want to keep the core direction mobile-first and more real-time than NeoLemmix. I do not currently plan to make paused skill assignment part of the main gameplay, because that would change the feel of the levels quite a lot.

But your concern about the moving skill popup is very valid. If later levels offer four or five possible skills at once, clicking the correct icon above a moving Fizzle could become too fiddly, especially on touch devices. That is something I need to handle carefully.

Possible solutions could be larger skill buttons, a more stable popup position, better spacing, limiting the number of visible choices depending on context, or another mobile-friendly selection layout. The goal should not be to make players fight the interface. If a level is difficult, it should be difficult because of the puzzle decision, not because the correct icon is hard to tap.

So I will keep the pause design as a separate question, but I fully agree that the skill selection UI must stay readable and reliable once more abilities are available.

Thanks again. This is very helpful feedback, especially because it points to problems that may only become obvious when the game grows beyond the first tutorial-style levels.

Thank you very much for trying the 5-level demo and for the detailed feedback.
Small note first: I think this reply ended up in the older thread:
"Fizzles – Original Puzzle Rescue Game With Playable Level 1 Demo"
The newer thread for the current demo is:
"Fizzles – Original Puzzle Rescue Game With Playable 5-Level Demo"
No problem, though — I'll answer here as well.

About scoring and unlockables: I agree. It is probably too early to judge that properly from the current demo. The current version mainly shows the basic mechanics and the first five ability introduction levels. Scoring, progression and balancing will need more testing once there are more levels and more combined mechanics.

The pause / time manipulation point is very interesting, especially coming from Original Lemmings and NeoLemmix. Fizzles is intentionally a bit different here. At the moment, I do not want players to fully plan and assign skills while the game is paused, because that would change the core feel quite a lot and would make many current situations much easier.

The intended direction is that the player observes, reacts, fails, restarts, and improves the solution step by step. Early levels are still mostly tutorial-like and introduce one ability at a time. Later levels are meant to combine abilities more, so the puzzle aspect should become stronger.

That said, your usability point is still useful. Fizzles is being designed mobile-first, and the controls are intentionally placed on the right side, separated from the main play area and easy to reach by touch. At the moment, I do not know of a situation in the current levels where pausing and then resuming would make the player too slow to react. I also do not plan to design levels around that kind of tight pause/resume timing.

So for now, I see pause more as a way to interrupt play or think for a moment, not as a core planning and skill-assignment tool like in NeoLemmix. Still, I will keep the general accessibility and reachability of the pause control in mind as the game grows.

Thank you also for reporting the Level 5 bridge issue. I know the area you mean. If some Fizzles turn around at a bridge edge while others continue, that is not intended behavior and should be treated as a bug. The builder / planter bridges are still one of the newer systems in the demo, so this kind of feedback is very useful.

If possible, could you send me or link a short video showing the Level 5 bridge bug when it happens? That would be very helpful for debugging, especially because the issue seems to depend on the exact position and timing of the Fizzles on the bridge edge.

I'm glad you noticed the instant bridge behavior. That is intentional. The Planter is not meant to be a direct copy of the Lemmings builder. The idea is that a newly created bridge can immediately become part of the path for following Fizzles. As you said, this removes some of the timing headaches from classic builder mechanics, but it also gives Fizzles a slightly different rhythm.

You are right that slow builders in Lemmings create many interesting tricks and level ideas. Fizzles is currently aiming for a somewhat calmer and more accessible direction, while still leaving room for puzzle depth through ability combinations and handcrafted layouts.

Thanks again for playing and for taking the time to write this up. This is exactly the kind of feedback that helps shape the next levels.

Hi everyone,

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

Fizzles is inspired by the spirit of classic guide-and-rescue puzzle games, 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, world and mobile-first interface.

The current demo includes five playable handcrafted levels. Each level introduces one Fizzle ability:

* Level 1 – Digger
* Level 2 – Floater
* Level 3 – Blocker
* Level 4 – Climber
* Level 5 – Planter

The demo also includes player profiles, difficulty settings, progression, highscore systems, music, sound effects, HUD, and a browser-playable version on itch.io.

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

The Kickstarter campaign for the next development phase is also live:
https://www.kickstarter.com/projects/hpwsoft/fizzles-from-5-playable-levels-to-the-first-release?ref=bxjuid

The campaign is intentionally small and transparent. It is meant to support the next concrete development steps: additional handcrafted levels, new abilities, onboarding, mobile UI polish, audio and presentation improvements, testing, and preparation for a first public mobile release.

I'm intentionally not promising a huge game all at once. The current focus is to continue from the existing playable foundation and build Fizzles carefully, step by step.

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

* Are the goals and abilities easy to understand?
* Does the creature-first selection approach feel clear?
* Is the HUD readable?
* Does the demo already suggest enough puzzle potential for later levels?
* What would you expect from future abilities or level mechanics?

Thanks for taking a look.

Hi everyone,

I'm currently working on a possible theme song for my puzzle game Fizzles, and I'd love to get some feedback from the community.

For context, here is a short gameplay video:
https://youtu.be/WrmIY4axcb8

I have created four song variants. Which one do you think fits the mood, visuals, and overall feel of the game best?

Song 1:
https://suno.com/s/JCQKYv9sUJWtu9y8

Song 2:
https://suno.com/s/fTF4zOCY7sXsoOOA

Song 3:
https://suno.com/s/fMxZqjYSXKykc6Um

Song 4:
https://suno.com/s/vdD6NlWQSV2X59bX

I'm looking forward to your votes and, of course, any short feedback on why you prefer a certain version.

Thanks!

I'm currently working on the player/menu screen for Fizzles, and I'd like to discuss one design question with you:

What kind of highscore or statistics system would make sense for a Lemmings-like puzzle rescue game?

The current menu already supports:
- multiple local players
- four difficulty levels per player
- separate progress per player/difficulty
- music and SFX volume controls

My original idea was to add a highscore/statistics screen, but the more I thought about it, the more complicated it became.

A classic time-based highscore does not feel quite right for Fizzles, because I don't want the game to become mainly about speed or pressure. The core idea is still rescuing the creatures and solving the level calmly.

A few possible approaches:

1. Highscore per level and difficulty
Example:
Level 3 / Difficulty 2:
Player A rescued 8/10
Player B rescued 7/10

This is clear, but with many levels it can become a lot of lists.

2. Overall player highscore
Example:
Player A rescued 120 Fizzles in total
Player B rescued 105 Fizzles in total

This is simple and easy to understand, but then the question is:
Should repeated plays of the same level count?
Or should only the best result per level/difficulty count?

The main reasoning is:
The more Fizzles you rescue, the better you mastered the level.

Used abilities are not necessarily a good ranking criterion, because some levels are designed so that the optimal solution requires using the available ability, for example Floater.

So my current question is:

For this kind of game, what would you personally prefer?

- A highscore per level?
- A global player ranking?
- Something closer to "best rescue result" rather than time?
- No highscore at all?

I'm especially interested in what would feel motivating without turning the game into a stressful speedrun experience.

The screenshot shows the current local player menu. Each player can choose a difficulty level, and progress is saved separately per player and difficulty.

Small update:

Thank you again for the feedback on the Fizzles demo. It has already helped shape several improvements and design decisions, especially around readability, onboarding, and keeping the mobile-first control approach clear.

Fizzles will continue to be developed regardless of the outcome of the current Kickstarter campaign. The current plan is to finish a first public version with 10 handcrafted levels and then publish the game on Google Play and the Apple App Store.

I have now created a small Fizzles community and updates page here:

https://hpwsoft.com/fizzles/community/

This page will be used for future development notes, demo news, feedback opportunities, and updates about the next steps for Fizzles.

There is also an optional email signup there for occasional Fizzles development updates. No one is added automatically; it is only for people who actively sign up themselves.

The playable Level 1 demo remains available here:

https://hpwsoft.itch.io/fizzles

Thanks again for taking a look and for the useful genre-specific feedback. That kind of feedback is especially valuable for a puzzle rescue game like this.

I think the important distinction is that instances should not replace the normal game flow.

Fizzles should still be playable as a straightforward level-by-level puzzle rescue game. A player who just wants to play casually should be able to choose a player profile, choose a difficulty, and continue through the normal levels without having to care about points or instances at all.

The points would be earned in the background by playing normal levels, for example depending on rescue performance. But they would not be required for normal progression.

Instances would be an optional extra mode for players who want more depth and additional challenges.

So the structure could be:

* normal levels remain the main game
* normal levels award points based on performance
* points are not permanently consumed
* casual players can ignore them completely
* instances are accessed separately as an optional mode
* players who want more challenge can use their earned points there
* normal level progression does not depend on completing instances

In the player/difficulty menu, this could be presented quite simply: the normal difficulty options are shown as before, and behind or below them there is an additional "Instances" button that opens the instance selection.

So the idea is not to make the whole game more complex for everyone. The normal game stays simple, while instances become an optional layer for players who enjoy planning, optimization, and harder puzzle content.

Thanks, Simon. That is a very useful point, especially the "not Excel" part.

I think you are right that repeatedly leaving an instance just to redistribute abilities could easily become annoying. My intention was to add a light preparation layer, but if the player has to exit and reconfigure several times, the preparation layer may become the main activity instead of the level itself.

Your alternative sounds cleaner: the player carries the available points directly into the level, all abilities are visible, and each ability use costs points. Then the interesting decision happens inside the level: spend points now, or save them for a later obstacle. Restarting or leaving the level would simply reset the point budget.

That would keep the core Fizzles gameplay more immediate. The player still has a progression/resource layer, but without the extra menu loop.

So maybe the better version is:

* normal levels award a limited number of progression points based on rescue performance
* special instances give the player a point budget
* all unlocked abilities are available during the instance
* each use consumes part of that budget
* the puzzle becomes solving the level efficiently with the available budget

This feels much closer to a puzzle game than my original "configure before entering, then leave and reconfigure" idea.

I will think more in this direction. It may fit Fizzles better because the player stays in the level and the decisions remain part of the actual rescue gameplay.

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?

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.

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.

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.

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.