Fixing the Movement System

My problem with my movement system was that it did not take detours around obstacles into account.

Here’s another example:

The path up the mountain should be included in the movement range, but how would that be calculated?

And here I was trying to calculate such things, with a brute-force experiment (see post):

The brute force approach to include detours in the movement range was inefficient.

It looks ugly and takes something like 10 seconds to compute.

I realized that to do what I want, I will really have to put a grid in the map. But the idea is that grid will only be used for calculating move range. Characters will still not move by the grid.

So here’s the grid:

So with this, I can run a plethora of algorithms for calculating paths.

Now what I did, was to use Dijkstra’s algorithm without specifying an end goal. So I’m letting it run on all directions, but imposing a limit on how much squares it can go to.

It’s similar to displaying the movement range in square grids of games like this:

It’s sort of like doing a flood-fill. But here I need to take into account the slope of terrain: steeper angles cost more to move. And with Dijkstra’s algorithm, it was easy to put that in.

So what I get is this:

But now that I’m using a proper pathfinding algorithm, it will take obstacles into account properly.

For example, this is my movement range in top view. If you add an obstacle (like a building) within the perimeter, the movement range will adapt properly.

My next step was to collect all those points and connect them to each other, forming the perimeter:

Now obviously, it’s looking ugly. The curves are jagged. So the next step was to apply some sort of smoothing to the points’ x,y,z positions.

And then we get this:

Which is quite nice and exactly what I want.

All I’m doing here is a simple average (i.e. mean) filter: for each point, you average its x,y,z position, and that of the point next to it, and the one before it.

Now actually, I’m applying the filter 4 times, to get a good smoothened out look.

For comparison, here’s the top view of the unsmoothed border:

And here it is, smoothed:

And here it is, super-imposed:

It follows the original path fairly well.

And as a nice bonus to all of this: it takes about 0.1 seconds to compute this movement range, so it really is far better than my old code.

As a final comparison, here’s what it looks like before and after:

W.U. Dragurian Colony Soldier Textured

Its been one year since I drew that sketch! I finally finished the 3d model.

Welcome Distraction: Serin’s Creed

Weekly Updates 23 and 24 were spent on a spin-off idea for Victis.

In the small game development studio I work on, I lobbied for what we call “Free Friday” where, in every first Friday of every month, for the whole of that Friday, we’re allowed to make whatever videogame concoctions we can think of.

This is our excuse to make time doing those crazy ideas we get from time to time.

This is also to de-stress (as I like to call it “detoxifying”) from being full of client work. That is, work where we create a videogame for a client, per her/his instructions, leaving little room for creative ideas.

The catch with this Free Friday, is we have to start with a blank slate every time, and make sure we have something presentable at the end of the day. Think of it as a short informal game jam.

So for the November Free Friday I thought of making this idea I had one time before I went to bed:

“Damnit I want to play Assassin’s Creed right now on my Android tablet!”

That’s pretty much the basic gist of it. I wasn’t able to have much by the end of the Free Friday so I took the weekend and the weekend after that continuing on it.

Here’s what I’ve ended up with so far:

I’ve detailed more of it in my personal blog here: Battle Maiden Part 1

How is this related to Victis

The player character in that little experiment is a Battle Maiden.

I wanted Victis to draw (loosely) on Überwald-esque dark fantasy, and that included gypsies.

Through some athletic feats of cognition, my train of thought arrived at pistol-weilding, dancing, acrobatic gypsies, that right now I’m calling “Battle Maidens” until I figure out a better name.

The idea of acrobatic, one-man army, free-flowing gameplay that Assassin’s Creed and Batman: Arkham Asylum had, fit well with Battle Maidens, so that’s the graphics I used for this Free Friday game.

Duplicate Materials Problem

From 10 draw calls:

I was able to reduce it to 6 draw calls.

Considering there can be about 30 to 35 characters on screen, this was a big reduction.

Normal Map Problems in Blender

Normal map baking in Blender is very simple and straightforward but there are numerous pitfalls that are not apparent to the user that can make things broken.

No objects or images found to bake to

Generally speaking, if either of the high-poly object or the low-poly object you are baking to are set as not renderable, Blender can’t find it and thus, can’t bake anything. To make objects not renderable, there are many ways to do so:

1. Set it as invisible from the Outliner
2. Have either objects in a layer that isn’t set to be rendered. In the Render tab, there’s a section named “Layers”. That determines which layers will be rendered.

It doesn’t make sense to me at all that normal map baking has to depend on these things as if we’re rendering to a movie file.

The other possible reason is if the low-poly object doesn’t have an image assigned to it. From my experience you can just create a new image from Blender, assign it to the low-poly’s UVs, and you don’t even need to save it yet. That is enough to make normal map baking to work.

Overlapping UVs

Take care when baking into objects that have overlapping UVs. If you have a head whose UVs’ left side is mirrored to its right side, this can cause the baking to overlap as well.

Here, the objects have multiple copies, thus, it made sense for me to simply make them use the same UV space. I was baking the high-poly object you see in the bottommost copy of that object.

However, the normal map baking produced those lines you can see in the left side of the screenshot. Again, this is because the UVs are overlapping.

What I did, was to temporarily set aside the UVs of all the other copies of the object:

Then bake again. This will produce a clean result like the screenshot below. Then simply move the UVs back to their original positions.

Flipped Normal Maps

Things looked fine until I saw my object up close:

The left side of my character’s armor seems to be flipped from the right side. This is because in the normal map (shown in the right side), the UVs were split in half. And then the right half was rotated upside down (because I was saving space).

Here is how it looks like in Blender:

However, when you preview the normal map from Blender, it looks fine.

In the end, I was forced to remap the UV layout so there’d be as few seams as possible.

This resulted in having to reduce the size of my UVs to fit in the image, but so far, that’s the only way I see to fix it.

Rushing for the IGDA July Meetup

For the impending IGDA Manila July Meetup, I certainly won’t be able to rush my next immediate objective: enemy A.I.

So I’m spending the time doing some polishing here and there.

Here’s the soldier with normal maps (finally stopped being lazy about baking it):

It’s sitting at 11.5k triangles which I think is good, but I could probably shave off a few more without sacrificing much detail.

I’ll also add the really cool sounds that Raf had been making.