I've been reading about Unreal Engine (for no particular reason except 
I'm in the middle of an Unreal game).

I was wondering, will there ever be the Ultimate Game Engine, the one 
where you could implement essentially any FPS-style model-the-real-world 
type game more easily than rewriting your engine in a general purpose 
language?

What's missing to make that happen?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I was wondering, will there ever be the Ultimate Game Engine

  That's like asking if there will ever be the ultimate renderer.

  Technology progresses and game engines must keep up. Some game engines
implement some new features well, others not so well and yet others not
at all. It's always a choice. Even if there was a game engine which
supported *all* possible features achievable with current hardware,
it would become old in 5-10 years. It's a question of whether the
authors of the game engine can keep up with technology.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I was wondering, will there ever be the Ultimate Game Engine
> 
>   That's like asking if there will ever be the ultimate renderer.

Sure. Your eyeballs. :-)

>   Technology progresses and game engines must keep up. 

Of course. Maybe I phrased the question wrong.

What do you think of a game engine possibly being feature-complete? 
Obviously, when new hardware comes out with (say) better lighting and 
shadows and such, the game engine would be upgraded to account for that. 
But I don't think you'd necessarily need to upgrade the games to account 
for that. And once the engine can render in realtime, something so 
realistic you can't make it *look* noticably more realistic, the 
incremental cost of building a better renderer might be not worth the 
cost of doing so.

> It's a question of whether the
> authors of the game engine can keep up with technology.

That's kind of what I was considering investigating with the question. 
I.e., not so much "when does development stop", but "what features are 
lacking to make the perfect game engine?"  And I don't mean "engineering 
trade-offs" due to commodity hardware being too restricted, but stuff 
that just hasn't been written at all.  If you could combine 
Black&White-style scaling with DOOM3-style lighting and still get the 
performance, what would be left to solve rendering-wise?

For example, a while ago, one might say "sucky physics". This seems to 
have been pretty well solved.  One might have said "difficult to write 
online versions". This is obviously either solved or relatively simple 
to solve, and getting simpler as one can count on more bandwidth.

Some hardware advances will make for some fairly incompatible changes.
Obviously, when new stuff like full-body VR suits come out, the game 
engine will have to change drastically to take advantage of it.

Just as obviously, NPC AI isn't anywhere near what you'd call "the best 
we can imagine doing".

What's left to solve?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Of course. Maybe I phrased the question wrong.

Or, to ask it yet another way, are there games which, by their very 
nature, would be difficult to put in the same game engine?

Obviously, tetris and solitaire and minesweeper would be harder to code 
in the id engine than just writing them by themselves, for example.

So how far apart can two games be and still be reasonably in the same 
engine?  Could you put Thief and Halo in the same engine realistically? 
Are there features of games that are incompatible with features of other 
games?

Obviously not, or you couldn't play them on the same machine. But how 
close to the metal do you have to get to merge them? How abstract and 
powerful can your game engine be while still supporting everything 
someone might want to do with a minimum of low-level on-the-metal code?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

"Darren New" wrote:
> So how far apart can two games be and still be reasonably in the same 
> engine?
>
> how close to the metal do you have to get to merge them? How abstract
> and powerful can your game engine be while still supporting everything 
> someone might want to do with a minimum of low-level on-the-metal code?

The whole idea of making a game engine that fits all games is not a very 
good one, IMHO. One game might depend heavily on physics while another 
doesn't use physics at all. The solution? Separate the physics engine from 
the rest, while still making it easy to integrate the physics engine with 
the rest of game engine.

Similarly, make the AI engine as a separate engine that can easily be 
integrated with the rest. And - this is one of the interesting points - do 
the same for the graphics engine. And the sound engine.

Once you have different part of the game separated into different engines, 
that can easily be integrated with each other, you have great flexibility 
combined with huge ease of use compared to making everything from scratch. 
You can also easily change just the sound engine to a different sound engine 
or similar with the other engines your game use, if you find out that it is 
desirable.

While some game engines are all-in-one package, there are many games today 
that are made from the principle described above, and you CAN find separate 
graphics engines (like OGRE), sound engines (like OpenAL), physics engines 
(like Newton) and AI engines (I only know of commercial ones).

