The Ideal Game Engine

[DudeMiester]

I'm just wondering what developers here would imagine as their ideal game engine, including graphics, game play, AI, networking, resource management, etc... By this, I don't mean particular features, but from a usability point of view. I'm talking about a highly extensible system, in which the expression of one's ideas flows like water.

Generic programming should be used to the extreme, of course. In this sense, be free to even imagine modifications to the language.

If there is a fairly cohesive standpoint, then I may attempt to implement something like it in my spare time. After all, I have significant experience in generic and concurrent programming, at least with C++.

 

[Razor1]

no such thing as an Ideal Game engine at least not yet. Each engine is made for one specific game, each engine has limitations based on the goals of the game it was built for.

It would be nice if there was an engine that had all capabilities for lets say an RTS/RPG/FPS/3d person/underwater or boat race game/car game/flight simulator. But by the time a developer makes all the necessary additions for such an engine it would be time to build a new one or build on concurrent. Its just easier to make an engine based on the game the developer is going for then when its licenseed let others fix the anything else. Usually if there is any modification to the source code of the engine that code has to be returned to the licensure of the engine anyways.

 

[DudeMiester]

Yes, but with generic programming techniques you can write all those modules as separate entities that seamlessly integrate if desired. However, this requires a certain cohesive system on which everything is built.

For example, the graphics engine can have many techniques, added and mixed freely, but a centralizing scene graphs, compositors and optimization systems are necessary. Even then, so long as there is a standard generic interface system, these components can be dropped in and configured automatically.

I suppose then, the ideal engine isn't so much of an engine, but an inter-op standard. Like a set of general idioms and interfaces that allow each module written in this system to understand each other. The C++ STL is somewhat like this I guess.

 

[ERP]

Yes, but with generic programming techniques you can write all those modules as separate entities that seamlessly integrate if desired. However, this requires a certain cohesive system on which everything is built.

For example, the graphics engine can have many techniques, added and mixed freely, but a centralizing scene graphs, compositors and optimization systems are necessary. Even then, so long as there is a standard generic interface system, these components can be dropped in and configured automatically.

I suppose then, the ideal engine isn't so much of an engine, but an inter-op standard. Like a set of general idioms and interfaces that allow each module written in this system to understand each other. The C++ STL is somewhat like this I guess.

There is no such thing as ideal in this context.
There is no right way to write a scenegraph, or even what ones responsibilities should be?
It gets evn more fuzzy when you get to game level constructs, should you aggregate or inherit, should different objects be different classes or just variations on a single class?
How do you deal with collision with terrain?
Don't even get me started on resource management, or memory allocation policy.

These are retorical questions I have strong views on all of them and in somecases the views vary based on what game I'm writing. You'd be hard pushed to find consensus on good game engine architecture even among those of us who've been doing it since the 80's.

I'd even change the engine architecture based on team size, and makeup (experience).

FWIW IMO the engine portion of it is easy (relatively speaking) the tool side of it is an enormous challenge.

When I'm extremley bored I work on an engine at home, I haven't updated my webpage in a while.

 

[DudeMiester]

I wouldn't aggregate or inherit. Currently, I'm working on a generic programming system where you can create a class that analyzes it's context at compile time and configures itself accordingly. Thus, programming a construct is reduced to stating the characteristics you desire it to have, then the bits and pieces will put themselves together. Perhaps you'll have to specify a thing or two, but for the most part it should be automatic. Essentially, one constructs a web of conceptual relationships.

Thus, the game engine would be a library of such generic concepts that the programmer pulls from as desired. In this way, programming is simply a matter of expressing the raw concepts and relationships imagined in your mind, instead of having to flesh out tons of extra details just to integrate your ideas. The problem is, of course, knowing what these concepts are, so that the library can be created.

I truly believe that this problem of necessary redundancy and repetition is not inherent, but rather a product of incomplete programming paradigms. Moreover, I'm pretty sure I've solved that issue.

 

[Graham]

The more generic you make your engine, the less you are making an engine.

Saying that an engine should accept modules for whatever the person using it wants, is like saying 'here is a car, but you must provide the motor, chassis and wheels'. Of course you could go ahead and write all those modules yourself, but then your engine is 4 million lines of code, and still is useless for that random person who is making a baking RPG. *cough*

