using the x and z buttons was not a good idea on hungaryan and german keyboard these two was not close and controll the oposite side.
Play game
Breezeblocks's itch.io pageResults
Criteria | Rank | Score* | Raw Score |
Presentation | #3295 | 2.800 | 2.800 |
Creativity | #3738 | 2.800 | 2.800 |
Overall | #3903 | 2.573 | 2.573 |
Enjoyment | #4595 | 2.120 | 2.120 |
Ranked from 25 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
How does your game fit the theme?
You play as a destructible set piece rather than a classic "player" character
Did your team create the vast majority of the art during the 48 hours?
We created the vast majority of the art during the game jam
Did your team create the vast majority of the music during the 48 hours?
We used pre-existing audio
Comments
My bad! I knew there was Azerty and the like, but Z/X are such standard A and B keyboard substitutes for most games that it didn't even cross my mind.
We sadly can't update things while the jam's running. Luckily you can play on your phone ;) or Win + Spacebar to cycle between languages if you're on Windows like me.
The voice acting is top notch, even if the game is a little simple.
This game is fun and it's satisfying to squash all the guys walking along the screen. But I think it's a little too easy, I was able spam one side and not lose. Overall, visually appealing and fun.
Why did I imagine them as Mario for some reason?Either way I GOT MANY OF THEM ahahahah
Nice job! This was pretty fun :D
Thank you and you're not "wrong"! Copy-pasting something for you:
30 seconds after Mark roughly said "Pong but you're the ball" [in the theme reveal video] I thought "Mario but you're the brick" (this ended up being my game, Breezeblocks). Later I thought "Spy but you're the camera/lights", but juggling light and shaders was gonna be more difficult for a noob like me, so I dropped that.
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.
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!
Fun. itβs a great time waster and I had a surprisingly good time trying to beat my scores.
Funny π
Quite easy and relaxing, when you get the rhythm ;)
Leave a comment
Log in with itch.io to leave a comment.