Filling Furrows and Implementing Interfaces

Last fortnight has been a whirlwind! I barely even blinked since putting the final touch on the last post, yet here we are again! That said, though it happened fast, it happened efficiently I think. Shall we go over it?

Strays has been going through some serious game feel testing. We’re by no means there yet, there’s always more work to be done, but I’ve been putting a lot of time and effort into how it feels to interact with our little puppos. The movement has been tweaked again, I’ve taken a new approach to physics that essentially removes friction from the equation and relies solely on our control script to add forces, and I’ve rewritten how we grab objects with the bite to make it more consistent. The result? Visually it looks the same. But it is starting to feel a bit more together!

That’s no fun though! You don’t want me to show you another video of the same game looking exactly the same, do you? This isn’t a Call of Duty announcement trailer! So what have we done that you can actually see?

Well, a couple of very cool additions actually! You may remember in the last post I showcased the new dig mechanic? Well, I’ve taken things a step further with that feature, and we can now fill in the holes we’ve dug!

Exciting right? No? Ok then, how about this; you can also bury small items in the ground! If you put an object into the hole and bury it again, and it will take that object with it. You’ll also get a tasty chaos boost too! The kicker is that the item is now gone, it isn’t coming back, so be careful! If you can get more chaos using it another way, maybe that’s a better path to take. And who knows, you might even be able to bury it later when you’re done causing maximum chaos!

If you’ll allow me to indulge in a bit of tech babble here, I’m going to explain why I’m really pleased with this mechanic programmatically. Those of you not interested in the code feel free to skip on to the next bit, which will feature kittens!

The tech behind the dig spot I’m actually really pleased with. It uses a concept we’ve brought up a few times now, but have never really explained; interfaces.

Background for non-techies: An interface is a nifty way of allowing you to add versatile and easily replaceable code to your project. It is essentially a list of rules that a class agrees to conform to. Usually denoted with an “I” at the start (for example ICake) it tells the class that implements that interface what the rules are. For example, our ICake might have a function called GetCalories() (I’m dieting, can you tell?) which the interface declares, but does not implement. Anything that implements ICake then has a responsibility to implement GetCalories(). So a VictoriaSponge class, which implements ICake might make GetCalories() return 2000. A ChocolateCake might make it return 3500.

So why is this important? Well, to the code, it means that we can treat ChocolateCake and VictoriaSponge as an ICake, and as such, the code no longer cares which of the two it is. An Eat class will just ask for ICake.GetCalories(), and use the number returned by the function regardless of which cake it ate. This takes the code from something that looks like this:

To something like this:

In the first case, something would either pass in a ChocolateCake OR a VictoriaSponge, and we have to test to see what is eaten as one will be an empty object. However in the second instance, you pass the object in as an ICake which could be either ChocolateCake or VictoriaSponge so you don’t need to test anything or store an empty object. This scales exceptionally well, so good use of interfaces is a crucial skill to have in programming.

That was a bigger explanation that I expected, and I could honestly do a deep dive on interfaces as a topic (the above is by no means comprehensive!) But for now, that should be enough to interpret what I’m about to say.

The reason I’m so happy with the dig spots, is the way I’ve handled interaction with it. I have a DigSpotController, which keeps track of the input, and if there’s a dig related interaction in progress. Within that controller is an object of type IDigInteraction. When the user presses the dig button, the controller decides based on context what type of interaction to do. At the moment the options are to dig a hole, and to fill a hole. Internally they handle each of those tasks, and the dig controller doesn’t much care which of those tasks is ongoing, so it’s fully abstracted away. This also makes it easier to add new functionality, for example, I will need some location specific dig actions; a place you cannot dig in, a place where digging has a unique effect, or if I decide to allow unburying objects, something to handle that. All I need for each of these is a new class implementing IDigInteraction, and it will just slot in. It just needs implement the Setup, Process, FinishEarly, and IsComplete functions that the interface declares! It’s pretty darn neat!

Right! enough of this code nonsense! I promised kittens and I shall deliver! One of the highlights of my week was visiting my sister. I was running a small errand, but more importantly, I knew her cat had just had a litter! Let me tell you, I overstayed my welcome that day. I did not want to leave. And it’s easy to see why:

LOOK AT THEM! I’m dissolving all over again just looking at the picture. ‘Course, as with all kittens, soon they will be murdery balls of spikey fluff… But by the gods I will still love ’em to pieces!

Matt out.