At this point, a 2-month recap would read something like, “I failed. a lot.”
It felt sorta like when you’ve been driving down a road for hours and you suddenly realize you’ve been going the wrong direction the entire time. I’m all about seeing failures as lessons, but the only thing you even learn from a failure like that is “Don’t do that.”
But luckily, I don’t have to talk about all that because this is the last devlog of the year, and you know what that means (I know you don’t but I said it anyway)…
It’s time! [drum roll] for the 2018 1st Annual Stonewood Games YEARLY Recap, so buckle up, bitches!
-Sorry, I don’t know why I called you bitches. You’re lovely people, I’m sure.
So, anyway, let’s put the cap back on this year’s recaps:
Made a bunch of concept models
Prototyped modular NPC system
Created biome-specific random object spawner (now completely replaced by noise-based version)
Built an over-complicated Day/Night Cycle System (also obsolete)
Layered Weather System w/ floods/droughts (Keeping some of this one, but will mostly be updated/replaced)
Made a pretty robust modular AI behaviour system
Wow. looking back is pretty informative. look at all the work I did that just got replaced later. Of course, I could’ve never got to the replaced version without first building these versions, but it’s useful to observe these types of things.
This is when I really started managing myself. I Started framing all my workload into 2-week sprints and keeping detailed information about.. basically everything. I also started utilizing MUCH better coding & backup habits.
As a result, my efficiency increased exponentially and I started getting WAY more stuff done.
During this time I built:
3rd-Person Camera Controller
Object Pooling System
upgraded AI Systems
This is why management techniques are a thing. It may just seem like extra work in the beginning, but in the long run, it’s quite the opposite.
(Granted, this was a 3-month recap instead of the usual 2, but it was during the summer, which means I was spending a lot more time with my kids and a lot less time working.)
Object spawner (noise-based)
Volumetric Cloud System
So that’s essentially what I spent the last year of my life doing, which ain’t too shabby, if I do say so myself.
Why Visual Scripting?
Most recently, I decided it’d be worth my while to upgrade and start using Unity 2018 which resulted in a small chain of events that has revamped my entire workflow.
Not long ago, I picked up a visual scripting tool called FlowCanvas (in the humble bundle where everyone picked up a copy of FlowCanvas). I loaded it up and rebuilt one of my simpler scripts with it, just to try it out. My thoughts were, “That’s pretty cool, but I can type this out WAY faster than I can do it visually”, and I figured I wouldn’t use it again, except maybe in some random specific use case…
Well, with the Unity 2018 upgrade comes Shader Graph, another visual scripting tool, only this one makes shaders. When it comes to writing shaders, I am lost. I have tried and tried to learn to write shaders to no avail. But the visual style of Shader Graph makes shader creation a breeze. All of the sudden, I can make shaders–basically equivalent to finding out you have a super power you didn’t know about.
This got me thinking about FlowCanvas again, so I decided to give it another chance. I rebuilt some more-complicated scripts and instantly saw numerous benefits in using the visual style. I was able to wrap my mind around the ‘bigger picture’ of complex systems which makes things MUCH more manageable (especially useful for a solo dev). Immediately, I found several errors, from small variable changes to higher level stuff like incorrectly coupled functions, which, consequently, were extremely quick & easy to decouple/refactor thanks to FlowCanvas.
Visual scripting also makes solving bugs MUCH easier as you can literally just look and see exactly where it’s going wrong. It also encourages experimentation because of how quickly you can just plug something up on the side, just to see what happens, without worrying about accidentally messing up something important.
While I suspect I’ll get faster with time, creating a flow map still takes quite a bit longer than just typing up some C#, but in the long run it actually saves a ton of time because of the aforementioned points.
I kind of always viewed visual scripting as a cheap shortcut for people who were too lazy to learn code. But now I’m not sure how well visual-scripting would actually work for someone who didn’t already have a good deal of programming knowledge. But I think, somewhat counter-intuitively, that maybe that’s not the point.
So anyway, I plan to try out a visual-based workflow and see if it doesn’t increase my productivity.
I’ll let ya know how it goes.