I’m both proud of, and really disappointed with my entry, “CRTs are Ancient, right?“.  Gameplay-wise, I think it’s probably the most polished, and with the most potential for continuation.  Content-wise, I’m really disappointed.  There’s a lot I wanted to do, and a lot of potential, but I was too focused on all the mechanics to be able to get any of it implemented.

All of my other entries usually take at least 10-15 minutes to play through and get a good idea of, whereas this can probably be done in five or less.  There’s one proper level in the game.  One.  That’s the shortest of any Ludum Dare entry I’ve ever made.  Considering how much effort I put into making the mechanics, I’m really sad there’s only one puzzle to use them with.

I think the biggest mistake was trying to make so many features; it’s a stealth game, a hacking game, and a first-person shooter all rolled into one.  You use the computer terminals to achieve your objectives, doing things like printing important documents, toggling lights, or working with elevators.  You can hide in the shadows and move swiftly, like a ninja, and never have to kill a single guard.  You can rambo through and shoot all who stand to oppose you.  All these mechanics are pretty decently polished, but I spent so long making them all that there wasn’t any time left to build a game around them.

Level creation for puzzley games is always a pain, there’s no denying that.  I was lucky to get four made for Shift back in LD35, and it was a real struggle to get them all working; and the number of mechanics to juggle was *way* smaller.  I wanted this to have lots of interesting puzzles built around timing, working with lights, shadows, etc; true light-n-dark stealth is hard to come by these days.  I wanted the computers to feel like an important part of the game; out of everything, they’re still the most clearly ancient.  But instead, they’re more of these simplistic things that you type away at for a couple of seconds, do whatever it is you need to do on them, and then go back to running/gunning/doing whatever it is you do.

I had these grand dreams of putting some social commentary on them; if you stopped and used “viewData” on some, you’d get these little insights in SCI-style files, where someone at the coropration (aka: me) would have written some info on something or another.  An entry on Tulpas, or psychology, social studies, even OS security holes.  Social commentary and story building.  It was going to be awesome.  But when it came time to write them, I realized there wasn’t any time to spend sitting around writing walls of text; not many people would end up reading them, and I needed to focus on level-design or gameplay mechanics.

In the end, I’m happy-ish with what’s out, but disappointed by all the lost potential.  Now, if you’ll excuse me, I’m going to go relax in No Man’s sky for a few hours before going back to playing and rating some of your games.

Tags: post-mortem

I’d like to participate in LD38, but it’s possible I won’t be doing so.  I would’ve been in #37, but between an incredibly severe lack of inspiration for the theme, and a lack of energy to code, I wound up abandoning the idea.  These same issues could knock me out of 38.  Let’s pick a fun theme for this one, like Unconventional Weapon (LD32) or the likes.

If I do participate, it’ll be with the same team (or, more specifically, lack there-of, most of my Ludum Dare friends have been busy lately) as LD35 and 36.  Similarly, I’ll also be using Unity for the engine, Blender for 3d work, GIMP for texturing, Audacity for normal audio work, and Caustic 3 comboed with Ableton Live for music.

I'll be joining LD38 (EDIT: Was LD36 because brain says "SCREW YOU"), possibly with one other guy, and this time, I'm aiming to do the Compo over the jam. I've got simple-ish game ideas for all the possible themes, and I should be able to develop them quickly enough that they could actually be made in time for compo submission.

I'll be using Unity 5, GIMP for textures, Audacity for raw audio work, Caustic 3 and Ableton Live for music, and the code will be put on GitHub.

I made a Goat-Sim style "smash-em-up" that also is political satire, to some extent.

You are a hugely unpopular president. You are also a giant for some reason. Stomp around and destroy the city. But watch out; there are giant protesters with witty signs that will offend your ego.

I very nearly didn't end up finishing this time; I suffered from lack of inspiration when trying to come up with a game idea, lack of inspiration to develop, and a general feeling like "I'm going to regret this really badly" because people are going to get offended by it.

The game's still sorta unfinished, there's no main menu, minimal sound effects (Beyond ability quotes, of course), and there's a lot of unfinished GUI elements and such. I'll make an update in a few days when I'm not quite as drained, that should add some polish and stuff.

