csanyk.com

video games, programming, the internet, and stuff

Tag: game design

Adventure (Atari, 1979) appreciated

Adventure is commonly regarded as one of the best games on the Atari 2600, and is certainly a top original title for the console. Out of all the games released for the system, this one stands out as being the one that best represents what was unique to the system.

A great introduction

It’s also a fantastic example of game design, with a built-in tutorial. Super Mario Bros has been recognized as having an excellent introductory level for teaching the fundamental concepts of the game, but Adventure did this just as well a good five+ years earlier, with game variation 1. Intended to be an easy difficulty version of the game, suitable for young children, it also works as a way to introduce the gameplay basics to new players of any age.

In Game 1, you start out in front of the Gold Castle, right in front of the gate.

This communicates to the player that this is your home base. The castle is locked, but the Gold Key is conveniently right there on the screen. Since the key and the castle are the same color, this communicates a strong clue that the key must unlock the castle. Since there’s an item in the starting room, and that item is usable in that very room, every basic element of the game is present on the first screen, so the player has the opportunity to learn the game immediately, before they start wandering and get lost.

If the player grabs the key and opens the castle, very likely they will enter inside, where they will find the Sword. The player may drop the Key by pressing the button, but more likely will run to the Sword and pick it up, and in so doing discover that picking up one item drops an already-held item. Either way, the player learns an important aspect of the core mechanic of the game, carrying an item.

This rewards the player for exploring, and for solving a simple puzzle with one of the objects found in the Adventure world.

If the player doesn’t enter the castle, regardless of which direction they explore, they will run into one of the two dragons: left, and they will encounter the Yellow dragon, and right, they will run into the Green dragon.

Without the sword, either encounter forces the player to run away, or be eaten — unless the player is carrying the Gold Key, in which case the Yellow dragon will flee from him.

Whichever is the case, something unique and different happens — thus demonstrating to the player that the inventory of items found in the game each change the game in distinct ways.

This is enough to encourage the player to experiment with each item they find in the game, in order to discover all the possibilities. But some of the most interesting special item properties in the game are introduced right away.

If the player has the sword, what happens will depend on the difficulty switch position, and the orientation that the sword is held.

If the right difficulty switch is set to A, dragons will flee from the Sword. If set to B, the dragons attack.

If the player is positioned such that the sword is between him and the dragon, the outcome is almost certain victory for the player as the charging dragon runs straight into the sword and dies. Thus, the game teaches the player how to kill dragons in a basic, direct way.

Otherwise, the combat can get exciting, as the player must dodge and move to touch the dragon with the Sword. In other variations, roaming dragons can and will often randomly encounter the player, coming at him from any angle, and this is good practice for such situations.

Again, the game design subtly hints the player toward the more exciting combat — the Sword sprite is always positioned with the hilt to the left, blade to the right. Despite the fact that the player can pick up the Sword (or any of the items) from any direction, most new players will instinctively grab the sword by the hilt-end, which will put the player in front of the sword when they encounter either dragon, making for a more challenging and more interesting combat.

If the right Difficulty switch is set to A, dragons flee from the Sword. Otherwise, they will directly charge the player. If the player is carrying the sword on the side the dragon approaches from, the combat is usually over quickly, as the dragon impales itself on the sword, and is slain.

But if the dragon flees, the player will have a much harder time slaying it — it will take a bit of luck for the player to enter the room positioned in such a way to have a chance at reaching the dragon with the Sword before it runs away. It’s very difficult to do this. One tactic that is effective is to walk near the edge of the screen, such that the Sword is actually off the edge of the screen, then wait for the dragon to approach near, and then attack.

If the player encounters the Green dragon, they will find the Black Key, which the dragon guards. The dragon guards the key, which is positioned on the left side of the screen, so will always charge the player from the left when the player enters the room from the top of the screen.

If the player runs away, the Green dragon will not give chase, as it is programmed to guard the black key, and will stay on the same screen as the key. This gives the player the ability to flee and return to the room repeatedly, and try several approaches to dealing with the dragon.

If the player grabs the Black key before running off, he will be pursued by the dragon.

If the player encounters the Yellow dragon first, the dragon will chase the player from screen to screen, as the dragon does not have an item to guard. But if the player happens to be carrying the Gold Key, this will scare the Yellow dragon off. If the player has entered the castle and grabbed the Sword, the Yellow dragon will approach the player at a slow, deliberate pace, and attempt to eat the Player. If the player is grabbing the sword by its “hilt” side, the player will be to the left of the sword, and this will cause the dragon to trigger its bite attack before it runs into the sword and becomes slain. Thus, the player will learn a) how the dragon moves and attacks, b) that the dragon is temporarily invincible while it in its bite attack mode, but also temporarily fixed in place, and c) that the dragon is dispatched by the Sword by touching it.

If the player is grabbing the sword from its right side, he may slay the dragon directly, without triggering its attack; in this way the player discovers that the sword is lethal regardless of its orientation. Later, the player may discover that the sword is always lethal to dragons, even if it is not in the player’s hand! This is perhaps surprising, but it is highly useful knowledge once discovered, as the player may run around the sword while carrying another object, and lure a pursuing dragon to run into the sword, killing itself.

Once both dragons are dead, the game is easily winnable. The player simply has to take the Black Key to the Black Castle, unlock it, retrieve the Chalice, and bring it back to the Gold Castle, and the game is over.