Rune

Post a reply to this message

Rune wrote:
> The whole idea of making a game engine that fits all games is not a very 
> good one, IMHO. One game might depend heavily on physics while another 
> doesn't use physics at all. The solution? Separate the physics engine from 
> the rest, while still making it easy to integrate the physics engine with 
> the rest of game engine.

Fair enough. On the other hand, since it's more a thought experiment, 
having a bunch of chunks of loosely coupled technologies and an 
overarching way of putting them together could be considered "one 
engine" for the purposes of this discussion.  Like, already, most 
engines don't do the mesh editting, as far as I can see. If you can plug 
it in and it's pretty seamless, then it's just another class of objects 
in the engine or something.

I admit it's a pretty vague question, more something to start thinking 
about than something that would have an answer.

So what bits aren't done yet?  What plug-ins would you want available?

And what's a good tutorial on the state-of-the-art of "AI" in game 
engines? I look at the unreal engine, and from what I've read so far, 
"AI" seems to imply "figure out what direction the player is from here, 
and figure out how to get there."  Not especially difficult AI. What 
sorts of things do "AI" programs in games really do?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Darren New wrote:
>> Of course. Maybe I phrased the question wrong.
> 
> Or, to ask it yet another way, are there games which, by their very
> nature, would be difficult to put in the same game engine?
> 
I think so, yes. Everquest, Halo, Neverwinter Nights 2, Homeworld 2.
Even just combining the scale of Homeworld 2, which allows you to zoom
in on a single ship or zoom out to see a hundred ship, with something
like Neverwinter Nights 2, which has occasionally has some really good
lighting effects, would either make an online game unplayable or require
tons of work with predicting what the user will do next so that the lag
isn't as dangerous. That might work in a slower paced game like
Everquest, but in Halo it would never fly with the players.

> Obviously, tetris and solitaire and minesweeper would be harder to code
> in the id engine than just writing them by themselves, for example.
> 
> So how far apart can two games be and still be reasonably in the same
> engine?  Could you put Thief and Halo in the same engine realistically?
> Are there features of games that are incompatible with features of other
> games?
> 
> Obviously not, or you couldn't play them on the same machine. But how
> close to the metal do you have to get to merge them? How abstract and
> powerful can your game engine be while still supporting everything
> someone might want to do with a minimum of low-level on-the-metal code?
> 

I think it is more of the developers having to decide between learning
one engine and modifying it to only do what they need as fast as they
need it to, vs building one from scratch that does exactly what they
want. Some games really don't need complex physics, so either the devs
need to re-write part of the engine or the engine will need to provide
the option to turn simple physics on. The same applies to various parts
of the lighting system. Add in various 'middleware', tree software like
SpeedTree or a modeler that can take advantage of all the features that
the engine provides, and the code base would be pretty unmaintainable in
my opinion.

I don't doubt that it could be done, but could it be done in a way that
would be easier for the game developers to use then it would be for them
to create their own? And could it be sold cheaper then developing a new
one with just certain features?

Post a reply to this message

"Darren New" wrote:
> I admit it's a pretty vague question, more something to start thinking 
> about than something that would have an answer.
>
> So what bits aren't done yet?  What plug-ins would you want available?

It's a bit fuzzy. Let's take rendering engines as an example. Let's say we 
have the engines A, B and C. Each of them support a set of features, 
including state-of-the-art features, but none of them have it all. So if you 
need *all* state of the art features in your game, no rendering engine 
exists for that. However, some of the engines may come with source code, and 
there's a good chance that extending one of those to include the missing 
features will be less work than making a whole new graphics engine from 
scratch.

> And what's a good tutorial on the state-of-the-art of "AI" in game 
> engines?

You don't need a tutorial for that; you need a bookshelf. There are few 
completely new techniques used in state-of-the-art AI - rather, it's old 
techniques that have been extended, recombined and made more advanced to a 
very high degree. This means that it's not very easy to summarize.

> I look at the unreal engine, and from what I've read so far, "AI" seems to 
> imply "figure out what direction the player is from here, and figure out 
> how to get there."

