Tag: game design

Fixing the Weapon Break Mechanic in BOTW/TOTK

The most often criticized feature in Legend of Zelda: Breath of the Wild and its sequel, Tears of the Kingdom, is the weapon breaking system.

I like to put on my game designer hat and come up with ways to improve games, and this is a subject that I’ve thought about a considerable amount off and on since I played through BOTW, and am thinking about more now that I’m playing through TOTK.

So here’s my suggested solution.

I actually like the possibility for weapons to break. I think it does make combat more interesting, and I support Nintendo’s reasoning that the feature gives the player reason to use other weapons than the current best damage weapon in their arsenal, which results in the player experiencing a wider variety of combat mechanics that result from the different properties and behaviors of the different classes of weapons found in the game.

So we’re not ditching the system, we’re going to tune it.

First, let’s recognize that weapon quality should come into play, as it does, but durability should increase much more quickly as weapon quality goes up.

So, at the start of the game, we have what I’ll call “found object” weapons, like the tree branch. These should rightly be very easy to break, in just a few solid hits, as they are.

The next class of weapon above that should be “improvised object”. These are tools, such as brooms, shovels, pitch forks, and so on, which are capable of being used as weapons, and are designed to be durable, but are not intended to be weapons. These should break more easily than a designed weapon, because using them for combat is putting stresses on them that they were not designed for.

The next class of weapon above “improvised” is “crude”. Crude weapons have a primitive look to them, and are built by crude or less skilled means, and won’t hold up as well as a better made weapon. Crude weapons are made of roughly hewn wood, bone, and stone, and not refined metals. Crude weapons can be repaired more frequently, and can be repaired in the field at places similar to the cooking pots found throughout the world. This amounts to “duct tape” level reinforcement of the weapon’s shaft, or the attachment of the weapon’s head to the shaft, for things like stone hammers and stone axes

The next class is “Standard”. Standard weapons are in good condition and should last a long time if properly treated and cared for, but are subject to breaking when abused, neglected, or subjected to abnormal rough treatment. In the game, a Standard quality weapon would be given no “modifier” adjective, eg there would be a “Sword” rather than a “Standard Sword” or “Traveler’s Sword” rather than “Standard Traveler’s Sword.”

Above that is “Quality”. Quality weapons are a bit more durable, and last a bit longer. They are made better, and from better materials. They are rare, and are found only in places like Shrines or stored in chests found in places where they would be well shielded against the elements, such as inside of a cave or building, not out in the open or under water. Quality weapons are often used by enemies of higher status, and can be won through combat against them.

Above that, is “Magical”. Magical weapons are the ones that have special powers, like elemental properties, or the Master Sword. These weapons do not ordinarily break through wearing out, but may break when subjected to extreme damage or misuse.

In BOTW, the Master sword cannot break, but gets “used up” after a certain number of uses and has to recharge. I don’t especially like that solution, as it feels artificial, but we’ll come back to that. I think the Master Sword should be a special case weapon, maybe a level above “magical”. We might call it “Legendary”.

Another factor in durability should be its condition.

The bottom condition is “decrepit”. These are the weapons Link may find laying out in the open environment, which have been neglected and subject to weathering, rust, or rot. These will do in a pinch, but may be at their end of life. Decrepit weapons can be upgraded through repair, one time, taking them to a blacksmith shop or weapon shop in one of the towns or stables (which don’t exist in the game as they are, but could be added with a reasonably small effort) and it should cost materials and rupees to get them fixed. They cannot be restored to anything above Standard quality, regardless of how they started out in life. Fixing is not a skill that Link should devote time into learning, so he relies on skilled tradesmen and women to do this work for him, and he definitely can’t do it in the field. Decrepit bladed weapons do less damage and are weaker against armor than

Above “Decrepit” there is “Worn”. A worn weapon has been used, but is otherwise in good condition and functions as it should. Above “Worn” is “New”. There’s nothing better than “new”. A weapon in New condition remains in New condition until it is used, and then slowly degrades to Worn, and if not cared for, will degrade further to Decrepit and then eventually break in action.

