Re: [pygame] Some Platforms

[Matt Bailey <mattb@xxxxxxxxxx>]

On Sunday 20 February 2005 03:12, Manuel wrote:
> Hello Matt
>
> Of course, ANY help is welcome, i've recently changed my code from:
> 	sprite always asking; I'm on the platform??
> for:
> 	platfom sayig, you are not on me, so start falling
>
> This adds more complexity, but could be used for some games.
> For example, if you want a sprite to always be on the platform, the simpler
> version is well, but what happens if a platform just disappear or rapidly
> change it's position?? the sprites on it have to start falling.
> Of course this is ugly for elevators, like in Abuse, when it does not
> matter how the elevator falls, the player should always be on it.

	Hmmmm, I take the original approach, actually. In my case,  it's a lot 
simpler to just have one object quickly running through a list of rects, 
rather than have a whole bunch of objects each doing full collision detection 
for the player, any bullets, and whatever other solid objects are around. In 
fact, my solid objects (floors, platforms, walls, etc) don't even have an 
"update" function. Stuff that's logically static, I try to keep progmatically 
static as well. I haven't tried elevators, but the way my collision code is 
set up, I *think* they would integrate well (so long as the elevator gets 
updated before the player). As long as you kept the movement of the elevator 
per frame less than the distance the player free-falls per frame, the player 
would stay on the elevator. If the elevator went down too fast, you'd see the 
player come off of it.....but this is physically accurate. :)
	Basically, I have the player move, then run through a list of solid objects. 
Collisions are detected by comparing the player's position in the last frame 
to its position in this frame after moving, against the position of each 
solid object. If, for instance, the top edge of the player is above the 
bottom of a solid object *and* the bottom edge of the player is below the top 
of an object (this makes it work for objects taller than the player as well 
as those shorter, such as thin platforms), I check for stuff like whether or 
not the right edge of the player rect was less than the left edge of the 
object before, and is greater than the left edge of the object now. This way 
I catch collisions even when the player never actually "touches" the object 
in-game, but passes through it (for narrow objects). After this is done and 
I've moved (or "stopped") the player as appropriate, I update my scroll code 
and check for collisions again.

> Ok, forgive all the above kinda self-notes(i tend to do this). As you said,
> generic python list are the best implementation combined with Rects.
> Rects, are, from my humble opinion, THE way to think games in pyGame.
>
> And about groups and lists:
> I was a little nervous when I entered all sprites in order to the group 
> that would be represented, and I obtained a disordered group overlapping
> itself (as you can confirm in my code)

	I must admit I'm a little rusty on my Pygame stuff (been  on other projects 
for the past couple months), I didn't spot this in the code. :)

> Also, the official pyGame homepage links to a selfcalled "PyPlatform"
> engine, that givesme a fu**ing 404, so what is this about?? I'm really
> interested. I'm from the 'doItYourselfAndBeOriginal' mind, but any abstract
> code is very welcome :-)

	I tried to check out that link too, it seems the project is abandoned.

> So sendme your code/notes

	I'll try to get something together for you by this afternoon or tomorrow.

	-Matt Bailey