Higher-Order Fun

Game Design & Game Programming


In Defence of Steam Greenlight

A few days ago, Steam’s already controversial service “Greenlight” (intended as a way to let the community decide which indie games are to be published by it) was surrounded by a true storm of controversy on Steam when they announced that all developers would be forced to pay a one-off US $100 fee before they could list their games on Greenlight (this is once per developer, not per game). All money thus acquired would go to the Child’s Play charity. The indie community was polarized in two camps which were almost at each other’s (and Valve’s) throats.

So let me get this out of the way: I think that Greenlight is a great idea (one of the best things to ever happen to indie gaming, in fact), and I think that the fee should have been there from the start. I shall now explain why.

First, a little disclaimer

Steam Greenlight was announced in a pub in London, where many of UK’s indie developers gathered to listen to Valve’s presentation. I was fortunate enough to be present. Some of the information here comes from my impressions from that presentation, and not merely from what is listed on the Greenlight website. I cannot provide sources for this, obviously, and it may well be subject to interpretation problems or changes since then. Nevertheless, I believe that the information I’m presenting is reasonably accurate.

What is Greenlight about? What is Greenlight NOT about?

Greenlight is primarily a tool to help Valve gauge interest in your game. Remember that Valve is not a charity dedicated to fulfilling the dreams of the indie developers of Earth – they are a BUSINESS. The objective of Greenlight is NOT to promote your game. It’s NOT to make an unknown game discoverable by the masses. On the Greenlight announcement meeting, Valve was clear that it was a tool that you would use to drive your fan base into supporting your game. It’s STILL your job to market and popularize your game. That said, many indie developers are claiming massive increase in sales thanks to the advertisement generated by Greenlight.

In fact, Greenlight is INTENTIONALLY “disorganized”. You can’t list games by popularity, and that’s absolutely by design – they don’t want a system in which games get stuck in positive feedback, with the most popular becoming even more discoverable and the least popular vanishing into the bottom of a list (how many people would actually look at the LEAST popular games, especially since there will be many truly horrid games there?). If you’re casually browsing, every game has an equal chance. If that was ALL there was to it, it’d still work as a system, since overall the most appealing games would still get a higher up-vote count. But, again, you’re supposed to drive your own traffic into your Greenlight page, and that’s absolutely fine – remember, the objective is not to promote the BEST games; it’s to promote the games with the highest SALES POTENTIAL. This was emphasized by their change from “Thumbs up”/”Thumbs down” to “I’d buy this”/”Not interested”.

I believe that once you accept the concept that the objective of Greenlight is to maximize sales, how it’s organized makes perfect sense. I believe that Valve hit an excellent model here.

Here’s another interesting thing: on the meeting, it was implied that Greenlight was now the ONLY acceptable way to get a game on Steam, unless you’re already doing business with them. Indie developers who think that they’re too good, and therefore need not join the unwashed mashes on Greenlight might want to consider getting off their high horses, because Steam is not going to make exceptions for them. They’ll go through popular voting, like everyone else. If they’re really as major as they think they are, they won’t be stuck there for long, and need not worry about it.

Another source of criticism is that the bars are moving SO DAMN SLOWLY – with very few games over 10%, and estimated times to get games approved in ludicrous ranges. But it has been said, both on the Greenlight FAQ and on the meeting, that it’s all tentative – NOBODY knows the dynamics of this system, so Valve is treating it as an experiment, and reserves themselves the right to change the rules at any time (as they should). Ultimately, Greenlight is a GUIDE for them. If they see a very popular game that’s still at 30% and looks like it’d be good for Steam, they might as well promote it to 100% – why not? I expect to see lots of changes to those bars in the coming weeks.

As an example of just how popular a game needs to be to fill the bar, here’s data from a game from which I have data for, Out There Somewhere – Saint11, one of the creators of the game, has agreed to release this data. Despite over 600 favourites, a majority of up-votes and a 9/10 Eurogamer review, it barely manages to have 1% of its bar filled! It will be interesting to see how this progresses over the next few weeks.

Some people have also made it clear that they believe that the existence of down-votes is a terrible idea. However, it’s a critical part of the system – down votes are simultaneously useful for Steam and for the developers of the game to know how popular their games are, and, more importantly, to let Greenlight know that you’ve already seen and rated this game, and never show it on your queue again. If you don’t down-vote the games that are not interesting to you, the queue will appear to be “broken”, and you will believe that discoverability is non-existent. On the matter of letting developers gauge the popularity of their own game, I hope that this will serve as a reality check for the many indie developers who believe that their games are much more interesting than actually perceived by the general public. I have seen developers complaining about 63% of down-votes on their games, even when the reasons for such niche appeal are evident. Hopefully this will make us all more aware of what the audience wants.

Why is the $100 fee a good decision? Why not a lower value?

Originally, uploading games to Greenlight was free. This meant that there were a lot of troll submissions, or people who misunderstood the service for a wishlist. There were also many very sub-par entries, either very early in concept stage, or done by amateur teams. The harsh reality is that most indie games are terrible, precisely because most of them are made by inexperienced teams. The harsher reality is that those don’t deserve to be on Steam, and their presence there was harming everyone else.

The $100 fee makes sure that not only legitimate developers submit their games, but it also discourages people with weak ideas from doing so. A lower value, say $10, could easily have blocked most of the trolls and confused users, but it wouldn’t stop the unmarketable games from being added there. With this relatively high fee, you need to have SOME faith that your game has a decent chance of being approved. Again, remember that Valve’s business is not to include EVERY indie game on Earth, merely the best of them. People who are amongst those almost certainly already have a following around them, and have built enough confidence that this is something that people would pay money for. From that view, $100 becomes a very irrelevant value – it’s the value of a few dozen sales even at low prices. If you don’t think that your game will sell thousands of copies, then don’t bother putting it there.

What about poor indie developers who can’t afford $100?

This is where things got really ugly on Twitter. There were many developers claiming that they simply can’t afford the $100 needed for the submission. They dedicate their lives to the craft and live on the edge, without a cent to spare. But again, this only seems relevant if you have a minor game that nobody has heard of. If you have a fanbase of thousands of people who want to play your game, surely you can do a fundraiser asking for 100 dollars for that purpose. Once your game is on Steam, you can just give them Steam keys (which apparently you can do at will), so this also works as a Kickstarter/Pre-order model. Or you can ask somebody else to cover that cost for you – if you truly have a Steam-quality game on your hands, somebody will pay that for you. I even saw some Tweets of people offering to do so. You’re only “left out” if you’re simultaneously extremely broke and unpopular – and, at that point, you’re not going to be successful in Steam anyway.

Finally, if your game is popular enough to eventually pass Greenlight, it should be popular enough to net you well over $100 of sales on OTHER, more indie-friendly websites, such as Desura. Once your game sold a few copies there, use the money to pay your entry into Greenlight.

Remember: Greenlight and Steam are not your personal marketing page! They are a STORE, to which you will only be admitted after proving that you can reach their standards. They owe you no favours.

Stronger filtering ultimately benefits us all

A lot of people are saying that this tax is just yet another barrier to the “democratization” of sales of indie games, that everyone should have the same chance, etc. Unfortunately, by letting everyone in Greenlight (even ignoring the trolls and confused people), the result was an avalanche of terrible games, with a few gems spread in-between. This makes people think that all indie games are bad, and eventually give up on Greenlight altogether. By increasing the barrier to entry in a way that the signal-to-noise ratio increases, every game that is on Greenlight benefits. It might seem like it’s elitism, but it helps the actually good games, it helps Valve, and it helps the consumers. It’s best to be left out of a good system than let in a broken system.