You can check your inventory to see the current condition of the items you have, and the item in hand will visually give an appearance of its condition as well, to make it obvious when it is no longer New, and when it transitions from Worn to Decrepit. The “gonna break any time now” pulsating glow from the game-as-it-is can remain in place, but only happens with weapons in the Decrepit state on their last legs.

Using a weapon will degrade its condition from its current state down to Worn, then Decrepit, and then eventually it will break. There’s a risk of breaking at each condition level, but the risk increases dramatically as the weapon becomes increasingly worn out. As the weapon goes through these stages, it gradually diminishes in the damage it deals, becoming increasingly ineffective toward the end.

Weapons of Standard and Quality quality can be repaired a finite number of times at the places where that service is available, and if maintained (brought in for service before they become Decrepit) they can be restored to their full original quality level.

Weapons of different types will progress through their wear states differently. Bladed weapons will become dull through use, and will do less damage as a result. High condition, high quality bladed weapons will do much more damage than a crude weapon or a weapon in poor condition. Likewise with stabbing weapons such as spears, as their tips become rounded with use, they will likewise do less damage. Blunt weapons, on the other hand, remain just as effective regardless of their condition, which is an advantage that they have over sharp weapons. Offsetting this advantage, blunt weapons are heavier, making them slower to swing, slower to recover, and slower to windup when using a long-press attack move.

Weapon damage doesn’t have to happen every time the weapon is used. When a weapon is used in the intended way, weapon damage should be minimal to nonexistent, with perhaps a small change of something more happening due to an unlucky strike. But when a weapon is misused, or strikes a durable surface like armor, a shield, stone, or wood, some damage may occur.

So if you swing your weapon and connect to do damage, if the enemy is a normal flesh and blood creature, the damage done to a weapon will range from 0-1 durability points, with 1 being a rare unlucky hit.

When you parry with your weapon, or when your attack is parried by the enemy, or when your weapon strikes the enemy’s shield or an armored enemy, or when the enemy is made of something more durable than flesh and blood, such as skeletal enemies, stone enemies, elementally infused enemies, hitting them does more damage to your weapon. Parrying with your weapon does less damage than when your attack is parried by the enemy.

Depending on the material the weapon strikes, and the type of weapon, it will take more or less damage. Hitting rocks with a hammer, pick, or drill will use up very little of that weapon’s durability, while hitting stone with a bladed weapon or spear will do significant damage very quickly.

Hitting wood with an axe blade will cause only slight to no wear, but hitting wood with a blunt weapon or a bladed sword will do more damage to those types of weapons. So misusing weapons, abusing them to hit the wrong type of material than they were designed to be effective against, will cause them to wear out and become damaged or ruined very quickly, but using the right type of weapon for the material being struck will result in slow, gradual wear.

This is already implemented to a degree in BOTW, where weapons like hammers and axes do get a durability attrition bonus when used to chop wood or mine ore, but my proposed solution goes further, and the wear to properly used tools and weapons is reduced, particularly against softer enemies, while abused weapons take greater damage, and most weapon wear happens when the weapon hits a shield, armor, is parried, or is used to parry, or when the player hits a rock or tree in the midst of combat.

This means that your weapon could last a long time, if you know how to use it properly, and are skillful with your aim and don’t make ineffective attacks that hit the shield, or if you only mine ores with hammers and only chop wood with axes.

To adjust the adjacent systems in the game to accommodate for increased weapon life and the ability to repair weapons, weapon drops would be less frequent, and enemy’s weapons would tend to be in worse condition, reflecting that it is in all likelihood a used weapon, as well as any additional wear done to it while wielded by the enemy. It also means that an enemy’s weapon might break in their grasp, which I think would potentially make combat a little more interesting. Special weapons of Quality, and Magical weapons, would be correspondingly higher in rarity, reflecting their increased durability and capability of being repaired. We might also do with fewer inventory slots for carrying weapons. This would have a further advantage of being a bit more reasonable and realistic. When you consider how many things Link is able to carry in his inventory slots, it’s a bit ridiculous. Being forced to choose between 2-3 weapons at most, one of them being a bow, and a shield, would be an interesting constraint and force the player to choose, sometimes opting for a weaker weapon that has a useful ability or property, and storing their other “keeper” weapons back at Link’s House in Hateno Village.

