I wanted to install the latest version similarly. I found that the latest version doesn’t have a working configure file; I was expecting to be able to use the standard ./configure; make; make install. It still worked for the most part without the ./configure part. In fact I took advantage of checkinstall to create a nice Debian package for me so I can uninstall and install easily.

So it builds, but I found that there are a few differences. For one, kyra-config doesn’t exist. I normally used it to get the cflags and the lib arguments for my Makefile, similar to the way you would use sdl-config. So, how do you build a project now?

I asked on the Kyra forums, and the maintainer was actually just sitting in front of it waiting for my posts. He was that quick! Eventually I found that the way I wanted to use Kyra wasn’t the way it was supposed to be used anymore.

Kyra isn’t currently capable of being backwards compatible, meaning that different versions of the same library can’t be installed at the same time. So basically statically linking is easier and less likely to cause problems. My only concern is the fact that the LGPL license requires different things for code that statically links to it, but I was planning on releasing my code under the GPL anyway so it isn’t a huge problem.

To make one of my famously long stories short, I ended up working on my Makefile and the library until I found out how to get it to work dynamically…just in time to read that I shouldn’t use it that way. I managed to get my project to build with the new library only to find out that I should use it a different way. I spent some more time until I finally managed to get it to build the preferred way. I have a source directory with all of my source files as well as a subdirectory with the Kyra library source.

It was definitely a good learning experience, as I learned more about linking and libraries on my Gnu/Linux system. I actually built my project successfully three different times: once with the old dynamic library, once with the new library fixed up to be dynamic, and once with the code statically linked. The last option is actually cool because I can actually add the Kyra library directory to my Subversion repository for Oracle’s Eye.

Still, I would have liked to schedule my learning experiences better. I was supposed to be working on my game project instead of the supporting library. I really wanted to try to work on what William Willing mentioned on his blog about Composition vs Inheritance. I’ll probably be able to work on it this Friday though. At least the new library seems to be working great now.

Learning Kyra: Installing the New Version is a post from: GBGames - Thoughts on Indie Game Development

I wanted the Player and the Walls to be on the same hiearchical level, and the Floors should be underneath. That way, Floors can be added to Kyra‘s KrImageTree as much as I want without the Player getting covered.

I already knew that I could setup the Tree by creating KrImNodes to act as the root of subtrees. Normally if you just add nodes to the tree, the later nodes will cover the earlier ones. I could instead add nodes to the child nodes instead to control the hiearchy. For instance, I could create a background and a foreground by adding background and foreground KrImNodes:

KrImNode* background = new KrImNode;
KrImNode* foreground = new KrImNode;
engine_->Tree()->AddNode( 0, background );
engine_->Tree()->AddNode( 0, foreground );

AddNode() takes as arguments the parent node and the node you want to add. In the above example, I am adding two new nodes to the root node. Now I can put as many items in the background as I want, and I won’t have to worry about covering up anything in the foreground tree. I already used this technique before with my Game in a Day in June.

What I learned was that I could also name a node. Kyra doesn’t care about the name, but I found that I could name a node and than search for a node with that name.

KrImNode* background = new KrImNode;
KrImNode* foreground = new KrImNode;
background->SetNodeName( "background" );
foreground->SetNodeName( "foreground" );
engine_->Tree()->AddNode( 0, background );
engine_->Tree()->AddNode( 0, foreground );

Now if another section of my code doesn’t know the specific pointers to the nodes in question, I can still do a search and get the information I need. For instance, in my GameWorldFactory’s createRoom() function:

engine_->Tree()->AddNode(
engine_->Tree()->FindNodeByName( "background" ),
floor->getSprite()
);

The result is that the Player can walk over the FloorTiles and gets covered by the WallTiles if the Player sprite was added to the foreground before the Room’s Tiles were.

The cool thing is that the separation of the Tiles into the hierarchy also makes it a lot easier to do collision detection. My previous code to move the player:

void GameWorld::moveY( const double distance )
{
player_->moveY( distance );
}

My current code to move the player:

void GameWorld::moveY( const double distance )
{
engine_->Tree()->Walk();
//! Check if moving Player sprite would intersect a wall.
//! If so, do not move the Player.
player_->moveY( distance );
if ( engine_->Tree()->CheckSiblingCollision (
player_->getSprite(),
&spritesHit,
0
) )
{
//! Reverse direction to restore position.
player_->moveY( -distance );
}
}