In order to do that, however, the player must first solve the blue labyrinth. The labyrinth is illogical — it is comprised of 6 screens of interlocking passages which cannot be mapped onto a Euclidean plane.

When you try, certain pathways overlap others, creating a bizarre, confusing maze. The maze is actually fairly easy to traverse, but how the different screens connect to each other don’t quite make sense — space here is warped, somehow.

There are several pathways through the labyrinth, but only one will take you to the Black Castle. 

However, due to the placement of the Bridge, there’s a second possible way through the labyrinth. In the first room of the Blue Labyrinth, there are four branching paths: left is the true path through the Labyrinth; right is the secret Bridge shortcut, and the middle two paths loop around to connect to each other, returning the player to the start of the maze.

So, regardless of the direction chosen by the Player, they’ll either a) quickly loop back to the start of the labyrinth, where they can start over without a lot of frustration or risk of getting hopelessly lost, b) go left and make their way through the labyrinth to discover the Black Castle, or c) go right and discover the Bridge shortcut, and a shorter path through the Labyrinth to the Black Castle.

This again shows good design, by demonstrating to the player a) how the Bridge functions, and b) a reward that shows how the Bridge can provide an advantage to the Player, thus demonstrating its value. It’s likely that the player will inadvertently touch the Bridge as they pass over the wall, and thus discover that the Bridge may be picked up like any other object, and that its portability makes it even more useful.

When the Player discovers the Black Castle, they’ll probably know immediately what the Black Key is for, and if they don’t have it with them, will know from their experience in the first screen that they will need to go back to retrieve the Black Key in order to proceed. If the player has yet to encounter the black key, their previous experience with the Gold Castle will have taught them that this Castle must also have a Key that will open its gate, found somewhere.

Upon unlocking the Black Castle, the Player enters into a room where they discover the Magnet. It’s common for players to drop the key upon entering the castle, perhaps in order to retreat and grab the Sword, which they may have also brought with them, just in case there is another dragon to fight — and if they do drop the key, they’ll immediately discover what the Magnet does: attract other objects.

The Player may pick up the Magnet and interact with it, dragging it around as it slowly attracts the key to follow it about the room. This invites the Player to see what else the Magnet will attract. (It works on all the other items in the game, but not the dragons or the Bat.)

When the player proceeds to the last room of the Black Castle, they’ll find the Chalice. From here, all they need to do is bring it back to the Gold Castle, and they win the game. There’s nothing in the game to tell the player that they need to do this, but it is provided in the written instructions pamphlet that comes with the game.

Otherwise, the purpose and use of the Chalice is mysterious. The Chalice is unlike the other items in the game, in that its color flashes and shimmers. This makes the Chalice stand out as a special object, and probably more likely for the player to pick it up, even if they skipped reading the instructions and don’t know what to do with it. Since it flashes a golden color, that may be enough of a clue to the player that they should bring it to the Gold Castle, as they did with the Gold Key.

Once the player knows what to do, they can complete Game 1 in a minute or less. Even without knowing what to do, it’s likely that a first time player can complete the quest in just a few minutes.

The tightness and self-teaching design of Game 1 of Adventure is nothing short of impressive. Considering how early this game came out in the life of the system, the level of refinement present in the level design is amazing. As obvious and intuitive as the placement of the objects and dragons is, we must recognize that these were the result of deliberate design choices, and that any other arrangement would have made the introductory level of the game less inviting, less intuitive, and less fun.

Advanced Adventures

Game Variations 2 and 3 introduce the player to a larger world, with a third castle (White), and two Catacombs (in the Black Castle, and en route to the White Castle). The White Castle itself adds another Maze, and in total the world has about doubled in size.

The Epic Quest

Game 2 is the canonical full Adventure experience. You have to visit every castle and use every item in order to complete the quest. This game introduces the Bat, which appears on the start screen, and swipes the Sword which appears where the Gold Key was in Game 1.

The timing here is tight enough that it must have been deliberate — try as you might, there’s no way to beat the Bat to the Sword. It will get there just barely ahead of you no matter how fast you can get there. 

Another thing about this introductory encounter: the Bat continues in a straight line, continuing to wrap from bottom to top of the screen in an endless cycle, which lasts until the Player either leaves the room, or touches the Bat or the Sword. 

Because the Player has learned the value of the Sword, very likely they will try to grab it and fight the Bat for control of it. The screen wrapping behavior of this initial encounter invites and practically guarantees that this will happen. The Bat is programmed to win these contests, thwarting and frustrating the player.

This teaches the player everything they need to know about the Bat, immediately: the Bat steals the item you need.

Best case, you can grab the Bat, and carry it with the sword until the Bat either drops the sword, or picks up another item. If the player does manage to grab the Bat, capturing it, sometimes it can struggle free, often at the wrong time.

Going to the right, where in Game 1 you found the Green dragon guarding the Black Key, you’ll encounter the Catacombs that lead to the White Castle. In the Catacombs, you’ll find the Yellow Key, the Bridge, and in the room South of the White Castle, the Magnet. The Green Dragon is wandering nearby, and will likely encounter the Player in a situation where the Bat has dropped the Sword, and picked up one of the other items.