It would definitely be interesting to see how the game feels with these changes. If a weapon broke only once every few fights, it would go a long way toward making me more willing to engage in battle. And by “every few fights” I mean every few encounters, not every few enemies. So if I’m fighting 4-5 bokoblins and a moblin, that is what I would consider a single “fight”. Weapons breaking every 3-4 encounters of that size, I think would be much less annoying, and feel more reasonable, while still providing the types of incentives that Nintendo’s designers were going for, to encourage the use of different types of weapons, rather than reliance on the single best weapon that you’ve found so far. I think I would enjoy combat much more if weapon breaking wasn’t something that happened in nearly every fight, especially with the better weapons you can find later in the game. When the weapons break so frequently, it makes me want to avoid combat in order to preserve my better weapons for use in fights that I want to have.

Some thoughts on the design of Mini Metro

I picked up Mini Metro about a week ago. I know it’s been around a few years, but I never claimed to be trendy.

I like the aesthetic and the mechanics of the game. It’s relaxing to play, yet gets hectic and overwhelming. It’s a fairly unique concept for a game, so it gets innovation and originality points. It’s a math-y game, but it presents the math intuitively and concretely, using shape and color and quantities that you have to eyeball, rather than representing quantities with numbers. There are various rates at which things happen, things that place demand on your resources, and you have to come up with a system that effectively utilizes those resources and balances demand. It requires a bit of strategy and some cleverness, and you can pause it, take your time, and think, or count and measure, or whatever you need to do to figure out your strategy. You have to understand how the rules work, and there is complexity in the ways the rules combine, but the rules are relatively simple taken individually, and they are introduced one at a time in a way that makes them easy to learn.

I don’t think it’s perfect, but it’s a pretty good game concept. Obviously, it’s been successful and popular.

But I think about ways I might improve its design.

What I don’t like about it is that there’s a little too much randomness in the spawning of the station points. Depending on how those play out, you can get totally screwed and have no possible way of managing the problems the game presents you. I feel like a better game design would always ensure that there was a solution that a sufficiently talented player could come up with, but that seeing the solution and implementing it would be the things that are difficult. It’s fine for the game to present a difficult challenge, and more difficult as the game progresses, but they shouldn’t be impossible.

So, for example, spawning a cluster of 6-10 Circle stations with no other types of stations in the region is an unfair situation. The spawning code should either not do this, or there should be ways to consolidate/erase multiple stations into a super-station. The game does give you Interchange stations, which have more capacity and speed than a basic station, but it only upgrades one existing station, and can’t be used to consolidate several nearby stations of the same type into one. I think it would be way more interesting if you could upgrade one station, and then all basic stations of the same shape within a certain radius of the new interchange would de-spawn, consolidating their traffic into the Interchange.
But I think the way I’d prefer to solve the problem would be to put the Station spawning in the player’s hands, not have it be done automatically by the game.

So my proposal would be that **passengers** would appear throughout the city, with a destination in mind (indicated by their shape). They have a limited walking distance that they are capable of traveling before they get tired and irritated. Irritated pedestrians change color and vibrate to indicate they are tired and unhappy. They will walk toward the nearest station, and try to travel to the closest station that matches their shape.

To make them happy, you can build a station near enough to them that they will walk to it, and then you can connect stations with your rail systems to take them efficiently to their destinations. You can spawn an unlimited number of stations (hmmm, perhaps), but you have limited resources in terms of rail lines, cars, carriages, bridges, and tunnels to connect them.

The passenger spawning is out of the player’s control, that part is provided by the game as the challenge, and the player can strategically build stations of the type desired, at the point desired. Maybe the player should be constrained by having to choose how many of which shape station is available to them, or something like that.

