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!

Space Farm devlog 3

I've had a lot more free time lately due to the holidays, so I ended up getting some neat stuff done.  I also didn't stop to think about a devlog post until now, so I guess I'll put the small stuff in this post and the big stuff in another one where I can go into more detail.

I took a screenshot this time-- there's stuff to see! The green cube off in the distance is the cursor from my last post. I haven't really made any changes there, beyond tidying up the code. I tend to do a lot of writing lines in and then commenting them back out as I work through problems, so I had some discarded code to delete.

Working my way down, the cylinders are my first farm "buildings" which is the term I think I'll use to describe any structure the player places in the world, e.g. chests, machines, decorations. Right now these guys don't really do anything, but the player can put them down under the cursor by clicking.

The little brown squares are my dirt blocks. They have a few booleans on them to control plant growth-- whether or not the dirt has been tilled, if the block has been watered, and if it currently has a plant in it. Using the mattock, which I'll cover more in my next post, the player can click an empty space to spawn a dirt block, and then click the dirt block to till it. The player can also plant a seed in tilled dirt, and then water it (again, more on those tools in the next post). It sounds a lot fancier than it is, really-- just a bunch of if statements. I also got the game object to change materials when tilled, which really tickles my fancy for some reason.

Finally we come to the plants themselves. Here's where things get fun-- the plant class has an enum for growth stages, and each growth stage can have its own timer for how long to spend in that stage. In other words, my plants will visibly grow through multiple different stages! Right now I'm just scaling a capsule mesh, but in the future I'm expecting to swap out models as they grow. I might also add different requirements for the stages, like needing to be pollinated, fertilized, weeded, etc. We'll see how the design goes.

Space Farm devlog 2

Welcome back!  I have more Space Farm updates.  To help you navigate these posts, I've added a "space farm" tag that should bring up anything related to this project.  I'll try to add other useful tags as I go, especially whenever I include code snippets.

As I might have mentioned in the last post, this time around I worked on letting the player interact with the game world.  Since I don't really have a clear plan for the gameplay just yet, I figured a cursor might be a good start.  I created something similar in a tower defense prototype in GM, so I had already worked out some of the logic at some point in the past and felt it should be possible to make again.  Seems reasonable enough, right?

So I started with simply spawning an object called "cursor" on the map.  Like everything else in this game so far, it's a cube.  I put a translucent green material on it so it'd stand out a little better.  Life was good.

And then I tried to make it follow the mouse.  This was... not as easy.  As I'm sure I'll state a million times in this devlog, I'm not super familiar with cameras, especially in a 3D space.  So translating from screen coordinates to world location wasn't intuitive for me.  I've written the kinda code where it works but I'm not really sure how-- Unity's "screen to world point" function got me most of the way, but I needed to add some funky-looking math to adjust the received value to account for the camera angle.  Without this adjustment, the cursor would float off the ground near the top of the screen, but sink through the floor near the bottom of the screen.

After correcting this, I decided to go ahead and lock the cursor's movement to a grid, as well.  I figured one of the first player actions I'll add is placing things in the world, and as a player I always appreciate a placement grid so I can plop things down all willy-nilly and have it still look decent.  This should also theoretically make things easier to program later, as I won't have to deal with detecting multiple objects under the cursor when the player clicks.  The design document for this project is still pretty bare-bones, so I might change this later.

Even with all the Googling, I'm having fun.  I think next I'll start on the farming tools.  It's kinda hard to have a farming game without the part where you grow plants, after all!

Space Farm devlog 1

Howdy, internet people!  I've started a new game project, which I will call Space Farm until I come up with a real name.  If that working title isn't descriptive enough, Space Farm is a farming game set in space.  That's the bulk of the design document at the moment, to be honest.

I'll start keeping track of my progress here on my blog, partly to share with y'all and partly for my own convenience.  I'm a habitual note-taker and have found some of my old posts to be consistently helpful as I worked on GameMaker and Unreal Engine games-- hopefully this devlog will do the same as I get started in Unity.

A quick note on engine choice-- although I have a fair bit of experience in GameMaker, my last couple attempts at a project felt hindered by the development environment it provides.  I really wanted to start using the scripts feature as much as possible to make the code more modular/ reusable, but they didn't give me the level of control (or maybe flexibility?) I expected.  And so I tried UE4 for a while.  It seemed like it ought to have been a good fit considering how much I had played with UDK in school, but it just felt too heavy for this dinky little farming game.  Unity and C#, which I haven't really used before, will be my weapon of choice.  At least for now.

Ok, that's enough of a preamble-- let's get to what I've gotten done.  For this work session, I kept things simple so I wouldn't get overwhelmed by the switch to Unity.  First, and perhaps most importantly, I set myself up a repository I can save all my work to.  Right now it's just saving a copy onto another HDD on my computer, but since this machine likes to kill itself about once a year, I'll be considering better locations soon.

Second, I implemented a simple 2.5D camera and movement system.  Cameras are still kinda foreign to me after spending so long with GameMaker, so I had to do some Googling.  Some nice person on the internet had already posted their solution to exactly what I wanted, which might have helped a little too much, but got me up and running.  You can now move around the world in eight directions with the camera keeping you centered on the screen.  Fancy!

I went ahead and added some "dirt blocks" to the scene for fun.  They don't really do anything yet, but it's starting to look like something now.

That's all for now.  Like I said, trying to keep it simple at the start.  Next on my task list is interacting with the world, so that ought to be a little more complicated.