Top 5 things you want to do when OS Uru lands.

Help bring our custom Ages to life! Share tips and tricks, as well as code samples with other developers.

Re: Top 5 things you want to do when OS Uru lands.

Postby diafero » Thu May 27, 2010 11:28 am

It's called "sd7" or "7d7", if you need something to look for. Unfortunately, it seems to be dead :(

Entity Setup
I'm not much of a programmer, but it seems the very organizational scheme of Uru is somewhat.... strange. I mean, the Quab's are set up as .age's. Everything is set up as ages. And the whole way avatars are setup. Jesus what a mess. Don't the vast majority of other games use entity systems and have different types of entities, some being animals or characters, and the AI is linked up to them? Nothing (aside from the Quabs, iirc) even has AI. Say you want to add in a cool physics system where you can pick up objects like in HL2 or something, it would probably have to be an enormous hack in Uru. Not flexible at all as a real game system.
I don't actually see the issue here - an .age is just a container. The prp files do have a lot of different object types (call them entities if you prefer). I actually like Uru's resource management as it allows for the resource manager to be quite generic (it just keeps a list of all objects available anywhere, and loads and unloads pages, that are organized in groups of ages). If you look into the avatar prp files you will see they are quite different from an age prp file, there are very different object types in there. But the resource manager does not and should not care. What do other games make better here? I doubt they have different file types for each and every thing...
The naming is a bit strange as an .age is not necessarily an in-game age you can link to, on this level, it's just a set of pages which are grouped together (and share a common sequence prefix). And a page is just a prp file.

Avatar System

Where to even start with this? lol We all know it needs a boatload of improving.
Do you mean they way avatars are saved? In that case, see above. Or do you mean the general animation system that does not allow to, e.g., alter the height of the avatar? I agree that there is a lot of room for improvement there, but IMHO it's by far not as bad as the KI, for example.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: Top 5 things you want to do when OS Uru lands.

Postby JulyForToday » Fri May 28, 2010 10:29 am

Thanks for the tip about 7d7, I had no idea about that. I posted on the alcugs forum, to see what's up with it.

Well, I've never been too clear on what a PRP file is, really. If there is a nice, comprehensive page explaining (to non-programmers) the way Uru and all it's associated files work, then I must have missed it.. ;) The way you're explaining it, a PRP is similar to a zip file (or any other resource file used by any other game), and each subsequent page file is like having a zip inside a zip (or resource container inside a resource container). Then inside those different pages then you have the REAL files, objects, textures, and interesting stuff. And the .age file itself is just a file that registers with the system and points to the PRP's. Although I don't know if other systems use an id for there resource files (I would think that they just need the path and file name).

Maybe there is not so much a problem with PRP, but with how they are being organized, and what you can access. I mean, imagine trying to make a drivable vehicle like the warthog from halo in Uru (rather than just something on rails like the Er'cana harvester, which is really just a horizontal elevator). Would you be able to have the components for that in PRP, and actually have that work in the current system?

And the avatar system, just look at 'garrison', and how many animations for avatars are in there. Plus the targets, plus the lack of fat / tall, dealing with ladders in a more dynamic way... I mean, really.. Not to mention how outdated the avatar customization stuff is (I can get my avatar on the Wii to look more like ME than I can in Uru... :P )

My major problem with Uru is it's GameWorld. And I might be wrong about a few things, but I feel some of the problems with the GameWorld come out of limitations of the GameSystem. Fix those limitations, and you could broaden the horizon of what is possible in Uru, make it a better game.
User avatar
JulyForToday
 
Posts: 118
Joined: Sat Sep 29, 2007 5:34 am

Re: Top 5 things you want to do when OS Uru lands.

Postby ddb174 » Fri May 28, 2010 10:50 am

Well, the prp format is okay; it's not great, but it's not bad. I would personally have gone with a checksum/hash repository. It's faster, more reliable, takes up less space, *much* easier to refactor across all Ages, etc. But Uru's just a straight-forward plain-jane game engine, and that's okay, that wasn't supposed to be its strength. It certainly doesn't have anything to do with Uru's negative growth, which has more to do with the lack of fun and things to do ;)
ddb174
 
Posts: 928
Joined: Thu Apr 10, 2008 7:28 pm

Re: Top 5 things you want to do when OS Uru lands.

