Category: Best Of

GameMaker Position and Motion Tutorial

Best Of, GameMaker Tutorials, games, programming, Tutorials
18 Comments

Motion is critical to just about any video game. Nearly every game has moving things in it, and how they move is a vital part of the game. Learning how to program motion and control it effectively is one of the most important parts of a successful game. There are a number of possible approaches to handling position and movement. Learning how these work will help you make better games.

This isn’t absolutely everything there is to know about motion, but it’s a great overview to start with, and covers everything I’ve learned with respect to motion in GameMaker Studio.  (more…)

Game Review: Iron Tank (NES)

Best Of, games, reviews
Comments

Iron Tank (1988, SNK) is a mostly-forgotten title for the NES, but deserves more recognition than it’s gotten. I think of it as a spiritual companion to the other great NES WWII Shooter, Capcom’s 1943.

Many of its features were successful in other popular games, but it has enough of its own unique strengths that it can stand up proudly as an innovative game with an experience you will find similar to many other games, but still feeling original and well done, not generic or derivative:

  • Radio communications screen for narrative elements (Bionic Commando, Metal Gear). The radio will sometimes give you warning about upcoming challenges, or some mission background to explain why you’re here and what you need to do. This is mostly inessential because the mission is always “Stay alive, destroy enemies, and advance, and destroy a boss.” but it still gives the game a story of sorts. Often the radio message will be “too late” advice, warning you to be careful about a challenge you just got through. Toward the end, the enemy starts broadcasting to you, threatening/begging out of desperation to get you to turn back. This boosts your ego, and is a neat reward for the player.
  • Configurable power up system (many NES games featured this, but Iron Tank’s is unique in its implementation, but perhaps could be described as a combination of Mega Man and 1943.) Your main gun has four different types of power boosts — Long range, Rapid fire, Armor Piercing, and Bomb shells — which you refill through pickups.The pickups are odd in that they are letters which sometimes don’t have an obvious relationship to the power boost they represent. L = Long Range (ok, fair); V = Rapid (velocity?); F = Armor piercing (huh?); B = Bomb Shells (right). Rather than remain enabled until expended or a timer runs out, you can enable/disable them on a sub-screen as needed. This means there’s strategy to the game — you can save up your power and use it when you hit a really tough spot in the game. Managing your power-up resources is critical to winning. Knowing when you need them, and deciding what you need at a given time, and balancing that against the yet unknown challenges that lie even further ahead makes for a cerebral game that layers on top of the action game. There are times when an obvious approach of using power-ups isn’t really necessary, because a subtler strategy will enable you to get by with a stock configured tank, and it often pays off to take the harder challenge now, conserving the power boosts for an even more difficult challenge later.
  • The most interesting power-up mechanic is the [R]efuel tank, which gives you a secondary life bar that extends your primary life bar — but only if you choose to have it enabled. Another interesting thing is that you can both shoot and run over foot soldiers — and the game seems to encourage you to run them over, as doing so gives you a tiny but vital boost to your main energy.
  • Infinite continues, and a password save feature, allowing the game to be longer than would otherwise be practical to beat in one sitting, and not punishing the player too severely for not being able to make it through the challenging parts of the game, and allowing therefore for those parts of the game to be even more challenging.

Basic gameplay

There’s a very good “Let’s Play” series on YouTube, if you aren’t familiar or need to get reacquainted. You are Iron Snake, commander of the Iron Tank, invading Normandy and liberating Europe from an implied but unnamed Nazi occupation. And by “liberate” I definitely mean “blow the hell out of.” Actually, there are occasional resistance fighters and POWs who you’ll rescue throughout the game, as well.

Controls

Controls are often a weak point in games featuring tanks. Not so in Iron Tank. Your tank features an aimable turret, which allows you move and aim independently. The way this was implemented on the standard NES gamepad was effective — hold button B and the D-pad controls the turret. This takes a little getting used to, but is very effective and you can be quite nimble with practice. Being able to aim to the side or diagonal and strafe is an important tactic, and makes the game more realistic and more fun.

Graphics

There is a huge variety of tile-based backgrounds, for simulating the European countryside, cities, docks, airplane hangers, the Normandy beach, cliffs, trees, roads, paths, rail tracks, fortresses, you name it. Even for the 8-bit NES, these are a little rough in spots, though never truly bad, and the variety makes up for it.

Music

The music in Iron Tank is really first rate. It is heroic and epic, evokes both the military marches and the WWII era, adds drama and tension, and provides cues to when more challenging areas are up ahead. Most of the music is in the lower and mid octaves, which gives it a characteristic unlike most other background music on the NES, while seeming suitable for a game about tanks.

Enemies

There really isn’t anything in Iron Tank sophisticated enough to call AI. The enemies all move in basic, simple patterns and pre-set routes, but a lot of variety makes the game challenging. Some tanks sit still, others chase you, while others seem to stand off at a distance and duck and feint, and still others will enter, make a quick attack, and then retreat before you can retaliate.

There’s also a great variety of enemies: infantry, officers, tanks, train guns, fortresses, turrets, and boss tanks called “Think Tanks”. I guess they’re hard enough that you need to think about how to defeat them? You even do battle with airplanes and submarines. Of course tanks are the star of the game, and there is a satisfying variety of enemy tanks, different styles of light, medium, and heavy, which vary in their speed, armor, and armament. Some are barely any threat to you, while others necessitate caution.

This variety of enemies invites a variety of tactics, which keeps the game fresh and challenging. The key tactic is avoiding being in range of the enemy cannons, flanking the enemy’s turret when you can, or when that isn’t possible, waiting for a pause in their fire and placing a well-timed shot to take them out. You can also sometimes use your long range shots to safely take out enemies before they’re able to engage you with their own armaments. Individually, their cannon fire is usually not too hard to dodge, being limited to 8 directions, resulting in predictable pie slices of safe zone. It’s not too hard to take out enemy tanks when they don’t outnumber you too badly and there’s plenty of room to maneuver. Sometimes moving slowly and cautiously, taking out the enemies one at a time, picking apart their defenses is the best approach, other times it’s better to just run for it.

Terrain