The other thing that I see with the game is that, at some point the game just decides to flood you with passengers until you die. Usually somewhere around the 1200-2000 passenger mark, the game just cranks up the generation of more passengers, attempting to overwhelm the player and force the game to a conclusion. Again, I think it’s better to give the player challenges that are possible. Maybe it gets harder and harder to keep up with the challenge, but there should always be a way to do it.

(I accept that it could be there is, and that it only seems like the game becomes impossible because I’m locked in to the design choices I made, and if I tore everything down and re-designed, maybe there’d be a way to create a more efficient system with the same resources available to me that could handle the new volume of traffic. But it doesn’t seem that way to me — even on Endless and Creative modes, where I have no constraints on the resources available to me to build the system, no matter how many lines and cars I throw at the problem, the population will always scale to a point where there’s always overcrowded stations.)

One thing I like about the game is that they don’t have an in-game currency that you earn by transporting passengers and use to spend on improvements for your transit system. I think if the game had that, it would be too much like a Sim-style game, and I think removing a concept of money, and de-coupling a potential feedback loop of performance income improvement more performance helps to keep the game simple — and I like that.

I wonder about that, and why the designer of the game decided on that. Because it’s inconceivable that they wouldn’t have considered every completed trip being converted into in-game money that would be spendable on more rail lines, trams, carriages, etc.

And they must have considered that, and then discarded the idea. I wonder why they decided it and what pros/cons they weighed to make that decision.

I never liked Donkey Kong

There. I said it.

Donkey Kong is the foundation of a modern business empire, a cultural cornerstone, the genesis story of the Marioverse. Not liking Donkey Kong is something akin to blasphemy. I gave it a shot. I wanted to like it. But I just never liked it.

I feel like I am about to regret one quarter just looking at this screen capture.

I first played Donkey Kong when it was new, in the Arcade, on Atari, and ColecoVision, and I never considered it one of my favorites. It was a smash hit when it came out, sold tens of thousands of arcade cabinets, swallowed hundreds of millions of quarters, sold millions of cartridges on home consoles, and been ported to just about every console of its generation and the next few after. It was groundbreaking, both technically and in terms of game mechanics and narrative.

I recognize all of that, and I still don’t care for the game. I respect it for its accomplishments, but yet I don’t like it. I can’t enjoy playing it.

This isn’t merely a statement of opinion or taste; I don’t enjoy playing Donkey Kong, and I don’t find it to be a particularly well-designed game.

Let’s talk about that.

Barrels – the first screen

How high can you climb?

Donkey Kong is very difficult and unforgiving. Part of its difficulty stems from the tight window for clearing dangerous obstacles, and the narrow clearance for successful jumps. But much of it comes from design choices that tend to make the game feel unfair.

Jumping

Jumping is the key mechanic around which the whole game is based. Yet, the jumping mechanic is rough. When you jump, you can’t change direction or height, so you’re committed to the path of the jump until you land. This makes jumping risky and hard. When you make a mistake, there’s no second chances. You know you’re going to die, and there’s nothing you can do but watch and wait for it.

You can’t jump very high — just the exact height to clear a barrel or fireball, and the exact distance to clear two barrels if they’re right next to each other… barely. Miss a jump by a little bit and you’re dead.

On the first screen, some of the ramps look like they might be close enough together to allow Jumpman to jump up to the next platform from the one below, but that is not permitted. You can only ascend to the next platform by climbing a ladder.

Not that you’d normally ever want to, but you can’t jump down from the edge of a ramp to the one below, either — the height is not great, but it will still kill you.

If you jump off a platform, you die if you fall just a short distance. Jumpman can’t survive falling any farther than the peak height of his jump.

Ladders

You can’t get off a ladder until you get allll the way up to the top of it, or allll the way to the bottom. Very often, you’ll think you’re there, and try to move left or right, only to find that you’re still locked onto the ladder and unable to move. A better design would have been to treat horizontal joystick input as continuing Jumpman’s previous climbing direction, moving him the rest of the way up/down the ladder until he is clear.

