From 188643eccb13452f0e77ccea2a6e1baf6d5320b3 Mon Sep 17 00:00:00 2001 From: LLLL Colonq Date: Tue, 26 May 2026 03:55:41 -0400 Subject: Big refactor, jam --- templates/api/jam2026.html | 121 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 templates/api/jam2026.html (limited to 'templates/api/jam2026.html') diff --git a/templates/api/jam2026.html b/templates/api/jam2026.html new file mode 100644 index 0000000..78ae617 --- /dev/null +++ b/templates/api/jam2026.html @@ -0,0 +1,121 @@ + + + + + + LCOLONQ MICROJAM 2K26-A-PALOOZA + + + + + +

LCOLONQ MICROJAM 2K26-A-PALOOZA

+
+ +

THE DETAILS

+
or, what are we making, actually
+
+

+ 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. +

+
    +
  1. +

    Make a game that's playable in the browser.

    +

    + 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. +

    +
  2. +
  3. +

    Games should be primarily controlled using the mouse.

    +

    + 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! +

    +
  4. +
  5. +

    Keep it short and focused! Less than a minute is ideal.

    +

    + 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. +

    +
  6. +
  7. +

    Make sure there is an obvious win condition and lose condition.

    +

    + 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! +

    +
  8. +
+
+

THE RULES

+
ok these are actual rules don't bend these ones please
+
+
    +
  • +

    + 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 your 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! +

    +
  • +
  • Be kind.
  • +
+
+ +
+ + + -- cgit v1.2.3