[photon137]

Very Beautiful! The demo has a nice Skyrim/LOTR feel to it and the lava flows were just gorgeous! If that lava flow generation is completely procedural then I'm extremely impressed.

Writing a highly parametrized engine like that with JIT script compilation is plain awesome!

[forrestthewoods]

There is no script. It's all done in C++ with the project broken up cleverly into DLLs which can be reloaded at run-time without interruption. And I believe the lava flow is done with animated meshes.

[photon137]

I thought Kismet was pseudo-script (albeit with a GUI).

Edit: http://www.unrealengine.com/features/kismet/

[forrestthewoods]

UE3 had Unreal Script which was a custom scripting language and that has been removed from UE4. Kismet is more data than script. There's no JIT-compilation.

[teamonkey]

To be clear, Kismet is a flow-based visual scripting language where you connect boxes together. In UE3 Kismet boxes are scripted in UnrealScript. In UE4 they are written in C++ and automatically reloaded when the code is re-compiled.

[barrkel]

I have mixed feelings about this. UnrealScript had a lot of interesting ideas; particularly its module system (a kind of sideways inheritance where you could override an ancestor in a package, but not have to override all the descendants to have them inherit the behaviour - really handy for third-party plugins); the synchronous animation playback, effectively using continuations behind the scenes; how it handled synchronization of variables for client/server; and to a certain degree the "modes" that objects could be in, a way of switching behaviour of a whole slew of methods en masse.

On the other hand, object-oriented approaches are not great for simulating huge numbers of entities, where column-major array-based layouts are a lot more efficient.

I wonder if Kismet data-flow graphs may end up getting too complicated for their own good. They look like they could do with a textual representation. The obvious manual iteration involved in the creation of the orrery in the gametrailers demo video posted in the comments elsewhere here shows how painful this approach can be.

[psykotic]

> a kind of sideways inheritance where you could override an ancestor in a package, but not have to override all the descendants to have them inherit the behaviour - really handy for third-party plugins

This sounds like the virtual classes that Tim were talking about ten years ago. (For the curious, the first programming language with virtual classes was BETA from Aarhus University.) They never made it into UnrealScript. His language research after that time was less incremental and sought to uproot almost everything about programming games. He moved away from object-oriented programming and more towards functional programming, specifically type theory. When I arrived in 2004, he was all about dependently typed languages, the big inspiration being David McAllester's Ontic. For a long time his plan was that his new language would be used to implement most if not at all of UE(n+1). Eventually that ambition had to be tempered by reality and thrown aside; I'm not sure if he's still working on programming language design.

[barrkel]

Yes, it's been 10+ years since I last seriously looked at UnrealScript; I must have misremembered that feature, virtual classes.

[tfb]

> particularly its module system (a kind of sideways inheritance where you could override an ancestor in a package, but not have to override all the descendants to have them inherit the behaviour - really handy for third-party plugins

Do you know if this can be done in UE1? I'm actually developing something called "NewNet" in UT99 for fun - plus, more people actually still play that game than all the others! Basically it fixes the movement lag associated with high pings and simulates zero ping by keeping track of the positions of all actors from within the past second or so, and "rewinding" the server to that saved position according to the ping of the shooter. There are mods for UT2003/UT2004 (UE2) and UT3 that do this, but nothing for UT99 - although there's the ZeroPing mod which is way too easy to exploit, as it's clientside hit detection. People said it couldn't be done for UT99 but I've managed to get a working prototype, even though it's quite messy and hacked together. It'd be great if I could do what you've mentioned, as it'd clean things up quite a bit.

The hacks I've had to do it get it to work right have been pretty silly, and there's a lot of duplicate code because I had looked for something like you mentioned (the sideways inheritance) but maybe I didn't look long enough, because I couldn't find it for UE1.

[UK-AL]

I don't get it, what's oo got to do with storing entities in column major storage. Store the objects in a 2d array.

Normally you don't even store entities like that, I've seen all sorts of crazy data structures, such as storing them spatially, so you can ignore visual updates.

Or am I completely not getting what your saying here...

[barrkel]

Polymorphism with objects implies an indirection to data with variable size, and also usually an object graph involving pointer chasing; lots of indirection is bad for performance. Also, cache-efficient manipulation favours non-indirected, tightly-packed data.

So instead of:

  class Entity { Vector location; Foo foo; Vector velocity; }; // etc.
  Entities[] entities;

One prefers:

  Vector[] locations;
  Vector[] velocities;
  Foo[] foos;

A physics engine updating locations and velocities won't waste cache on redundant information (like foo) in this case.

There was an excellent presentation (from some games conference) on this topic posted here on HN a few years ago, but I can't find it easily.