I had amazing plans to make my own awesome engine. But it ended up like a higher level directX. It's still good (in my opinion) and I'm happy with it, but to go where I wanted I then had to make 'engine 2' which sits atop it.
The problem with that design is that you can get so much abstraction that one tiny bug in the lowest level can cause absolute hell to the top levels. Consider multithreading for example....

 

[DudeMiester]

No, not like that obviously. More like, "Here's your car. Choose the engine, chassis and wheels, and we'll have it done in a few minutes."

I just want to know what engines, chassis and wheels people want, then I'll program a system smart enough to put it together by itself. Car's are mostly built by robots these days anyways.

 

[ERP]

I wouldn't aggregate or inherit. Currently, I'm working on a generic programming system where you can create a class that analyzes it's context at compile time and configures itself accordingly. Thus, programming a construct is reduced to stating the characteristics you desire it to have, then the bits and pieces will put themselves together. Perhaps you'll have to specify a thing or two, but for the most part it should be automatic. Essentially, one constructs a web of conceptual relationships.

Thus, the game engine would be a library of such generic concepts that the programmer pulls from as desired. In this way, programming is simply a matter of expressing the raw concepts and relationships imagined in your mind, instead of having to flesh out tons of extra details just to integrate your ideas. The problem is, of course, knowing what these concepts are, so that the library can be created.

I truly believe that this problem of necessary redundancy and repetition is not inherent, but rather a product of incomplete programming paradigms. Moreover, I'm pretty sure I've solved that issue.

You're kind of missing my point.
In any sort of real large scale app implementations directly impact interface, this is particularly true of games where performance is important. Whether or not I can load or unload an individual resource or I have to deal atomically with resource collections for example, requires any code dependant on the resource manager to do very different things.

Building from well defined replaceable modules is a no brainer, however, once you get above the base layer unless all your bottom level implementations have semantically similar interfaces, top level components become dependant on sets of core components.

You would be surprised how much different games vary in the solutions to apparently similar problems, resource management and the representation of a game level object being probably the most disparate. But it goes beyond that into diametrically opposed concepts like centralised vs decentralised ownership.

I've changed my mind on what good game architecture is inside the last 5 years and I've been doing this for 20+.

In the end you can build almost any game on almost any near complete set of functionality, but I don't believe there is an ideal, every combiknation of components leads to compromises somewhere.

 

[Graham]

No, not like that obviously. More like, "Here's your car. Choose the engine, chassis and wheels, and we'll have it done in a few minutes."

I just want to know what engines, chassis and wheels people want, then I'll program a system smart enough to put it together by itself. Car's are mostly built by robots these days anyways.

Thats exactly the problem though, and exactly what I was trying to say. No one person wants exactly the same thing, so if you wish to satisfy everyone, you need to provide for everyone. Otherwise things become so generic that you get to a point that to do something with the code, you have to just do it yourself.

I'm not saying it's an impossible task, or one that should not be attempted, but I qualify that with 'for a team of experts'. Game engines are spectacularly complex beasts, and in my view very little of that can be automated. Unreal3 would probably be the closest to a 'generic' engine out there, at least by what epic claim it can do. However it's still not a drop-in engine, if you want something slightly different done, chances are you will have to script it yourself. A goal of UE3 is to make it easy to do that scripting (at least from what I can tell).

Another example:

For a first person shooter perspective. You could have one client wanting to use BSPs, one wanting Portals. There are many ways to satisfy these demands, here are some examples:

Engine.UseBsp = true;

Engine.SceneType = SceneTypes.BSP;

Engine.Scene = new BSPScene();

They each get more abstract and generic. The first is the fastest, and least code. However it's also the most limited. The second has room for expansion, but would get ugly fast. The last is the most abstract, and also the slowest, and most bloated. Also, the last implies that the *Scene classes have access to a lower level API provided by the engine, hence more abstraction.

It's a simple example but I hope it makes sense.
Each of them still falls over when a new client comes along and wants occlusion culling based terrain. Either you must provide the support, or they must implement it themselves. (let alone the cases where someone wants multiple scenese, scenes within scenese, partially shared scenes, etc)