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.

A cube and a dream!

Alright, for this 2nd post I figured I would discuss the original game that was planned and the view that we've dreamed.

First off, I will admit, I'm a match-3 fan. I love these games. Quickly finding objects and moving them to make 3-of-a-kind or more and seeing how long I can keep it up. I've played many many many... different match-3 games and here's what I've thought.

Every match-3 that I've played always worked on a 2D flat board. Sure, some have had you remove pieces and the board underneath reveals itself to show a picture. But we've never seen anything that was actually in full 3D, and this is where my dream arose. I have a vision of a cube of pieces, hovering in the air, letting the user rotate it at will and move pieces around the outside, making matches, having them explode/erupt/shatter/etc.. and having the pieces within the cube slide forward and replace them. Doesn't seem too hard does it?

Well actually, it's a little complex. First, we wanted to make this a bit of a challenge for the user, come on, who doesn't like a challenge. So, instead of the pieces just appearing from the center of the cube, they're actually sliding around the inside of the cube. So imagine this, you've made a match on the side you're facing, suddenly the pieces disappear and the ones behind all side forwards, filling in the gap. Yes, that's right, all the pieces behind those empty spots will move forwards, all the way from the other side of the cube, causing new pieces to fall into place on that face of the cube. So, here's the trick. Imagine you've setup a side of the cube to your satisfaction, knowing that you have a great combo ready in case you need it, then you switch to the other side and make a match. Suddenly your combo is gone! This game will require you to think only on your feet, no strategy required. If you wait for a specific move, you'll destroy anything you've worked on.

Let me know how you think of this.

Start of a Blog!

Well, here goes. The first post of a new blog.

As listed by the blog name, this is a blog of a developer. Actually, if everything goes as planned, maybe two developers. :)

The purpose of this blog is just to help jot down thoughts and ideas on games that we're developing. We're not out to create our own video game studio... unless we make LOTS and LOTS of money first. Hahaha.

Seriously, we're just two guys developing video games with XNA, which means we're able to publish games for Windows and the XBox 360. It's mostly for fun too. We're not spending 8 hours a day programming. (Though I've done it a couple of times already since I had a REALLY good code idea in my head)

Myself, I'm unemployed and actively job hunting, and my partner is currently employed with a full time job. This passion is just a hobby. A fun hobby, but still just a hobby.

Here's what's on our plates:

We've two games in development.

One: A puzzle game in a match-3 genre where we're working in a 3D space, and not just a 2D flat board.

Two: A multiplayer platformer RPG. Yes you read that right. It's a bit ambitious for newbies but hey, we like thinking big.

Both games are being developed simultaneously, which means, we work on whatever part of either game that we feel like.

Originally the first game wasn't going to be worked on seriously since a few technical issues arose, but those have been resolved, and thanks to them, both games are progressing quite well actually.

Now, more about the process:

Since we're two guys just coding these games for fun, we don't have nor want a commercial product that assists with the development. No predefined libraries for us, no thank you!

Everything we've done we've coded. And anything reusable has been added to our GameLibrary. The GameLibrary is just that, a library of game parts. It first started as just an FPS calculator and limiter. But now it's got multiple camera types, basic controllable 3D models, even a Clickable model type. The latest component added was a Mappable Input Controller. I love this thing. I can map any button to any action and it'll run flawlessly sending callbacks when a mapped action was triggered.

Well that's it for today. The next couple of posts will describe the games and the current visions, before going into any technical.

See you soon.