Game Design Game Development Geek / Technical Linux Game Development

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.

June #1GAM

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:

June #1GAM

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));

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));

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.

5 replies on “June #1GAM: A Huge Island with Coconut Trees”

Looks like you’re making progress. This could turn into a very fun game, especially all the picking up and putting down and eating of things. A couple of comments… are you sure you need to chunk the map into tiles (graticules?) Even a 1024×1024 map should fit in memory, and it sounds like you are thinking of reducing the size of the island anyways, so that might be a way to simplify things. Also, don’t be afraid to store things by value, esp. in std containers. Yes, it can create performance issues but more often than not it doesn’t, and it keeps things a lot more straightforward.

Thanks, jovoc!

A tile is 32×32 pixels, and a pixel is also the basic unit for distance in this world. A graticule is made up of 32×32 tiles. The world is 32×32 graticules. So the entire map is 1024×1024.

I created the graticules because I didn’t want to do distance calculations to figure out which entities and objects to update. Right now, I can find the graticule that the player/camera is in, get the surrounding graticules, and only do updates/rendering on those. Basically, if the player is close enough, I can brute force the update for all objects in a specific graticule.

I agree on how straightforward it can be to have containers of values instead of pointers. I made them pointers so that I can quickly make separate lists, although I later found that I didn’t need it for the task I thought I needed it for.

Heh, I was trying to come up with a structure that allowed me to render and update only nearby areas of the world, and I realized it was sounding very similar to Minecraft’s “chunk” concept, but I definitely didn’t want to try to mimic that game. Everyone seems to be making Minecraft clones, and I’d rather not.

So, graticule sounded like a decent enough name for the concept, especially since I access them by world coordinates.

Comments are closed.