Component Game System - Using Microsoft COM?

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

My personal choice would be C# or Java, Python or something like that. 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). C#, for example, has a lot of features that make pluggable architectures really easy: powerful reflection, sandboxing, simplified memory management.

Oh, and Microsoft's COM is actually unrelated to the entity/component system you've linked to in those links.

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.<br/><br/><br/>The "component" in COM has absolutely nothing to do with components in likes of Dungeon Siege - it's just the same name.<br/><br/>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.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->Are there any people here who know COM well?<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->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.<br/><br/>Open alternative is CORBA, ZeroC's Ice is lightweight CORBA equivalent. The emphasis of COM is interoperability.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->What are your thoughts on using COM to create a big game engine architecture?<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->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.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->And what's the cost / downside of that? Can I use that to plugin C++ objects at run time?<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><i>Original post by Antheus</i><br/>Open alternative is CORBA, ZeroC's Ice is lightweight CORBA equivalent. The emphasis of COM is interoperability.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--> 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.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><i>Original post by Antheus</i><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->What are your thoughts on using COM to create a big game engine architecture?<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->Head, gun and bullet come to mind...<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE-->:))) That's what I call clear text! :)<br/><br/>Greetings,<br/>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.

Hi again!

Quote:

Original post by Antheus Unreal engine? Unity3D?

Both cost (I'm an "indie") and compatibility worries with the "Evolve Your Hierarchy" approach.

Quote:

Original post by Antheus You still misunderstand what Component/container designs are used for.

I think I disagree. But I digress... ;-)

Quote:

Original post by Antheus They have nothing at all with "Evolve Your Hierarchy" article.

I agree to 99%... ;-)

Quote:

Original post by Antheus The article explains the simulation update model and class organization.

That's right. I think it's even more than just a "class organization" though. It's whole new way of thinking, of representing the real world in C++ (classes, yes). - Or "new" to games at least - since a few years that is. But never mind, I think we agree on that.

Quote:

Original post by Antheus 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.

I wasn't aware of that as I don't know them. I guess I'll have to go study up on them then! (Hmmm... A pointer to real easy noob entry into the subject? :-)

Quote:

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

As said, I know neither, so I'd have to study up on your remarks and what they mean / how they might or might not be compatible with my plans. Thanks.
I have heard about C# though that it doesn't allow you to manage memory yourself. Is that correct?

Quote:

Original post by Antheus 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.

I disagree, some such systems might offer a lot, even if it's just for learning to write my own system. - That is, without considering managed languages. As said, I know nothing about "managed languages" and would probably have to learn or at least study up on them to see if they fit with my plans. Thanks a lot again for your input though! You knowing more about managed languages than me (obviously) gives me the impression I should consider your suggestions well. Thank you! :-)

BTW, I think COM is definitely off the table for me now. Even it might offer a few things which Microsoft had to pay dearly for to learn over many years, it's probably overweight indeed, not platform independent and a too complicated overkill for my needs. I might still read a little in the old book about it though, just out of curiosity - and perhaps to learn a few basic tricks / theory in case I DO decide on creating my own little system. :-)

Quote:

Original post by cruZ 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.

Hey! Why last question? So far this thread's open for discussion! ;)
No seriously: Yes, all three scenarios apply. - Well, that was a lie... Scenario number 3 doesn't apply yet, but it could eventually. I think I'll go for something in between a full plugin-system and just bare-to-the-bones naked Dlls. That way I can start little but shouldn't have to refactor too much sometime in the future. Compromise? ;-)
Can I ask a question back? What's the most important thing to do when programming something new (creating a program from scratch)?
My vote: Planning, planing ahead. Or at least trying to.

Regards,
Mark

I'd suggest only implementing what you have in mind for your first game (i.e. make a game, not an engine). This lets you follow the YAGNI principle -- if you don't need the functionality now, why implement it now?

Quote:

