Over Unity

Over Unity - A Puzzle Game is a 3D puzzle game built around creating perpetual motion machines powering "wheels", using portals, velocity addition arrows, gravity changer arrows, and little wooden deflectors! I'm going to be talking through my Ludum dare, initial ideas on what I wanted to do, the scope I grew into over the first day, troubles through day 2, and the mad dash that day 3 always is! Here's the game's page: https://ldjam.com/events/ludum-dare/47/over-unity-a-puzzle-game

A Little Gameplay

Again, here's the link to the game: https://ldjam.com/events/ludum-dare/47/over-unity-a-puzzle-game

Beginning Ideas

As soon as I saw the theme I thought death loop, as I figured everyone else would, so I discarded that. I wanted something different that would fit the theme. Pretty soon, getting an object stuck in a loop came to mind. From that it wasn't much a jump to perpetual motion machines - though I guess it could have gone the other way. I wanted to use a grid to make the puzzles stable/safe, with custom "physics". I hadn't made a puzzle game before so I was concerned about things being ever-so-slightly misaligned if it weren't nicely grid based. I'm kind of questioning this decision now, but at the time it made sense. The original ideas about what "Tiles" there would be were a bit more vague/nebulous and larger in scale. I initially envisioned them as having any size (multiple tiles wide), and specific input/output directions and tiles.

The first day

Initially I went into full "systems mode", putting together the grid system and all of the little things that made it tick. I did this before I'd really fully conceptualized what tiles would be, so if you look in the code now, you'll find some unused things that just fell out of scope as I worked. Once I wanted to get in and test the system in-game, I decided to hop over and create some models.

Modeling

I used blender to model all of the objects in game. I'm not much of a 3D artist, so I kept everything very wieldy and low-poly. I still had the game mis-scoped at this point, so I made a few assets that never got used (including a 2x1x3 conveyor belt!). I got the environmental assets and the portal and wheel tiles done, so I moved back to the game

First time in game

There were obvious bugs, as most people who've made games would expect. They were easy to fix. I noticed I messed up the normals on the conveyor belt, so it didn't get put in. This was the first step toward my eventual scope-thinning. The simple portal and wheel formed the basis of it. Simple 1-tile things that changed one thing about the ball. Following this I decided I wanted to add velocity and gravity effectors, as well as deflectors. I wanted at least 10 puzzle rooms, and a split path in rooms you could do. I ended the first day at this point, but overall I'd say it went well.

Day Two: Mostly everything

On day two, I created the rest of the tiles and threw them in. Bugs galore! I didn't really think about all of the edge cases with my weird grid-based system, so a lot of this day was spent fixing them. The morning was the new tiles. The afternoon was a cycle of create room -> notice bugs -> fix bugs -> fix room puzzle -> create next room. I noticed a fairly big bug with the code to move the ball between two locations, to check every tile in between for interactions, so that was quite the thing to fix. I was using a 3D breshenham line-drawing algorithm found online, but I realized it was only correct for one octant of 3D space. I remembered I'd written a line-drawing algorithm for minecraft world generation years prior, so I dug that up and ported it from java to C#. It worked fantastically, but it was a really silly waste of valuable time. Additionally, I added the tile indicator showing which tile you were interacting with at the moment. It was a really simple implementation of it, but it improved playability massively.

A Crash!

Finally, after a bunch of this, at 3 AM on Sunday I made unity crash with the SECOND occurrence of a stack overflow bug. The first didn't scare me enough I guess. I had around 7 rooms done at this point. I hadn't saved the scene in over 24 hours (silly me), and I lost 5 puzzles. Luckily, most of what I did in that time was fix bugs, not create puzzles. Additionally, I remembered most of what those puzzles were, so it only took me an hour to get those recreated, and by 6AM, I had 10 puzzles ready, my goal. The next day would hold mostly aesthetic stuff.

Day Three

Goals on day three included creation of a UI, SFX, music, and a real model for the player (before I'd been using the unity capsule). My girlfriend graciously made the UI assets, and picked the font. The UI went together pretty quickly. Hint text went on most levels (though I regret the color of the text for it). After all of that, I turned toward music. I'd been having a music-writing block for a while, but I breezed through the creation of the background song for the game. It only took a little more than an hour, and mood-wise and musically I'm pretty happy with it. It seems like the rest of the people who've played the game have enjoyed it as well, so I'm pretty happy with myself for that. The SFX was kind of sketchy for me - I've never really made SFX myself before. I did what I could, and it came out usable, but not great. Anyway, it was all implemented. After that, I was done... which was weird. I had nothing else I needed to add, so I could just use it to add more content. In 2 hours I'd added 5 more rooms to the end. These puzzles tended to be pretty hard, and I'm sure very few Ludum Dare'ers will get to them, but I'm happy I added them. It was a good exercise in puzzle creation. At the very end I realized a few mistakes in collider placement on some rooms on my test playthrough, so the last 30 minutes before time ended was frantically fixing those. I fixed it with 10 minutes to spare, built, and uploaded!

Regrets

I really feel like I hit the scope I'd had in my game since early day two, was satisfied with the music, and the art. Even though it wasn't great, at least it was a particular, consistent style that I liked. The regrets are mostly in the execution. I realized early on that it was difficult to tell the placement of things in 3D space with a static camera. I kept feeling like I should do something about that, but I'd never gotten around to it, or even figuring out what it'd look like. As well, I probably should have been a lot more explicit with hints, it seems people have trouble interpreting what the player should be doing for certain puzzles, what the goal is and how to get to it.

With my progression system (opening doors), I tried to make it such that you had to continuously power the machine to open the door enough to progress. My implementation left a lot to be desired. If you squeezed through a door in a small time-frame, you could lock yourself our of the room before, a puzzle that you needed to complete to progress. I could probably consider this a bug and fix it, but at some point it kind of feels like fundamentally changing how the game works, so I won't do it for the judged version.

I probably should have also made better tutorial rooms in general. Some of the objects used to affect the ball are non-obvious until they're seen in use, even with the little text blurb I make about them. The behaviour of the ball when in free motion is non-trivial, with it being able to move at any angle. This is kind of at odds with the grid mechanic, and my graphical presentation didn't help.

The graphical presentation of the ball left a lot to be desired. Originally I just had the ball popping between locations, but that wasn't clear enough, so I lerped it between them. This was "good enough", and I thought eventually I might do something better. I got caught up in a lot of other things, and that never happened. Given the time now I'd like to properly integrate the ball's velocity and acceleration to give a smoother, more predictable appearance. You might not notice now, but the entire ball-system runs on a twice-per second tick. Living in this sort of half-space between that and smooth motion doesn't exactly work. Additionally, the ball just goes to the center of every tile. That's not great, and certain tiles would benefit from having a more particular animation. Given time I would have liked to add this.

Final Thoughts

Over this long-winded post-mortem, I might sound a bit disappointed in the game. I guess that's the nature of the format. This is actually my most successful Ludum Dare not in a large team. I made a game that's actually a... game. It has goals and satisfying gameplay, and things to do. My previous entries had one, or even none of those. I'm very happy with what I produced and I feel satisfied with it being done, unable to change it for the purposes of this jam.