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