Original post by Markie Both cost (I'm an "indie")

They are both free. Check the license for fees related to releasing commercial projects.

Quote:

and compatibility worries with the "Evolve Your Hierarchy" approach.

When UDK was released, the landscape changed. That is not some hobbyst toy, but real world proven complete solution into which hundreds of engineer years went into and has delivered hundreds of AAA titles, which will likely be followed by thousands of indie projects.

It's one of those no contest scenarios where it simply isn't viable to compete with. At least as far as "low-level C++" engines go.

Especially due to:

Quote:

I'm going to need *modularity* in big scoops

Quote:

that should last for a long time

Quote:

calls for a robust plugin-system and that in turn for robust interface standards

Quote:

engine subsystems such as physics simulation, graphics renderer, AI, etc.

Quote:

Original post by Markie 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? ;-)

For what I know the selling argument for COM is that it allows distributed computing, language_independent binary interface and among other things that (supposedly) brings "ease" for backwards-version compatibility. I've heard of the (in)famous "dll-hell" but thanks God I have not had the chance to suffer it myself.

It is not bad at all. If you used Microsoft stuff and you liked it so far it is mostly implemented on it (and OLE).

I really don't think it would be "convenient" for straight-forward game development though, nor that anything that it offers would really bring any benefit for it.

Quote:

Original post by Markie Can I ask a question back? What's the most important thing to do when programming something new (creating a program from scratch)? My vote: Planning, planing ahead. Or at least trying to. Mark

Well, that is a science of its own ;). Nowadays agile software development should be chosen over the classic waterfall model. Especially if u'r not quite sure yet what the outcome should be and if there are lots of changes to be expected. Read more here: http://en.wikipedia.org/wiki/Agile_software_development . Usually u would start defining what u want to do with the piece of software. That is defining use cases. Then u would identify the components u need in that sw. Then start breaking down those components into handy pieces and write testcases for each one of them. The testcases u derive from your usecases. So u have now code to test your renderer, your network code, your AI and your sound server... Finally u can start thinking about putting everything together into one application. -> Congrats, u have built the first prototype of your application! After that u usually start all over again. That is called your second iteration. Repeat that n times, till u think your application is now worth a release. Thats called iterative sw development. That's it in short. There is tons of books about that topic, so u'll find plenty of information on that topic.

Quote:

Original post by Markie I have heard about C# though that it doesn't allow you to manage memory yourself. Is that correct?

It allows you, if you really want or need to. But what do you want to spend your time on? Writing game-code or managing memory? Garbage collection and the like isn't a bad thing.

Quote:

I disagree, some such systems might offer a lot, even if it's just for learning to write my own system. - That is, without considering managed languages. As said, I know nothing about "managed languages" and would probably have to learn or at least study up on them to see if they fit with my plans. Thanks a lot again for your input though! You knowing more about managed languages than me (obviously) gives me the impression I should consider your suggestions well. Thank you! :-)

If all you have is a hammer, everything looks like a nail. If you're only familiar with one language, then it may seem that it's the best language for any given situation. But no single language excels in every area. Learning multiple kinds of languages and paradigms will make you a better and more productive programmer.

Quote:

Can I ask a question back? What's the most important thing to do when programming something new (creating a program from scratch)? My vote: Planning, planing ahead. Or at least trying to.

Research and prototyping. If you're not entirely unfamiliar with it, you can make some estimates based on what you know already. But planning isn't very useful if you're totally new to something, you will need to get at least a little familiar with the subject first.

Building an actual prototype will give you some more insight in to what kind of problems you're going to encounter. Research can show you what others did in a similar situation and what worked and didn't work for them. And of course, use common sense, and don't give in to feature creep and things like that. YAGNI is a good principle indeed. Don't waste time solving the wrong problems.

Hey guys! Thanks again for all the answers!
:)
I feel very honored to get so many well-meant replies!
Thanks!
What a cool place this continues to be! :)
(If only other forums on other topics worked so well... ;-)

Back to the subject:

Quote:

Original post by RobAU78 I'd suggest only implementing what you have in mind for your first game (i.e. make a game, not an engine). This lets you follow the YAGNI principle -- if you don't need the functionality now, why implement it now?

