Game Dev Blog #11: The Pareto Principle

This entry is part 12 of 13 in the series EDX CS50G Game Dev Course Final Project

The last blog entry wasn’t the penultimate blog entry for the “Final Project” after all.

3 Achievements

  1. Visual changes: I’ve updated a bunch of screens and replaced fonts, so that things are more readible. I also changed the resolution of the game to be closer to the action. I’d been going back and forth with what resolution to make the game, but I think I’m now happy with the lower resolution feel (at least for the version I’m submitting for the course project)
  2. Bug squashing: I’ve spent most of the weekend trying to squash final bugs that cause weird behaviours with ledge climbing, as well as the monster rats not behaving properly when attacking and chasing, often just throwing themselves off ledges to their doom. It’s kinda funny, and I do want an element of that when they chase you and you jump off a ledge, but they shouldn’t be doing it when you’re ledge grabbing!
  3. A new name: I couldn’t keep calling it “Final Project”, so I updated the start screen with the name “CAVE DESCENT” – Bear in mind that all the code I’m writing will be part of planned releasable game one day, but “Cave Descent” is just the name for this more basic course project version, and not what the final game will be called.

2 Things Learned

  1. Pareto Principle strikes again! Fighting the remaining bugs has reminded me of the Pareto Principle. The final 20% of the project takes 80% of the time. That’s what this weekend has felt like, so close to finishing the code, but these bugs have really dragged things out.
  2. Hacks to make things work = more bugs! Up until this weekend I’d been trying to write well structured code, to set myself up for the bigger project I have planned. But, the closer I got to my deadline, the more I’ve started to hack the code a bit, just to make things work. But in doing so I’m introducing mess, which is leading to more bugs popping up, and then more hacks to fix those. It’s mostly around state changes and how one entity can affect the state of another. Anyway, once I submit this project I’ll go back with a fine-toothed comb and look at where I could improve the structure and remove any hacky code I’ve added.

1 Thing Coming Up

I have finally finished the coding for the version I intend to submit, so now it’s the documentation and video to go with it, and then submit and hope that it passes! I may do a retrospective blog post once I get my grade, and then I’ll pivot into preparing the code (and itch.io page) for the “proper” game.

Series Navigation<< Game Dev Blog #10: Enemies and backgroundsGame Dev Blog #12: Game and course complete! >>

category:

Game Development

Tags:

No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *

Series

Recent posts

Categories

Latest Comments