Terrablox

This image is probably self explanatory.

The idea here is one inch plastic cubes that link together horizontally and stack vertically.

They're abstract and simple. The brown can be dirt, sand, a tree trunk, or a wooden wall. Gray could be rock, masonry, metal. You'd have a hundred or two of these (roughly a filled shoebox) and create terrain on your tabletop usable for a wide variety of games. Or even just as a toy.

I'm prototyping these now, and intend to try and get them manufactured. Ideally they'd come in a box of one hundred, with several colors, and a mix of cubes and plates.

Nontechnical Explanation of Color in 3D Games

Actual pixel value sent to the pixel on the monitor is, in a typical 3D game:

Texture value * Light value, where each value is a scale from 0.0 to 1.0.

The scale measures from black to white. Or rather, from the monitor displaying that pixel as dark as it go at 0 to as bright as it can go at 1. Different monitors have different maximum outputs, but because of how our eyes work we don't actually notice this as anything except "better contrast". The fact that the colors are recorded as relative to the amount the monitor can output is the cause of problems when designers are making art to be displayed on different monitors, or for print, or whatever.

(As opposed to a 2D game which typically merely blits, i.e. copies the values directly from a sprite image, which is actually analogous to a texture, in a way.)

Thus a 'fully lit' scene will display exactly what the texture is (texture value * 1), while a 'fully dark' scene will display black (texture value * 0). A black texture will always show up as black, and a white texture will show up as whatever the light hitting it is.

Texture value is the value of the pixel of the texture map at that position on the screen, based on the position of the polygon it's mapped to, the way it's mapped to the poly, occlusion, and so on. This is all going on in the GPU is is the majority of the math needed for rendering. You've got to worry about how the poly is rotated, scaled, skewed, and so on. But basically eventually you get a result that says, "This pixel is pulling from THIS spot on the texture image." So this is what I mean by it being analogous to blitting: You've got an image, and you want to get a pixel it from it and draw it at the right spot on the screen.

Light value is the amount of light hitting that spot on that poly from lights placed in the scene. Each light object has it's own value from 0 (no light) to 1 (max light) Note I don't say 'black' and 'white', because that's technically not what's happening.

The lights are all casting some amount of their value on that pixel, usually based on distance. In nature, this falloff has to do with the brightness of the light and the inverse-square law: The intensity of illumination is proportional to the inverse square of the distance from the light source.

This law doesn't actually work though because the value of the light is NOT the luminosity, which I'll explain later.

