For this event, your challenge is to make a "microgame". Microgame is a term used by the WarioWare game series to describe short, (mostly) self-contained minigames played in rapid succession. The individual microgames tend to present a single gameplay mechanic or task for the player to perform, with a well-defined success and failure state. Typical microgames are only a few seconds long, while some end-of-stage "boss games" can last a minute or more. In WarioWare, the player is presented with a series of microgames to play in a random order. Failing at an individual microgame costs the player a life, and losing all lives means game over!
For an example of this type of gameplay, here is a nice demonstration video.
Your mission in this game jam is to make a microgame! At the end, we'll collect all the submissions together, so you can play through the whole collection like you would a stage in WarioWare. In order for this to work nicely, it's best if everyone follows some simple guidelines. These mostly aren't hard-and-fast rules, but moreso a framework to ensure that the overall collection is playable.
The browser is how we're going to ensure all of the games can play nicely together. This doesn't mean you have to write a game with JavaScript!
Many languages and libraries can be built to WebAssembly. For example, if you like C and raylib, check out this guide! It's also quite easy to write Rust programs targeting WebAssembly. In general, if you have a preferred language and graphics library, it's likely you'll be able to make something work!
Full-fledged game engines like Godot also have the ability to export a web build. For Godot, see the documentation.
It's also perfectly fine to work with JavaScript and Canvas, either using some library or plain browser APIs! If you'd like to go this route and aren't sure where to start, check out the MDN documentation for the Canvas API or maybe WebGL. If you'd like something a bit more batteries-included, maybe check out Pixi or Phaser.
We want to make sure that someone playing the collection doesn't get confused by the controls. With keyboard controls, each game might pick totally different keys, and adjusting the player will be a challenge. As such, please center your game's control scheme around a standard two-button mouse. You're still welcome to use the keyboard and any other input method that's generally available, but try to avoid assuming that the player will know the control scheme you require. For example, a keyboard-involved microgame might involving mashing keys indiscriminately, or playing a "hot-and-cold" game based on the physical locations of keys pressed in the player's keyboard layout. Get creative!
Ideally your game is tightly focused on a single gameplay idea. Feel free to interpret this however you wish! If you want to make a two minute mini-RPG, be my guest! Rough and interesting is a good way to go.
We need a way to know if the player should lose a life after your game runs. The player running out of time is a perfectly good lose condition (but make sure to display a timer somewhere onscreen if this is the case!). But again, feel free to be inventive!
When you submit your game, ideally you should submit an archive (ZIP or tarball) containing a folder. That folder should contain all of your game's assets, alongside an index.html that runs the game. Most game engine web exports will give you exactly this!
Your game should be scaled to fill the entire browser window. We recommend that games render at 240x160, but this is not a hard requirement. Feel free to break/bend this rule if you like!
In order for things to work smoothly, you'll need your game to report when certain things have happened, and also to respond to certain requests. Don't worry! This is simple and easy, and we have some examples available using common tools.
Your game can communicate with the "harness" by calling the JavaScript function window.parent.postMessage. The harness will send some messages back to your game in the same way (and you can listen for them with window.addEventListener("message", your_message_handler_here)). If that's inconvenient, we also set certain special JavaScript variables whenever events fire, so you can poll those variables inside your game loop if it's easier.
Here's what you need to send and receive from the harness:
When your game's page loads, you should load all assets and send a ready message to the harness:
window.parent.postMessage({op: "ready"});
After sending this message, wait patiently! The game has not started yet, so you shouldn't start any timers or expect the player to input anything just yet.
The harness will tell you that the game should start, and at which difficulty level.
You can detect this by either listening for an event, or reading a variable:
or:
window.addEventListener("message", ev => console.log(ev.data));
// ev.data will be {op: "start", difficulty: 42.0}
This means that your game should start right away - you can start any timers and expect player input! You are free to interpret the difficulty number any way you like - this number will be roughly the number of previously-completed games so far in the current round.
window.lcolonqJamStart
// this variable will either be an integer or falsy!
// you can check it repeatedly in your game loop until
// it's an integer - that integer is the difficulty level
When your game starts (in response to the previous message), you should let the harness know it started successfully:
The
window.parent.postMessage({op: "started", verb: "catch!"});
verb field tells the harness to display a particular word as a prompt to the player as your game appears.
You are free to run your game! When the game is done, report whether the user won or lost:
or
window.parent.postMessage({op: "done", win: true});
At this point, the user will no longer be able to interact with your game. You should reset things, and be ready to run the game again fresh when you receive the start message. In general, you should assume that your game page could be reloaded entirely, or it could never be reloaded and receive repeated start events!
window.parent.postMessage({op: "done", win: false});
That's it!
Alongside your game, please submit source code (either a link to a repository or actual source in an archive file). Please include the open-source license you are releasing your code under, as well as any licenses and attribution for any assets used.
Please do not use any "trained" machine learning tool with external training data for programming or asset creation. That is: no off-the-shelf LLMs, image generation, etc. anywhere in the development process or final game. Feel free to use machine learning techniques at your leisure if you're using a model you trained entirely yourself on data you have collected yourself (and to which you have a license).
In brief: Claude code/ChatGPT/AI images are banned. If you'd like to write some weird genetic algorithm thing or do reinforcement learning for game AI or procedural textures or whatever else, that's cool and please do it!