Category Archives: Game Design

For September’s One Game a Month project, I wanted to try to use the optional theme: hexagons.

I toyed with the idea of making a turn-based strategy game involving a hex map, but more and more I liked the idea of a hexagon-based puzzle game.

Long ago, I thought of a game involving hexagons that you can trap as they fell down shafts. The idea was that you controlled whether they continued down or got stuck at some point, but I never fleshed it out.

So I’ve been writing down ideas. Should the puzzle area be a grid that just happens to have hexagons? Do I make a hexagonal play area?

More importantly, what is the player doing in the play area? Do I make a match-3? I kind of liked the trapping mechanic, but I couldn’t think of a good way to make it fun.

Then I looked at the calendar and realized that over a week has gone by. So I thought I better steal some game play rather than try to create my own.

I recalled playing a QBasic game by Oren Bartal called Ultimate Super Stack. The point of the game was to trap stars between two objects, and I remember finding it very compelling. Maybe I can make a hexagon-based version of it.

I realized that there was a lot to the game, and I thought back to simpler puzzle games, such as Yoshi for the NES.

So I decided to try to mimic that game instead.

So far, I have four platforms in an empty play area, with a switcher at the bottom.

Eventually, I will add dropping objects, most likely shapes such as circles, triangles, and squares. If two objects match on top of each other, they’ll disappear. If a hexagon’s bottom piece appears, then it’s top piece can close it, along with any objects trapped inside of it.

The player will be able to move the switcher to one of three positions to swap the platforms and any objects sitting on top of them.

It’s a simple game, but I don’t anticipate having a lot of time to create it this month, what with me going to ISVCon 2013. We’ll see how it turns out.

August was a hectic month for me. My wife and I closed on a new house, which meant that most of my “spare” time was spent preparing the house and getting ready to move.

The theme for August was “Philosophy”, and I had originally envisioned a game about making eye contact with strangers.

I wanted to have a very dark room, so you could only see yourself and your immediate surroundings. You can tell where the other people are because their eyes would be the only visible feature, similar to what cartoons did to show people walking around in dark rooms.

I wanted the eyes to be incredibly expressive. They should communicate attraction, danger, and sadness.

I thought that the goal of the game would be for the player to navigate a room, avoiding eye contact with dangerous and creepy strangers while trying to make eye contact with a potential romantic partner.

As you got closer to other people, you would see features besides their eyes: skin color, nose shapes, weight, etc.

And these other features wouldn’t matter at all.

That is, you might find that the potential romantic partner is not someone you might normally be attracted to in real life.

But with even less time to work on the game than normal, I had to scrap most of this design. I kept they eye contact idea, though, and I am pleased with what I came up with.

I started with an eye that the player controlled, but eventually I realized that for the game I was creating, there was no reason for the player to be an eyeball. It was too confusing when you couldn’t easily tell your character apart.

I made the eyeball a “guardian”, rotating around while the player tried to pick up squares in the area. When the guardian spotted the player, it would freeze for a second, then shoot towards the location. If the player touched a guardian, it was game over.

To add challenge, when a guardian shoots off toward the player, it would also leave behind a clone, so now there were two guardians looking for the player.

As you can see above, the game got exponentially difficult.

So I made one more change:

When smaller guardians touched, they combined into a larger guardian which constantly chased the player. This change solved the issue of too many multiplying guardians while also providing a different challenge to the player.

Finally, I made the pick up item look significantly different. A white box in a sea of eyeballs didn’t stand out enough, so I made it the same color as the player and also pulsated it. The animation made it stand out nicely.

I would have liked to have added a third type of challenging guardian, or added some way for the player to remove guardians. I would have also added sound effects and particle effects, but I ran out of time.

Despite not having a lot of time to dedicate to it, I really like Eye Contact. It’s one of my favorite #1GAM entries. There is something disconcerting about all of these eyes looking for you.

I’ve been working on Shipwrecked since June. Even then I realized that it was very ambitious, but rather that continue to work on it throughout the rest of the year, I’m going to call what I have done and move on.

It’s amazing what a deadline can do to productivity, though. In the last few days of the month, I managed to add the ability to create objects, sleep, and go fishing.

I created a number of new objects, including sharp rocks, fishing poles, and opened coconuts.

The crafting screen tells you what you can make and what you need in order to make it.