To a high degree yes, but it's also:
- how to attack the enemy while keeping oneself in minimum danger (seeking 
cover)
- how to cooperate to best take out the enemy while not getting in each 
other's way
- how to percieve and correctly use the environment, like elevators, 
sidewalks, terminals, cannons...

...and that's just in FPS-games. These task sound simple, but in reality 
they're far from "not especially difficult".

> Not especially difficult AI. What sorts of things
> do "AI" programs in games really do?

In games like Oblivion and Grand Theft Auto, NPC's must evaluate their needs 
and plan ways to satisfy them - like go to a shop and buy some food, then 
return home, sit at your table and eat the food. If the shop keeper has been 
killed, another shop must be found - or there is the option of stealing 
food. Every decision must furthermore be based on the NPC's knowledge of the 
world, which may be outdated. An internal model of the world must be kept in 
the NPC's memory, so it doesn't seem to know things it isn't supposed to be 
able to know.

Other types of games have completely different requirements for AI. For 
example race-simulations and fighter games.

Rune

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:47389a96$1@news.povray.org...


> Like, already, most engines don't do the mesh editting, as far as I can 
> see.

    I don't know about other engines, but CryEngine2 now has a basic mesh 
editor within the program. I say basic, but it may not be, it 'looks' basic 
to me.

> So what bits aren't done yet?  What plug-ins would you want available?

     I'll think about that one after I've played the full Crysis game...  ;)


>
> And what's a good tutorial on the state-of-the-art of "AI" in game 
> engines? I look at the unreal engine, and from what I've read so far, "AI" 
> seems to imply "figure out what direction the player is from here, and 
> figure out how to get there."  Not especially difficult AI. What sorts of 
> things do "AI" programs in games really do?

    Well, in the Crysis demo, if you shoot at a grunt from a mediocre 
distance, say, 300 to 500 yards(?), you'll have a hell of a job to kill him 
through your 'scope as he strafes from side to side rather than running for 
the hills crying for Mum... ;)  Seriously, I think the guys at Crytek have 
looked into this side of it more compared to FarCry and perhaps other 
companies games too.

     Can't wait for the Full to see what really happens. Four days? WooHoo! 
:)

   (Check out their editor when it comes out Darren, and see how they do it, 
it's just brilliant! Unseriously buggy, (everything works), but brilliant!)

       ~Steve~



>
> -- 
>   Darren New / San Diego, CA, USA (PST)
>     Remember the good old days, when we
>     used to complain about cryptography
>     being export-restricted?

Post a reply to this message

Rune wrote:
> It's a bit fuzzy. Let's take rendering engines as an example. Let's say we 
> have the engines A, B and C. Each of them support a set of features, 
> including state-of-the-art features, but none of them have it all.

Sure. Nothing but economics stops someone from putting them all in, 
right? Economics and processing power?

> This means that it's not very easy to summarize.

OK.

> To a high degree yes, but it's also:
> - how to attack the enemy while keeping oneself in minimum danger (seeking 
> cover)
> - how to cooperate to best take out the enemy while not getting in each 
> other's way
> - how to percieve and correctly use the environment, like elevators, 
> sidewalks, terminals, cannons...

Ah, OK. I guess that makes sense.

> ....and that's just in FPS-games. These task sound simple, but in reality 
> they're far from "not especially difficult".

No, actually, it sounds pretty visciously difficult to get right, to me. :-)

> In games like Oblivion and Grand Theft Auto, NPC's must evaluate their needs 
> and plan ways to satisfy them - like go to a shop and buy some food, then 
> return home, sit at your table and eat the food. If the shop keeper has been 
> killed, another shop must be found - or there is the option of stealing 
> food. Every decision must furthermore be based on the NPC's knowledge of the 
> world, which may be outdated. An internal model of the world must be kept in 
> the NPC's memory, so it doesn't seem to know things it isn't supposed to be 
> able to know.

Hmmm. Yah, I can see that, where you have something more than what you 
get in (say) Half-life in terms of plottiness. :-)

> Other types of games have completely different requirements for AI. For 
> example race-simulations and fighter games.

Certainly.  OK, I guess all that makes sense.  Thanks!

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message