My answer to those left out is simply: keep making games, learn from your mistakes, and improve. Once your games are good enough, you will be let in, and then you’ll be glad that Greenlight’s filtering has kept it functioning.

Math for Game Programmers 05 – Vector Cheat Sheet

This is the long due fifth article in this series. If you aren’t comfortable with vectors, you might want to take a look at the first four articles in this series before: Introduction, Vectors 101, Geometrical Representation of Vectors, Operations on Vectors.

This cheat sheet will list several common geometrical problems found in games, and how to solve them with vector math.

Read the full article »

The guide to implementing 2D platformers

Having previously been disappointed by the information available on the topic, this is my attempt at categorizing different ways to implement 2D platform games, list their strengths and weaknesses, and discuss some implementation details.

The long-term goal is to make this an exhaustive and comprehensible guide to the implementation of 2D platform games. If you have any sort of feedback, correction, request, or addition – please leave it in the comments!

Disclaimer: some of the information presented here comes from reverse engineering the behavior of the game, not from its code or programmers. It’s possible that they are not ACTUALLY implemented in this way, and merely behave in an equivalent way. Also note that tile sizes are for the game logic, graphical tiles might be of a different size.

Four Ways of Implementing

I can think of four major ways in which a platform game can be implemented. From simplest to most complicated, they are:

Type #1: Tile-based (pure)

Character movement is limited to tiles, so you can never stand halfway between two tiles. Animations may be used to create the illusion of smooth movement, but as far as the game logic is concerned, the player is always right on top of a specific tile. This is the easiest way to implement a platform game, but it imposes heavy restrictions on the control of character, making it unsuitable for traditional action-based platformers. It is, however, popular with puzzle and “cinematographic” platformers.

Flashback, shown with tile boundaries

Examples: Prince of Persia, Toki Tori, Lode Runner, Flashback

How it works

The map is a grid of tiles, each one storing information such as whether it’s an obstacle or not, what image to use, what kind of footstep sound to use, and so on. The player and other characters are represented by a set of one or more tiles that move together. In Lode Runner, for example, the player is a single tile. In Toki Tori, the player is 2×2 tiles. In Flashback, which is unusual due to the smaller size of its tiles, the player is two tiles wide and five tiles tall (see image above) when standing, but only three tiles tall when crouching.

In this kind of game, the player will rarely – if ever – be moving diagonally, but, if he is, the movement can be decomposed in two separate steps. Likewise, he will likely only move one tile at once, but multi-tile movement can be done as multiple steps of one tile, if needed (in Flashback, you always move two tiles at once). The algorithm is then as follows:

  1. Create a copy of the character where he’d like to move to (e.g., if moving one tile to the right, make a copy where every tile of the character is shifted 1 tile to the right)
  2. Check that copy for intersection with the background and other characters.
  3. If an intersection is found, the character’s movement is blocked. React accordingly.
  4. Otherwise, the path is clear. Move character there, optionally playing an animation so the transition looks smooth.

This kind of movement is very ill-suited for traditional arc-shaped jumps – so games in this genre often have no jump at all (Toki Tori, Lode Runner), or only allow vertical or horizontal jumps (Prince of Persia, Flashback), which are nothing but special cases of linear movement.

Advantages of this system include simplicity and precision. Since the games are more deterministic, glitches are much less likely, and the gameplay experience is more controlled, with less of a need to tweak values depending on circumstances. Implementing certain mechanics (such as grabbing ledges and one-way platforms) becomes a breeze, compared to more complex movement styles – all you have to do is check whether the player tiles and the background tiles are aligned in the one specific way that allows for a given action.

In principle, this system doesn’t allow steps of less than one tile, but that can be mitigated in a few different ways. For example, the tiles can be a bit smaller than the player (say, a player is 2×6 tiles), or you can allow a visual-only movement to take place inside a given tile, without affecting the logic (which is the solution that I believe that “Lode Runner – The Legend Returns” takes).

Type #2: Tile Based (Smooth)

Collision is still determined by a tilemap, but characters can move freely around the world (typically with 1px resolution, aligned to integers, but see the note at the end of article regarding smoothing of movement). This is the most common form of implementing platformers in 8-bit and 16-bit consoles, and remains popular today, as it is still easy to implement and makes level editing simpler than more sophisticated techniques. It also allows for slopes and smooth jump arcs.

If you’re unsure which type of platformer you want to implement, and you want to do an action game, I suggest going for this one. It’s very flexible, relatively easy to implement, and gives you the most control of all four types. It’s no wonder that the majority of the best action platformers of all time are based on this type.

Mega Man X, shown with tile boundaries and player hitbox.

Examples: Super Mario World, Sonic the Hedgehog, Mega Man, Super Metroid, Contra, Metal Slug, and practically every platformer of the 16-bit era

How it works

Map information is stored in the same way as with the pure tile technique, the difference is merely in how the characters interact with the background. The character’s collision hitbox is now an Axis-Aligned Bounding Box (AABB, that is, a rectangle that cannot be rotated), and are typically still an integer multiple of tile size. Common sizes include one tile wide and one (small Mario, morph ball Samus), two (big Mario, Mega Man, crouched Samus) or three (standing Samus) tiles tall. In many cases, the character sprite itself is larger than the logical hitbox, as this makes for a more pleasant visual experience and fairer gameplay (it’s better for the player to avoid getting hit when he should have than for him to get hit when he should not have). In the image above, you can see that the sprite for X is square-ish (in fact, is two tiles wide), but his hitbox is rectangular (one tile wide).

Assuming that there are no slopes and one-way platforms, the algorithm is straightforward:

  1. Decompose movement into X and Y axes, step one at a time. If you’re planning on implementing slopes afterwards, step X first, then Y. Otherwise, the order shouldn’t matter much. Then, for each axis:
  2. Get the coordinate of the forward-facing edge, e.g. : If walking left, the x coordinate of left of bounding box. If walking right, x coordinate of right side. If up, y coordinate of top, etc.
  3. Figure which lines of tiles the bounding box intersects with – this will give you a minimum and maximum tile value on the OPPOSITE axis. For example, if we’re walking left, perhaps the player intersects with horizontal rows 32, 33 and 34 (that is, tiles with y = 32 * TS, y = 33 * TS, and y = 34 * TS, where TS = tile size).
  4. Scan along those lines of tiles and towards the direction of movement until you find the closest static obstacle. Then loop through every moving obstacle, and determine which is the closest obstacle that is actually on your path.
  5. The total movement of the player along that direction is then the minimum between the distance to closest obstacle, and the amount that you wanted to move in the first place.
  6. Move player to the new position. With this new position, step the other coordinate, if still not done.


Mega Man X, with slope tile annotations

Slopes (the tiles pointed by green arrows on the image above) can be very tricky, because they are obstacles, and yet still allow the character to move into their tile. They also cause movement along the X axis to adjust position on the Y axis. One way to deal with them is to have the tile store the “floor y” of either side. Assuming a coordinate system where (0, 0) is at top-left, then the tile just left of X (first slope tile) is {0, 3} (left, right), then the one he stands on is {4, 7}, then {8, 11}, then {12, 15}. After that, the tiles repeat, with another {0, 3}, etc, and then we have a steeper slope, composed of two tiles: {0, 7} and {8, 15}.