Postby Aloys » Fri May 28, 2010 11:00 am

imagine trying to make a drivable vehicle like the warthog from halo in Uru (rather than just something on rails like the Er'cana harvester, which is really just a horizontal elevator). Would you be able to have the components for that in PRP, and actually have that work in the current system?

Yes, in fact there's the Zandoni easter egg in Uru that is a drivable vehicle. But it is a lot of work. Because Uru doesn't have basic gameplay bricks that you can assemble, everything is actually coded in Python from scratch each time.

You can do a lot in Uru, but it was not designed for 'amateur' custom creation content: at Cyan all of the Ages integration and scripting was done by a dedicated team of experienced people who are not bothered by complex scripting. As a result Uru is quite difficult to create gameplay for. Entities system like what you have in Half Life/Quake/Unreal are made to easily set up 'pre-fabricated' gameplay elements (weapons, vehicles, items, simple doors & interactions etc), in Uru each Age is totally unique each puzzle is different and you have only a couple elements that you find in all Ages (books, GUI etc). And developping an 'entities' content creation tool is actually quite a bit of work, that's why they haven't bothered with that: it was easier for them to just code everything from scratch with each new Age. I agree some things should be much easier to use, but that's not how it is unfortunately..
User avatar
Aloys
 
Posts: 1968
Joined: Sun Oct 21, 2007 7:57 pm
Location: France (GMT +1)

Re: Top 5 things you want to do when OS Uru lands.

Postby diafero » Fri May 28, 2010 11:59 am

The way you're explaining it, a PRP is similar to a zip file (or any other resource file used by any other game), and each subsequent page file is like having a zip inside a zip (or resource container inside a resource container). Then inside those different pages then you have the REAL files, objects, textures, and interesting stuff.
Subsequent page file? No, viewing a prp file simply as a container of objects is fine. Each object has a type, and a name. Each prp file has a unique 32-bit ID (that is split into sequence prefix and page number, or page suffix). An object is referenced by that 32-bit ID, the type ID, and it's name. On startup, Uru loads the "keyring" by reading the header of each prp file. It then has a full index of all objects available. The actual object content is loaded on demand, triggered for example by linking to an age or python scripting. Some objects are loaded on sartup, and some objects can be used without being explicitly referenced.
Some more details you might be interested in are explained at http://www.guildofwriters.com/wiki/Plasma_101

trying to make a drivable vehicle like the warthog from halo in Uru (rather than just something on rails like the Er'cana harvester, which is really just a horizontal elevator). Would you be able to have the components for that in PRP, and actually have that work in the current system?
The way Uru works, this would require some new types (or maybe you can even use the ones existing for the Zandoni). But it's no the PRP system that restricts this. But you can have each object in any PRP file, for example Chloe once had the plan to put a NPC into an age, and animate it like avatars are animated in Uru. This should technically be possible, though Cyan did not do that - the NPCs they made are actual Avatars you can also play, they are in a global file. But even if it does not work, that's not the fault of the on-disk format.

And the avatar system, just look at 'garrison', and how many animations for avatars are in there.
How would you want to reduce them? It might be better not to have a single file per animation, but even with a better generic animation system (that I agree would be awesome) you would have to design each animation, and save it.

Sure there are better formats, there always are. But of all the internals I had to deal with in Uru, all the design (mistakes) they did, the PRP format is really okay.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: Top 5 things you want to do when OS Uru lands.

Postby JulyForToday » Fri May 28, 2010 12:13 pm

I forgot about that airstream, lol.. although I bet that thing would never flip over.. :-P

But that's part of what I'm getting at. For short term, sure just code whatever and build what you need. Last time I checked, they had a name fore that: Prototyping.

When you actually are building a system your going to USE, and use a LOT, then it's worth the effort to make the system as robust as possible, preferably enough that a baby could use it.

Look at how they manufacture cars. Sure I could just make some wooden wheels and slap some more wood together and make a soapbox racer. But to churn out thousand's of cars a year, you need to have people who are experts in industrial engineering designing an assembly line, as much as you need engineers to design the cars themselves. Sure it causes a *heck* of a lot more administrative overhead, and the whole thing is far more complicated a beast than just slapping together that soap box racer. Question is, just how much content do you really want to put out there, and can your system support you in doing that?

The point of this is really that when (if) we get the source code, then things no longer NEED to be the way that they have been. We can change it, if we want. If were are willing to flesh out what those changes are, and make them happen. But if we just take the source code and patch whatever little problem areas are here and there, and don't make any significant changes, then we are just taking the path of least resistance. Which means we will always have to live with "that's just how it is", until we get sick of it to the point we actually want to change it. But by then lots of work will have gone into patching things, and continuing to build around the present system. So it's really just like cleaning up a messy room in your house. The longer you wait, the more dramatic the clean-up effort will actually be.

Edit: Or to go with my initial post, speculating how much it's worth it. Example: My parent's live in this old house (like 1880) and it's been poorly maintained. It's not the kind of house that's really a historic landmark and would be great to renovate. They've been rather bad about maintaining it too. Yet they just put a new roof on it last year, yet the foundation is crumbling..... In this particular instance of this house, it's better to just knock it down and build a new one (trust me, the thing is a mess end to end). Yet they won't do it because they live in it, financial reasons, emotions, and most importantly, they've put a bunch of work in already, and knocking it down means loosing that effort.

So it really becomes a question of how much is saving or renovating the old thing (system or house) worth it? Or should you just restart from ground up. Is there anything salvageable? Bathtubs, carpets? The new roof? But then your locked into the house's dimensions. Maybe only the foundation is bad, and the house should just be lifted while redoing the foundation.

The analogy is quiet appropriate for this. How much should plasma be gutted? A little? A lot? Completely scrapped? You can't fix the house if you don't know what you want it to look like. So what kind of system do we really want to be working with?
User avatar
JulyForToday
 
Posts: 118
Joined: Sat Sep 29, 2007 5:34 am

Re: Top 5 things you want to do when OS Uru lands.

Postby Aloys » Fri May 28, 2010 1:09 pm

I agree, but basically it comes down to reality and the means we have.. There are only a handful coders here, and not all of them agree on what to do or how to do it (and if we add the rest of the Uru community at large it's even more of a mess). How would you want to totally rebuilt an engine and a game design as big as those of Uru with those few ressources?
User avatar
Aloys
 
Posts: 1968
Joined: Sun Oct 21, 2007 7:57 pm
Location: France (GMT +1)

Re: Top 5 things you want to do when OS Uru lands.

Postby ddb174 » Fri May 28, 2010 2:49 pm

We can rebuild from scratch, but if it won't run the old content, why would anyone use it? I really don't think they would. And so we are stuck with basically the old system, with a number of changes (Bik/PhysX/Cross-platform/etc) that we must do or are able to do without serious consequences to the old content. And as Aloys says, it would be a huge amount of effort, especially to reproduce the quirks.
ddb174
 
Posts: 928
Joined: Thu Apr 10, 2008 7:28 pm

Re: Top 5 things you want to do when OS Uru lands.

Postby JulyForToday » Fri May 28, 2010 2:55 pm

I agree that resources are limited, and by than I mean humans who can code. That's the largest issue we face (no matter what we're talking about). But I never said anything would happen over night. But if OS Uru ever really happens (?), then it's not a bad idea to discuss our options. And of course getting a consensus in this community can be a bit like herding cats... lol

As far as rebuilding an engine goes, again, like I said before, leveraging gives us the best benefit of our time.

Right now Plasma 2 has it's own rendering component (you know, all that stuff Brice Tebbs did). If we want to add something like HDR (which correct me if I'm wrong, but Hex Isle does have this) we'd have to integrate that into Plasma. And if we want better shader support, or shader materials we'd need to integrate that into plasma. And with any other thing like that (animation systems, compositor system..etc.) we'd have to hope to god we can make sense out of plasma, and that cyan was diligent about documenting stuff, that it's not all spaghetti, and that it doesn't give throw a ton of obstacles in our way when we try to including new things like that (or any future advances..). We'd have to integrate those things ourselves, document it ourselves, and maintain it ourselves. Indefinitely.

Create a new system with a rendering engine, like Ogre, and guess what, it comes with all that stuff, plus plugin architecture, plus plugins like paging geometry or octree scene managers, tons of third party libraries (like caelum and hydrax). Other people are writing it and using it. It's stable, and is not going to disappear. It has documentation, and it's ready to go. And it will be updated with modern features as time passes.

We will likely be spending time on plasma's architecture itself as well to make sure that physics and networking code are working correctly, maybe swap out subworlds for something better, or more sensible. Maybe mess with how Uru deals with messages, and scripting. Adding video textures, and integrate theora and ditch bink. The list of modifications to plasma continues....

Create a new system using a pre-existing framework, like IndieZen, and guess what, the component architecture would allow us to change anything from the render engine to the physics engine, to the sound engine, whenever we felt we needed to. Again, other people are writing, maintaining and using it. It's has a generic architecture, but it's designed to be capable of working for an MMO. It already integrates a bunch of 3rd party libraries (like ogre, openal/fmod..etc), so we wouldn't necessarily have to do that step either. It already has support for scene formats from ogre, and will be able to use Ogitor as an scene editor (again, leveraging another team of people's work).

