June #1GAM: A Huge Island with Coconut Trees

In my last One Game a Month project post, I mentioned that I had message routines and created tiles for an island.

At the time, I said the next steps were:

• Add a map. A big one that spans more than a single screen.
• Make the camera center on the Castaway as we explore the map.

Well, I did it. And I might have gotten a bit overambitious.

Above is an image of my 1024×1024 map so far. Each pixel represents a tile, as it does for the maps of my first major game, Stop That Hero!. I find loading images and defining tiles by colors to be quick and easy.

But I’m starting to realize how much work it is to create such a large world. I wish I had time to figure out some procedural algorithm to generate an island for me. As it is, I’m plotting things by hand, and taking shortcuts as I get bored. You can see the mess of green swirls at the bottom left as an example.

In any case, I thought I should add some other elements to the island, so now there are coconut trees:

I like the way they look when they are clustered together, even if the lack of variety makes them look more cookie-cutter than would be ideal.

I am finding a problem with rendering, however. Specifically with Z-ordering. There is no concept of an obstacle yet, so the Castaway can walk through trees. When he is above a tree and walking down, he’s behind it until his feet hit about halfway down the tree, then he pops in front of it.

I think it is because the render ordering is based on the top-left corner of a blitted image and not the hotspot location, which would be the bottom of the tree and the feet of the Castaway. When the Castaway’s feet get about halfway down the tree, his head is just below the top of the tree, so now the system thinks he is in front. Hopefully that’s what it is and can be easily fixed.

I did run into one problem with the map loading that I’d like to share here. The 1024×1024 map is split into 32×32 graticules (I refused to call them “chunks”). Each MapGraticule is split into 32×32 tiles.

When I loaded a graticule from the map, I did it by getting the pixel offset and then matching tiles to colors in each pixel in the 32×32 area of the image.

When I ran the game, however, I was confused why so many graticules appeared very similar. In fact, they looked the same. What gives?

My image loading code was fine. The problem was when I created the MapGraticule objects for the island map in the first place.

I did so like so:


for (int column = 0; column < WORLD_WIDTH; ++column)
{
   std::vector<MapGraticule*> graticules(WORLD_HEIGHT, new MapGraticule(graticuleWidth, graticuleHeight, DEFAULT_TILE));
    m_map.push_back(graticules);
}


For those of you unfamiliar with C++, the above code loops through each column in the world, creates a collection of pointers to MapGraticule objects, and adds it to the world map.

For those of you very familiar with C++, you see what I did wrong. I created a single MapGraticule object, but created a vector of pointers…that all point to that same object.

So when I was populating each graticule with the right tile data, I was actually overwriting the same object’s data. When I went to render the world, I was likewise getting the data to render from the same object instead of multiple objects like I expected.

It was a simple fix. I simply added a loop to go through each row and created a unique MapGraticule object for each coordinate:


for (int column = 0; column < width; ++column)
{
    std::vector<MapGraticule*> graticules;
    for (int row = 0; row < height; ++row)
    {
       graticules.push_back(new MapGraticule(graticuleWidth, graticuleHeight, DEEP_WATER));
    }
    m_map.push_back(graticules);
}


My next task is to give the player something to do other than explore the map.

Walking around is fun and all, but the people demand drama!

They want the player to pick things up. They want the player to put things down. They want the player to eat things.

Oh, the excitement!

And I might shrink the size of the island while I’m at it.