Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I had a surprising amount of fun with this, didn’t expected to get used as quick to the mechanics as I did. I also think I had a pretty good run after a while, but a technical issue prevented me from seeing what was left of the time: in full screen mode, the right side cuts off (halfing the »M« in »TIME«… signed: ancient monitor man). Did I not think about trying to press ESC to see what’s going on? Yes.

TUTORIAL

When seeing the manual screen my initial thought was: would be cool one could try out the keys… then I tried doing that at was pleasantly surprised. :) Oh, maybe dropping an info that jumping is also a thing?! I had to learn it the hard way.

SHIELD

First: I dig the look of the shield, that waterfall like movement: very nice. Second: I miss is a visualization of the remaining shield energy (using the outer ring as an »energy bar« could work quite well). And I’d also like to have a way to recharge the shield by doing something, something?! Maybe by accessing a special port within the scene, or by means of smacking bot-butt extra quick; or for being extra-close to one when it goes down so that a kind of energy transfer can take place?! To quote myself: something, something.

Also: kudos regarding the detailed credits screen. Always happy to see that.

I’d write even more, but I have to check at least another game out before the deadline hits (only 45 minutes left, ugh).

(1 edit)

Wow thank you! You don't know how much I appreciate gaming experience feedback as detailed and complete as the one you write. I appreciate it very much.

TUTORIAL. Hehe, yes, I wanted to make it interactive because the game starts off strong... There is information about jumping (and double jumping), I think you skipped it, hehe.

SHIELD. I admit that I tried some of this things. Like puting a duration bar and recharging it after a period of no using the shield. But I still have many programming limitations, even with GDevelop. I've only been learning with that program for just a month and a half. and I'm very very new. Before that, I've only made Bitsy games (extemely simple motor of 1-bit games). I like the idea of implementing the bar on the shield itself and the recharging process by destroying enemies (for example). With more time I`ll explore how to code it.

CREDITS. I'm trying to improve in that sense, it's something we all leave for last... I think, anyway, I forgot to put the author of some assets, I'll have to check it.

SCREEN. Oh! That error you mention has not appeared on any screen I tried. Have you tried playing it on the Gd.games website? Which resolution are using? Maybe I need to check the propeties of the project to adapt the resolution...

Again, thank you very much!!! ^_^

(1 edit)

“Wow thank you! You don't know how much I appreciate gaming experience feedback as detailed and complete as the one you write. I appreciate it very much.”
Thanks! I’m happy my comment was so well received! Now, I would not call it “complete”… which I try to proove by adding a crap load of more nitpicks below. Haha.

“There is information about jumping (and double jumping), I think you skipped it, hehe.”
Whoops. Right there over the player sprite. I’d say gracefully overlooked that one… *cough*. Granting the tutorial screen a bit more thought… the amount of text encountered at first sight is surely overwhelming. It would benefit from applying more principles of visual hierarchy. Using button symbols instead of the words (e.g. “arrow keys”) would make it easier on the eye and also allow for a quicker nagivation of the info (i.e. a first glimpse tells you already what paragraph is about controls, and what is about game elements like enemies, etc.). And a very general tip: for paragraphs one should always use left aligned text instead of centered or right aligned text. Looks more orderly right away and is easier on the reader’s eye.

“SHIELD. I admit that I tried some of this things. Like puting a duration bar and recharging it after a period of no using the shield. But I still have many programming limitations, even with GDevelop.”
Ah sure, that combined with a strict time limit (as in 3 hours … total rando example) makes these things especially tricky. I havn’t yet looked into GDevelop, though I spotted the logo in many Jam games already.

“Before that, I've only made Bitsy games (extemely simple motor of 1-bit games).”
Ah, that one I even tried out! I think I heard about it on a YT channel, normally about D’n’D table top stuff… if I remember correctly he used it specifically to quickly test dungeon designs before he exposes his TTRPG parties to them. Btw, I’d recommend to look into GB Studio … it’s really quick to set up, received a lot of great upgrades with the latest releases, and the coolest thing is that the compiled game can run on original Game Boy hardware (or other handhelds of which some are contemporarly produced… like the Analogue Pocket). And the rather strict limitations (like 4 gray/green shades at max.* – oh boy, it’s 2-bit! – for the original Game Boy) are actually great for beginners to handle.

*… though you can later kick things up big notch by developing for Game Boy color (easily activated by ticking a single checkbox), which allows the handling of several 4-color palettes where multiple can be used within the same screen and even sprite.

“SCREEN. Oh! That error you mention has not appeared on any screen I tried. Have you tried playing it on the Gd.games website? Which resolution are using? Maybe I need to check the propeties of the project to adapt the resolution...”
Yes, I tried it also in the GD.games page with the same result! 1920 × 1200 is my main monitors resolution. I’d assume there’s a section in the preferences of a GDevelop project to tell it how to prioritize the view port’s dimensions to fit monitors with a different resolution. Right now, apparently, it makes sure to match the height, which then potentially leads to horizontal clipping.

Whoops, I just saw that I typed away for a straight hour. Cheers & till later!

Hey, hello again! I am overwhelmed in the best way by this new analysis (hehe). I sincerely appreciate the time and effort dedicated!

Desing issues. Indeed, there are design issues that were sacrificed due to the restricted time for the game development. The addition of keys images in the tutorial or the justification of texts, even dosing the information so as not to overload... They are all excellent ideas!

Motors. Regarding the rest... I don't come from the world of programming or videogame development. I'm learning to get out of my comfort zone while doing things I like, but coding has always been a problem. Tools like Bitsy, GDevelop, Twine, RPGMaker... (I'll also try Gb Studio, but I have an eternal lack of time due my work, hehe; I love the idea of restrictions to force creative solutions) help people like me a lot. We won't do the most polished things, but it serves to democratize creativity and expand gaming ideas. 

Screen. Finally, I already solved the screen failure, thanks to your advice. Now you should be able to play it on GdGames without any problem (https://gd.games/kolde/smash-rush). When I make some more minor changes and design corrections, I will also update the version on itch.io.

Again, I don't know how to thank you for your time, it's quite an honor!! ^^