Tuesday, December 31, 2019

Everything I Did in the Years Before 2020

Even though the date on this post says 2019, I'm actually compiling it here in early 2020. This is my solution to a sort of annoying problem, which is that I've gone and spent several years doing, learning, and making stuff, without having the foresight to put any of it up online. It's a double-edged sword - 80% of what I've done is now embarrassing to look at, and thankfully, I get to retroactively decide not to show it to you. On the other hand though, that last 20% is a huge catalog of dead, unfinished, or unremarkable projects, and they're doomed to be lost as soon as I run out of disk space.

Instead of trying to fill out a blog post for each of them, I've decided to dump a whole bunch of these projects into this one Super Duper MegaPost (tm). Not everything made the cut, obviously. To be honest, most of my projects get deleted after I give up on them, so some stuff really is lost forever. Again, as a disclaimer, many of these projects are still embarrassing to look at for all the usual reasons. They're old, and I didn't know what I was doing yet, and blah blah blah. They represent my first five-ish years of learning, messing up, and starting things I obviously couldn't finish. I figure that learning from your mistakes is cool and all, but learning from other peoples' mistakes is even cooler - so I'll post them here anyway.

Plus I didn't only make mistakes. Sometimes I made stuff that was almost sort of interesting.

Oh, and in addition to this mega-post, I'll be uploading my game jam submissions separately, since they at least represent "finished" projects. So keep scrolling down to see those.


And now, on with the show:



At one point in the somewhat recent past, I found out that I could re-live my childhood dream of beating Super Monkey Ball 2, with the help of an emulator. After about half an hour though, I gave up on the dream again, because I realized it would be more fun to implement the mechanics and screw around in UE4. We actually developed this into a fun little game concept, where you can morph between a few different shapes, each of which has different movement mechanics and physical properties.

Anyway the morphing uses basic blend shapes (morph targets in UE4), although the bouncing deformation in the second video is just a material effect. The movement itself, along with the bounce physics, were tricky to implement. I didn't want to rely on the physics system to move around, since it's inconsistent and a bit unreliable at high speeds; So I wrote a custom character controller in C++, and made a vague attempt to properly compute the bounce forces for the soft body. I keep promising myself that someday I will revisit the concept, becuase it really would be a cool game.






I've played a fair bit with splines in UE4 over the years, and there are two main challenges. The first is that a spline can have many points, but a spline mesh can only have two. You always have to hack together a system that skins a spline with an array of meshes, which is a bit of a pain. The second is that I swear somewhere in the implementation is a rotation normalization bug, because the only reliable way to control spline roll without introducing kinks as you cross coordinate axes is to compute the roll manually. Anyway, I was playing with an ability that would grow vines over stuff, and it worked reasonably well.





Coincidentally, for the same project, I got to dive in and play a lot with character control and movement abilities. This is easily my favorite part of gameplay programming; I'm fascinated by movement systems in platformers, and "skill-based" modes (like surf and bhop in Source Engine games). I tuned the movement to be pretty fun, extended the player controller with niceties like crouching/sliding/sprinting, and also added a couple of dash abilities:





At one point I decided to do ocean water, for some reason (The reason was that it is very fun). There are a few methods, of varying complexity, and I pretty much implemented them all. The prettiest one uses a compute shader for FFT, to generate textures for offset, gradient, and folding. I want to stress that I did not write the FFT shader, although I spent hours and hours in my university library trying to wrap my head around the math. I just adapted an old UE4 plugin (like, version 4.2 old) that handled the FFT. My actual goal was to read back the displacement texture to compute buoyancy on the game thread, but at the time I didn't know enough about the rendering pipeline to make that happen.






A little known fact is that since Minecraft came out, every novice engine programmer goes through a voxel phase. I was no exception, and at some point I got super into runtime terrain meshing. I used the Runtime Mesh Component plugin to do your basic metaballs example with marching cubes. That plugin was super interesting, and I was sad when it stopped being maintained. Thankfully though, it has since been resurrected, and now has made some seriously cool improvements; I really want to poke around with it again sometime. Oh and the holes in the mesh are just where it clips the simulation bounds, that's not a bug in the meshing.





