SQYD.studio

With “Watch Out for Goblins! The Demo!” mostly finished and set to drop in just over a week, it’s a good time to think about the next steps.

WOFG! is a sizable Unity project at this point. Over 400 custom scripts, dozens of third-party assets, and integrations with many Unity tools, it’s starting to show its weight. Code quality is all over the map, there are some core systems I’m happy with, but lots of the code base is prototype code (i.e. written fast to prove the concept, not to be performant, easy to expand, or easy to understand). I’ve also learned so much since this project started. I now have a better understanding of Unity’s workflow, C#s tools and syntax, and what exactly WOFG! is trying to accomplish as a game. My friends, the time has come to refactor. 

That’s what this blog will mostly be about for the next however long it takes. I want to try to examine WOFG!’s structure as it stands and think through my decisions as I work to improve what’s already there. There are a few reasons I want to try to share this process on my public blog:

1. Slow Myself Down – I tend to write lots of code “intuitively” figuring out things one piece at a time by making the thing and seeing what works. This is good for making prototype code, not necessarily for building a maintainable long-term project. I hope blogging publicly about the process will force me to slow down, make a proper plan, and justify what I’m doing to myself.
2. Might Help – I’m a jack of many trades, but little expertise. Being self-taught (mostly), I don’t feel confident enough to provide coding tutorials, and while I believe I have some game design insight I want to wait until that’s a bit more proven before I opine on the topic. What I am an expert in is WOFG! as a project. As it stands now WOFG! has all the elements of a full and complete game, just most are a little rough around the edges. There are lots of game dev tutorials out there, for better and worse, that focus on achieving a specific effect or using this or that Unity tool. There are fewer resources on project structure and the considerations that have to be made to create a full game experience. Focusing on a refactor through the lens of project structure may be helpful for someone else on their game dev journey.   
3. Regular Updates – It’s a good way to let people know what I am working on week to week. That’s what a dev blog is supposed to do. I’m going to try to showcase as much of the process as I can. I’ll share my success and my mistakes. I’ll do my best to justify my thought process at each step and I believe we will all learn a lot along the way.    

So that’s my plan. Blog about refactoring over the next couple of months. 

Now, to set some ground rules for what to focus on while we dive into this refactoring:

1. Goblin Specific – I’m making WOFG! not another game. I’m going to fight my tendency to try to make my code generally usable for future projects. Any code that works for WOFG! is great, it doesn’t have to work for anything outside the scope of this wacky goblin game.
2. Mod Friendly – Mod support is something Joel and I have talked about quite a bit. I think it is achievable and I’m going to try to work towards it as part of this process. This will change the way the project is structured (e.g. loading from asset packs, maybe addressables?) but it also means writing clean, well-documented code that people can extend with custom scripts.
3. Performance Focused – There’s a lot more performance I can squeeze out of my custom scripts, especially when it comes to the goblin controller. There are null checks all over the place, and several components essentially check for the same thing in different ways. I’m going to re-write and restructure critical areas first- things that happen in Update()/FixedUpdate() are priority. No doubt my menu scripts have an awful code smell- but if they work and they don’t block the main thread in a meaningful way I can live with them (at least for now).
4. Embrace Unity’s Workflow – Since starting this project I’ve become a lot more comfortable with Unity’s workflow. The hierarchy, game objects, components, prefabs, etc., now make a lot of sense to me. In my early scripts it’s clear I didn’t quite understand Unity’s intent. The code works, but often in a way that overcomplicates and doesn’t take full advantage of the tools Unity gives us. I’ve also learned a lot about making custom inspectors and editor tools that will help iterate us on the project faster. Part of this process is to set up WOFG! as a Unity project that can continue to be expanded through the editor and inspector as much as possible without constantly spinning off new custom scripts.

All that to say,  the focus for this blog will be on Refactoring for the next few months. Aiming at weekly updates. Next week, I’m going to try to lay out an overview of the project and build an action plan. 

I hope sharing this process can help you structure your own project (or learn how not to), but mostly I hope this process helps me become a more deliberate game developer. Thank you for reading. 

Until next time.