Animations and the Calculations required.

Alright, second post of the day.

So, as mentioned in the previous post, this entry will be about Animations and things required for them.

Now, some of you reading might already know that I used to work for a Game Studio already in the past. I left due to personal reasons, and I'm already happy to see that 3 of my games have already been published after I left. Puts a sense of pride in me knowing that something of mine is already out in the market. (Don't know how well they're selling, but they were my first commercial games!)

Now, when designing the animation procedures I remembered that animations weren't super easy to calculate. But I have the extra complication of having to do the calculations for 3D space and not 2D spaces. But, I've created a 2 simple animation functions and I'll be able to now expand easily on them.

Of course, since I'm working on new work in the GameLibrary I'm doing all the testing in my 3D match-3 game since it's technically the tech demo. (Plus, I needed these here urgently or I couldn't do anything else!)

1. The first animation I completed was a GoToScale function. This is what it sounds like. It takes a scale, either X,Y,Z scales, or a complete Vector and a time frame and will scale the object up/down accordingly in the specified time. I also added an optional callback so that you can know when your animation is done. (This is something I've programmed from my past work I designed before and I still love this system so why rewrite what works right?)
2. The second animation... GoToPosition! The backbone of any video game. How do you make things move automatically without having to recode the movement everytime... with GoToPosition! Just like GoToScale it takes X,Y,Z or a Vector and an optional callback!

Well now, with these two animations complete and running I had to update the 3D cube a little. New click functions call the GoToScale now, and if the two pieces are next to each other, they slide into the other's place smoothly. Next chunk of code to be added is the comparison so see if a match has been made!

Now, I'm going to make some developer's lives a little easier, and some of you pro's out there might wince and think I'm an idiot but here we go!

My basic multistage animation system technique!

First, background info about how I developed my technique:

At the previous studio I was at, I had to do a lot of animations for my games. Everything from an animated score scroller to flipping sprites. Well, I had originally had done everything with a sequential set of functions. But this caused really bloated code with loads and loads of single use functions. I spent about 30 minutes and came up with this 1 function technique that I still love and use.

First, make a function... give it a good name cause you only have to call it once!

Now. Here's my favorite part. You can do this two ways:

First, a parameter in the function that's just a number or....

A global variable specifically for this animation.

Either way works, just depends on what your callback system can handle. Currently, my system can't handle me sending the next "step" through the callback so I'm going to be doing it with a specific Global variable. (Yes, not efficient, but I wanted to get the animations working quickly)

Alright. Next Step... a Switch!

Each step runs the specific animation aspect for this step and then breaks out and does nothing.

function. But, here's the trick, if you're doing multiple items setup the longest animation of this step to have the callback back to this exact same function. Break out of the switch and then increment the counter.

Now, here's the joy... each previous animation step will callback the function and each stage will run in order and you don't have to dig through hundreds of lines of code to find each stage of the animation.

Here's a rough example of the technique:

public void AnimationExample()

{

switch (GlobalStep)

{

case 1:

GoToPosition(NewPosition, Time, AnimationExample);

break;

case 2:

GoToScale(NewScale, Time, AnimationExample);

break;

default:

FinalizeAnimationCode();

}

GlobalStep++;

}

That's it! I've used this technique hundreds of times in my games. I created an entire Story board system using this technique. It works great and I love how simple it is to edit so that you can expand and shrink the animations to your hearts content.

Well, that's it for this edition of the Diary. We'll see what's happened the next time I update... Hang around for the next installment.

Co-operative fun both on-line and off-line!

Well here's the description of the 2nd game already in the pipeline. It's been a while since I posted and much has happened to the game during that time. Here's the description and rundown!

Description:

I've played many many platformer games and some even with RPG elements. I've spent many hours enjoying the original D&D arcade games. If you've never seen or heard of them... think Golden Axe done with D&D classes and experience.

Now, with these wonderful games in mind, I had a thought pop into my head. Why not make a true adventure platformer that multiple people can play together? This is the premise of the game.

The only and primary idea we've both agreed on for this is this:

Multiplayer is done both off-line split-screen and on-line. Unlike other RPGs like this, we want the players to separate sometimes. That's right, you've not stuck being on the same screen with each other. We want to design the levels so that certain character classes can go in certain locations.... usually for a challenging puzzle/encounter, but will give the player rewards for succeeding. Various ideas that have sprung from this are: Rogue-class performing multiple wall jumps up high to get to a trapped hall with a chest at the end. Fighter-class encountering a large group of monsters s/he has to defeat to find a reward.

Now, remember, this is just two friends developing these games so nothing is actually designed formally. Especially for this RPG project we're enjoying. Right now everything is just adding elements that we want to put in the game. Making sure that everything is very modular so that we can enable/disable anything we want.

Of course, here's what we've currently done:

1. First iteration of the level engine just read a simple text file with characters in it showing where the tiles were. This was a good start cause it allowed for the second step.
2. Pseudo-Physics. I call these Pseudo-Physics because there's lots missing, but the basics are here thanks to my resident Software Engineer. We have collision detection, and gravity. Even jumping, double jumping, and... Wall jumps! It's so much fun.
3. The creation of a Level Designer was started. With this part 4 was done simultaneously since both parts were integral to each other.
4. Second iteration of the level engine was created. I had to rewrite this because the grid system just doesn't work for an RPG style platformer. We couldn't design stairs, ramps, etc with the old engine. Plus, we hit a design flaw in the original one. Due to the array-style that was used, a 50x50 map was unplayable on my Quad-Core machine since it had to calculate 2500 possible objects to draw on EVERY frame. This was a process hog especially since not every 2500 spot in the array was actually populated with an object. The new engine is MUCH more efficient, it's a single list of the objects. And only the objects that are populated. There's no 2D array to scan just the single List. Secondly added to the engine was something I definitely had to add... scaling! We're not limited to one size for each object. We have full scaling to enlarge or shrink each object as we need them. This is allowing us to create pretty detailed levels right now with just a cube as our building blocks. Handcrafted stairs and ramps look nice with this new system.
5. A new level loading and saving system was implemented. Since now with our new level designer we don't have any size contraints... yet (probably just number of objects). We're not stuck to the grid system anymore. So I had to create a new file format to save the entire levels, but how was I to do this? Well, thankfully since I'm using just a single List to hold the level now, I had an easy way to iterate through all of the objects to save and load them. That was the easy part. Second, I had to create output for each object. So, in one file I have the Model that was used, the Scale of the tile, and the exact Position of the tile on the level. This is saved in binary to preserve some file size, plus prevents editing the file directly.
6. So, with the level designer and new level system in place we found a few flaws in the old code.... stairs! We couldn't do them before but we can build them now, since he's done all the physics and collision work already, I've delegated anything physics/collision to my partner and he's done great. We now have physics stairs. Walk up to a ledge that's a little higher than the ground you're currently on and you'll walk right up. No need to jump. Instant hand-made stairs are feasible.
7. Path finding... yes, that's right, path-finding. My partner thought this up and I'll agree we need it. There will be monsters and other moving things in the game. But how are they going to know how to walk around the level? We're not going to program a full movement AI cause that would just be too many calculations for us. We as few processes running so what's been done? Well.... the full idea will be this: Select a monster/character and run the Patrol system. This system actually starts the monster/character at it's current position and finds every possible route to walk. There are limitations to it... the object can't fall too far, etc, etc... eventually it finds a nice route and will start to patrol it. We can save this route and then load it later when the level loads. Currently, we have no monsters, but the patrolling system works for our character so it's cool to watch him try to figure out a route.

Well... that's all for this game currently. I've been working on designing the Animation algorithms and calculations for the models. This'll be the next post.