Detailed View of the {4, 7} tile

The system that I’m going to describe allows arbitrary slopes, though for visual reasons, those two slopes are the most common, and result in a total of 12 tiles (the 6 described previously, and their mirrorings). The collision algorithm changes as follows for horizontal movement:

  • Make sure that you step X position before Y position.
  • During collision detection (4 above), the slope only counts as a collision if its closest edge is the taller (smaller y coordinate) one. This will prevent characters from “popping” through the slope from the opposite side.
  • You might want to forbid slopes to stop “halfway through” (e.g. on a {4, 7} tile). This restriction is adopted by Mega Man X and many other games. If you don’t, you have to deal with the more complicated case of the player attempting to climb from the lower side of the slope tile – one way to deal with this is to pre-process the level, and flag all such offending tiles. Then, on collision detection, also count it as a collision from the lower side if the player’s lowest y coordinate is greater (that is, below) the tile’s offset edge (tile coord * tile size + floor y).
  • A full obstacle tile adjacent to the slope the character is currently on should not be considered for collision if it connects to the slope, that is, if the character (that is, his bottom-center pixel) is on a {0, *} slope, ignore left tile, and, if on a {*, 0} slope, ignore the right tile. You may have to do this for more tiles if your character is wider than two tiles – you might simply skip checking on the entire row if the player is moving towards the upper side of slope. The reason for this is to prevent the character from getting stuck at those tiles (highlighted yellow above) while still climbing the slope, as his foot will still be below the “surface level” by the time he comes into contact with the otherwise solid tile.

And for vertical movement:

  • If you’re letting gravity do its job for downhill movement, make sure that the minimum gravity displacement is compatible with slope and horizontal velocity. For example, on a 4:1 slope (as {4, 7} above), the gravity displacement must be at least 1/4 of the horizontal velocity, rounded up. On a 2:1 slope (such as {0, 7}), at least 1/2. If you don’t ensure this, the player will move horizontally right off the ramp for a while, until gravity catches up and drags him down, making him bounce on the ramp, instead of smoothly descending it.
  • An alternative to using gravity is to compute how many pixels above floor the player was before movement, and how many it is afterwards (using the formula below), and adjust his position so they’re the same.
  • When moving down, instead of considering a slope tile’s top edge as its collision boundary, instead, compute its floor coordinate at the current vertical line, and use that. To do that, find the [0, 1] value which represents the player’s x position on tile (0 = left, 1 = right) and use it to linearly interpolate the floorY values. The code will look something like: 
    float t = float(centerX - tileX) / tileSize;
    float floorY = (1-t) * leftFloorY + t * rightFloorY;
  • When moving down, if multiple tiles on the same Y coordinate are obstacle candidates, and the one on the X coordinate of the player’s center is a slope tile, use that one, and ignore the rest – even though the others are technically closer. This ensures proper behaviour around the edges of slopes, with the character actually “sinking” on a completely solid tile because of the adjacent slope.

One-way platforms

Super Mario World, showing Mario falling through (left) and standing on (right) the same one-way platform

One-way platforms are platforms that you can step on, but you can also jump through them. In other words, they count as an obstacle if you’re already on top of them, but are otherwise traversable. That sentence is the key to understanding their behavior. The algorithm changes as follows:

  • On the x axis, the tile is never an obstacle
  • On the y axis, the tile is only an obstacle if, prior to the movement, the player was entirely above it (that is, bottom-most coordinate of player was at least one pixel above top-most coordinate of one-way platform). To check for this, you will probably want to store the original player position before doing any stepping.

It might be tempting to have it act as an obstacle if the player’s y speed is positive (that is, if the player is falling), but this behavior is wrong: it’s possible for the player to jump so he overlaps the platform, but then falls down again without having his feet reach the platform. In that case, he should still fall through.

Some games allow the player to “jump down” from such platforms. There are a few ways to do this, but they are all relatively simple. You could, for example, disable one-way platforms for a single frame and ensure that y speed is at least one (so he’ll be clear of the initial collision condition on the next frame), or you could check if he’s standing exclusively on one-way platforms, and, if so, manually move the player one pixel to the bottom.


Mega Man 7, with tile boundaries, highlighted ladder tiles, and player ladder hitbox.

Ladders might seem complicated to implement, but they are simply an alternate state – when you’re in a ladder, you ignore most of the standard collision system, and replace it with a new set of rules. Ladders are typically one tile wide.

You can usually enter the ladder state in two ways:

  • Have your character hitbox overlap with the ladder, either on ground or on air, and hit up (some games also allow you to hit down)
  • Have your character stand on top of a “ladder top” tile (which is often a one-way platform tile as well, so you can walk on top of it), and hit down.

This has the effect of immediately snapping the player’s x coordinate to align with the ladder tiles, and, if going down from the top of ladder, move y coordinate so player is now inside the actual ladder. At this point, some games will use a different hitbox for the purposes of determining whether the player is still on the ladder. Mega Man, for example, seems to use a single tile (equivalent to top tile of the original character, highlighted in red in the image above).

There are a few different ways of LEAVING the ladder:

  • Reaching the top of the ladder. This will usually prompt an animation and move the player several pixels up in y, so he’s now standing on top of the ladder.
  • Reaching the bottom of a hanging ladder. This will cause the player to simply fall, although some games won’t let the player leave the ladder in this way.
  • Moving left or right. If there is no obstacle on that side, the player may be allowed to leave that way.
  • Jumping. Some games allow you to release the ladder by doing this.
While on the ladder, the character’s movement changes so, typically, all he can do is move up and down, and sometimes attack.


Castlevania: Dracula X, with tile boundaries

Stairs are a variation of ladders, seen in few games, but notably in the Castlevania series. The actual implementation is very similar to that of ladders, with a few exceptions:

  • The player moves tile by tile or half-tile by half-tile (as in Dracula X)
  • Each “step” causes the player to be shifted simultaneously on X and Y coordinates, by a preset amount.
  • Initial overlapping detection when going up might look on the tile ahead instead of just the current overlap one.
Other games also have stairs that behave like slopes. In that case, they are simply a visual feature.

Moving Platforms

Super Mario World

Moving platforms can seem a little tricky, but are actually fairly simple. Unlike normal platforms, they cannot be represented by fixed tiles (for obvious reasons), and instead should be represented by an AABB, that is, a rectangle that cannot be rotated. It is a normal obstacle for all collision purposes, and if you stop here, you’ll have very slippery moving platforms (that is, they work as intended, except that the character does not move along it on his own).

There are a few different ways to implement that. One algorithm is as follows:

  • Before anything on the scene is stepped, determine whether the character is standing on a moving platform. This can be done by checking, for example, whether his center-bottom pixel is just one pixel above the surface of the platform. If it is, store a handle to the platform and its current position inside the character.
  • Step all moving platforms. Make sure that this happens before you step characters.
  • For every character that’s standing on a moving platform, figure the delta-position of the platform, that is, how much it has moved along each axis. Now, shift the character by the same amount.
  • Step the characters as usual.

Other Features

Sonic the Hedgehog 2

Other games have more complicated and exclusive features. Sonic the Hedgehog series is notable for this. Those are beyond the scope of this article (and my knowledge, for that matter!), but might be subject of a future article.

Type #3: Bitmask