If you’re lucky, you may dispatch the Green Dragon in the catacombs without much trouble, but it’s just as likely that you’ll get stuck in the catacombs without the Sword, which is very dangerous — especially prior to learning how to navigate the catacombs. If you can, kill the Green Dragon as quickly as possible, but if you lose the sword, try to grab the Gold Key and run for it so you can at least get the Gold Castle open. The Green Dragon will always guard the Magnet or the Black Key, so you can use the Magnet to “trade” for the Gold Key so he’ll ignore you while you run to the Gold Castle and unlock it.

Here, the Player is carrying the Bat, who is carrying the Bridge, just after the Player killed the Green Dragon with the Sword. With so many objects on the screen, they flicker, so this is a composite image of several screen captures.

The White key is found in the Blue Labyrinth along the path to the Black Castle, and inside the White Castle is the Yellow Dragon, and the Black Key. If you’re new to Game 2, you’ll probably head up the familiar path to the Black Castle, and discover the White Key here.

You’ll need to run with the White Key to unlock the castle, then come back with the Sword so that you can face the Yellow Dragon and slay it. If you can, once you open the Gold Castle, go back and grab the other items in the game and bring them to the Gold Castle. The Bat does not enter the Gold Castle ordinarily (he will only be found there if you grab him and drag him there yourself) so anything you store in the Gold Castle is generally safe from the Bat randomly picking it up and moving it somewhere.

If you can, put the Sword in the Gold castle for safekeeping, and then go unlock the White Castle, run back to retrieve the Sword, and return to the White Castle and slay the Yellow Dragon. The White Castle’s maze is divided into two interlocking sections. To get to where the Black Key is, you’ll need the Bridge.

To get the Black Key, you need the Bridge, and the insight that the maze is larger than it seems.
The Black Key is well-hidden inside the inner chamber of the White Castle maze.

Once you have the Black key, you’re ready to take on the final challenge. Take the key to unlock the castle, then return to the White Castle and grab the Sword, and return to the Black castle. You’re about to face the Red Dragon, who is the fastest and fiercest of them all. He guards the Chalice in the catacombs of the Black Castle. All you have to do is kill him and take the Chalice. Fighting this dragon in the tight confines of the catacomb is tricky, but not too difficult. Just keep the Sword between you and the Dragon.

Once the Dragon is defeated, there’s nothing left to threaten you; run back to the Gold Castle with the Chalice and win the game.

The way this variation is laid out guarantees the player will take the longest path through the game, and experience all of it. It’s well designed from that standpoint. The Bat’s mischief can greatly lengthen the time taken to complete this quest. It’s very common for the Bat to grab the item you need right when you are about to use it, and leave you with something you don’t need, or even bring a live Dragon to eat you! If you’re accustomed to the layout of Game 1, you’ll probably spend a lot of time exploring the Blue Labyrinth, where you’ll find nothing of value, only dead ends. But by exploring the new catacombs area, you’ll quickly find most of the items in the game, and it’s just the chance interactions with the Bat, and the risk of being caught without the Sword when a Dragon draws near that can lengthen the game.

The randomness of the Bat makes Game 2 somewhat different each time you play, but the initial position of the items is always the same, and the order in which you must unlock the castles always is the same. So playing this variant repeatedly doesn’t offer a lot of replay value. Even so, the random element introduced by the Bat still gives this variation a decent amount of replayability.

The Random Remix

Game 3 randomizes the starting position of every item in the game. There are a few constraints, of course: no key can be locked in its own castle (although, there is a bug, by which the Gold key can sometimes start out locked in the Gold Castle, rendering the game unwinnable), the Chalice never can start in the Gold Castle, but otherwise everything is random. It can happen that you start out getting attacked by all three Dragons immediately, with no Sword in sight to save you. You’ll have to explore everywhere and anywhere to find the Chalice, and the items needed to get to it.

This is my favorite variation of the game. It’s the most replayable, because every time you play you’ll have to figure out where things are and which ones are needed in order to unlock the Gold Castle and retrieve the Chalice — the only two things in the game that you must do to win. Everything else is optional. And due to that fact, it’s often possible to complete the quest more quickly than is possible in Game 2.

Screwing Around

Once the Dragons are killed, the Player is safe. This frees him to explore the game and experiment. The Bat can get annoying, but it’s fairly easy to grab it, run to one of the castles, and lock it inside.

It’s an interesting discovery that you can carry the Bat into a castle, run out quickly, locking the gate behind you, and never have to see the Bat again. The insight may be learned by the fact that in Game 2, the Yellow Dragon never appears in the game until you unlock the White Castle. Since that is the case, the Yellow Dragon must have been confined in the White Castle. Might this work with the Bat also? It does!

It’s also possible to gain this insight by locking a Key in its own Castle. It’s possible! To do this, you need to touch the open castle gate with your Key, which causes the gate to lower. If you drop the key in the doorway, as the gate lowers, the Key will disappear, apparently into the castle. Now behind the locked gate, the key and anything else inside that castle is forever locked, inaccessible to the player evermore.

At this point, Adventure becomes a sandbox game. You can play around with the items and figure out all kinds of things to do with them. Mainly this means playing around with the Bridge and Magnet. The Bridge may be placed at various walls, and you can even try to use it to cross the boundary of a room that is normally blocked by a solid wall. This sort of, almost works — you can see into an adjacent room this way, but not quite enter into it.

Experimentation is at the heart of what makes Adventure special.

