more games where the client can connect to an arbitrary server of their choice and have all contents/etc/... streamed down to them, sort of like a web-browser but also a game?...

in this case, then users would run game servers in a similar method to how they run Apache, while being able to control nearly all aspects of gameplay from their own local server, and being able to include portals to other servers (potentially with very different gameplay). likewise, without requiring the big centralized server-farms (or service fees) typical of an MMO.

sort of like if Steam hybridized with a web-browser and normal network gaming?...

also:

destructible terrain (specifics could depend of server-side policies);

user-level multiplayer world editing (could be restricted to users with OP rights);

...

likewise: streamed single-player games could also be worthwhile.

admittedly, some of this is a goal in my case, but there are still holes and potential security issues limiting this sort of use (many types of assets are not currently streamed, and the security of client-side script-code is still a bit worrying and it will still require a fair bit of work to work before this can really be made "safe"). (the issue is providing enough freedom where the scripts can do what they need, without providing so much as to allow script code to compromise the clients' system, like in the possible case of malicious game assets and scripts or similar...).

it could ultimately be made pointless though by the whole Unreal Engine + HTML5 thing though (where the whole engine is pushed down to the client as a big mass of JS code and similar...), which could limit the need for a native-code version of an engine on the client. (even if, personally, this seems like a "big pile of crap" solution...).

I know that there's a Sonic fangame that has a special mode where people can join and netgame and go into the 3D equivalent of debug mode from the original Sonic games (letting everybody place objects around), and then save the object layout. This was implemented because the level needed too many objects to be placed.

Can't get more collaborative than that, I presume?

Cube and Halo also have something like that. But neither of those are full editors.

Real-time editing of content and assets without the need to rebuild the whole level again just for 1 asset change.

In other words, an engine where it doesn't take ages to build the hierarchy so it can be generated on the fly at load time instead of having to prebake the process when saving the data.

Real-time editing of content and assets without the need to rebuild the whole level again just for 1 asset change.

In other words, an engine where it doesn't take ages to build the hierarchy so it can be generated on the fly at load time instead of having to prebake the process when saving the data.

some of us have engines that do this at run-time.

namely, not only can the data be built at load-time, but can be modified dynamically in real-time (say, a piece of geometry is modified on the server and sent out to any connected clients).

granted, this does come at the expense of not having prebuilt light-maps or visibility data, requiring real-time lighting and visibility determination, which does reduce performance somewhat. one compromise here is cached vertex lighting, which is more viable on lower-end hardware, but this generally doesn't really look good.

another strategy is periodically using occlusion queries and similar to help rebuild visibility data, ...

(at least, in my tests, tended to be faster than using ray-casts or antiportal-based strategies).

Yeah, I was just mentioning the correlation. And in fact, yes, engines that can build the hierarchy fast enough in load time usually can do it in run time too (because it generally comes from having a simple implementation), which makes them extremely dynamic (something that can affect gameplay greatly, not just improve productivity). In fact, that alone can make up for some reduced or removed features in several cases (because as long as it looks good it's OK, right?).

Real-time editing of content and assets without the need to rebuild the whole level again just for 1 asset change.

The luminous engine is the closest I've seen.

http://www.gamedev.net/topic/647955-total-data-reentrancy-fools-errand/

The first feature is you see them tweaking variables in-game. Every game engine should have this to some degree.

Some are better than others -- e.g. one engine I used recently allowed you to tweak values like this, but not save/update them, so you'd have to simultaneously make the same changes in the editor in order for them to be permanent.

There's also different interfaces for doing this tweaking, the main options I've seen are:

1. An on-screen display, like in the video.
2. A special mode that launches the game as a window inside an editor tool, with regular windows forms / toolbars / etc for making changes.
3. An external application connected via a network, which can display the game's internal data and allow you to make changes.

The second feature you see in the video is a live-link with Maya. This is a special variation on option #3 above, where you write some special plugin/Mel/Python code, which connects to the game via a network and syncs data between the DCC app (Maya) and the game. This is a great workflow because the artists get to use the tools that they're used to, and any tweaks they make are actually being made to the source art files too, so they're preserved.

I've personally never been lucky enough to work with an engine with this feature, but I know Melbourne House had it in the 90's between XSI and their PS2 engine (before I worked there), and Crytek has it to some degree (animations can be synced between Maya and game for tweaking).

As mentioned in the above-linked thread though, there's other variations on this idea besides "live linking". IMHO, "live link" should be a mandatory feature in any game engine, to allow for fast iteration on tweaking, and in my experience, it has been present in the last 4 engines I've used.

Two out of the last 4 engines I've used have also supported "asset refresh" on top of "live link" -- where the modified asset data can be recompiled and reloaded while the game is running. This is less instant than "live link" -- taking from a frame to a few seconds, instead of instantly -- but is much more general, allowing larger changes to be quickly iterated as well (e.g. a whole texture, a whole mesh). IMHO, this is a required feature for a big engine, as the reductions in iteration time are immensely valuable over the course of a project. Every engine should have this feature going forwards.