Hey everyone! I've finally come close enough to considering networking a game. My question is this:
For a traditional FPS, whereby there may be AI *teammates*, one could use the same class (UserBase) as the other real clients, but replace the networked inputs with simulated ones.
However, this particular game (no surprise here) involves zombies. I originally intended to implement them as a separate team, and network them in the same way as normal players. However, this gives rise to the fact that many packet entries for zombies wouldn't require all the same data as that of a normal player (weapon type, ammo, clip). Do you think that this would be an acceptable solution to take?
My other option would be to split the packet into two parts; Base information and then specific information, but I don't like the sound of that very much
Thank you everyone!
0
NPC / AI should they be abstracted?
Started by Angus Hollands, Dec 01 2012 05:55 PM
2 replies to this topic
Sponsor:
#2 Moderators - Reputation: 3295
Posted 02 December 2012 - 12:54 AM
Either will work.
Also, you can split packets into separate subtypes, and include a bitmask up front of what subtypes are included. A single byte gives you 8 possible subtypes. Thus, Zombies simply would not send weapon and clip information... unless some zombies have some kinds of weapons ;-)
It's common in "deep inheritance" hierarchies, to marshal the parent class first, then add your own information in the serialized stream. If you use this mechanism for networking, having some parts (movement) in a superclass, and specifics (player vs zombie) in a subclass would work out alright. But I personally don't like deep inheritance -- I much prefer composition.
In a composition system, you pretty much get the same thing, though -- add a "gun and chip" component to players with guns and clips, and a "ooze and brains" component for zombies, or whatever. Marshal (and de-marshal) components in order, and you have the same effect. Use the bitmask to tell which components have updated data, perhaps.
Also, you can split packets into separate subtypes, and include a bitmask up front of what subtypes are included. A single byte gives you 8 possible subtypes. Thus, Zombies simply would not send weapon and clip information... unless some zombies have some kinds of weapons ;-)
It's common in "deep inheritance" hierarchies, to marshal the parent class first, then add your own information in the serialized stream. If you use this mechanism for networking, having some parts (movement) in a superclass, and specifics (player vs zombie) in a subclass would work out alright. But I personally don't like deep inheritance -- I much prefer composition.
In a composition system, you pretty much get the same thing, though -- add a "gun and chip" component to players with guns and clips, and a "ooze and brains" component for zombies, or whatever. Marshal (and de-marshal) components in order, and you have the same effect. Use the bitmask to tell which components have updated data, perhaps.
Edited by hplus0603, 02 December 2012 - 12:55 AM.
enum Bool { True, False, FileNotFound };
