   network /w engine architecture issues
  i know this has probably done over but oh well :-/i have made 2 engines now, and have re-written them lots of times due to shocking architecture.a few ideas/issues i am dealing with now:okay we have a Node class as the base classthen a RenderObj would extend from thisalso a NetObj would extend from this, for network codingnow, would a model (geometry + material), extend a renderObj and a netObj? this would causes issues with multiple inheritence!or maybe a renderObj would extend from a NetObj, but extending from a  netobj automatically means it will be replicated over the network?maybe if a class/object needs to be replicated it should contain a netobj instead of inherit from one, and if i object has a model, it should contain a model instead of inherit from one? but if this is the case, then these objects must inherit from some base object so i can store them in a linked list?!ideas to help me get through this confusion would help 
  I''m not sure how to help you with the network architecture problem, but I know that you can avoid multiple inheritance using the virtual keyword when defining parent classes:class Foo;class FooSon : public virtual Foo {};class FooDaughter : public virtual Foo {};class Fooness : public FooSon, public FooDaughter {};  There would only be one base Foo object. ;  what does that do?;quote:Original post by psykr  class Foo;class FooSon : public virtual Foo {};class FooDaughter : public virtual Foo {};class Fooness : public FooSon, public FooDaughter {};  If you did this without the virtual keyword, then all the actual data in the Foo class would occur twice, if you created an object of type Fooness.  When using the virtual keyword, it means that there should only ever be one Foo instance for each object.  Diagramatically...With "virtual"[Foo]    / \  /\[FooSon][FooDaughter]  \/    \ / [Fooness]  Without "virtual" [Foo]   [Foo] |  | |  |[FooSon][FooDaughter]  \/    \ / [Fooness]  Thus, whenever Fooness tried to access data that was declared as part of Foo (and which it obviously inherits), then it is ambiguous which Foo to use, if virtual isn''t used.  If it is, then there is only one Foo, and so Fooness grabs its data from that one Foo.As for your original problem, I''m not entirely sure what design is best, but my intended [future] implementation uses interfaces.  Thus, if I have an interface IRengerObject, and it points to a concrete object of some sort, then I can request an interface of type INetObject.  If that underlying object supports INetObject as well, then I get that interface.  And if it supports it, then it is already working with the network code, and is replicated.  If it doesn''t support INetObject, then it is oblivious to the network, and isn''t replicating.  (Well, that was highly incomplete and vague, but maybe the basic idea is there.)Of course, interfaces in C++ bring plenty of drawbacks, as well, a big one being that it is incredibly difficult to inherit implementations   as well as interfaces.  But then again, that''s how COM works, and I suppose that Microsoft knows at least somewhat what it''s doing.  And I''ve heard arguments that implementation inheritance is bad design, so to some, this isn''t a drawback at all.  The biggest drawback is that changing this would require an entire rewrite to an engine, most likely, but it''s something to consider for the future, maybe. ;  well i am restarting my game from scratch so i can design it better.these interfaces sound k3wl, i have used interfaces only in java... havent tried c++ tho... might have to do some research here ;  you remind me of my wee self back in 1885..er..rewriting my engine a million times over was the thing for me back then .Somtimes rewriting your engine isn''t necessarily a good thing...just food for thought... ;  The interface thing in C++ is basically using abstract classes as interfaces.  An abstract class is one that has at least one member function with the declaration as such:virtual int MemberFunction(int SomeParameter) = 0; //The " = 0" part makes it a pure virtual function  You can''t instantiate an abstract class, but you can inherit from it.  All my interfaces inherit from one single base interface, i_Unknown.  This class has Attach(), Detach(), GetInterface(), GetInterfaceId(), EnumInterfaces(), and SupportsInterface().  They do the following:Attach  () and Detach  ()These are used to implement reference counting.  Every object remains in memory until its internal mRefCount becomes zero, then it deletes itself (at the end of a Detach() call).GetInterface  ()Its two parameters are an interface Id, and a void pointer to a pointer of some interface type.  If the underlying object supports the requested interface, then it fills in the interface pointer with a pointer to the correct object (usually this  ).  It also calls an Attach() on the pointer that it returns.GetInterfaceId  ()This just returns the interface Id of the current interface.  This is a static member function, as opposed to a virtual member function.EnumInterfaces  ()This takes one parameter (the previous interface Id) and returns the next interface Id that is supported by the underlying object.  Giving it the Id for i_Unknown makes it return the first Id in that objects list, and when it returns i_Unknown''s Id, that indicates the end of the list.SupportsInterface  ()Returns true or false, indicating whether the underlying object supports the specified (by Id) interface or not.Since every single interface inherits from i_Unknown, then every single interface pointer you have can be used to get other interface pointers, assuming the object that the interface pointer points to supports that interface.So any concrete class you define should inherit from one or more interfaces, and every virtual member in the interfaces should be implemented, and no more.  The nice thing is that C++ will force you to implement every single pure virtual function, because unless you do, the class is still abstract, and thus can''t be instantiated.And a nice thing about GetInterface() is that your concrete class doesn''t have to inherit and implement every single interface that GetInterface() returns.  You can also internally create another object that does support those extra interfaces, and then in GetInterface(), return the pointer to that internal object.  On the outside, it''s completely transparent.And in addition to all that, it''s sometimes nice to implement a templated smart pointer that automatically handles Attach() and Detach() for when the pointer goes out of scope, or is copied, etc.There''s a lot more to it than that, of course, but that''s the main gist of my design.  It''s almost entirely based off of my limited knowledge of COM.  But simplified in many areas, I think. 