SQYD.studio

We’ve all heard the phrase: “When all you have is a hammer every problem looks like a nail”. If you somehow hadn’t, you have now. It’s pretty true in most cases- at least for me. That’s why I’ve spent a good deal of time over the last two months trying to expand my toolbox and learn some new skills.

This has led me to discover a corollary to the hammer-nail proverb (which Wikipedia tells me is called “the law of the instrument”). My new law is something like “when you get a shiny new power drill, every problem looks like a place to make a hole.” Let me tell you- I’m just barely resisting the urge to drill holds all over my scripts these days. 

Let me back up a bit. Like said in the last blog, I’ve got a clean project open in Unity 6 and I’m re-building a lot of core systems. Alongside this I’ve been toying with some new Unity tools and teaching myself some wicked new C# moves. This is dangerous. When I first discovered delegates/events I used them everywhere. Events are great, but they don’t belong everywhere. I drilled holes in my work just to flex my leet skills. After a while I had to go back and make repairs. I hope I learned my lesson. I think I did. Must say though, I’ve got a brand new drill and I’m itching to use it.

What’s the metaphorical drill? Why it’s the Unity Job System. Why block the main thread when you can break your problems into chunks and process them in parallel? I had success moving a lot of the raycasts the Goblins use for grounding into Raycast Commands and processing them as jobs between FixedUpdate and LateUpdate. It gave me small but noticeable performance improvements- and those marginal improvements have filled me with the desire to implement Jobs everywhere.

This week I started in earnest working on the new goblin character controller. While making my plan I packed all my movement information into structs so I can process them as Jobs between FixedUpdate calls. I prototyped it. It works. Listen to the power drill go “verrrrr”. Oh no.

In this case- I managed to pull myself back from the ledge. Truth is the Goblins don’t need many calculations for their movement. Running this stuff on the main thread probably won’t have a meaningful impact on performance. I’m trying to write clean and expandable code that I can maintain for the rest of the project. I don’t need to code with new systems I’m still learning. I’m wary of the unforeseen consequences. 

I’ve put the movement calculations in FixedUpdate. It’s boring and it works. I can always move them into jobs down the line if I need to. Today is a victory for level-headed practicality.  Against impulse, judgment has prevailed. Man, it feels bad- I was going to have a lot of fun drilling holes.    

P.S. – realizing I’m ending the blog on a down note. That’s all for literary effect. I’m actually pretty happy with my early character controller rework. I’m optimistic I’ll be able to get an excellent new goblin for everyone early in 2025. Happy holidays folks. I’ll blog again in the new year.