Where I work, we’re always trying to find ways that can help our devs prevent burnout, have some fun, and learn some new things. One of the ways we do that is with a quarterly Hackathon. We get the opportunity to try something that we usually don’t mess around with, or just go nuts with something we’ve been curious about. The best part of the whole thing is that it does not have to be work related. It often is because we love having an extra week to fix things that we otherwise would have no time to work on, but there is also an oppotunity to just try something for fun for a week. I definitely do not take for granted how rare a thing like this is and I’m grateful to have it.
I’ve taken a few of these Hackathons to poke around a bit with game development. If you’re a software developer and a gamer there is a good chance you’ve thought about what it would be like to make your own game. I never thought I’d have the chops for it, but I learned about a nifty game engine called Godot. It’s a full featured and complex game engine, but it has a very Python-like scripting structure and prevents itself a bit friendlier than some of the other engines out there. Unity and Unreal are powerful, but the learning curve is rough and they can be very intimidating. Godot has a massive community of developers that have taken there time to create YouTube videos and tutorials that can help you get started. Having software development in my background definitely helps.
I’ve made a few games with the engine and generally I’ve been the “story guy” for each of them. Which is all well and good, but I didn’t feel like I was contributing in a way that was satisfying to me. I was told by my wonderful teammates that the story matters. Without it there isn’t a game. Which is nice, but I still wanted to contribute actual useful code. This Hackathon, I was determined to make a meaningful contribution, and this Hackathon is where it really started to work out for me.
I finally understood how some of this stuff works. The light bulb came on and I began to understand how the engine works. Not only that, I was able to contribute some meaningful, real life features to the game. I was able to do some animation, add some patrolling enemies, work out bugs, and all the other fun stuff that comes with making games. I got so into it that I even worked overtime and on the weekend to get some of the stuff done. A week is not a very long time to make a game, and without a little extra time spent, it would have never been ready for the demo day.
We ended up WINNING the Hackathon category of “best non-work related project” which was super cool to me, and the game is actually playable. It’s buggy as all get out, but it’s fun enough. It has some cool ideas in it and I’ve continued to mess with it in my free time just to see if I can make it work really well. I’m trying to follow the advice of several creators I love that say you should always finish everything, even if it sucks. There’s always some “cooler” idea that is rolling around in your head, but you do a disservice to the process by not seeing the other ones through. Plus, the game is pretty dang fun and has some cool ideas in it. Even if we just finish one level it’ll be an achievement.
I’ve since picked up an actual Godot course on Udemy and it has been a huge help. There are a ton of things we figured out, but there are much simpler ways of doing things. It makes me really want to go back and re-architect some of our game to do more sensible things. I love the YouTube videos I’ve found, but there is a huge advantage to having someone take you through making a fairly complex game from start to finish. I’ve learned a lot of little tricks I would have not been aware of otherwise.