My very first game, Hue Hopper is complete! I can now officially say I am a game developer. It’s definitely not a AAA title and I certainly wouldn’t charge anyone money to play it. But it wasn’t meant to be. It was meant to be a learning project. And I definitely learned a lot from it. And quite frankly, I’m really proud of myself. (Not something I say lightly.)

The downside? I’m not exactly sure how to get it so others can play it. I coded the entire thing (more on that in a moment) and I’m not sure how to export to anything other than an executable. I’ll be spending a few days researching if I can make it WebGL or something. If not, I’ll just make it available for download. Check back next week to play.

Reviewing the Process

Hue Hopper has been the result of about a month’s worth of work. That may seem like a bit much for what I actually produced. But let me explain.

For my first project, I choose to intentionally avoid the most common game engines (Unity, Unreal Engine, Godot, GameMaker, etc.). I have no problem with these tools. In fact, I plan on using them myself. But for my first project, I wanted to build it entirely using code. One, I just wanted to see if I could (I can!). And two, I really wanted to understand what’s going on behind the scenes once I do start using an engine.

If you want to see how I went about actually making the game, here are previous posts detailing the process.

What I Learned

This was a huge learning opportunity for me. And I could probably detail a ton of what I actually learned. But the largest (and probably most important) things I learned were less technical than I was expecting.

Outlining Your Game is Critical

Oh man. If there was only one thing I would advise from this project, it would be this. Creating my game design document for Hue Hopper was extremely helpful to getting things done (mostly) on time. There were two main things in particular this helped.

First, I knew exactly what I wanted to get done. Without specifying the end goal, I probably would have kept building and building the game. I know from experience that you can keep going on projects indefinitely without a clear goal in mind. But having both a target date and what features I wanted kept things fairly focused.

Second, I knew what I needed to work on and when. Setting specific days to work on certain features was actually a pretty good idea. I’ll definitely be taking that into future projects. One way I may expand on it is by also including things it may be dependent on. There were several pieces I ended up having to develop before actually working on what was intended.

I Have More Support Than Expected

Having the right support team is always important. And my family has always been supportive of me. But with this project, everyone just seemed to be on board more than usual.

In my very first blog post, I mentioned my nephew was the reason I even started getting into game development. I haven’t had the chance to see him since I’ve completed Hue Hopper. But when we got together for the holidays, he asked about the progress.

Honestly, I doubt I’ll impress him with this first game. 12 year-olds, right? Hard to impress!

My kids are younger and not quite up to video game age. But nonetheless, they asked about my progress a few times week to see what had been added. They even made the decision to get me two game development books for Christmas: Bloods, Sweat, and Pixels and The Ultimate Guide to Video Game Writing and Design.

But probably the most surprising was my wife. Game development takes a ton of time. And I already have a full time job. This meant after the kids go to bed was pretty much the only time to work. Time I would usually spend with her was instead spent coding. She was extremely patient and encouraging throughout this entire process. So much so that she even asked if we could try making something together at some point. Totally did not see that coming.

Plus she was my only play tester. Unpaid, I might add. So I guess I owe her a nice date night?

Structuring Game Code

Ok, so one technical thing. I’m a web developer professional. I’m no stranger to having clean and organized code. But developing a video game is slightly different than I’m used to. Seeing those difference and coming up with a solution how to structure the game was actually a pretty important thing.

There were several things within my code that just weren’t clean. It fits my web background and is technically “correct code”. But from a structuring standpoint, I definitely recognize several things I could do to help organize my code better. And I’ll be taking those with me into future game development projects. (From what I’ve seen, most major game engines already correct some of these issues.)

Final Thoughts on Hue Hopper

As I said, I am extremely proud of myself. Hue Hopper was a fun first game to develop. It was a great learning opportunity and while it isn’t spectacular, but it’s mine. I still have a lot to learn, but this has been a great foundation. Now I feel like I’m ready to move on to bigger projects.

So what’s next? Well, first I want to figure out how to actually make it available to play for others. So check back in a few days to see the progress. After that, I plan to spend the remainder of January working through tutorials specifically to learn Unity. Then comes my next game project. But more on that in a later post.

Categories: Dev Log