Eh, that's a little hard to explain. This whole thing is about making an engine, NOT a game. There are very many games out there already. And I'm very finicky about almost all.
Instead of just complaining, I'm trying to do better. The problem is, the days of pong and pac man are over. You can't write a good game all by yourself anymore these days. And often there isn't even a market for them.
I like turn-based RPGs. For instance like Jagged Alliance 2. Companies who produced such games won masses of awards (like SirTech) and almost all concurrently went bankrupt (like SirTech).
There's something to think about here. Something to think about very hard.
And something to think about today's top-selling empty teenie games with all graphics, whistles and bells and not much "feel" (O.K., there are exceptions, even an old fart like me (39) must admit.
It's this: Its JUST NOT WORTH it. - Financially.
That means what I want must be produced for free. No pay. That means I'm on my own or open source. If I'm on my own, I'll never finish. Which is the most likely scenario.
All the same, I want to DO something about the lack of games which *I* like. And just one additional title isn't enough for me (even if that alone already is way beyond what I could do all by myself with my remaining time).
So I put my mind to make something to produce MANY such games, an engine. :-)
That's certainly even a little more difficult, even more impossible in turns of remaining man-hours, but all that doesn't count. All that counts is that this is the only thing I can get my motivation up for enough to keep at it.

I say: If you make one game really really good, it's a pure WASTE in software development to simply *TRASH* the ENTIRE CODE after the game sold. But that's exactly what happened with my favorite games. They sold, went bankrupt, disappeared. Instead, code should be re-used. What's really needed is a (O.K., I know this doesn't exist and is virtually impossible, but one can try though) end-it-all engine that satisfies as many needs (for turn based RPGs) as possible. That way more such games should be producible than if every company bankrupts itself with the staggering man-hours in creating their ONE SINGLE game themselves.
It's just not worth it creating so much code and NOT using it for an engine, NOT re-using it. That's a waste. And that waste directly translated into MORE development hours per-title, less income, more bankruptcies, less turn-based RPG titles and less companies producing them.
So creating an engine, and NOT a game is what my project is all about. Right from the start. I never was interested in anything else. Life is too short as it is already.
Speaking of which... Time to stop here I guess.
So much "background ranting" for now...
;-)

Maybe I also missed your point:
I DO need a plugin-structure now. Or almost, as soon as I'm done planing the engine's main layout. The plugin-system will be a very central part of the engine as the engine itself should be updatable, modular and easily changable.
What I don't need now is a renderer. Or graphics. Or sound. Etc.
That's why I haven't even considered out-of the box famous stuff like the Unreal Engine, etc. Don't even know what it is really, except something that can probably be used to make very nice looking and fast first-person shooters.
But perhaps I don't know what I should about them...?

Quote:

Original post by Antheus [Unreal engine? Unity3D?] They are both free. Check the license for fees related to releasing commercial projects.

Alright, I'm sorry. I didn't know that. That's *VERY* cool indeed.

Quote:

Original post by Antheus When UDK was released, the landscape changed. That is not some hobbyst toy, but real world proven complete solution into which hundreds of engineer years went into and has delivered hundreds of AAA titles, which will likely be followed by thousands of indie projects. It's one of those no contest scenarios where it simply isn't viable to compete with. At least as far as "low-level C++" engines go.

I *never* thought that were "some hobbyst toys". Even if one doesn't prefer first-person shooters, anyone remotely interested in computer games knows (or should) "Unreal" has its name for a reason which is not just bluff.
I'm also aware that hundreds of engineer years probably went into such engines and perhaps I'll consider using them as a renderer. Or even for multiple things, physics, etc. But first I want to create a Component Object Engine (an engine where game object / entities are split into smaller component objects). And it's not even because I think that approach is the ONLY way to even remotely try to get near the versatility of playing an original pen & paper role playing game with real people, where the limitations of actions, quests and adventures were truly, only human imagination (at game play! :-). It's also because I need a component object based engine for simulating realistic distances (hierarchical coordinate systems).

