Adding entities to an entityset on client request


I have been playing around with Zay-ES for some time now and must say it has vastly simplified my game design needs.

In my game I am now at the point were I am seriously attempting to implement my entity system across the clients and server and came across a few ideas.

Essentially my game is set in space and I want to be able to implement a fairly detailed sensor/radar system.
To that end I have created EntitySets on the client holding bare bones information for all objects in space. (eg. type:ship, position:x,y,z, …)
With this information at the client side I intended to simulate a sensor sweep that would do a ray cast to check if the object was “visible” to sensors and if so retrieve further information from the server in an additional entityset.

After getting to this point I realized that I could not generate an entityset for only “visible” objects efficiently. If it was single player game it would be easy to just mark the entity as visible within a component and retrieve all relevant entities with a simple FielfFilter. Multiplayer marking it as visible would have to be done per player instance which would lead to a really sluggish custom filter. As an alternative I considered requesting the entity information be sent back to the client but quickly disregarded that as an option as well as I would need change updates to this data.

This left me with the thought of creating an entityset that was initially empty and having the server add entities to it upon client request. There would be no requirement to have entities added or removed automatically just keep track of any changes to the components. I immediately delved into the Zay-ES source to see if this was possible but my sleep deprived brain just didn’t want to cooperate so I shelved the project for the night.

After sleeping on it I thought I should check see if I am missing something really obvious or reinventing the wheel. (I am know to do both of those things regularly!)


Are you using Zay-ES net for your networking? If not then it will take care of lots of issues for you that you haven’t hit yet. :slight_smile:

Anyway, you could do this with a custom filter. I’m not sure why that idea doesn’t work for you. Can you explain more?

To be clearer, I’d do the custom filter based on some sectors or something and not absolute position. You can always filter better on the client in your GUI itself but some kind of sector based filter will be more efficient than having to change the filter every time the ship moves. So if you divide your space up into a conceptual grid or something then you can make the grid cell part of your position component.

Actually, if you do that then you don’t even need a custom filter since an Or filter full of 9 field filters will work fine. Just reset the filter when the player’s ship crosses a grid boundary (ie: their grid cell changes).

Note: your other approach is not horrible either… you may have just not been thinking about it from the correct direction.

If you want to keep track of the visible relationships then just encode them as entities + components. So if PlayerA can see ship1 then you can create an entity with a component that links them, like a LineOfSight(PlayerA, Ship1) component. Some system on the server just watches for position changes and then creates/removes these entities as needed. (Creating entities is just as free as setting a component after all.)

Then on the client you just have a EntitySet looking for entities with LineOfSight with your player.

The moment I saw you had release the Zay-ES net code I started using it and yes it has greatly simplified the network components and required messages.

I had thought about using sectors in space but it doesn’t quite fit what I want to achieve with the game as it needs to be more precise. I want to create an environment where a player can hide from sensors by hiding behind a planet or turning off engines and floating like a just another piece of space junk. Having a wing of fighters waiting on the far side of transport ship that is acting as bait. A player may also launch sensor probes that will periodically scan and relay information back to the ship as well. I want to make getting and interpreting the sensor reading a big part of the game.

For example I want the player to see a bunch of small to medium objects floating in space and then make a decision to investigate because it might be an asteroid field or it could be a the remnants of a battle waiting to be salvaged. On the flip side that asteroid belt might have a hidden surprise or that space junk may be a player set trap waiting for a curious cat to drop by.

One of the driving factors for having the clients do the ray casting check was to reduce the load on the server. All the server would have to do is confirm the raycast was accurate and provide the relevant details and accuracy based on the strength of the sensor(s) and the detectable signature of the object being scanned.

I like the idea of creating disposable entities to represent the line of site and that fits perfectly with what I need. That solution will also solve the issue of how to manage fleets in that I can easily just have one lineOfSight entity for the entire fleet which will allow the sharing of sensor readings.


@kylar said: I like the idea of creating disposable entities to represent the line of site and that fits perfectly with what I need. That solution will also solve the issue of how to manage fleets in that I can easily just have one lineOfSight entity for the entire fleet which will allow the sharing of sensor readings.


And the nice thing about doing it on the server is that the client will never see them unless the server decides it can see them. ie: prevents cheating. The server also knows when things move and so can simply redo the checks when things move. The system that does the checks can use whatever data structure it wants to make this more efficient… which may still involve sectors. :slight_smile:

You may have misunderstood the sector approach, though. It was just a coarser grained version of this similar filtering. The client would still have had to do the line of sight checks and so on but it would be guaranteed to only be doing them to local objects. The down side is that the client would have all of the information for all local sectors and therefore could hack their client to provide more info than what they could actually see.

…but either way, positions would still have been full detail. They would have just included an additional gridId field or something in addition to x,y,z.