I do wish I knew more about AGS's 16- and 8-bit modes.

Being able to do more with custom palettes than just a simple screen tint would be incredible... buuuuut probably not viable given all the modules I'm using.

By the way, the runes seen throughout the game are a font I made for the project, as part of a cut puzzle where you'd have to translate something without magic. Postjam, maybe.

(Also the sigils are loosely based on Neopets tropical fruits bc I have one personality trait.)

The dungeon runs on a grid, allowing doors to link up automatically/teleportation to lead you to the right place.

If you're going North your destination is player.Room+10, South is player.Room-10, etc etc.

The original map was HUGE, so it was important to automate as much as possible!

The game can also add or remove tags on the fly (such as "toggled" for switches, "locked" for doors, etc).

This doesn't get used as much as I'd like it to, but opens up a lot of possibilities for future builds and also felt clever doing it.

Most things have a 'Tags' String property, allowing me to quickly classify Objects and InventoryItems without the need for tons of variables and checks.

eg: the Knife is tagged as 'thin'. This lets it pass through barred passageways and cracks, whereas the big Godere boulder would not.

If yes, it gets temporarily added to cContainer's inventory, which is shown on the Floor Inventory screen.

Since all instances of an InventoryItem share the same properties, it means DUNGEON will forget where any duplicates are and fail to spawn them. But for a gamejam, it works.

When the player picks an item up, 'Room' changes to -1 to indicate it's being carried. When they drop it, 'Room' is set to the player's current room.

Then, whenever the player enters a room, AGS checks the InventoryItem array to see if any items have a 'Room' ID that matches the player's location.

The inventory system is rejiggered from a previous prototype called Budget Cuts. Rooms can't have inventories of their own; in AGS, that behaviour is exclusive to Characters.

So, DUNGEON instead gives each InventoryItem a Room property.

If you're wondering why the closeup art looks crunchy, it's because I tried to stay off my tablet as much as possible during this jam.

If it was too hard to draw with a mouse it was drawn on paper, scanned, and then converted to 1-bit using PhotoShop (+ the "use custom dither pattern" setting).

OMYD was designed with the Panorama module in mind, but it was taking too long to implement. So instead, each room is on a 3x4 grid and a viewport crops the BG so you only see one bit at a time.

This approach plays nicer with HTML5, ScummVM, etc so I'll be keeping it as a setting in future builds.

I had to apologise to my playtester like seventeen times. And even now I don't think that's enough.

With his help I think I've gotten it up to MOSTLY intentional frustration rather than unintentional, but either way, *good luck I am very sorry.*

Unfortunately I had to cut the fancy camera movement because the module wasn't playing nice/I didn't have time to figure out why. Also most of the story beats are just. missing. Ah well. I'll come back to it. Maybe.

Regardless, a good learning experience. Workin' on a thread of technical notes. 👍

quick let me counterbalance the shock with the art for the actually important rooms

(And yes, the game over screen is currently a 1:1 of ZGI's. If you think I can't make this project even more shamelessly self-indulgent, you are dead wrong.)

I obviously haven't started on the art for the game, hence the amount of recycled assets. Cool Ranch does not have magical secrets inscribed on his beak. Probably.

The room inventory code is repurposed from the Budget Cuts prototype and is a lil shoddy, but works as a proof of concept.