Since the Player’s sprite and the WallTiles’ sprites are siblings, and the FloorTiles’ sprites aren’t, I can simply check for collision with the siblings. CheckSiblingCollision() returns true if there was a collision, and so what I do is move the Player back the same distance, which should place it where it was before the move.

Unfortunately, it doesn’t quite seem to work. The Player does obey the WallTiles, but it then gets stuck. I think the problem is the double precision used for the distance. The sprite makes use of integers to move, and so I am probably losing precision. When I move the player back, it might be just short of where it should be.

Before this week, I was looking at a single Tile and a Player that moved around it. Now I have an actual Room and simple, although flawed, collision detection to keep the Player in the Room.

I’m also wondering if PlayState should still own the Kyra engine. I think that maybe GameWorld should own it instead since it makes use of it more, but for now I at least know that the project is working. I can always optimize later, and in the meantime I am making steady progress.

Oracle’s Eye Development: The Room 2 is a post from: GBGames - Thoughts on Indie Game Development

A big change is the license. It used to be dual licensed. You could either make use of the GPL or the LGPL. Now it is under the LGPL for any purpose and without the requirement to display a splash screen.

One of the new features is Isogen, a tool for quickly and easily generating seamless tiles and walls for isometric games. It looks pretty cool and makes me think about the possibility of developing isometric games.

It can compile with Gnu/Linux, BSD, and MinGW32. There is the ability to compile for Mac OS X, but apparently the run-time performance leaves much to be desired…but the source is freely available to those who would be able to submit patches!

Another thing I’ve been interested in is learning the Python programming language. People have been suggesting it to me recently, and I think after I finish Oracle’s Eye I will look into the language. The cool thing is that I won’t necessarily have to find a new graphics library since there is a Python binding called PyKyra. It isn’t new, but I just noticed it was a possibility.

I’ll need to check and see how much it breaks backwards compatibility with the old version, but I am really looking forward to giving Kyra 2.1.1 a spin.

Learning Kyra: A New Version Released is a post from: GBGames - Thoughts on Indie Game Development

GetSpriteResource( Char_Player)

where Char_Player is a constant defined in a .h file generated by Kyra’s Sprite Editor. While I could write a file to load the U32 that the constant referred to, it seemed unwieldy to have a script file that looked like:


Player 1 < < 0
Enemy 2 < < 0
...


I would think that updating such a file would be confusing, if not a nightmare.

So while perusing the code files looking for information on how to do something else entirely, I saw that the test programs provided with Kyra had lines that looked like:

bigRes = engine->Vault()->GetSpriteResource( "LARGE" );
medRes = engine->Vault()->GetSpriteResource( "MED" );
smallRes = engine->Vault()->GetSpriteResource( "SMALL" );


I was excited that I could apparently load sprites by name, but I didn’t remember seeing anything about how to do it in the documentation. I looked more closely and found something about how to refer to a sprite’s action by name, but not the sprite itself. After some more hunting through the code, API, and documentation, I figured it out.

The name of the constant Character_Player was made by creating a sprite called Player. Character_ was just a prefix I used for all characters. Kyra allows me to refer to the name of the sprite as “Player”, however. So:

GetSpriteResource( Char_Player)
is interchangeable with
GetSpriteResource( "Player")

and naturally that means that I can do something like this:

string name = GetEntityName();
GetSpriteResource( name.c_str() );

Voila! Sprite loading by script is possible! The only thing I need to do is make sure that the names that I give my sprites using the Sprite Editor are the same as the names in my script, but it is definitely better than syncing the names with things like ( 1 << 0 ).

Learning Kyra: Sprite Loading is a post from: GBGames - Thoughts on Indie Game Development

I’ve spent some time just reading through the documentation for SDL and Kyra. I’ve also tried to pick up what I can at Kyra’s forums on SourceForge.

For instance, GlDynArray has been removed from the library for the next update. I can substitute std::vector<> though, which for all intents and purposes means very little has changed except for a redirection/abstraction. For now, I need to use it when doing hit detection, but I shouldn’t rely on it for my own code.

