File formats and scripting - XML

I think I want to use XML to create the quests and bulk of the game. I wrote up a basic idea of what I think an xml file for the game would look like.

<game>

<quest type=" ">
 <id>  </id>
 <title>   </title>
 <description>  </description>
 <incomplete>  </incomplete>
 <complete>  </complete>
 <failure>  </failure>
 <npcid>  </npcid>
 <solution>
  <killnpcid>  </killnpcid>
  <finditemid>  </finditemid>
  <savenpcid>  </savenpcid>
 </solution>
 <reward>
  <giveitemid>  </giveitemid>
 </reward>
</quest>

<npc x=" " y=" ">
 <id>  </id>
 <name>  </name>
 <sprite>  </sprite>
 <avatar>  </avatar>
 <talk>  </talk>
 <alignment>  </alignment>
 <movement>  </movement>
 <health>  </health>
 <inventory>
  <itemid>  </itemid>
  <itemid>  </itemid>
 </inventory>
</npc>

<item x=" " y=" ">
 <id>  </id>
 <type>  </type>
 <name>  </name>
 <sprite>  </sprite>
 <description>  </description>
 <quantity>  </quantity>
 <damage>  </damage>
 <heal>  </heal>
</item>

</game>

After some searching, it seemed that TinyXML was the most popular for games. But alas, I am coding in C, not C++ so I couldnt really use it. I looked around a bit more and found ezXML. Its written in C and its very easy to use. I loaded it up and got it working straight away. I wrote an app that reads in the file and counts how many there are of each type. It then allocates memory to store each in a structure and loads them in.

Tile transitions

After reading http://www.gamedev.net/reference/articles/article934.asp i was utterly confused. I knew what I had to do; just not how to do it.

The answer was in this picture:

From the above article it states that each in order has an equivalent binary value. IE the first one is 0(blank), 1, 2, 3, and so on up to 15. But because we want to store all these in a single byte, the second row starts at 0(blank) and goes up by 16. IE 0,16,32,48,64...etc

Now that we know this, we know that each tile can have a single byte that represents its transition overlays. When we create a new tile type, we add to the 8 surrounding tiles to create their transition value. What do we add? Well, by drawing a 3x3 grid on a piece of paper I started with 0 in the middle - a blank tile. Starting in the upper left I checked each against the list in the picture above. So the corresponding upper left tile in the list above is row 2 tile 4 (starting at 0) . Because its on the second row, and we're storing it all in one byte, we shift the value left 4 bits.

So going through each one starting at the upper left, moving across to middle top, upper right, etc, we get 64,8,128,1,16,2,32 and 4.

Now when we place down our tile, we add those values to the surrounding tiles' existing transition values.

How to draw the transitions

We have a transition value for each tile created by going through the base tile type and adding to the transition value as above.

The general algorithm for each tile is as follows: 1. We do the corner layer first. Take the transition value and shift it right 4 bits. This lets us only work with the upper 4 bits. ie T = T>>4

2. From the list of corner tile overlays, look up the corresponding T value and draw the tile.

3. After placing all the corner layer, move on to the transition value for the sides layer. Instead of shifting right 4 bits, we want to AND the value with 15 (binary 00001111) to give us only the lower 4 bits. ie T = T&15

4. From the list of side tile overlays, look up the corresponding T value and draw this layer over the previous. It is important to draw the side layer second because in cases where a tile would use both corner and sides, we dont want corner pieces to be drawn on top of side pieces.

And thats it, really. What if you have more than two tile types (ie something other than just grass and water)? Well, all you need to do is have a T value for each different type of transition. IE a T value for Water to Grass, a T Value for Hill to Grass, etc. You only need a one transition of each direction for each tile type. That is, you dont need a type for Hill to Water, because Grass takes precendence over Water and Hill over Grass. The images in the tutorial that I mentioned earlier explain it pretty well.

The Plan

The key to any successful project I believe is having a good plan.

There are a few key decisions that have to be made early on in the project, or nothing can be done. Here are a few things to think about:

Tile Engine
At first I had this idea of going completely isometric, I even made up a simple engine that displayed an isometric map on the screen, complete with scrolling. But then I remembered - I'm only a beginner. I was bound to run into problems that I couldnt solve easily.


The isometric engine I started. This was actually the editor. The line through the middle was a few road tiles.

So take 2, I restarted my engine and did it in flat tiles, at a resolution of 320x240. It was looking good, and I was getting somewhere. But I started running into problems because my tile size was too big - 40x40 pixels - way too big for such a low resolution.


The second attempt at an engine. By now I had learnt a lot, but it still wasnt quite right. The graphics by the way, were from a talented guy I found with google, at http://lostgarden.com/2006/07/more-free-game-graphics.html

Finally I have decided to settle on 640x480 with a tile size of 32x32. A tile size of 32x32 will come in handy for multiple reasons:

1. 32 is a multiple of both 640 and 480.
2. 32 is a power of 2. This will make bit-wise operations easier, thus making optimisation faster.
3. It is a nice size that allows for a significant amount of graphic detail without having to create a great amount of tiles.

Screen Resolution and Colour Depth

In addition to reasons above, there arent so many good reasons to go 640x480 as there are to not. Most games of today run at 800x600 or higher, with 32-bit colour. These games usually use DirectX or OpenGL and have a splendor of 3d graphics. However our game doesnt use those technologies. Because of our game's simplicity, we will stick to 640x480. Most other games similar to ours from that era were also 640x480.

The next question is - 8,15,16,24 or 32-bit colour?

Whilst most games of the day were 8-bit, I have decided to go for 32-bit. I originally started my earlier engines in 8-bit but found whilst I didnt run into any problems, I kept finding myself having to re-create a new palette for the game every time I added some new graphics. Some might say that I should start with a palette and stick to it, but to put it simply, laziness has won me over. 32-bit will be easier to code and to draw.

Introduction

For many years, I had a dream of creating my own computer adventure games. I followed this for a long while, learning to program, and eventually having a crack at AGI game making.

However, after a couple of years of tinkering with the AGI interpreter, I played a game called 'Solar Winds'. Long before the popularity of MMORPG's I had an idea. I thought wouldnt Solar Winds be awesome if you could play it online against other players? It would be a space trading type game online.

I set out to create my own version. I Called it 'SpaceM' and actually had a working prototype for a short while, around 1998. By 2001 however I had begun an interest in other things, including that which doesnt involve a computer.

So now, in 2009 I have the time again (for the most part) to restart my interests in programming. I have scrapped the idea of a space trading game and have gone back to basics, to hone my skills and create an RPG.

The blog
Keep coming back to this site for the progress on the RPG, and the obstacles I run into.