Space Farm devlog 4

Alrighty, time to share some more details about how I've been structuring my code.  As mentioned in the last post, I've recently added in a few tools the player can use.  I'm kinda excited about the way they're implemented, so first I'll cover the tools themselves, and then I'll describe their current implementation now that I've refactored a bit.  Disclaimer-- this feels pretty clever right now, but I'm more than willing to admit that it's an experiment that I might scrap for something better later on.

Tools!  What is a farmer without farming tools?  Right now I have a mattock, a watering can, and seed bags.  The mattock will be a multi-purpose tool covering digging, tilling, and chopping.  The watering can is, well, a watering can.  And the seed bag currently lets you plant an unlimited number of my generic testing plant, but in the future will come in a variety of species and max seed counts.

Ok, the tools themselves aren't super exciting.  But maybe the way I've coded them will be.  As seems to be standard practice for Unity, I have a player controller class.  Right now, this class handles all the button presses.  I currently have three tools, which means three unique functions.  But wait, I've already mentioned that some of the tools, like the mattock, will have different uses depending on what they're getting used on.  This could easily turn into a lot of different functions.  Cramming them all into the player controller would be a nightmare, and putting all the different uses for each tool into the tool's own code would be multiple smaller nightmares.

I've chosen option three: have the objects you act on be the ones holding code for what to do when they are clicked on.  I'll admit it, when I write it out like this it sounds more like a bunch of tiny nightmares scattered across my entire code base.  To try to prevent it from getting out of hand, I've started trying to keep the different classes to a minimum, but give each one a lot of options that can be used when making a prefab to create the unique game objects.

To illustrate, here's what happens if you click on a dirt pile with the watering can equipped: the player controller detects the click, and then tells the dirt pile you've clicked on to run its "get hit with the watering can" function.  The dirt block checks to see if it already has its "I've been watered" boolean set to true, and if not, it sets it to true.  If there's a plant attached to the dirt pile, it will be told about this new update to its watered status so it can start growing.  Essentially, the player's click was passed through every game object connected to the place they clicked on, and anything hit took care of managing its own reaction.

It can get a little hairy trying to track down the path an input takes (or is supposed to take but didn't!) but so far this method has been more help than harm.  I guess over time I'll get to see if my opinion changes!