I believe that there is a large group of disgruntled indivuals out there that want to see things like this fail. I mean, this forum is GAMEDEV, and you're saying that the idea of creating a game engine for specific development is "retarded". I'd love to see you accomplish anything with that mindset. The point of the whole thing is that it isn't "retarded", it encourages problem solving, creative thinking, and teamwork skills. To see people with a positive mindset find things like this makes me very sick with disappointment. It's not uncommon though, how many wannabe movie companies never make it in the "real" industry? The number is probably similar to your list of game engines out there. When I started this process back in 07 I saw how there was alot of potential, and also alot of potential problems, but I always kept my goals in mind, and never used the excuse that my work and contribution wouldn't make a difference, because I know that it has. But this defeatist attitude that so many people share has to stop. I don't have the resources to organize bunches and bunches of people into specific groups. That would have to be a moderated effort supported by experienced people that had suceeded where so many fail and wish to extend to the hopeful game developers out thier thier nich for team organization.

True pioneers do what they do because they find satisfaction from it. Too many people work in this industry because they just need a job. For the love of god, don't join an industry because you want to make money. Do it because it's what you love to do, otherwise you'll just end up causing more harm than good. Everybody knows that.

you're saying that the idea of creating a game engine for specific development is "retarded".

Nobody said that.

We did however say that setting out to build a generic game engine is not a sensible endeavour for a loosely-organised team of hobbyists with no clear lead developer.

And not to harp on this point, but it's an especially bad idea for someone who is still stuck on OpenGL 1.

you're saying that the idea of creating a game engine for specific development is "retarded".

Nobody said that.

We did however say that setting out to build a generic game engine is not a sensible endeavour for a loosely-organised team of hobbyists with no clear lead developer.

And not to harp on this point, but it's an especially bad idea for someone who is still stuck on OpenGL 1.

I guess one could try to bring up the matter of how generic the engine is, and how tightly coupled the parts are.

for example, "sufficiently generic to implement games within a specific genre with a particular gameplay style" vs "sufficiently generic to handle multiple genres and gameplay styles".

likewise for coupling:

parts are sufficiently coupled that the engine is, for the most part, a unified entity;

vs, each component is largely its own library and almost functionally independent of the others, with some certain amount of high-level glue logic holding them together (treating each as a collection of APIs or similar).

depending on the desired level of "genericness", there is a large difference in terms of likely project complexity.

it is easier if focusing on a single genre.

going beyond this likely involves a tradeoff either between trying to make everything very loosely coupled and parts being interchangeable, or trying to address everything directly (this tends to quickly devolve into "there be dragons here" territory), and/or the thing starts looking more like the offspring of an OS and a web-browser, or ...

as for the OpenGL 1.x issue: yeah...

from my personal experience in these areas, one is probably almost better off having multiple rendering backends.

I had the misfortune of starting off mostly with a GL 1.x feature-set, and later expanding to use lots of newer features, ...

and now the renderer is sort of an awful mess with multiple interconnected rendering paths and some amount of #ifdefs for things like dealing with OpenGL ES and similar.

at some point, the thing may need to be broken up, and probably somewhat re-engineered (as-is, it is a bit absurd in many areas).

Who said anything about being stuck? And you seem as if you have some kind of resentment for Gl1, not to say that I don't agree with you, it's not particularly the most effective, or technologically advanced system, but it's the framework for all the other resources openGl has to offer. Besides, a good developer could use something like Gl1 and still make a great game, because it's not about making sure it meets the current standards. it's about creating a compelling experience that demands interactivity.

the fact that I refuse to use anything but openGL 1 until I have mastered it thouroughly

It was a tongue-in-cheek commentary on the idea of someone wanting to 'master' a 20 year old API.

Who said anything about being stuck? And you seem as if you have some kind of resentment for Gl1, not to say that I don't agree with you, it's not particularly the most effective, or technologically advanced system, but it's the framework for all the other resources openGl has to offer. Besides, a good developer could use something like Gl1 and still make a great game, because it's not about making sure it meets the current standards. it's about creating a compelling experience that demands interactivity.

a drawback here is that OpenGL 1.x and newer versions of OpenGL diverge sufficiently WRT how they behave (and what sets of API calls are supported, ...), that one is left essentially needing multiple versions of their renderer:

one to work well on older hardware (and some vaguely new but low-stat HW);

one to use newer features and work on newer hardware;

possibly one to deal with OpenGL ES.

while a person could just do a sole GL 1.x renderer, they may find:

it performs poorly on newer hardware (vs what is possible with a different rendering strategy);

it risks not actually working in some cases (such as those where many of the older API calls were dropped);

...

this results in portability either requiring an abstraction layer in the renderer (to support alternate targets), or creating a wrapper layer and partially emulating GL 1.x on top of newer or alternate GL versions (crufty and not terribly efficient).

You can find out which calls are obsolete and ignore them while seperating the renderer from the majority of the core game functions. The renderer and the hardware will always have to be updated, that's just the nature of the search for photorealism in 3d graphics. I would like to see more games re-made with updated graphics re-implemented on newer systems, like they did with halo. I know it's a complicated and expensive process, but if you really love to do this kind of stuff then it shouldn't be that big of a deal. Alot of people don't enjoy working with the resources and overcomming the obstacles because they're either too difficult or too complex. We shouldn't be spending all kinds of time worrying about rendering package backends, and all the intricacies of modern computer graphics. There are people that do nothing but that kind of stuff, and they've been doing it for years and know all the ins and outs. I don't claim to be a computer graphics genius, I just want to know the basics and be able to take an idea and turn it into a reality without too much of a struggle understanding obfiscated code developed by mad scientists spinning on gerbil wheels. Hey, that even gives me an idea for a game.