Some terrain is more open than others, however. The variety of terrain matches the variety of enemies and enemy tactics, and itself influences the tactics that will be most effective in a given area. Although the game is 2D, there are simulated ledges, cliffs, and rooftops where placed guns can harass you, sometimes out of your own reach unless you have some power boosts enabled. There are walls and buildings and natural barriers that can constrain your movements, but provide cover in return. Water likewise blocks your path, but leaves you exposed to fire.

There are wooded areas where the tree canopy foregrounds partially obscure the action beneath them. The NES didn’t have a capability of alpha channel, but they still made the forest sprites partially see-through, so that when you go under them, you can see the unobstructed part of your tank (or lurking enemies) through them. This is really cool.

Insta-kill anti-tank landmines will block your progress along otherwise open and inviting pathways. They blink, being invisible half the time, so can be difficult to spot.

Destructible terrain

While not dynamically destructible, there are enough buildings and walls that you can blow up to uncover secrets or alternate paths that it’s worth mentioning. Being in a tank and not being able to destroy these things just wouldn’t feel right.

Multi-path map

I don’t know of any other NES game that did this, so Iron Tank deserves special recognition for this design. At several points in the game, you’ll encounter road signs that point out a fork in the road. Depending on which path you take, you’ll proceed to a different level, with different terrain and enemies. One path might be more difficult, but you have no way of knowing before you make your choice. This means that in order to experience every bit of the game, you’ll need to play through it multiple times.

Map x-wrapping

Instead of having an edge, the map wraps on the x-axis. There are certain places on the map where there are no side walls, and you are unbounded in your horizontal direction, but in these locales, the map wraps around. While not exactly realistic, it does make for some potentially useful tactics, as you can return to an area by continuing in one direction, without needing to double back.

Overall

Iron Tank is a solid effort from SNK. The game integrates a lot of the features and design elements of successful NES classics, and does it well. While mainly an action game, the story elements provided by the radio communiques and the configurable power-ups give an element of strategy almost like a proto-RPG. It’s one of my favorite lesser-known games on the NES.

See Also

If you liked this game, you’ll want to check out 1943, Guerrilla War, Commando, Jackal, Heavy Barrel and Ikari Warriors. All have a similar WWII/war theme and vertical scrolling shooter gameplay.

Random number generation in game programming

Best Of, GameMaker Tutorials, games, programming
Comments

Random number generators are extremely useful in game programming. I have found a lot of uses for randomness in my projects.

What can you do with randomness?

Man, all kinds of stuff. Nearly any value that you want to initialize in a game object is a candidate for possible randomization. Randomness fuzzes up your game, making less deterministic and therefore harder to defeat with simple patterns and more replayable.

Pretty much any time I would normally use a literal or a constant number in my code, anymore I step back and ask myself what range of values might work in that place, and then create a random function that will provide me with a number in that range. The only time I don’t do this is when I really do need a precise value, or when performance is too important to sacrifice the computation time needed for the random function to return its result.

Here are just a few ideas for how you can use random numbers to improve your games:

Unit stats

Nothing makes a video game feel more like a video game than when every enemy you encounter is an exact clone of all the other enemies that look like it. You can use randomness to give your enemies some personality by giving them randomized stats. Instead of fixed values for Attack, Defense, Speed, Damage, etc., use a random range of values to generate stronger and weaker versions of your enemies. It takes a little more time to compute these values on the fly, but modern processors can handle this load easily, unless you’re generating a huge number of units.

Sprite generation

Why spend a lot of time hand-drawing every sprite in your game? Create a generator system that randomly puts pieces together, and create random sprites on the fly. If you’ve played around with an avatar generator such as eightbit.me or the Mii generator on Wii or the XBox Live Arcade avatar generator, imagine that kind of model system, but with a random selector in charge of picking the hair, eyes, etc. You can do this to randomly generate other things, such as buildings, procedurally, as well.

Colors

If you’re calling drawing functions, randomizing colors can give your game a lot better visual appeal. If you’re clever in how you pick your random colors, you can come up with color schemes that work nicely, yet are always slightly different each time you play. You can either pre-define a palette of colors and randomly select one, or you can randomly select R, G, B or H, S, V numbers and create a color at runtime. You can experiment with different mathematical tweaks to shape and constrain the randomness.

Map generation

If you can write a good random map generator, you can save yourself from having to hand-design all your maps. GOOD random generation may be very difficult to accomplish, however — especially for more complex games. But even if you can’t guarantee a good random map at runtime, an almost-good random map generator can save you tons of time or spur your creativity by doing most of the work for you, leaving you with something almost good enough, that just needs a little hand-polishing to make shine.

Procedurally generated content in general is a good use for random functions. You can use a random number function to create a deterministic sequence of generated values that is always the same. This is because computer hardware actually does not have a means of creating a truly random number — it fakes it, approximating randomness with a pseudo-random algorithm.

This is used to good effect in one of my favorite Atari 2600 games, Pitfall. A pseudo-random function, using a fixed seed, is used to generate each screen in the game. This achieves a very high information density, since the data that was needed to represent each screen could not be stored on a 4kb ROM, but a generator function that creates that data easily could. This technique is not used very much in modern game development since storage isn’t much of an issue any more, but it is still a very interesting technique and one which merits study.

AI

There are many potential applications of randomness to AI. Whenever your AI needs to make a decision, you potentially can use randomness to make that decision less predictable. Weighted probability is important here, as completely random AI behavior is erratic and seems crazy, while an AI that occasionally does something unexpected will seem tricky or deceptive or clever. Dynamically weighting the probability according to context at runtime will make your AI seem smarter.

GameMaker/GML random functions

These are built in to the Game Maker Language (GML):

  1. random(N): returns a random floating point value between 0 and N, not including N.
  2. random_range(A, B): returns a random a floating point value between A and B, not including B.
  3. irandom(N): returns a random integer value between 0 and N.
  4. irandom_range(A, B): returns a random integer value between A and B.
  5. choose(a,b,c,d,e,f,g,h,i,j,k…): Randomly returns one of the arguments, up to 16 arguments may be passed into a GML function. You can weight the likelihood of one result by repeating it in the arguments list. (e.g., choose(dog, dog, dog, cat) would be 3/4 likely to return dog, 1/4 likely to return cat.)
  6. random_get_seed(): Gets the current seed value for the randomizer.
  7. random_set_seed(): If you need a randomized, but deterministic function, you can set the seed for your random function. (This approach of setting a known seed is how the levels in Pitfall for Atari 2600 were always the same even though they were generated by the Atari’s random number generator.)
  8. randomize(): Sets the seed of the randomizer to a random value.