Similar to “Tile Based (Smooth)”, but instead of using large tiles, an image is used to determine collision for each pixel. This allows finer detailing, but significantly increases complexity, memory usage, and requires something akin to an image editor to create levels. It also often implies that tiles won’t be used for visuals, and may therefore require large, individual artwork for each level. Due to those issues, this is a relatively uncommon technique, but can produce higher quality results than tile-based approaches. It is also suitable for dynamic environments – such as the destructible scenarios in Worms – as you can “draw” into the bitmask to change the scenario.

Worms World Party, featuring destructible terrain

Examples: Worms, Talbot’s Odyssey

How it works

The basic idea is very similar to the tile (smooth) algorithm – you can simply consider each pixel to be a tile, and implement the exact same algorithm, and everything will work, with one major exception – slopes. Since slopes are now implicitly defined by the positioning between nearby tiles, the previous technique doesn’t work, and a much more complex algorithm has to be used in its place. Other things, such as ladders, also become trickier.


Talbot’s Odyssey, with the collision bitmask overlaid on top of the game.

Slopes are the primary reason why this type of implementation is very hard to get right. Unfortunately, they are also pretty much mandatory, as it’d make no sense to use this implementation without slopes. Often, they’re the reason why you’re even using this system.

This is, roughly, the algorithm used by Talbot’s Odyssey:

  • Integrate acceleration and velocity to compute the desired delta-position vector (how much to move in each axis).
  • Step each axis separately, starting with the one with the largest absolute difference.
  • For the horizontal movement, offset the player AABB by 3 pixels to the top, so he can climb slopes.
  • Scan ahead, by checking against all valid obstacles and the bitmask itself, to determine how many pixels it is able to move before hitting an obstacle. Move to this new position.
  • If this was horizontal movement, move as many pixels up as necessary (which should be up to 3) to make up for slope.
  • If, at the end of the movement, any pixel of the character is overlaping with any obstacle, undo the movement on this axis.
  • Regardless of result of last condition, proceed to do the same for the other axis.
Because this system has no distinction between moving down because you’re going downhill or because you’re falling, you’re likely to need a system counting how many frames it’s been since the character last touched the floor, for purposes of determining whether it can jump and changing animation. For Talbot, this value is 10 frames.
Another trick here is efficiently computing how many pixels it can move before hitting something. There are other possible complicating factors, such as one-way platforms (dealt in the exact same way as for tiled (smooth)) and sliding down steep inclines (which is fairly complex and beyond the scope of the article). In general, this technique requires a lot of fine tuning, and is intrinsically less stable than tile-based approaches. I only recommend it if you absolutely must have detailed terrain.

Type #4: Vectorial

This technique uses vectorial data (lines or polygons) to determine the boundaries of collision areas. Very difficult to implement properly, it is nevertheless increasingly popular due to the ubiquity of physics engines, such as Box2D, which are suitable for implementing this technique. It provides benefits similar to the bitmask technique, but without major memory overhead, and using a very different way of editing levels.

Braid (level editor), with visible layers (top) and the collision polygons (bottom)

Examples: Braid, Limbo

How it works

There are two general ways of approaching this:

  • Resolve movement and collisions yourself, similar to the bitmask method, but using polygon angles to compute deflection and have proper slopes.
  • Use a physics engine (e.g. Box2D)

Obviously, the second is more popular (though I suspect that Braid went for the first), both because it is easier and because it allows you to do many other things with physics in the game. Unfortunately, in my opinion, one has to be very careful when going this route, to avoid making the game feel like a generic, uninteresting physics-platformer.

Compound objects

This approach has its own unique problems. It may suddenly be difficult to tell whether the player is actually standing on the floor (due to rounding errors), or whether it’s hitting a wall or sliding down a steep incline. If using a physics engine, friction can be an issue, as you’ll want friction to be high on the foot, but low on the sides.

There are different ways to deal with those, but a popular solution is to divide the character into several different polygons, each with different roles associated: so you’d (optionally) have the main central body, then a thin rectangle for feet, and two thin rectangles for sides, and another for head or some similar combination. Sometimes they are tapered to avoid getting caught into obstacles. They can have different physics properties, and collision callbacks on those can be used to determine the status of character. For more information, sensors (non-colliding objects that are just used to check for overlap) can be used. Common cases include determinining whether we’re close enough to the floor to perform a jump, or if the character is pushing against a wall, etc.

General Considerations