Hugely Unpopular President Simulator was not one of my better Ludum Dare entries. I didn't decide on the idea until ~16 hours after the theme was announced, and it was only because I absolutely could not think of anything better. (Thought 1: I would have done well to surrender when I realized I wasn't going to get anything finished with as uninspiring a theme as this one.)

I spent most of the first day procrastinating and playing other games because I had no further game ideas beyond the vague "you're a giant Trump stomping around and wrecking the city for points ah-la Goat Simulator" and thusly just wanted to sit and think. At the end of the day, I went through a burst of coding and got the most basic of gameplay elements added. (Thought 2: I would have done well to surrender when I realized that I wasn't going to have any ideas beyond the vague starting one.)

The second day was more of the same. I added the vague outline for abilities, and a patriotic-looking health bar (the background texture is red-white-and-blue, if you haven't seen it yet) to top it off, and then...nothing. (Thought 3: I would have definitely done well to temporarily block Steam from working so I couldn't play more GMod, forcing me to actually think long and hard about how to make a game out of this stupid idea.)

The final day was just adding the basic protesters, packaging the game up, and plopping it on the LD site. (Thought 4: I should've come up with some funny sign ideas beforehand, so I wouldn't have to spend an hour sitting in front of GIMP with the text tool up, staring blankly at the screen waiting for witty ideas to come to me.)

All in all...This was a Ludum Dare I should've probably quit, instead of forcing myself through to the end. The theme was painful, the game idea is probably controversial, and I felt pretty terrible by the end despite having barely spent any time working on things. What I learned from this? Know when to surrender. I really should have.

I didn't initially expect to be joining LD39, simply because I had zero inspiration for any of the themes save for one; luckily, the very same that got picked. So I spent most of the night fleshing the idea out and working on getting a blank Unity project up and running. This's where I'm at so far.

The entire mechanic of the game is that your sources of energy are few and far between, and, as a robot, you need that energy to survive. Initially, you're running off the light output of what're essentially lightningbugs. I'm still throwing together the base GUI elements, so...yeah, it's just pretty flickering lights and an idea so far. But it's notably better than LD38.

I'm aiming to have the minimum viable product (e.g, all the mechanics and core things are in; like, I could submit without much guilt) by the Compo deadline, and if I have some good SFX, music, and ambience by the Compo as well I'll actually be submitting for it. Woo!

Now for sleep and brainstorming.

After abandoning my original idea over 24 hours into the jam, I decided to make something a bit different, a bit simpler, and I was going to do something a little crazy: I was going to make my entry in under 24 hours. I was going to make a compo entry.

Shockingly, it worked out. There's definitely some bugs and critical polish things that need to be fixed, but I can work on those in a day or two when I'm not, like, dead.

You can play/rate it at https://ldjam.com/events/ludum-dare/39/the-fallen, or go straight to Itch: https://cliffracerx.itch.io/the-fallen

If you find any game-breaking bugs (e.g, the win/lose conditions are bollocksed, or critical control tutorials are missing), tweet me at @CliffracerX and I'll try to hotfix it ASAP. I might be asleep when you send the tweet, what with timezones and such.

Good luck to those who're still working on their Jam entries! I'll be happily playing some of your games in 24-ish hours.

Shipping The Fallen after creating it in under 24 hours came with a cost: bugs. Lots and lots of bugs.

The most critical one, one I thankfully discovered before anyone else seems to have played the game, is simple; the win condition didn't work. I hotfixed that IMMEDIATELY.

Then there were some smaller, but equally game-breaking ones. For instance, one that would cause the wiring system to lock up; I still don't know why it does this at all, but I put in some emergency resets so if you turn buildmode on/off again it should work. That's a game-breaking bug, however, as without the wiring system, it's literally impossible to actually recharge the batteries required to win the game.

There've also been documentation errors, like not including the controls; some people simply have outright been unable to play the game because they couldn't find out how to build things. Whoops.

I'm not entirely certain at what point the line between "critical bugfixes" and "altering the core of your game" is drawn, but...yeah. I'm still fixing those bugs.

This was an interesting Ludum Dare for me, as it was the first time I pulled off a compo entry. Originally, I was going to make a 3d game about being a robot in a dying world (think OneShot but on steroids and with no semblance of mercy, hope, or friendliness) and trying to survive for as long as possible, maybe even finding some way to stay alive indefinitely (e.g, creating a weaker replacement Sun) whilst the odds are stacked against you. The "running out of power" mechanic would be very literal; your character is a robot that relies on power to survive.

But 24 hours into LD, I had made minimal progress; I had an okay health/power/ammo UI, and some decently pretty graphics. But that was it. No mechanics whatsoever. I was like "nah, it'll be fine", but as I was saying that, I was procrastinating and watching Extra Credits instead. Turns out, that was totes worth it. I was watching their episode on the idea of the Minimum Viable Product.

https://www.youtube.com/watch?v=UvCri1tqIxQ

That video basically saved my bacon this LD. Because it was the swift kick to the head I needed; I had scoped WAY too large for a Ludum Dare entry, even a Jam one. So I started over and thought up a new idea. "A top-down game. Hmm, with pixel art? Ooh, and over-complciated power mechanics and basebuilding!" These three ideas combined into what is now known as The Fallen, my entry. I knew at the very least I wanted to have the minimum viable product up and running by the compo deadline, that way if I hadn't actually finished MAKING the game by then, I'd still have a playable thing up and running that just needed content and polish.

It was totally worth it. As it would turn out, The Fallen is one of my best Ludum Dare entries, well, ever. The only other one that I ever felt any draw to post-jam was The Adventures of Cactusman (LD32), and that never really went anywhere because my idea guy/lead artist and I had been on rocky relations for most of 2016 and we never really finished the first of the big post-jam updates.

The Fallen, on the other hand; I've already logged about three hours just playing it outside of LD, just because it's FUN. I'm proud of my shooting mechanics. I'm proud of my basebuilding. I'm super proud of my graphics. I'm proud of the core idea, and I think it can go further. It's GOING to go further.

The only updates I'm going to do during the Judging Period are going to be bugfixes and critical polish, and I'm hoping I don't have anything I actually need to upload, because I do cringe super-hard whenever I have to push a modified copy of the game (e.g, to fix bugs like "win condition is bork because ???", "wiring system locks up for no reason", "bullets don't hit because ¯_(ツ)_/¯)", etc) after submission hour is over.