There’s no jumping from a ladder, either. Allowing this would make the game play feel less stiff, and give the player greater control and flexibility. It seems like Jumpman should maybe be able to reach up from the lower ladder to grab the bottom rung of the upper half and climb up, or to jump off from the top of the broken ladder to get some extra distance and height out of the move. And, surely, if only he could only jump vertically from the top of the ladder, you’d be able to reach the top half and continue up. But no, he can’t do any of these things.

Some of the ladders are broken, turning the ladder into a deadly dead-end. You can climb up them, but only get part-way. Even if you’re at the very top rung of the bottom half of a broken ladder, barrels rolling by below you will still hit you and kill you, even though you’re well off the ground. It’d be nice if the game gave you a break and decided there was enough clearance that you could be safe here. And a barrel that decides to roll down from the platform above and take the ladder path will also kill you. If it does, there’s no way you have time to get out of the way in time; you’re a sitting duck You’re stuck on the broken ladder until you backtrack down and get off. If you could jump off the ladder, or jump to clear the gap where the ladder broke, you’d have one more option, open up possibilities, a chance to dodge out of the way, and it would make the game feel a little more fair. But Donkey Kong doesn’t give this to you.

Hammer

The Hammer power-up allows Jumpman to fight back against the barrels and fireballs that are his bane, and earn extra points. But this comes at a cost.

Jumpman can’t climb ladders with the hammer, and cannot jump. This means he is stuck on the platform where he grabbed the hammer, for as long as the hammer persists.

The hammer is a temporary item, which runs on a timer that ends after a few seconds, but without warning. You can be right about to smash a barrel when suddenly the hammer disappears, leaving you defenseless and no time to jump out of the way. And if that happens, again you have no choice but to die. This feels unfair. To fix this problem, the game should give the player a cue to let them know that their hammer time is about to expire — blinking or an audio signal would be helpful. And maybe if the game detects that Jumpman is facing a barrel, and it is within a “close enough” distance just as time is about to expire, give the hammer enough extra frames before despawning it to allow the barrel to be busted, avoiding what would otherwise feel like an unfair death.

Since the levels are timed, and running out of time will kill you, and you can’t clear the level when you have the hammer because you can’t climb with it, getting the hammer can screw you if you grab it while the timer is running low.

As well, your remaining time gives you bonus points, so being forced by the hammer to wait before you can finish the level can actually cost you points, unless you can smash enough barrels/fireballs to make up for the lost bonus time, and make it worthwhile. It would be better if you could cancel the hammer early, or if you could still climb and jump while holding it. Or, perhaps hitting the jump button while holding the hammer could make Jumpman throw the hammer, giving you a useful way to cancel it early, and a ranged attack that could come in handy and give you one more option.

The hammer may make you seem invincible, but you can still be killed if a barrel gets past the hammer to touch Jumpman. Most players don’t realize this until, soon enough, they learn it the hard way. A barrel coming down a ladder can be hit by the hammer, but if it swings out of the way and the timing is just wrong, the barrel may hit Jumpman in the head before the hammer swings back up. Likewise, the rolling barrels may approach Jumpman from behind, or roll under the hammer while it is swinging above Jumpman’s head. The swinging of the hammer is automatic, not controlled by the player, so whether the hammer hits the barrel or the barrel gets through is somewhat random. Usually Jumpman will hit, but once in a while the barrel will get through. I would fix this design issue by making Jumpman invincible from the front while holding the hammer, but still let him take hits from above and the rear.

Barrels/fireballs

Barrel pathing is pernicious; whether a barrel will go down a ladder or continue down the ramp can’t be known for absolutely certain, but it seems that barrels are more likely to go down the ladder if you’re on the ladder, making using ladders especially deadly. It makes you paranoid to avoid starting up a ladder until any approaching barrels have cleared the ladder you need to climb. To some extent, you can manipulate the barrel AI by your position and direction, as the enemies will tend to take the path that is least advantageous to you. So by standing to one side or the other of a ladder, and facing the right direction, you can often influence the barrel to take the short path or the long path.