Eventually, through much trial and error, but more likely through reading about it or being shown by someone who knows, you may discover the Easter Egg, the hidden room with the Dot, which is used to access a secret room where the author’s name is hidden.

Items with purpose

One of the great aspects of Adventure is how purposeful every item and character in the game is. The items in the game give the player the capability to do anything they might need to do, and give the game’s design a sense of completeness. There’s nothing missing, and nothing obvious to add. 

Keys unlock Castles, and there is one key per Castle. They give the player something to find and something to do in order to access parts of the map that are locked when the game begins. They give the Dragons something to guard (or flee): The Yellow dragon runs from the Gold key; the Green dragon guards the Black key, and the Red dragon will guard the White key.

The Dragons exist to create danger and tension for the player, something to overcome and defeat. They make Adventure be a game about more than simply exploring.

The Bat exists to give the game randomness that makes the game world feel “alive” as the Bat randomly moves items around the world, which would otherwise only move if the Player moved them. The Bat is a mischievous and frustrating enemy, who cannot be killed, but may be dealt with by locking it in a castle. The Bat makes the Dragons more dangerous while they’re alive, since it can take the Sword or bring a Dragon at an inopportune time. But the Bat’s randomness also means that it can sometimes aid the player, by taking a threatening Dragon away, or dropping a needed item that the player had trouble finding. This redeems the frustrating aspect of the Bat, to a degree, and makes it an entertaining character.

The Sword gives the player a way to defeat the dragons.

The Magnet gives the player a way to grab items that are stuck in walls, or otherwise inaccessible, making it much less likely that the player will get stuck in an unwinnable situation due to a trapped object that they cannot reach.

The Bridge serves a similar purpose to the Magnet, in that the Bridge can enable to Player to get around dead Dragons that may block narrow paths. But the Bridge also has several specific purposes: A) To enable a short-cut to the Black Castle by Bridging over the dead-end of the right branch of the Blue Labyrinth; B) access the inner chamber of the White Castle maze, necessary to complete the quest in Game 2; C) to reach the hidden room in the Black Castle labyrinth, where the Dot is hidden, necessary to unlock the now-legendary easter egg and find the secret screen with the creator credits. 

The Chalice gives the player a goal, and something to do to give the game an ending. The existence of the Chalice makes the game about more than merely exploring, more than merely slaying dragons. It gives the player a quest and a purpose.

Speculating on a Sequel

Adventure has been a frequent target of homage for homebrew and hacks and indie game developers. I don’t know how many projects I’ve seen over the years that took direct inspriation from Adventure, but I can recall a Quake mod from 2002, and unofficial sequels for the Atari 5200 and Atari Flashback system, a pair of homebrews called Evil Magician Returns and Evil Magician Returns 2, and certainly others too obscure for me to find with a quick search.

I’ve played some of them, and of those that I have played, I have found them to be lacking in some way — they just don’t feel as good as the original, for various reasons. Either they offer more of the same, without offering enough new, or they attempt to update the graphics in ways that spoil the utter simplicity of the original graphics. The graphics weren’t really the point of the original — the Player is represented by a simple square pixel, after all — and so I would like to see a sequel that focuses on gameplay, but retains the graphical style and overall feel of the original, but adds new items and new areas to explore.

Making it my own

I think anyone who loved the original has probably thought about what they’d want in a sequel. So in that spirit, here’s my proposal for how I would extend the original game. Perhaps I’ll try to program it at some point.

My idea is more like a “Game 4” variation of the original than it is an Adventure II. A “Game 5” variation would be a randomized version of the game with all of the elements from Game 4, much as Game 3 is a randomized version of Game 2.

Here’s what I would add:

  • There are three empty rooms in the area (Marked 1, 2, 3 in the map below) where the White Castle is found:Adventure MapThese feel like unfinished, purposeless rooms in Adventure. This is where I would extend the world map. I would replace these empty rooms with entrances to new mazes that lead the player to new areas of the game. Perhaps I’d have all three entrances lead to three inter-twined mazes, which require the use of the bridge to go between them. The Brown Key would be hidden somewhere in this new maze. The exact details of the maze aren’t shown, but the maze would occupy the empty region shown in the map detail below, with the new Brown Castle somewhere in there, perhaps where indicated… but possibly not.Adventure-Variation 4 Detail
  • I’d add at least one new castle, but probably just one, found at the other end of one of the mazes. The existing castles are White, Black, and Gold, this castle would be some new color. Which color? It should be a color that is possible with the Atari 2600, and not already in use as a Castle or Dragon color, or a color that is close to one of those colors. This rules out Green and Red, Yellow, Black, and White. Probably a good color for a fourth castle would be Blue, or Brown.
  • I’d add a new Dragon. The existing Dragons are Red, Yellow, Green. The new dragon should be a color that is possible with the Atari 2600, and not already in use as a background or Dragon color. This rules out: Black, White, Gold, Yellow, Green, Red, and Blue. I’d also avoid Purple, since that’s the color of the Bridge.
  • The trick with the colors is that the Atari 2600 can only produce 128 distinct colors in NTSC, as shown by this chart. While the RGB color space isn’t exactly gamut compatible with what the Atari 2600’s TIA chip generated, this is close enough for our purposes.
    Atari 2600 NTSC paletteThere are only 16 hues to choose from, and we don’t want to pick something too close to what’s already in use. This may not be exact, but my best guess as to which colors are already reserved in Adventure is as follows:
    There’s a lot of possible colors still available, but many of them are too light or don’t contrast well enough. But a purple, green, aqua, or brown would seem to be the best candidates. Brown seems like a good choice for a Castle, or Blue, while an aqua or orange shade seems like the best choice for a Dragon.
  • Spider Spider (New Character). The spider’s purpose is to create Webs. Like the Bat, the Spider is black. The Spider cannot be killed. Can he be picked up and carried? I haven’t decided — probably not, just to make him different from the Bat. The Spider lurks in the Brown Castle, spinning webs inside, making the catacombs inside the Brown Castle more challenging to get through. When the Brown Castle is unlocked, the Spider is set free, and can roam about the rest of the world.
  • Web WebWebs are obstacles which slow the player down, but do not block him. Webs will stick fast to any Object in the game, so that they cannot be moved, will not be attracted by the Magnet. When the Player is holding the Sword, he can cut through the Webs, so moves at normal speed. Cutting the web destroys it, freeing up any trapped objects so that they can once again be picked up and carried, or moved by the magnet. Dragons ignore Webs, and are not impeded by them. The Bat can pick up a web and move it to another part of the world. The Bridge can be used to navigate over webs without being slowed down.
  • TorchNew item: The Torch. The Torch serves to light up catacombs areas, making them easier to see in when present. It can also be used to destroy Webs, by touching them. The Torch will destroy Webs whether or not the Player is holding it, and the Torch will light up a catacomb maze whether or not the Player is holding it. The Bat may pick up the Torch. The Torch is found in one of the new maze areas in the game. This maze area is very dark, and has the shortest catacomb sight radius yet, when the Torch isn’t present.

