# data[].attributes.body
PRE-ALPHA

# data[].attributes.attachment_link.readable_text
A platformer is a game in which a character runs and jumps around a level consisting of platforms floating in the air. Although this article focuses on platformers, the philosophy behind each idea can be applied to any type of game, whether 2D or 3D. This list does not only include tips for the product (a fun game), but also for the development process.

1. Keep the user interface simple

The player presses the jump button to jump. That is a simple user interface. The challenge for the player is pressing the jump button at the right time to complete the game. In other words, the challenge is not using the interface, but using it at the right time.

The more transparent and intuitive the interface is, the better. If drivers on the road had to concentrate on how to turn their vehicles, there would be many more accidents.

The simple interface also applies to the menus and all other interactive sections of a game. It must be easy to navigate between menu items and to select items.

2. Make important information easy to see

Make it easy for the player to see important things in the game. Platforms that the character can walk on must stand out from scenery in the background. Collectable items must be easy to recognise. One glance at the HUD should give you all the information you need. An easily readable font is a necessity. The player must know what is going on in the menu.

3. Mind your collision boundaries

The collision boundary of a friendly object is bigger than the object. The collision boundary of a harmful object is smaller than the object. Friendly objects include power-ups, switches, ladders, and swinging ropes. Harmful objects include enemies, enemy bullets, spikes and rotating blades. The bigger collision makes it easier to interact with, or collect the friendly object. The smaller collision makes it easier to avoid the harmful object.

(The collision boundary can also be referred to as collision rectangle, collision bounding box, collision sphere, collision region, collision polygons, etc. The player collides with an object if the player's collision boundary overlaps the object's collision boundary.)

4. Make it easy to jump over gaps