Barrel spacing is too random and can often kill you unfairly. Donkey Kong will sometimes roll two barrels at you too far apart to jump both together, and too close together to jump the first one and then immediately jump the next one.

Sometimes DK will toss a barrel that will go straight diagonally down the screen, ignoring collisions with the ramps. These move extremely fast and are unpredictable, making them all but impossible to dodge. If you happen to be in their path, at the top of the screen, you have almost no warning and no time to get out of the way.

Collisions with barrels will kill you with any overlap — even if you’re standing on the platform below, with your head poking above the next level, a barrel rolling along that level will collide with you and kill you. An if it passes below and clips your feet even a little, while you’re on a ladder, it’ll kill you as well. Collision boxes could have been made smaller, to make slight collisions forgiving, and allow for exciting “close calls” rather than cruel kills.

Rivets screen

Rivets – the final level (but also the 2nd one you reach, for some reason)

You clear this screen by popping all the rivets out of the girders, causing the structure to collapse. You clear the rivets by walking over them. This creates a narrow gap between the two rivets, really it’s just a crack. It looks narrow enough that you should easily be able to walk over it without inconvenience, much less danger. Yet, if you try, you find that Jumpman will fall through this narrow gap, to his death. This could have been nerfed by making you stop at the edge of these gaps rather than fall, or by allowing you to step over them unimpeded.

In later Mario games, Mario has the ability to fall any distance without injury, so long as he doesn’t fall into a bottomless pit. In Donkey Kong, though, Jumpman can’t fall any distance greater than the height he can jump. This means you have a lot less options and possibilities for moving around a level. The result is the controls feel stiff and uncomfortable.

You can grab a hammer on this level, as well, and if you do, you’ll be stuck walking back and forth on the girder you’re on, unable to walk over any gaps created by a missing rivet. This often means waiting for several seconds on one of the smaller side platforms, unable to climb up or down the ladders, and unable to cross the rivet gap. When you have the hammer, the fireball enemies that move around this level will often keep out of your reach, unless they happen to already be on that platform with you, seemingly waiting for your hammer time to end, so they can swarm you the instant you’re again vulnerable. If this happens, you’re often blocked from multiple sides, or facing two consecutive fireballs spaced so that you can’t clear them with any possible jump. Again, it’s like the game is designed to punish you.

Elevator Screen

Elevators – oh shit.

I could never clear this screen as a kid, not that I got many chances to. To get to it, you have to clear Girders, Rivets, and then Girders again, making the first Elevator screen level the fourth level in the game, and by this time I’m usually out of lives.

The jumps on this screen are very unforgiving, due to the height that Jumpman will fall if he misses the moving elevator platforms that he must land on in order to make his way to the goal. If you mis-time your jump, you may miss the platform, or simply land on it after falling too far. And you don’t have to fall very far to fall too far and trigger a death when you land.

There are bonus objects to pick up on this level, and not very many other scoring opportunities. But the bonus objects are so difficult to reach it’s not really worth it. You’ll waste too much time, or miss a jump and die.

At the end of this level, there’s a bouncing spring that moves horizontally very quickly, bouncing at you before falling down the right side of the screen. This makes any approach up the level involving movement through the right side of the screen especially deadly. It takes pixel perfect timing to avoid this final obstacle, and it’s probably the hardest single challenge to negotiate in the entire game. Apparently (I say, because I’ve never done it) the way to clear this final obstacle is to wait patiently, and time your move so that you can pass through the danger zone between one spring launching and the next. Move at the wrong time, and you’re screwed. It’s possible stand in a specific spot where the spring will bounce over Mario harmlessly. I don’t think it’s possible to jump over the spring; if you can it’s almost certainly not worth the risk.

Pie Factory Screen

Everyone thinks the cement trays are pies, and who am I to argue?

This screen is also known as the cement factory, or the conveyor belt screen. I don’t remember ever playing it, so I don’t really have complaints here. To get here, you need to clear 7 screens, and since I could never get past the Elevator screen in level 4, making it to the Pie Factory was far beyond my ability. It’s also the level that is often omitted from home console ports. I don’t even know what you need to do to clear this screen.