I was thinking about the need for more complex animations and Actions for an individual sprite. For example, a sprite may have a standing animation. When you press the space bar, an attack animation should run, but I might not want it to loop over and over. Was I going to have to keep track of how many frames of animation there were for a given Action in order to make sure it doesn’t loop?

Nope! Turns out that Kyra’s KrSprite class has functions for determining the number of frames for an animation and for getting the current frame. Now I can do something like the following:


if ( theSprite->Frame() >= numFrames )
{
// then the ATTACKING animation is over and should change state
}


I also found that a sprite can clone itself. In my June GID, I had these fuzzy creatures multiplying, but I loaded in a resource from a file and created a sprite from the resource. I originally thought that I could optimize it by storing the resource to be used later, but I could further optimize by just using the Clone() function to create a new sprite. I could also use GetResource to get a pointer to the resource used by an existing sprite if I really needed it.

I want to work on some code to test what I’ve learned to see how well it works. I can get something substantial completed this week.

Learning Kyra: Some Tidbits of Info is a post from: GBGames - Thoughts on Indie Game Development

I covered collision detection already, but it was in a limited capacity in Attack of the Clones. Basically, I checked if a sprite was colliding with a specific object. But what happens when I want to check for collisions with objects that have been added dynamically and prevent me from anticipating them at compile time?

The code below creates a number of sprites from the same resource. Kyra comes with the Grinning Lizard Utilities, so those are prefaced with Gl. I think that it makes it confusing if you want to mix your code with OpenGL, but whatever. One of the utilities is GlDynArray, which acts very much like the C++ Standard Library’s vector class. While it is in the provided demo code, I couldn’t find any mention of it in the documentation. I simply followed along with the demo in shooter.cpp. I created an array and added 10 ghost sprites to it. In the code below, MAX_GHOSTS is equal to 10. I also add those sprites to the tree.

KrSpriteResource* ghostRes = engine->Vault()->GetSpriteResource(GHOST_ghost);
GLASSERT( ghostRes );

KrSprite* ghost = new KrSprite( ghostRes );
ghost->SetPos( GHOST_START_X, GHOST_START_Y - 64);
engine->Tree()->AddNode( midgroundTree, ghost );

GlDynArray< KrImage* > otherGhost;
for (int i = 0; i < MAX_GHOSTS; ++i)
otherGhost.PushBack( new KrSprite( ghostRes ));
for (int i = 0; i < (int)otherGhost.Count(); ++i) {
otherGhost[i]->SetPos( GHOST_START_X, GHOST_START_Y );
engine->Tree()->AddNode( midgroundTree, otherGhost[i] );
}

So now I have a bunch of ghosts bunched up in the center, which is where GHOST_START_X, GHOST_START_Y sets them. I placed the player’s ghost about two tiles higher. Since I was going for simplicity, and I mostly hacked out this code without designing it first, I just made the sprites in otherGhost move around randomly. Another utility is GlRandom, which provides random number generators that are superior to rand() provided by C++. The following code demonstrates how I used it:

GlRandom random;

...
//the following is in the main loop
for (int i = 0; i < otherGhost.Count(); ++i) {

...
otherGhost[i]->SetPos( otherGhost[i]->X() + (random.Rand(3) - 1) * moveSpeed , otherGhost[i]->Y() + ( random.Rand(3) - 1) * moveSpeed);
...
}

So now each of the sprites in otherGhost move in random directions. I move the original ghost much the same way as I moved my clone sprite in previous Learning Kyra entry. Well, there is movement for the player and other objects, but what about collision?

if (engine->Tree()->CheckSiblingCollision(ghost, &hit, 0) ) {
for (int i = 0; i < (int)hit.Count(); ++i) {
engine->Tree()->DeleteNode(hit[i]);
int j = otherGhost.Find(hit[i]);
otherGhost.Remove(j);
}
if (otherGhost.Count() < 1 )
done = true;
}

Very simply, if the main ghost collides with any of the other ghosts, those ghosts disappear. When the last one disappears, the main loop ends, and since I hacked this out instead of designing it, so does the program. Still, it is game-like. I experimented with other options to see what else I could do.

Instead of removing the ghosts from the tree, you could make them stationary, sort of like in Freeze Tag. As they get hit, I remove them from the otherGhost vector to keep them from moving about, but I also added the following to fade them a bit:

KrColorTransform color = hit[i]->CTransform( 0 );
color.SetAlpha( 50 );
hit[i]->SetColor(color, 0);

While it isn’t fun or polished in any way, I don’t think I can expect too much more from this specific project, at least not without struggling through painful changes. I didn’t set specific goals so the project simply evolved. I’ll consider this project complete and move on to a new project that will benefit from my new experience and some better design. You can download the project as it stands from one of the links below:

KyraGame-r1.tar.gz
KyraGame-r1.zip
Kyra Source in .tar.gz format
Kyra Source in .zip format

NOTE: You will need Kyra v2.0.7 to use this code. Also, the comments in the code weren’t all updated to reflect the fact that I’ve changed it. It is licensed under the GPL or LGPL as specified.

Learning Kyra: Hit Detection is a post from: GBGames - Thoughts on Indie Game Development

The first three entries in the series documented my attempts at learning about the engine. I had a goal to become more familiar with the engine by the end of the month, so those articles were more focused. While that month has since passed, I am still learning plenty about the engine.

Recently I learned how to create tiles. Originally I was creating sprites, and they are sufficient for making games. However, I can also use tiles, but the documentation warns:

A Tile — in contrast to a sprite — is always square (width == height.) It can be rotated and flipped, however. You should always use Sprites unless you need to rotate and flip the image.

Making sprite images and making tile images are similar activities. When I use the Kyra Sprite Editor, I need to specify tile instead of sprite. Tiles are simpler since I do not need to mark hotspots and verify that they are aligned correctly. I was able to get three tiles very quickly, and saving created the .xml file to use. Then I used the Kyra Encoder and created the appropriate .dat and .h files. I copied those over to my source code directory.

The code to load a tile is different from the code to load a sprite, and the tutorial doesn’t cover it. I had to look at the Bug-Eyed Monster (BEM) demo code to find an example that I could use. To load a sprite, you have to do a few steps:

1. Load the .dat file
2. Get the KrSpriteResource as specified in the header file you created
3. Create the KrSprite from the KrSpriteResource

Loading a tile is a little more complex:

1. Load the .dat file
2. Get the KrResource
3. Get the KrTileResource by using KrResource::ToTileResource()
4. Create the KrSprite from the KrTileResource

Ok, so there is only one more step, but it took me some time to find how to retrieve a KrTileResource. For instance, to get the KrSpriteResource, there is a function: GetSpriteResource(name_of_resource). To get a KrTileResource, however, you first need a generic resource by using GetResource(ALLCAPS_TAG, name_of_resource), and I couldn’t find the documentation on what that tag should be. It turned out that they were defined in kyraresource.h, and the one I needed was KYRATAG_TILE. Again, it was not in the tutorial so it took some work for me to learn what was needed. Here is the relevant code, keeping in mind that when I used the encoder, I prefaced everything with Tiles2_ (I already had a previous attempt with Tiles_) :

KrResource* res = engine->Vault()->GetResource( KYRATAG_TILE, Tiles2_tile2 );
GLASSERT( res );
KrTileResource* tileRes = res->ToTileResource();
GLASSERT( tileRes );
KrTile* tile = new KrTile( tileRes );
GLASSERT( tile );

tile->SetPos( 130, 98 );
tile->SetRotation(1);
engine->Tree()->AddNode(0, tile);

Anyway, I imagined that the tiles I created would be pretty cool to work with since they have alpha transparency. I could make clouds or chain-link fences, for instance. As I moved a sprite to the tile, I expected that the sprite would show through the tile’s transparent spots; however, when adding an image to the engine’s tree, the order matters. Since I added the sprite after the tile, the sprite image overlapped the tile image. I switched the order in the code, and it worked perfectly fine.

But then I was concerned. In a game, elements will get added dynamically. I wouldn’t want to find that a new enemy can walk over tunnels, or that the hero walks under floor tiles! Then I learned how the BEM demo handled Z-Ordering.

Everything that can be in the engine’s tree inherents from the base class KrImNode. KrSprite and KrTile are both KrImage classes, and KrImage is a KrImNode. KrImNode isn’t an abstract class, and it is the key to handling Z-Ordering.

