Starting is always the hardest thing. Or is it? I've always been a little bit good at starting things. Not so much dishes when they're piled up at the end of the night and the dishwasher is still clean and full. But hobbies, for sure. It's the finishing part that's next to impossible. But I had a new Chromebook for spending time on the couch, with my wife, and I had this weird, clunky, 4.0 Linux build of Godot to work with. I decided to dive into a hobby that's eluded me since I taught myself the basics of C++ and DirectX out of textbooks around 2004. 

With game programming, it's always the complicated things that bog me down until I get frustrated and quit. Everything starts to feel like a poorly designed plastic seal on the inside of a sour cream container that's only going to drive me mad and end up slathering my fingers in a nasty condiment. So when the theme for the jam was announced: Duck, Duck, Goose, I decided to go as simple as possible. It's my first game. Let's keep the scope down and have fun! I grabbed some bird assets, some underwater tiles, and an idea for a silly action game. 

I needed a protagonist to keep the player underwater for as long as possible, and I had been wanting to try out some of the free sprite creation tools that are out there. I spent a surprisingly short amount of time on Piskel making my simply animated "bad guy".

After a bit more than a week, I've got the bones of something that seems quite fun, and I spent much of yesterday getting some UI and a title screen done. It's the area where I bomb out pretty quick doing tutorials, so I made this one super quick and stuck to a lot of what I already know. Maybe there will be time to refine it over the weekend, but -- at last, I reveal my title screen!

you may notice that those are not geese butts sticking out of the water. That's right -- my placeholder has been replaced by some original artwork, and I have a protagonist. You'll have to wait for that reveal until Saturday's showcase! I've got progress bars to learn!!

Yay, welcome aboard!

Keeping it simple was definitely a good approach, I think that’s where a lot of first time jammers get into trouble but there’s plenty to learn by completing even a very small game from start to finish. And the art is looking great so far!

Note to self: remember to make a title screen…

Today was the showcase for game previews, and the reveal of Taco Meat, my protagonist. You can watch my 1 minute video here. When I watched it during the show stream (which you can see the VOD here), I was struck by how slow it looks. It truly is just a preview. There's no real challenge once you know how to swim around. I was also struck by how much I love my simple, 4 frame animation for the controllable character. I can see, given more time, having a lot of fun plugging in my own art as placeholders for future projects. Part of the reason I bought a chrome book was to get me away from my gaming rig (and, sometimes, away from Rocket League), and next to my wife on the couch while she watches TV (probably something post-apocalyptic and/or dystopian). 

I'm overwhelmed by the long weekend. I did not get much (any?) done today. I'm in a play w 3 hour rehearsals sat and sun, and woke to a killer headache after battling with trying to use the particle system until late. I watched the showcase after rehearsal and then helped my wife move a bunch of bricks. I'm brain tired and the next parts of development (fine tuning the enemies, creating the level, implementing a high score tracker, and making sound fx) are going to take time. My brain tends to not meet challenges until that time is pressing, but I also have Monday off, so I have zero dopamine to give. 

One step at a time. Tonight, I'm going to pick one thing (not something I don't need like particles!) and get it done. Maybe I start with something simple. I don't have a restart key yet! I can do that tonight!  

I finished my game late last night, and I gotta tell you - I was not prepared for how I felt.  Or how I feel. The first feeling was elation. I've struggled for a long time with this weird sense of guilt from dropping in an out of various hobbies and projects. I have a ferocity that I tend to attack things with, and that gives way as soon as I get to the boring parts. So after years and years of trying, I was just about at a point in my life where ever completing a game felt like a joke. 

This jam came along at the perfect time.  It was Godot only, small teams, and a duration that seemed perfect for my schedule. I figured - why not just submit something - even if it's a super-simple game, it will be a finished product.  Early on, I teamed up with someone else - another first time jammer. The night before the project we both had second thoughts. How will we collaborate if we don't even know how to do our own thing? How do we use github from multiple machines? Personally, I was afraid of getting stuck in a problem and holding up the timeline. 

So solo-dev it was. I started out with some rules for myself: 1 - dump anything I couldn't figure out before I went to bed each night. I did not want to waste any time on features that would never work. 2. - keep track of anything I didn't make myself the moment I download it, no matter if I was using it as a placeholder or not. 3. make a complete game, no matter how simple. 

And I did it. I made a game and I am elated. I can't wait for the judges to try it, and the feedback from friends and community members has been extremely gratifying. 

I'm also really tired and sad it's over. It feels like the post-show blues I've been getting at the end of performances since starting that hobby. It's good though. Sadness is not a disqualifying factor from doing this again. :D

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