@xoorath aw yeh!
@barnaby Cheers! The world is split into a grid, each cell has a 32-bit coordinate, so at a walking rate of 8 blocks a second, it will take about 17 years to get from one side of the world to the other.
As for the collisions, the method I'm using has not really been tested on large numbers of entities, but seems to work ok.
Each object in the world gets an integer width w
and height h
(e.g., 1x3 for moonman), and a collision width and height (.9x2.8 for moonman). the collision width and height are less than the actual width and height so moonman can fall in unit width holes, fit nicely into a cave of height 3, etc.
Sensors are placed on an entity at the junctions of their geometry, so moonman has 8 sensors, 4 on each side. Which sensors are used depends on the direction the entity is going. So when falling straight down only the two bottom sensors are user.
In an update step, the entity's position is updated, and each appropriate sensor is traced through the world using this algorithm
. The tracing splits the sensor up into segments, each of which are tested against the cells in turn for collision. If the cells contain a full block or an empty block then the check is trivial. If the cell contains a slope then a little more code magic is required.
That's the general idea, but its a little more complicated. For instance, if the sensors are just points, then some funny stuff can happen, like getting caught on the side of a cliff as you fall. So instead, I include the two adjacent edges to the sensor when checking the collision.
A few random notes:
- When landing on a slope the bottom-side sensors are ignored, and a bottom-center sensor is used instead.
- Entities have an onGround flag, and the physics and collisions are done differently based on this.
- The raycasting can be simplified if you cap the velocity of entities to one tile per frame - but i haven't done this.
Some more refs:http://info.sonicretro.org/Sonic_Physics_Guidehttp://www.gamedev.net/topic/509143-how-to-go-about-platformer-physics/