To celebrate, I think it would be great to spread the news about my strategy game that puts you in the role of the evil villain, Stop That Hero!.

And so I’m having a sale all this week.

It’s still in alpha release, but if you’re interested in it, you can get early access to the game as well as support its development by purchasing it today.

Until Saturday, July 27th, the day after my birthday, you can get “Stop That Hero!” for only $5 using coupon code BIRTHDAY2013.

That’s 40% off the current price.

Currently, the game lets you summon minions such as slimes, warlocks, and dragons to fight the heroes who are trying to conquer your castle. The controls are simple since artificial intelligence manages who does what and where. You summon minions and manage your resources to do so by choosing when and whom to summon at structures you control, such as your castle, towers, and dragon nests.

Timing is important, and it can get frantic, especially when the heroes send powerful wizards and knights your way.

The next update will feature animations and more scenarios, and any current customers will get informed when it is released.

Shortly after, I made it so you can also drop items arbitrarily, which means now players can properly propose with this game:

Next on my task list was to create an inventory management system. I wanted the player to be able to equip arbitrary items and not just the one that was picked up first.

But of course, first I needed to create items to collect.

That screenshot above shows a tree branch (clearly not from the coconut trees), a seashell, an empty net, a fish, a rock, and a coconut. Nearby are the coconut tree and boulder.

I want the player to be able to combine items together in useful ways. I don’t want a full-blown crafting system, but some way to fabricate useful tools out of other useful tools. An example of what I want is a lean-to made out of branches:

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.

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

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.

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.

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:

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.

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.