Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Sprite Move : collision and Obstacle

Author
Message
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 14th Jun 2014 21:04
I

I'm looking for a way to create some "obstacle" (block collision) for my character (or the ennemies).
Do you have an idea how I can do that ?

The image are only a 32*32 box.

My code :


Thank you for your answer

http://www.dracaena-studio.com
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 14th Jun 2014 21:27
Create a sprite to use as the blocker and set it invisible, test for collision. Or are you asking something different?

Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 14th Jun 2014 23:41 Edited at: 14th Jun 2014 23:53
It's something different .

When I test a collision between my "character" and an obstacle (a wall, a tree..), if the collision =1, my character can't move after that.
I'm looking for a technic to only block the character but not stop it forever (like on my first code).

I have found a little technic, but it doesn't work properly in some situation and I'm sur there is a better solution for sprite movement and block (obstacle) :



http://www.dracaena-studio.com
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 15th Jun 2014 10:08
OK so you're overcomplicating things a little. You just need to check collision before changing the sprite position at all. You're using GetSpriteCollision which will report back only after the collision has happened which will get you stuck. Since the sprite is still in the collision zone you're getting all sorts of weird movement when you're attempting to adjust.
So you want to use GetSpriteInCircle or GetSpriteInBox to test for a collision based on what the new coordinates of the player sprite will be.

I've re-written your MovePlayer() function to rely on a secondary function, CheckForCollisions(), and have it check before any movement happens.



However, you're making a lot of extra work for yourself. Check out the physics commands. They are much more suited for handling complicated sprite collisions. Also they'll allow you to move the player in a nice smooth way without a ton of math (though your works pretty well). All you have to do is add velocity to the player sprite in the direction of the mouse click. If collision happens AND the sprite velocity > 0 then set the sprite velocity to 0. Make all of the walls static sprites.
There are a lot of commands for physics and it seems overwhelming, but they are well worth it.

Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 15th Jun 2014 11:19
Hi Naphier

Thank you very very much for your answer ! It's excellent.

I would like to use the physics commands, but it's for a 2D iso game (RPG). So I don't know if I can use the physics for this kind of game and gameplay because I will have a lot of block and character (player an ennemies).

So I don't know if the game would be enough performant with 70 ennemies and more than 200 block to test each frame ^^.

I will make some tests to understand the phycis commands, because it's totaly new for me ^^.

Thank you again for your answer.

http://www.dracaena-studio.com
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 15th Jun 2014 20:32
Yeah I'm not sure. I did a little physics prototype and it was OK up to about 500 sprites.
There are tricks to get better performance, like stepping the physics engine, limiting polygon shapes to fewer points. Also, if your 200 blocks are positioned next to each other you really only need physics on the blocks that are borders.

I've attached the project in case you want to look at some physics setup. It shows examples of how to allow different groups of sprites collide only with certain groups.

Attachments

Login to view attachments
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 15th Jun 2014 22:07
Not quite sure what you mean by "technic".

Quote: "only block the character but not stop it forever "

You mean like if you push on it for a second or two it eventually passes through?

Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 17th Jun 2014 10:41
@Naphier : thank you again for your example, it's very interesting.

Thanks to your first answer, I have made a little mapeditor to test the blocks and other things. it works great.


Quote: "There are tricks to get better performance, like stepping the physics engine, limiting polygon shapes to fewer points. Also, if your 200 blocks are positioned next to each other you really only need physics on the blocks that are borders "

What does mean "Stepping the physics engine" ?
For the shape, I will only use box shape I think.
A lot of blocks are positioned next to each other, but I don't know how to get only physics on the borders of this block.

To get better performance, I think I will use some "zones" (a big sprite invisible).
If the player is on one of these zones, I create the next blocks/ennemies/PNJ and so. And I could probably set the old blocks invisible or deactivated.
So I should not have more than 50-100 blocks/ennemis to test on a zone.




At Phaelax :
If you try the code of Naphier, you will see the result I would like to have .
In my first code, the character was stopped forever (we can't move if he was near a block), in the new code, the character is just stopped if he's near a block, but we can move on the other direction.

http://www.dracaena-studio.com
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 17th Jun 2014 10:58
http://www.appgamekit.com/documentation/Reference/Core/StepPhysics.htm
You can step the physics engine forward by time this is more for reactions to collisions and velocities and stuff. Not really applicable to your methods of just colliding with walls. Better for handling objects that are moving with physics.

Look at the various sprite shape commands. You can draw polygons around your collision areas to use as borders. I'd probably go with some invisible sprites though. It all depends on how your scene is set up.
Performing something like a zone method is probably good.

Phaelax is quite well versed in top down rpg setups. He can probably help with more complex stuff. Up to 500 blocks and enemies on screen seems like a lot to me. I can't imagine a game with 50 enemies on a screen that I have to deal with them all moving. I'd get frustrated quickly.

Login to post a reply

Server time is: 2024-11-25 06:23:07
Your offset time is: 2024-11-25 06:23:07