Really, all we would have to do is integrate python scripting into Indiezen (basically an interface between lua and python), and make an offical format for both maps and scripting if we felt that the existing .age and .paks weren't good enough. Write some conversion programs for .ages to get the assets into a working format for the new engine. And a good converter /exporter for blender (pyprp needs to be re-written for Blender 2.5 anyways). The rest is making sure the network code works, which is the primary thing I would think we'd end up cannibalizing from plasma. Sure it would not be as simple as I just made it sound. But neither is adding all those nifty features into Plasma as it is.

And again, the key would be to design an extensible system. It would not have to be created over night. It just has to have the correct architecture that doesn't wall off our options, and makes adding things in the long term an easier process, and a process that we actually know something about.

Maybe I'm totally whacked here, but I don't think it would be so impossible to accomplish. Anyone who thinks what I'm suggesting is pure quackery (again, cause I'm not really a programmer), please feel free to correct me.

And personally I'd rather build a new house then renovate an old one that looks like it will be a b**** to fix up. Especially when the new house design is bigger and better than the original's, where as when you renovate, it will rarely be bigger or better, and any such changes would be awkward, and more difficult.

But I agree, this is something for the actual coders (who do the actual coding) to decide, if they don't already think I'm insane for suggesting this.. ;-)
User avatar
JulyForToday
 
