Category: Game Design

My last One Game a Month July project update mentioned updated exhaustion animation and more complex stamina and air supply systems, which I think added a bit of richness to the game.

My most immediate goal was to be able to identify objects in front of the player.

In the above screenshot, the player is facing a coconut tree, and a little bit of descriptive text appears.

And as you can see, I shrunk the boulders. It’s temporary. I wanted to add rocks to the game, and rather than create a new object, I just changed how an old one is rendered.

You’ll also notice that standing in front of a rock results in an action becoming available. If you press the spacebar, you’ll pick it up:

And that yellow box at the top right corner of the screen is your currently equipped item from your inventory.

Putting that box in required changing the UI slightly. I think it works out well enough:

What happens when you want to change what’s equipped?

An inventory system is the next item on my list!

I want the player to be able to bring up an inventory menu to:

• select and equip items
• drop an item
• eat/use/consume an item
• combine items

That last one is how the resourceful Castaway will best be able to make the most of a life on a desert island. Combining tree branches would result in a lean-to, which the player can place to provide some shelter, for example.

As I think about all of the items and combinations, I realize that there’s a lot of systems to add to make them worthwhile. For instance, the lean-to is really only useful if I require the player to sleep and seek shelter from weather, which means I need some kind of per-day exhaustion mechanic and a weather system.

Also, can you combine sticks with rocks to make clubs? It would make sense to have a need for a club, such as attacking any wildlife you find for food.

Whoa, wait! What about the Low Violence Challenge? If you recall, I wanted to challenge myself to create games that were less about destruction and violence. I was inspired by Corvus Elrod’s Low Violence Challenge. It was surprisingly hard at first! I have a game idea file that was almost useless this year because so many of my one-line designs depended on “ATTACK” as the main mechanic.

While I think that adding combat mechanics necessarily adds violence to the game, it won’t represent the majority of the game play. Weapons and violence aren’t going to be the focus of this game. Yes, you can attack animals and eat their meat, but you can also opt to be a vegetarian. This game is about exploration and survival, and it is most definitely not about eliminating all other life on the island.

And besides, since it isn’t the core of the game, it’s probably not going to be the first thing I work on. I have less than three weeks to finish the game, after all.

Now that it is July, I’m continuing work on my One Game a Month project, Shipwrecked.

At the end of June, I was trying to create a new image to indicate that the player is either drowning or collapsed on the ground. I had a first try, but it didn’t read very well:

That last frame is supposed to be the “collapsed on the ground due to exhaustion” image, but it didn’t look very different from the “facing up” image.

So I asked for help on Twitter and Google+, and I got some great suggestions:

Unfortunately, I ran out of time last month, but that’s when I created Dark Horse last Saturday and submitted that game for June.

So when I got back to work this month on Shipwrecked, I wanted to make it obvious to the player how dangerous it is to stay out in the water too long.

I created a few more frames of animation for drowning, which happens when you’re out of stamina and swimming. You can still swim, but you only have a few seconds of air left. If you run out of air, you die. Swimming has the Castaway bobbing in and out of the water, but drowning shows what little of his face that is above the water in anguish:

And if you make it back to shore in time, here is the new “collapsed due to exhaustion” look, based on the feedback I received:

I also added a stamina bar to the top right of the screen. If you are drowning, a second bar appears to give you an indication of how much air you have left. Both of these bars can be seen in the above screenshots.

When you stand still and aren’t swimming, you regain stamina slowly.

What I like about everything I just described is that it is a pretty simple system that provides a better play experience. It is slightly more complicated than what I had before. Originally, if you had no more stamina and were swimming, you instantly drowned. It was harsh, and you had little feedback.

Now, stamina informs whether or not you have the strength to swim. If you don’t, then you start drowning, but you still have time to get back to safety before you run out of air. Air becomes a secondary resource, and the player has more options. Do you risk swimming to that smaller island that may or may not be within swimming distance, or do you turn back? It’s up to you how conservative you want to play. What’s more, stamina doesn’t recover if you are moving, so if you have to keep running away from something chasing you, you are risking the danger of not being able to swim very long.

I’m reminded of a talk given by Chris Crawford in which he discusses the use of variable ranges rather than booleans to provide a larger experience. If you have an NPC in adventure game, you could have a boolean that represents whether or not the character is hostile towards the player, but wouldn’t it be possible to have a richer experience if there were any number of in-between states, such as indifferent? Or secondary states, such as confident or fearful?

While I’m pleased with the stamina and air supply systems, I still need to give the player some way of eating food and recovering from hunger. I could implement a simple system in which touching nearby food objects automatically consumes the food, but in keeping with the above ideas, wouldn’t it be a richer experience to have an inventory system and give the player the choice of when to eat? As a couple of examples, I can introduce the concepts of food spoilage and cooking.

