Creation Commences and Multitasking Manifests

The first real leg of development has finally begun, Strays is underway! I’ve had to wear a lot of hats already, but I’m feeling positive! Shall we take a look under the hood and see what we’ve been up to?

Before I dive into it, if you’re new to the blog or have missed recent posts, and find yourself wondering, “What even is a Strays?” then I recommend you check out last fortnight’s blog. I give an overview and there’s even a fun little announcement video if you are visually inclined! Enjoy!

As is always the way with any new project, the first step was a lot of thinking. Gameplay ideas, story concepts, multiplayer integration, that sort of thing. Primarily, we focussed on what we would want to see in a fully realised demo. With that in mind I set to work detailing out some elements that will add some gameplay to the world. The result is this hard to make out image here:

Not to worry if you can’t make out the details, I have a plan to put out a video going over creating this patchwork that should be with you guys soon!

With some ideas on (metaphorical) paper, it was time to set to work. Naturally in Unity, the first step was to get something moving. But what? Well without assets you’ll often end up with a very similar looking starting point:

In a more traditional game, this would often be an upright capsule, rather than the box on its side you see in the video. That’s because we’re using a quadruped, a dog, as our base. Most characters are human (or human adjacent) so a taller, less directional capsule is used by default. The sphere at the front is to give me some idea of direction.

John set up some spawning code and got a basic implementation of two player controls working so we have two players in the scene, which put us in a good starting position. Well, sort of. See, the problem is that we want to use physics for a lot of the features of the game, and the basic movement I set up, though snappy, didn’t synergise well with the idea of using physics to drive everything; colliding with a box with any sort of mass, for example, would have no impact on your speed, the box just moved out of the way:

Not ideal, so I had to rewrite the movement code to use AddForce and AddTorque instead of just setting the velocity – which is what I had been doing so far.

Background for non-techies: So as GSCE physics may have taught you velocity is the rate that something is moving and the direction it moves in. In games programming, it’s usually a 3D vector that represents some manner of Units per Second in X, Y and Z. If we set the velocity of an object, it will start moving at that speed in the direction we specify.

Now Unity is pretty clever, and the inbuilt physics engine will then use friction and drag and all manner of effectors to manage that velocity. The result being that, generally, if you set a velocity once, you will move a bit, but be dragged to a halt by the friction of whatever surface your object is on.

This is fine, as the most basic movement code sets your velocity based on input every frame, and if you let go, you will stop moving, no additional code needed. The problem is, that the velocity is being set regardless of whatever you are pushing against. So if you are pushing against something that can also move, it will act as though you have unlimited pushing power, because even if it tries to stop you, by reducing your velocity, you just set the velocity again next frame.

This is where the AddForce and AddTorque functions come into play. These allow you to apply an amount of velocity every frame, essentially providing an acceleration force, that doesn’t just ignore any forces acting upon the player; it takes them into account. This means if you push into a heavy block, you are slowed by it, but if it’s light enough you can still push it slowly. AddForce is essentially movement, and AddTorque is rotation. Rotation is a whole other beast that I’ll spare you the details of this time…

This took a little while and I got bored of seeing a capsule halfway through development, so I found a free low-poly dog model to use instead. You may have already caught this on socials, but things didn’t initially go to plan, per se:

Not what I was looking for, but good for a giggle! I got there in the end thankfully and eventually we achieved dogs that could move around in a way that followed the laws of physics… mostly. Next on my list was to add the bite mechanic, so we could chomp on an object and drag it around, as well as just push it! This wasn’t too complicated, just creating a physics joint between the object we’re biting and the jaw of our dog model and removing it when you let go of the bite button. It’ll need more work, but as a starting point, we’re most of the way there.

At this point I needed something different to do, so I turned my mind to that most daunting of beasts for me, 3D modelling. With the help of a course I picked up on Humble over Christmas, I started learning the basics and pretty soon I had some objects up and ready to roll:

Nothing too fancy, but enough that things are starting to look a little less “generic Unity startup”-y! And this is how it all looks in Unity at the moment:

For the first real sprint on this project I think we’ve done alright. I’m ramping back up to speed after a prolonged Christmas and New Year break, getting the old work ethic back, and I’m excited to get moving and keep you all abreast of development!

Matt out.