Final Devlog for Duck, Duck! It's a Goose!
Tomorrow's the award stream and we wrap up this little journey of 2 and a half weeks. I've taken some time today to review some of my code. It's the first time I've opened it since fixing a large bug after submission. I opened up a doc and took some notes - mostly on my player object's script, and here are some things I noticed.
First -- and I knew this was happening while it was happening -- this junk is so spaghetti. Rushed for time, I hard coded variables in. I made calls to the singleton (and back) just to make things work in a hurry. It's sloppy and needs a lot of cleaning up to work with it again. I can also see my lack of experience in coding show through. I have many instances where a function takes care of some things that were already done in the process function. Many other lines are repeated in the process function. The best example is turning on and off the collisions based on the direction the player is swimming. There's no reason for this to happen any more than once per tick, and it was best be suited in it's own function because of that. I think. And that's what I mean - I don't really know. This makes sense to me:
Is the player moving left or right? Is the player swimming down? Great. Hey collision function, we've answered these questions. Can you turn on a particular collision accordingly and make sure the rest are off?
Second - I'm not customization friendly on a lot of fronts. I have a node for the main music loop of the game. It's attached to the player, which honestly is fine. The player's driving the game, so when they die, their music should die with them. But why a node, and not an export variable? It seems better that the level designer can pick which track plays quickly, especially if I ever wanted to do different biomes or level types. My only guess as to why I did that is that I have never really gotten as far as sound in my games. I usually quit tutorials before then, and my own projects definitely never make it that far.
Speaking of music, the sound of the fish jaws (a Zippo lighter) is attached to the player and not whatever enemy jaws are happening. It's fine. It worked just fine. But it means the player is figuring out what hit it and then making that thing make noise. Seems like a good way to be not scalable. What if I want a level with miniature submarines + 50 other things that don't belong in a duck pond? Will I group all of them and then hard code their sounds into the player? That's nuts.
Lastly, for now: I want more empty nodes when I get crazy with things like collision shapes. Like just for organizational purposes. This looks ugly:
So anywho, I am planning on skimming through the rest of my project, making notes, and refactoring a ton. I want to see if I can manage to do that without breaking it. And then, maybe, I'll get around to those dead fish powerups and scoreboard interactions I wanted from the start. Thanks for reading and showing up for this event. It's been life changing. Truly. <3