Senbir: Post-Mortem-ish thingy

I often have terribly ambitious ideas for Ludum Dare, and LD42 was no different - a game about writing assembly code for an actual virtual machine. But I think it went fairly good.

The game itself shipped fine - pushed it out the door just as submission hour started, with a fully functional set of tutorial/starting levels to unlock extended & custom modes, and minimal bugs within said campaign. The problem came when I realized how many op-codes had errors, and how many documented and mostly-finished features slipped past the radar, as is the tradition of making a game in 48 hours.

I spent most of the next week fixing semi-game-breaking bugs (if you consider "nonfunctional opcodes in a programming game" to be game-breaking, anyway) and waiting for my internet to come back after it got blown out by a storm. That wasn't fun. Still, by the next week, a lot more of Senbir was functional, and I was able to do some neat stuff.

Like a paint program.

As cool as it is to be able to write my own programs in it (and as amazing as it is to see other people sharing their own programs), the one area where Senbir is really lacking is in gamey elements, and it's something I do regret (even if there's genuinely NO WAY I could've feasibly done that in time for Ludum Dare) - sandboxes aren't for everyone, and sometimes it's hard to find inspiration.

One of the other areas where it really suffered is in the documentation - a lot of things that just made perfect sense in my head, as a C# programmer, threw actual Assembly vets for a major loop. The tutorials/starting levels could've used a lot of work, too.

This sorta comes back to a recurring theme I've noticed with my Ludum Dare entries: I can get most of the main mechanics implemented without a hitch, but the UX is always hampered by a lack of explanation. Started in LD32, I believe it was, with the Adventures of Cactusman - I watched the Button Masher Bros play it on livestream, and a lot of the game mechanics weren't immediately obvious to them. Happened again with Shift, then with CRTs are Ancient, right?, then The Fallen, and then finally with Dreadnot. Pretty much every game I make where the mechanics & controls aren't immediately obvious (Hazard Hills & Hugely Unpopular President Simulator both escape this effect by nature of being very simple to play) suffers from this problem.

That said, I'm still super happy with the end-result, and plan to keep working on expanding both the game itself, and the capabilities of the TC-06, be it with more op-codes, a simple IDE to aid in writing more advanced programs, or maybe even some kind of cross-compiler tool one day down the line that could create TC-06 assembly from C/C++ code. At some point, I also want to do a proper implementation of the TC-06 in C++ (probably in library form, so it's possible to upgrade the version in-game to support MUCH higher clock-speeds), as well as a standalone program that uses it.