Re: [Algorithms] Entity Management, Messaging and Traversal
Nick Trout <nick.trout <at> codemasters.com>
2007-10-01 15:10:23 GMT
> Matthew Harmon
> While most operations we use (Draw(), Update (), etc.) are required by
most entities, there are some that only apply to a small number of
objects. For example, a PhysicsUpdate() call [...] My initial reaction
is to create a publish/subscribe scheme [...]
(Apologies for late reply, been on holiday. Hopefully I'm not repeating
anyone here. At least I haven't seen this version stated explicitly)
I think if you added a publisher-subscriber mechanism you're just adding
a generised interface registration system. Why not just add C++
interfaces? i.e. IRender, IPhysics, INpc, etc and register these at
construction time with the appropriate systems (*1)? One thing I've
noticed about making things overly generic is that it confuses people
(*2). If things aren't generic enough and people are limited that points
to a design flaw which you, well, have to design to fix (good!). P-S
will more than likely become a soup of crazy topic registrations which
obscures your game architecture (e.g. dependencies are no longer clear)
-- "Oh, I can't see how these two objects relate to each other, so they
obviously need a new topic to communicate..."
I agree with what has been said about inheritance, you should always use
sparingly (to avoid suck). I agree with what Tom says about components
as well (if you have to query for other components at some point you'll
break the encapsulation). I think the trick is to make sure you can wire
up you component at creation time, i.e. the entity constructor/factory
has all the necessary information to create an entity. This can be made
easier by having higher level, more specific entity types, which
generalise a specific behaviour (e.g. character, vehicle, building, etc)
and then you specialise these with data (e.g. hit points, meshes,
textures, LOD, damage, sounds etc). If you want to update particle
effect attached to object you do it in there. And you can add your
special cases there (*3).
Nick
(*1) They don't all have to be implemented by the same object. Objects
created by the entity at creation time (that implement, say, IRender)
might be registered. This is probably better OOP as well because IRender
is usually not an interface it's a RenderableObject IYGMD. -- I think
this lends itself more to the AOP style mentioned in the Insomniac paper
(I think they've just used a C version of C++ AOP here because SPUs
don't like C++)
(*2) The very term "entity system" is a case in point. Ask 3 people what
it is and you'll get 3 different answers. Asset systems have also been
mentioned in this discussion, but they are for requesting and managing
assets, but some people call them components.
(*3) Oh come on! How many times have you had to put a hack in to ship or
provide a special mission functionality? Ship happens! Why not design it
in.
**********************************************************************************
Disclaimer
The information and attached documentation in this e-mail is intended for the use of the addressee only and
is confidential. If you are not the intended recipient please delete it and notify us immediately by
telephoning or e-mailing the sender. Please note that without Codemasters’ prior written consent any
form of distribution, copying or use of this communication or the information in it is strictly
prohibited and may be unlawful.
Attachments to this e-mail may contain software viruses. You are advised to take all reasonable
precautions to minimise this risk and to carry out a virus check on any documents before they are opened.
Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and
must be signed by both parties. Except as expressly provided otherwise all information and attached
documentation in this e-mail is subject to contract and Codemasters’ board approval.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters.
This footnote also confirms that this email message has been swept by
SurfControl for the presence of computer viruses.
**********************************************************************************
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
For those interested, there's a neat set of slides over at Insomniac's R&D page with relevance to this topic: http://www.insomniacgames.com/tech/articles/0807/a_gameplay_architecture_for_performance_clean.php Cheers,
RSS Feed