Pushing sprites

[Vincent]

Hi guys!

I just updated to the latest SGDK2 version.

I looked at the CleanGame demo to understand the pushing behaviors between sprite, but I failed to reproduce it.  I think I am confused by the rules. (PushSprite, ReactToPush, ReactToPushBack, etc.) 
I want to use these behaviors for two things:
1- Like in the demo, I want to create boxes to push
2- I want to use these behaviors to create sprites that cannot be passed through even if they don't move (sprite walls that can be broken eventually for example).

What rules would I have to implement on which sprites to implement this.
Case 1:
I have a character sprite (binded to player 1 controls, so it will move)
I have a box sprite (can be moved)
Which rule goes where?

Case 2:
I have a character sprite (binded to player 1 controls, so it will move)
I  have a wall sprite (must not allow the character to pass and must not move when pushed)
Which rule goes where?

Also, in the help files, it says that the rules ReactToPush and ReactToPushBack are for "Pushers".  Is this "Pushers" a sprite category that is hard coded and must absolutely be named "Pushers"?

Thanks!

[bluemonkmn]

Case 1 is complicated, so I'm not sure I can get this right in my first try, but I think you want ReactToPush on the box sprite, and ReactToPushBack on the character that can push the box.  And I think those rules go before ReactToSolid in both cases.  If that doesn't work, let me know and I'll investigate further.

Case 2: Just put ReactToPush on the character sprite, and pass the something indicating the wall sprite(s) in as a parameter.

Pushers is a sprite category (you can name it what you want) that contains sprites like Wall for case 2 (the wall pushes the player away from it).  In case 1, the box would use a sprite category containing the player sprite, indicating that the player is what's pushing the box.

[Vincent]

Great!  I'll try this tonight.

Thanks

[Vincent]

I started working on these two features.

For case 1, I'm still working on it.  The boxes have a tendency to get pushed very fast (they are launched into the air rather than pushed) or to overlap each other almost in a kind of gelatinous way...  Very weird.

For case 2, very simple, like you said bluemonkmn.  ReactToPush on the character and it works just fine!

Thanks!

[bluemonkmn]

For case 1, I'm still working on it.  The boxes have a tendency to get pushed very fast (they are launched into the air rather than pushed) or to overlap each other almost in a kind of gelatinous way...  Very weird.

If case 1 includes the boxes' ability to push each other, then it's even more complicated, and may be somewhat unreliable.  It was a real challenge to get that working in my own project.  Hopefully it's good enough, though.  I think you want to:
1. Make sure the box has a maximum velocity set (implement a LimitVelocity rule so boxes will not launch off into another dimension).
2. I think the boxes will also need to call ReactToPushBack in order to prevent them from overlapping each other.  Check CleanGame (Package sprite definiton) for specifics on what sprites are in the category that is pushing back, and when to call it relative to ReactToPush and other movement-related rules.

[Vincent]

I'm still working on the boxes, I'll look at the CleanGame more carefully.

I added something that is not in the CleanGame project that might interest you.  Boxes push one another but when there are stacked on top of each other, when you push the bottom box, the boxes on top of it get pushed too.  I just allowed the boxes to ride one another like moving platforms.

It opens up possibilities to push a pile of boxes rather than only pushing the one on the bottom and have the character get the stacked boxes on the head.  :hurt:

[bluemonkmn]

I actually did exactly that in an earlier version of CleanGame and removed it because it caused something else screwy to happen.  Don't remember what, though.  I think if you have multiple boxes sitting on another box, they won't push each other correctly going one direction or the other, especially if you're pushing them into wall, and will overlap each other.  This would happen because ReactToPushBack and ReactToPlatform are both functions that force other sprites to process their rules before processing their own rules.  I'm not sure if the way this happens for platforms would conflict with the way this happens for pushing, but I must have disabled it for some reason.  Maybe that reason is gone now, though, because I improved the implementation after I disabled that, I think.

[Vincent]

Okay!  I think I've got it for boxes!

It might seem obvious, but the specific order of the rules are important and that got me some time to figure it out.  So, for the box, it's something like this:

• Gravity
• ReactToInertia
• Platform management rules (boxes if you want and other platforms)
• ReactToPush (everyone of them, boxes and character)
• ReactToPushback (everyone of them, usually only the boxes)
• LimitVelocity
• ReactToSolid
• SnapToGround
• MoveByVelocity

And then, a very important thing that took me a while to find out, the boxes must have a higher sprite priority than the character pushing them.  Once I set the boxes priority, they stopped overlapping each other and being thrown very hard in the air.  That was funny though!  :laugh:

So for a general rule: the "pushers" must have a lower or equal sprite priority and the "pushbackers" (sure ain't a word but whatever) must have a higher or equal sprite priority.  If the "pusher" has a higher sprite priority than the "pushbacker", it won't work...  Well, it didn't work for me.

For the character himself, it works like boxes, but remove the ReactToPush, since the character won't be "pushed" by boxes.  I think he's just pushed back by them when they hit a wall.

I hope this comes in handy for other people out there! 

Thanks a lot bluemonkmn!

[bluemonkmn]

Glad you could work this out and provide the helpful details for all.  I should have told you about the sprite priority.  Yes, the pusher has to be a lower priority than the sprites it pushes to work more reliably.  I'm glad you were able to work that out, though.

[Vincent]

Okay, now I'm facing another problem. 

Since the "pushers" must have a lower or equal sprite priority than the box sprite, then a sprite created at runtime will always have a higher sprite priority than the sprite create at design time.  A dynamic sprite cannot push...

Example:  In my game, I want the TKBolt power to be able to push boxes.  I don't create the boxx at runtime.  And even if I would, The TKBolt projectile can be created at any moment.  It will be created after the box.  How would I solve that?  Should I look in my previous project (the tkd remake game) to use the function I used to replace SpritePriorities in the list?

Or is there a supported way to tell to a dynamic sprite te execute it's rules before the other sprites?

Thanks!

[bluemonkmn]

I don't have a quick answer for that one.  I'll have to think about it.

[Vincent]

No problem!  Take your time!  
There's no rush anyway I have a lot of work to do just designing the levels in my game.

Thanks a lot for helping me out! 

[bluemonkmn]

I have a thought.  Dynamic sprites aren't necessary.  Initially I didn't implement them at all, but then added them as a convenience so you wouldn't have to pre-define all your possible sprite instances on every map.  You should be able to pre-define TKBolt sprite instances on each map with the appropriate priority, and leave them inactivate.  Then you can activate one whenever you need to with the correct priority level.  The function would be very similar to the TileActivateSprite function, but would probably activate at the player's location instead of at a tile's location.  There isn't a function like this now, but you could certainly add one based on a copy of TileActivateSprite.  If you only need one then you could use the existing ActivateSprite plan function, but that would have to be implemented on a plan, not a sprite.

[Vincent]

Okay, I see.  So I would hide the TKBolt sprite (or more than one if needed) and make it (them) appear when needed...

I'll try that!  Thanks!

[bluemonkmn]

Yes; I use the terms "Activate" and "Deactivate".