• entries
743
1924
• views
581599

# Rethink

150 views

I've come to the conclusion that the entire physics and collision system needs a rethink for Udo than worked for Orc.

My previous method has been to maintain everything as a list of game objects that derive from a common base, then high up in the hierachy add some general code for collision detection that all game objects inherit.

While it is nice and simple and means that leaf classes require very little of their own code, it does not seem to be sufficient for a platformer. Everything needs to be handled differently.

Enemies should only collide with the map and the player, for example. I also want to have the ability to have objects or map blocks behave like those Mario-style ones that you can walk in front of and jump onto so you only collide when you land on them. I can't see any feasible way to implement this with the current system.

So a bit of a back to the drawing board when I get home tonight. I still think a class hierachy and a factory unit that generates instances from the level file is a nice solution, since the engine only gets to see the base CItem and is insulated from the details of actual specific types of item, but I think a lot of the physics needs to move down the hierachy (or do I mean up? Towards the leaves) a bit so that different items can handle their collisions differently.

I still don't think it is feasible to move everything, then handle collisions as a second step. My problem with that is that say I move items A, B and C, then find A collides with B. If I align A and B along their edges, what happens if I then discover that both A and B then collide with C?

The current system of move along the X, test collisions and pick a final X co-ord, then do the same for the Y, for each item before moving on to the next one is the only way I've ever found of getting rock solid collision detection to work properly in a 2D game. Guess it wouldn't hurt to have a google for some other approaches.

I'm wondering if for the blocks you can jump in front of but land on top of, I could test to see if the players feet intersect with a narrow band at the top of the block and if so, and the player has a positive Y velocity, anchor them on top of the block. Problem is that if the band is too narrow, the player could fall through it when falling very fast, but if it is too wide, the player could incorrectly end up landing on the block when just moving in front of it.

Perhaps I'll need to check collisions along a sequence of steps between the old position and the new one, but since checking collisions involves doing co-ord based map collisions AND running through every other object on the map, this would not be very efficient.

Then again, I don't need accurate collisions for enemies, since they are just killed or kill you on touch. Perhaps I need to have a seperate list of items that actually need to be block-collided, like moving platforms and static blocks, and objects that I can examine the collisions in one go after all the movements are completed, like enemies, pickups and so on. Trouble there is that even non-accuracy-critical collisions like enemies still require some information about the previous move since we need to know whether the player landed on them or not. Maybe storing each objects previous position would be a solution to this.

As you can probably tell, I'm thinking myself in circles at the moment. I'd really love to have a sit down for a couple of hours with someone who wrote like original Super Mario or something and pick their brains. I just can't seem to find much on the internet beyond the very basics of creating platformers.

How difficult can it be? And don't even talk to me about moving platforms. Nightmare.

Still push on. If anyone does have any good links for 2D platform physics, please feel free to post.

<caveat>Don't you wish that you could view the entry you're replying to when you post a reply to a journal entry? So, forgive me if this is entirely redundant / missing the point / exactly what you said

So, I'm not sure which way is "up" in your hierarchy [wink] Let's say that "up" is towards the base classes and "down" is towards the derived class. It's better to have the collisions detection able to work with object higher up the tree. In Unreal, the base class is Object and Actor derives from it, and Actors can collide with the environment. However, how to fit that into a collision detection scheme can be tricky. Have you considered separating the collision detection from the object? Sorry, that's not clear at all so I'll suggest an example.

Example #1: You could use an interface...

class CollidableGameObject
{
virtual bool IsIntersecting( CollidableGameObject* Other ) = 0;
};

class SuperHero : public CollidableGameObject
{
bool IsIntersecting( CollidableGameObject* Other )
{
// Perform collision detection black magic
}
};



Example #2: Or, have a distinct member that deals with the collision

class CollidableShape
{
virtual bool IsIntersecting( CollidableShape* Other ) = 0;
};

class CollidableGameObject
{
CollidableShape* m_collidableShape;
};

class SuperHero : public CollidableGameObject
{
bool IsIntersecting( CollidableGameObject* Other )
{
return m_collidableShape->IsIntersecting( Other->getCollidableShape() );
}
};



I prefer the second option because you only have to put collision detection once into your game objects, and shuffle the dark art of collision detection into the objects that actually need to deal with collision detection. It also makes it much easier to swap different collision shape in and out of your classes, or derive more complicated collision detection objects from simpler ones. For example, you could have a CollidableShape that is composed of OtherCollidable shapes quite easily, or create a complicated CollidableShape from simple ones.

Hopefully this is helpful and not just a clear demonstration of my n00bness [wink] But if it is, you should let me know [grin]

Not at all noobiness. I'm actually very interested in your second example and the idea of being able to compose a more complex shape from a group of collidableshape objects. I'm thinking that could even be applied to the idea of a mario sprite carrying an object.

Obviously I've got basic collision detection, where everything is either solid or not, down to a fine art but problems come in a game like Udo when you have, say, moving platforms or blocks that can end up stacked on top of other sprites.

The solution I want for Udo is to have moving blocks work like some of those old Mario platforms, where you can run in front of them, but if you jump above them and land on them, you stop.

This seems pretty hard to implement with my current collision detection methods so I think I need to rethink. I basically need three types of object - non-solid, completely solid and like described above. Obviously non-solid are easy since they are just ignored, and solid is fine by my tradional methods, but I need to figure out a way to implement the third kind, and also be able to get that to interreact with the solid kind as well.

I'm going to have a play around with it tonight. I think I need to rip all the collision guts out of Udo and start again really.

Thanks for the input. Much appreciated.