The biggest regret I have about having sprinted for the Compo deadline and making it into a <24-hour Compo entry is simply how many critical polish elements and gamebreaking bugs are still there; like, I wanted BGM, sounds for walking/getting hit, reloading, etc. With that extra day, I might've been able to add those, and make sure it didn't ship with some of the aforementioned gamebreaking bugs.

Once Ludum Dare's over, I'm going to buckle down and start working on a post-jam version, one with more gametypes (e.g, endless mode, co-op, extended mode, etc), more stuff to do (like more buildings, character upgrades and cutomization, etc), and loads more polish. If it's good enough, I might even put it up on Itch for Pay-What-You-Want, maybe w/ a minimum of, like, $1, rather than forcibly free; but that depends on how well-received it is.

All in all, I'm happy about how this Ludum Dare went. I'm going to get back to playing/rating your games (drop me a link in the comments if you want me to play yours), and pondering what I'd like to work on post-jam.

Sometime around Unity 5.4 and later, Mac builds seem to have stopped working, at least when built from Windows. I've been using 5.0.3f since roughly its release date, and I never upgraded, and I can confirm it has functioning Windows->Mac builds. You may want to consider trying to make a downgraded copy of your project, or maybe just trying to build from a Mac if you have one. I believe there's also a way to fix the app file, but the fix method that actually works varies from report to report; some folks just say to chmod it and the error will go away, but others report that the underlying data has to be manually modified to get it working.

I've tried to play some of this jam's games from my Macbook and to no avail; most of them throw the same error, "This app cannot be launched.", which is as helpful as you'd expect an Apple error to be. It's possible it might be building for a newer version of the Mac OS, in which case; some people (like me) aren't on that version and therefor are unable to play your game w/out a WebGL copy.

You should make a WebGL version anyway, it's not much extra effort to export one from Unity, and it's totally worth it; you'll get a lot more players when they don't have to download your game. That's all I've got. Keep on jamming, LDers.

I know I was quiet this LD (to the point of forgetting to make an "I'm In" post, whoops), but I feel obligated to say: I didn't make it this time.

I learned my lessons back in '38 and '39 that shipping unfinished LD entries just isn't worth the pain, and I don't even have a win condition implemented yet for this LD's project. So...yeah. Nothing released in time for '41. That's not to say it's been a bad jam, though.

I decided to make a game using Unreal 4, and it's been incredible for learning the engine. Though I didn't reach my goal (a fully-fledged non-violent survival game), I did make a polished and functional basis for creating the game post-jam.

My goal was to make something that's ostensibly a walking simulator with endless survival elements; you'd basically be living off the land, in harmony with nature. No modern tools or technology - you gotta live off the land. Taking leaves & branches off trees to create makeshift shelter, making a flammable wrap around a stick to get a torch, that sort of thing. Very "wilderness survival show", but with less drama over food and drink - motile beans don't need such trifle things.

Where I actually wound up getting was what you can see in the photos - a basic building system, inventory, stamina and a defunct health bar, multiplayer, and some other goodies, like the ability to save/load your game (persistent inventories, even in multiplayer!), and a relatively fancy menu system.

In spite of its lack of content (or, to some extent, gameplay), it still feels like one of my most polished Ludum Dare entries ever. Saving and loading? Smooth multiplayer? A relatively large and relatively pretty world? A proper menu system, HUD, and pause screen?! Those sorts of things don't even appear in my UNITY titles that often, let alone for Ludum Dare!

So, with all that in mind - I'm glad I partook of this Ludum Dare, even if I wasn't able to submit anything for it. To the rest of you lovely jammers, good luck with your projects! I hope to be playing and rating some of your games in a few days.

(Postal note: The trees and such aren't mine! The only assets I created are the actual Blueprints used in gameplay, and the UI textures - everything else is either the Starter Assets, or free goodies from the Marketplace/Forums. Pop over to the Free Foliage Starter Kit page on the Unreal forums to grab the trees - when imported right, they'll look way better than they do in my project.)

Ludum Dare always seems to creep up on me, and the tradition remains unchanged. I'll hopefully be participating in LD42, and making...something or another in Unity, probably.