I watched some videos of people playing this level, and it looks like it might one of the more enjoyable levels. A few of the platforms are conveyor belts, which affect Jumpman’s horizontal speed when running on them, depending on which direction you’re facing, they’ll make you slower or faster. This doesn’t seem to affect your jumping ability much, though, because any other objects on these platforms are also affected by the conveyor belt speed.

At the top of the screen are two extension ladders which slide up and down according to a timed pattern. To clear the level, you have to wait for the ladders to extend up, then climb to the top-most platform. This doesn’t seem terribly difficult, although you’ll be at the mercy of the timing if there happen to be any fireball enemies nearby, you may not be able to get past them due to the timing of the ladders.

It’s hard to say without having played it, but all-in-all I think the Pie Factory might actually be one of the easier levels in the game. Which makes it seem strange/questionable that it is the last to be introduced to the player.

Lose a life and start over

On any level, if you lose a life, you start over from the start of the level you’re on. No progress is saved, no checkpoints. In order to clear the level, you have to do it perfectly, not making any lethal mistakes. This makes clearing any level which you have difficulty with especially difficult.

In a modernization, I imagine that there would be a waypoint system to allow you to keep some of the progress you make in a level. On the Rivets screen, this would be a simple matter of remembering the rivets you’ve popped. On the Elevator screen, starting Jumpman on the last platform he safely touched before dying would be helpful. On the Barrels screen, resuming exactly where you died would be nice, but if not, then at least start over on the last platform touched.

Why did Donkey Kong succeed?

Donkey Kong was one of the most successful arcade games ever, and even today it is a favorite of many gamers who appreciate the games of this period.

In 1981, arcade videogames were still quite new and had grown almost unimaginably popular after about a decade of market growth and technical development, with great interest in any new title that came out. It was a time we now look at as a golden age for the video arcade, after several years of ascendancy through the 70’s black and white era that gave way to the mega-popular blockbusters that dominated the early 80’s, games like Asteroids, Berzerk, Defender, Pac Man, Dig Dug, Joust, Galaga, and Moon Patrol. Out of all of them, only Pac Man made more money than Donkey Kong. What made it such an attraction?

Donkey Kong had the benefit of being unlike anything that had come before it, in terms of play style and technology, yet it had instant familiarity all at once, in the way it echoed the familiar King Kong story from classic cinema. It had colorful cartoon-like graphics. Its sound effects and music were charming. The game play was novel, yet intuitive, despite the brutal difficulty level. And for an arcade game, being extremely difficult was actually a good thing, since it resulted in shorter games, more credits per hour, and thus higher revenue. The challenged appealed to many gamers of the time. And there were not yet other games similar enough to compare against it, so the rough edges in the mechanics weren’t very obvious.

As one of the earliest platformer games, it broke ground and innovated, and for the time that was enough. Despite the shortcomings, rough edges, and unforgiving difficulty, it captured the minds of the public and gave them entertainment.

For all that, though, it just wasn’t for me, and I’ve come to accept that. For my quarter, Ms. Pac Man or Zookeeper is a far better play.

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 the player fearlessly.

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.

It’s also possible that the first-time player may press the fire button, thinking this is necessary to use the sword for attack; if so, they will discover that the button serves only to drop the currently held item, and now they will be defenseless! They may need to run away, or dodge around the dragon, and in so doing, may discover that the sword can kill dragons with a touch, regardless of whether the sword is in the player’s hand or not.

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; the rest all reach dead ends. 

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 degree 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 White 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.

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.

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 that characters can’t exit a locked castle 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 interesting that the designer took the time to make the castle gates both open and close. It would have been simpler and easier to make the key-open event a one-time thing, and for the gate to remain forever after open. But doing this would have made the keys one-time use items, with no further purpose once used. Being able to control the gates and lock things in castles makes the game more interesting, by giving the player an additional way to interact with and control the game world.

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. (This can render the game unwinnable.)

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 famous 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 full of purpose 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 dread, to fear, 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, a way to win, and an ending to the game.

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; the new 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 would 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.