No component object based engine, me no fun, me not work. It's that simple. ;-)

The Unreal engine truly is unreal amazing and fantastic. But it's not made for what I want, it's not my tool, my weapon of choice.
If you fly over my project description (www.mrpgs.net) you see things like the ability to simulate realistic distances, real stars in a night sky, nearly infinite view distances, and many other things which even an Unreal engine was not made to handle. At the same time, I'm willing to give up graphics almost entirely. Even real time. To begin, turn-based text output is FINE by me, IF it's realistic. I just *do* not think the Unreal engine was made for that.
And that in NO way is to say that the Unreal engine does not excel at what it does and what it was made to do. Can you see my point or have I perhaps missed yours?
Perhaps I need to tell a lot more about my project. There is some info in the link provided (www.mrpgs.net), but it's a little outdated. I'm more busy planning and developing new ideas and solutions right now, than with keeping the public documentation about it updated (with that you never know if anyone even actually reads it, so why invest the few man-years left into that... ;-) Besides, I'm behind schedule about 1 year already and I'm still in planing!!
:-O ;) [But for my philosophy, that's O.K., as I think that's most important.]

Quote:

Original post by owl For what I know the selling argument for COM is that it allows distributed computing, language_independent binary interface and among other things that (supposedly) brings "ease" for backwards-version compatibility. I've heard of the (in)famous "dll-hell" but thanks God I have not had the chance to suffer it myself. It is not bad at all. If you used Microsoft stuff and you liked it so far it is mostly implemented on it (and OLE). I really don't think it would be "convenient" for straight-forward game development though, nor that anything that it offers would really bring any benefit for it.

As said, I probably won't really consider really using COM. A few people who I think really know it did not recommend it for games-usage. But I will try to learn from it what I might need for creating my own little (tiny) plugin-system (I WILL try to start as small as possible with it). The entire concept is just amazing though. At least when it was still new: Assembling and re-using entire components which can "talk" with each other and be changed and updated independently. That's a powerful concept. Powerful in terms of what might become possible thanks to it.
Of course there probably are better alternatives today, but for creating your own (if I will), sometimes its good to learn from the beginnings.

Quote:

Original post by cruZ Well, that is a science of its own ;). Nowadays agile software development should be chosen over the classic waterfall model. Especially if u'r not quite sure yet what the outcome should be and if there are lots of changes to be expected. Read more here: http://en.wikipedia.org/wiki/Agile_software_development . Usually u would start defining what u want to do with the piece of software. That is defining use cases. Then u would identify the components u need in that sw. Then start breaking down those components into handy pieces and write testcases for each one of them. The testcases u derive from your usecases. So u have now code to test your renderer, your network code, your AI and your sound server... Finally u can start thinking about putting everything together into one application. -> Congrats, u have built the first prototype of your application! After that u usually start all over again. That is called your second iteration. Repeat that n times, till u think your application is now worth a release. Thats called iterative sw development. That's it in short. There is tons of books about that topic, so u'll find plenty of information on that topic.

Yup, that's interesting *shit* if I might say (?). There's a classic book to it too: The Mythical Man-Month. :)
I will be developing in iterative steps all right. I too believe that to be by far the best, even only practical approach. It's just that the entire engine will have subsystems which are plugins. Thus the plugin system will be before even the first iteration of ANY other subsystems.
As to Agile software development, that certainly sounds very interesting, however, I don't have a team yet. Once (or if ever) I do, I'll probably consider it. :)

Quote:

Original post by Captain P Quote: Original post by Markie I have heard about C# though that it doesn't allow you to manage memory yourself. Is that correct? It allows you, if you really want or need to. But what do you want to spend your time on? Writing game-code or managing memory? Garbage collection and the like isn't a bad thing.

No, it probably isn't. Point taken. However, I'd have to learn C# as well... (and that's another 2-6 months I guess?)

Quote:

Original post by Captain P If all you have is a hammer, everything looks like a nail. If you're only familiar with one language, then it may seem that it's the best language for any given situation. But no single language excels in every area. Learning multiple kinds of languages and paradigms will make you a better and more productive programmer.

