BEAT EM UP - NPC - GENERAL MOVEMENT THEORY

In this thread we will be discussing how exactly an NPC or ENEMY in a Beat Em Up game should move or act in relation to the player(s).

Although I have a history playing video games, I only recently began trying to make them. It does add a new dimension when you try to essentially look under the hood and find the exact mechanisms of how some of the greats operated. Especially in this case, the Beat Em Up games.

The players will move from left to right until they encounter the enemies / npcs. Then the camera will stop. Essentially locking the player(s) into the current playable area, until they defeat the NPC’s.

And after they do? The notifier appears…“bling! bling! bling!” time to move along now. And the camera moves again. This process is now essentially a rinse and repeat process until the mini-boss.

The NPCs can be dragged and dropped into the level or they can be direct spawns based on logic which you choose.

From what I can tell in most of the classic BEU games, the NPCs are heading to either the Y1 or Y2 spots of the players. These are numbers on Y either plus or minus say about 100 units of the actor’s world location. So the area directly in front or behind a player.

Upon activation, the NPCs have to decide WHICH player to go to. I have experimented with distance checks to determine this. They also have to decide whether to go to Y1 or Y2 of the respective player. I have also tried distance as a way to determine this.

However, that approach seems fixed. I’m thinking now its a matter of choosing to alter which player and Y1 or Y2, based on events. After a knock down.?..After a successful attack / punch? After the demise of the player(s)? I am thinking now that at least one of those mechanisms was if / when an NPC is attacking a player at say Y1, the other NPCs immediately rush to Y2. I have seen that a lot in arcade Beat Em Ups. It is a flanking type effect.

And then of course there is the possibility of things on the Battlefield. Like weapons, ride-able things, etc etc. And if such things are present this would have to always take precedent over a move to player Y1 or Y2.

So when they get to Y1 or Y2, then what? I call this “time 2 attack”. I am starting off with half a second for the bottom tier jobber NPCs. I imagine this number gets smaller in these games as you progress and or fight mini-bosses or just big characters. This means that once the NPC reaches your Y1 / Y2, the timer starts, if the “time 2 attack” (or t2a for short) is reached, the NPC throws a punch.

What I have found is that the NPCs in BEUs should be knocked down at various times, lets say from weapons, or from combo attacks like uppercuts. And the final knockdown is when they are eliminated.

DASH - I have roughly experimented with this and have had it a few times. What you wanna do here is also a timed count like in T2A, but this time on the X. And if distance is great and on the X for like 2 or so seconds? Then they can dash attack the players.

Hope to hear the forums ideas on this. Thanks everyone.

My €0.02:

Not sure I understand the original ask here. Shouldn’t they move the way you design / need them to move? Are you asking for new ideas or a way to execute your vision?


The most straightforward way to implement what we see above without juggling arrays or digging in the EQS:

  • opponents move on a strip of navMesh with AI
  • players have an overlapping volume
  • using a timer, opponents query the players’ volumes at random and fetch the number of opponents inside that are engaged in combat, and their position:
    • if the the number < threshold, target the player:
      • prioritise front if a front attacker
      • prioritise back if a sneaky ninja
    • if the player is surrounded, let them be / attack from distance
  • have a spawn manager that controls the flow of combat and spawns enemies based on whatever factors you desire

Could this work for you? If you’re looking for input about 1 specific feature / scripting issue, you may want to dedicate it a separate thread.


May I suggest you pencil in a simplistic GDD. Outline how things are supposed to work, ideally, throw in a couple of sketches; then remove half the features that are not must have. If you’re not sure how to implement the core aspect of movement and interactions, you may want to skip mounts & weapons for now, at least.

What you have above is not a bad start but it’s out of focus. Consider the following:

  • achieve reasonable movement and controls for the player
  • rudimentary camera work is enough
  • block out 2 simple levels, 1 open arena and 1 with some obstacles, no assets
  • implement basic spawning system; when an enemy dies, another one pops up
  • implement basic enemy movement system, just walk up to the player
  • simplify the combat dramatically for now, 1 punch kills only, the player cannot die
  • get the basic game loop going - start / walk / fight / re-spawn / walk some more / fight some more
  • have very clear comms in place ← this is critical and will become a mess anyway
  • make a featureless version of what you ultimately want
  • avoid adding fluff or prettify stuff

If you can’t get the above right… widgets, mounts, weapons, stats, combos, visuals, sound, storyline and whatnot do not matter whatsoever and actually pull you back from where you want to be. However, once you do get the above going, start fleshing it out, iterate on the abovementioned list:

  • improve player movement and controls
  • make the camera work less janky
  • add a 3rd level with elevation
  • the spawn system now creates waves or 1-3 opponents
  • enemies can actually attack player
  • combat is now 3 punch kill, each enemy has a healthbar, player can die → game over screen
  • the game loop now has a main menu, loads a new level, has a game over screen and the credits screen with your name on it
  • clear up the comms you messed up big time because it’s a bloody jungle and we cannot find what feeds data to what and why dispatchers dispatch twice :person_shrugging:
  • start musing about another feature - a new enemy type, one that carries a weapon delivers serious bonks

Set up small tasks in your mind, work on 1-2 things at a time, tops.


That felt like €0.05.

1 Like

Sure, just asking opinions of the forum, thats all.

NOOOOOOOOOOOOOOOO!! not the navmesh!!!

That is a useful idea.

Beat Em Up type game Everynone… I mean, it could be like the everlasting skeletons beside Death Bringer on the Sega Genesis version of Golden Axe. But then they didn’t die just had everlasting energy hence no need to respawn. Might work for an endurance mode off the main menu or something, I think the NES Double Dragon had one.

I do sketches all the time when I need to figure out things.

Of all your suggestions here, this is the one I am focusing on tonight. What is “janky” about it appears to be…let me show you this diagram I’m working on considering camera movement.

Imagine that rectangle represents the playable area inside of a Beat Em Up. Your BEU “Battlefield” if you will. We can divide the two left and right halves into A and B. How I typically approached this was if P00’s (or P01?) world location Y was greater then the camera actor’s Y (actual camera component) Then the in the camera’s actors BP an add actor worldset fed by an event tick would move the camera. Smooth seems to involve subtracting P00’s world location from the the camera actor. But…since I don’t want the camera to get “janky” with it, there is a problem with this I knew I would face down the road, and that is, at the time of allowed camera movement and the notifier, if the player is in A, all is well. But, if the player is in B? You get a quick jerk. While playing the new BEU GI. Joe RIse Of Cobra on Steam, I noticed that the way it accomplishes this situation is to force players to go to the far right of the screen (I made an arrow and called it endpoint in the diagram) and then camera movement returned. I may need to make a separate thread for this issue. So far I haven’t got it.

Definitely want to have some climbing ladders and fences to climb. Nightmare getting NPCs to tread there though I fear…

I just want jump, punch, kick, dash (maybe dash jump), weapons, and things like uppercuts / combos etc etc.

I’m not too worried about that, enemy movement behavior is still the top priority atm.

Believe it or not, I have had that before, with mini-boss, but have had to redo so many times I lost a lot of steam lol.

ha

Enemies that present the weapon, this would be like Linda on Double Dragon, she came through the door and introduced many young players to a whip (that didn’t sound right)

I’m starting to see that is the best bet in game dev. The longer I spend at it all it feels like my debugging time and or efficiency is improving.

You are very generous @Everynone , thank you.