It's been a long time but I kinda want to make something. This time it'll be for Windows 3.1. A 32-bit Windows port can come post-jam. Note that I've started late and have quite a few things to do today so I'll need to put something together quickly.

My tools:

• Language: Pascal
• Emulator: 86Box
  • Development set: 100 MHz 486DX4, 32 MB RAM
  • Stress-testing set: 16 MHz 386SX, 4 MB RAM
• OS: Windows 3.1 on MS-DOS 6.20
• Compiler: Borland Pascal 7
• Text editor: Borland Pascal 7
• Image editor: The resource editor that comes with BP7
• Actually transferring the game to the host system so I can upload it: Floppy disk image + mtools

I'll probably port it all to FreePascal after the time is over. It seems the mingw-w64-fpc package in the AUR works at least for a basic MessageBox-fuelled Hello World program.

I'm aiming to do something more like a puzzle game. Should work mouse-only and keyboard-only. Will probably make heavy use of GDI for drawing shapes and stuff, I don't want to waste too much time on art.

There might be some beeps at different frequencies for sound but that's probably going to be all on that front.

And yes, this will be a very Windows-y game. There aren't many of those made these days.

A Linux port might come later but don't hold your breath. I will avoid the use of widgets here which should help with not needing to rewrite too much of the code, but there will still be a decent chunk of changing Win32 API calls to Xlib API calls.

Git will really only be used once I start porting stuff.

And a proper mockup with some basic code to go with it. No input code yet other than the fact that the "Game" menu has an "Exit" item which tells the window to close as if someone double-clicked on the top-left menu or Alt+F4'd.

Anyway, there will be pressure plates which hold doors open and closed. Probably going to have some specific to a given creature type. Ironically, I went with a really uninspired puzzle game idea ("stuff it, let's just do a lock-and-key puzzle") and then realised that it was going to be a little different.

I decided to use 16x16 tiles, then picked a 32x24 grid for levels for 2 reasons: - It fits nicely in a 640x480 display with suitable padding for the window border. - If one uses 8x8 tiles, then it also fits nicely in a 320x200 display for a potential DOS port.

And no, the art style isn't a placeholder, although I might put some colour into the creatures. ... also I just quickly did a test with an emulated 16 MHz 386DX and it's looking like I might need to pre-render some images. Or maybe not panic over it and instead ensure I work enough magic with dirty rectangles to make it perform. I'm not too fond of going with pixel art for this as I do need the window to be resizeable in the Win32 port after publication.

And as an added bonus, it seems I'm getting weird hangs in 386 Enhanced Mode now. Not sure what happened, doesn't appear to be my code. Oh well, at least Standard Mode works properly.

It's amazing what happens once you've got enough of a codebase together. The pretty picture doesn't do it justice.

Anyway, features so far: - You can select and move creatures around with keyboard and/or mouse - Complete with flood-fill path detection! - You can toggle in and out of edit mode to edit the board (mouse only)

Stuff to implement next: - Actual level win condition - Loading and saving of levels - Switching between multiple levels - Editing of creature positions + counts + types - This is begging for a right-click popup menu. - Reload the level when switching to edit mode

And then: - Add buttons - Add normally-open/normally-closed doors - Implement the puzzles I have on paper (3 so far) - Add help info - Come up with more puzzles

So yeah, level file support.

EDIT: Oh right, forgot to mention, apparently I have 647 lines of code now.

Usually I end up hanging or crashing Windows 3.1 earlier when I'm making something, but this time it hung while working on the file loading and saving code. After rebooting the VM I've found that after doing the weird song-and-dance I did to prevent losing all my work on my levels in the future, it probably managed to save something almost correctly - I think I was one byte off.

Here's hoping there's no more system hangs! At least this isn't like the last game jam I was in where I was doing something on a real DOS machine and had to hard-reset a few times while writing the keyboard interrupt handler... but so far I haven't managed to hang it due to forgetting to do the GetMessage/TranslateMessage/DispatchMessage loop where needed.

Also, I'll be doing this as an Extra entry now.

There's even a win condition! But right now the game's pretty boring and not resembling the "thinly-disguised lock-and-key puzzle variant" idea I was going for.

And yes, every level is currently called "Untitled". I have a dialog box in the resource for renaming levels but that'll have to wait.

Which now leaves me with these bullet points in yesterday's blog post:

• Add buttons
• Add normally-open/normally-closed doors
• Implement the puzzles I have on paper (3 so far)
• Come up with more puzzles

I'm at 1955 lines of code now. This'll probably go past 2000 lines, but I mostly just need to draw stuff and add more logic.

The file-like I/O abstraction I've done will probably be reused for next jam. (Me reusing my code for a Ludum Dare, that'll be a first!)

Also, the levelset handling is, uhh... suspiciously similar to how ZZT does it. Except ZZT dumps stuff into a 20,000 byte buffer and then copies that into a newly-allocated block of memory. But the basic principle of "every level is a packed block shoved into memory and unpacked on demand, and the file is mostly a bunch of length-prefixed blocks containing said level data" is the same.

Speaking of design influences, the level editor pops open a tool window to the side of the window... kinda like how Kye's level editor does it. Except this level editor allows you to edit a full level set instead of a single-board level set. Of course this totally wasn't an influence on the fact that the default level set is called "default.lvl"...

Anyway, this has been a lot of fun and I want to get this finished, and next time I'll be using the same toolchain. I'll probably get some more editor stuff together for some base code though.

Now it's time to make levels! (I have 2 so far.)

And yes I did have to prevent a bug where sitting on a button being used to hold open a door could result in one jumping past the end of the door.

There are a few things still missing but they can be done later:

• You cannot delete levels from a level set yet.
• Multiple level sets are not supported. This is a matter of implementing the Windows 3.1 file open/save-as dialog boxes.

But anyway, time to actually make the levels!