I have been studying COM recently for my job, and I have had several interesting ideas about how to implement different aspects of a game using COM. For instance, any monster in the battle that implements IRangedAttack would hang back and pelt your men with arrows while those that implement IMeleeAttack would charge in swords drawn. That is a very basic example but you get the point. Another possibility might be to implement the rendering engine as a component so it could be upgraded without affecting the rest of the program, and so on. I''m sure COM isn''t the fastest object model, but I have a 1333 (it was under $600 for the mobo, proc, and ram so you have no excuse for not owning one either...) so speed isnt ultra important end all that it once was (no I''m not advocating sloppy code). I am hoping that anyone with experience using COM in a game, aside from the required bit of DirectX, would share their experiences with us.

I''ve thought about it, but the load times for COM dll''s are *very* disappointing. If you design it correctly, there should neglible speed penalties for using COM - no more than using a virtual call and a dll call.

If you had a team of people who knew COM and had experience with OOD and writing games, you could make an extremely flexible game engine.

Wouldn''t it be nice if you could use more than one mod at a time with QuakeIII? Wouldn''t be nice if each point-release didn''t breakk all the existing mods? Or if the v1.27 client could connection to a v1.17 server?

Granted you don''t need COM to do that, but if you were using COM, those would all be trival operations.

...
The problem is with the IDispatch interface; he''s the guy that let''s all the scripting languages have access to the COM objects. If you built your game engine COMpliant you could use the VB IDE to write VBScripts that the engine would be able to execute - you wouldn''t need to write your own hookie scripting language. But IDispatch kinda blows; It only supports the VB datatypes, which means there''s no char* and no DWORDs. There isn''t exactly pointers, but it does support interfaces...

Magmai Kai Holmlor
- The disgruntled & disillusioned

Oh I tried to make a COM game engine, but the complexity kinda got out of hand and I really didn''t use any COM features. So intead, I just created virtual classes, or "interfaces", and programmed with them:

struct IObject
{
virtual int AFunction(int n) = 0;
};

And then implemented them:

class CObject : public IObject
{
int AFunction(int n) { return n+1; }
};

This way I can design objects that reside in different DLLs or whatever without having to worry about being COM-compliant.

And just couple days ago, I wrote a tetris-clone that just used normal C++ classes. I haven''t done that in a really long time (instead writing using that "interface" stuff), and wow, the simplicity was very nice. I think in future games I''ll just use C++ classes with some virtual functions, kinda like MFC. That way I can extend and still keep things simple and easy to follow.

I agree with mutex completely, just use your standard OOP design knowledge and create you virtual functions. You''ll still have the same major advantage of COM (having something that plugs in exactly where it''s supposed to with only improvements), but your code will be overall less complex, easier to read (I''ve noticed that COM branchs stuff out too an almost bewildering level), and still completely functional.

As for your behaviorial COM idea, I wouldn''t really go for that approach for AI, although it is very seductive. A game where the behavior could be plugged in. Nice, but once again, you could just use a DLL and a virtual function as part of your inherited class.

I absolutely agree that using pure abstract interface classes and simple DLL registration is probably better than going the full COM route. One of the coolest features of COM is its immediate relative, DCOM (basically just COM over the wire). Remoting interfaces becomes fairly complex if you try to roll your own using straight C++ and UDP/TCP. The Unreal engine, via UnrealScript, actually has its own RPC mechanism (the simulate modifier for example).

You could actually write your own class/method call remoting architecture specifically for games but that would require a LOT of development work.



Dire Wolf
www.digitalfiends.com