Anyhow, this idea isn’t quite fully formed, particularly in terms of the map. But as a general sketch of a concept for an extended “variation 4” game, I think it’s got potential. I think the Torch and Spider give the game new features that have purpose, without wrecking the balance of the existing items.

Who knows if I’ll develop it — it’d definitely be a challenge to build.

Pixel Art Chess Set: Communicating function through design

My five year old nephew started learning to play Chess recently, as I discovered on a visit a few weeks ago.  We played two games, and I didn’t have too much trouble beating him, but for a five year old he’s not bad. He knows all the pieces and their basic moves and their relative value.

I thought it would be fun to build a video Chess game that he could use to help learn strategy and how to see the board. So this is my latest project. I’ll be posting more about that as I work on it.

My first step was to design graphic resources. I didn’t want to spend too much time on it, just a basic “programmer art” chess set, that I could use to build the program with. Of course, it didn’t end up that way, and I’ve gone down the rabbit hole designing variations on sets of minimalist pixel art chess men. It’s too fun and fascinating not to.

My first attempt was actually rather good, I thought. I went for 16x16px representations of the classic chess pieces. I drew them very quickly, but was very pleased with my results, particularly the Knight.

I could have stopped right there, but it was so fun to make this set that I wanted to continue exploring and see if I could refine my pixeling technique further.

I decided to search the net for images of chess pieces to see what variety there was, and found a lot of examples of beautiful sets. I started to take notes and to infer design rules for chess men:

  1. Chess pieces are called “chess men” which seems antiquated and sexist, especially given that the most powerful piece in the game is the Queen.
  2. The modern standard chessmen are a design named for English chess master Howard Staunton, and have been in use only since the mid-19th century. A strength of its design is that each piece is easily distinguished from the others, making errors from mistakes in identifying a piece — a problem with other sets — unlikely. Previously, chess men of different types had a less distinct appearance from one another, and were not as standardized.
  3. In a Staunton set, the Knights are the most detailed, ornate, varied, and realistically represented pieces. 
  4. In Staunton sets, there is a standard height order: pawn, rook, knight, bishop, queen, king. (This surprised me, since Rooks are more valued in Chess I would have expected them to be taller than Bishops.)
  5. The pieces are differentiated by their tops. Each type of piece has a distinct, unambiguous shape.
  6. The body/base of the pieces have a common design, to create unity among the pieces in the set.

I tried to apply design choices to my chess set following these insights.

A follower on Twitter offered feedback that the pieces should be different heights, so I tried that. With a 16×16 pixel tile size, I could only shorten the back row pieces by 1-3 pixels.  I also tweaked the King piece by adding a few more pixels to its top, to make it a bit more distinct from the Queen, and moved the Pawn so that it wold be more centered in its square.

I do like the result:

Staunton pixel chessmen

I think my initial 16×16 Staunton set look like they’re in ALL CAPS, while this set is more “readable” by using “mixed case” heights for the pieces.

I wanted my chess game to be focused on usability and instruction. I needed each piece to be immediately recognizable, and not to convey a bunch of extraneous information to the player that has nothing to do with play mechanics. 

My next attempt was a different take altogether. I wanted the look of each piece to suggest its rules for movement. I also thought that it would be clever if the pieces communicated the rules for using them through their visual design.

I ended up being very pleased with this set as well, although I went through many more variations, particularly with the Pawn. This one also came together easily and rapidly.  When your tile size is 16×16 and you’re working in just a few colors, it’s easy to work fast.

Things I like about this set:

  1. The shape of the piece is a built-in tutorial for how the piece moves.
  2. The Pawns still have a pawn-like shape (at least the black pawns; white pawns are “upside down”).
  3. The Knight’s shape may be read as an abstraction of the horse’s head shape of the Staunton piece.