Usually when I add a sprite or tile to the engine, I use the following code:

engine->Tree()->AddNode(0, tile);

AddNode()’s first parameter in this case is 0, which means that in the tree, it is a child of the root. If I add a second child, it will be drawn over the first child when the following code gets run:

engine->Draw()

BEM handles Z-Ordering by creating subtrees. Background images should be added to the backgroundTree while foreground images should be added to the foregroundTree. You create those trees in the following way:

KrImNode* backgroundTree = new KrImNode;
KrImNode* foregroundTree = new KrImNode;

engine->Tree()->AddNode(0, backgroundTree);
engine->Tree()->AddNode(0, foregroundTree);

Now, when I create a tile that goes in the background, I use AddNode(backgroundTree, tile1). Naturally I would have a separate subtree or two for entities I want to always be between the background and the foreground. If I need to create tiles for the foreground, I can add them to the foregroundTree:

engine->Tree()->AddNode(foregroundTree, tile2);

And tile2 will always be drawn on top of any images that are siblings to tile1, even if I add an image to backgroundTree after adding tile2.

Now that tiles and the Z-Ordering methods are added to my toolbox, I’m becoming much more dangerous with the Kyra Sprite Engine. Using just what I know now, I can probably make a fairly simple game without struggling with an unfamiliar library. There are still a few features to learn, however, including:

• Fonts
• Alpha blending and color transformations
• Scaling
• Canvases
• Sub-window views

I may tackle one or two of these in the next Learning Kyra post.

Learning Kyra: Tiles and Z-Ordering is a post from: GBGames - Thoughts on Indie Game Development

Last time I was able to create a non-interactive moving body with a head attached. It simply walked from the top to the bottom of the window. Fairly simple, just like the graphics created for it.

In this entry, I will describe how I tackled the following tasks:

• Adding multiple characters to move around at once
• Adding interactivity
• Adding collision detection

I began with trying to add multiple characters to the program since it seemed like the simplest task. I did run into some problems, but in the end I managed to accomplish what I wanted.

To start, I needed to create a new character. I decided to make a clone of myself, goatee and all, as I described in the first part of this series.

I figure that as a clone he didn’t need his own body, so I can just reuse the existing one. Kyra allows you to change the colors on the fly, so I could always tint his appearance later. For now, he also gets a blue shirt with brown pants.

Kyra creates sprites based on resources. I already had two resources: gbHeadRes and gbBodyRes, both of which can make the sprites gbHead and gbBody. I simply used similar code to create the first clone: I grabbed the new resource gbCloneHeadRes and created gbCloneHead from it.

I then created a new sprite from gbBodyRes called gbCloneBody. For all intents and purposes, it is a copy of the already existing gbBody, but Kyra needs to know about each sprite. I then added the gbCloneHead as a child of the clone body. I set the position of the clone so that it would start a little higher than the regular character. This way, it will look like he is chasing him.

It actually turned out decent. I then tried to add multiple clones. I thought they would be great in a triangle formation, chasing after the poor original. It was at this point that I started having problems. I thought that since the head would be the same I could probably just add it as a child of all of the new bodies, but Kyra didn’t like that since it would seg fault when I run it. I just created multiple heads to go with the multiple bodies. I then found I had an off-by-one error. I wanted to create a triangle of characters, but I forgot to actually count how many I would need. I needed six, but I only created five, but then I was trying to set six, and so I kept getting seg faults until I figured this one out. /me smacks self in head for that one.

Still, I was victorious in, as you can see:

Objective accomplished! Now onto the next.

Interactivity is the stuff that games are made of. Up until now, I’ve only had an animated graphics demo. Once I get it to be interactive, I’m that much closer to making simple game demos. w00t!!

Kyra did not provide facilities to handle input, so I just followed the demo’s lead and used Simple Directmedia Layer to do so. Since I didn’t want to create multiple images just to have the body move left, right, and up, it would be fairly simplistic. I wanted to make it so the user can press the arrow keys left and right, and the main character would move accordingly while running down the screen.

It was actually fairly simple to implement, and I managed to get it working quite quickly. I simply added a variable for the movement speed and then if SDL detects that the left or right arrow is pressed, I would set the movement speed accordingly. For example:

I then modified it so that the SetPos for the gbBody would always modify the X coordinate by moveX. Then, just to add some useless complexity, I made it so that two of the clones would also move as you moved. The two middle clones will separate and move together as you move from left to right. It was here that I experienced the issue of z-ordering. Kyra will draw the sprites in the order that you added them to the engine, so while the top row would rightly be behind the second row, the second row would walk over the head of the first clone! To correct this issue, I simply added the clones from front to back.

But what happens when I want to make a sprite run in multiple directions? For example, the Kyra demo shows the Bug Eyed Monster program where the creatures can walk around in a circle, which means that a creature that might be closer to the viewer must be drawn on top of the other creatures, but that same creature can move to a point where another creature will become closer. The demo obviously handles it correctly, so dynamically changing the z-order is clearly possible. I’ll save learning this task for another day.

For now, another objective can be stricken off my todo list. It may not be very complex, but it’s a start.

Time to tackle collision avoidance. At the moment, the clones in the middle row can walk through each other, which is not something I want them to do. I found that the shooter demo makes use of collision detection, so I tried to follow what it did. Unfortunately it wasn’t very clear to me how it was handling it:


KrSprite* newMonster = AddMonsters();

GlDynArray< KrImage* > hit;
// Can we keep the monster we just added -- or did it collide?
if ( newMonster && engine->Tree()->CheckSiblingCollision( newMonster, &hit, mainWindow ) )
{
engine->Tree()->DeleteNode( newMonster );
newMonster = 0;
}
else if ( newMonster )
{
// This add will not be collision detected.
StatusAdd( newMonster );
}


So it creates a creature, but somehow it is able to determine if there is a collision even if it didn’t set its position? I plan on asking about that on the Kyra forums. (NOTE: I have since discovered that AddMonsters() actually sets the position, so nevermind) For now, I was able to determine that I needed to use the Walk() function to set the tree to check for collisions. I also needed to compare what I had to what was in the list of collided sprites returned by CheckSiblingCollision(). I spent a bit of time here because I was unfortunately trying to grab the wrong information.

I was trying to do this:


