Fun idea! Only confusing part is that the "lives" system is a little unclear - I think if you hit the ground without hitting a worker it's supposed to cost a life, and three times you're out? But I tested it a bit and sometimes hitting the ground without workers didn't cost a life, and sometimes hitting workers cost lives, so that was a bit confusing. The sound effects were very amusing and the controls were a fun challenge.
Viewing post in Breezeblocks jam comments
TY for playing!
The first thing you described is a correct assumption, because programming the game with the idea of penalising misinputs would just be mean; "hitting workers costs lives" isn't supposed to happen! The game behaviour goes like this:
- There's two objects at the sides of the stage I called gates, and once the unscathed workers touch them they make you get a strike because you let them through (undesired outcome).
- A worker coming from the left can only interact with the gate on the right and viceversa. This is the first of many design choices made to not let conditions clash.
- Every statement of this kind runs just once and is restricted to the specific objects.
- The workers' states are set at spawn time, so there are at least no portions of code awkwardly going off after that potentially causing chaos with the wrong gate.
- Gates are not barriers, which I placed under each brick to decrease the points each worker gives you (100 to 50 to 25).
- A worker who's been hit will be deleted immediately and replaced with his crushed version in a hard hat. They are different objects like the barriers and not the same with a triggering condition turned off.
You're the first person to describe that happening, but I think I can imagine at least one possible scenario why: like I previously pointed out I've noticed some niche/old browsers or old computers might eff around with either the sprite positions or collision boxes. I made it so that a worker coming from the opposite side of another worker who spawned the previous turn will meet the other worker exactly at the centre of the brick above them, which means that if you notice them being grossly offset when you play, you can be sure something is definitely wrong.
Perhaps when workers of a specific direction get hit when they are past the second brick on your device, their sprite and the gate happen to be offset in a way that they touch when they're not supposed to be close to each other. Again, this is just me speculating on one scenario, basing myself on what I've seen happening. Since everything is quite tightly scoped and the objects are always different, "this worker I took out still made me lose a life" is quite the oddball event, whether it's the engine's fault or mine.
As far as fixing something like this – supposing I did nothing wrong – or the sprite offset that's confirmed to happen on Brave goes... I can only tell people to make sure they're on the last 64-bit version of Chrome/FF, maybe play with one graphics setting (hardware acceleration?) and nothing more. Basically prevention. GDevelop can natively distinguish OSes but not platforms, and even when it is bundled as an .exe it's basically some Electron/Chromium wrapper thingy. The experience is still that of running an HTML5 game through a browser. I don't know if they have the power to fix anything if I go on their GitHub and go, hey, things are looking weird for everyone on Brave who's played my game, as I can imagine they depend on many external projects other than Chromium which they don't have a say on. Reproducing conditions is an exponentially bigger affair than with other engines as, AFAIK, browsers and rendering are the Wild West, due to the little standardisation they have.
That's all I could rationalise as a noob programmer, thanks for coming to my Ted talk!