Welcome to Null City Software
Tasty, tasty software.
 
Null City Logo Home Kitae Breeze Products Login Forums Contact Us About Us
Since I've not written much about the engine for a little while I thought I'd drop a quick post on here to demonstrate a few of the advanced features of Kitae and the Kitae Game Editor.

First of all I wanted to demonstrate something I seem to have self-termed "temporal collision detection". Someone please drop me a note if this is a fairly well understood collision detection term, as I can't find mention of it anywhere and I'm not sure where I heard it. Anyway, pretty much any game developer that has written a game will have encountered the problem of objects moving too quickly to detect a collision with a thin or small object. This problem can be particularly annoying with common objects, such as fast moving bullets or particles. Solving the problem can be equally difficult, depending on your objects.

In the above picture, you can see that during the first update frame at time index 0ms the object is to the left of the green wall object. By the time the second update occurs at time index 16ms (60 FPS)  the object has moved quickly from x50,y50 to x200,y100 on the right side of the wall, completely missing the wall as far as the game in concerned. Enter "temporal collision detection". Kitae simply performs multiple collision detections across the line that describes where the object was in the previous frame and where the object is now. The algorithm can be told to either let the collision occur but leave the moving actor alone, or to stop the object from passing through the wall.

Kitae now employs a full cached geometric collision detection system. Every graphic in your game can have an attached geometry set used to perform collisions against other objects. The Game Editor allows you to build these geometry sets quickly and easily for your game assets. Below is a screenshot of the geometry set editor and two groups of vertices that make up the gun and circle sections of the graphic.



Collision detection code can be enabled on a per-actor basis so long as a geometry set has been created for the underlying art asset. These geometry sets are incredibly powerful, as they allow the engine to perform geometrically perfect collision detection. Any sprite based actor with any rotation or scale can be collision detected against any other. As long as the geometry set correctly depicts the shape of the sprite, the collision detection looks very accurate. Additionally, these geometry sets are basically groups of vertices, which means that collision detection results return the exact groups which collided during the detection. An example of where this could be useful might be in a beat'em up. Every frame of a character animation can have a set of geometry with multiple groups. In such a game you might opt to put groups on the "feet", "torso", "head" and "fist" of the character. During a "punch" cycle, the collision detection algorithm would return you the exact body parts that collided, perhaps then you would assign a higher damage factor to a "fist -> head" collision than a "fist -> torso" collision. This is just one example, grouping is useful in just about any game genre.

Geometic collision detection is not quite as accurate as per-pixel detection, however per-pixel detection is difficult to manipulate with objects that can be rotated and scaled, since it basically requires 2d bit-mask arrays. The geometric collisions Kitae uses are generally very quick and return immediately when there's no chance two objects have collided. For further optimisation I may consider using quad trees.

Of course you have full access to the data contained in geometry sets built at design time, so you could for example feed this information into Farseer or other third party physics engine. On that note, I have decided that Farseer will not directly be part of Kitae, but examples will be made available showing you how to utilise Farseer within Kitae.

Right, ok, time for a demonstration. Below is a short video of an example I plan to bundle with the engine:



The darts in this video have a simple rectangular geometry set, and so does the wall, the darts are approximately 100 pixels wide and the wall is approximately 15 pixels. The darts are fired at random velocities in the range of 1...450 pixels per update from the cannon - when the space bar is held. Without temporal collision detection, the faster moving darts would completely miss the wall and pass straight through it. Kitae correctly detects the collisions with the wall irrespective of speed.

To show you how easy this process has been made, here is the relevant collision code used to perform the detection shown in the example video above:

Code:
CollisionResult result = actor.CollideTemporal(this.wall, CollisionAction.None);
if (result.Collided)
{
    // Deactivate the dart.
    actor.Velocity = Vector2.Zero;
    actor.Location = new Vector2(wall.X, actor.Location.Y);
    this.flyingDarts.Remove(actor);
}

This collision detection can also be applied when detecting sprites against tile maps. This is very useful for arkanoid style games as it provides an easy way to build block grids.

Release date. Still not sure yet. I'm working on Kitae in tandem with a game I've always wanted to develop. I figure there's no way I'm going to release the engine until I've proven it works in a released game. This is also incredibly useful from a user-interface stand point, as I'm feeling the rough clunky bits of the editor and smoothing them out as I go. All good for anyone who ends up using the engine. Kitae should be released somewhere near christmas at current development rate. The particle emitter system and effect system are the only large chunks of the engine that have seen little development at this point. Obviously documentation too :)
Null City Software
Null City is dedicated to developing top quality sofware products for Windows PC, XBox and Windows Phone. We specialise in games and .NET applications & components.