1 Game a Week – Week 9

I’m going to make this a short post-mortem, since there isn’t really a lot I have to say about the game itself. I also want to immediately get started on my next game, so let’s get right into it.

I started the week wanting to make a platformer again. I haven’t tried to make a platformer since Week 1, and all I really managed to get done was a basic collision system and floaty controls. I wanted to do better this time around, with a player character that feels weighty and a simpler implementation.

I struggled with the collision code again for a few days, but I managed to get a simple tilemap collision algorithm implemented that worked for my purposes. I then spent a day tweaking the player character controller parameters, adding in acceleration and deceleration values, jump gravity and coyote time. At this point in the project, it was possible to do very basic platforming. However, I wasn’t quite sure what I wanted to make now that I had a simple platformer system implemented. This was on Thursday.

The next 3 days was a blur of trying out random ideas and just trying to get something working. I thought it would be cool to have to fight a dragon enemy, something I’ve wanted to implement in a game for a few years (I even made a prototype few years ago). I added the enemy on a fixed track, and made it shoot projectiles at the player if the player is in line of sight. The player can then hit the projectiles back at the dragon to hurt it. Once the dragon is dead, the path to the dragon’s lair opens up and the player wins the game. Fairly simple premise.

Death animation (and the best part of the game tbh)

Honestly, I ran out of time and energy on Sunday, and the second to second gameplay wasn’t fun. So early in the day, I decided to just stop working on this project. I think that was the right decision, there was very little to gain to push myself much harder.

What went well

  • I was able to use knowledge I’d learned in previous prototypes to make this game. Specifically Week 1’s collision system was simplified and updated for this game. Week 7’s bezier train system was also adapted for the dragon path.
  • I learned how to implement a lot of smaller features, such as having the Camera pan to the room that the player is in. Line of sight raycasting on a tilemap. A wipe effect for reloading the game scene. Hurtboxes and Hitboxes. Very common features in games that will let me prototype faster in the future!
  • The player character is fun to control. Even though mechanically it’s the most basic platformer controls possible, I think adding the squash and stretch, plus tweaking the physics values showed me how important ‘feel’ is to make a game enjoyable.

What could have gone better

  • The game structure ended up being a total mess. The combat wasn’t fun, and I didn’t have the time to redo it.
  • I made a mistake with the dragon implementation. Every segment is on the bezier track, and follows a set distance behind the next segment. It would have been better to have a “target” on the bezier curve, and have the dragon physically follow the target, with each segment following the next segment. This would have allowed me to dynamically remove and add segments like a linked list, so that the dragon’s total length gets smaller the more the segments are destroyed by the player.
  • I spent too much time on polishing certain features instead of getting the game to a very simple beatable state, and then polishing from there. For example, I spent a few hours polishing the death animation when really I should have been getting the core gameplay to a workable state.

What I learned

  • Getting the core gameplay working early is essential. It’s something I’ve messed up on with every game I’ve made so far. I think I spend too much time early in the week trying to figure out what I’m going to build, then I make a quick decision mid-week and rush to get something done over the weekend. It’s an unsustainable way of making these prototypes and I’m going to now force myself to have the game beatable by Wednesday, so I can polish and tweak it over Thursday and Friday. No more weekends.
  • I find it very difficult to implement something when I don’t have a clear design or goal in my head. When I knew I wanted to make the death animation, it was very easy for me to focus and get that working. I had a lot of fun with it too. But if I’m not entirely sure what the design is, I tend to procrastinate and get stressed. I think I need to spend less time doing up-front design on the larger systems, and just let myself build things as I code the prototype. The code will end up a mess, but that’s ok, since the code base for these games will only be worked on for a week anyway.

Summary

The game I made this week was just plain bad and unfinished. But I learned a lot of lessons from it. I’m going to change my approach to making games from now on, with a focus on getting the core gameplay loop working early in the week, and polish, tweaking and art on Thursday and Friday.

It wasn’t until I watched Mark Brown’s video on his own game development journey that I realised I haven’t been focused on making sure the game’s design is actually sound before trying to polish it. For my next game, that’s exactly what I’m going to do. I hope it turns out better than this one.

The Game Design needs to be good first, otherwise everything else is wasted effort.
Image by Mark Brown at Game Maker’s Toolkit.

As always, if you want to try out the game (I’m sorry in advance), the link is right here:

1GAW – Week 9

Unfinished platformer boss prototype

Available now to play on your browser

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

One thought on “1 Game a Week – Week 9

Leave a comment