At the same time, July 31st will be here before I know it. I can’t get carried away with feature creep before I have created the core of the game play.

So despite my efforts, I wasn’t able to finish the game I’ve been working on all month for June’s One Game a Month project.

So I took a good chunk of Saturday to make an entirely different game instead.

I’ll continue working on Shipwrecked for July, but Dark Horse is a very simple racing game that I managed to get done in less than four hours.

Download Dark Horse for Linux 64-bit (362 kb tar.gz file)

It was originally a Zero Hour Game Jam project from last November that I never finished. It started out with a very simple rendering of a horse that can jump.

I then added hurdles and birds as obstacles, a clock, and a previous best time to beat for the challenge:

The still images don’t show the horses legs spinning in place, and when the horse jumps, it looks pretty frantic.

Hitting obstacles slows you down and prevents you from making your best time. You need to jump over the hurdles on the ground while avoiding the birds, which fly up and down in the air.

Each race has a random collection of obstacles. I thought about adding collectables to give the player more incentive to get in the air to make the birds a bit more dangerous, but then I thought about giving rewards for collecting all of the items, and unfortunately my game development time is up for this weekend.

Dark Horse is not polished, but it feels good to get this old project to a completed state.

And next month, I hope to deliver the ambitious Shipwrecked. I’ve already dedicated 23 hours to it, and another month might be enough. B-)

Last week, I posted a video of dancing coconut trees for my One Game a Month project for June.

I ran into some technical issues when loading and rendering the world and its objects in the right place, and so I didn’t get as much accomplished this weekend as I would have liked.

I still don’t have an inventory system, but I thought about adding a shark to the game, which means that the player should be able to enter the deep water for at least short periods of time before drowning.

The Castaway, in his pampered past life, never learned how to swim.

I’ve also added rocks. I’ve been experimenting with making them look right. Above, they were large boulders, but they looked odd when the player was standing next to them. Below, they are a bit smaller width-wise, but I made them tall to avoid making it look like you could pick them up. It’s…odd.

Still, now it is possible to have areas of the island that are impassable unless you take a more roundabout route.

As it stands, the game has day/night cycles, a large island to explore, two objects (coconut trees and boulders), water to swim in as well as wade through, and hunger.

But it still isn’t really a game.

Next up:

• make the player die from hunger
• give the player a new object that helps alleviate hunger
• give the player a temporary mount of time to be in deep water before drowning

I would like some concept of fatigue, a way to create a shelter, weather effects such as rain, animals such as sharks and crabs, and an end goal. I worry that I can’t do it all by Monday, though. I’m half-tempted to churn out something simple for this month and continue working on this project next month.

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.

The other day, I had merely a walking Castaway demo for Shipwrecked, my June One Game a Month project.

I spent a little more time on the controls than I thought I would. It didn’t feel right. I tried something simple at first:


if (an arrow key has been pressed since the last update)
{
velocity = 1.0
player.setDirection(the direction of the arrow key)
}
if (an arrow key has been released since the last update)
{
velocity = 0.0
}


It worked well enough. The Castaway moves at a constant speed until the key is released, then he comes to a complete halt.

The problem was that if you are switching directions periodically, sometimes the velocity drops to 0 even if you feel like you should keep moving.

So I changed it. Now, instead of checking for key release, I check the status of all four arrow keys. If none of them are currently pressed, THEN set the velocity to 0.0. Otherwise, allow the movement to continue.

It feels much better.

I’ve also added some message routines. Basically, if there is a message to display to the player, it will end up in a queue with a timer. When the message is visible, the timer ticks down to 0, and it removes the message from the queue for the next one. It took me all of 15 minutes to implement.

And instead of a giant purple emptiness, I added some tiles.

In this Shipwrecked message queue video demo, you can see all of the elements of the project in action, including being able to read a few lines in the Castaway’s diary:

I simply painted the tiles down using for-loops, so the Castaway could walk on water right now if I let him.

So the next big things to do:

• 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.
• Give the player something to do other than explore the map.

My worry is that I’ll get to the end of the month without any game play. I still haven’t exactly figured out what actions the player has, nor what the ending looks like.

It’s partly because I’m worried that I’ll be too ambitious. For instance, if I implement the ability to get heat stroke, it means the player needs to be able to avoid it, which means finding or building shelter. Do I have time to implement the ability to collect resources and build a lean-to (as well as draw one that looks half-decent)?

These last few things have come together quickly. Maybe I’ll get lucky and won’t have to compromise entirely on the concept of a Castaway surviving on a desert island after a shipwreck.