2022 7DRL Postmorteum Postmorteum

I've had a couple days of the day job and refreshed my neurons a bit.  While I suppose every day of the event my blog entry about it was essentially a 7DRL postmorteum, here's one last postmorteum posted a couple days after the jam submission.  If you've ever read a postmorteum on Gamasutra, they basically have three parts: what went right, what went wrong, and a conclusion.

Leerie

What went right:

• Having the entire week off to work on it.  I did have a car repair to worry about that ended up taking a good 6 hour chunk out of that week, and the usual household responsibilities, but that was pretty much it.
• The algorithm managing tiles spawning and despawning when illuminated and no longer being lit.  It went off flawlessly by having a list of instantiated lightsources that had an interface that returned what they lit.  Every turn, I would poll them all and use that data to fill three lists: what's lit this turn, what's newly lit this turn that wasn't last turn, and what's no longer lit this turn that was lit last turn.  From there, it was quite easy to get the necessary work done.
• The decision to have "initialized but undefined tiles."  On a boundless tilemap like I was using, it turned out to be very handy to generate a few tiles that might be potentially used later.  I set them so the field of few mechanic would treat them as unobstructing tiles so the light sources would have full illumination range access to generating that content upon lighting them.  It also neatly nipped in the bud any possibility I might end up trying to set a tile's terrain before I created it.
• Giving up and going with a linear street.  While it was unfortunate I had to give up on the idea of a city street that might weave around unpredictably, I have to say that the game became several times easier to develop once I did.  If I had to do it again, I'd have perfected the game and its mechanics on a linear two-way street first before worrying about them weaving about.

What went wrong:

• Not having a concept ready to go from the start.  It took most of the first day to make up my mind, but it's not against the rules to have come up with it before the start of the event.
• Too much cosmetic concerns.  Most of day one went to preparing Oryx Labs' Classic Roguelike for utilization.  Most of day two went to deciding which of my many purchased tilesets to use.  Day four, I ended up changing my mind again.  While the Kenney 1-Bit tileset was an overall excellent choice, I have to say if I just stuck with the Oryx Labs' Classic Roguelike set I probably would have regained about ten hours of development time.  At the very least, I should have used that for prototyping until the final days.
• Big snag #1: isolating the coordinate determination algorithm.  I had three kinds of coordinates: global coordinates, chunk coordinates, and local coordinates.  It wasn't until day 5 that I figured out my tiles were being placed in the wrong places (especially in the negative coordinates) because my algorithm derived the other two coordinates based on the global coordinates and the 0,0 origin formed a fencepost.  It took me over three hours to figure out.
• Big snag #2: figuring out how to create a city dynamically-derived chunks.  The original intention behind Leerie was that the city streets would go in all directions at random.  Despawning a street and re-illuminating it might generate a street going in a different direction, which fundamentally changes the way the city grows.  By the time I got around to doing this, I was too burned out from other issues to deal with coming up with a good algorithm to do this.  So I had to abandon the idea, and what we ended up with was a far simpler, linear street.
• Too much blogging. While I hope these devblog entries will be useful for future developers to read, spamming away takes time.  I was under the impression that it's less energy-intensive to write up the walls of text than it is to do focused game development work.  That's not completely wrong, but nevertheless this was time I could have been using to try to make Leerie a better game.  I had taken to running my entries through Grammarly to filter my propensity to overly pad my sentences, and this probably tripled the time it would have taken to write them off the cuff.  At worse, blogging kept me up too late, costing me sleep and setting me up for less effective development the following day.
• Not focusing enough on the core gameplay loop.  Classic rookie mistake, yes, but basically everything that went wrong conspired to undermine doing only this in various ways.

Conclusion:

Perhaps one of the best skills that an experienced game designer can have is to recognize what features require the greatest priority of effort.  My dabbling in game development hasn't allowed me to become that experienced yet.  If nothing else, I can say that this was excellent practice in coding camp, I learned a few things I should have learned years ago.  (Including, staggeringly, how to do class type comparisons in C#.)  But, more importantly, I learned a little more about how to manage scope.  What kind of feature can easily become a maintenance nightmare.  That cosmetics can wait.  Granted, I don't know if I'll remember these lessons when I need to, but this game certainly gave me a chance.