I didn’t have much of a goal beyond surviving the weekend this year; last year’s event was so frustrating and demoralizing that I really wasn’t sure if I could do that. But it’s been a lot better this year than last creatively, and it turns out being in a room by yourself is less intimidating and demoralizing than being in a room full of people who are not talking to you. The game jam here is not really social, which is the opposite of what I loved about the Startup Weekend event last fall; I’ve been considering running an event of my own and adapting something closer to that format, where pitches are the first thing thrown out there, and teams form organically from the pitch process.
Having said that, I started out with a really simple notion of top-down shooter with bullet-hell-style gameplay, and I discovered at one point that it became pretty hilarious if I made it more difficult to control by adding spin anytime the player got hit. One of the things they focus on during Startup talks is “pivoting’, which is just being willing to take new information into account immediately. In this case, I saw that the spin really made the whole thing a lot more fun, so that was a big part of my focus in the end.
The final product has a bunch of problems, mainly due to constraints on my time.
- I didn’t rescale the enemies after importing the “final” graphics, so the hit boxes are too large and they end up killing themselves a lot of the time.
- enemy projectiles can kill the enemies, which isn’t an ideal mechanism
- projectile speed and rate of fire are too high which means there’s not a great “flow” to the game.
- I didn’t understand how to attach a text mesh object, which meant I couldn’t really implement a health counter for the enemies. I think that would have made the experience at least a little more coherent.
- I wasn’t really sure what to do about the player’s health. I had a notion for using a particular spot on the avatar as a “rage-up”, which would tie nicely into the spin mechanic, but I couldn’t really get it to work the way I wanted.
- There are things about Unity that are just plain bad. As an example, I implemented a method called OnCollisionEnter2d, which I thought was a standard method to detect collisions in the 2d physics system. I then spent about 2 hours debugging because the actual method name should be OnCollisionEnter2D. No errors, no warnings. Just hours of trying to figure out why my objects weren’t interacting.
There were, however, a few things I’m proud about:
- the aforementioned spin mechanism. It really throws a loop into the gameplay. I think tuning this and the projectiles would have made a huge difference
- the enemy spawning structure – having the bad guys actually force the player to keep moving by spawning right beside the player avatar works nicely
- the level-up projectiles – this was an idea I hit on pretty early; when the projectiles collide, they level up, growing larger and hitting harder as a result. It’s a very simple mechanism, but it’s visually distinct and I can see where, if it were tuned correctly, it might drive some interesting gameplay.
I wish I’d gotten a bit more time to polish it, but a lot of my time was spent learning the Unity system, particularly the 2d physics, which are pretty solid, and the resource system. I also wish I’d had a chance to implement a couple of features, including the boss encounter and level transition.
But for a first effort in an unfamiliar tool system, I’m still pretty happy with it. And it made me a Unity convert. Their system is amazing for this kind of rapid development.