These are scripts you may import into your project:

  1. gauss(median, deviation): Returns a random value with a gaussian (“normal”) distribution around a median value. From GMLScripts.com.

All programming languages have similar random functions or classes built into them. Whatever tool you happen to be using, it pays to learn about how it can produce random numbers, and how you can use them to do useful and interesting things.

If you have any favorite ways of using random numbers in your programs, post a comment below and share it!

Keeping randomness under control

One of the mistakes most game developers will make when using random functions is to use too wide a range of random values, or failing to control the range of values returned by the random function.

Know your math

Randomness feels most random when the probability distribution is flat. However, this often does not make for the most interesting gameplay mechanics. It’s often more useful to have a weighted function that has a greater probability of returning a value in one part of the range than in another. Understanding probability math is key to getting your randomized functions under control. The other key is to develop your intuition to know what range of values will work best for a given situation.

If you’ve ever played tabletop role playing games, then you know about dice. Dice are good analog randomizers, and can help us understand probability and randomness in a computer program. In classic Dungeons & Dragons, character ability scores are randomly determined by adding the values of three six-sided dice. This results in a bell curve, meaning that the results of a 3d6 roll are distributed in such a way that an “average” score between 9-12 is far more likely than an extreme score of 3 or 18. So one way to directly simulate this type of dice rolling in a computer program would be :

N = 0;
repeat(3){N+=irandom_range(1,6)}; // generates a value between 3-18, distributed around 10.5

In computer programming, there are more efficient ways to achieve a bell curve distribution than this. Calling random() multiple times, and writing loops will make your code slow, so if there’s ways to avoid doing that, it’s a good idea. The gauss() function from gmlscrips.com creates a “normal” distribution around the agrument passed into it, and is fast and efficient.

round(gauss(10.5, 3.5)); //simulates rolling 3d6, approximately

Note that this will not return exactly the same distribution of values as a true 3d6 roll will. But this is because 3d6 is actually an approximation of a gaussian distribution — the gauss() distribution is more accurate to a “standard normal” statistical distribution. If you compared graphs of the bell curves of 3d6 vs. the gauss() function, the gauss curve would be smoother, and would include values outside the 3-18 range (2 and 19 would show up a tiny percent of the time).

There are other types of distibutions that you might want to achieve with your randomized functions, for some purpose. Knowing your math is important here. Learn the graphs of common functions, and understand the relationship between the shape of the graph and the probability distribution of a randomized function modified by each function. For example, random(x), ln(random(x)), and random(x)^2 have very different looking distributions. Knowing this, you can tailor an equation to fit your needs.

Once you get comfortable with the math, it’s actually fun. Play around with a graphic calculator and see what different graphs you can come up with. Each time you discover an interesting or useful shape, make note and file it away for a time when it might be useful.

Testing

Because adding randomness to your functions make the game non-deterministic, it can make things more difficult to test. Certain conditions become hard to duplicate, because you don’t directly control them, and this can make repeatable testing of your game seem impossible.

There are approaches you can take to ensure that your code works, still. First, when you are building up your functions, ensure that the non-random parts of the code work well before you introduce randomness. If necessary, temporarily remove the randomization and replace it with a literal value, a constant, or a variable. Once you are have tested thoroughly and are sure the code is working correctly with a range of controlled values, you may safely replace the controlled values with random values that are constrained to the ranges you tested.

In some cases, you may need to go back and re-test code. It would be a pain to have to find/replace every random() call in your code. Not only would it be time consuming, it would increase the opportunity for errors to creep in. A better approach may be to comment out the equivalent non-random code next to the random code, and leave it in your code file. That way you just have to comment out the randomized function and un-comment the deterministic version.

Even this is time consuming and error prone, however. You may want to create randomized and non-random versions of your functions, and introduce a configuration variable that you can toggle to enable/disable randomness. Then you can pepper your code with things like:

if settings.random {randomized_function()} else {deterministic_function()};

All this extra branching in your code can get ugly and unmangeabeable too, so try to limit this to keep it to a minimum.

You could also use polymorphism to create sibling classes, one which inherits randomized functions, and one which doesn’t, and just spawn the appropriate class instances according to the game configuration at runtime.

The great thing about being able to turn randomness on or off at runtime is that it allows you to very quickly see the difference, reducing the lag time between test runs. This could even turn into a feature of the game, rather than a debug exercise.

With proper care taken during development, randomized functions can be just as reliable as deterministic functions. It just takes a little extra forethought and planning.

Robotron: 2084 and Zookeeper

Best Of, design, games, reviews
Comments

Today was the day of Cleveland’s Classic Console and Arcade Gaming Show. This year was especially well attended, and I was very happy to see a higher proportion of female gamers attending. I’ve been going since I heard about it 2005, and every time I go there is always something I have never seen before, and it’s always a good time. In addition to rows of tables with old games to buy and look at, some homebrew and modding fun, and some old school systems set up with games to play, there are drawings and tournaments.

This year, they had two of my favorite 80’s arcade games: Zookeeper and Robotron 2084. Robotron was a tournament game. I thought I might have a chance at winning, but I didn’t come close to the top score — although I did have the second highest score. I played a lot of games to get sharp, but my top score of 214,000-some points was still far from the winner, who posted a score of almost 391,000. It’ll take me a while to get that good.

While the experience is still fresh in my mind, I thought I’d reflect on what makes Zookeeper and Robotron two of my favorite games.

(more…)

“Preaching to the Choir”

Best Of, life
Comments

We all probably hear a lot of cliched business phrases in our work lives, but one I’ve been hearing a lot lately is “preaching to the choir”.  Whenever I hear it used, it seems to be in a manner that discourages the practice.

The idiom as it is normally used seems to mean “wasting time” — with a strong image of uselessly “persuading” those who are already persuaded, and possibly boring/annoying them with something they’ve heard a million times already.

