The hitboxes are WAYY off, the game is very cute and cozy
b8horpet
Creator of
Recent community posts
The idea is cute and very clever. The execution is sometimes buggy, where the clickable controls don't really work, and the game gets stuck.
However, the chomps are not really well implemented, they are not required to land on any box nor to be non-overlapping to count, so spamming Space+G while on the top left corner is a viable speedrunning strategy.
The concept is amazing and funny, the mechanics need some time to get ironed out. Also what happens if the debt is payed after the first week? The game seems to not notice this. Or the grind just never stops for cats?
If you push all the buttons at the same time and find the rhythm, the mouths are perma open. Faster flies mean faster reload, so the food only increases over time this way. Maybe letting only one frog eat at a time or counting the food per frog would make more sense in balancing the game?
The idea is neat though and key remapping is a quality feature often overlooked!
sadly it crashes my browser on MacOS (Firefox)
EDIT: it works on safari
The theme is very unique and fun, the upgrades to purchase are insane (i was about to mention how hard the game is without apparent coyote time, when i encountered it in the shop and made me giggle a little, nice 4th wall breaking).
The last questions remains, is there an end that can be reached? Was i just impatient?
The purple number thing is currently coded as poison, but is meant to be antibiotics. To which certain cells can have resistance. If there were multiple antibiotics this can shape the outcome of the game in ways that it might be better to do a little harm if it leads to the competition to disappear.
This was a planned mechanics but cut due to the time constraint / problems mentioned in other posts. The tutorial is also a content that was intended to be created as the levels themselves. The first few levels were supposed to use a subset of the mechanics, like toggle the purple thingy and the green thingy (currently not visible) which would be the food available. And introducing more mechanics later.
This was a quick test level to check if the mechanics are working or not. It was changed in the last minute to enable multiple strains. The center one was the player originally, but that meant instant win without user input, so it was swapped to make it more challenging.
It is approximately impossible now to win, and no content change is allowed during the voting period. After the voting period ends I intend to release game-play updates to this game, because I care about this idea and I think this could be executed way better than this.
Stay tuned!
I tried so hard, and got so far, but in the end it doesn't even matter...
Suffice to say, when I read your comment I was a bit touched, almost to the verge of tears, because not only did you try to play this game, but you replayed it again and again in order to actually try to win. This deserves a proper response:
I was experimenting with the current status of the game, if it is possible to win or not? The goal was to reach 100 cells. I wrote a system to emulate player input to make replays easier (to enable inhuman reaction times even), and experimented with ideal player options.
The best setup was just barrier around the enemy cell and the poison, but even then the player cell did not go as far as needed to win.
Then I touched the parts that used random choice between free cells and possible parents, and implemented heuristics that favor certain behaviors, like let the cell that has more energy multiply (dies probably later), or choosing places that have more food or further to the original cell, or even walls (because then no division happens and the cell does not lose energy from it), but to no avail. The most alive cells in a single iteration was just above 90, and no matter how I tried to "cheat" the random (saying that it is possible if it was true random for events to happen in this particular setup that favors the player) the results stayed the same.
So in conclusion, the possibility to actually win in this build is close to 0, but I cannot prove or disprove the impossibility of it. That would need some major rewrite to search the graph of all possible game states to find a winning move (individually evaluating each random choice), which is not a job for GDScript. And even if I would found one winning state that is reachable in this initial setup, that would probably mean it has astronomically low chance to actually be played out by chance like that. Not even factoring in the behavior of the pseudo random number generator, that might make some patterns of actions impossible to reach, and an entirely different problem of finding a random seed that makes that desired outcome.
Maybe one day i explore the wast possibility space and come back with a result. Or just fix the game and make some actually playable levels.
We'll see after the voting ends...
The game was rushed, and the "content" is missing, as in hand crafted puzzles. This is a debug build, which is probably unplayable as is.
missing mechanics (already implemented in code but not hooked into the UI):
- visualize different kind of environmental factors (poison/food/...) currently posion is visualized, food is not seen
- distinguish between strains of bacteria (the goal is that the strain "Player" needs to survive, by any means necessary, now both look the same)
- different speed factors (now the default is 1.0, gui missing)
- Win condition is now hard-coded to reach 100 cells, could be changed to be sole survivor, or survive a given seconds (simulation ticks)
I want to respect the rules and not add any features after the deadline, and adding a UI toggle to enable an already implemented feature feels like cheating, and not just a bugfix from the user standpoint, so I leave it as it is for the end of the vote period.