Nadnerb wrote:Personally, I think Plasma is rather well organized, internally, and would be relatively simple to extend, given actual source.
Well, your opinion is more valuable than mine. I admit I'm not the most knowledgeable about the matter.
I see very little reason to try to rebuild the engine from scratch using another framework like ogre that imposes it's own assumptions about how games should work.
If working with plasma is as simple a prospect as you suggest, then I would agree that their may be little reason in my entire proposal. Although I fail to see how Ogre really imposes much, since it is designed to be purely a rendering engine, and not a game engine. If you could elaborate on what downsides you think there are to Ogre's setup, please do. The only problems I could see would be converting mesh and material assets, and a converter for both of those would be possible. We can already get them into blender (for the most part), so getting them into ogre wouldn't be impossible. Keeping the scripting working would be the major concern, and if we used Uru's existing scripting framework and combined it with a new system, then the scripting for the ages could still work.
The result of such a venture would probably be a mass of hacks designed to get the existing content (and that's where the real value is, at the moment, as dustin noted) to work under the new framework, when the content been designed specifically to operate in the existing framework, to the point that the structure of stored objects in the files implies very strongly the methods that plasma employs to use them. As far as we know, we will never get the original max source files for the uru content, so we won't be able to "recompile" it to work with some brand new engine, so I don't see how this could work out well.
Again, I don't know how much stuff in those mysterious PRP files are actually organized. I don't know how the scripting is set-up or what depends on what. I assume that the resources in there are actually separate things. Meshes are meshes, and scripts are scripts, and never the twain shall meet. Sure I can imagine there would be a lot of stuff in there with the coding that points to object A, or Mesh B, or Texture C. And I could see how a lot of that could break if you tried using something other than prp maybe. If prp isn't something you mind (for those of you coders out there), maybe it's possible to use it in a new system, and would avoid breaking everything. Just store the meshes and materials in the prp's in ogre's format. Or maybe again, I'm just tralking crazy..
As for the lack of "pluggable" content in Plasma...
That is one of the big concerns I would say, as far as creating a more dynamic gameworld. Again, you'd know more than me as far as what is possible with Plasma. But what kind of options do we have when working with it, say for something like AI scripting.
...design principles that work well for things like first person shooters do not really apply to Uru.
I agree to a certain point. FPS's definitely have a different focus. And we don't necessarily want Myst Mayhem here. And I agree that having the same damn buttons everywhere would be aggravating (heck I'm a little irked that the lever in Teledahn is used in Kadish). But you can't deny that FPS's are dynamic (because they need to be) and that maybe Uru could benefit from that, and that it could be less rigid. And some of that prefabricated entity framework stuff could help in a lot of ways. I mean, why are kickables set up inside places like the hood? Or the barriers in the city? Why isn't there some kind of global prp file for stuff like that, and we just load whatever we need, whenever we need it? That's what one of those FPS systems would do, they just do it a lot (as you pointed out). But from what you've described, then shouldn't it be possible to drop a city barrier right into Relto? Or anything else from any other PRP in the game? (assuming your messing with the scripting) Or am I getting it wrong?
And for user content, some of that could be really useful. There will always be people creating user content that is of lower quality, that may reuse such assets ad nauseum. There is likely little of redeeming quality in such examples that something as simple as a unique button would be able to fix. But it might help having a library that could quickly allow prototyped ages to be built, and then those projects that are serious about creating polished ages could take it the step further and customize those generic elements.