The idea seems to be that preaching to the choir is a useless activity, because the people are already in the choir, and that the preacher would be better off finding sinners to preach to… the choir isn’t the problem, it’s these sinner people who haven’t heard your message a million times and don’t agree with your point of view who you should be preaching to.

I would like to challenge this notion. “Preaching to the choir” should be much more effective than preaching to non-believers. Think about it:

  • The choir is listening to you. They’re there because they want to be there. They want to hear preaching.
  • A choir isn’t the leader. The choir needs a leader. I’m sure they can think for themselves, but they still need someone with vision and focus, who can inspire and motivate them with a message worthy of amplification.
  • The choir exists to amplify that message! That’s why they’re there!

You don’t have to overcome a lot of resistance in the choir order to get them to buy in to your message. This means the amount of time you need to spend persuading relative to the amount of time that you can spend in action doing useful and productive things is more favorable. “Preaching to the choir” should be a good thing, not a pointless thing.

(more…)

The Early 80’s Arcade Aesthetic

Best Of, design, games
4 Comments

My friend Sam recently asked the internet if there were any books on early arcade game aesthetics. I’m not aware of any books that particularly stand out as being focused on game graphics, so I didn’t have any titles to suggest, although there are starting to be quite a few really good books on the history of the arcade.

To help him out, I brainstormed as much as I could, and since I think this ended up being pretty valuable, I figured I’d turn it into a blog post.

Basically every design principle in the graphics of early 80’s arcade games was governed by the insane limitations of the tiny systems of the day. Memory was SUPER expensive, 16k of RAM was a LOT in the late 70s/early 80s. CPU was 8 or 16 bit and SLOW – 1MHz or so. At the time there often wasn’t a dedicated video processing unit, or even dedicated video memory — everything was handled by the CPU, which often dedicated most of its processing power to simply drawing each frame of video, leaving relatively little processing power left over for handling game logic.

Here’s a list of qualities and factors that fed into creating the early 80’s aesthetic:

  • Portrait aspect ratios. Most of the old games, particularly vertical scrolling shooters, had monitors mounted in the cabinet in Portrait orientation (3:4 aspect ratio, as opposed to 4:3 ratio). Portrait gave vertical shooters more range to fire, and enabled manufacturers to build narrower cabinets, which allowed them to store, ship, and display more units in a given area.
  • Large pixels. The dot-pitch of those old screens was pretty coarse. You might have had a 15-, 17-, or 19-inch screen displaying 320×240 resolution, or even 240×160. Individual pixels were quite apparent, particularly in the late 70’s. Macro lens photos of the screen would reveal visible gaps between pixels. Early home computer monitors were capable of displaying a mere 40 or 80 characters of text, and the screens were tiny — 13″ or smaller.
  • Tiny sprites (usually 16×16 or 32×32 max)
  • Animations typically limited to 2-3 frames, though there were sometimes exceptions. Each frame of animation in a sprite cost valuable storage.
  • Bright colors and pastels. Here’s a great collection of color palettes available to home consoles and computers.
  • Grid-based graphics. Most terrain, characters, etc. were sized to fit within a standard grid size. Terrain, mazes, etc. were generally built out of repeated tiles.
  • No alpha channel. I don’t recall seeing any translucency (colors blending when two sprites overlap) in this era. Any transparency would have been all or nothing, provided by a mask. Before masking techniques became widespread, many early games had the background color drawn into the sprite, resulting in artifacts when two sprites would overlap.
  • Limited color palette. 2N colors to pick from, where N <= 8. So, generally 256 or fewer colors on screen. The most common color depths were 1-bit (B&W) and 8-bit (256-colors), although there were a few notable grayscale games, such as Fire Truck. 8-bit color ruled in the arcade until the 16-bit revolution came to the arcade, around 1986-87 — the golden era (roughly, 1978-1984) of the arcade was exclusively B&W, and 8-bit.Oftentimes, computers of the day had a pre-defined color palette and were further limited by the number of distinct colors they could draw on the screen at any one time, such as out of a total of, say, 4096 possible colors, which were baked in to the hardware and could not be changed, and you can only draw 16 (or 64, or 128) of them on the screen (or, in some cases, up to 4 colors in any one sprite) at any one time. If you want to emulate specific hardware, it’s a good idea to research the capabilities and narrow your color selection to match the authentic palette of the original hardware. These limitations often resulted in workarounds such as dithering (drawing two colored pixels closely together to allow the eye to blend them to a middle value). Here’s a fascinating article about the Commodore 64, describing a technique for getting “secret” colors to emerge from the C64’s limited palette by rapidly switching between two colors in the palette to synthesize a new color. It also meant that smoothing your images with anti-aliasing wasn’t possible, because there weren’t enough available colors to do proper tweening. Jaggy pixels ruled the day. Many home computer games of the era did their graphics in Text Mode, which has its own distinct look.See also: MDA, CGA, EGA, VGA
  • Palette swapped sprites. Old computers used color palettes, or indexed color. Out of a gamut of, say, 64 or 256 or 1024 or 4096 possible colors, a sprite typically could only use, say, 4 or 16 out of the 256 available colors. These four chosen colors were defined by a “palette”, and each color on the palette had an index value used to refer to it. By changing the colors in the palette to different colors, or in other words swapping one palette for another, the indexes in the sprite would be updated to use the new colors. Re-using and re-coloring the sprite, saved on storage space. A palette swap took a bitmap and re-mapped the values in each pixel to a different color from the new palette. This is why Mario is red and Luigi is green, for example. It was also very common to have different power levels of enemies denoted by using palette swaps.
  • Blinking and flashing. Rapidly flashing colors as a cheap, eye-catching form of pseudo-animation.
  • Flicker. If the processor couldn’t handle drawing all of the sprites on the screen in every screen refresh, something had to drop. So a sprite might not draw every screen update if there are too many on the screen, or too many in a horizontal scan line.
  • Abstract, iconified representations of things, and cartoony drawings, as opposed to realistic drawings.
  • Reliance on clichés, tropes, and popular idioms to help make graphics more easily recognizable, and a willingness to extend the idiom in a clever/absurd/zany fashion.
  • Fruit and keys and things are canonical bonus items.
  • Giant head/face, tiny body/limbs. They tried to fit the entire character into a 32×32 square, and most of the detail needed to go into the face/head to make the character recognizable and memorable.
  • High contrast is important for foreground/background.
  • Shigeru Miyamoto once gave an interview where he discussed why the original Donkey Kong sprites for Mario…mario
    • had white skin (the background was black, so they wanted strong contrast),
    • had a mustache (it helped his nose stand out and a mouth and chin were too complicated for the number of pixels left in the region)
    • wore red overalls/blue shirt (the overalls helped with the contrast of his swinging arms, which you otherwise wouldn’t get from a solid colored top.)
    • Wore a hat (his dark hair would have stood out less against a dark background, and presented problems with animation.)