Regardless of the type of platform movement that you have chosen (except perhaps for type #1), a few general considerations apply.


Super Mario World (low acceleration), Super Metroid (mid acceleration), Mega Man 7 (high acceleration)

One of the factors that affects the feel of a platformer the most is the acceleration of the character. Acceleration is the rate of change in speed. When it is low, the character takes a long time to reach its maximum velocity, or to come to a halt after the player lets go of controls. This makes the character feel “slippery”, and can be hard to master. This movement is most commonly associated with the Super Mario series of games. When the acceleration is high, the character takes very little (or no time) to go from zero to maximum speed and back, resulting in very fast responding, “twitchy” controls, as seen in the Mega Man series (I believe that Mega Man actually employs infinite acceleration, that is, you’re either stopped or on full speed).

Even if a game has no acceleration on its horizontal movement, it is likely to have at least some for the jump arcs – otherwise they will be shaped like triangles.

How it works

Implementing acceleration is actually fairly simple, but there are a few traps to watch out for.

  • Determine xTargetSpeed. This should be 0 if the player is not touching the controls, -maxSpeed if pressing left or +maxSpeed if pressing right.
  • Determine yTargetSpeed. This should be 0 if the player is standing on a platform, +terminalSpeed otherwise.
  • For each axis, accelerate the current speed towards target speed using either weighted averaging or adding acceleration.
The two acceleration methods are as follows:
  • Weighted averaging: acceleration is a number (“a”) from 0 (no change) to 1 (instant acceleration). Use that value to linearly interpolate between target and current speed, and set the result as current speed.
vector2f curSpeed = a * targetSpeed + (1-a) * curSpeed;
if (fabs(curSpeed.x) < threshold) curSpeed.x = 0;
if (fabs(curSpeed.y) < threshold) curSpeed.y = 0;
  • Adding acceleration: We’ll determine which direction to add the acceleration to (using the sign function, which returns 1 for numbers >0 and -1 for <0), then check if we overshot.
vector2f direction = vector2f(sign(targetSpeed.x - curSpeed.x),
                              sign(targetSpeed.y - curSpeed.y));
curSpeed += acceleration * direction;
if (sign(targetSpeed.x - curSpeed.x) != direction.x)
    curSpeed.x = targetSpeed.x;
if (sign(targetSpeed.y - curSpeed.y) != direction.y)
    curSpeed.y = targetSpeed.y;
It’s important to integrate the acceleration into the speed before moving the character, otherwise you’ll introduce a one-frame lag into character input.
When the character hits an obstacle, it’s a good idea to zero his speed along that axis.

Jump control

Super Metroid, Samus performing the “Space Jump” (with “Screw Attack” power-up)

Jumping in a platform game can be as simple as checking if the player is on the ground (or, often, whether he was on the ground anytime on the last n frames), and, if so, giving the character an initial negative y speed (in physical terms, an impulse) and letting gravity do the rest.

There are four general ways in which the player can control the jump:

  • Impulse: seen in games such as Super Mario World and Sonic the Hedgehog, the jump preserves the momentum (that is, in implementation terms, the speed) that the character had before the jump. In some games, this is the only way to influence the arc of the jump – just like in real life. There is nothing to implement here – it will be like this unless you do something to stop it!
  • Aerial acceleration: that is, retaining control of horizontal movement while in mid-air. Though this is physically implausible, it is a very popular feature, as it makes the character much more controllable. Almost every platformer game has it, with exceptions for games similar to Prince of Persia. Generally, the airborne acceleration is greatly reduced, so impulse is important, but some games (like Mega Man) give you full air control. This is generally implemented as merely tweaking the acceleration parameter while you’re airborne.
  • Ascent control: another physically implausible action, but very popular, as it gives you much greater control over the character. The longer you hold the jump button, the higher the character jumps. Typically, this is implemented by continuing to add impulse to the character (though this impulse can incrementally decrease) for as long as the button is held, or alternatively by suppressing gravity while the button is held. A time limit is imposed, unless you want the character to be able to jump infinitely.
  • Multiple jumps: once airborne, some games allow the player to jump again, perhaps for an unlimited number of times (as in the Space Jump in Super Metroid or the flight in Talbot’s Odyssey), or for a limited number of jumps before touching the ground (“double jump” being the most common choice). This can be accomplished by keeping a counter that increases for each jump and decreases when you’re on the ground (be careful when you update this, or you might reset it right after the first jump), and only allowing further jumps if the counter is low enough. Sometimes, the second jump is shorter than the initial one. Other restrictions may apply – the Space Jump only triggers if you’re already doing a spin jump and just began to fall.

Animations and leading

Black Thorne, character doing a long animation before shooting backwards (Y button)

In many games, your character will play an animation before actually performing the action you requested. However, on a twitchy action-based game, this will frustrate players – DON’T DO THAT! You should still have leading animations for things such as jumping and running, but if you care about how the game responds, make those cosmetic only, with the action taken immediately regardless of the animation.

Smoother movement

Using integers to represent the position of the characters is wise, as it makes it faster and stable. However, if you use integers for everything, you will end up with some jerky motion. There are multiple solutions to this. These are a few:

  • Use a float for all computations and for storing position, and cast to int whenever you’re rendering or computing collisions. Fast and simple, but it starts losing precision if you move too far away from (0,0). This is probably not relevant unless you have a very large playfield, but it’s something to keep in mind. If it comes to it, you can use a double instead.
  • Use a fixed point number for all computations and position, and again cast to int when you’re rendering or computing collisions. Less precise than float and with a more limited range, but the precision is uniform and can, on some hardware, be faster (notably, floating point processing is slow on many mobile phones).
  • Store position as an integer, but keep a “remainder” stored in a float. When integrating position, compute the delta-movement as a float, add the remainder to the delta-movement, then add the integer part of this value to the position, and the fractional part to the “remainder” field. On the next frame, the remainder will get added back in. The advantage of this method is that you’re using an integer everywhere except for movement, ensuring that you won’t have floating point complications elsewhere, and increasing performance. This technique is also very suitable if you have some framework in which the position of the object has to be an integer, or where it is a float, but that same position is used directly by the rendering system – in that case, you can use the framework-provided float position to store integer values only, to make sure that the rendering is always aligned to pixels.

On how Diablo III fails to live up to the Diablo legacy

[Edit: I’m now halfway through Act II, and everything I say stands – and, in fact, the problems have become even more obvious]

Diablo III just got released this week, to a spectacularly catastrophic launch day in which almost nobody could play. But once the server loads normalized and the initial hype died out, a surge of furious comments started to take over Twitter and Metacritic (where it has the wonderful User Score of 3.6). What went wrong? In my opinion, Blizzard has slowly been taking away everything that made Diablo excellent, and re-worked it into a far more generic (and perhaps marketable, they expect) experience.

It got to the point where I was almost quitting the game in disgust several times, but I tried to endure – until I saw King Leoric – a character who, in the original game, would greet you with “The warmth of life has entered my tomb. Prepare yourself, mortal, to serve my master for eternity” – brought back as a pathetic parody of its former self, in a ridiculous context, spitting out boring lines, and I just couldn’t take it anymore. I will probably go back to it, and maybe eventually beat it, but it will never be anything near the first two Diablo games.

For a game that actually has a reasonably solid gameplay, it’s peculiar that such things would bother me so much. But they did, and I think that understanding why is important, so here’s my best attempt at expressing what I felt. This might resonate with your own experiences, or you might have had completely different feelings. If so, please share in the comments.

Let’s recap.


Diablo (and by that I mean Diablo I) was a dark, moody, atmospheric game. I don’t feel that it’d be a major stretch to call it a horror game. The soundtrack was unique, powerful, memorable, and very, very creepy. The sound effects were of excellent quality – possibly better than in Diablo II and III, even. The scenarios were dark, and you couldn’t see much. Your character was initially very weak, and through most of the game, a bad mistake would cost your life (which was a far worse punishment – you’d drop all equipment to the floor, leaving it vulnerable to be stolen, and making it harder to kill whatever killed you). The game intro set the perfect tone for the game:

Then along came Diablo II. Instead of being confined to maze-like dark dungeons, you were thrown into open, bright worlds full of creatures that posed less of a real challenge. The music was unremarkable, and failed to add to the atmosphere. Worst of all, you felt POWERFUL. This was no longer about a mad heroic journey – this was just hack and slashing. This is the same reason why Amnesia is genuinely scary, while Doom 3 and Dead Space are nowhere near as much – you just have too much power in those games, compared to the defenseless protagonist of Amnesia. But Diablo II still tried to be dark and horror-ish, and in many senses, it succeeded. The cinematics certainly preserve the feel of the original game. Let’s look at the intro:

And then comes Diablo III. It took the same changes Diablo II had done, and amplified them. I see no hint of horror in this game. All I see is generic adventuring. This feels like D&D. This feels like Torchlight. This feels like WoW. It feels like many things… unfortunately, Diablo is not one of them. Here’s the intro:

The progressive change of mood in those intro videos is fairly telling of what’s going on with the series, I’m afraid.


This is where the game really stroke a nerve. I’ve been under the impression that all of Blizzard’s writers were either fired or driven to incompetence after the release of the original StarCraft. From Brood War onwards, the quality of the text and storylines has decreased significantly, and Diablo III is the most telling example.

Diablo I had little in-game plot. You just returned to Tristram, which has been overran by a mysterious dark force coming from the depths of the local church. As you slowly descended through its dungeons, you got a few more hints of what was going on, until you finally came face-to-face with the Lord of Terror himself, Diablo. But that’s not to say that it was bad – first of all, it strengthened the atmosphere of mystery in the game. Second, what little was told was superbly well written. Third, the manual itself had excellent backstory, explaining the events preceding the fall of Tristram in a compelling and believable way. Here’s a sample of in-game dialogue:

It’s said that Tolkien was once asked why didn’t he wrote about all those distant mountains he would talk about on his books. His reply was supposedly “I could talk about them, but then I would need even farther mountains”. Part of making the world believable is to have a lot more to it than just what’s immediately visible to the player. The team behind Diablo I understood that well… but in Diablo II, they made a terrible mistake. They systematically went through the backstory in the Diablo manual and, as if holding a checklist, made sure that everything they encountered there would be directly relevant to the story of Diablo II. Andariel, Duriel, Mephisto and Baal. Archangel Tyrael. Tal Rasha. Even Izual and the Hellforge. Very little was added to make up for the losses, and what little it was was of far inferior quality. The game world had completely lost all its depth. A world in which you can see for yourself EVERYTHING ever mentioned in any form of Lore might be suitable for a massive MMO where you can actually travel the whole world – but just makes everything seem very shallow when you stride across a handful of small towns and just happen to run into every legend there ever was. Dialogues were plentyful, but very bland. In every way, they had managed to lose the magic of the game’s story. In a way, it felt like a fan game – eagerly consuming any elements it could find from canon, while making very predictable and boring additions.

When I thought that it couldn’t get any worse, Diablo III managed it. Do you remember how, in Diablo, your character (now called “Aidan”) was the elder son of King Leoric? No? Well, neither do I, but it has been retconned to be that way by Diablo III. Very peculiar that nobody in Diablo recognized him as such, and that he would say “Rest well, Leoric, I will find your son!” after slaying his undead body. The installer presents an avalanche of slightly tweaked events, written with pompous adjectives and going as far as pausing mid-sentence to name Tyrael’s sword – as if that had ever been relevant. Do you remember Adria’s daughter, Leah? You know, Deckard Cain’s niece? No? Also, people sure do like Tristram, going ahead and building a “New Tristram” right next to where one of the three Prime Evils came back not so many years ago (I assume so, anyway, as Cain was already old in the first game and has managed not to kick the bucket yet). Speaking of Tristram, can we decide whether the whole incident took place in its church (D1), monastery (D2) or cathedral (D3)? But now I’m stepping into nitpicking territory – although this sort of inconsistency only shows how little they care about making it coherent.


I would normally argue that gameplay is the most important thing in a game, but Diablo III makes me wonder to what degree is that true. There’s nothing really WRONG with the gameplay – it has been simplified from Diablo I and II, certainly, as it is now much more forgiving and “casual-friendly”, but that doesn’t bother me too much. I prefer more complex RPGs, but this is hardly what’s stopping me from playing.

It does have to be said that the new system does make me feel like a versatile, powerful character, which, as I mentioned before, is the exact opposite of what a Diablo character should ideally feel like. But I suppose that role-playing a cool and powerful character that spits pseudo-witty lines to coward mayors is very popular with most players, and setting be damned.

There is one thing, however, which is unforgivable. In an attempt to stop cheating and piracy, Blizzard has forced everyone to ALWAYS be playing online, through their servers. If their servers are down, or if your connection is unstable, or if you’re in an airplane – you can’t play. It doesn’t matter if you just want to have some solo fun – you’re STILL playing multiplayer, for every technical purpose. This is the worst form of DRM, and the only reason why anyone is willing to put up with it is because of Blizzard’s history of excellent games. Unfortunately, as of late, I can’t even say that they still make excellent games. Speaking of Blizzard’s history of DRM, do you remember how Diablo I would let you install a semi-demo copy (“Spawned version”) on a friend’s computer, so he could play with somebody who had the full version, subject to only a few limitations? And how the game didn’t even have a CD-key? From that to THIS? How long you’ve come, Blizzard.

I might not buy another Blizzard game, but this hardly matters – I’m sure their profits will continue to escalate. By making “popular art”, they sacrifice the exquisite quality that their games always had, but profit even more. Jonathan Blow said that you shouldn’t try to do what the audience wants – instead, you should make something great, and the audience (or, at least, some of it) will want that even more than what they originally thought they wanted – and I agree with that sentiment. I don’t think that many others do, however.

A shame, too. I WANTED to love this game.

“Fourteen years were not enough” / “14 anos não foram o suficiente”

A while ago, there was a discussion in a mail group composed of members of the Brazilian videogame industry, regarding its perceived lack of progress when compared to many other countries – the case in point was that even Iran was showing more impressive results than us. I sent the following email, and since people have since come to tell me that they really enjoyed the text and wanted to publish or spread it, I’ve decided to make it available here on the blog, both the original in Portuguese and an English translation.

English Translation

Here follows my opinion. I don’t presume to assert it as fact, but to me it seems like a realistic picture of the situation.

There might be a lack of governmental incentive, but that, in my opinion, is no excuse. We have examples of games which had literally millions of Reais spent on them, and at the end had a catastrophic or disappointing result. There are many examples of games with less exorbitant budgets – merely adequate – that have failed anyway. And some with a low budget that worked (and a few others that failed). I believe that examples of all categories will come to your minds.

Clearly, the financial matter is not the only obstacle. From what I can see, there’s a serious problem of arrogance in the Brazilian industry. It’s NOT generalized, and there ARE exceptions, but it seems far too common for a team without the least experience in developing games to try to bite more than they can chew. There’s nothing wrong in having a little ambition, but one should be fully aware of the enormous difficulties involved in the game development process. This most common case is of the person who has never developed a game, but has read two blogs and a book (sometimes, not even that) and considers himself a professional game designer. Like every other art form, game design is a skill that needs practice and is refined after many years. This kind of belief (where one considers himself an expert in a topic in which he’s a beginner) is a known psychological effect: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

What do I propose? I believe that the best solution is for teams to think small, and make simple games, at least at first. This is important for a number of reasons:
– To get experience;
– To be able to experiment, without the fear of sinking a big project;
– To have Brazilian games on the market, which is useful not only to inspire the remainder of the community, but also to start the flow of money and show them what we can do;
– Understand that it’s always harder than it looks.

And it truly is harder than it looks. Look at the “top” indie games. Note that all of them have a simple concept, and yet took a very long time to get there. Now imagine how much harder it would have been, were they complex ideas. Braid, for example, can be roughly described as a “puzzle game with simple physics and a basic platform movement, where you can go back in time”. Sounds easy, no? It took three years to be developed, and cost around 180 thousand dollars, paid by Jonathan Blow himself. It’s worth remembering that he had 16 years of programming experience, and wrote for game magazines, among other qualifications. Similar cases are seen in World of Goo, Super Meat Boy, Aquaria, etc. If your idea is to “make an MMO” or “make an FPS” or something even more complicated, stop and think about it. It’s not impossible, of course, but I consider it naïve to pick this path without a team that has obtained a lot of experience in successful games. Especially the Game Designer.

Currently, the situation is a bit sad. There are a few Brazilian games ranging from OK to Good available commercially (e.g. Eversion, Freekscape). I can’t think of any that I consider to be truly excellent. Outlive was mentioned on this thread, and indeed it had much potential, but its execution was underwhelming.

However, the future does not seem so bleak. With each passing day, I see people starting less greedy projects, doing it more for the love for the craft, truly studying – not merely trying to be famous like an “awesome guy from the industry”. iPhone’s rise might have helped, making it more “acceptable” to develop small and fun games. I hope that, through this path, our industry can learn what makes a good game tick (in the same way that Japan and the United States learned decades ago, at the time of the old consoles) and then use that knowledge to make true brazilian masterpieces.

I have some fear about this “cultural” concern in our games. I believe that the best games transcend the culture of the country that originated them, and speak directly to human nature, without the need to appeal to national identification. I’m no fan of Taikodom, but one thing that it did right was to deal with that tactfully – instead of throwing Brazilian culture in your face, there are mere subtle references, e.g. “Santos Dummont Station”. Other games take a less subtle path, and try to create a “culturally rich” experience… which ends being almost ridiculous. Remember that Demon’s Souls is Japanese, Heavy Rain is French, Minecraft is Swedish, The Path is Belgian (and I don’t imply that I like The Path), Darwinia is British, Crysis is German, Eve Online is Icelandic, Limbo is Danish…. and none of those felt the need to have a distinctive element of their countries visible. Why is there this need in Brazil? (Perhaps I am mistaken, but it DOES seem like a recurring theme.)

My advice? Make Flash games. Make iPhone games. Make cell phone games. Join the Global Game Jam (we had lots of fun Brazilian games last year – not bad, considering the mere 48 hours to develop them). Don’t take those things as “inferior work”, a mere obstacle on your path to glory; Face them as opportunities to experiment with gameplay, to learn WHAT is a real game, and later, YEARS later, bring your ambitious dreams into reality. Read books. Join forums. Exchange ideas. Your gameplay ideas are NOT as genius as you think they are: don’t make secrets out of them. If you’re a programmer, implement games and engines. If you’re a game designer, learn to use Game Maker or Construct and get to work.

I wrote my first game in 1997, in Klik & Play (probably the first Game Maker-like tool). Years later, I learned C, and then C++, but ever since that first game, I never stopped playing with implementing games. I’ve released several on different events, but the great majority lies unfinished – they ended up being mere experiments. Today I work on the field, and develop games professionally, for the casual market. Fourteen years developing games were not enough for me to consider myself an expert on the field – and another fourteen won’t be, either. Yet, I want to be able to keep practicing and studying, both because I want to improve, and because I love it. This is the least I expect of myself, and the least I expect of you. Dedicate yourselves and you shall have success. Just don’t expect to achieve it without much sweating.

Good luck and sorry for the long rant!

Original (Português)

Segue minha opinião. Não tenho a presunção de afirmar que é fato, mas me parece ser um quadro realista da situação.

Pode até haver uma falta de incentivo governamental, mas isso, na minha opinião, não serve de desculpa. Nós temos exemplos de jogos que tiveram literalmente milhões de reais gastos neles, e no final ou tiveram um resultado catastrófico ou decepcionante. Há vários outros exemplos de jogos com verbas menos exorbitantes – meramente adequadas – e que ainda assim fracassaram. E alguns com verba baixa ou zero que deram certo (e mais outros que deram errado). Acredito que exemplos de todos os casos surgirão na mente de vocês.

Claramente, a questão financeira não é o único empecilho. Pelo que eu observo, existe um problema sério de arrogância na indústria brasileira. NÃO é generalizado, e EXISTEM exceções, mas me parece ser muito comum que uma equipe sem a mínima experiência em desenvolvimento de jogos tente abocanhar mais do que conseguem. Não existe nada de errado em ter um pouco de ambição, mas deve-se ter plena consciência das enormes dificuldades envolvidas no processo de se desenvolver um jogo. O caso mais comum é o da pessoa que nunca desenvolveu um jogo, mas leu dois blogs e um livro (as vezes, nem isso) e se considera o game designer profissional. Como toda forma de arte, game design é uma habilidade que se pratica e se refina ao longo de muitos anos. Esse tipo de crença (onde a pessoa se considera ótima em um tópico na qual ela é iniciante) é um efeito psicológico bem conhecido: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

O que eu proponho? Acredito que a melhor solução é para as equipes pensarem pequeno, e fazer jogos simples, pelo menos a princípio. Isso é importante por vários motivos:
– Ganhar experiência;
– Poder experimentar, sem medo de errar em um projeto gigantesco;
– Ter jogos Brasileiros no mercado, o que serve não apenas para inspirar o resto da comunidade, como também para começar um fluxo de caixa e mostrar que podemos fazê-lo;
– Entender como é sempre mais difícil do que parece.

E realmente é mais difícil do que parece. Observe os Indie “top”. Note que todos têm um conceito bastante simples, e ainda assim levaram um tempo enorme para chegar lá. Agora imagine o quão mais difícil seria se fossem idéias complexas. Braid, por exemplo, pode ser descrito (grosseiramente) como “um jogo de Puzzle com física simples e movimento básico de plataforma, onde você pode voltar no tempo”. Parece fácil, não? Levou 3 anos para ser desenvolvido, e custou cerca de 180 mil dólares, pagos do bolso do próprio Jonathan Blow. Vale lembrar que ele tinha 16 anos de experiência com programação, e escrevia para revistas de jogos, dentre outras qualificações. Casos similares são vistos em World of Goo, Super Meat Boy, Aquaria, etc. Se a sua idéia é “fazer um MMO” ou “um FPS” ou algo ainda mais complexo, pare e reflita sobre isso. Não é impossível, claro, mas eu acho ingênuo escolher esse caminho sem uma equipe que tenha obtido bastante experiência em vários jogos que já tiveram sucesso. ESPECIALMENTE o Game Designer.

Atualmente a situação é um pouco triste. Existem alguns jogos Brasileiros de qualidade OK a Boa disponíveis comercialmente (e.g. Eversion, Freekscape). Não consigo pensar em nenhum que seja realmente excelente. O Outlive foi citado nesta thread, e realmente é um jogo que tinha muito potencial, mas a execução deixou muito a desejar.

Entretanto, o futuro não parece tão ruim. Cada vez mais, eu vejo pessoas começando projetos menos gananciosos, fazendo aquilo pelo amor à arte, estudando de verdade – não apenas querendo aparecer como um “cara foda da indústria”. A ascensão do iPhone talvez tenha ajudado, tornando-se mais “aceitável” desenvolver jogos pequenos e divertidos. Espero que através desse caminho, nossa indústria possa aprender o que faz um jogo ser bom, (da mesma forma como o Japão e os Estados Unidos aprenderam décadas atrás, na época dos consoles antigos) e depois usar esse conhecimento para fazer verdadeiras obras primas Made in Brazil.

Tenho um certo receio quanto a essa preocupação “cultural” nos nossos jogos. Acredito que os melhores jogos transcendem a cultura do país de onde originaram, e falam diretamente com a natureza humana, sem precisar apelar à identificação nacional. Não sou fan do Taikodom, mas uma coisa que ele fez bem foi usar isso com tato – ao invés de ser uma coisa brasileira jogada na sua cara, há meras referências sutis, e.g. “Estação Santos Dummont”. Outros jogos pegam um caminho menos sutil, e tentam criar uma experiência “culturalmente rica”… que acaba sendo quase ridículo. Lembre-se que Demon’s Souls é Japonês, Heavy Rain é Francês, Minecraft é Sueco, The Path é Belga (e não implico que eu goste de The Path), Darwinia é Britânico, Crysis é Alemão, Eve Online é Islandês, Limbo é Dinamarquês… e nenhum desses sentiu a necessidade de ter um elemento distintivo de seu país evidente. Por que então há essa necessidade aqui no Brasil? (Talvez eu esteja enganado, mas me parece um tema recorrente.)

Meu conselho? Faça jogos em Flash. Faça jogos para o iPhone. Faça jogos para celular. Participe do Global Game Jam (tivemos vários jogos Brasileiros bastante divertidos ano passado – nada mal, considerando-se as meras 48 horas para desenvolvê-los). Não encare essas coisas como “trabalho inferior”, um mero obstáculo no caminho da sua glória; Encare essas coisas como oportunidades de experimentar com gameplay, de aprender O QUE é um jogo de verdade, e depois, ANOS depois, bote seus sonhos ambiciosos na prática. Leia livros. Participe
de fóruns. Troque idéias. Suas idéias de gameplay NÃO são tão geniais quanto você acha que elas são: não guarde-as como segredo. Se você é programador, implemente jogos e engines. Se você é game designer, aprenda a usar Game Maker ou Construct e bote a mão na massa.

Eu implementei meu primeiro jogo em 1997, no Klik & Play (provavelmente o primeiro programa estilo Game Maker). Anos depois, aprendi C e depois C++, mas desde aquele primeiro, eu nunca parei de brincar de implementar jogos. Lancei vários em diversos eventos, mas a maioria esmagadora nunca foi terminada – acabaram sendo apenas experimentos. Hoje trabalho com isso, e desenvolvo jogos profissionalmente, para um público casual. 14 anos desenvolvendo jogos não foram o suficiente para que eu me considere um expert na área – e mais 14 não serão. Ainda assim quero poder continuar estudando e praticando, tanto para continuar a me aperfeiçoar, mas também porque eu amo fazê-lo. Esse é o mínimo que eu espero de mim mesmo, e é o mínimo que espero de vocês. Dediquem-se e vocês terão sucesso. Só não esperem alcançar o sucesso sem muito suor.

Boa sorte e desculpem o rant prolongado!

SPJam 2011 – Down Goes the Phoenix

Last weekend, I was in São Paulo with my friends at Studio Miniboss to join the first edition of SPJam. The event was lots of fun and a success, with almost a hundred entrants and over 20 digital or board games. Our entry, made in the 48 hours of the event, is “Down Goes the Phoenix”:

It’s a horizontal scrolling shoot ’em up on which you play with a Phoenix. As the game progresses, your phoenix grows older as the bar on the bottom fills. Shooting or getting hit lowers the bar. When the bar is full, you’re a mature phoenix and you can reincarnate – doing so resets your power-ups, but increases your score multiplier and kills all enemies, as well as removing the fog that slowly descends upon the screen, obstructing your view. As an arcade game, the objective is to obtain a high score, and knowing the right time to reincarnate is a critical point.

The game is written in C++11 in my own engine. I was the programmer and Amora, Santo, bitmOO and Marina Val were the visual artists. The music was composed by Rafa Miranda, and we had some game design help in the first day from Iko. Thanks to everyone involved!

The SPJam version of the game can be downloaded here: http://higherorderfun.com/stuff/DownGoesThePhoenix.zip (Win32 binary). This is the exact version made in those 48 hours, save for minor bug fixes.

Best of Game Development Videos and Presentations

Here’s a list of my favourite videos and presentations on several subjects related to game development. I strongly recommend every single video listed below, at least those that match your area of expertise.

If you can think of any good videos that I missed, please leave a link on the comments. I will update the post with any videos that I enjoy.

Game Design

Programming & Technical


(Most of the following are highly technical and specific, but I recommend the first presentation, “Why C++?”, to every programmer.)

Religion in MMOs: Proposal of an Experiment

Here’s an experiment idea:

It’s common in RPGs to have some sort of religion system, generally with a multitude of deities which are more-or-less at peace with one another, and whose followers typically do not try to murder each other at the first opportunity. Sometimes, you can offer donations to churches to get some bonuses, to karma or luck or whichever is applicable. Knowing the right time to pray is even a key gameplay element in Nethack.

This sort of behavior is, of course, also observed in the real world – people will often pray and make donations seeking to get something in exchange. The difference is that, in the game world, they actually get something out of it. But they don’t have to.

Consider an MMORPG with a religion system (whether it’s monotheistic or polytheistic is not important), and a series of temples spread around the world. Players can visit those temples, and consult a list of services that the temple can perform, along with their costs. Perhaps a player can get a 5% extra to-hit bonus for a donation of 100 gold. For 500 gold, he will get a +5% bonus chance to find rare items… Or so the temple claims. The player spends his hard-earned coin, and the game says something along the lines of “you feel lucky”. And nothing changes.

How many people would believe that? Would anyone conduct a systematic, scientific in-game research to evaluate how much of a difference said donations would provide? Even if some “skeptic” told other players that it’s a hoax, would they believe it? Perhaps they’ve donated once, and found a very rare item afterwards. Their minds would be making connections. What if this “truth” is spread in forums, FAQs and wikis… perhaps in the game manual itself? After months investing money in those things, wouldn’t the player feel even more compelled to believe that he wasn’t being cheated all along?

The idea could be developed further and let players take on the role of priests, although a mechanic would have to be designed to allow them to mess with the system without easily exposing its truth. For example, perhaps there’s a holy book defining how those bonuses work, in a cryptic (and possibly self-contradicting way) and leave it to the priests to interpret it and write the list of services. Temples that offered so much that it was visible that it didn’t work would lost trust, and temples that offered too little wouldn’t be able to compete. Some form of selection would eventually choose the best religion.

To my knowledge, no game has ever implemented such a system (if you know of one, please mention it on the comments). If it works as intended, analysis of player’s reactions to the system (and to the discovery that it was all their imaginations, if the developers ever decided to Word of God (pun unintended) it) could be very enlightening. Would that change how they perceive religion in the real world? Would such a study have any impact on understanding the psychology of belief? Perhaps not. But, if nothing else, it would be an interesting topic to bring up in a religion discussion.

Multi-thread OpenGL texture loading

Those who have used OpenGL are probably aware that you can only invoke OpenGL procedures for a given context on the thread that currently owns it – usually, the main thread. This leads many programmers to assume that OpenGL is strictly single-threaded, and that no loading can be done on the background, inside some loader thread. This is not the actual case, and it’s actually fairly simple to work around this.

The key to multi-threaded OpenGL is in creating multiple contexts that share data between them. On Windows, it is done with the wglShareLists() procedure. On X and Apple APIs, it can be done during context creation (glXCreateContext() and aglCreateContext(), respectively). It boils down to creating a second context for the loader thread, and setting it to share data with the main context. This way, all data loaded on the second context will be available on the main one – you can just create a texture normally on the loader thread, and then glBindTexture() it on the main thread, for example.

On Windows/C++0x, the code looks like this:

void startLoader(HWND hwnd)
	// Assuming that this is the main thread
	HDC hdc = GetDC(hwnd);
	HGLRC mainContext = wglGetCurrentContext();
	HGLRC loaderContext = wglCreateContext(hdc);
	wglShareLists(loaderContext, mainContext); // Order matters

	boost::thread([=] () {
		wglMakeCurrent(hdc, loaderContext);
		runLoader();	// Your method for loading textures
		wglMakeCurrent(nullptr, nullptr);

Most APIs (such as Allegro, SDL, wxWidgets, etc) will provide you with a simple method of retrieving the window handle, which is all that you require to call the above procedure.

Note that you could create the context and share the lists inside the loader thread, but wglShareLists() must be called BEFORE anything is done on the main context, so the safest way is to do it on the main thread (otherwise, the new thread could take a while to run and be too late to do it).

IMPORTANT! I have observed that, on some cases (Windows 7 64, NVIDIA 320M), attempting to use a texture after it has been created (via glGenTextures()) but before its data finished uploaded (in this case, via glTexSubImage2D()) resulted in the texture being corrupted, and remaining corrupted even after it was uploaded. This will happen even if you wait for glTexSubImage2D() to return before using it on the main thread, since OpenGL is asynchronous. To avoid this problem, make sure that you glFinish() the loader thread before you attempt to use any textures initialized there.

Programming is Art

Programming is a subject most often lumped in with engineering or science, and there are countless books dedicated to writing better code, but is this a good approach? To me, it seems much more reasonable to understand it as a form of art.

Does it matter? Yes, I think it does. I believe that this distinction is important, and I believe that many other programmers agree with it. I also think that it affects how we view and hire programmers, and, ultimately, it greatly influences the productivity of software development in many companies.

Read the full article »