Hi all I guess I'm another fan of the arising game programming paradigm of Component Object Game Systems mentioned in resources such as these: - Scott Bilas' great article "The Continuous World of Dungeon Siege" (which might have started a few things). Unfortunately Scott canceled his old account and hasn't rehosted the article on his new webpage yet: http://scottbilas.com/ - Evolve Your Hierarchy - GameDev Topic: Is the Component Object Model Really Worth it? I want to create a game engine system for simulating multiple old-style pen & paper role playing games. First with text- or just 2D output, eventually with full 3D output. Naturally with physics simulation, a procedural universe, etc. :-) I'm going to need *modularity* in big scoops. That's why I'm diving into the topics of plugins and plugin architectures right now. Continuing this thought, not only putting game objects into a plugin, but entire subsystems of the engine core quickly demands implementing some kind of standards for interfaces with which plugins, subsystems, game objects, renders, etc. communicate. One such standard is Microsoft's COM (Component Object Model). Has anyone ever considered using COM to create a very large and complex game architecture (that should last for a long time)? I don't know anything about COM yet, except that it is an interface standard. Are there any people here who know COM well? What are your thoughts on using COM to create a big game engine architecture? Regards, Mark

Quote:Original post by Codeka
I used quite a bit of COM in my previous job. Personally, I wouldn't recommend it unless you didn't have a choice...

Uhh.. Is it that bad?
Or just that complicated? Why not?
Did you use it for game coding? Perhaps it's more appealing when you can use the standard for a new and exciting game idea than for a word processor?
;-)

Quote:Original post by Codeka
My personal choice would be C# or Java, Python or something like that.

Yea, actually Java was recommended to me for my idea (MRPGS). But seeing that most important games, apps and standards are in C++ I figured I shouldn't try something new in those regards also. Plus I'd have to learn the language(s) first. Not that I wouldn't do that if I saw the benefits (after all, I learned C, C++ and Windows32 JUST for my idea so far), but I have worries about speed, not finding people participating and other things when not using C++. I might have to revise that decision, but that would be a very long discussion I'm afraid.

Quote:Original post by Codeka
Plugin architectures in C++ are difficult (you've either got to write it in pure C or use something like COM that forces an ABI on you).

Difficult, yyees! I've noticed: Some General PlugIn Questions
What's so bad about having an ABI forced upon you? Particularly in the case of COM?

Quote:Original post by Codeka
C#, for example, has a lot of features that make pluggable architectures really easy: powerful reflection, sandboxing, simplified memory management.

I've never considered C# very seriously. What is the reason then that most games are not programmed in C# but in C++? And wouldn't those reasons apply to a project like MRPGS as well?

Quote:Original post by Codeka
Oh, and Microsoft's COM is actually unrelated to the entity/component system you've linked to in those links.

Uh, yea, I know. Only VERY remotely: Abstraction, compartmentalization, and reusability. I think that's one motivation for game object component systems AND for plugins. ;-)
And perhaps the fact that a component game system is likely to get complicated and big and thus would profit of longest possible reusability. And that in turn calls for plugins, as much as possible, thus a standard for plugins (make your own or use COM?).

Regards,
Mark

Don't get too hung up on the "component" part of the "Component Object Model" name, it really has nothing to do with components in the sense you're talking about (an Entity/Component design pattern).

One of the main reasons for the existence of COM is to facilitate inter-process communication, and as such it has a *lot* of baggage attached to it that is of absolutely no use to you.
Baggage both in terms of bloat, and in terms of complexity to work with.

You will be much *much* better off implementing your own system.

Yeah, I know COM and use COM a lot, since i developed quite a few DShow components and nope, I would not recommend COM. Its a large overhead, it is complex, it doesnt comply with C++ standard rules and best practices. Its not platform independent. It has dependencies to libraries you dnt want to be dependent on. COM has its use- that is developing components for DirectShow, MS Office, OS components and a few other things. But I would definetly not use it in a game.
Rolling your own pluginsystem for pure C++ that is platform independent is not that big of a deal. Can be done from the scratch having all whistles and bells in approx. 2-3 weeks. And then it does exactly what u want it to do.

greets

If you need modularity, embed Lua, Python or &#106avascript into your application. All great, flexible languages.


The "component" in COM has absolutely nothing to do with components in likes of Dungeon Siege - it's just the same name.

Component/container or entity models are about composition over inheritance. Instead of having deep hierarchy, objects are organized as collections of functionality. This can then be implemented in many ways.

Quote:Are there any people here who know COM well?

Yes. And this knowledge costs a lot of money at consultancy rates. It's dated, MS-specific technology, and as such in high demand for legacy software.

Open alternative is CORBA, ZeroC's Ice is lightweight CORBA equivalent. The emphasis of COM is interoperability.

Quote:What are your thoughts on using COM to create a big game engine architecture?

Head, gun and bullet come to mind...

Hey!

Thanks guys for all the answers! :)

Quote:Original posts by different users
Don't get too hung up on the "component" part of the "Component Object Model" name, it really has nothing to do with components in the sense you're talking about (an Entity/Component design pattern).
...
The "component" in COM has absolutely nothing to do with components in likes of Dungeon Siege - it's just the same name.

Yea, yea, got it! :) I know!
I state my reasons for bringing the two into connection with each other at the end of my second post. Sorry for the confusion and not being clear enough:
I know "Component" in Microsoft COM and "Component" in "Component Game System" are NOT the same thing. However, I'm interested in BOTH because I do see a connection, even if perhaps only remotely: Abstraction, compartmentalization, and reusability. I think that's one motivation for a Game Object Component System AND for plugins / Microsoft COM. :)
I think the fact that a Component Game System is likely to get complicated and big and thus would profit *A LOT* of longest possible reusability makes it an especially good candidate for update-able subsystems, objects, etc. And that in turn calls for plugins, as much as possible. And maximizing out on plugins, well, calls for a robust plugin-system and that in turn for robust interface standards. And reading the first few pages of an elderly second-hand book I got (Inside COM) it seems like COM is exactly the product of quite a few years of trying to create just that by Microsoft.
Keep in mind, I'd like to build the entire system pretty much with plugins! Engine core, physics sim., graphics, AI, EVERYTHING! ;-)
So fire-proofed interface standards seem important and a "head-start".
Now if you guys tell me there are better alternatives to COM, I'm all listening!

Quote:Original post by cruZ
I would not recommend COM. Its a large overhead, it is complex, it doesnt comply with C++ standard rules and best practices. Its not platform independent. It has dependencies to libraries you dnt want to be dependent on.

O.K., I'm afraid that's the kind of info I needed. I guess it won't be COM then.

Quote:Original post by cruZ
Rolling your own pluginsystem for pure C++ that is platform independent is not that big of a deal. Can be done from the scratch having all whistles and bells in approx. 2-3 weeks. And then it does exactly what u want it to do.

To build something really proper yourself doesn't seem such an easy chore. I read this article by Gigi Sayfan which tries just that: Building Your Own Plugin Framework
Check it out. It's a long, complex but interesting read! To me this is not trivial at all. And it's not even independent either, it uses parts of the Boost and parts of another library (Apache?).
Of course there ARE much simpler systems, just not with the same robustness and features. BTW, does anyone know a good book on the subject of creating your own plugin-system? I am willing to learn how to roll my own, but that seems like a pretty big hill to tackle, at least bigger than using an existing standard such as COM. But if there's really nothing proper out there I guess it might be worth it in the long run as plugins for everything is a very important aspects of my project.

Quote:Original post by Antheus
If you need modularity, embed Lua, Python or &#106avascript into your application. All great, flexible languages.

And what's the cost / downside of that? Can I use that to plugin C++ objects at run time?

Quote:Original post by Antheus
Open alternative is CORBA, ZeroC's Ice is lightweight CORBA equivalent. The emphasis of COM is interoperability.

Thanks, I'll check out COBRA and ZeroC's Ice. But "interoperability", isn't that EXACTLY what I need if I want to load engine subsystems such as physics simulation, graphics renderer, AI, etc. as plugins (at run time) and perhaps later even add additional new subsystems? "Interoperability" seems very important to get everything to work together flawlessly.

Quote:Original post by Antheus

Quote:What are your thoughts on using COM to create a big game engine architecture?

Head, gun and bullet come to mind...

:))) That's what I call clear text! :)

Greetings,
Mark

Quote:Original post by Markie
Keep in mind, I'd like to build the entire system pretty much with plugins! Engine core, physics sim., graphics, AI, EVERYTHING! ;-)

So fire-proofed interface standards seem important and a "head-start".
Now if you guys tell me there are better alternatives to COM, I'm all listening!

Unreal engine? Unity3D?

Quote:Thanks, I'll check out COBRA and ZeroC's Ice. But "interoperability", isn't that EXACTLY what I need if I want to load engine subsystems such as physics simulation, graphics renderer, AI, etc. as plugins (at run time) and perhaps later even add additional new subsystems?

You still misunderstand what Component/container designs are used for. They have nothing at all with "Evolve Your Hierarchy" article. The article explains the simulation update model and class organization.

And if you want Dungeon Siege like plugin system, use a dynamic language like C# or embed one of scripting engines mentioned above.

Quote:"Interoperability" seems very important to get everything to work together flawlessly.

COM-like systems are obsolete today. They are simply not needed anymore since languages, virtual machines and services provide same thing, but consistently and in a natural way.

All the systems mentioned above were created long before managed languages took over the development, and do not really offer anything of value for your particular intent. C#, for example, provides everything needed for this purpose out of box.

Never use Microsoft COM. Ever. It really is that bad.

One last question, why do u need to be that flexible? The purpose of using a pluginsystem is to be able to dynamically add new features to an already deployed system. Usually in a scenario where it is not an option to redeploy or update that system. A second scenario i can think of is to enable third party users to add functionality to your program without having your source. A third one could be, that you have a system that is so big, that it needs days to recompile after a interface break in one of its libraries. Thinks twice, do u have one of these scenarios? Otherwise u dont really need a pluginsystem. Breaking down your program into normal dlls is fine in 99% of all cases.

greets.