The player can jump when he is in the green area. The larger green area on the right makes it easier to jump across platforms (that's a good thing).

Traditionally in games - and realistically - a player can only start jumping if he is standing on something. Allow the player to start jumping when he is in mid-air, when he just stepped off the edge of a platform. Have a leeway of about one second in which the player can start jumping. (After the one second he can no longer jump, and continues to fall downwards.) This makes it easier to jump from one platform to another.

5. Make it possible to change animation states anytime, anywhere

The character's animations should follow the player's movement, not the other way around. In other words, the player's movements should not be limited by the animations. Ideally, any animation should be able to start from any other animation, at any time. The player wants to run, jump, grab onto a ladder in mid-air, climb up, shoot his gun, and jump off the ladder. The animations should allow him to do that.

Also, the player should never have to wait for his character's animation to end before he is able to move again. Do not disable input while an animation is playing, causing the player to wait for the animation to end before he can move again.

6. Provide plenty of power-ups and collectables

Most kids collect stuff, purely because it is fun. That same feeling of joy happens when you collect things in a computer game. Put collectable stuff in the game. The more, the better.

There is no logical reason for it. It is just fun.

7. Write generic, but versatile AI

Design and code a small number of base AI agents, each containing a small number of variables. The variables are given different values to create a large variety of AI agents.

Examples of base AI

Walking AI
Walks on horizontal surfaces.

Variables

Health Speed Jump height Attack style

1 = Easy

3 = Medium

5 = Difficult

0 = Static (remains in one spot, e.g. Venus's flytrap)

1 = Slow

2 = Medium

3 = Fast

5 = Super fast

10 = Slow, but fast when the player is nearby

0 = Cannot jump

1 = Low

2 = Medium

3 = High

10 = High when the player is directly above

0 = None, just wander around

1 = Near range melee

2 = Medium range melee

3 = Shoot projectiles

Examples: Knight, Archer, Fire Elemental, Giant Venus's flytrap, Elf.

Flying AI
Flies around in the air.

Variables

Health Speed Fly diagonal Attack style

1 = Easy

3 = Medium

5 = Difficult

1 = Slow

2 = Medium

3 = Fast

5 = Super fast

10 = Slow, but fast when the player is nearby

0 = Cannot fly diagonally

1 = Can fly diagonally

0 = None, just wander around

1 = Near range melee

2 = Medium range melee

3 = Shoot projectiles

Examples: Hawk, Gryphon, Ghost, Air Elemental, Dwarf in gyrocopter.

Crawling AI
Walks on any surface: horizontal, vertical, diagonal and upside down.

Variables

Health Speed Drop down Attack style

1 = Easy

3 = Medium

5 = Difficult

1 = Slow

2 = Medium

3 = Fast

5 = Super fast

10 = Slow, but fast when the player is nearby

0 = Cannot drop from the ceiling

1 = Drop from the ceiling randomly

2 = Drop from the ceiling when the player is beneath

0 = None, just wander around

1 = Near range melee

2 = Medium range melee

3 = Shoot projectiles

Examples: Giant Spider, Worm, Killer Snail, Slime Elemental.

8. Have a story and atmosphere in mind

Define the game's story early on in development. The story is a guideline for the game's overall atmosphere, art style, and goals. The story can be complex or a single line of text. You can reveal the story to the player in cut scenes and dialogue, or you do not need to show it to the player at all. As long as everyone working on the game knows what the game's story is.

Example story: A lone marine fights hordes of zombies and demons on a moon base.

From this story we know what the game is about.

lone - single player, solitary character

marine - fighter, army, military, tough-as-nails, guns, shoot stuff

fights - action, fighting

hordes - many enemies, relentless

zombies - gore, gun fodder

demons - supernatural, dark

moon base - sci-fi, futuristic, remote

9. Define scope and time clearly

Make a list of everything that needs to be done to complete the game. Then estimate how long it will take to implement each item in the list. The amount of time you end up with is the minimum time it will take you to complete the game.

To put it into perspective: If your design document is 50 pages long, and it takes an average of 2 days to implement the features per page, then it will take you at least 100 days to make the game. It is natural to have an initial design doc which does not include everything that will eventually be in the game. More pages will be added to it during development.

To put it into perspective again: If it takes an artist 2 weeks to create and animate a character, then it will take 20 weeks to create 10 characters. That is 5 months - almost half a year. If you have two artists, then it will take half the time to complete the characters. But it still takes 20 weeks of actual work. In other words, you still pay for 20 weeks of work.

It is very easy to think of new features to add to a game throughout the development process. However, every time you add a new feature, you push the release date further away. Continue to add features on a regular basis and your game will never be complete. When you add a new feature, be prepared to take another one away to meet your deadline. Make sure that you prioritise your initial list of features, so that the least important ones can be dropped if (or when) you run out of time.

Do not be ashamed to make a game which has a very limited number of features. The people laughing at you are probably working on an MMO that will take them 15 years to complete.

Remember, one of the most rewarding feelings in the world is to complete a project.

10. Prototype before finalising theoretical fun

There are thousands of good ideas for computer games, but not all of them are fun. The best way to find out which are fun, is to prototype the game. The prototype is a quick-to-make and quick-to-change version of the game that helps you to test out your ideas.

Why prototype? It saves you time in the long run. Have you ever had to recreate art or reprogram a system because the design changed as a result of the game not being fun?

To save time, use an existing game engine and download free resources from the internet to create the prototype. The prototype may be done in the same engine used for the final game, and some of the code can be reused.

The prototype may also be a completely separate program (or programs) that will be discarded when the final game is in full development. For this reason, there are people who do not like prototyping. They believe it is a waste of resources and time, because the final prototype 'product' is discarded. Think of the prototyping as another idea phase of development. During this phase you test out your ideas, change them, replace them, and tweak them, until they are fun. The prototype 'product' is, therefore, a tool used for testing ideas.

Remember: Prototyping must also be included in your list of things to do, and, therefore, must be part of your schedule.

11. Involve everyone in the team in the design

Would it be better for an artist to work on a character if he or she was involved with designing the character? Or better yet, if he or she came up with the idea for the character? Would it be better for a programmer to code a system if he or she was involved with designing it?

The answer is yes. It will also be better for the game.

A game is a creative collaboration. If only one or two people design the game, then it will be creatively limited. People generally feel happier and more devoted to a project if they are included in the design process. Therefore, encourage everyone to be involved in the design process. And it does not always need to be a formal process. In other words, you do not always need to schedule a meeting where everyone is involved. People can send emails, talk in the kitchen, or shout across the room.
Further Reading

# data[].attributes.attachment_link.description
This article gives handy tips for designing and building a platformer. There are tips for designing the interface, handling jumping and collision boundaries of goodies and baddies, implementing AI,...

# data[].attributes.attachment_link.readable_text
In a previous article, I gave you 11 Tips for making a fun platformer. That article had general tips that covered a wide range of game design tasks. This article looks specifically at the process of designing levels for a platformer. The process is a guideline and covers the steps from the initial idea to the final playable level.

The article does not focus on scheduling. However, you do need to keep scheduling in mind when designing levels. The size of a level and the amount of resources it contains depend on the number of people working on it, and the time available to complete it.

1. Choose a visual theme

Choose a visual theme for the level. You can go with a predetermined, game-wide theme, such as 'Forest', 'Ice', 'Lava', or 'Castle'. Or go for something more creative, such as 'Steampunk Cloning Facility', 'Psychologist's Nightmare', or 'Cupid's Ice cream Parlour'. Ask everyone in the team for theme ideas.

2. Make a list

Make a list of everything you want the player to experience in the level. This includes what the player does, sees, learns, hears, and encounters. The list should include specific items and general items.

Specific items usually occur once in a level.

General items occur more than once in a level.

Throughout the article the term 'item' is used to refer to the items of a list. These items not only include game items (power-ups, keys, and doors), but also events (finding the first locked door), enemies, and game mechanics (double-jumping).

Write down how many times each general item occurs (for example, there could be 50 coins to collect in the level, or the player might need to defeat 10 swordsmen). These numbers are estimates, and they help you to determine the level's difficulty. For example, there could be two Tough Trolls in level 1, but four Tough Trolls in level 2. Let everyone in the team contribute to the list.

The following examples are also used in the images later in this article:

Specific items:

1. Meet first enemy.

2. Find first power-up.

3. Learn about double-jumping.

4. Learn about destructible environments.

5. Find first locked door.

6. Find first key to open the locked door.

7. Pull lever to activate the moving platform.

General items:

1. Foot soldier enemies (x30)

2. Gun turret enemies (x10)

3. Power-ups (x30)

4. Moving platforms (x3)

5. Locked doors (x2)

6. Keys (x2)

3. Make a rough layout

Draw a very rough layout of the entire level. This layout should show the path that the player will take through the level. Think of it as designing the street layout of a city, but ignoring the buildings.

You may end up doing several layouts before you have one that you're happy with. Usually, the reason for changing the layout is one or more of these:

Some areas are too big or small.

Some lines are too straight and too long (i.e. boring).

The overall layout is too simple or too complex.

The overall layout looks uninteresting.

An example of the rough layout of an entire level.
4. Make rough sketches for the specific items

Players will need to find each item in the list that you created in step 2 somewhere in the level. They might also find some items in the same area. Make rough sketches of each area in which the player will find the specific items in the list.

Use symbols to identify the various objects in the level, for example, E for 'Enemy', P for `Power-up', and K for 'Key'. Also make notes on the sketches.

Distinguish clearly between negative and positive space when you do the sketches. The negative spaces (white in the sketches) are the areas where the player can move, and the positive spaces (diagonal lines in the sketches) are things like floors, walls and platforms where the player cannot move.

These sketches help you focus on the layout of each small area, without having to worry about where they fit in the overall layout of the level. Think of it as focusing on designing a building and ignoring its location in the city.

You may make sketches for some or all of the general items, but it is not necessary. The general items are usually moved around when you design the detailed layout or play test the level, so they may end up in completely different areas than you originally planned.
Examples of rough sketches

Specific item 1: Meet first enemy. Specific item 2: Find first power-up.

Specific item 3: Learn about double-jumping. Specific item 4: Learn about destructible environments.

Specific item 5: Find first locked door. Specific item 6: Find first key to open the locked door.

Specific item 7: Pull lever to activate the moving platform.
5. Make a detailed layout

Draw a detailed layout of the level. The detailed layout uses the rough layout (from step 3) as a guideline. It includes all the specific items (copying the rough sketches from the previous step) and the general items. When you copy the rough sketches of the specific items, you may need to change them slightly (for example, change the size, flip it horizontally).

Place as many of the general items in the detailed layout as you can. You can add the remaining general items when you build the level using a level editor.

When you place the items, keep in mind the path that the player will take through the level. Certain items may need to be placed in a specific order, such as a weapon being placed somewhere before the player encounters the first enemy.
An example of a detailed layout. The locations of the specific items on the detailed layout.
6. Build the initial layout

Use a level editor to build the level's initial layout, using the detailed layout (from the previous step) as a blueprint. You may need to change the sizes of some areas when you build the level. This happens because the layout sketch is usually not drawn exactly to scale. Also use the editor to add all the outstanding general items to the level. For example, your list might contain 20 enemies, but the detailed layout has only 15 enemies. Add the remaining 5 at this stage.

First build the initial layout before you add the visual details. In other words, use limited graphics for the initial layout, to make it easy to change things if you need to. For example, if you have five grass images, use only one for the initial layout. You can add the other four in step 8 when you decorate the level.

At this point the final graphics for the level may be incomplete, in which case you can use placeholder graphics. It is a good idea if the placeholder graphics have similar colours to those of the final graphics, because the colours affect the feel of the level.

7. Play the level

The initial layout is for playing the level, so that you can determine if it is fun and how long it will take to play through the level. Play the level and change the layout until is it fun and balanced. Let other people play it as well.

Changing the layout may include the following:

1. Move, add. or delete platforms to make jumps easier or more challenging.

2. Move, add, or delete power-ups to balance the amount available.

3. Move, add, or delete enemies to make the level easier or more challenging.

Important note: By the time you design and build your first level, you should already have prototyped and finalized the gameplay mechanics using temporary test levels. If your gameplay has not been finalised by this time, then you risk having to change your levels when the gameplay changes. For example, if you decide to make the player jump higher, then you will have to move many platforms to accommodate the new jump height. Changing fundamental gameplay usually has a ripple effect.

8. Decorate the level

Once you're happy with the level's layout and once it's fun to play, then add the details. This includes adding all the final graphics and audio. Play the level again to make sure that it still feels the same - or better - after all the graphics have been added. There's a good chance that the level will feel different. It should feel better with the final graphics, but sometimes it may feel worse. For example, the placeholder background might have been a single colour, but the final background might be a detailed image that makes it difficult to see the enemies, in which case you will have to tone down the background or change the enemies, whichever will be quicker.

Further Reading

Super Mario Brothers 3 - Level Design Lessons (Radek Koncewicz)

Level Design Lessons (Anna Anthropy)

# data[].attributes.attachment_link.description
In a previous article, I gave you 11 Tips for making a fun platformer . That article had general tips that covered a wide range of game design tasks. This article looks specifically at the process of designing levels for a platformer.

# data[].attributes.attachment_link.readable_text
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.

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.

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.

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.

Slopes
Mega Man X, with slope tile annotations Detailed View of the {4, 7} tile
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}.

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.

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

One-way platforms

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.

Ladders

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.

Stairs

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

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

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.

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.

Slopes

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.
Braid (level editor), with visible layers (top) and the collision polygons (bottom)
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.

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.

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

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;

Jump control

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

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.

# data[].attributes.attachment_link.title
The guide to implementing 2D platformers

# data[].attributes.attachment_link.description
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.

# data[].attributes.body
Acá pueden encontrar los niveles y la historia de la que parte el juego.

# data[].attributes.body
Inspiracion grafica boss 2

# data[].attributes.body
Inspiracion grafica Level 4

# data[].attributes.attachment_link.title
Astaroth - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.description
Astaroth en la actualidad existe en 7 energías directas,divididas según su jerarquía.Solo una es lider de las otras 6.Se le denomina también como el Rey de las 7 coronas del ser humano,de la naturaleza,de los espiritus en su última reencarnación,del sentir de los espiritus,de los 7 caminos espirituales del alma al cuerpo,del descanso o elevación total de las reencarnaciones del ser humano,la última numerología y la voz de las voces del amor y del las almas.

# data[].attributes.attachment_link.title
Paimon - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.description
Si solo se invoca a Paimon, se debe hacer alguna ofrenda o sacrificio y él lo aceptará; entonces, dos reyes llamados Beball (Bebal o Labal) y Abalam (Abalim) irán con él junto a otros espíritus, a menudo veinticinco legiones; pero estos otros espíritus no siempre vendrán a menos que el conjurador use la llamada sobre ellos.

# data[].attributes.attachment_link.description
While his Semitic predecessor was depicted as a man or a bull, the demon Baal was in grimoire tradition said to appear in the forms of a man, cat, toad, or combinations thereof. An illustration in Collin de Plancy's 1818 book Dictionnaire Infernal placed the heads of the three creatures onto a set of spider legs.

# data[].attributes.body
Todo lo que está es conceptualizacion narrativa y teorica, de ninguna manera influencia nuestra representacion gráfica del juego. Lo que si hacemos en "Concepto Imagen".