Don’t forget vector!

Notable vector titles of the era:

  • Asteroids was the first hugely successful arcade game that used a vector display. Note the intense glow of the UFO and missile in this image, due to the vector display over-drawing those lines many more times than the refresh rate of a raster scan CRT would have allowed.asteroids_630x[1]
    I’m not sure what the very first use of a vector monitor was in the arcade, maybe Lunar Lander?
  • Battlezone When gamers of the area think about vector games, probably the first two titles they’ll think of are Asteroids and Battlezone.battlezone[1]
  • Qix Actually, Qix used a raster monitor, but it was primarily line based art, so I’m including it anyway for inspiration. Plus, it gives you an idea of how a line art game would look on a low-res raster display of the period.Qixingame[1]
  • Tempest Tempest was the first color vector game, and was a sensation at the time of its release.maxresdefault[1]
  • Space Duel is one of my all time favorite games. It featured innovative 2-player co-op/competitive play, and awesome graphics.Spaceduel[1]
    Note the distinct difference in this photo of an actual vector monitor screen photograph vs. how the game looks when emulated on a modern display:score8055_20140504190722[1]
    spacduel2[1]
  • Star Castle An often overlooked classic, the arcade version Star Castle used a color overlay over a monochrome vector CRT:star_castle_large[1]
    Later cabinets made use of a color vector CRT display, and looked much better: screenshot1[1]
  • Star Wars (really impressive achievement vector graphics, actually — convincing 3D, accurate wireframes of familiar star fighters from the movie, simulated fills, etc.)Star_Wars_Screen[1]
    1181242172192[1]

There might be other notables that I’m forgetting, as well, but these should have you pretty well covered.

Color vector screens were something rare and expensive, most vector games were B/W or monochrome (green or amber). I believe before proper color vector monitors became cheap enough, some vector games may have made use of cellophane overlays attached to the screen which filtered the vector image painted on that part of the screen to make it appear colored.

When you DID have colors, they were very bright colors, almost always primary colors (RGB).

The way the vector monitors worked:

  • There are no pixels (not easy to emulate, but maybe the retina display on the new iPhone/iPad can help make this more convincing?) This meant no aliasing or scaling artifacts.
  • A->B, not scan lines. The cathode beam was drawing from A to B for each line segment, not drawing scan lines from top to bottom.
  • Bright and sharp. As such, a vector display could spend much more time drawing each line segment, far faster refresh rates than the 30Hz that is typical of pre-HDTV raster CRTs. Unlike a raster CRT, there was not a fixed refresh rate; the cathode beams traced over the line segments as quickly as they were able to. This resulted in a very bright, flicker-free vector line (again, not easy to emulate) compared to the brightness of a white pixel on a raster display. There was often some ghosting as the intensely bright phosphor dimmed after the object on the screen moved. This was a hardware artifact, not something programmed in to the graphics routine as a special effect. Vector displays GLOWED and were sharp and gorgeous.
  • More stuff to draw means dimmer lines. This also meant that the more stuff being drawn on the screen at once, the overall brightness of each individual line was diminished, ultimately resulting in visible flicker if too many things were being drawn at once.
  • Even brighter vertices. Where line segments intersected, or at vertices, the beams additively excited the phosphors resulting in an even brighter point at the corner in relation to the brightness of the rest of the line segment. We’re talking REALLY excited phosphors!
  • Geometric shapes and polygons, not curves. Curves would have required far too much computing time to calculate precisely. Curves were always approximated with line segments. Linear functions are way faster than polynomial and trig functions, and the processors of the day didn’t even have dedicated floating point units (FPUs).
  • (Usually?) a single line thickness for all graphics. I can’t think of any vector games where the line thickness varied, but it’s possible there may have been some. Typically the lines were quite thin, like pencil lines.
  • No fills. Everything is a wireframe — maybe a simulated fill by drawing in a bunch of lines in a pattern. Fancier 3D games would occlude line segments that were “behind” the surface of some other object, but a lot of them just let you have a kind of x-ray vision effect where you could see through the wireframe.
  • Black background. You can have any background color you want, as long as it’s black.
  • Favorable to 3D. These properties made 3D games much easier to draw in vector than for raster graphic displays of the time. So a lot of the early 3D experiments were done with vector displays, most notably Battlezone.

Further reading

Games and stories

Best Of, design, games
2 Comments

Humans are storytellers, and we do it more or less instinctively, but many of us are not great storytellers. Humans are also game players, and we also do that instinctively, and most of us are at least decent in some game or other.

The use of Story in videogames is a rather deep topic, but suffice it to say that games have done well with minimal story, with trite and clichéd story, and often with just plain bad story. Games do have the potential to deliver great story, and some have.

This article at Ars Technica raises some points that I mostly agree with, in that a game doesn’t need a story to be a great game. But I disagree with it insofar as great stories should only be told through established, proper forms. Reading it prompted the following thoughts in reaction:

Even Chess has an element of story to it: Two kingdoms at war. It’s abstract, but it does have meaning. It’s not really the point of Chess, and it’s easy enough to re-theme the story a particular chess set tells. Understanding the course of a game of chess through the metaphor implied by the significance imparted on the various pieces doesn’t really add any insight to winning strategy, though. Chess is loosely coupled to its story. It’s there for flavor, and there’s some symbolic meaning there, but it’s not very important.