Definitely!
It's just that I have sooo many things to consider learning also. It's hard to decide what to learn if you don't know it, you know? ;)
I guess I really SHOULD look at least into C# though. It's been recommended to me by several people now. I'll make a mental note to include that in my next shopping trip for "learning food". Thanks. :-)

Quote:

Original post by Captain P But planning isn't very useful if you're totally new to something, you will need to get at least a little familiar with the subject first.

Yes, chicken and egg problem. That's why nobody recommends starting with a huge engine. Everyone recommends starting with smaller projects. I have written some smaller software. One or two BASIC games, a few C programs, a pretty heavy weight PHP forum (and a content system) and a few other things.
The problem is: Time's short. And so is motivation. One must do what one is motivated to do. At least when not paid. And my kind of project IS NOT paid, that's the whole reason I must do it myself and can't leave it to big $ companies. If it would yield pay, they WOULD do it. Bioware DID Dragon Age after all, it's just not what I want (havn't played it yet, same "man-years left" problem again... ;-)

Quote:

Original post by Captain P Building an actual prototype will give you some more insight in to what kind of problems you're going to encounter.

Oh, I will. :-) A prototype that loads subsystems as plugins, and runs them, split up into 2 or more threads. The subsystems will be dummies first. And the multiple threads just for show off. Just to get into the dirty muck which I'll end up in playing with neck-deep in the end right away! :-)

Regards all and thanks again for the replies! :-)
Mark

To summarize, what you are looking to build is a sort of 'glue framework', right? Since even RPGs tend to differ a lot, it makes sense not to stick to one rendering or physics engine. So building a modular system seems the way to go.


You're making some wrong assumptions here and there, though. Time is short, that's right, but that's a poor excuse for discarding good advice. The reason why people recommend starting small and working your way up is because experience and knowledge are powerful tools. You're going to need those for the bigger projects. They're investments. Without them, you'll make things very difficult for yourself. I would even say that they're more important than the code itself - because they can produce that code.

You could, of course, spend your time writing an engine - only to find out that it doesn't solve the problems that actually matter while developing a RPG. It's a shot in the dark.

Or you could build a (basic) RPG - prototype style, quick'n'dirty - and find out what problems really need to be solved. Perhaps not what you had in mind initially, but it's a much more stable approach.


As for code reuse and going bankrupt, are you certain that not reusing code made those companies go bankrupt - or was it the other way around? Either way, nowadays there's a lot of code that can be reused, so for many programs and games you can mostly focus on glueing some libraries together and writing your game-logic. I'm not sure if your do-it-all engine is even all that practical given these circumstances. What I mean is, I can grab an engine like Panda 3D and a physics engine such as Bullet, and start building a game. There's a little glue code that needs to be written, there's the game-logic that I need to build, but those things are fairly game-specific. Where, in all that, does your framework solve any problems?


Bytheway, here's a suggestion: look into scripting languages like Python, Lua or Ruby. I'm using Python frequently for prototyping ideas, testing algorithms, building data conversion tools and even graphical editors. It sure beats C++ in terms of developer time, it's a lot easier to work with, even easy to learn. If time is a problem then scripting languages and their libraries are a must. Code reuse, remember? That counts for engines, but also for libraries and languages. :)

Postmortem:

Quote:

Original post by Markie Quote: Original post by Captain P Building an actual prototype will give you some more insight in to what kind of problems you're going to encounter. Oh, I will. :-) A prototype that loads subsystems as plugins, and runs them, split up into 2 or more threads. The subsystems will be dummies first. And the multiple threads just for show off. Just to get into the dirty muck which I'll end up in playing with neck-deep in the end right away! :-)

Actually I just noticed introducing 2 threads now is probably stupid. I haven't even fully designed the main engine layout yet. Introducing multiple threads at this stage is plain stupid. I need to design the engine first, at least with all important subsystems. Only then can I see what and even if some parts can be executed in parallel.

Sorry, I just had to correct myself on this.

Greetings
Mark