Vee's Village, Postmortem(undead?)

I set out to make a very simple design, because I knew I would spend most of my time fighting my own untested technology. The game is fun for what it is: basically a repetitive one-feature game, no depth. It's that time-tested mine-it-then-build-it grind that never fails to addict, and I can see ways of making it really expansive in the future with a more sophisticated villager model, more bespoke structures and planning instead of just placing blocks, and a more elaborate character controller that supports more scenarios(e.g. fly around with your bat wings to collect rare items).

What happened along the way to slow me down?

• I fought against my rendering code since it wasn't quite at the point where it supported indexed color with colorkey transparency, and implementing that revealed what turned out to be a bug in my shaders(did not support vertex color, hence I could draw colored sprites, but couldn't tint text and shapes properly until it was fixed)
• My Javascript implementation was barebones, hence lacking in useful errors and stack traces, which wasted time as I got deeper into the game implementation. There were a lot of things that were reported as "index out of range", when it was actually me supplying the wrong number of arguments: I would have shaved off an hour or so of debug if I had added lines in the API to ensure the number of arguments was correct.
• The Javascript engine I'm using, Otto, is also about as sluggish as they come, so it doesn't scale up well to really any quantity of villagers, and would make achieving 60hz in most games an exercise in tedious manual optimizations(inlining, reducing allocations, etc.) - not something I want to encourage. Fortunately there are other options out there for Go, such as goja, duktape, or even the mighty V8 engine. Otto was a good first pick to get started - I'll have to spend a little while evaluating the alternatives.
• I spent an awful long time working out the math to scale Vee while keeping her feet pinned to the correct position, and I probably should put together some convenience libraries to deal with this kind of stuff because everyone hates dealing with low-level APIs for rotation and scaling anyway.
• I didn't really get around to doing as much with the sound code as I wanted, though technically I still have time before the jam ends. It can trigger a mean square wave, and that's about it. The synthesizer is one of the most specialized, design-intensive parts of a fantasy console which also means that it tends to be overlooked. I have plans, though, big plans.

For the most part, coding a fantasy console isn't too far removed from coding any other game engine, the difference is that because you start with limitations in mind, you can make a decision on the fly about whether or not the limitation is worth it, and if you want to discourage over-engineering during the game development process, you can also force your preferred simple API or convenience function to be the "fast path", "most scalable", or "zero cost" when in the Real World the trade-offs could be infinitely more complex. I am thinking that I might allow 64 and 256 color modes as well as 4 and 16...not because I really want to work with higher end modes myself, but because it's very elegant to do that in the shader code, and I can find other ways to discourage people from rushing to max out the specs.