I think out of these variations, my favorites are: P9, Kn2, B3, R1, K?  I’m least certain which King I like.  I think K4 and K5 are my top two, but I also liked the idea of incorporating a crown motif into the design, to signify the King’s special property of being the King.  K1, K2 and K6 were attempts at this, but I think K1 looks too much like a Staunton Rook, unfortunately.

I wasn’t sure which of my designs to use for my final set, so  I posted my sets on Twitter and a pixel art community on Facebook. @Managore responded to my request for feedback by coming up with a set of his own design, which I quite like.

His design was retweeted and liked over 500 times, and received many positive compliments from his followers, many of whom are game developers. One of my favorite indie developers, @TerryCavanaugh, who made VVVVVV and Don’t Look Back, pointed out an physical chess set that had been designed a few years ago which incorporated the same ideas.

It’s exciting to see my idea get picked up and reworked by fellow game developers who are inspired by the concepts I am exploring. So fun! Getting that validation that what I’m working on is interesting to others is very motivating. But it’s particularly good to get some attention from developers whose work I’ve admired for years, however modest.

I’m excited about this project and look forward to working on the program. I have more design ideas that I’m looking forward to getting into soon.

Ability use frequency vs. payoff in the original Legend of Zelda

My friend Douglas Underhill wrote an interesting article about game design, dealing with the frequency of an ability’s use with its reward payoff. Doug’s question comes down to, given that there are hundreds of abilities to potentially pick from in character design, and that certain abilities are either useful much more often and in a much wider range of situations, or else provide a much greater payoff than others, what can be done in designing the rules system and/or world to encourage diversification in putting a finite amount of skill points into skills that are useful less often, or which provide a lower expected payoff.

Underhill asserts that, ideally, less-used abilities should be higher in their payoff, in order to encourage players to put character building points into them at all, while frequently used abilities should be low in payoff, to offset their wider applicability and to prevent the game from falling out of balance. But it’s an inherent problem because the feedback of high reward will encourage the use of an ability.

Essentially, though, game design encourages the use of abilities that grant a high reward, and the higher the reward, the more likely the player is to use and rely on that ability (barring some other limiting mechanism that mitigates or suppresses over-use).

But beyond unbalancing the game, or making the player’s strategies predictable and boring due to min-maxing, the reward weight/use frequency of abilities in a game’s design will determine and shape what the game is about. Dungeons and Dragons is nominally about role-playing and fantasy adventure, but its rules systems make it a game largely about dice rolling and fantasy medieval combat.

Tabletop RPGs are inherently flexible, though, so a given group of players might opt to make their game (or at least a particular game session) about negotiation and barter in a fantasy medieval economy, and there’s nothing wrong with doing so. But it’s much more likely that the typical group of D&D gamers will spend most of its time fighting and questing for objects and abilities that make them ever better at fighting and surviving in exotic, hostile fantasy environments.

After reading Doug’s article, it got me thinking about how this principle applies in video game design. (more…)

Math every game developer should know

[Editor’s note: For now this is kindof a stub article.

I’m brain dumping a list of math that I use all the time (or would like to) in making video games.

For now, it’s just a list of areas of math that come in really handy, again and again, with many games. I won’t try to put lessons into this article; this is just a list of topics to check into.

I’d love to grow this list! Leave a comment, or contact me with suggestions for more math to add.

Over time, I’ll probably flesh this out with a list of gamedev-specific uses for each type of math.]

  1. linear algebra

  2. trigonometry

  3. stochastic functions (randomness)

  4. probability

  5. permutation

  6. matrix algebra

  7. fibonacci

  8. statistics

  9. binary and bitwise math

Fun enum ideas for game development

Most video games have a counting, ranking, or level system of some sort. It’s often good to have a thematic flavor to your counting systems. This way, rather than calling your level progression by boring old regular numbers, you can give each level number a meaningful, or flavorful, name. This can add character or meaning to your game world, or it can be used to help disguise the underlying math, resulting in a game where the underlying mechanics are masked away from the player, leading to a more mysterious experience where they need to experiment and discover. What’s cooler: a “level 3 sword?” Or “the sword of autumn?” What’s more powerful: the knight sword or the rook sword?

To that end, I thought I’d demonstrate a few example enums that you can use to spice up your game design.

ENUMerate all the things!

Alphabet {A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z}

Greek Alphabet {Alpha, Beta, Gamma, Delta, Epsilon, Zeta, Eta, Theta, Iota, Kappa, Iota, Kappa, Lambda, Mu, Nu, Xi, Omicron, Pi, Rho, Sigma, Tau, Upsilon, Phi, Chi, Psi, Omega}

Military Phonetic Alphabet {Alpha, Beta, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliett, Kilo, Lima, Mike, November, Oscar, Papa, Quebec, Romeo, Sierra, Tango, Uniform, Victor, Whiskey, Xray, Yankee, Zulu}

Army (simplified) {Private, Specialist, Corporal, Sergeant, Officer, Lieutenant, Captain, Major, Colonel, General}

Navy (simplified) {Seaman, Petty Officer, Ensign, Lieutenant, Commander, Captain, Admiral}

Chess {Pawn, Knight, Bishop, Rook, Queen, King}

