Three Dollar Quill

Well, my save/load module is like 500 lines long, but it's fine. It's fine. It's fine. It's fine. It's fine.

I do actually have some ideas for potentially removing bits of it, but there's also stuff to look into adding. My plan is to get on with part 10 of the tutorial, but I need to take it easy for now, because most of that was today, according to the logs.

I'm trying to figure out what direction I want to take this game after I get through the tutorial. Like, yes, the starting point the tutorial gives me seems fairly standard for traditional roguelikes, but the tcod library doesn't really lock much down in terms of gameplay. I had some ideas for a game I'd like to exist earlier, but I don't know if a sprites-on-grid turn-based game is the proper medium for the concept or not. The basic idea I had is something inspired by the early Fallout games, but the apocalypse it takes place after is Lovecraft-inspired rather than nuclear. There are multiple NPCs that all look suspiciously like Jeffrey Combs. The player is presented with a dialogue option to comment on this, but the requirements for it are impossible to fulfill. I mean, the early Fallout games were very turn- and tile-based, so it's not that I have a specific reason to doubt the idea would work, but more that I don't know if I can execute the general idea with this technology.

Anyway, I'm wiped out from traveling, and writing over 400 lines of code, so I'm just going to scout ahead a bit in the tutorial. I don't actually remember how I wanted to prioritize the various tasks I came up with, but I'm inclined to push through the tutorial until I run across something that looks like it would interfere with them, because I'd like to get out of fitting my priorities around it.

I should probably describe what the heck is in all the serialization code that it's so long. Basically, it currently has 23 pairs of "dumper" and "loader" functions, each associated with a single concrete type in the codebase:

• Seven types of component (ai, collision, display, fighter, inventory, item, position)
• The map
• One of the AI functions
• The ecs "world"
• The game
• The messages and message log
• The six current game states
• Three of the item functions
• 2D coordinate pairs

There are a number of TypedDict classes to define the exact interface expected between loader and dumper. Everything is type-annotated, though some of it needs to be fudged a little. The public interface to the module is two functions that wrap up access to the serialization machinery; they accept and return Game objects, which recursively include everything of interest.

Closing thoughts: I think I'll be able to finish part 10 pretty quickly. Probably the most effort I'll have to put in will be tracking down the code that relies on functions that are or will be deprecated. I've finally got actual test code running against this stuff, though I need to actually write tests of the core game logic; everything I need is there, pretty much, I just haven't put anything together.

Maybe what I ought to do is write code to log all of the events generated by normal play, and write functionality for "replays" with test code. That probably doesn't quite make sense. Oh well, it's late. Good night.