Sad days indeed....

Well, here's something that has hit me hard...

Just the other day, I rebooted my Windows 7 machine due to a system update and BOOM... the RAID 0 settings I had for my 2 1TB drives was destroyed, can you see what happened here?

Did you know that you can't just say, make a RAID 0 and poof your data will be returned to you?

Yes, you've read that right... everything I had on my hard drives was wiped clean. The downside to this, I've lost everything I had on my computer...

Thankfully, my friend who is working on the games with me has an older copy of the games, but at least not everything has been lost!

What's worse is, 2 days before I had fixed my gimbal locked camera and we had a full 360 degree of freedom. Oh well, now that I know how it's done, I can rebuilt that code easily.

The problem with Cameras and a Gimbal!

Alright. There might be some of you who just by looking at the title to this post go: Duh!

And for those of you, who like me, wouldn'tve figured out what the problem is here's the low down.

I keep saying that my camera controls aren't quite what I want and there's a reason for that. I'm working in a 3D space, but I'm using a 2D input device (the mouse).

Now, my original code to rotate the cube around the screen was by adjusting the x and y rotations by the value that the mouse has moved. Seemed simple enough. Create a degree of rotation, transfer that into a Matrix and poof! Instant rotation of the cube... and this does work... mostly. The problem is, I'm only using 2 out of 3 dimensions for rotation... can anyone see the problem?

I did some research and found out the term... it's called Gimbal Lock. This happens with 3D maths that use regular vectors and matrices... 1 axis of rotation lines up with a 2nd axis and suddenly they're locked together, unable to seperate. Leaving you only 2 degrees of rotation. Well my code has this without even bothering to lock an axis. Since I was only using the x- and y-axis, this locked the z-axis from any rotation. In theory I deliberately coded in a Gimbal Lock.

Now, I've read about how I can prevent this completely by using Quaternions... what's a Quaternion? Good question, I never studied these in University, so everything I'm learning is from the wonderful internet. With that said, I think I have a rough enough understanding on how they work and how to use them. Unfortunately, the XNA libraries don't have prebuilt Quaternion maths, so it looks like I'll be creating a new Component to my GameLibrary that'll handle all of my Quaternions.

(As a quick heads up for people who've never heard of Quaternions... they work in 4D space, wrap your head around that!)

It's alive!

Alright, I feel like an idiot now.

This bug for 2 weeks has been plaguing me everytime I tried to fix it.

Here's the deal:

My original code that detected match-3's and created new objects. It was just buggy to the point that it was unplayable.

So, I decided to completely rewrite the code. I scrapped everything match-3 related and rebuilt the code from scratch. (Thanks to C# and #regions!)

Well, the code is very... hrmm, the best description I can think of is "dynamic". The functions shift the intent of the functions that they call.

From here, I created a couple of helpers to manage everything, but I did make one specific function that creates the new tiles and moves them into place. I had just forgotten one specific thing.

Here's the deal:

I had to create a mouse selection routine for the original selection system. Raycasting a point into the level and then determining the closest object to the front of the screen that's clickable.

Now. This selection code uses a Container I had created called the Object Container. It does what it says it does. It contains all of the objects in the game. But here's the catch. If the object you're trying to click on isn't in the Object Container... it doesn't trigger the click. This was my problem. I had completely forgotten to add the new tiles into the Object Container. So when I clicked, they were essentially invisible. One line added and the code is fixed!

I am thinking that this is a problem with the clicking code. I'll probably update the base object creation code to automatically add new objects to the Object Container and this would remove any future similar issues.

Well that's it. Time to go, maybe I'll start on fixing the camera controls since they're not QUITE what I'm wanting...

Till next time!

Updated Match-3

Well, it's been awhile so here's a quick update.

I've refactored the entire match-3 system. It's much more efficient and actually detects all matches correctly. It even moves the tiles into the correct space everytime now. But I've hit another new bug from the refactoring. The new tiles that are created not clickable. What's weird about this is the fact that from all of my debugging, I can see that the tiles themselves are clickable, but yet I'm not getting them to click on.

As I've been writing this, I think I just realized what the problem is with my clicking.

I'll post again if my theory is correct...

Signing out.

The magic of 3D Match-3's

Alright folks. Newest update! Whoohoo, I know it's been awhile, but I hit a snag in the code and have been working on fixing an annoying and infrequent bug.

So... what's been going on lately? Glad of you to ask, here's the lowdown on it.

Our match-3 game is progressing incredibly. I've been working on the animation codes a bit to improve them. Plus, I'm now able to swap tiles around on the cube. To the point where a Match-3 is actually detected! Yes, that's right, basic gameplay is almost complete!

Now, I have matches being removes, and new tiles coming in to replace them as per the basic game design. But I have hit a weird infrequent bug that, when a match-3 is discovered... for some reason the tiles don't shift into place to replace to newly removed tiles. It's weird. The match-3 is removed, but new ones don't fall into place. This is what I'm working on. Though, my animation code to replace the tiles is EXTREMELY ugly and incredibly inefficient. I'll be refactoring that entire code first into a few helper functions to trim down the code. It's very repetitive, so I should be able to animate all 6 directions of the cube with only a couple of functions.

(Of course, this goes without saying, if refactoring this code fixes my bug... I'll be very very happy!)

After this, I want to rework the camera controls since the rotation of the cube is dependent on the camera and it's not working how I would like it. So that'll be next... after this, I get to do some proper 3D models. Once it looks good, scoring will be added... bonus tiles, maybe various game modes. Oh, mustn't forget to add a proper menu system, and even a highscores table. But this is all done later, I want the gameplay to work so that I can test it and make sure that it's a viable game.

Well, that's all for now... till next time!

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.