Would like some help with enemies pushing the player.

Hi everyone! I am currently developing a top down game in which you control a cart and enemy attack it.

Here is a reference video of the problem:

I’ve been struggling with finding a solution to the enemies being able to block the player and I would like to implement a way to push the enemies out of the way. Obviously I could disable collisions but I think that would just look bad.

I am not using behavior trees because there will be a lot of these on screen at once and I just don’t really need that much logic in them besides just following the player. They are currently using a floating pawn movement system if that helps at all :).

1 Like

Hey there @TheEtherealPineapple! This is a really cool design, and the potential already shines through in this post! Excited to see where this leads!

On to the answer! So this is going to be dependent on a number of factors, one of which is how sophisticated you want the knockback. Since these aren’t characters and just pawns we can’t use launch, so one of the best things to do would be to just impart the velocity of the vehicle to the zombies and disable their movement component while they recover. Depending on how your movement is set up I’ll let you handle the disabling, but here’s a super basic script to impart the last velocity of a player to the floating pawns. Though it’s probably best to process the speed at which they were hit to justify if they move or not, but at the end of the day that’s design considerations!

Let me know if you have any questions! This is a simple setup and will require decent tweaking to make it feel right on your side, but I’m already confident in your design skills seeing as though I already want to play this game haha!

2 Likes

I think the problem is the ground friction of the black things against the motor power behind the character.

If you put a heavy enough object in front of the player, the player won’t be able to push throguh it.

Easiest solution is probably to toggle the friction value to 0 for a a fraction of a second - this should result in a “natural” pushback that wont stop the player - and can be adjusted to avoid sending the pawn flying.

If the floor is not the issue (the floating movement is acrually floating with no gravity) then the simnplest solution is to turn off their engine on impact.

Meaning they must be actively pushing towards the player and really should not be after collision occurs.

You could simply detect the collision and apply the same motion of the player controller to them so they stick like bugs on a windshield…

How about this:

  • the pawn:

  • the enemy:

Since this is using physics, you now get access to Mass and physical materials.

Seems like it’s worth exploring if there’s a plan to use more physics later on. If no, setting velocity as in the @SupportiveEntity example, would be my way to go about this.

You forogot to check the damage causer identity. Not that enemies can cause damage to enemies in the current example, but you know… since you flaggged the damage causer, may as well test it :stuck_out_tongue:

Otherwise Its a nice example of not having to use Pawns… probably lighter weigh computation wise without the movemebt component of pawn (which is replicated too).

I was connecting wires mostly at random until it started to work.

Otherwise Its a nice example of not having to use Pawns…

They’re all Pawns.

I was avoiding going into the physics side myself since they were using floating pawn movement. I do like the friction version as well, it feels a bit better than mine, mine acts like an impulse and it it nice and chunky but definitely not as smooth!

But they don’t have to be. You could apply the same logic on nearly anything. Which was also kind of my point with just checking the impact and applying whatever pushback you prefer.

For performance purposes, I’d avoid the pawn class so that in theory you can create a manager and just spawn a billion of em without too much strees on the cpu (gpu is a different story since each is at least 1 drawcall).

1 Like

Thank you guys for the massive amounts of help on this one!!! I tried each solution individually and decided to go with sort of a mix between @SupportiveEntity and @MostHost_LA 's thoughts. I used the same methodology to make it so each enemy would slightly repel each-other as well in order to make it easier to “split” crowds.

I attempted @Everynone 's solution and it worked well, but I decided to stray away from simulating physics on each pawn.

Also thanks @SupportiveEntity so much for the words of encouragement!!! This is my first semi-professional project so I’m glad it looks good in its current state :)).

1 Like

Absolutely no problem! Definitely take good stock on MH’s words on performance here, pawns aren’t as heavy as characters but they are definitely going to be expensive if you start needing a ton of the enemies at once! If you start needing more than 20 or 30 you may start feeling the weight and may need to look into handling their movement manually. I do recommend doing stress tests on the CPU side as soon as you get your loop down if possible!

1 Like

If it gets to be a prblem, look into loop aggregation and OnTick management.

The short of it is that you create one actor that runs the ontick event, and manages the location/movement of all the entities it controls (which is a lot cheaper than having each entity do its own thing).
Note that there may be a sweetspot to how many objects ca be confortably managed by 1 manager entity - so maybe you end up needing more than 1 to manage batches of “units”. Same theory though.

2 Likes