• Create Account

90´s Platformer Collisions

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

#1TookieToon  Members

351
Like
0Likes
Like

Posted 26 March 2014 - 12:33 PM

Hello!

I want to create a 2D platformer game. My intention is resemble the classic 1990´s games, like Prince of Persia and Another World.

The game should handle several floor "levels", falls, floors with inclinations, and maybe deformable floors too.

The character should be able to walk, jump, go up a floor level, go down.

I want to do all the programming in C++, I don´t want to use an engine like Box2D.

My plan is to use data structures storing the floor geometry as line segments. Something like this:

struct Segment
{
vec2 pointA, pointB;
};

// All line segments in a floor level
typedef std::vector<Segment> t_floorLevel;

// All geometry of the game map
typedef std::vector<t_floorLevel> t_terrainGeom;



So the question is...How can I handle the collisions?

Should SAT be overkill for this?

Should I represent the characters as circles, and check if they hit a line segment?

Thanks, Paul.

#2Javier Meseguer de Paz  Members

375
Like
1Likes
Like

Posted 26 March 2014 - 01:48 PM

I would start by using an acceleration structure. In the case of the floor, you can have the map divided into vertical slices (like a typical regular grid, but 1D instead of 2D). Apart from that, it all depends on what accuracy you want. A simple bounding circle-segment test could do, as you mention. Or an axis-aligned square - segment test. Or you can go and implement a full-fledged polygon-line test...

In case you go the polygon-segment test approach, you may test it easily by intersecting the segment with the polygon's segments... (maybe checking if the entire segment is inside the polygon in case you think that's possible).

“We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” -  Donald E. Knuth, Structured Programming with go to Statements

"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Ken Beck, Twitter

#3LorenzoGatti  Members

4080
Like
1Likes
Like

Posted 27 March 2014 - 02:40 AM

I suggest starting from the rules, and optimizing geometric acceleration structures later.

You can implement a generic query (e.g. what platform segments, at what time, and from which side intersect this object if it moves between these two positions) in a simple, inefficient and obviously correct way, use it as the foundation of a complete collision detection system that does what you want (e.g. one-sided barriers, sliding on slippery surfaces, etc.), and when you have refined your requirements try optimized, more complex and less general algorithms.

Omae Wa Mou Shindeiru

#4LorenzoGatti  Members

4080
Like
1Likes
Like

Posted 27 March 2014 - 05:41 AM

Regarding the specific questions:

Should SAT be overkill for this?

It might or might not be a good choice of clever algorithm for "phase 2".

Should I represent the characters as circles, and check if they hit a line segment?

A convex polygon or (if the character isn't convex) a simple polygon is going to be much more suitable for a character than an ellipse; rounded corners can cause the character to stand in a wrong position, something quite unacceptable in a platformer. Ellipses are popular collision shapes for bullets, which are actually round and tolerate some approximation because they explode on contact.

Omae Wa Mou Shindeiru

#5Javier Meseguer de Paz  Members

375
Like
0Likes
Like

Posted 27 March 2014 - 02:13 PM

I suggest starting from the rules, and optimizing geometric acceleration structures later.

Just to clarify, when I said "I would start by" I meant "the algorithm for collision detection should start by". When it comes to the development timeline, I totally agree with LorenzoGatti's suggestion of having something that works first an optimizing later...

Edited by Javier Meseguer de Paz, 27 March 2014 - 03:03 PM.

“We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” -  Donald E. Knuth, Structured Programming with go to Statements

"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Ken Beck, Twitter

#6TookieToon  Members

351
Like
0Likes
Like

Posted 27 March 2014 - 02:36 PM