A game like Tic-Tac-Toe has no story at all, right? It’s just an absolutely abstract conflict based in the geometric realities of the grid and the arbitrary significance of orthogonal lines. Well, suppose we take the British name for the game, Noughts and Crosses, and then let’s to a tiny bit further to modify the Noughts so that they’re Crescents. Instantly, we’ve created story: a retelling of the age-old, pointless clash that nobody can win between Christianity and Islam. It’s so slight, it’s almost stupid that this change is all that is needed to convey a story with a moral, yet it’s strangely powerful. And that’s how ingrained story is to games. It’s there because we can’t help ourselves putting it there.

Some attempts at telling a story that is the equal of our finest books, plays, and films through the medium of videogames game end up being a failure, and this ends up hurting both the game and the story. This much is true. I think “So don’t ever do that” is the wrong lesson to take from that. Game design is a rapidly developing art form and it’s entirely likely that new ways of integrating story and game are possible, many of them still over the horizon. We can imagine a lot, but we can’t imagine everything the future will bring. Which is why the future is so fascinating. Closing off an entire branch of game design because it was a bad idea in the past or because past attempts failed is just shortsighted.

If you’re making a game, the first goal is make sure that the game is good. There are a lot of ways to do this, likely infinite.

If you support the game with story elements, it can enhance the game. Game developers should try to make those good, of course, as they should make any element in the game as good as they are able. But they don’t have to be concerned about telling great, serious stories. Stories told through games can be great, though, and it’s fine to aspire and experiment to find what works and what doesn’t, but clearly most games do not require a level of storytelling the equal of a classic novel in order to be great as games. It’s OK for them to aspire to do so, though.

Unearthed Treasures of Childhood

Best Of, games
Comments

I’m cleaning out my home office today… well, let’s say this week.

For most of my life, I have been a packrat, and a fairly disorganized one at that. I have always been very sentimental about things, and would keep reminders of events, and basically never threw out anything that I had worked on when I was a kid. Most of that stuff got kept for a really long time, far longer than it was useful, if it even ever was useful.

But after a certain point, keeping everything gets to be a burden. A few years ago, I started to recognize that this was a problem and that I needed to do something about it. I have a very strong instinct to preserve and archive things that are important to me, either because they express some idea that I find compelling, or because they help to define my personality or could be used to explain myself in some way that would be persuasive or understandable to others.

Anyhow, in my office I have piles and piles of old papers, drawings and things I wrote for fun in childhood, school assignments, newspaper clippings, comic strips, receipts, artifacts from memorable experiences, and outright junk. I’m working on going through it all and purging as much of it as I can stand to part with. Mostly it’s not hard, it’s just a lot of sifting and it’s time consuming.

It’s a bit embarrassing for me to admit this. If you’ve seen Hoarders, that could be me. I say “could be” because that’s easier than admitting that it is me. I’m definitely not that bad, and definitely not as bad as I used to be, but it’s taken me some time. I just had a realization and asked myself what I was doing, and from there it’s just been a matter of prioritizing when I can go through the accumulation of decades and get rid of things. Most of the time I am busy or obligated and haven’t gotten to a lot of it. But I have free time this week so it’s happening.

Anyhow, going through my piles of junk, I came across my original concept drawing for the Boobie Teeth game! I thought that it had been lost to the ages. But here it is. I’m blown away. Finding it here is surreal. I have no idea how it came here from my mom’s attic, where I know it had stayed for many years. But I must have retrieved it at some point, put it aside, and forgotten completely about it.

It’s 3 pages of wide format fanfold line printer terminal paper. Someone in my family would bring lots of it home and give it to us for scrap paper which we could draw on the unused side. The printing on the used side has 1982, which helps establish the date — likely the drawing would have been done some time around 1982-83. This means that I must have been 7 or 8 when I drew up the concept, not six.

The game concept is also quite different from how I reconstructed it from memory: Boobie Teeth is a space fish. Rather than eating other fish, Boobie Teeth primarily feeds on these alien creatures called Boobies, which resemble the ghostmonsters from Pac Man, only with legs. Actually, I recognize them as being “stolen” from a game I liked at the time, Fast Eddie for Atari 2600:

 

Fast Eddie for Atari 2600
Fast Eddie for Atari 2600, the inspiration for “boobies” in my original concept.

My game concept also featured some birds, called Boobie Helpers, who tried to help the Boobies avoid becoming Boobie Teeth’s prey. Also, there were two other types of fish in the game: An “older” species of the same genus as Boobie Teeth, which only eats plants, but which Boobie Teeth can eat for bonus points, and a “new” species which preys on Boobie Teeth. One of the more interesting aspects of the original concept was that the Boobie Teeth species was facing extinction. Only 12 fish remained. And when you died in the game, your skeleton would sink down into the sea bed, and become fossilized in the sediment.

I’m not sure how much of these unearthed revelations will end up making it into the finished game. They don’t entirely fit with the version of the game that I reconstructed from memory. I like the death->fossil concept.

As soon as I can scan the drawing, I’ll be posting it here for you to see. For now, here’s photo I took with my digital camera:

 

Boobie Teeth original concept

Original concept drawing for Boobie Teeth

Original concept description:

You are one of the 12 remaining space fish called Booby Teeth. These little space creatures called boobies are trying to eat you. There are booby helpers that look like birds. You have to eat the boobies from behind. There are 11 other fish that are in reserve. A new specie of Booby Teeth called the Booby Crusher. It is much bigger and it is trying to eat you because it doesn’t know any better. He is 15 mph faster than you. There is one last kind of booby teeth. It only eats plant life. You are trying to eat it like the Booby Crusher is trying to eat you. It swimsflies across every time you have played for 30 seconds. It is 1000 points the first time it flies by and it will stay there until the score on it is 0, then it will disappear. Every time it flies by its score gets lower. The gill on it is the 1 in 1,000. After that it disappears. It is 900, 800, and so on until it gets to 100. The score keeps splitting in half. If you clear the whole board of Boobies, Booby Helpers, and Booby Teeth that eats plant life, you have to find the fossil form. The more times you lose a remaining fish you have to find more fossil forms. When you find it, you have to pull it up with your mouth, then you will get a rougher landscape. The game starts all over again. (Later there are mountains and volcanoes.)

