Game Development

Blog 581: No Excuses

It’s 2014 and I’m going to make a real computer game.

No excuses. No pussy-footing around, no putting it off, no procrastination. This is it.

The Pre-Crimbo Rush

Naturally the festive season is the most productive time of the year, so I used it to smash a little difficulty I had been having with unit movement. Unit movement is a fundamental factor upon which the entire project hinges, so it kind out counts as the bottom of the stack.

Now, the six-day prototype created during the summer of 2013 as a feasibility study had movement, sure enough, but that was cobbled together from found scripts rather than hand-crafted. It was mostly fine but had some odd behaviours, like how pushing a physics-based crate could catapult the player mech into the sky, and juddery movement going down slopes. Because of the large and complicated nature of said found scripts, I didn’t understand enough to dive in and adjust them.

So I decided to make my own from the ground up. Yes, I answered fear of existing complexity with reinventing the wheel. That’s just… how I roll.

Move Along

It’s actually simpler than you might expect to make things, specifically characters, move. Unity provides a built-in CharacterController component that handles a lot of nasty stuff like going up slopes and steps; all you actually need to do is push the thing around and worry about gravity.

Of course, when I rolled my own I ended up with even worse judder problems than the found scripts.

It turns out that, even when the CharacterController is moving along a surface, you still have to apply downward force. You don’t just push horizontally as one might expect (why apply gravity when you don’t need to?), you always have to push down.

It makes sense when you find out why: the way the CharacterController knows if it’s on the ground or not is based on it colliding with the ground, and collisions naturally push back a tiny bit from the thing they hit. In the case of moving along the ground, frame-by-frame it jumps into the air from the collision, gets gravity and falls, hits the ground and then jumps again — unless you always apply gravity. (I actually apply a constant force in this case so it is guaranteed to stick to the ground even on fairly steep slopes: I want WC3-style movement but in true 3D space, so sue me.)

So that got horizontal movement out the way.

2edgy4u

It didn’t solve my problems with going over edges, though. I knew conceptually what I wanted to do — if you drive over an edge, you should fly off rather than awkwardly clinging to the “ground” of the lip. The problem was that, because the collisions are done with a capsule that has a rounded bottom, even if the tip has left the ground the… buttocks?… haven’t and you can still sort of judder along. Nasty.

I’d like to say the answer came to me on the toilet, but it was another of those pseudo-sleepless nights. It’s all about sliding.

Obviously in WC3-land there’s a lot of sliding: “knockback” has always been the most fashionable triggered effect. Believing this was fluff rather than an integral part of movement, I didn’t want to add in that kind of mechanic too early: I wanted the basics to be down solid before going nuts.

Sliding, however, provided the answer. Sliding through the air, to be precise.

Running over the edge, we know when the CharacterController leaves the ground. At that point, we take whatever movement vector it had and hang onto it. Even while the player has now let go of the move button, the unit throws itself nicely over the edge — neatly avoiding getting caught on it. (Might be janky for larger/slower-moving units but we can leave that for now… As long as it’s moving fast enough for the curve of its capsule’s buttocks, I guess.) Throw on some gravity and some natural deceleration and our hapless unit describes a gentle curve into the void.

Success! And the bonus is that, having built it for myself, I fully understand what’s going on (quaternion mathemagic aside, but let’s not worry our pretty little heads about that).

Tool Support

While the main bulk of the game is nice solid stuff that exists in the game world, I’m going to have a whole host of more abstract elements like computer screens, keypads and conversation trees. All that stuff has to go somewhere.

So I am writing my own development kit, natch.

However, the beginnings of this WinForms GUI has actually been some considerable work on LoneWiki. As a personal wiki has been extremely useful for tracking novelisation projects, so too is it beginning to harness the mythos of this newborn space fantasy epic.

But I don’t want a collection of stand-alone tools, though, no sirree. I want one solid environment. I’ll always have to work between Unity, Visual Studio, Milkshape, Paint Shop Pro and this toolkit, so I don’t want to have any more windows to juggle than that — which means that I need to integrate a LoneWiki instance…

Obviously Past Robbie has a lot to answer for. A monolithic UI class, where everything is smeared across a single WinForms form, is not suitable for integration anywhere but the recycle bin. However, there are plenty of component parts in there — the viewport and the editor can be split into custom controls, those can be packaged under one LoneWikiBrowser control that slots into the parent form…

It’s still a hideous mess, but it’s a start. (Theoretically, when I release the next version of LoneWiki, anyone will be able to include a reference to the EXE and integrate LoneWiki into their own tools too!)

There will be more tabs than this in the end. Did I mention it's also an integrated SVN client?
There will be more tabs than this in the end. Did I mention it’s also an integrated SVN client?

I also expect this tool to play a part in at least arranging game elements — unit types and weapon stats will feel more conveniently editable with a dedicated UI, either by auto-generating stuff from meaningful tables or directly fiddling with the prefabs created in the Unity editor. Or constructing things at run-time from meaningful tables. Something like that.

… Whatever Warcraft 3 does, okay? That’s the core of my experience so it’s only natural.

Alas, you playas will never see this thing. The nature of Unity seems to preclude modding; at least, not without me building my own level editor on top of it. I’m not even going to consider that kettle o’ fish. Maybe once I’m further down the line, though, people might want to join the fun developing official scenarios…

Ach, let’s not get ahead of ourselves. I don’t even have a studio name yet.

4 thoughts on “Blog 581: No Excuses”

  1. I think its due to my immaturity, but I cracked up when the little arrow thingy drove its self off the platform after your arrow thingy blocked it.

    Like

  2. Sliding? RDZ, you’re missing an oppertunity here: players hitting their undersides, their forward momentum dragging them on, slowling tilting forward…
    …spinning their way downward, landing with their feet up in the air 🙂

    Like

    1. I wanted to make units turn into physics objects when they get knocked off their feet, so they’d roll around and bounce off stuff, but I’d have to set up ragdolls and weird physics stuff I don’t understand. At the moment I’m just thinking “if WC3 didn’t have it, I don’t need it (yet)”.

      Like

And you tell me...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.