Rainbow {Red, Orange, Yellow, Green, Blue, Indigo, Violet}

Elements {Earth, Air, Fire, Water}

CardRank {Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King, Ace, Joker}

CardSuit {Clubs, Diamonds, Hearts, Spades}

Zodiac {Aquarius, Pisces, Aries, Taurus, Gemini, Cancer, Leo, Virgo, Libra, Scorpio, Sagittarius, Capricorn}

Seasons {Spring, Summer, Autumn, Winter}

Months {January, February, March, April, May, June, July, August, September, October, November, December}

Weekdays {Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday}

Lunar Cycle {New, WaxingCrescent, FirstQuarter, WaxingGibbous, Full, WaningGibbous, ThirdQuarter, WaningCresent}

Some of these may not necessarily have a natural order to them, but might just be a set of categories which you could use to organize something in your game. That something could be worlds, or items, or creature types, or powers, or anything else you can think of.

What else?

What else is there? Probably a whole lot! You could probably make a good basis for a game system out of gemstones, or metals, or barnyard animals, or anything, really!

If you know of a set of things that would make a good enum that I’ve left out, leave a comment below.

Using enums in GameMaker Studio

Enums are covered in the manual in the article on Data Types.

The basic syntax is as follows:

First, you have to declare the enum.

enum <variable>{<constant> [= <value>]}

You create the enum using the enum keyword, naming the enum <variable>. Then, in brackets, you list all the constants that make up the values in the enum. You can explicitly declare values for the enum constants, or you can leave them implied, in which case GameMaker will assign them integer values starting at 0, and increasing in order through the collection. You can even use expressions rather than a static value.

To access the enum constants, you use the syntax enum_variable.constant.

In your code, there are all kinds of situations where using an enum is potentially useful. Here’s a few things to look for in your code that might signal a good opportunity to use an enum:

Conditionals for checking state

Consider the following ways of checking the state of some object:

