TL;DR Summary

• Accessibility is Everything: Make your game easy to play—preferably in-browser with no downloads.

• Test Early & Often: Browser behavior can differ from local setups—catch issues early.

• Iterate Post-Jam: Update gameplay, art, music, and features based on feedback.

• Keep Builds Lightweight: Optimize videos, assets, and overall file size for faster loading.

• Difficulty & Options: Offer multiple difficulty levels and ways for players to progress.

• Art Cohesion: Decide on a clear art direction and stick to it.

• Engage Players: Add banter, dynamic responses, or extra interaction to keep things lively.
  

• Integrity Matters: Avoid fake reviews or spam—honest feedback is more valuable long-term.
  

Accessibility is Everything

If there's one key lesson I learned from this game jam, it's that Accessibility is Everything.

You can have the best gameplay in the world, but if it doesn't run easily (i.e. run in browser with no additional setup required, not a download game).

Download Games got significantly less traction than web browser games in Monkey Jam 2025: https://itch.io/jam/monkey-jam-2025

Worse, ours was a web game, but instead of using index.html our file was called story.html, so it wouldn't run by default - you had to setup a local web server to play the game.

One player on discord commented that you "had to be a professor" in order to run the game.

This lead to an abysmal score - mostly one stars, as it was too painful to setup.

However, it's a lesson learned that I will carry on to the next game jam - so if we look at it from a pure learning perspective, I will never make the mistake again.

Post-Jam Lessons & Tips

Some other smaller lessons I learned, but want to pass on, in case they will be useful to other indie devs:

• Just because the game jam is over and you cannot upload files, doesn't mean that the battle is over. There's still marketing - screenshots, trailers, discord - you can still change the marketing even after the submission is locked.

• Keep things fresh - We had a fishing minigame that simply was moving the bobber and pressing the button in time. That's been done a gajillion times (as one player commented here https://itch.io/jam/monkey-jam-2025/rate/3917761) - so for the post jam version, I decided to remix the fishing minigame with something new - there is now a DDR Arrow minigame added after the fishing portion which makes it a bit more involved.

• Always fix things before moving on - I gave feedback to a few devs, but some didn't respond and just moved on to the next jam. If you don't learn and incorporate anything from user feedback, then you won't grow, and will keep making the same mistakes again. Always make sure to make a post-jam version incorporating any user feedback.

• Our game never had a game over screen, because we didn't have time to program one - hence the game over screen just became a bad ending on a visual novel, which actually turned out to be better than a generic game over screen - that way I could write custom endings for each scenario.

• When Making music , use references for inspiration rather than writing a full song from scratch. The Mudan Dance Theme was a heavily inspired (almost remix) of Gene Yuss' Theme (Links Club Doubles Match) from Mario Golf Advance Tour.

• Learn from other games - Some other games in https://duckindisguise.itch.io/monke-island had really exceptional sound design. it's a subtle thing, but well-chosen or crafted sound effects can really bring your game to life.

• Upload early! so you can playtest how it works in browser. Early testing is crucial to fixing bugs - you'd be surprised on some things that worked in a local development environment but didn't work in browser. For instance, the dust particles that appeared when you collect cinnamorolls wouldn't appear because in the browser, the filename was case sensitive, but in the local environment it wasn't.

• One other web a11y thing I found out is that when using keyboard keys, it's crucial that you use event.preventDefault() for the arrow keys - this makes it so when you move the arrow keys around ,it doesn't move the webpage around.
  

• A Subtle but important thing: the mouse cursor - when interacting with menus or interactive objects I change it from the default pointer to the hand - that way it's more obvious that something is interactive.
  

• Pay attention to filesize: Some people had gargantuan builds (over a Gigabyte, which I can only imagine as folks using the Unreal Engine and compiling a web build using the Emscripten Toolchain, yikes). Thankfully, our build is pretty much using native web code / javascript, so we can keep our performance fast (you should pay attention to framerate as well) and file sizes small, with the final size being a whopping 51 Megabytes.

• Another note on this: Reducing the size of the videos was a huge win: just pay attention to the video length (don't have something super long that plays for 20 seconds if you only need 5) and video resolution (does it need to be 4K?) (in our case, it was speedlines used for the cutscene before the dance battle) cut our total filesize in roughly half (we were at about 98mb for the jam version, but the post jam was 51 Megabytes).

• Difficulty Select - not everyone that plays your game is a hardcore gamer - so having multiple difficulty options for different types of players can be a huge bonus. The original difficulty of the dance minigame is now the hard difficulty in the post jam edition. Also, there was an ability to add extra lives, just in case it was too difficulty, it gave players a way to progress.

• Decide on an art direction and stick to it: For the game jam, the backgrounds were normal art backgrounds with a bit of blur. However, this style kinda clashed with the pixel art done by the artist. For the post jam edition, I added the pixelation filter to the backgrounds, as well as remixed all the songs into a full chiptune soundtrack (only half of it was chiptune during the game jam, the other half was regular music), so it feels much more cohesive and like a retro game cartridge.

• One feature that was added post jam was the banter system (characters interacting and bantering with each other, even dynamically responding to each other when certain phrases were said) - banter helped keep things more lively which playing minigames, a much needed spice, as sometimes playing just minigames without any other interaction can get boring and repetitive.

• Never compromise on Integrity: some people engaged in ratespam (creating fake accounts in order to downvote others), or review-4-review (offering to play others' games, but asking for a review in return). Although in the short term it would seem that they gained, in the long term they would deprive themselves of genuine conversations with authentic feedback and finding genuine product market fit. Honest devs like Team Cherry took the one star hit with their hungry knight game, but incorporated feedback, and were able to make games like hollow knight and silksong.
  

Closing Thoughts

Game development is like being a blacksmith in the forge - you make something, then make small adjustments until your game is complete.

Things don't have to be perfectly adjusted the first time, get something basic working first, then iterate to improve and streamline it as user feedback comes in.

That's all for now. Hope you learned something, and feel free to comment below if you'd like to share your game jam learnings or accessibility learnings as well.