Using the controller: Pushing the joystick up makes the Booby Teeth go up. Pushing the joystick down makes the Booby Teeth go down. Pushing the stick to the right makes the Booby Teeth go to the right. Pushing the stick to the left makes the Booby Teeth go to the left. The fire button makes the Booby Teeth bite.

Scoring:
Common Boobies: 50 pts.
Tallest & second tallest Boobies: 100 pts.
Strongest Booby: 150 pts.
Shortest Booby: 125 pts.
Flying Booby: 250 pts.
Booby Helpers:
Baby: 300 pts.
Mother: 2,000 pts.
Fastest Booby: 350 pts.

BunnyBots

Best Of, games
Comments

I was over at my parents house for Christmas. When I was a kid, my mom kept a bunch of my old school assignments and things up in the attic. I had hoped that I’d be able to go up there and find some of the old game ideas that I had drawn when I was in first and second grade, but unfortunately it seems within the last ten years she went and got rid of a lot of that stuff, and turned the rest of it into some scrapbooks. Unfortunately, it appears that most of my old ideas were lost, other than to my memory.

There was just one thing that I did find among all of that stuff, which might have been a video game concept. The strange thing is, this one I have no memory of making. The drawing is of BunnyBots, which looks a bit like Lemmings, only with bunny robots. That field war machines and artillery pieces, apparently. They fire carrot missiles at each other and drop easter egg bombs and have tunneling equipment for digging rabbit holes. Gameplay evidently resembled a 2-player PvP 2D horizontal scrolling RTS.

Mind you, this was probably drawn in 1982-3, long before Lemmings or real-time strategy existed.

I dunno when or if I’ll ever turn this concept into a game, but here’s a scan I made of the drawing:

BunnyBots

Original drawing for BunnyBots videogame concept. Click Image to enlarge.

Super Pitfall for NES was super-pitiful.

Best Of, games
Comments

If you’ve never played a Pitfall game before, it’s best to go back to the beginning to the original Pitfall! on the Atari 2600. One of Activision’s finest games, and one of the best on the console, or on home consoles of its day, period. Pitfall!’s adventuring theme was in style thanks to the popularity of the new blockbuster movie with Indiana Jones, but wasn’t based on the movie. Although it lacked actual “platforms” the game might be thought of as a prototypical platformer — the gameplay is all about running and jumping. Pitfall was followed by a sequel, Pitfall II: The Lost Caverns, which featured a more expansive map, engaging background music, and a real ending, but suffered a bit from repetitive gameplay. Overall it was still a highly regarded game and one of the most technically advanced titles released for the Atari 2600.

In 1985, Nintendo released the NES in North America, and put an end to glut period in the market that had plagued the industry from 1983-4. The consoles of the Atari generation were long in the tooth, but had been so popular in previous years that anyone who could was releasing anything they could burn to an EEPROM cartridge and slap a label on, regardless of quality. This resulted in a huge glut of terrible games, sales plummeted, and some analysts were saying that videogaming was just a fad that had seen its day come and go. Fortunately, Nintendo reversed that thinking, largely on the merits of Super Mario Bros., itself a sequel of sorts to their popular Donkey Kong, Donkey Kong, Jr., and Mario Bros. arcade titles from the previous generation. SMB was an innovative next-generation platformer, which advanced the state of the art over former running and jumping king Pitfall Harry, and introduced many, many innovations and superb level design and a forgiving, yet challenging difficulty curve.

A full two years after the launch of the NES, Activision released Super Pitfall. Only this time, they didn’t develop the game in-house, instead opting to farm it out to a company called Micronics for Pony Inc., I assume due to lack of familiarity with programming for the NES hardware. The game was a failure on so many levels, it’s difficult to enumerate them all, and unbelievable that the game got released at all given the quality of the competition at the time. It’s interesting to contrast Super Pitfall against Super Mario Bros. because fundamentally they have so many things in common, yet one game does everything so well, and the other does everything so poorly.

As a 12 year old, I was excited to play what seemed like a promising title — the Activision games for Atari were top notch and pushed the hardware past the limits of what many thought possible, and the Pitfall games were the creme de la creme.

I can’t promise an exhaustive list of all the ways that this game fails, but here’s my best attempt. Keep in mind I haven’t played this game since I was 12 or 13, so going on 22 years — THAT is how indellibly the “suck” was burned into my cerebral cortex.

Plot:

Plotwise, Super Pitfall is basically just a rehash of Pitfall II: The Lost Caverns. You’re supposed to rescue your niece Rhonda, her pet cat Quick Claw, and find treasures. Apparently, no one at Activision had bothered to put any time into coming up with any new ideas since the release of Pitfall II in 1984. Did they think not enough people had played Pitfall II, and so the plot was still fresh? Did they think that plot didn’t matter for adventure games in the NES era? I can’t say; I can say that the game feels stale from the minute you start reading the instruction booklet. Come on, anyone who liked video games played Pitfall II in 1984; it’s been three years, couldn’t they have taken 15 minutes somewhere and wrote up a new plot?

Graphics:

It’s tough to appreciate how poor the graphics performance is in Super Pitfall without seeing a video. Still screenshots do not convey the problem adequately. There is so much flicker that it becomes easy to lose track of something on the screen because it’s been invisible for that long. Not only do the sprites flicker like a strobe light on low, but they are poorly animated as well. Pitfall Harry looks like Mario dressed up in an coal miner costume — nothing at all like he looked on the Atari. On the Atari, Pitfall is thin, and looks like he might be a tall, wiry guy. In Super Pitfall, he looks tubby, with a big nose and mustache, like Super Mario. This is at once both a sacrilege to the real Pitfall Harry, and a pale, pathetic imitation to Mario. Scrolling is very jerky. Rather than smoothly draw in the new background tiles as the screen moves, it seems to wait until there is space to draw the entire row or column of tiles, and then draws it in all at once. This creates a clunky, lurching effect that looks and feels horrible.

Hit Detection:

Hit detection is imprecise, to put it kindly. Often you die for no apparent reason. Stuff that looks like you’re clear by a good distance can still hit you. Worse, it appears to be inconsistent. Sometimes you die, sometimes you live, with little visually apparent distinction between the life and death. It’s as though the hit detection mask is a variable sized, invisibile object that orbits around the visible graphical sprite that is Pitfall. It is probably also a rectangle, rather than a precisely fit shape.