//check state using string matching
if state == "state_idle" {//do state actions}
//check state using literal numbers
if state == 0 {//do idle actions}
//check state using variable
state_idle = 0;
[...]
if state == state_idle {//do state0 actions}
//check state using enums
if state == enum.value {//do state actions}

Out of these, using enums is the best approach. Why are enums better?

Conditional checking by string matching is much slower than number matching. Your string value provides semantic meaning to the reader, making the code easier to understand when a human reads it. But when the program goes to check the conditional, it has to check every letter in both strings to see if they match.

As well, this approach is fairly error prone. It’s very easy to type the strings in slightly wrong. If you’re not careful, it’s easy to type one string where the state is assigned, and another string value where you’re checking state in order to do something state-specific. If you don’t catch the error, you’ll have a hard to diagnose bug because the conditional check won’t match what you’ve set the state variable to. One extra space, or misspelled word, or inconsistent use of capital letters, and the string match check will fail. The compiler won’t help you catch this sort of bug.

It’s a lot faster to do conditional checking via numbers. But naming your states with literal numbers: 0, 1, 2, etc. provides no meaning. Is 0 the idle state? is 1 running? is 2 jumping? Keeping track of this stuff in your head makes your work as a programmer harder, and makes the code hard to read, and brittle. You can do slightly better by creating a named variable and assigning the number value to it. The named variable can be expressive, e.g. state_idle = 0, state_running = 1, etc. But variables values can change, and storing each value takes a little bit of memory. By contrast, an enum value is constant — it cannot be changed once it is declared. And enums are global, so they are only declared and set in memory once, and thus require fewer resources. Even if you have ten thousand instances that use your enum, the memory used by them is the same as if there is only once instance.

Create an enum that provides expressive labels on these values, and you have the best of both worlds: expressive code that checks conditions fast, and uses computer resources efficiently.

Iteration over a set

Conventionally, programmers often rely on conventional looping variable names such as i or j to iterate over a collection of things, such as the members of an array, or other data structure. While this is OK, you can make your code more expressive by using enums to denote important numbers.

For example, it’s common for programmers to use a nested for loop iterating over the variables i and j to create a grid structure. Instead of using i and j, we can use variables named row and column instead. As we iterate over the range of rows and columns, we can use enums as flags to do something special at row (or column) == enum.constant.

Another example:

Say we want to implement an inventory equipping system for the player. The character has inventory slots for head, body, gloves, right hand, left hand, shoes. We decide to create an array, called inventory[], and assign the equipped item in each slot.

We could simply index the array with numbers:

inventory[0] = hat;
inventory[1] = armored_breastplate;
inventory[2] = iron_gauntlets;
inventory[3] = sword;
inventory[4] = empty;
inventory[5] = double_jump_boots;

Now, it’s not too hard to tell what each inventory slot is for. But it’s not as easy as it could be, either. Is the sword in the left hand or the right hand?

Let’s use an enum, and make the code easier understand.

enum inv_slots{head, body, gloves, right_hand, left_hand, shoes};
 
inventory[inv_slots.head] = hat;
inventory[inv_slots.body] = armored_breastplate;
inventory[inv_slots.gloves] = iron_gauntlets;
inventory[inv_slots.right_hand] = sword;
inventory[inv_slots.left_hand] = empty;
inventory[inv_slots.shoes] = double_jump_boots;

Now, it’s quite easy to see that the double_jump_boots are being worn on the player’s feet, rather than being carried in the player’s hands. It’s simple to keep track of which slot is which.

Creating a set of related, named values

Here’s a useful enum for direction angles for a top-down game:

enum compass {e = 0, ne = 45, n = 90, nw = 135, w = 180, sw = 225, s = 270, se = 315};

It’s much easier to remember and understand direction = compass.sw instead of direction = 225. You can use this enum for 4-direction and 8-direction movement or aiming, and you could even expand upon it if you wanted by adding constants for ene, nne, nnw, wnw, wsw, ssw, sse, and ese, like so:

enum compass {
 e = 0, 
 ene = 22.5, 
 ne = 45, 
 nne = 67.5, 
 n = 90, 
 nnw = 112.5
 nw = 135, 
 wnw = 157.5
 w = 180, 
 wsw = 202.5
 sw = 225, 
 ssw = 252.5
 s = 270, 
 sse = 292.5
 se = 315,
 ese = 337.5
 };

(I like to format my code like this; lining up the variable names, equals signs, and values makes it easy to scan down the file, and makes it clear that these values are all related.)

If I wanted, I could go a step further and use radians to make it clearer that these values are fractions of a circle:

enum compass {
 e = 0, 
 ene = radtodeg(pi * 0.125), 
 ne = radtodeg(pi * 0.25),
 nne = radtodeg(pi * 0.375), 
 n = radtodeg(pi * 0.5), 
 nnw = radtodeg(pi * 0.625),
 nw = radtodeg(pi * 0.75),
 wnw = radtodeg(pi * 0.875),
 w = radtodeg(pi), 
 wsw = radtodeg(pi * 1.125),
 sw = radtodeg(pi * 1.25),
 ssw = radtodeg(pi * 1.375),
 s = radtodeg(pi * 1.5),
 sse = radtodeg(pi * 1.625,
 se = radtodeg(pi * 1.75),
 ese = radtodeg(pi * 1.875)
 };

You can group together, and name other values that go together in a system using enums in this way, too.

Parting thoughts

Hopefully, these examples will help you see how enums can be useful to make your code more expressive, easier to read, and easier to maintain. Look for opportunities to use them in your code. They can really help!

Stat-Driven Causality: Better than pseudo-randomness!

Watch this video on how the “random” loot drops in the original Legend of Zelda were actually determined:

I found it very interesting. In my game projects, one of the more difficult areas of game design is getting the frequency of the loot drops to feel right.

Let’s look at the ways in which the loot drops in Zelda are not random.

  1. Loot drops happen because of an event, eg defeating an enemy. They don’t happen “randomly” for no apparent reason. This drives a feedback loop of “kill monster, get treasure”.
  2. Which type of item gets dropped is actually not random. However, it’s important for the drop to seem random to the player, so they never can be sure of what they’re going to get. This keeps them guessing and curious: “What will I get if I kill this monster? There’s only one way to find out; better kill it!” invites play much more than “Ho hum, here’s another [enemy]; I know they only drop [type], and I don’t need that right now, so I’ll just walk by it.”
  3. It does seem that certain types of enemies do drop certain types of loot a bit more often. For example, in the overworld Tektites seem to be pretty reliable about dropping rupees, and tend to yield a higher proportion of blue rupees that are worth 5. They do drop other things, bombs and hearts, and fairies, but it does seem like they will drop rupees a bit more than other types of enemies. There may be a similar relationship between other types of enemies and other types of loot. This gives certain areas of the map, where these types of enemies appear, have strategic value for “farming” a given type of resource.
  4. It would make sense that more challenging enemies might yield more/better loot, but I don’t notice this so much when I play LoZ. It seems that as you progress through the game, the difficulty of the monsters ramps up, matching your own power increase, but that the reward remains more or less constant. Still, in many games, there’s a directly relationship between challenge and reward.
  5. By connecting the frequency and type of loot dropped to a complex conditional based on the internal state of the game’s various counts, it’s possible to tune the difficulty of the game to a far more precise degree than could be done through purely random loot drops. For example, if the player is low on hearts, you could use that data to drive a slight increase in the amount of health drops, to make the game easier. Or, to make the game more challenging, you could make health drops rarer when you’re low. This can be tweaked so that “easier” areas of the game have the more generous/forgiving drop rate, while the harder areas have stingy/unforgiving drop rates.

Up until now, I have thought of loot drops as something based on completely random chance, not influenced by various factors being tracked in the game. I had played with various stochastic functions to create what felt like “right” odds to give the game the right “feel”, and wondered why simple random distribution never felt quite right.

But what is “right” is highly subjective, difficult to define, and requires extensive time spent playtesting in order to gauge “feel”. But now, I see a much more interesting potential in tying the frequency and/or item dropped to causal relationships to various stat counters. What’s great about tying the loot drops to in-game stats is that it allows you to directly apply mechanisms to balance the game, based on how the stats reflect the player’s performance, their progress in the game, and the amount of difficulty you want at that point in the game.

Exactly how to do this will still be very subjective, and require extensive play testing, of course, but it will be tune-able and in the control of the developer, rather than purely random chance. I am excited by the possibility of using the stats model to drive feedback loops which can help to govern the game’s challenge level, or to provide certain items when they are more likely to be needed, or just to make the loot drop frequencies seem a little more interesting and less totally random. It seems like a potentially much more elegant way of distributing items in the game.

csanyk.com © 2016
%d bloggers like this: