It's been a long long time since I last participated in Ludum Dare - somehow, I always remember it exists a bit after it has ended. I saw that one was coming up two days early and thought, "Hey, maybe I should do this and learn WebAssembly along the way - how hard can it be?" Well, I thought, I'll just write a minimal engine from which I can draw sprites, play sounds, and accept user input - oh, and it'd be nice if I could get it to compile locally for easy debugging. Maybe I'll even practice by implementing asteroids or something. How hard could it be? Well, here we are, not too late with an engine that sort of works, even if it takes forever to compile (and I'm not going to spend my time figuring out how to write a better Makefile). I've tricked Xcode into thinking it might compile as normal C++ (it won't) to get that sweet sweet code complete even if I can't have that even-sweeter integration with a debugger (I'll just skip the part of LD where I write buggy code, I guess, because I have no plan for debugging). Even though I might have an engine which is just various open source components in a trench coat, I am excited to do some C++ing ~on the internet~.

I uploaded my "engine" here, though it'll probably give you a 403 Forbidden Error until I work out how to get the .htaccess file right: http://themilobrandt.com/LD46/WASM.zip

I'm a bit ashamed to say that this may be the best looking game I've ever made. Yeah, most of the things are rectangles and the main thing that isn't is just a circle with a crappy face drawn on it, but at least the colors would require more than 3 bits to specify - that's progress for me! If we all agree to say that this is "charming and minimalist" instead of "bad", I think we'll get along just fine. But, hey, I'm a crazy person who likes to write physics engines from scratch and all that is going great, save for a few whoopsies that are now debugged - and I've got a nice 2 minute loop of background music that seems to work really well (and, hopefully, will convince anyone who plays to go with the interpretation of the graphics as minimalist).

What Went Well

In general, the process for programming this game seemed to go really smoothly - perhaps I've finally done enough work with vectors and such that writing this sort of physics engine isn't too bad. I'm really pleased with how smoothly it works too - the movements feel quite natural and are workable for a player. Granted, I think this was helped by the physics engine not being very ambitious: it does rectangles and circles and nothing else, but that seems to suffice. Plus, the code around this engine is not so horrible for the speed at which it was written - a lot of the features from recent C++ standards were a boon in developing this.

I liked working with WebAssembly too - the ability to deploy code so quickly is quite convenient, as I'd always found packaging code to really suck in a short time frame and that's basically entirely eliminated in this approach. I was almost surprised at how seamless it was to transition from writing for actual platforms to WebAssembly.

I'm very pleased with how the music came out - especially since I was able too sit down and pound out a loop of a little more than 2 minutes in a little more than 2 hours. It was nice to do this early, since it set some amount of mood for the game going forward.

I did a lot of polishing working prior to really fleshing out the gameplay. I'm not exactly sure how this worked out for the gameplay, but it sure made the process feel smoother - no last minute scrambles for assets or for code to put things together. Plus, I think I saved myself time by writing the code right the first time so that it could support some nice flourishes rather than having to go back and hack things in.

What Didn't

Well, setting aside graphics which are a perpetual source of trouble, I had a fair amount of difficulty with using WebAssembly, which is a new technology to me. The big two issues were in compilation time and debugging - the project is rather small, given that most the game-specific code was written in a day, and the engine itself was largely written in the three days prior to that, yet it took about a minute to compile each time! Plus, I haven't worked out a practical way to debug WebAssembly - I had been relying on Chrome's debugger to work well, but it's not very useful to try debugging when you can't see variable names and when pointers print as their literal values - and long compilation times made it hard to debug by printing from the code.

There are definitely some issues that I think are something to do with my use of WebAssembly, though - the frame-rate seemed perfectly good most of the time, except for occasional spikes in lag. I'm not so pleased with that, since it certain worsens the game experience, but it's not overwhelmingly prominent.

I didn't really feel like my level design is so good - it feels like I made levels just because a game needs levels, rather than because I had anything really clever to do with them. I'm concerned that my game might not do enough to teach players the mechanics - but we'll see. I also definitely felt limited by the tooling I had for level design - everything had to be hard-coded, but this meant that testing was a pain (because it took at least a minute to test event any change - though I was smart enough to add a level skip button this time around) - and it also involved a lot of data entry. I worked out everything on graph paper prior to coding it. I also think that a lot of the "fun" of platforming games comes from fluid sequences of motions - which is hard to do without a lot of tweaking. I also started to feel that my frame was too small to accomplish a lot - scrolling would have been helpful to implement, and not really that hard, except for the issue with entering data. It also occurred to me only very late that, since I was hardcoding things, I didn't need to invest time in building a level framework that would support serialization - it was a lot easier to make interesting things happen in levels once I realized that I could just store all the information in opaque function objects since nothing ever left the C++ context. I spent a really large amount of time on making levels, so it's a bit of a shame that it didn't work out better.

Things to Add To My Toolchain

1. Generation for Level Data: It would be nice to have a tool for inputting lots of coordinate data - even something as simple as "draw rectangles, get output in desired format" would be great. Heck, even without serialization/deserialization, a tool that would spit out the source code to hard code that kind of data would be great. I know there's lots of tools out there for generating this sort of level data, but I'm not familiar with any.

2. Proper compilation for WebAssembly: I'm sure a lot of my compilation woes would have been solved by building separate object files and linking them at the end of the build, rather than feeding the entire source to the compiler each time around. This wouldn't be so hard to accomplish by changing my Makefile, but I just didn't have the time to learn to do this during the competition.

3. Debugging for WebAssembly: I'll have to look into whether a gdb-like tool exists for WebAssembly - it seems like Chrome's facilities for this are still quite new and not yet well-featured. It might just be a matter of time before good debuggers become standard.

4. Integration of C++ with Javascript: One thing that would be really excellent would be to learn to use Javascript together with C++ - if I could have made it so that Javascript would talk to C++ well enough to "write" level in Javascript, I think I would have saved a lot of time and opened new possibilities; it just strikes me that "use an interpreted language" is a nice middle-ground between "hard code stuff" and "load levels from files" since it leaves open all the customization of a programming language, without the pain of hard-coded assets.

5. Some sort of sound generator that's not bfxr: I generally find that bfxr conflicts with my aesthetic preferences for audio; I like to make sounds with smooth envelopes and lots of reverb, which is not really what bfxr is good at. I might have to think about writing something for this purpose.

Oh, what's this? Ratings are in? Wow, let's go take a look: Hmm... a little small... let's zoom in... Alright, things looking normal... scores in the 50 - 70th percentile, not bad not bad...

Wait... what's that? ENHANCE! WHAT!? An outrage! An absolute shock! An affront to the dignity of my did-it-in-less-than-five-minutes graphics! We must get to the bottom of this. Okay, let's empty out the folder of assets in my game and get a line-up. Alright, here are the suspects:

Suspect No. 1: The Concept of Love

A bit lumpy, but this one seems to have an alibi: it's just a particle effect and, to be honest, probably the most polished thing in the game, graphics-wise... what's the next suspect?

Suspect No. 2: The Concept of Heartbreak

Well now, this pair of shady fellows seems like a plausible MURDERER for my graphics score! I mean, they might look good if they actually coordinated, but as a particle effect where each is just randomly placed... hmm... looks pretty bad, huh. Well, let's keep 'em here and see who else might be to blame.

Suspect No. 3: The Negative of the Concept of Love

Okay, all these images that are clearly derivatives of the first one are getting a bit suspicious - and this one is just for a fade in/fade out. Granted, it is way too low resolution to be scaled as big as it is used, and it's a bit weird when it clips into the edges... but, I don't think it murdered the graphics score...

Come on... think... what are the graphics that the player stares at for the whole time...?

AHA!

Suspect No. 4: A circle

Oh man, now that I look at it again, Circle is pretty unpleasant to look at... as one commenter put it, Circle has a bit of a resting "horrified screaming stare" face. Of course, it's not like Circle plays a big role in the game, right? Oh, it's one of two main characters? Well that's not good, but I feel there must be something more. Still, it's gonna be hard to tell Circle how ugly it is...

Doesn't the player control something? And what about the background? Or the levels? I don't see anything in here for them... really suspicious how I can't find the sprites that make up the majority of the game... hmm... wait... what's that little thing? Is it even there! ZOOM IN! Oh, I think we've solved this!

Suspect No. 5: A single white pixel

AHA! This must be it! This little pixel was masquerading as most of the graphics - just using various colors and scales as disguise! Heck, it thought it might be able to be the main character without much modification! I bet this didn't help either... of course, Suspect No. 4 is still... certainly a contender for the ~murderer of the graphics score~.

Welp, I'm exhausted. That was a lot of investigative work. Still, I think these graphics are better than average for me - at least there was a color scheme this time, haha!

Hello, Ludum Darers!

This is a bit of self-promotion, but hopefully not too off-topic*. I'm a developer who made his first game in Ludum Dare nearly a decade ago (and have made quite a few games since then here) and I set out last year to make a game of a larger scope (though not based on a jam game) - and am starting to get near where I hope to release it publicly. I've always been impressed with the quality of feedback I get on jam games from this community, so I thought I'd reach out here to see if anyone would be interested in testing my game prior to any public release of it. A trailer for the game follows, showing sped up gameplay:

https://youtu.be/ZiOrIll8mUk

The game is called Warp Factory and is an automation puzzle game in which the player must build factories to produce various shapes and patterns, as well as to perform more dynamic tasks. It features a system of portals that allow one to cut apart and reconnect space in paradoxical - and productive - ways.

Anyone interested in testing can sign up at this link: https://themilobrandt.com/warpfactory/subscribe.html

I'm planning various improvements before I release the game as a public beta in a month or two - particularly to graphics** and to improve some aspects of user experience, as well as to support modding - but I'm not sure how the gameplay holds up for someone who hasn't been acclimating to the puzzle for the last year, especially since I plan to create more puzzles, but don't know exactly where players would value these most - so feedback would be much valued and likely to be reflected in the game's development.

(*I propose that we just pretend this is for the October Challenge, setting aside that the October Challenge is on hiatus and that it is nearly as far from October as it's possible to be)

(**I'm afraid that, after developing this game for a year, I have conclusively proven that my usual struggle with graphics during these competitions is not, in fact, due to time constraints. That said, I hope to participate again in the April LD and will surely blame time constraints for the inevitably bad graphics nonetheless :) )