Archive for the ‘2D’ Category

Keeping Busy – Deathspuds, Animation & Painting

So I’m hoping to make “things I’ve been up” to a more regular thing on my blog. It has been pretty hard finding time to write and revise some good useful articles which I’m hoping to post soon. But until then, rather then writing something useful. I figure I’ll just write what I’ve been up to. At least that way this thing gets used and maybe some of the stuff in it may be useful, and/or even interesting!

So what’s been happening recently.

I’ve recently completed Milestone 3 for DeathSpuds. 

This milestone saw the implementation of Enemies which can melee and/or shoot projectiles at the player while moving through a level. The behaviour was a little bit whacky at first, mainly because I tried to condense the melee and Projectile shooting into a single Attack State but it just made it as confusing as the AI was behaving.

I ended up splitting the Melee and Projectile shooting into 2 separate AI States. It made more sense considering the Enemy would either do one or the other or both. And it was easier to determine when to switch between or leave these states by checking per state, rather then all in one.

The enemies also avoid walls now to. The also find a way out when they get backed into a corner.

Enemies that also just specialize in shooting projectile will also maintain there distance, running away when you get to close. Ones that can do melee will move in if you get to close to them. At the moment it’s set to be 3/4 of the closest possible firing distance. I’ll probably end up tweaking this or even making it an available factor in the Unity inspector to get better control over this distance.

This milestone also saw the implementation of enemies spawners, such as enemies spawning from a point and out of the ground. This presented a small problem with Unity’s Mecanim, which is handling all of our animations. It just doesn’t give you much control over using a single Mecanim Animator Controllers which defines the animation behaviour of a character given certain values, at an initial starting state. Forcing you to duplicate the controller file, renaming it, and setting a different starting state.

For example, one of our enemies can spawn out of the ground and also just be standing idly in the scene. But in order to do that, your need to define 2 specific Animator Controllers for the 2 different types of starting states. The controllers are basically identical, accept one has it’s initial starting state as “Idle” and the other as “Spawning”. It would be nice if it were possible to force a particular state onto the animator for purposes such as this.

I know it doesn’t sound like much but imagine making adjustments to one and having to duplicate and set the starting state. Now imagine doing that a hundred times with just minor adjustments over a long period of time. It would get quite annoying.

In all the Enemies are pretty fleshed out and it’s going quite well. I can see some issues popping up which I’ll probably address if and when they arise, such as line of sight  of projectile shooters with enemies blocking the way. But it could just be a matter of making them simply move their position, I doubt it… but here’s to hoping it is.

There was a whole bunch of other things which went in. A lot of which was for to improve performance at run-time for the first level. Which Josh has made to look damn awesome. But I’ll leave it that for now.

Today, I also integrated some core animation components into my flash framework. It hasn’t been much of a priority before because most of what I was doing with flash was being driven by code or physics. Since I’ve been working on point and click / hidden object engine, having a means to control animations and animatable things has become pretty important.

My goal was to have an item you clicked from the scene move themselves into the foreground, and spin and fade into your inventory. I ended up implementing an Animation Manager that let you pass in Animates, basically animations that define a particular behaviour, such as spinning and fading. Basically setting values on this animates and passing it to the Animation Manager will cause the animation to occur.

I also had to make sure that it was pretty easy and straight forward to do for people who may end up using this engine the future. Mainly Elise. The way you use it was kind of inspired by how you use [UIView beginAnimation] in the iOS Core Animation Framework. Of course what I’ve implemented is nothing compared to how Core Animation actually works. But I based my design purely on it’s ease of use, minus the static call.

I’ll most likely be tweaking this over time and adding more features to it and even more animate types but overall I’m pretty happy with how it turned out.

I’ve also been doing some digital painting for the backgrounds in our game.

Point and Click Background 1

Elise did most of the line work for the painting. I’ve just been colouring it in. It’s a work in progress. We’re still working out the final look of some other areas, so some things are likely to change.

And that’s what I’ve been up to lately.

Sprite Sheets – Working Out Their Size

So I’ve been working with Elise making a 2D point and click / hidden object game. We’ve been slowly piecing our engine together looking at the tools we can leverage to help create the content, as well as revising our own existing tools to do some work for us.

Recently, I’ve been revising our sprite sheet generator. It’s probably one of the oldest and first things we’ve had in our arsenal of tools, and it certainly has been there before the great options we have these days as indie developers, such as TexturePacker. If you haven’t heard of it and your a 2D game developer, I really suggest you check it out.

Up til now, when we integrate our sprite sheet generator as part of our pipeline process, we specify a fixed size, throw all the images in, and sort using a Binary Sorting algorithm, and hope it all fit. If not, we make the sheet bigger. It was a very manual process, and our best size guessing algorithm rarely guessed the best size. In fact upon revising the code I wondered what the hell I was even trying to achieve in the first place. Either I was programming late at night or using someones suggestion from the internet.

Regardless, I threw out the old code and re-wrote it, and here’s what I came up with.

public const int MinOptimizeSize = 8;
public const int MaxOptimizeSize = 8192;

public static Size CalculateOptimalSize(SpriteSheet sheet)
{
// no sources?
if (sheet.Sources.Count == 0) return new Size(MinOptimizeSize, MinOptimizeSize);

// work out the sum of all source areas
int areaSum = 0;
foreach (SpriteSource src in sheet.Sources) areaSum += src.Area;

// if there is no area, then return something small
if (areaSum == 0) return new Size(MinOptimizeSize, MinOptimizeSize);

// find the size
int guessWidth = MinOptimizeSize, guessHeight = MinOptimizeSize;
int power = MinOptimizeSize;
while (power <= MaxOptimizeSize)
{
// compute the area of the power!
int powerArea = power * power;

// if the power area greater the the sum of all source areas?
if (powerArea >= areaSum)
{
// set the guess size
guessWidth = power;
guessHeight = power;

// find the minimum height to fit the area
while (guessHeight * (power / 2) > areaSum)
{
power /= 2;
}

// update the height result
guessHeight = power;
break;
}

// next power
power *= 2;
}

// return the size result
return new Size(guessWidth, guessHeight);
}

Sorry about the formatting, WordPress keeps removing it!

Basically what it’s doing is finding the total area of all source images and finding the minimum sized power of 2 square to fit it all. It then works backwards focusing on only the height, halving the height to see if the sum of the source areas can fit in in that. When it can no longer fit, the previous height is the one that will fit it all.

There are some cases where this result isn’t going to be able to fit everything perfectly, especially with arbitrary sized sprites, or you have sprites that are seriously huge. But for a starting place it’ll be close.

Once you have that size, there are additional checks you may want to do after you’ve worked it out. Such as evaluating the width and height of your sources images. By doing this you can determine the following.

  • Whether to swap the width and height values if you have more tall sprites then you have wide ones. This is because you are more likely to fit tall sprite sources inside a 512 x 1024 then your are in a 1024 x 512 sprite sheet.
  • Checking the size of the of each sprite source against the size of the “guessed” fit. This is because you may find that one or more of your image sources may exceed the dimensions of the “guess” itself, requiring you to make early adjustments.

There are a lot of other things you can do but that goes into your sorting method for your sprite sheet, which is another topic on its on. But the methods discussed here should give you relatively useful results for determine the initial size to fit your source images. And with that, to those who have stumbled in here, I hope you find it useful! Feel free to leave any comments or other suggestions below.