i'm really glad I got this project done. I've been meaning to learn godot for such a long time now, but, yknow, committment issues. anyways, I GOT IT DONE!!

i ran out of time to compose music properly, so instead I sat down at the piano, improvised some space-y lofi sounding stuff, then bitcrushed it to hell and back and called it a day. i like the way it turned out, personally.

i'm looking forward to playing the other entrants' games!!!! :3

I made my game Yelp for the limitations kajam. Despite 6 weeks of jam time, I was still coding in the final hour. 🥲

I'm glad I submitted something, but there's very little actual gameplay and it's not particularly fun either. I focused mainly on the "Over-sensitive" limitation (use as many inputs as possible) and chose to use the microphone to propel the player and trigger attacks, but I quickly ran into technical issues. I couldn't always reliably detect and utilise microphone input (possibly because of noise cancelling and/or a lack of API understanding), so ultimately I restricted it to just attacking. Even then there is a noticeable lag between screaming at the computer and it actually attacking (possibly this could be reduced if I better understood the various HTML/JS audio APIs). Still, I think it's pretty novel for a jam game and I'm glad I tried.

Originally I'd aimed for a horror game, and the game briefly had a shroud around most of the screen. Not being able to see what's coming is a common horror trope and it did improve the feel. But I also wanted to aim for the "Geometron" (no textures; geometry only) limitation, and a decent-looking shroud meant technically using a texture, even if it was auto-generated. It's also a tall order to create a horror game without sounds for atmosphere.

I learned a lot, though. This is the first graphical (i.e. not mostly HTML/UI) game I've made in a while. Turns out Pixi.js is still a solid rendering engine. I was less keen on matter-js for physics, mostly because the docs aren't very helpful and the API isn't always predictable. I'd happily use Pixi again, but would be tempted to seek another physics solution (library or roll my own).

Congratulations to everybody who participated! There are some very interesting games so go ahead and try them.

What's next?

Remember that we have the 20th Alakajam on 13th of September, and another tournament in October. Check the events page for more details.

You can access the games i've created here: https://sunbeam6.itch.io/

I'm going back to my 12yo self's roots and started with the main menu. As one should do!

But I guess this Kajam is a good reason to get started!

Let's see how far I can take this in the remaining time.

Cool kajam! I've picked the following limitations:

Esoteric: My entry targets Windows 3.11. Exactly how I'm going to distribute this in a way that anyone can play it remains to be seen
Illustrator: Hand drawing all the art. I do a fair amount of amateur art for fun, but almost never using physical media. I'm hand pencilling, then inking, and finally scanning all the graphics for my entry. Not being able to repeatedly hit 'undo' each time a line is slightly off has been the biggest challenge in the jam for me
Window dressing: Game windows are part of the gameplay. For one, the game needs 'Windows' 3.1(1) to run, but also involves popping up multiple views, each in its own window. Managing these is part of the gameplay, though not particularly complicated.

Instead of my usual cross-compilation shenanigans I'm making the game from inside a Windows 3.11 virtual machine, hosted on a raspberry pi (my main desktop pc at the moment). The screen redraw in the VM is pretty slow, which means that sometimes moving a window, of which I have many, triggers a ten second or so screen refresh. It's pretty painful but is all part of the fun (I keep telling myself).

I'm using Visual Basic 3.0, which I thought would save me some time being designed primarily for interface design, but having to learn such an old version of Visual Basic might be taking longer than drawing the scribbles illustrations.

Let the limitations begin!

The task: make a game by 9th of June, using one or more of these limitations. Pick as many or as few as you like - if you're feeling brave, you could even take one from each category. They're intended to be flexible, as we have a wonderfully mixed community creating games in lots of different ways.

Good luck, and let us know your limitations!

Demoscene

• Cramped: Executable is at most N bytes/pieces/whatever. Choose N appropriate for your platform/engine.
• Esoteric: Game works on $obscure_platform.
• Art attack: No assets; procgen only.

Graphics

• Geometron: Lines and shapes only: no images.
• Seeing double: Use exactly two sprites.
• Illustrator: Draw all your art by hand.

Audio

• Orator: Make audio only using your mouth.
• Bleep bloop: Music, generated by gameplay.
• In the field: All audio comes from a single field recording.

Wildcard

• Over-sensitive: Must use as many inputs (keys, buttons, devices, whatever) as possible.
• Vestige: The past must leave a trace.
• Window dressing: Game windows are part of the gameplay.

Note: if you need something more specific for the Demoscene limitations, I suggest looking at the Revision PC events.

The 15th Kajam is nearly here!

Get your spellbooks ready folks, because we'll be jamming again in May. The 15th Kajam will run from 3rd May, 20:00 UTC to 9th June. (That's this weekend!)

The theme will be: Limitations.

Back in the day, game creators had to work hard to squeeze the most performance out of their processors and limited hard disks, the best art out of their palettes, and the most fun out of their printers. This is rarely a problem for indies nowadays, but it can still be inspiring to work within limits.

On Friday at 20:00 UTC we'll announce a list of limitations - some like the above, but others, too. When you enter the jam, we want you to choose a set of limitations that inspire you, and then see what you can create over the month.

Rules

• The Kajam rules are very relaxed. The limitations in this jam will be flexible enough to accommodate different styles of gamedev (e.g. using an engine; creating a ZX Spectrum game; inventing a board game). You're also free to change your selected limitations mid-jam - they're here for fun and inspiration, after all.
• We do ask that you refrain from relying on "AI" to make parts of your game, though. We want to see what you can create, not what ChatRPG regurgitates! If you really really must use AI, make it clear you did, and how.