Controls:

You move slowly, the controls respond slowly to player input, have barely any control over your jump once it’s initiated. It’s just about impossible to get out of the way of anything unless you see it coming well in advance, and it moves in a predictable way. The aforementioned flicker and hit detection problems make this far from simple. The poor jumping control is probably the most inexcusable flaw in the game, after the graphical glitches and performance problems. In a platforming game, jumping is crucial to get right. Super Pitfall blunders by conceding to realism the fact that in real life you can’t alter your trajectory once your feet leave the ground. In Super Mario Bros., you can control much more finely how far and how high you jump, and it makes jumping fun. Mario gets jumping right.

Also, Super Pitfall has a pistol available as a power-up item. The original Pitfall games were essentially non-violent. Pitfall could die from scorpion stings or eaten by alligators, but he himself never committed any violent acts. I’m not against new features, but again, the implementation was shoddy. And I did think that having guns in the game changed the spirit of the original Pitfall, to the detriment of the franchise. What I’m not sure about was the design decision to make the original games non-violent.

Pitfall Harry takes a lot of his cues from Indiana Jones, who only ever used a pistol once in all his movie adventures. So that’s one good reason for Pitfall Harry not to need a gun. As well, in the early 80’s there was a lot of concern about violence in video games affecting young minds, just as there is today. It’s hard to believe, given how cartoonish and low-res the sprite based graphics of the day were back then, but in the early 80’s there were crazy people who were worried that shooting in a video game would result in an increase of shooting in real life. I’m not sure if Pitfall was originally nonviolent due to pressure from these organizations, or due to the idealism of the designers, who maybe wanted to show that non-violent games could be fun, or due to technical limitations for how much you can cram into 4k of 6502 Assembly, or possibly a combination of all three. Partly, I think it was simply because there was only one button on the joystick, and it was for jumping. But the main, and best, reason is that the original games didn’t need a gun. It made for more exciting gameplay if you had to run, evade, and jump past obstacles rather than blast your way through them. Besides, many of the obstacles in the game (I call them obstacles and not enemies, because most of them are indifferent to your presence in the game, and only kill you if you blunder into them) are rare, exotic animals. It just doesn’t seem right that Harry would be willing to gun down some endangered species just so he can get through unimpeded.

Maybe they needed to give you something to do with that second button on the NES game pad. But it’s implemented terribly compared to games where shooting is the main point of playing. In a shooting platformer game, like Contra, you can shoot in any direction, have unlimited ammo, can have as many bullets on the screen as you want. In Super Pitfall, ammo is a resource that you have to collect, you can only fire one bullet at a time, and it sometimes takes several shots to kill an enemy, although I could never tell if this was due to bad hit detection or because there was a variable amount of damage done with the bullets and it sometimes took multiple shots to kill certain enemies. Regardless, killing an enemy feels like a cop-out to avoid having to jump over obstacles. But given how much the hit detection sucks, it’s worth it when you can. But the ammo is so scarse that you dare use the gun only when you’re faced with a situation that you couldn’t possibly jump through unassisted. The idea seems to be that they didn’t want to turn the game into a shooter, and so each bullet you pick up is almost a surrogate for an extra life, and you spend them whenever you see a situation where it looks likely that you’d die if you didn’t use them. It would have been better if they had allowed Pitfall to shoot himself and end the misery.

Hidden stuff, yet no clues as to where they are or what they are for:

Hidden secrets were a big part of Super Mario Bros. popularity. Finding all the hidden coins, bonus rooms, and warp zones was a smart design choice that gave the game a lot of replay value. Super Pitfall has many secrets, too. But again, it’s all spoiled by terrible implementation. Most secrets are discovered by jumping in specific locations on the map. This causes some secret item to appear close by. There’s never any apparent visual cue to tell you that you should try jumping in a specific location; the game sortof expects you to “mine sweep” through the entire map, tile by tile, jumping every step of the way, until you find a secret. Once you do, you’d better memorize it or mark it on a map, or you’ll never find it again. Many of these secrets are essential to making forward progress in the game — keys that unlock other levels, or even the actual gateway to another level. This means if you can’t find the secret, you can’t complete the game. You end up frustrated and give up. There’s no replay incentive to go back again and find secrets, since in order to beat the game once you will end up finding them all, or at least all of the critical items. The non-critical items (bullets, extra lives, bonus points) don’t aren’t necessary if you make it through without getting them, you’re just that much better at the game if you don’t end up needing them, and discovering them is so counter-intuitive and tedious that the less of them you need to find, the happier you are.

Game Map is next to impossible to navigate:

One thing I’ll say about the Lost Caverns that Super Pitfall takes place in: the designers sure gave a convincing feeling that you were lost. So many areas of the game look identical to other areas that it’s very difficult to determine if you’re in a new place or if you’ve somehow looped back to where you had been before. The different areas in the game are linked together through “warps” that take away your sense of geography and you lose your spatial orientation. I couldn’t even tell if I’d left “world 1” and proceeded to “world 2” and then to “world 3” when I warped, or if the entire game was open to me and I was simply warping from Point A to Point B back to Point A. In several places the connection points from one warp area to another are stuck in dead-end passages that you would have no reason to walk down. They look like they’re merely “filler” space on the map and have no purpose.

Conclusions:

I was fortunate in that I discovered the game at a video rental store, so I didn’t waste my money actually buying it. A better title for this game would have been Super PitFAIL. This game was so bad it basically trashed the franchise. I never bothered even looking at any Pitfall title that came afterward. Activision’s execution here is abominable and inexcusable, a travesty to fans of the greatness that was the Atari-era Pitfall. This game has a lot of similarities to Super Mario Bros. when you look at a list of its features and the elements of play, but when you look further, the only real similarity these two games share is the word “Super” in the title.

To properly appreciate how badly designed AND badly constructed this game really is, you should watch a video of it on youtube. There are many, but one of the better one’s is by game reviewer Aqualung. (Warning, may contain objectionable language.)

Part 1/2:

Part 2/2: