I recently picked up a book on ATL and started learning about the basics of COM development. From what I've read so far, it seems that using COM to serve up a game engine within a DLL to a game executable is a feasible idea. Considering that you would have a well-known engine interface between the engine and the game, and that as the engine matures and adds features, the interface can be easily improved and used, I think it's quite possibly a working solution. You could then basically just distribute the DLL and the interface and new games could take advantage of the features by retrieving a newer interface from the DLL. I realize that DirectX is completely based on COM, but is COM a good idea for a game engine that overlays DirectX? Are there any significant disadvantages that would be suffered as a result other than the fact that it eliminates cross-platform code? Are there any well-known game engines that are currently based on COM? Thanks!
Crossbones+ - Reputation: 2345
Posted 10 June 2013 - 08:46 AM
I recently picked up a book on ATL and started learning about the basics of COM development.
Put the book down, and back away slowly.....
Considering that you would have a well-known engine interface between the engine and the game, and that as the engine matures and adds features, the interface can be easily improved and used, I think it's quite possibly a working solution.
Not with COM you can't. With COM you stick to a pre-defined rigid interface. As you add features to your engine, your support burden increases as you support this iteration, and all previously published interfaces. If you screw up one of your earliest interfaces, you'll be fighting that design decision for some time to come (and you'll have methods suffixed with '2', or 'Ex' in the case of the WIndows32 API).
You could then basically just distribute the DLL and the interface and new games could take advantage of the features by retrieving a newer interface from the DLL.
You could, but they you'd have to start adding a tonne of versioning and DLL validation checks to your code. You'd also have to validate that each of your DLL builds in binary and backwards compatible with the previous versions. It would be far too easy for this to go wrong in practice. This approach *might* make sense if you're in the business of writing operating systems (or middleware at an extreme push), but it's not going to be that useful for a single game release. Just ship your game binaries in a single installer, rather than having an 'Engine V1' + 'MyGame' installers.
Edited by RobTheBloke, 10 June 2013 - 08:46 AM.
Moderators - Reputation: 25435
Posted 10 June 2013 - 12:22 PM
You certainly CAN do it. It is a thing that can be done. But that does not make it a good idea.
Programmers deal with COM all the time. Game programmers are most familiar with Direct3D and it's family of interfaces.
Every time they want to change something, they need to:
1) Provide an entirely new interface to get access to all the new sets of features. Releasing D3D12 means you have a brand new family of interfaces, rather than 11+12.
2) Preserve all backward compatibility with every prior version. Releasing D3D12 cannot break D3D3, or D3D5, or D3D6, or D3D7 or...
Similar things are true with other systems that expose COM interfaces. You can run MS Office through COM automation, just be careful that you pick a version that actually matches what is installed. When a new version comes out you need to update your interfaces, and they tend to change in breaking ways.
If you want to release your game as a COM object you can. Maybe you can embed your game in a word document or something. It doesn't seem like it would gain you very much, but it a real thing that can be done, and you can do it if you want.
Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.
Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.
Crossbones+ - Reputation: 1679
Posted 28 June 2013 - 05:14 AM
Why would you possibly want to do that?
Making a game is hard enough as it is, without being deliberately masochistic and using stupid APIs.
COM doesn't give you anything unless you need to interact with something else which depends on it. While you don't need to do that, you don't want to use COM. Seriously.
And even if you do eventually need to make it as a COM class, then you can probably stick some kind of horrible wrapper around your "real" code.
* You don't want to
* You don't need to
* Even if you did need to, you don't need to, YET