I tried using Unreal in LD41, and while the results were gorgeous (and basically an all-around better recreation of a game I'd made over the course of months in Unity), I don't think I'm skilled enough to gamejam with it yet. Having more fun using it for architectural visualization and such (yay for open-house RPGs! :p) - though UV-mapping houses will be the death of me.

Anyways, tools for LD42:

• Unity 5 (technically 2018.something for Linux - damn their new versioning system, I'll never remember this bullhonk >_>)
• Blender (2.78 custom-rolled in Linux)
• GIMP 2.8 (standard apt-get version in Linux)
• Audacity (version unknown, just whatever's available from the xubuntu 16.04 software app)
• Caustic 3 (running in WINE 2.7, 32-bit wineprefix, acquired via PlayOnLinux)
• Inkscape (unlikely to see use, version unknown)
• XUbuntu 16.04 - Linux support is mandatory now. Windows support has become optional. :sunglasses:

My entry's gonna be going into some brave new territory (for my LD entries, at least) - a true sandbox entry. I've been toying around for the past week or so with the idea of writing my own (virtual) processor architecture, using a custom assembly-style language & such. The whole thing is still very WIP, but when I saw "Running out of space" as a possible finalist theme, my interest was immediately piqued for the possibility of making a game that implements said architecture.

Your goal is basically just to write a simple bootloader/BIOS thing capable of loading a thing off the disk, with the only information being "how many addresses to load" in disk address zero. I plan to include detailed documentation both in-game and out, as well as a few small interactive tutorials. Beyond that, it won't really have any hand-waving or goals, and if you want, you can completely blow away the win screen included on the harddrive, to replace it with your own program.

That even means you could write your own (TINY!) game and share the disk image for it with other people. How cool is that?!

Your computer itself has 128 bytes of RAM, in the form of 32 memory addresses, storing 32 bits each. The drive (port 0) has 1kB of storage space in 256 addresses, currently, 148 of which are in use for rendering the win screen you see above. It also has 64 bytes of register space (16 register addresses), 16 bytes (4 addresses) of which are given semi-hardcoded uses by the processor itself.

The monitor (port 1) is 16x8 pixels and supports 4 colors, off/black, on/white, a dark green, and a light green.

In the future (when I implement the functions for it), there'll be a keyboard in port 2 as well, which isn't likely to be used in any "official goals", so to speak.

I'm not COMPLETELY sure, but I think there's a chance you might be able to make, say, a small Snake implementation or something. It'll definitely run up against memory limitations, though - the only way you can even fit that in RAM is to make a small for loop that can run functions off the disk after an offset, and my guess is you'll need at least 18 addresses to make that loop. JMPs and similar would require even more code.

I intend to include an option to load it up in a higher-fidelity mode that gives you 1kB of RAM & 8kB of disk space, letting you build larger programs, but...that's more for "I just wanna play around in a virtual machine" and less for achieving the LD-specified goal of writing a basic bootloader thingy.

My only major quibble with the whole idea is this: Is this Compo-legal? The actual op-code list & such for the VM/processor was made before LDJam, so does that break the "all assets must be created before the jam" rule?

I made a game about computers for this Ludum Dare. Specifically, virtual computers. With processors. And RAM. And so on. The "Running out of space" gimmick is that you're running out of RAM/disk-space - your computer only has 128 bytes (32 memory addresses of 32 bits each) of RAM, and your drive isn't much better at 1024 bytes (256 memory addresses).

That's not really the main reason I'm posting this, though. I'm wondering if it's compo-legal. I've been toying around with the actual ideas for the processor architecture the game implements for a few days before Ludum Dare, as well as a Unity-compatible implementation of it. I don't THINK it'd fall foul of the rules, due to the clause "You’re free to start with any base-code you may have.", but I'm not 100% certain.

Thoughts, jammers?

With some quick last-ish minute coding, I've got basically all the documented features implemented, and have everything released & the actual game entry published. Onto a proper game overview.

Senbir is a "game". Sorta. More than anything, it's a sandbox with a fully-featured virtual computer, but it does include some short tutorial levels to help guide you all the way to building a simple bootloader that can run a program (read: a win screen) off your disk. That's all well and good, you might be thinking to yourself, "but how does it fit in with the theme?"

Your computer only has 128 bytes of RAM. That's 32 memory addresses (1 address = 4 bytes) in RAM. Your programs have to fit into 32 addresses or less. Your drive is bigger (1024 bytes in 256 addresses), but by no means the end-all be-all of storage. This is all REAL SIMULATION, too. You're writing actual assembly (and by extension, bytecode) for the virtual TC-06 processor that lives in your computer. You can, in theory, make anything. You have a monitor - data port 0. You can read from it and write to it. A harddrive, port 1. Read and write access. A keyboard, port 2. Even a mouse in port 3.

If that's all a little too restrictive for you, then there is an Extended mode that gives you 1kB of RAM & an 8kB drive, as well as a Custom mode that lets you pick pretty much every number yourself.

Not the MOST exciting thing to post about (everyone's used paint programs by now!), but it IS a paint program made for running on Senbir's Extended mode computer.

For those curious to give it a try in-game, the code: //==PAINT== //WASD to navigate. Spacebar toggles if you're painting or not. Use E and Q to shift forwards and backwards through the list of colors, respectively. //This version was made for EXTENDED MODE, with its 16x8 resolution, and 4-color capability. //=REGISTER USAGE= //REGISTER 00: BRUSH DOWN? //REGISTER 01->2: KEY PRESS THIS TICK //REGISTER 03: USED FOR IFJMPS //REGISTER 04: BRUSH X //REGISTER 05: BRUSH Y //REGISTER 06: BACKGROUND COLOR REGISTER (USED IF BRUSH IS NOT DOWN) //REGISTER 07: BRUSH COLOR REGISTER (USED IF BRUSH IS DOWN) //REGISTER 08: TEMPORARY MODIFICATION REGISTER //REGISTER 12: INT 16 //REGISTER 13: INT 8 //REGISTER 14: INT 4 //REGISTER 15: INT 1 SET 15 3 00000001 //Set register 15 to the integer 01. Addr0. SET 14 3 00000100 //Set register 14 to the integer 04. Addr1. SET 13 3 00001000 //Set register 13 to the integer 08. Addr1. Yes, I know, there's a duplicate. SET 12 3 00010000 //Set register 12 to the integer 16. Addr2. SET 6 0 00000000 //Set register 6 to have the appropriate color. Addr3. SET 7 0 01000000 //Set register 7 to have the appropriate color - white. Addr4. GETDATA 2 3 0 //Get the last keyboard input. Addr5. PMOV 1 2 0 31 0 0 //Move the last keyboard input into register 2. Addr6. IFJMP 0 15 1 //If a key was pressed, jump to the input subroutine. Addr7. JMP 2 3 //Otherwise, do nothing. Addr8. PMOV 9 2 0 31 0 0 //Put the "brush down" variable in so IFJMP'll accept it. Addr9. IFJMP 0 2 0 //Jump to the background restore if the brush isn't down. Addr10. JMP 0 2 //Otherwise, jump past it. Addr11. SETDATA 0 3 6 //Wipe the old one. Addr12. PMOV 4 7 28 31 6 1 //Splice the last 4 bits of the X register (the actual x position) into the rendering register, offset +6 (<28>XXXX -> CCXXXX<26>). Addr13. PMOV 5 7 29 31 9 1 //Splice the last 3 bits of the Y register (the actual y position) into the rendering register, offset +9 (<29>YYY -> CCXXXXYYY<23>). Addr14. PMOV 7 8 0 31 30 1 //Addr15. GETDATA 0 3 8 //Get the monitor data. Addr16. MATH 1 6 5 //Paste the color in. Addr17. JMP 0 1 //Addr18. JMP 0 1 //Addr19. SETDATA 0 3 7 //Render the brush. Addr20. JMP 2 16 //Jump back to the start of the loop. Addr21. SET 0 0 01011101 //START OF INPUT SUBROUTINE. Set Register 0 to the key ID for W. Addr22. SET 0 1 11000000 //Set Register 0 to the key ID for W. Addr23. GETDATA 2 3 0 //Check the W. Addr24. MATH 1 2 5 //Move the result of GetData in. Addr25. IFJMP 0 34 1 //If W IS pressed, jump to the appropriate memory position. Addr26. SET 0 0 01011000 //Set Register 0 to the key ID for A. Addr27. SET 0 1 01000000 //Set Register 0 to the key ID for A. Addr28. GETDATA 2 3 0 //Check the A. Addr29. MATH 1 2 5 //Move the result of GetData in. Addr30. IFJMP 0 32 1 //If A IS pressed, jump to the appropriate memory position. Addr31. SET 0 0 01011100 //Set Register 0 to the key ID for S. Addr32. SET 0 1 11000000 //Set Register 0 to the key ID for S. Addr33. GETDATA 2 3 0 //Check the S. Addr34. MATH 1 2 5 //Move the result of GetData in. Addr35. IFJMP 0 30 1 //If S IS pressed, jump to the appropriate memory position. Addr36. SET 0 0 01011001 //Set Register 0 to the key ID for D. Addr37. SET 0 1 00000000 //Set Register 0 to the key ID for D. Addr38. GETDATA 2 3 0 //Check the D. Addr39. MATH 1 2 5 //Move the result of GetData in. Addr40. IFJMP 0 28 1 //If D IS pressed, jump to the appropriate memory position. Addr41. SET 0 0 01001000 //Set Register 0 to the key ID for SPACEBAR. Addr42. SET 0 1 00000000 //Set Register 0 to the key ID for SPACEBAR. Addr43. GETDATA 2 3 0 //Check the SPACEBAR. Addr44. MATH 1 2 5 //Move the result of GetData in. Addr45. IFJMP 0 26 1 //If SPACEBAR IS pressed, jump to the appropriate memory position. Addr46. SET 0 0 01011100 //Set Register 0 to the key ID for Q. Addr47. SET 0 1 01000000 //Set Register 0 to the key ID for Q. Addr48. GETDATA 2 3 0 //Check the Q. Addr49. MATH 1 2 5 //Move the result of GetData in. Addr50. IFJMP 0 28 1 //If Q IS pressed, jump to the appropriate memory position. Addr51. SET 0 0 01011001 //Set Register 0 to the key ID for E. Addr52. SET 0 1 01000000 //Set Register 0 to the key ID for E. Addr53. GETDATA 2 3 0 //Check the E. Addr54. MATH 1 2 5 //Move the result of GetData in. Addr55. IFJMP 0 33 1 //If E IS pressed, jump to the appropriate memory position. Addr56. SET 0 0 00000000 //Unset 0. Addr57. SET 0 1 00000000 //Unset 0. Addr58. JMP 2 50 //Jump back to the render loop. Addr59. MATH 15 5 1 //W WAS PRESSED. Increment Y down by one. Addr60. MATH 13 5 4 //Modulo Y just in case. Addr61. JMP 2 5 //Jump back to the render loop. Addr62. MATH 15 4 1 //A WAS PRESSED. Increment X down by one. Addr63. MATH 12 4 4 //Modulo Y just in case. Addr64. JMP 2 3 //Jump back to the render loop. Addr65. MATH 15 5 0 //S WAS PRESSED. Increment Y up by one. Addr66. MATH 13 5 4 //Modulo Y just in case. Addr67. JMP 2 3 //Jump back to the render loop. Addr68. MATH 15 4 0 //D WAS PRESSED. Increment X up by one. Addr69. MATH 12 4 4 //Modulo Y just in case. Addr70. JMP 2 3 //Jump back to the render loop. Addr71. MATH 9 2 5 //Move the contents of Address 9 (the brush toggle) into 2 for IFJMP use. Addr72. IFJMP 0 2 0 //Is the brush up? Addr73. JMP 0 3 //Nope. Addr74. SET 9 3 00000001 //Turn the brush on. Addr75. JMP 0 2 //Skip past turning it off. Addr76. SET 9 3 00000000 //Turn the brush off. Addr77. JMP 2 7 //Jump back to the render loop. Addr78. SET 8 0 00000000 //Addr79. SET 8 1 00000000 //Addr80. SET 8 2 00000000 //Addr81. SET 8 3 00000000 //Addr82. MATH 7 8 5 //Splice the color in. Addr83. PMOV 7 8 0 1 30 1 //THING. Addr84. MATH 15 8 1 //Q WAS PRESSED. Increment COL down by one. Addr85. MATH 14 8 4 //Modulo COL just in case. Addr86. PMOV 8 7 28 31 30 0 //Splice it back into the renderer. Addr87. JMP 2 10 //Jump back to the render loop. Addr88. SET 8 0 00000000 //Addr89. SET 8 1 00000000 //Addr90. SET 8 2 00000000 //Addr91. SET 8 3 00000000 //Addr92. MATH 7 8 5 //Splice the color in. Addr93. PMOV 7 8 0 1 30 1 //THING. Addr94. MATH 15 8 0 //E WAS PRESSED. Increment COL up by one. Addr95. MATH 14 8 4 //Modulo COL just in case. Addr96. PMOV 8 7 28 31 30 0 //Splice it back into the renderer. Addr97. JMP 2 10 //Jump back to the render loop. Addr98.

I also have a Custom preset & updated version that're better for pixel art-ing up in a thread on Itch.IO: https://itch.io/t/279217/code-sharing-megathread

If you want to see what Senbir's VM is capable of without having to muck around in the code yourself, this is a good way to do it.

You can compile it straight to the computer's ROM once you've pasted it into the Assembler window. Turn the computer on, activate the keyboard (look at it and press F), and then use WASD to move the paint cursor around, spacebar to toggle drawing, and Q/E to cycle colors.

This is more of a request than anything else, but, if you made your game with Unity, please include a Linux build with it, and a Mac one too, if you can help it. Unless you're using outside libraries that don't support Linux builds (seems unlikely for a LDJam game to me), it's as easy as going to Build Settings, and selecting Linux Universal (x86 + x86_64), and/or pulling up your Unity installer to grab Linux support. Barring any catastrophic failures (which are likely to affect your other platforms as well), you shouldn't need to do any more work than that, even for providing support - Unity's Linux builds generally play nice across all consumer-friendly distros.

I know I'm not the only developer who's working in Linux this LD, and it reaaaally hurts not to be able to play and rate more games, 'specially those of people who've rated Senbir. I like being a Feedback Friend. :slight_frown:

It's a bit more effort, but if you're an Unreal 4 user instead, you can do cross-compiles for Linux using the instructions found here on the wiki. Or if you have a Linux machine sitting around, you can install Unreal 4 on it & copy your project files over to make a Linux build that way. Whatever works, right?

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.

Ludum Dare, why must you always sneak up on me?!

So, barring any horrible disasters or being impossibly busy, I plan to participate in the LD44 compo, although I have no backup plans to try and make work within the theme's boundaries in the event we get another A Small World or similar, and as such may end up bailing in that situation.

Toolset of choice: * Still on XUbuntu 16.04 (Windows support remains optional :sunglasses:) * Unity 5 (specifically, Unity 2018.2.somethingorother. the new versioning system remains bullhonk, y'all.) * Blender (2.78, custom-rolled) * GIMP 2.8 (2.8.16, as provided by apt-get) * Audacity (2.12, as provided by apt-get) * Caustic 3 (running in a 32-bit WINE 2.7 prefix)

Well, this has definitely been one of the more unusual LDJams I've participated in. Usually, I either participate on-time, or I completely miss that LD is underway until it's already well done and gone. This time was different; I remembered LD was happening ~19 hours into the Jam, went "oh CRAP", and jumped straight into a new design-doc to work out what game I'd make this time. Settled initially just on "something with a robot where all your weapons, armor, etc use your personal battery & if you run out, it's game over", thinking it'd probably be a top-down wave-shooter in the vein of The Fallen, with the notable gimmick of being able to trade your maximum energy for artifacts that grant new powers and the likes.

That wound up changing to a side-scrolling dungeon-crawler of some kind, and my first 24 hours were mostly spent faffing about in other areas whilst slowly building a character-controller. Not a whole lot of motivation until towards the end of those 24 hours, which saw the starts of a procedural-weapon system. Unfortunately, being that I started late, I only had another ~24 hours to go, and still the motivational troubles persisted. Until the last ~8 hours or so (the final day), at which point I had a stroke of semi-genius on how to do a vaguely Metroidvania-style finite map, and spent the remainder of the day cramming to smooth out the pre-requisites for random map generation, followed by about two hours of massive stress trying to finish the map generator in time to submit.

Unfortunately, I didn't succeed; when the hour hit, the world-generator was suffering some catastrophic failures, and enemies didn't even exist yet. As Submission Hour rolled in to a close, I put up a barebones template page under the Unfinished category w/ a link to the as-of-the-time unfinished Gitlab & Itch.IO pages, and threw in the towel on submitting in time for an actual scored entry. Kept working on it, though, and here we are about a day later and ~75 hours of dev-time in, with a post-release post-mortem. A few hours after Submission Hour closed, I'd managed to fix the world-generator, and over the course of the next day, most of the remaining critical polish got put in - all three sizes of weapon are now available, enemies are present, you can win and lose the game, et cetera. So, while it's a day late, the game is done (for the time being) and now playable via Itch.IO, and the source is available at GitLab.

My lessons from this Ludum Dare are probably only a pair this time; one, check the bloody calendar to make sure LD isn't already half-over, and two, don't bloody procrastinate playing Breath of the Wild instead of making videogames. Gah. On that note, I'm going to go procrastinate playing Breath of the Wild whilst recovering from that mad development spree. If all goes according to plan, I'll be playing some of your games fairly soon, so if you happen to want feedback, I'd be glad to provide some if you'll leave a comment, though I dunno if my ratings will count, being that my game is Unfinished. Cheers, fellow jammers!