Just like every engine programmer goes through a voxel phase, every novice tech artist goes through a toon shading phase. This one is a pretty standard post-process effect for outlines and cel shading. In hindsight, this sort of effect is extremely wasteful; UE4 does a tremendous amount of work (and uses a tremendous amount of video memory) for the PBR pipeline, and this effect throws most of that work away. I've since done the same effect with what I think is a better approach, involving a custom shading model for the engine. The new one also supports all light types (not just directional), and handles shadows more gracefully. Regardless, I actually made a YouTube tutorial for the older effect (on top of the pile of existing ones), which was full of bad, wrong information, but someone took it and made a short film with it, which was awesome!





In addition to all the UE4 stuff, I've started and then abandoned countless graphics engines, usually built around the Vulkan or D3D12 APIs. Invariably, I get far enough along to realize that actually I've structured things poorly, and then I start again. I do get a bit further every time though, so I've got that going for me, which is nice. Here's a couple random examples of old and dead engines, none of which do anything remotely remarkable:






OK this is getting far too long, and there are so many more dead projects to talk about, but they just get less and less polished from here. Instead of padding out this post any further, I'll drop a couple of unlisted YouTube links, which are mostly just me talking through some internal tools stuff, or showing other team members what I've been up to. These were never meant for public eyes, so consider it a "behind the scenes" look, from years ago when I didn't know what I was doing (I still don't, but hey).


Finally, here are some fun extras presented without context:




Tuesday, February 19, 2019

UE4 Winter Jam 2019: Coup d'Amour

After having to miss the fall UE4 jam last year, we were determined to make something happen in the winter jam. School schedules still managed to get in the way, but in the end we found time for a fun little project.

I tend to wear a lot of hats for game jams; I primarily did gameplay programming, but also some UI stuff, sound, particles, and general tech art stuff. With school getting in the way I really only got to spend 3ish days out of the 5.

Andrew did sound and music, as usual, which turned out really well. He really only had the weekend (two days), and then had to take off back home. We had an emergency in the last 24 hours with music, and he had to compose something really fast using GarageBand on a  2011 iMac, which was quite impressive.

Barak did his usual amount of art, which is to say, "all of it". He also only had 2 or 3 days, because on top of school, he had to go attend a wedding in the middle of it all.

We also got Will in for this one. He did a lot of UI design and programming, and also did some great work with the trailer and submission. The trailer is mostly limited by my ability to supply him footage near the deadline. Like the rest of us, he only had around 3 days to pitch in.

The theme this time around was `All's Fair in Love and War`, and we decided to submit something in the `Friends and Foes` category (a shared-screen multiplayer game). Will came up with the game's name; It's a play on coup de' grĂ¢ce, which is "killing blow" or "blow of mercy" in French. Coup d'Amour is "blow of love", which is fun considering the jam's theme (He also checked it with a native French speaker to make sure the wordplay is valid, so hopefully we aren't making fools of ourselves there).

So there you have it. Coup d'Amour is a local multiplayer game for four players:

controls for the game
screenshot of the game



It's a twin-stick shooter, and you all play on the same screen. The rules are pretty simple:

  • You play in teams of two, as king and queen. You're attached to each other with a rope (it's a metaphor for your love, or something).
  • To win, use your crossbow to sever the other team's rope.
  • There are two colors of crossbow bolts; You shoot one, your teammate shoots the other.
  • You have a shield, but it only blocks one color. Use it to protect your partner, and hopefully they'll protect you too.
  • Your shield will break if it takes too much damage. That wouldn't be good.
  • Blocking damage makes your teammate's shots more powerful. If you charge them up enough, they could break right through an enemy shield.
  • You can shield bash the enemy if they get too close. This costs some shield durability, but will stun your enemy.
  • Grab powerups to give you a shield-ignoring fireball, or regenerate your own shield's durability.

These rules make for a pretty fun kind of rock/paper/scissors style gameplay. You want to block shots to charge up your partner, but not so many shots that you lose your own shield. To win, you can out-play, out-smart, or just out-shoot the enemy team. Since you're attached to your partner though, you'll have to coordinate where and when you move or attack. Play too timidly, and you'll find yourself with a broken shield. Too aggressively, and the enemy will do too much damage for you to block.

Here's a quick video to give you a sense of the gameplay, and I apologize that it has no sound (we were in a rush near the deadline, as you might imagine):

We had a ton of fun working on the project - the logic is pretty complex, with a lot of moving parts, and all of the art save for some sounds was done by hand (although the far-off camera angle doesn't really do it justice, sorry Barak).

If you'd like to download and play it, and you have four gamepads and a Windows computer, you can check it out on my Itch.io page here. Unfortunately it does require four gamepads for you to get past the lobby screen, a fact which I fear may have made it difficult to judge for the jam.