Rather, the typical game physically sets a radius for each light (set by the level designer, actually) and makes it so the light falls off linearly (although often it's a square falloff) until at the max radius, it's 0. So at the center of the sphere, the light amount if equal to whatever the light is set to, let's say 1,0.5,0.5 for a pinkish light, and at the surface of the sphere it's 0,0,0.

So, the game is finding how much each light in the scene is casting on our pixel, based on each light's distance and value. Once we have a list of all these values, simply add them all together! This part is easy, and even naturally results in lifelike color blending. A red 1,0,0 light and a blue 0,0,1 light will combine to end up with a purple 1,0,1 result. This is why colored lighting was a very early bullet point feature of 3D games.

Now, whatever value you have is the total amount of light being cast on that pixel, which can be anywhere from 0 to infinity (assuming you can place anywhere from 0 to infinite lights). We can't actually store a value on that scale though, we want a scale from 0 to 1. You could set 1 to be whatever the highest value in the scene is and normalize everything else based on that, OR you could simply clamp at at 1,1,1. This is what most games do. Thus, in the level designer's mind, lights will never add together so much that they make the texture render brighter than it is.

Thus if you take a pixel, and its got 0.5 light coming from light A, and 0.75 light coming from light B (after distance check), they'll add together to 1.25 light and be clamped to 1, and we say that that pixel is "fully lit" at 1. In practice it might even be rare for a pixel to ever be fully lit though. It's usually some distance away from all the lights in the scene, and they're often not even max value lights. This is why in, say, Quake 2 if you disable lighting and let everything just be based on texture value everything looks really bright and stark. You're not used to ever seeing those values.

But basically nothing will ever become so bright that it goes outside the range of values possible for the monitor to display.

West Marshes - Magic Items

Magic items are made using "shares" of arcane components. These are things such as rare, magical metals and acids, or extracts from magical creatures. Powdered unicorn horns, dragon's blood, basilisk venom, things like that.

These materials have magical energy which is transferred to, and shaped by, the ritual caster in the creation of a magic item.

Each level of magic item needs a certain amount shares. There's no easily explained progression for the amount it needs, other than it sort of increases not quite by half from the amount needed for the previous level.

One share costs 50 nobles. This is both the price the players pay when buying it from others, and the price they can sell it for.

Residuum weighs more than as given in the PHB. One share of residuum weighs 1/50th of a pound, or about the same as two cents (which are, in turn, the size and weight of modern US pennies). This means a pound of residuum, 50 shares, is worth the same as pound of gold, which is worth 2500 nobles. Gold and residuum are both rare and valuable, and both are used as trade currency when dealing with especially large amounts.

When you disenchant a magic item, or use a ritual to convert magical components into residuum, you get it as small, 1/50th pound lumps, rather than powder. These lumps are often minted into coins, slightly larger than a rupee and worth half a crown. When buying ritual components (something only possible in the largest of cities), you're much more likely to find people (a person, usually) selling residuum coins rather than raw materials.

When reading these prices, keep a few things in mind: two gold coins (200 nobles) is more money than many master craftsmen make in a year. Collecting enough magical components to create a level 15 magic item would be hundreds of thousands of man-hours (assuming non-adventurers) of dangerous work, hunting magical creatures or harvesting rare substances from dangerous areas. Wealthy nobility and kingdoms might be able to afford magic items for themselves, but certainly no army would be equipped with issued magic items.

Adventurers are very lucky indeed, to find such fantastic treasures.

Level |	Shares |	Value |	Shares From Disenchant
1	5	250	1
2	7	350	1
3	9	450	2
4	12	600	2
5	14	700	3
6	25	1,250	5
7	36	1,800	7
8	47	2,350	9
9	58	2,900	12
10	69	3,450	14
11	125	6,250	25
12	181	9,050	36
13	236	11,800	47
14	292	14,600	58
15	347	17,350	69

West Marshes - Coinage

From left, clockwise: A noble, crown, rupee, and cent. The cubes are standard d6s, for reference.

I'm throwing out the 4e coins basically entirely, because according to the DMG the players should have found something like six million pounds of gold (as a party), in addition to magic items, by the time they reach Paragon tier. This is the point at which they're supposed to be "starting" to become famous and interacting with things on a national level, such as commanding or ruling nations.

That outrageous number is for two reasons, one of which is that coins in D&D are described as extremely heavy compared to historical coins. The other reason is because the amounts given for treasure and the cost of magic items are mostly arbitrary, and tend to favor handing out huge piles of gold or platinum as a rule. The prices of everything else are scaled to match.

So in my world, as minted by the Empire of the Unnamed Kings, to which Blanche-Piste belongs, there are four coins.

The base unit is the "noble". This is the second largest coin, 30mm in diameter (about the size of a US half dollar) and 0.03lbs of near pure silver. One of these coins is the equivalent, usage-wise, of a modern $20 bill: larger than any single transaction you're likely to make, but accepted pretty much anywhere and easy to make change for.

The second coin is the "cent". This is a third largest coin, 20mm in diameter (about the size of a US nickel), worth 1/100th of a noble, and is 0.01lbs of near pure copper. This coin is used to make change or for small transactions among commoners, it is something like a US $0.50 or $0.25 coin in the mind of the average person.

The third coin is the "rupee". This is the smallest coin, and is worth 1/10th of a noble, or 10 cents. It is 19mm in diameter, smaller than a cent (about the size of a US penny), and is not pure silver, but rather an alloy of silver and copper, weighing in at 0.006lbs. This is the coin most commonly used among commoners, it would be equivalent, to something like a US $1 bill.

The last coin is the "crown". This coin is 38mm in diameter (about the size of a US silver dollar), the largest coin, and 0.04lbs of near pure gold. It is worth 100 nobles, and thus most commoners will rarely handle more than a handful of these per year, if any. It is difficult to make change for, and used mostly among merchants for large transactions.

Larger transactions, such as gifts between kingdoms or purchases of entire regions, are made using silver or gold bars.

1 pound of cents/copper: 1 noble, 100 coins.
1 pound of rupees: Roughly 16 nobles, 166 coins.
1 pound of nobles/silver: Roughly 33 nobles, 33 coins.
1 pound of crowns/gold: 2,500 nobles, 25 coins.

To put it into real world terms:

If one were to go out to lunch in an average tavern, you would go in with 1 noble (a silver coin), buy a meal, a drink or two, and expect to get back a rupee or two as change.

Crowns, on the other hand, are very rare; try to imagine something like a $1000 USD bill: the amount is something you might expect to pay for certain things, but rarely will you need to actually handle crowns for transactions. You're more likely to just use 100 nobles.

All prices are measured in nobles. When a person sees a crown, they don't think of it as "one crown," but rather, "a hundred noble coin." A rupee is thought of as, "10 cents." The decimal system is in use, so one might see prices such as "23.50", which would be 23 nobles and 50 cents. If you gave the merchant 24 nobles, you would get 5 rupees as change.

The average town-person will carry maybe 1-10 each of nobles, rupees, and cents on their person.

West Marshes

This is a general overview of my D&D campaign, mostly for the benefit of my players.

Setting: Orid Kajeth, the region to the east of your kingdom, across an inland sea. The area was formely settled by a tiefling kingdom, long ago, but they migrated away because the area is very dangerous and was not considered valuable. It is most mostly swamp and marsh, criss-crossed with slow, lazy rivers. The weather is hot and humid year round, with frequent rain in the summer.

Recently (as in nearly a century ago), the dwarven kingdom to the east of Orid Kajeth starting mining in the hills of the region, and found rock salt. Your kingdom established the town of Blanche-Piste to be able to import this resource. The town's name means "White Road", named for the chief trade good: white gold... salt.

The town is only 50 years old, and it was built almost entirely at once by an expedition sent over for the purpose. Now it acts as a port for traders, who come into town, drop off their goods, and take salt. Then merchants in Blanche-Piste take those goods to the dwarves by barge, and trade for more salt for next season's traders. This process happens over about a month, each season except summer, when it's too stormy in the sea.

However, the area is still very dangerous. Your kingdom has sent over soldiers of fortune to help explore the area, guard the barges, and defend the town if needed.

Campaign Structure: We already have ten players, and I'm still pushing for more. This is already twice the size of a normal party, but the idea is for smaller groups of those players to schedule games whenever they can, with whomever they can, instead of everyone committing to a weekly session. Some of the players are playing characters who already live in the town, some are characters coming by ship as a soldier of fortune, and some are drifting in for other reasons.

There's a world map divided into hexes. Each hex is about 2 1/2 miles across, and represents one "area of interest". For each session, the players will decide on a hex, travel to it, explore it, and return to town at the end of the "day". Then next session is free to any other combination of players, who can choose another hex or the same one as they please.

Each hex has a certain type of terrain and certain denizens. These will not be adjusted to match the adventuring party. If you're level one, and stumble across the red dragon: run. But as you go, you'll get a feel for how the wildlife and monsters are dispersed. Many of the hexes will not actually have combat, but require exploration and puzzle solving. You will often find things that help you explore other areas.

Each character will receive a flat amount of XP for each time they go out and explore, plus bonuses for overcoming certain situations. XP is not awarded by headcount of defeated enemies.

Roleplaying: All players are encouraged to visit the IRC channel #lovely-lodge on EsperNet. This channel represents the tavern in Blanche-Piste that becomes the de facto headquarters of the adventurers in town. This is where characters will talk about events that have occurred, speculate on what they mean, and plan their outings into the wilderness. This roleplaying is encouraged to take place at any time between sessions, representing the characters hanging out in town between days of exploring.

Players are encouraged to keep a map of the world, to mark where they've found things, or areas to avoid. Many of the "dungeons" will be too large to explore in a single session, or might require higher level abilities and items to get into the deeper places, even if the dungeon is in a low level area. It will be worth your time to keep note of any doors you haven't been able to open, pits you haven't been able to cross, and things of that nature.

House rules:
Sight and Cover:
Instead of tracing from every corner to determine line of sight and cover, we use Maptool's LOS, which traces from the center. This means it's harder (impossible?) to shoot around corners, you can see less of the map than you would "normally", and it's easier for creatures to hide from each other. You're less likely to gain cover by standing behind a wall (instead you'll block off your view of the battle entirely), so keep that in mind and look for low walls, furniture, windows, etc. to hide behind instead.

If Maptool covers a target's square by half or more, they have superior cover from you. Half or less, normal cover. Usually, lines of cover will radiate out diagonally from where's your standing, while orthogonal will be either clear shot, or entirely hidden. That's what happens when everything is a grid!

Light:
All bright light sources now cast dim light in the outer 1/3rd of their radius. Creatures with lowlight vision see that dim light as bright light, and see an extra 50% of the radius beyond that as dim light. Effectively, they see all light sources expanded by 150%, but what seems dim to you still counts as dim light when determining concealment. If you have lowlight vision, keep in mind that what looks dim to you is total darkness to creatures with normal vision. Keep your allies informed, or your enemies confused, appropriately.

Perception & Insight:
I'll be making these rolls secretly. Additionally, if any player notices something using their passive checks, I'll inform that player with a private message, and it will be up them to have their character tell their allies in character. This means, when a character says something, they might not just be making it up, it might be because I told them.

Bamf: DevLog 4 — Advanced Lighting

Alright, so now we have lighting! At this point I went back and tweaked the physics more, and started working on enemies that look around for you and pay attention to how lit up you are and other cool stuff like that. But to make this easier to read through I'll skip ahead to where I went back and worked on the lights more.

When I first did the lights, they actually didn't look like the screenshots I show in the last post, with the nice gradual shadow that got darker the farther you got from the light. Instead each one would draw a bright circle, and then a bigger dark circle:

You could control the size of the circles though, and it actually looked alright, and divided the levels clearly into 'dark', 'dim', and 'bright'. But mainly just to see if I could, I instead had each light draw a radial gradient, ending up with the gradual falloff shown in the last post.

Then I went further. See, in these examples, the shadows are very sharp and clear, but in real life, shadows have slightly blurry edges. Sometimes. It's kind of taken for granted that shadows are blurry, but they usually are not. What causes blurry shadows is when last is being cast from an area instead of a single point. The smaller the area the light is coming from, the sharper edged the shadows will be. But when you have a large area, there's a portion of the shadow that's hit by *some* of the light. And that slice gets bigger as you get farther from the light.

In the first example, we're tracing the shadow based on where the center of the light is. We find the angles to the corners of the object (red lines), and draw the edges of the shadow (blue area) based on those angles.

If we take into account the entire light, we get this diagram:

The area between the two lines is where the light is partially blocked, and because it gets wider as you go, the shadow gets blurrier the farther away you go.

There are many ways to recreate this effect when you're drawing in a program. One way is to calculate this area where it should be partially blocked, and draw a gradient between the two lines. I didn't choose this method.

Instead, what I'm going to do is make each light act like a small collection of lights scattered around within a small area. The light from each will each cover a slightly different area, and slightly overlap with the other lights, making soft edges on the shadows.

Here's a comparison of a simple light and a so-called 'area' light:

Not only do the shadows look nice and blurry, the blur hides the jaggy edges really well, making the shadows look more like they were painted in. So I call this a win.

Now for the sun. To get outdoor lighting we don't want to just place a bunch of lights all over the place outside the buildings. The sun casts light from very far away, casting all the shadows in the same direction. So we'll make a new type of light called a directional light, and for this type of light, the edges of the shadows will just always be a given angle, instead of based on where the light is. Throw one of these in the level, tell it to make the shadows all going down and slightly to the right, and you have sunlight.

This directional light also works sort of like an area lights: It's acting like a collection of lights, each casting shadows at a slightly different angle. Even though the sun is very far away, it's also very very big, so it's still technically an area light. The effect is probably not as dramatic as it is here, but I don't know the exact measurements so I'm just eyeballing it and using what looks good. As mentioned before, the blurriness hides the jaggy edges, so it's probably fine for this to be too blurry.

But, real life doesn't have pitch black shadows like this, right?

This is for two reasons, one of which is easy to duplicate. The first reason is light bounces off things, it doesn't just stop. Hold up something white and it will reflect light back into the room. This is time consuming to accurately model in a game. Mainstream 3D games are still not doing it, instead faking it with other methods or calculating it beforehand.

The second reason is when you're outside, light isn't coming only from the sun. The sky actually catches and scatters a lot of light, sending it every which way and generally filling all the shadows with light unless they're totally blocked from the sky. There's a simple 3D rendering technique called ambient occlusion that mimics this. For every point in the scene, it measures how much of the sky is visible from that spot. The less sky it can see, the darker that spot is. You can fake this by simply placing a bunch of directional lights all over the place, all aimed at the center of your scene. I did this for a couple projects in school because real ambient occlusion takes a very long time if you want it to look nice.

So I just have a light that works sort of like an area directional light, except instead of only slightly different angles for each pass, it renders roughly 160 lights, starting from point directly right, and increasing by small amounts each time to cast light down and right, down, down and left, and finally ending up pointing directly left.

The end result of this is, light is coming from every direction except down. Here's an example of this ambient light by itself:

And here's what it looks like added to our scene (without on top, with on the bottom):

Cool, now we've got light streaming in through doorways and windows, and the outside feels very bright and outdoorsy, especially compared to the lighting inside. It also means we only have to place two lights in any level to create outdoor lighting: a directional light and the 'fake' ambient occlusion light.

Next post: Tweaking the controls and physics.

Bamf: DevLog 3 — Lighting

Alright, now that we can figure out where shadows would be, we can make lights. 2D games usually do not have lighting calculated by the game; they just have art, which is all hand crafted to look good.

Castlevania: Aria of Sorrow. The blue glow means he's a vampire.

Hand crafted art is good, but it's time consuming and it's hard for the game to figure out how much light is present at a given spot, which we'll need to do later to let the game decide whether enemies can see you or not. Analyzing images to figure out what they are is difficult for a computer. Humans are so good at it that we don't even realize how complex a task it is.

So we're going to take an approach to lighting that's more like how 3D games handle it. We'll just have all our art drawn as if it were brightly lit from every direction, and then place light objects in the level. Anywhere that's not within a certain distance of these lights, or is covered up by a shadow as calculated by our shadow system, will be drawn on the screen very dark. Or more specifically, shadows will be drawn over everything.

Quake 2, the same scene rendered without shadows, and with.  I really could have showed you an example using Bamf screenshots, now that I think about it.

So here's what we have to start with. We have all our black blocks placed around the screen to be the level itself, these are the solid objects. Then a prepainted background image is drawn on the screen. This painting is drawn as if everything were brightly lit and there are very few shadows drawn into it- just enough to show details. Now we want to tell the game we want lights at certain spots, and have it figure out what areas of the screen should be dark, based on that.

Hey, a house. Designed by a man who hated privacy.

To do this, we'll use a similar process as we did for the Line of Sight vision: Draw black shadows over the screen streaming away from each solid object. Except we only want lights to light up a certain radius, and we want more than one light, so shadows have to be able to be erased by other lights.

So we'll change our tactic slightly, and use surfaces. So far we've only been drawing things onto the screen, but you can draw things to your own images and then draw those images to the screen (or to each other, which we'll use in a minute.) Game Maker refers to these extra images as surfaces.

So we make a new image for each light. Start out filling it entirely with black, then draw a white circle centered on where the light is coming from- the light object.

A very realistic light.

Then draw black shadows for any solid objects that are close enough...

It's not a coincidence that it looks like a pie.

And now you have sort of a graph of what's lit up and what's not. In Bamf, here's what the shadow surface looks like for a typical light:

This is also an example of things I have not explained in this post. Find out what for only an extra $59.95.

Once you have one of these surfaces for each light, you can blend them together into one surface. Colored lights will even properly add together to make new colors, because of how Game Maker (and computers in general) record color information:

I could have put the two colored lights closer together to get some bright yellow instead of a slight area of brown, but what would be the fun in that?

And once you have that, you can blend it with your actual game art to darken it:

The man who lives here also hates being able to see what he's doing, I guess.

So what's the benefit of going through all this trouble instead of just painting the level with shadows like this?

First, you can draw the shadows on *top* of the graphics, so the player or enemies that are in dark areas will be covered up by the shadow; they'll be dark.

Second, it's very easy for the game to look at the shadow surface and measure how bright a certain spot is, because now it doesn't have to worry about, for example, whether it's dark because it's a black object, or whether it's actually a dark spot.

Thirdly, it makes it easy to make the game look nice. Even just some blocks on a white background can look spiffy with some good lighting placement:

Not demonstrated in this example: Good lighting placement.

Next post: Advanced lighting.

Bamf: DevLog 2 — Platforming & Line of Sight

Alright, so now I know it's going to be a platformer, it needs a platformer engine! These are fairly simple affairs.

This is partially for my family and might be of interest to those unfamiliar with programming so I'll start from the ground up.

Basically you want stuff to happen on the screen, which is a 2D grid. Each space is a pixel, and the area has a finite size. So you have objects, and each object has an X (horizontal) and Y (vertical) coordinate. Then each object just gets drawn to the screen at whatever its coordinates are. In most cases, the upper left corner is 0,0 and it counts up from there as you go right or down.

Then you can do some more complex things, like change the coordinates of an object by a small amount and repeating every split second, to get the illusion of movement (commonly known as 'animation'). You can tie changes to X to whether a button on the keyboard is pressed, and just have a constant addition to Y for gravity.

Now what if you want the character to stop if he hits something? You need to be able to see if two objects are 'colliding'; occupying the same area of the screen. Typically your objects aren't a single point on the grid, they're an area of the grid, so you can't just check their coordinates and see if they match. You need to check every coordinate within the first object's area, and compare them with all the points within the other object's area. It's easiest to do this if you just assume everything is a rectangle, and that's usually sufficient. If two objects have overlapping areas, they're colliding.

So now we can tell whether two objects are colliding. To make floors and walls, we have more objects, which we'll just call 'solids'. Whenever the player collides with one of these solids, it stop moving. But, if you just did that, the character would get stuck and never move again the first time it collided with a solid. So what you do is check for collisions at where the character would be if it moved, and stop movement beforehand.

Anyway, the collision checking and movement I'm doing is a more complex than this, but I'll talk about that later when I go over how I'm tweaking it. It still works essentially how I've described. At this point I've got a playable platformer engine. I can scatter some solids around a room, and run and jump around on them. It took me about half an hour to get to this point-- Hooray Game Maker.

Now I moved on to Line of Sight, because I really had no idea how to do it. I want any area of the screen that's blocked from the character's vision to covered up with black. This way, you won't be able to see through walls or floors as you typically can in a platformer.

My first idea is to cover the whole screen with black, then erase the black from the areas you can see by tracing lines starting at the player and going outward in incremental angles, continuing each line until it hits a solid. To get perfect shapes, I'd have to send a trace out to every pixel on the edge of the screen, covering any possible gap between lines. But, this is far too many lines to draw every 30th of a second. It slows the game down considerably because for every line, it has to check for collision at each of about a hundred or so positions on the grid to find out where it collides. There's a lot of math involved in comparing all the coordinates of every object with the given coordinates to see if they match up, and it costs time.

So I try drawing really wide lines, and only send out about 60 (or so, I don't remember the exact amount). The lines are wide enough that they cover up the gaps between them. But it's very imperfect now. It basically works; it gets across the idea that you're only seeing what the character can see, but it just looks awful, especially in motion, because it fudges so much.

So clearly this needs a different approach entirely. What if, instead of erasing the visible area, we only draw over the invisible area in the first place? For every solid object, trace out basically a shadow based on where the player is, and draw that shape.

You trace a line to each corner of the solid to find the angle (red lines), then draw shapes from the corners, to other coordinates that are far away but along that same angle (blue lines). By doing each pair of opposite corners, you don't even have to worry about figuring out which corners to draw from, as long as all the solids are rectangular. (If you want to be able to build objects out of non-rectangular shapes, that's more complex. So I'm just going into this knowing my levels will be mostly straight lines.)

Now instead of drawing a line for every pixel on the screen, we're drawing a shape (a polygon actually) for each solid object. We could probably do some checks to make sure we're not drawing shadows for the ones that are going to be covered up by other shadows anyway, but's faster just to draw them all and not worry about drawing over the same areas of the screen a bunch of times.

Plus, now it's pixel-perfect instead of having big, noticeable, weird shapes.

And as a bonus, holy crap, now we have all the math and everything already in place to calculate shadows. Time for lighting.

Bamf: DevLog 1 — Concept

So I'm making a game, and decided to keep a journal of my progress. Let's say weekly-ish. I've already been working on it for about three weeks, so this first post will cover the core ideas, the next post will cover everything I've got so far, and subsequent posts will be plain log entries.

This is actually a restart of a project I worked on for a few months last year. I ended up losing the source, and now I've started over on it with a few new ideas.

The gimmick of the game is the player can teleport without limit. Now how do you make that fun? The typical method to make a game fun is challenge. Perhaps it also has some intrinsic fun because it's so unique and powerful. But let's assume we want it to be challenging and go from there.

I've chosen to make it 2D, because mice are 2D and they're a great controller for quickly selecting a specific spot. (This also makes the DS and the Wii good choices for a platform, but it's easier to develop for PC if you're broke.) I've also chosen to make it a platformer instead of top-down or isometric to have vertical travel be more important. If we make teleporting preserve your velocity, you can teleport to midair spots but you'll fall, potentially reaching a fatal collision speed. This limits teleporting in a natural way; it's easier to move around horizontally than vertically and you have to worry more and finding spots to stand on.

Let's talk about other limits. Typical ways to limit teleporting are range and recovery time. There are many examples of a very short range teleport (a 'blink'), on the order of a few meters. And almost universally you're limited to a certain number of teleports, or teleport-per-unit-of-time. City of Heroes, for example, has a very long startup time. When you click to teleport, it takes a few seconds of your character posing before you actually teleport, and then you can't move for a few moments afterward. This makes it worthless in any fast paced situation, relegating it to travel over long distances. Because it is very long range, it's the best travel option. You can get across any zone in the game in just a few hops with an upgraded teleport.

But what if we want really fast teleporting? This is probably extremely powerful. Even if you limit the range, the character can move around large distances very quickly, if there are places to stand along the way. The traditional platformer goal of, "get to the end of this obstacle course," becomes trivial. Is there some other goal that remains challenging?

What are some other goals in video games besides "get to the end of this area"? A few generalized things come to mind: Defeat opponent(s), collect things. Defeating opponents could be a goal, or *avoiding* defeat by them could be the goal, while you work on other goals (survive a certain amount of time, collect things.)

With these other goals in mind, it's still possible to make "get to this spot" a goal, you just have to keep in mind that typical platformer level design becomes very easy with a teleport. A teleporter is going to be more challenged by things with lots of vertical travel, dangerous drops, and maybe mazes and jumps that only become safe by teleport part of the way.

Anyway, here's what's I've got so far: You have large, intricate levels. Scattered around the levels are objectives, and enemies. It's possible to avoid enemies, and it's very difficult to actually fight them (but your teleport gives you an advantage). You have to go around the level and collect things (possibly NPCs), and getting around the level will switch between slowly sneaking around when guards are present, or running, jumping and performing acrobatics that Feel Good when there is no danger. So the levels will have lots of fun, crisscrossing paths to move around the level easily once you've figured out where to go. Additionally it will have situations and puzzles which push the player's understanding of and skill with the teleport.

So there are a couple different aspects: Stealth, parkour, combat, exploration and how teleporting affects all of them.

Time to build an engine! I've prototyped this game before, about a year ago, and got a pretty good idea of how I want the controls and physics to feel, but I lost that source, so I'm starting over now with a better idea of what I want it to do. Next post: Basics of the engine, and line of sight.

Failure in Games

Why do gamers want the possibility of failure when they play a game?

I've been talking about this a lot with friends over the past few days and here's what I've come up with:

In a game, there are rewards. The win screen, the next level, new abilities, the hopefully engaging story, whatever. The player wants that reward.

It's pretty easy to get that reward by other means. Cheat, download a savegame with everything unlocked, look up the ending, watch someone else play it, or any number of methods, depending on which part you want.

Why don't people do this if they just want the reward? Well, many people do. Especially as games become more complex, presenting stories and ideas that appeal to a wide variety of people. Maybe the story stands on its own; for example watching a Let's Play of the Metal Gear Solid series could conceivably be interesting (if very long winded). Maybe the joy of running around with a fully powered up character surpasses any joy the mediocre story manages to evoke.

But, there's a second reward that persuades people to play the game: the challenge. More specifically, the feeling of triumph when you rise to that challenge. Games have a requirement from the player before the player is allowed the rewards. Figure out how to run, jump, avoid enemies, defeat bosses, complete objectives. Do these with the right timing, in the right situations. Essentially it's a puzzle. What sequence of actions results in success? It's not just that the player wants the reward, it's that she wants to work for it.

On top of this, many games add punishments. The most common punishment is the practice of sending the player back if she fails. In other words, she's actually farther from success than she was at the moment she failed.

This can go between various extremes. Nethack, for example, wipes all your progress. Period. The longer you go, the more progress you're going to lose if you die. Half Life 2 only sets you back a few minutes, due to frequent automatic checkpoints. You're never risking more than a few minutes of progress. Typically you're sent back to the beginning of "the level", which in this context is just a means of noting where you'll be sent back to if you fail.

The reason games do this is to give the player the excitement of risk. It creates tension when she comes close to failure, because failing means she's going to lose some of the effort she spent. She's actually gambling some of her progress to get more progress. She says, "I bet X amount of progress that I can complete this next section." She gets a rush of relief when she succeeds, because the gamble paid off.

But she also gets frustration when the gamble fails, or the challenge is too great. There's a balance between making it so easy it's boring, and so hard that it becomes frustrating. This balance has to do with a lot of factors and is a whole post by itself. Any designer can make a difficult game, but can they make a game where working for the rewards is fun?

One way to reduce potential frustration is to minimize punishments. Remove them entirely; then it's back to just being a puzzle. Figure out and execute the correct sequence of moves, and the player wins. 

Braid is a good example, failing doesn't actually cost anything, it only means you're not moving closer to winning. 

This doesn't make Braid easy, you still have to work for the rewards, but it does make it pretty mellow. You're never losing progress; at worst you're just not gaining any. It takes away the frustration of failure by making failure not cost anything. But you also lose the excitement of risk, because you're never risking anything.

Does this make Braid (or any other game with very low cost failure) a game not worth playing?

It depends on whether you want that excitement of risk.