At the beginning of August, I took part in the GMTK Game Jam. It was a 48-hour event, organized by Mark Brown of Game Maker’s Toolkit fame.
The jam started on August 5th, at 10:00 PM local time. The theme was announced to be “only one”. Now that I look back upon it, I have plenty of ideas, some inspired by other entries in the jam. However, at the time, the only one (pun not intended) I could think of was a one-bullet shooter, where you had to retrieve your projectile before you can fire again.
Before rushing head-first into starting it, I decided to sleep on the idea and see whether I will be able to come up with something better. The next morning, due to a lack of better ideas, I started work on Hyper Disk.
The idea was simple:
- The game would be a top-down shooter;
- Players had only one projectile;
- When thrown, the projectile would bounce off enemies, walls, and obstacles;
- Players would have to retrieve their projectile in order to fire it again;
- There would be three different throws available – left spin, right spin, and no spin;
- Enemies would spawn off-screen and enter the game area afterwards;
With those considerations in mind, I started working and I submitted the final jam version of Hyper Disk with a couple of hours to spare.
What Went Right?
1. Disc Physics
I quickly managed to implement the basic physics of the disc. I also had the player shoot and catch the disk consistently and without bugs in the first couple of hours. All three throw types were implemented and working as expected. The different throw options were meant to add a bit of tactical thinking to the game, as the spin of the disc would affect the bounce direction. This was an idea that came to me from playing way too many hours of 8-ball pool in high school. There were some minor tweaks I could have made to the physics materials of the walls, but overall, I believe that the disc and the way it behaves in the arena are pretty fun, despite being somewhat hard to predict at times.
2. Graphics
I used ready-made graphics by Kenney.nl and only tweaked the disc sprite to make it stand out a bit more. This allowed me to save valuable time for other aspects of the game, such as playtesting, cleaning up code, and so on. The production quality might have suffered from using those, but they turned out to be a good fit and allowed me to focus more on the design and programming aspect. That being said, I do see the value of custom graphics and if I had known that I would have a few hours to spare in the end, I would have started with custom sprites, instead of CC0 ones.
What Went Wrong?
1. Enemies
Once enemies spawn, they bee-line it for the player, with a speed lower than that of their target. That was enough for the concept of the game. However, there were two problems that I massively overlooked.
The first one was that enemies spawn just off the edge of the game area with no visible indication of that. Therefore, if the player is close to the arena’s edge and a new enemy spawns right next to them, they would be penalised without even realising why. This was, quite obviously, a frustrating issue.
The second problem is that there is only a single type of enemies. So, what spawns is an endless barrage of robotic clones that get dull and boring about five minutes into the game. Especially considering the spawn rates, players could have a single game session last several minutes and seeing the same boring zombie-like bots chase you around the tiny arena can get old very fast.
2. Disc Retrieval
Midway through development, I decided to add the option of retrieving the disc once it has been launched. In order to reward single-shot kill combos, I decided that resetting the combo multiplier on disc retrieval would make players think twice about using it. This, I believe, was a good idea.
However, in order for the disc retrieval to work without weird physics behaviours, I had to choose between one of two options. Either stop the disc dead in its tracks once the retrieve button is hit or wait for it to slow down and stop on its own before retrieval is allowed. I chose the second, which turns out to be a wrong choice, based on the feedback from various players.
3. Player Movement
The player moves via a transform.position shift, instead of through the use of their own rigidbody2D. This was a deliberate choice, in order to allow the player to pass through certain colliders that stop the enemies and the disc (penalty zones). While the penalty zones added to the complexity of the otherwise barebones rules, the choice of modifying the transform directly resulted in player movement feeling awkward and slidey, as if the player is on ice. This could have been avoided by using the player game object’s rigid body and tweaking its physics values.
Furthermore, it was not necessary to modify the transform directly in order to allow the existence of penalty zones. Using separate layers and modifying the collision matrix in the project’s settings could have achieved the same result.
Wrap-up
Overall, the main problem with this project was the lack of clear direction when starting it. This idea was the only one that I could think of at the time, which in turn meant that it was fuzzy and lacked originality. This resulted in a chaotic and slow development process, which ended with releasing a strictly average WebGL game, which failed to impress in any way. Bugs and kinks were ironed out and the game is pretty much finished in accordance with the Day 2 plan (save for the UI), but it shows no potential for further improvement and it feels flat and generic. The jam ratings only cement this point, as the game ranked just around the middle on every score criteria.
Further development of this game is highly unlikely. If it does happen, the original idea must be stripped down to the bare minimum and rebuilt from scratch, in order to make something unique and worth playing.
