Sim-Eth-Es attack system

I’m wondering what approaches there are to creating an attack system. Let me start by defining attack system (in my game at least):

  • Creates the attacks based on player inputs (player wants to shoot a bullet/bomb, attack system creates the bomb entity based on player, attack type, constants, environment etc.)
  • Keeps track of players abilities (like which guns, which tools etc. does the player have access to currently) - Perhaps this could be seperated into an InventoryState

Right now, my GameSessionHostedService is creating a Attack entity with owner (the player) and attack type (basically the player input/key presses/mouse button presses etc.). I’m doing entities and not components, as I’d like to have the option of one-to-many relation (i.e. create multiple attacks simultaneously). The AttackState sees these Attack entities and creates the resulting attack (by creating another entity).

Does this approach make sense ? Have you guys done anything of the sorts and what considerations did you have?


mine is composed of a weapon control which gets shoot command. the weapon is simply a entity creator. the entity has a model, pos, shape and damage component. the weapon control can be exchanged (cuurently minigun and rocket launcher). the weapon control takes care for the amount per second and type of projectil. it also takes care for heat up cool down.
my damage system takes care for collisions of entities withe health, pos and shape and damage,pos and shape. it callculates the new health if collision. I enhanced it with a link to the fireing ship to know who mad a hit point.

ADDITION: the bullets/rockets have a driver control (like the ship itself).
NOTE: I’m not 100% sure if it is the correct or best approach. There are quite a lot comparison as I can fire 20 bullets a second :smile:

1 Like

This part only seems necessary if you want to steer them during flight.

1 Like

As to the first post, I’m not sure I understand what this means in game to the player or what the “game logic” needs to be for these so it’s tough to comment one way or the other on your approach.

I normally think of a player attacking as “fire this gun”… which is a “fire this gun” command and not an “attack” command. I would think of “attack” as in the case where you click on some enemy and then automatic attacking will be carried out. Like more turn-based style like FFXIV or WoW versus twitch shooters.


My method is pretty simple. When someone presses shoot on the client it activates a function just like ‘move’ when it hits the server side it places a bullet entity in the world gives it a velocity and that is it. Physics takes care of the rest.

Seems to work fine.



Exactly my plan for at least some of the projectiles like the rockets. and it is just the easiest way even if I don’t steer them btw as the system and code is just there. Note the driver in my code is similar to a models spatial I just see type rocket and apply the rocket driver or I see ship and apply ship driver and so on. just the es way imho

1 Like

For whatever single action that tolerates 50ms+ delay having this shiny transmission mechanism of Paul you can write just

public void doOneTimeAction(int action);

and that will cover it, as whatever you want to do then - you can do on server. What I’m thinking of now is how to set up “dynamic” PlayerActionState that could be set up from server… I mean not just mapping but behavior as well… but maybe I went too abstract already

1 Like

I guess in sim-eth examples I took a short cut but normally there is a system that only attaches drivers to objects if the relevant control component is there. No reason to waste time calling drivers for regular projectiles, really.

1 Like

That part was not yet ES like in your example, but there was a comment that this should be done more ES like :wink:
I don’t know if it is really a wast of time. I mean my rockets have steering for sure. For plain straight on bullets I agree it is not necessary, but there I implemented anyway a much much simpler driver, so code vise it is like there is no dirver, but the driver just fits perfect and makes the design - at least for me - simple to understand and I can add easily other projectils with interesting steering behaviour as I simply have to implement a new driver for it. So I guess I leave it for that way in my case as instead handling straight bullets differently. I somehow like the idea that the different drivers are like different looking spatials, handle them in a mob container server side.
Btw. with this drivers I can easily implement swarming bullets :smiley: or what ever.

But any way thanks a lot for that great sim-eth-es example Sir, I would never get that far without! And still endless fun ahead :smiley:

1 Like

+1. It’s like a diamond mine to explore… contains pure gems if you are able to recognize them. Like this one:

Serializer.registerClass(Name.class, new FieldSerializer());            
Serializer.registerClass(BodyPosition.class, new FieldSerializer());    
Serializer.registerClass(ObjectType.class, new FieldSerializer());
Serializer.registerClass(Position.class, new FieldSerializer());
Serializer.registerClass(SphereShape.class, new FieldSerializer());

It’s not just suitable for the task. In ES it fits it exactly 1:1, as components are nothing but data, i.e. fields, so FieldSerializer suits perfectly for them. You can even probably rewrite this in a generic way, if you like.

1 Like

And maybe a small bug report: Your debug HUD does not vanish/reset if you leave the game you see the HUD still when you have the login screen. Now do now a couple of login, disconnect, login, disconnect and you see that position and speed in the HUD bar is multiple time there (as many time you do login/disconnect cycles). And after 5th or 6th attempt you get some negative position exception in the gird layout, which took me some time to track down (I thought I messed my game and later tried to reproduce the same in sim-eth-es :slight_smile:)
Nothing urgent or so, maybe even good as people has to dig a bit deeper and that way understand more and more of that example, so feel free to leave it as it is, I just wanted to say.

And sorry to the OP for my off-topic report here.

1 Like

Yeah, I’ve seen it too… just haven’t had time to fix it.


This part I didn’t with ES specific logic but just an interface for the various projectiles generators I have (currently two of them twin minigun and rocket launcher). The projectiles are pure ES based, as described and as Paul said for only straight forward bullets it might be an overkill, but I don’t know in my case it just works good and looks good code wise…

But as soon you want to visualize the weapon currently selected by a player then you need also for this a ES style approach I would say.

1 Like

Thank you for the input. I will continue and update this post once I arrive at some sort of design

1 Like

I was also thinking about the Combat System for my game during last week (At my free times in casern :wink:).

It consists of these sub systems :

  • SeeingState (VisionState): This system detects and inform when an entity see other entities. (Based on distance, view angle and entity types)
  • HearingState : This system detects and inform when an entity hear something.
  • AttackState : Based on what an NPC is seeing or hearing this system decide if he should attack enemy.
    And based on his weapon types (weapon effective range, hit point ,…) and his distance with other enemy, decides if he should follow him, in that case informs the SteeringState to follow the enemy and when gets close enough he will perform an attack.
    At the end if the attack done successfully and based on the hit point will inform the HealthState to update enemy’s health component. (By creating new blank entity and setting a Damage component to it and linking it to target entity)

I need to think about many to many attacking behaviors and aiming strategies, … .

Will keep an eye on this topic :slight_smile:



Note: in certain designs or game types, those would all be a part of the AI system.

At the beginning of the AI’s update, for any entities that are actually active, you’d update what they see/hear since it could be quite complicated, depend on environment, etc… the entity’s behavior tree, or state machine, or AI script, or GOAP rules, would use that as some of its environment information to decide what to do next.

In fact, for some of those architectures, you wouldn’t even calculate that until needed.