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.

Looking forward to another Kajam, thought I'd sign up a little early and make sure it's in my calendar. Bummed I was unable to join the most recent alakajam, so now I have to wait in jam-jail until May.

Hopefully the theme will be something retro-friendly, I haven't done any 'modern' gamedev in a few months now - old consoles and computers are better (and people will say 'wow this runs on DOS? so cool!' and ignore the fact that the game is awful).

Also I'm hoping we maintain a no-AI or 'all AI content must be declared so voxel can downvote it' stance on jam submissions. I'm only interested in playing things made by the alakajam community, not content fever-dreamed by water and energy guzzling ML platforms trained on stolen content, thanks!

The 13th Kajam coincides nicely with the Dos Games June 2023 Jam, so maybe I'll make a DOS based entry. This might make any kind of networked realtime multiplayer quite complicated to implement, unless the game is hosted on a BBS or something. Maybe I'll create a 'play by mail' game where each player takes their turn and then emails the save to the next? Interested to hear what everyone else's ideas and plans are

I've been a bit disengaged from AKJ but I'm looking forward to participating in AKJ17, which will finally be the jam where GIANT ROBOTS is chosen as the theme

Lately I've been dabbling in NES assembly programming, so that's probably what I'll use. I've done a (not great) NES entry using C before, but I've honed my 6502 assembly in onehourgamejam to the point where I can definitely cause some trouble in a jam timeframe.

I'm starting an hour early because I'm a dirty cheater. Current plan is to do a Game Boy entry…

For the last few days I've been putting together a little cross platform game engine. It's not at all ready for use but a good JAM will make the problems with it pretty obvious real fast, so that's my plan for the weekend - write game in unfinished engine.

Also if the theme is boring I will make a GIANT ROBOTS game regardless, thanks.

My current plan is to use the haxe programming language to create my kajam entry. In theory I can write a single codebase that can be compiled down to a headless (no graphics) server to run in the cloud, while having that same code be able to produce the playable version of the game. In order to get multiplayer support in the browser, I'll also be using websockets.

But more importantly I want to be able to quickly iterate on my entry during my free time, so I've set out to automate as much of the build and deployment workflow as possible. Nothing fancy, just a makefile that builds the server, deploys it to the remote server and launches it. I can then launch the client on my local machine and see messages passing between the server and client, which seems like a pretty important precursor to a remote multiplayer game. Testing with a local server on your development machine is OK but bypasses a lot of the issues that can occur with a 'real' server out on the interweb.

The test was successful but revealed that terminating the server on the remote server left a zombie process sitting on port 8000, which means that attempting to run the server again would fail as the port was unavailable. This behaviour didn't occur when hosting the server locally, so there's some instant proof that it's worth testing on as realistic a setup as possible. Hooray.

Checking out the prison cells

Meeting a doggo in a tunnel

Might have made a mess here

Meeting the staff and students in the re-education centre

A very blocky train at the yard

Added directional sprite support to my raycaster today, so now you can see FRIENDLY WORLD INHABITANTS from multiple directions