In retrospect:

Balancing the game was the hardest part, and the pacing isn't very good.

That's probably because I used too many unconventional mechanics, some worked better than others.

I planned things at the beginning, but it wasn't enough and I should have refactored my code so it's not 3000+2000 lines.

I should have used classes and the observer pattern.

I should have put most of the data in a spreadsheet and exported it rather than editing JSON directly.

It was a good idea to take heavy inspiration from (copy) the Kittens Game UI since I wouldn't be able to make anything better.

Saving by serialising one entire state object (and storing anything that shouldn't be saved separately) was a good idea.

The scope of the project was reasonable, maybe a bit too large.

The objective of telling a story was achieved, but it doesn't work as well as an idle game.

Drawing was fun, but I have no talent for it and it's time consuming, so probably not worthwhile.

Using a kanban board helped immensely with development, but it's not so useful when planning ideas and I'll stick to regular notes for that.

It felt worthwhile to finish the project, but I started to hate what I made after showing it to others even though I only got constructive feedback. Therefore it was wise not to show work in progress.

There's a bug I can't reproduce so I can't fix it. Some people found that they got too many extra resources when loading a recent save.

An idle game.

Haven't seen this one before, it got me.

@property seems really cool too allowing you to animate colours, if I could get it to work...

#228 - color-mix and backdrop-filter are too good to overlook...

But Firefox's position is truly dire as of late (and I stopped using it).

Wikimedia corruption is more benign than Mozilla corruption because the latter have to actually do something.

I don't feel optimistic about what happens to all these forks if Firefox dies.

Let's cope about Ladybird.

I think social media bridges (like between IRC and Discord) can defeat network effects, which is why web scraping and public APIs are so important.

I thought of another idea, to introduce enemy units so it gains a similarity to chess endgames but it would be a lot of work.

Actually, the thing that stops me from leaping to implement this is not the amount of work but a few small problems which I can't decide how to resolve.

1) If the enemies move in a phase after the player's move, then the player's apparent visual move speed is halved, which could feel very unpleasant, but maybe it's okay because those levels will be considered 'unsolved'?

If the enemies move simultaneously in time with the player, then collisions become visually confusing because there are two kinds of collisions now, starting from adjacent and from a 1-tile gap.

2) Worse, while the AI movement could easily be designed in a deterministic way, it's very difficult to communicate to the player which direction gets priority in diagonal cases where both moves seem equivalent.

I don't think the player is likely to internally model a fixed move order priority, and even if that information was displayed visually, I would not feel good about using it to solve a puzzle.

Additionally, if I made the AI favour minimising Euclidian distance from its target, it would mean the AI is no longer consistent with the player's click to move pathfinding unless I recalculate the path whenever the player clicks to queue moves. That might be an option but it's inconvenient.

3) I want to show the reachability of units by hovering them, but I don't know how to display this visually.

If it overrides the default active player's reachability saturation, then it's going to be confusing and make you think you controlled that character, as well as worsening experience in the valid and common use case where you click a unit intending to path to and pair up with it.

After writing this out I had the idea for 2) to show an arrow for the AI's projected move when you hover the map with the mouse, as well as the player's projected move.

But it would only be for the next turn, not all moves in the sequence to reach the hovered tile, because the predictions would become inaccurate.

Even though keyboard moving is also allowed, the player can choose to use mouse movement in situations where precisely predicting the movement of an enemy is important.

It's not ideal though because the player should be required to calculate in their head and predict exactly what will occur, a vague uncertainty requiring testing isn't good.

Maybe I need to make an effort to teach them priority through level design? But most players would guess or brute force it because there's only 2 possibilities.

Since I optimised the pathfinding algorithm, I should be able to run it multiple times in one frame.

This will take a lot of refactoring, I'll give it a rest for now.

I still didn't solve 1) or 3).

Saving/loading turned out to be negligible, possibly because I used a binary format instead of JSON.

The slowest part right now is actually generating the minimap level thumbnails, it only does this once and it doesn't cause any lag, in the future if I can be bothered I'll use a script to generate these as image files.

Most games have multiple save slots, I guess it's useful so multiple people can play on the same computer, but is it really that important?

It's not very immersive, and it's the very first thing you see when you start up the game.

I'd rather be immediately transported to the game world with some sort of animation.

I should post more screenshots of the game since it's been a very long time since I last did so.

A true puzzle game shouldn't have to worry about save versioning issues because I don't expect to be updating the levels.

Thus I am not going to bother manually assigning a unique ID to every unit and just use an incrementing ID.

For the sake of testing during development if the total number of units changes then I'll wipe the save file.

I think I'll autosave whenever the player changes areas.

I should be able to do this asynchronously and even let the player continue moving while the file is being written, it should be very fast because there isn't much data to save.

In the case where a player repeatedly switches areas possibly causing file lock issues I will just ignore the later saves because it doesn't matter anyway.

I have to be sure the player is never able to change areas after "getting stuck" to avoid softlocks, this may constrain level design slightly but I'm willing to make that sacrifice.

If I don't serialize and save the entire undo stack then the player can potentially softlock themselves.

I think I need to clear the undo stack in a new level or something rather than having the game be technically open world, but it's inelegant and makes one of the intended mechanics troublesome.