Understanding game engines...a little help?

They have documentation on the engine, it's just not as thoroughly documented as they might like it to be. In some cases there may be things that are undocumented, but in general there is documentation. This is something I've been told by more than one person that has seen the code.

BAB knew the animation side of the engine very well, and knew some about the rest of the engine. I don't think I'd characterize t as really knowing the guts of the engine. Castle left after BaB and knew the engine pretty well. pohsyb knew it much better than either of them (both from being a programmer and from having worked on the game longer, including Beta) and he left after Castle. Neither BAB nor Castle originally worked on the engine. They came in later, much like the current team.

TheDarkWatcher knows the engine very well. Synapse knows the engine very well. Black Scorpion knows the engine pretty well. I'm not sure how deep Positron's knowledge of the engine is, but I'm pretty sure he has a good understanding of it.

People working there know the game engine better than you think they do.

I suppose this is true, so where's the 'happy medium'? I'd like to think with today's game engines that we can at least emulate some of these experiences without a ridiculous drain on resources.



S.

This isn't even wrong. OpenGL is still a live standard, graphics cards still supply drivers that support it, and the concept of "emulating" it doesn't really apply well. In theory if the spec mandated functionality they lacked they would "emulate" that (or just indicate that it wasn't supported, if it was optional), but in practice any video card will support openGL the same way it supports DirectX. It may not be as fast, but this isn't because it's "emulating" rather than "supporting", it's because Windows driver devs tend to focus on DirectX.

(MHO, the world would be a much richer and happier place if MS had just worked with the spec rather than inventing a competing spec, but that is not a new concept in talking about MS.)

They're called mayhem missions.

Seriously, if you have several hundred players frequently passing through a zone with destructible environments the odds are that unless you have structures repairing/respawning themselves at an absurdly high rate the zone will resemble Boomtown on a nearly permanent basis. The same principle applies to any sort of environmental changes that can be caused by players.

Cos i know speshul people

Another factor: While we can send an item's "state" (the mailbox here is in 'broken' state. show random letters in the wind), most of those pieces are renedered client-side and don't match what others see on their screen. This is rather common in online games (and noticeable when you team with someone in the same room). This is because otherwise you'd have to track and communicate the positioning of all these random pieces to everyone.

It really isn't a big deal for little things like broken debris, but when you start thinking about the BIG things, some debris-tracking will be essential.

---

But like others have said, affecting the "world" on a permanent basis isn't a limitation on the engine, but one of design.

As early as Ultima Online, developers were toying around with ecology models you could tamper with. There are some great written accounts of the mess beta testers could make for each other in such systems. Some of the earlier games were very much experiments in giving players different ways to impact the world, and largely they found that players impacted the world in ways that generally made it unfun for others. Its essentially one of those "what everone wants until they see what everyone else does with it once they get it."

It became easier (and a better user experience) to minimize how badly a player can f^&% up the world, which is why the MMOSpace has gravitated to the controlled-experiences we see today.