Fishing doesn’t work quite as well as I’d like.

It’s too easy! Fish seem to sail onto shore for you, and I would rather it be more difficult, requiring patience and time.

If I had more time to develop this game, I know of a number of things I wanted to add:

Daily stamina, which reduces as you take actions, such as walking with heavy items or swimming, and requires rest to recover. Right now, sleeping simply fast-forwards time.

Food spoilage.

Encumbrance. I added weights to the objects, but the player can still carry an unlimited amount. I would like it if swimming was more difficult with too many items, for instance, so drowning is more likely.

Disease.

Weather, such as extreme heat, rain, and bad storms.

Other entities, such as sharks to pose as water hazards and crabs to be dangerous food sources.

Injuries.

Thirst.

Caves to explore.

Debris, such as crates floating to shore from presumably sunk ships. Suddenly life on the island is more interesting when combing the beach results in finding bottles of wine or magazines.

Morale and sanity. I had a vision of the player going insane the longer he/she survives. Insanity would manifest as coconuts being the heads of people walking around the island, for instance, or objects such as rocks suddenly being seen as edible.

I took cues from Harvest Moon and NetHack primarily, plus I always liked the book Robinson Crusoe.

I learned that surviving on a desert island is a very common theme in games. For example, Stranded by Unreal Software was released in 2003.

Most recently there is Wayward, and when I learned of it, I almost lost motivation to continue work. Here was a game that was a very in-depth, turn-based version of what I wanted to make, although I had no intentions of adding bears and giant spiders.

I also felt bad because I realized that I needed to provide a way to create objects, and adding a crafting element to the game made me feel like I was copying the big trend since Minecraft became famous. It seems as if every aspiring indie game developer is making a procedurally-generated world in which you have to use nearby resources to survive.

As for this game, despite working on it for almost 50 hours across two months, I’m afraid it doesn’t have a lot of depth. The island has its objects randomly generated within it, but it’s not a very interesting algorithm. I would have liked to have created an expansive island to explore, with jungles and cliffs, but for now, the island is populated with random trees, boulders, shells, branches (where are the trees that made those?), and empty nets.

Of course, it’s only 50 hours. I’m sure if I worked on it full time in a given month, I could have accomplished much more, and if I dedicate multiple months to working on it, I could have something richer.

So on that note, I got quite a bit accomplished for this project. B-)

What I learned, however, is that even if I have plans for a lot of inter-dependent systems in a game, I should implement one to completion before moving on to another. It took way too long after I coded in a system for hunger and starvation for the player to have a way to avoid such a death, for instance. If I added hunger, I should have added food right away. In a similar way, I created a lean-to because I had plans for a need for shelter, but I never did put in any reason for a shelter to exist. A number of items become merely ornamental as a result.

All that said, I really enjoyed making this project. I hope I come back to it in the future and flesh it out more fully.

Get 40% off of my strategy game that puts you in the role of the villain by using coupon code BIRTHDAY2013 at http://www.StopThatHero.com to help me celebrate my birthday tomorrow!

Next, you can finally eat something in Shipwrecked, my July One Game a Month project.

While the game has let you starve to death slowly for some time, there’s been no way to avoid it until now.

I had a vision for an entire inventory system to manage, but in the interests of finishing this project, I’ve decided that pressing Tab is enough to cycle through any items you are carrying.

If you have an edible object in your inventory, and it is the currently equipped item, you can now use the Eat action.

I also added a few more items to the game, such as bottles:

My plan is allow you to fill bottles with liquids, but you shouldn’t fill it with sea water, which will actually dehydrate you. Which means I’ll need to make some fresh water somehow.

Which brings me to the problem I’ve been having with the creation of this game.

I have less than a week to get this project done by the end of the month, but there is still nothing really interesting to do yet in the game. I think if I learned anything from this project so far, it’s that you shouldn’t try to address an entire game’s features at once.

For example, when I added hunger to the game, I should have followed through with creating food, and then creating the ability to eat that food. Instead, I had various aspects of the game in various states of completion.

I have a lot of ideas and plans for this project, and I might be falling in love with it, which makes it hard to let go.

I’ll have to finish a minimal version of Shipwrecked for now so that I can come back to it another day.

No, no, Shipwrecked. Don’t speak. This thing is bigger than either of us.

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.