# New tile based platform engine – theory behind the player

This post will explain the theory behind the player of my tile based plaftorm engine, and answer to some questions readers made commenting steps 1 to 4

First, you must know how Flash converts coordinates to pixels.

The player in this platform is a rectangle whose width is 12 pixels and height is 18 pixels.

Its origin is set to `(0, 0)` so you should expect to have 6 pixels to the left, 6 to the right, 9 to the top and 9 to the bottom.

This is the theory that will make you fail your collision engine.

In this picture

You can see the red/white cross at in the center of the green rectangle (the player) representing the `(0, 0)` origin of the object, but if you look at the red pixel (yes, it’s a pixel because the image is magnified) at real `(0, 0)` position, you will see it’s not centered in the origin point as you could expect but it’s moved one pixel to the right and one pixel to the bottom.

This happens because every pixel has a size, and its size is… one pixel.

So the red pixel starts at `(0, 0)` but its size makes him end at `(1, 1)`.

For this reason, the right bottom yellow pixel it’s not at `(6, 9)` as someone can imagine, but at `(5, 8)` while the left bottom one is a `(-6, 8)`.

Fail to determine the real player edges and you will mess up the collision engine.

The couple of red pixels at the bottom of the rectangle, located at `(-6, 9)` and `(5, 9)` is not part of the player sprite, it’s just a couple of pixels representing the feet of the player. The left and the right one.

Checking both feet can make me know what kind of tile the player has under its feet.

Obviously a player can have one foot on a tile and one foot on another tile.

That’s why I had to decide the main foot. If your player has one foot on a normal tile and one foot on a ice tile, do I have to apply ground or ice friction?

I decided to make the left foot as the main one. This means if the left foot is not in the air, that’s the foot that will inherit ground friction. If the left foot is in the air, then the main foot will be the right one.

This routine can (and will) be optimized in two ways: the first way checking if both feet are on the ground and looking for the tile in the middle of them.

The second way id determining if the player is facing left or right then assigning the right or left feet as the main one.

The other pixels (the yellow ones) are used to check collisions between the player and the environment… but I will talk about it later.

Now I would like to answer a couple of questions:

Wouldnâ€™t a matrix be better than an array of arrays? It would be all one variable, and it would make a level editor easier to design, in my opinion.

Sure, but it would make harder to design level “on the fly” directly from the source code. Obviously the final version will have a matrix and an editor.

There is an inconsistency in that if the player gets on the conveyor belt throws you off. A related inconsistency is that the -> conveyor belt doesnâ€™t affect you until you are on all the way but the <- conveyor belt starts as soon as you touch it

This is due because of the primary feet issue I described before.

That’s all at the moment… next step… clouds… then more theory.

215 GAME PROTOTYPES EXPLAINED WITH SOURCE CODE
// 1+2=3
// 10000000
// 2 Cars
// 2048
// Avoider
// Ballz
// Block it
// Blockage
// Bloons
// Boids
// Bombuzal
// Breakout
// Bricks
// Columns
// CubesOut
// Dots
// DROP'd
// Dudeski
// Eskiv
// Filler
// Fling
// Globe
// HookPod
// Hundreds
// InkTd
// Iromeku
// Lumines
// Magick
// MagOrMin
// Maze
// Memdot
// Nano War
// Nodes
// o:anquan
// Ononmin
// Pacco
// Phyballs
// Platform
// Poker
// Pool
// Poux
// Pudi
// qomp
// Racing
// Renju
// SameGame
// Security
// Sling
// Slingy
// Sokoban
// Splitter
// Sproing
// Stack
// Stairs
// Stringy
// Sudoku
// Tetris
// Threes
// Toony
// Turn
// TwinSpin
// vvvvvv
// Wordle
// Worms
// Yanga
// Zhed
// zNumbers