itch.io

PNG doesn't support layers so you'd have to have tons of individual PNGs, and the eye color customization doesn't work. You can easily open the PSD in Krita (free software) and export the layers you need as individual PNGs, or create a single PNG containing the combination of features you want.

Click "Buy now", then "I already paid for this".

I think the tags would benefit from a multicolor variant, with each letter having a different color, or possibly even a gradient. The single-color versions look a bit drab, in my humble opinion.

Stealing someone else's work without permission is unacceptable and illegal with or without credit.

A game jam submission is supposed to be a game *you* made for the jam, during the jam period. Not something someone else made seven years ago, which you took without credit  or, as far as I can see, permission.

I wanted to use a CRT shader to enhance the "retro" feel of my game. I found a free CRT shader for Godot, integrated it, dialed it down a bit so it didn't interfere with visual clarity too much... sadly, it didn't work properly in the web version.

Then, I considered adding the shader to the Windows version but remove it from the web version, but ultimately I decided to keep things simple and cut it entirely. Seems to have been the right choice - almost everybody played the web version only, I have exactly five downloads for the Windows version.

My lesson here is that web is king on itch.io and in future game jams, I'll most likely focus on that platform exclusively. It also shows that time constraints aren't the only constraints.

Thanks, the Frogger reference was definitely on purpose, although I feel I could have done more with moving hazards than I did.

I had never heard of Vlak (I was 2 years old when it came out) but I gave it a quick try, it looks interesting.

Make sure that your game starts and correctly scales to the viewport.

Make sure that the game you uploaded to itch.io actually *starts*.

Make sure the potential player doesn't need to download Java, Python, or whatever in order to run your game.

Make sure that the controls are documented, at the very least in the description, but ideally in game.

If you fail at one of these points, people are unlikely to play your game, let alone rate it.

Making mistakes is human, but if you made any of these, learn from them for the next time you do a game jam.

Your game is broken. The ZIP file does not contain the .pck file generated by Godot.

The graphics are mostly from Urizen's 1-bit tileset and I couldn't have made something like this without third-party asset packs.

Your Github repo is not public, as required by the jam's rules.

I really liked your idea, too!

There seem to be some issues  with moving diagonally.

I enjoyed the game but I have one point of criticism if you revisit it in the future: you might want to move the camera a bit more to the right to give the player a better view of what's ahead.

Stealing somebody else's work from seven years ago and trying to pass it off as a game jam submission is unacceptable and disrespectful to both the original author and to everybody who actually put time and effort into this game jam.

The game is way too hard.

For one thing, you're immediately dropping the player into a level with a note density that is pretty much what you'd see in the harder difficulty levels of most other rhythm games.

You also start throwing those very fast notes at the player before they've had any chance to listen to the music for a few seconds and get a feel for the rhythm.

The lack of audio or visual feedback for hits and misses makes it even harder to establish yourself on the rhythm.

Bottom line: most players are going to lose your game within the first two seconds, and that means you're going to lose most players within the first two seconds. If you want to go for this level of difficulty, you *really* need to ease the player into it.

How does this relate to the game jam's theme, "Scale"?

Fellow Java dev here. Most people aren't going to figure out on their own how to install a JRE and run your jarfile. You should at least include a download link in your readme, but it would be ideal to include a full JRE in your download package.

I'm also completely stumped how to play the game. I somehow got past the first level by moving the mouse wheel while randomly trying all kinds of buttons to see if they do anything. Then I got stuck on the second level (the one with the weights) where I get that the idea is to move the weights onto the scale, but I have no idea how to *do* that. Drag and drop doesn't seem to work, neither does clicking the weight (which makes it move by one or two pixels) and then clicking the place where I want to move it.

You should at least amend your project page to include the controls, otherwise I think you're not going to get much worthwhile feedback on the rest of the game.

And it seems even the app store link is broken...

Congratulations!

You can actually make the snake go faster by tapping the movement buttons instead of holding them. One tap = one tile.

Not what I'm looking for. A real portable app needs to store its settings and other user data on the same device as the executable. Just putting the app on a USB stick does not do that.

Is it possible to do a portable installation on a USB stick?

Yes.

The rules say:

"Create a new public GitHub repository to store the source code and any assets you’re able to share for your entry and push your changes before December 1 13:37 PT."

So, if you have assets that you can't share (e.g. because you're bought them and aren't allowed to redistribute them outside of your game), you don't need to add them to the repository. But if you *can* share them, my read is that you need to do so,

There are many ways to obfuscate the history of a git repo. The easiest is `git squash`, which takes multiple commits and squashes them into one large commit.

You can delete the history of a Git repository.

I'm pretty sure the point is that Github is organizing this jam and they want to promote their product, git, and open-source software in general.

Also, requiring a public git repo doesn't actually prevent anybody from starting development before the jam actually starts.

You could just keep your project private during the jam, then clean it up a bot when you're done developing, and then switch it to public - that's what I'll be doing as well

The reason why most submissions are web games is that everybody can run them as long as they have a web browser, and you can just play them with no download or installation. That means you'll get more people playing your game, more people rating your game, and more feedback.

If your game requires VR hardware, that'll reduce your potential audience by a lot, but if you're okay with that, there's nothing in the rules against it.

Sounds interesting, I'd like to play it. But the way you describe it, it sounds like it could be quite complex. Can you finish this in a month? (I don't think I could.)

Do you think of this as an action game (where the focus would be on relatively simple interactions under time pressure) or more of a puzzle game (where the challenge would lie more in how multiple objects interact with each other)? Answering this question might help you to narrow down which mechanics you *really* want and need, and if you end up with a lot of time left after implementing those, you can always add more.

Whatever you decide to do, good luck with your project!

My read is that you don't need to share any third-party assets (e.g. stuff you buy on itch.io) if their license doesn't allow it. But your code, your own assets, and any third-party assets you *are* allowed to share (e.g. kenney's CC0-licensed stuff) need to go into the git repo.