if (gbCloneBody[2] == (KrSprite*)(hit.ItemPointer(i))


but I was supposed to do this:


if (gbCloneBody[2] == (KrSprite*)(hit.Item(i))


It turns out that Item() already returns the pointer I needed, so I was getting a pointer to the pointer, which is why I couldn’t detect the collision. Once I figured out this part, I was able to add code to move the clones away from each other if they intersect. They now bounce off of each other, which is closer to what I want.

So hours later, the third task is solved. Mission accomplished!

Recap: Today, I learned how to create multiple characters and display them on the screen simultaneously. I learned how to reuse existing sprites to make new composite sprites. I learned how to add interactivity to my project while also adding some crude collision detection. What does it all mean? It means that I can not only have the clones avoid walking into each other, but I can also check if they intersect other objects, such as powerups or projectiles or anything I can throw at them. I’m excited about the possibilities, and my own demos are fairly crude.

Next time:

• I want to learn about dynamic z-ordering.
• I want to create tiles and backgrounds.
• I want to make a simple game using what I’ve learned, probably something like Pac-man or Lock-n-Chase.

For now, I’ve accomplished enough to go to the Chicago Indie Game Developer meeting on Sunday with pride. B-)

You can download the updated version of the code:
KyraTest-r15.tar.gz
KyraTest-r15.zip
Kyra Source in .tar.gz format
Kyra Source in .zip format

NOTE: You will need Kyra v2.0.7 to use this code. Also, the comments in the code weren’t all updated to reflect the fact that I’ve changed it. It is licensed under the GPL or LGPL as specified.

Learning Kyra: Attack of The Clones is a post from: GBGames - Thoughts on Indie Game Development

When I last worked with Kyra, I managed to get my head floating on a black background. Since then, I found out why lines like #include “SDL.h” are preferred, so I updated my code to reflect that change. I’m definitely becoming more aware of the issues I’ll encounter in development, much more than I was a month ago. Good. It means I’m learning. My goals for my next iteration in development:

• I want to make the head’s background transparent.
• I want to make the head move.
• I want an animated body to go with it.

Geting the head transparent was weird. I was under the impression that Kyra’s sprite editor would actually pick a color to make transparent based on which corner I told it to use, but apparently I was mistaken or there is a bug when it uses something other than certain graphic file formats. I switched to using .tga files from .png, and I also found that I could set the transparency within The Gimp. First task: completed.

It didn’t take me long to get the head moving. I didn’t even have to change my code since I already programmed it to move. The data file just didn’t have the information to know how to move it. To change it, I entered the Kyra editor and set it up so that the head would move a few pixels in some arbitrary direction each frame. It was quite easy to do, and I even experimented with creating multiple frames. With only one image, it wasn’t very good looking, but it was good progress. A Black Triangle, if you would. Second task: completed.

Once I accomplished movement, I set out to create a cartoon body. I fired up The Gimp again, and was able to create three images for the body. The total walking package is below, and as you can see, I should stick to programming:

After getting the data encoded properly, it only took a few tweaks of the code to get the walking body on the screen. Check it out:

So now I have a walking character. He only moves in one direction, but he walks. Third task: completed.

So I managed to accomplish what I set out to do, and it was much easier than I expected. I managed to get more familiar with the mechanics of Kyra’s sprite editor and the code itself. I learned how to use The Gimp for more than just capturing screenshots and cropping photos. I also am learning that content development will probably require a lot more planning than I originally thought was needed.

My goals for my next iteration:

• I want interactivity: the character should walk in the direction indicated by input.
• I want multiple characters at once.
• I want them to practice collision avoidance: a character shouldn’t be able to “walk into” another

You can download the updated version of the code:
KyraTest-r8.tar.gz
KyraTest-r8.zip
Kyra Source in .tar.gz format
Kyra Source in .zip format

NOTE: You will need Kyra v2.0.7 to use this code. Also, the comments in the code weren’t all updated to reflect the fact that I’ve changed it. It is licensed under the GPL or LGPL as specified.

Learning More Kyra is a post from: GBGames - Thoughts on Indie Game Development

One of my goals was to program 5 hours per week at the minimum. While I wasn’t able to do it consistently, I did program on my own projects much more often than I did last month. I even managed to fix up my Tic-Tac-Toe game so that it is a completed project under my belt. I’ve been learning, but now that school is no longer a worry I can accomplish much more in the coming month.

Another goal was to learn how to use Kyra. I haven’t touched it since I got the demo running on my machine. The demo was quite impressive and showed the power of the Sprite Engine. So I set to work, but I had some issues.

I created a directory in my Projects directory called KyraTest. I setup a Subversion repository and setup my documentation, source, and resource directories. Kyra comes with a tutorial, so I started there. The tutorial involves using a few images together. I wanted to start simply, so I cropped a photo of my head and shrunk it. I figured I could later add a cartoon body to it and have a bunch of characters running around on a screen. For the moment though, I just had this head.

I was able to create the .dat and .xml files from the sprite editory provided. I then copied one of the tutorial code files into my source directory and edited it to make the references to my own data. For some reason the file was written as if you wouldn’t have Kyra or SDL actually installed. It would have lines like:

#include "SDL.h"


All well and good, but why not use the system include instead of a local one? If you know, please let me know why the first way would be preferable.

Anyway, once I got that part squared away, and fixed the bugs I introduced when I edited the file, I got it to compile. Unfortunately it wouldn’t run because it couldn’t find libkyra.so.0. I found that it was installed on my Debian system, but there wasn’t a link created in the standard location for libraries. Once I created the link, it worked fine.

The end result: A black background with an image of my head in the middle. B-)

It was what I set out to do for today before going to bed, but it was kind of frustrating getting to that point. I sent an email to the author explaining the issues I had and how I fixed them, and I also asked for explanations on some of the code decisions.

My goal for this week: I want to make an application where a bunch of clones (with goatees, of course) are chasing after the real me (sans-goatee) before the meeting on Sunday.

And for the code collectors:
KyraTest.tar.gz
KyraTest.zip
Kyra Source in .tar.gz format
Kyra Source in .zip format

NOTE: You will need Kyra v2.0.7 to use this code. Also, the comments in the code weren’t all updated to reflect the fact that I’ve changed it. It is licensed under the GPL or LGPL as specified.

Learning Kyra is a post from: GBGames - Thoughts on Indie Game Development