Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKylotan

Posted 18 January 2013 - 07:16 AM

Assuming that my understanding is correct, can I ask if anyone has successfully implemented an entity system with networking for a First Person Shooter?

The first people I ever heard to use a component-based system (I won't call them 'entity systems' as I think that's a ridiculous name) were the developers of Thief, which is essentially a first person shooter. Even if you only shoot every few minutes. So, yes. Networking and component-based entities have nothing to do with each other really.

 

I don't like the way in which I must add endless methods to a GameObject entity to simply send its state. How would anyone recommend enabling serialisation of an object?

Why must you add endless methods?

There are various off-the-shelf methods of serialising objects (eg. JSON, Protocol Buffers) but I have generally gone for a hand-rolled approach. One function for each of the types I need to serialise, and complex types can yield up a list of simple types covered by the previous functions.

You could have "networked attributes" but essentially this is the same thing, except you have to make a note of what you're sending each time. Whether this is a pro or a con depends on how often you need to send partial updates.

 

At present, I have a manager class that calls the to_bytes method of each entity (GameObject) and in turn returns a sum of the bytes. It seems a lengthy step, especially when unserialising is a similar process.

There's not really any way of getting around this - serialization literally means creating a series of bytes from your object.

 

What are the main methods for state replication? Is it advantageous to use RPC updates that invoke state changes, or just use a full state / delta encoded state system instead?

Depends on your requirements. It's not unusual for games to do all 3 of those. Personally I prefer to separate the state changes from the RPC calls, however.

 

Are there any good resources other than I've mentioned on EntitySystems? Can anyone offer any insight into alternative yet relatively tolerant uses of OO that could work as a solution?


You're overthinking things. Components are just subobjects. You serialise them the same way you serialise any other subobject.


 

What is the most common architecture for dealing with game state? E.g Object heirarchy, object manager, ownership of update methods, serialise methods etc.


There's no standard. People use whatever suits their game. Shooters might just send specific position and orientation updates on a regular basis, with events to notify of projectile creation and destruction, whereas MMOs might often have to send full state updates as characters enter the visible range. How best to serialise these things will differ from genre to genre because you don't need full serialisation to send 2 vectors.


#1Kylotan

Posted 18 January 2013 - 07:15 AM

<blockquote class="ipsBlockquote" data-author="Angus Hollands" data-cid="5022715"><p>Assuming that my understanding is correct, can I ask if anyone has&nbsp;successfully&nbsp;implemented an entity system with networking for a First Person Shooter?&nbsp;</p></blockquote>The first people I ever heard to use a component-based system (I won't call them 'entity systems' as I think that's a ridiculous name) were the developers of Thief, which is essentially a first person shooter. Even if you only shoot every few minutes. So, yes. Networking and component-based entities have nothing to do with each other really.<br /><blockquote class="ipsBlockquote"><p>I don't like the way in which I must add endless methods to a GameObject entity to simply send its state. How would anyone recommend enabling serialisation of an object?</p></blockquote>Why must you add endless methods?<br /><br />There are various off-the-shelf methods of serialising objects (eg. JSON, Protocol Buffers) but I have generally gone for a hand-rolled approach. One function for each of the types I need to serialise, and complex types can yield up a list of simple types covered by the previous functions.<br /><br />You could have "networked attributes" but essentially this is the same thing, except you have to make a note of what you're sending each time. Whether this is a pro or a con depends on how often you need to send partial updates.<br /><blockquote class="ipsBlockquote"><p>At present, I have a manager class that calls the to_bytes method of each entity (GameObject) and in turn returns a sum of the bytes. It seems a lengthy step, especially when unserialising is a similar process.</p></blockquote>There's not really any way of getting around this - serialization literally means creating a series of bytes from your object.<br /><blockquote class="ipsBlockquote"><p>What are the main methods for state replication? Is it advantageous to use RPC updates that invoke state changes, or just use a full state / delta encoded state system instead?</p></blockquote>Depends on your requirements. It's not unusual for games to do all 3 of those. Personally I prefer to separate the state changes from the RPC calls, however.<br /><blockquote class="ipsBlockquote"><p>Are there any good resources other than I've mentioned on EntitySystems? Can anyone offer any insight into alternative yet relatively tolerant uses of OO that could work as a solution?</p></blockquote><br />You're overthinking things. Components are just subobjects. You serialise them the same way you serialise any other subobject.<br /><blockquote class="ipsBlockquote"><p>What is the most common architecture for dealing with game state? E.g Object heirarchy, object manager, ownership of update methods, serialise methods etc.</p></blockquote><br />There's no standard. People use whatever suits their game. Shooters might just send specific position and orientation updates on a regular basis, with events to notify of projectile creation and destruction, whereas MMOs might often have to send full state updates as characters enter the visible range. How best to serialise these things will differ from genre to genre because you don't need full serialisation to send 2 vectors.

PARTNERS