We had our DMA senior show, and I was really gratified that my friends played along and posted itch.io comments to situate the game as being a diminished version of some sort of idealized game from their childhoods.

Whenever I leave behind some code for a while I worry about not being able to make sense of it if I return to it, so I asked Alex for some general tips on cleaning up / refactoring code that was made in a hurry (and this was definitely made in a hurry)

I think refactoring is best done in the context of a specific goal, rather than just for its own sake (Like we did with PathFinderMover). If you’re refactoring for no particular reason, the best case scenario is that your game works basically the same as before, but a lot of the time, you’ll just break things that were basically fine. When you try to add or change something, it becomes really clear where the pain points are. Also, a lot of refactoring ideas you have to actually try before you can know if they are even actually helpful, and so me just telling you things in the vacuum might even be counterproductive.

Here are some general thoughts anyway, that you should take with a grain of salt.

  • It’s an obvious one, but any code that you found yourself copy-pasting or retyping, with minor changes you should try to wrap in shared function/property (like we did GridFunctions, and PathFinderMover) something like groundMap = GameObject.Find("Ground").GetComponent<Tilemap>(); and similar ones suggest that you should have some kind of CombinedTilemaps that holds all the tilemaps, wraps common functions involving them.
  • Try to give prominent functions and variables helpful, accurate names (flipWalkingSprite?)
  • delete any functions or variables you know aren’t being used, or could be equivalently derived from other things you already have. (Find all references is helpful for this)
  • Any place you where you had to do something weird/counter-intuitive or where the code is sensitive are the most important places to add comments
  • make your player use pathfindermover instead of its bespoke code
  • try to separate the block taking/placing code outside of player, so that your NPCs could use it too
  • Try to separate the money and obelisk contract state into a separate script so your soldiers and npcs could have same kind of contract state/finances
  • make as few things public as possible (you can use [SerializeField] to make fields settable in editor, but not available to other scripts).
  • Related to above, you should try to minimize the amount scripts reference each other, and try to make such interactions as abstract/high-level as possible, minimizing accessing specific low level variables and functions.

Obelisk was meant to be as much about everything that surrounds a computer game as the software itself, but I would like to return to the game itself as well as the code that generates the book (I’ll probably continue developing the book first). Some things I’d like to add to the game-

  • More intelligent npc behavior, currently they get stuck or fall off often when trying to collect blocks

  • More developed block economy, interactions when one obelisk territory encroaches on another

  • Some actual functions for the “inexhaustibe treasury” (the really fat obelisk with the big capstone and all the guards). I’d like it to tie in to a total obelisk economy.

  • Basically I’d like the whole thing to function better as a simulation

  • More content, using the balanced system as a guide for placing it

  • Some additional NPC interactions other than showing a single quote. This could be limited fetch quests if they’re clever and not boring. I like the idea of confounding an obvious feeling videogame chore in some way.

  • NPC’s would have a unique identifier tied to their debt. Every individual’s debt is their “name”.

  • A meta game that runs between the book and the game, this is kind of murky, possibly something to explore in another game.