Posts: 118
Joined: Sat Sep 29, 2007 5:34 am

Re: Top 5 things you want to do when OS Uru lands.

Postby Nadnerb » Fri May 28, 2010 4:00 pm

Personally, I think Plasma is rather well organized, internally, and would be relatively simple to extend, given actual source. 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. 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.

As for the lack of "pluggable" content in Plasma, that's a bit of a myth. Any object from any page in the game can be loaded at any time... take KI markers for instance. The fact of the matter is really that Cyan just didn't create very many obvious reusable assets, graphically speaking, preferring instead to create as many entirely unique locations and objects as possible. And on the inside, there are actually quite a few reusable parts. There are generic linking scripts that are used for linking books throughout the game, and the responder system basically allows the wirer to drop in blocks of triggers for animations and scripts quite easily, if you're using Cyan's tools.

And if you want to do something that hasn't been done before, you can write a new script to do it, but you don't necessarily have to code up everything you want to do, as chances are you can use an existing door script if you supply the appropriate triggers and models, and if you want to do something fancy like a combination lock, chances are that your design hasn't been done before. Of course, since the whole point of uru seems to be to create unique puzzles that probably haven't been done before, the average age does contain quite a few custom scripts.

Basically the point I'm trying to get at is that design principles that work well for things like first person shooters do not really apply to Uru. Having simple common building blocks that babies can use is not a good thing for Uru, because then ages would appear to be somehow coming out of the same bag of parts, rather than crazy expressions of an infinite universe. I've pushed the same big red combine push-button hundreds of times in the half life 2 series, to do various things like open doors, turn off shields, and make elevators move, and it was fun, but it's not what I want to see in Uru. I won't claim that everyone shares my opinion, but I'd be interested to know if anyone disagrees here.
Image
Live KI: 34914 MOULa KI: 23247 Gehn KI: 11588 Available Ages: TunnelDemo3, BoxAge, Odema
Nadnerb
 
Posts: 1057
Joined: Fri Sep 28, 2007 8:01 pm
Location: US (Eastern Time)

PreviousNext

Return to Scripting

Who is online

Users browsing this forum: No registered users and 0 guests

cron