Day 2: Time To Get Busy

So, as we last left my postmortem of my game Match Strike, I was starting day #2 with a working flight sim, for the most part. The plane could fly, and the HUD was working. I had a small bug with how the artifical horizon was rendering, but the fix was simple: I just had to fix the pitch-calculating code. Pretty basic mistake, but my sleep-hazed brain couldn't figure it out just 8 hours prior. :)

Right! So we have the basics of flight. But now what? The Match-3 concept just wasn't going to hold up. I'd need a way to select which 2 blocks to swap, and after some thought I realized that would be impossible for the rapid movements of a flight sim. I had ways around this problem, but they required a lot more coding to make work. So, I decided to swap from a match-3 game (like Candy Crush or Columns) to a simpler, more puzzler-like game called SameGame (originally Chain Shot!). In SameGame, the only action is a tap, instead of a swipe or block swap. That's easy for a plane to do at high speed, right? :)

So I implemented the blocks, just as destroyable entities. My idea for the player's gun to make it work like a hitscan weapon (and any bullets it fired would just be visual effects), which would cut down the delay the player had before a move when into practice. I also spent time making a targeting cursor, which according to feedback was quite a necessary addition.

Right, blocks are now done! Now what? Next up was making the puzzle aspect. The blocks were destroyable, but I had to make them destroy other blocks that they were touching (if they matched), and they had to move. That part I coded up rapidly, which would later end up being a rattlesnake in the grass, ready to bite me post-launch. But more on that, later!

As a further aid to the player, I also added a board-camera, which would always show the position of the blocks onscreen. I wanted this to be rendered as part of the cockpit on the plane, but never had time to come back to that concept...

What's next? Well, just shooting the puzzle block was a challenge, but I wanted more! So of course, the obvious thing: Turrets, which shoot at the player. That part didn't take long to add in.

Now what? Further challenge; Limited fuel! I already had the game loop at this point. You could fly, shoot at blocks and solve the level, and die. But another condition for dying was easy to add. I already had to write code so the game would detect you landing at the airfield, so it was easy to re-use this for refueling.

Most of the game was done at this, but I decided to juice it up. I initially recorded some audio to have a bit of extra flare, but wouldn't it be neat if all the game events had audio queues? I probably spent way too much time on this part, but by the end of Day 2, I had what I felt was a pretty solid product.

So I went to bed, feeling pretty good with my progress.

Day 3: Time To Get Moving! Time...Time...Time to Get Moving!

Last day!

The gameloop was done, and I had enough juice items to make the game interessting. So that was done. Now what? My first step was to make the random level. I decided to have five stages total, 1 through 5, where the final one would be a randomly-generated level. And I'm glad I added that, since it did give the game some re-playability.

I find the hardest part of any Ludum Dare is what I like to call the "bumpers" in a game. These would be: Transitions between levels, menu screen, and so on. This is important to really give a product a finished feel to it, but I can sometimes spend as much time writing this kind of code or designing the art, as I would the actual game itself!

I was ready to go! I tested a few builds, and was preparing to upload when -- disaster. The game crashed on exit, and I mean hard. It's the crash I discussed in this post.

Oops. But I had no time to solve this issue. On to release! Shortly afterwards, I decided to do a WebGL build and see if worked, and viola. It did, and no crash.

It was time to rest after that.

Day 4-6: Post-Compo Troubles

I was starting to see reports of the game being "glitchy" and "buggy" in the comments. Ut-oh, time to investigate! I found a lot of problems with it, particularly the WebGL version, which had broken some of the visual and audio aspects of the game.

First major problem: Keyboard bindings were becoming invalid after dying! This was due to rushed config menu code on the last day, as mentioned above. It was an easy fix.

The second major problem was that I had made an error with my valid board position detection code. It was not detecting valid moves in the final positions, which meant that sometimes the blocks would not slide properly once gaps were introduced in the board. I changed this, which resulted in fixing all the block sliding issues, but it caused the boards to generate new values. I did write separate simulation code to verify that the boards were solvable, though this isn't used in the post-compo bugfix version. (For the record, detecting solvable SameGame boards is an NP-Complete problem, so I didn't feel too bad when it could take up to tens of thousand iterations for my solver to figure it out. :grin:)

A few days later, I figured out the crash-on-exit problem. I had decided to use the new Unity Timeline Director to animate my title screen logo, and there's a problem with playing sound effects from this mode. Disabling that part, and using code to generate the sound effects, and that was fixed. The problem didn't cause any issues with playing the game, but it was nasty to see a this-app-crashed dialog every time you exited the Win64 build of the game... So glad that was solved!

What Went Right

• Solid idea for my game. I knew what I wanted, and it was easy to adapt the idea.

• Extra Juice. I spent some time juicing the game during its development, and I think that really paid off.

• Doing an open-world/open-ended level first, then the regular levels. This gave the game some replayability.

What Went Wrong

• Incorporated a lot of untested code at the end, which ended up causing crashes/bugs. Namely, the crash-on-exit (using the untested Unity Director) and keyboard-binding code (causing the game to lose keyboard bindings on death).

• Perhaps a bit too much polish, not enough meat. There was a lot of additions I wanted to add which would make the game harder and give more challenge, but I had to drop them.

• Not enough explanation of how to play. A lot of people didn't realize you could shoot the turrets and stun them, for example.

Overall, a very fun Ludum Dare! Over and out, and good luck to you all!