It is the last day of the Jam, and the game is as done as it is gonna be.

The last bits of functionality were combat and health restore.

Because of lazy art, I only had a skin icon for the loot drops from enemies.

So you eat snake skins and badger skins.

I suppose that is suitably monsterous.

During the implementation of combat, this game turned a corner into something actually somewhat and compelling if simple.

There is an energy cost for attacking an enemy.

How does this change everything?

The only way to regain energy is to walk around in yer lair.

And moving around costs satiety.

So, moving around yer lair converts hunger into energy.

And you also require a small amount of energy to pick mushrooms.

And that makes it a resource management triangle between health, which is restored by eating the FLESH OF YER ENEMIES, hunger (only satified by MUSHROOMS) and energy, only increased when you are safe in yer lair.

Up until the moment that this was true, this game was just a starvation simulator.

So what did I learn/relearn/confirm?

1. One, bleeding enums are bad, and just use strings when you find one.
   1. Examples of bleeding enums: Item Type, Character Type, Map Type. Any enum that is going to infinitely expand while you make yer game. Traditional enums are bad for this, but do put const strings in a module/static class to allow for an identifier for them.
2. Two, not all enums are bleeding.
   1. In this case, there are only so many colors. It will not expand. A regular enum is fine.
   2. So, when unsure about whether or not an enum is bleeding, what assumption should we make? This, I don't have an answer to, but I have identified several cases where I know for certain that the enum will bleed.
3. Modern screens have an aspect ratio of 16:9, so while its find to have a goal of making a retro looking game with the CGA aspect ration of 8:5, just approximate the resolution in a 16:9 equivalent
   1. ancient CGA resolution was 320x200 (8:5 AR). The monitor I develop on is 1080p (16:9 AR). So I made the virtual screen 320x180. Yes, this eliminates 20 rows of pixels, and thus 320 x 20 = 6400 pixels, which in the lower resolution can be critical for delivering information. In this game, the UI was streamlined and simple, so it worked out.
4. Limiting yerself to four colors sucks.
   1. I picked 4 color CGA. When you pick four colors, you've really picked 3 colors and a background. The CGA colors were Cyan, Magenta, and White, with Black for the background. Very quickly the items and characters would look very same-y, especially when all icons/sprites are monochrome and 12x12.
   2. I expanded to 16 colors and I like the freedom that it gives me. I also did not use the 16 color DOS palette, and instead found the "optimal" Wad's Palette.
5. Key delay and key repeat should operate as most player expect.
   1. I have now officially abandoned the "tap the key/button" way of controlling the character. I got to go on an archaeology expedition to relearn the ancient BIOS interrupt that was introduced with AT style keyboard.
6. In past projects, usually structured in a very similar manner to this one, I had a less than perfect understanding of my "layers" and they were named poorly as a result
   1. Here's the list of layers that exist in YTM: Application, Presentation, UI, Initializer, Business, and Data.
   2. The Application layer is correctly named. It is abstracted from the game's display and input with things like DisplayBuffers(Of Hue) and the Command enum (which is NOT a bleeding enum)
   3. The Presentation layer is correctly named. It wraps up the MonoGame stuff, and provides places for the Application Layer to plug stuff into it.
   4. The UI layer needs some thought to the name. It how the Application layer makes use of the Presentation layer, so is effectively the abstraction layer for presenting.
   5. The Initializer layer is absolutely incorrectly named. It is the ACTUAL business layer/domain layer for the game.
   6. The tragically named Business layer is really the persistence layer. It operated mostly like an ORM for the data store.
   7. The Data layer is correctly named. It represents the schema/data store perfectly. In previous games I had used SQLite as the data store. Now I use POCOs and serialize them to json.
7. More of the stuff that I think of as the game can instead be made into a boilerplate.
   1. I always have a title screen, a main menu, an options screen, a way of changing the window size, a way of changing volume, an about screen, a "are you sure you wanna quit" screen, as well as loading a game.
   2. Within a game, there is always a game menu, with the "continue", "abandon", "save", "options" functions in it.

Next Steps

1. Expand the boilerplate
2. Be mindful of how bleedy an enum is likely to be
3. Better layer names
4. More mainstream choices in how controls work and window sizes
5. Sticking with 16 colors, and prolly the palette I used this time

And that's it.

Git off my lawn.