In an abstract manner, I mean. After reading this TF2 blog update it hit me that one of the questions facing community mappers is this:

Quantity vs. Originality (in place of "quality" so you see what I'm driving at).

Uru is not a first-person shooter so the focus is not on creating a balance of choke points and strongholds, but rather on creating interesting vistas but also on interesting architecture.

I also wonder if it is likely that there will be many "prefabs" (to use the term from Valve's old Worldcraft editor, now Hammer) developed for use in worlds. This depends, I suppose, on how much of a role "beginner Ages" will play in MORE.

Prefabs would let some people with a focus on sculpting and small-scale artwork develop what they want, and it would let people more interested in creating larger worlds focus on creating vistas and not the nitty-gritty stuff. This is, of course, more or less the balance of skills found in any real-world game studio - although there is also crossover, and I wouldn't discourage that. I am wondering, then, how easy it will be for these groups to interact with each other, and also (but no less importantly) with people in the community who have strong specific ideas for puzzles or gameplay (i.e. hopefully everything remains a community effort and I hope artists will keep a strong presence on these main Forums, not just on blogs or on Guild sites).

For fun, let's end with a quote from the TF2 blog article:

Quote:

In coming up with these ideas, we have a set of questions we ask about each one, for example:

* What are the costs in building this compared to the value it creates for the end user?
* What are the obvious types of new gameplay that we can create with this theme?
* Is this environment flexible enough that we can leverage it for our other gameplay types?
* Is this environment flexible enough to be usable for ideas we may come up with in future updates?
* Is this type of thing recognizable to a larger set of people?
* Has it been used successfully anywhere else? Has it been used too often?
* Does it create a unique experience that people will be drawn to?
* Can we leverage existing art assets to help build the new environment?

One thing I've noticed with many UCC ages is the focus on vast spaces and a lack of linearity. Too often, I enter a great looking UCC age but don't know where to go, or have to draw a map so I can get back to where I was. There are so many rooms and spaces that serve no purpose or seem extraneous or repetitive. It might be interesting, it might even be good architecture, but it's not good level design. It feels like a chore to walk through it all, and it feels so disorienting.

I think you're a bit mistaken when you say that Uru ages shouldn't follow some of the same rules that make good FPS maps. When we were dropped into the Cleft, we didn't know where to go, but that sense of disorientation was intentional. No other age worked that way, or if they did, a linear path existed but was hidden. Pretty much each corner of each age had a purpose, and the way you progressed through each age was more or less linear. That gave the player a sense of scale and knowledge, and it's important to not leave too many options which make the player double-back just to be sure they saw everything. Even the dead ends were purposefully designed (except for maybe the Teledahn stump).

We talk about Uru in terms of exploration, and while it's a vital aspect of the role-playing element of Uru, actually playing Uru is nothing like exploring at all.

In fact, this is why Ahnonay was so brilliant, because it first appeared random, but after awhile you started to see a path to follow. It's the same with Minkata, which became linear once your saw the line. Many of Uru's best ages have a linear path which is eventually revealed to the player, but some ages (Kadish) are pretty much straight-up linear.

To address a point of yours, I'd like to think that once the tools are made available, many writers will make prefab objects and small buildings to ease the load on beginners and get more people involved in age-building, but it seems to me that each age should be in some way unique, to be worth the effort, especially since it's not yet certain that we will be able to implement complex puzzles which might make an otherwise drab environment interesting to "explore."

On the other hand, "unique" can mean different things. If anything about an age is unique, it's layout, it's puzzles, it's "vistas," anything, then it should be judged on that factor first, even if some of the other things are derivative, why not?

_________________
KI#01165421
Hey! Visit The Jalak Registry, the source for all things Jalak. Yes, it's still open!

Taking a page from TF2 is fine by me......

Something like the Source SDK will have to be done eventually that is plain enough. Yeah yeah the Writers have done wonders, but months of learning Blender added to the time it takes to just learn to use the tutorials is too much. I've been playing TF2 a lot recently and it's fun seeing new maps people come up with, and it's all reused parts.

See it once and play it everywhere.

No major hoops just basic modular design to the Game engine so assets from any source based game can be picked up and put to use in any other source based game. Garrys mod for example is a big example of doing it right. That said something like Garry's mod doesn't exist for Uru, and I don't know who would be able to make it. Cyan would have to release access to Uru:CC and EoA as the only preexisting sources of parts and that would be a hard sell.

Modularity isn't a bad thing but it has to be planned for, and Cyan didn't plan on us fans needing it. Instead of a update when MO:UL happened we got Uru:CC, now with MO:RE the best we can hope to get is Uru:CC again. You will not see a Garry's Mod for Uru, or even a major alteration to Ar'gura because no one has done it.


<Probably my final Age building Rant>
Part of this is frustration at the Writers, and part of this is pure joy at the silly little things I have been doing this past month that have gone so right. I was given the advice that if you like a game don't wait for Gametap, buy it and enjoy it. The same advice goes for Age creation and Uru in general, don't wait on Cyan to do it right, or the hackers in the Writers corner to tell you how.

Uru is based of DirectX and some customized bits of code Cyan built for their plasma engine out of python code. Don't worry about Python it's just the computer version of super glue, consider it more a after thought then something you should devote a lot of time to. Cyan used Python but the truth is you can do your coding in any language you are comfortable with and wrap it in python so you can use it anywhere you can use python. (Which is just about everywhere.) Puzzles, animations, or anything else you can imagine that starts with a mouse click or pressing a keyboard key can be done how ever you are most comfortable doing it.

It's that no one has learned how to do it that is hurting Uru. The hard truth is that the Writers after years of work learned how to use the python interface that is meant to be used. To learn what the Writers have to offer requires only one thing....Time. You will spend time learning blender, you will spend time learning how to use tutorials written for a older blender tool version with a newer version, and you will spend time until you ignore the changes they keep making and choose one version of their blender tool for good or bad and get to work.

If you want a good basic introduction to Game Engine design I recommend Managed DirectX 9 Graphics and Game Programming by Tom Miller isbn:0672325969

If you want a good way to learn Blender buy the blender manual from their site. It's laid out as small lessons easier to read then the noob to pro guide online, with the online material doing a good job supporting the weaker sections in the book that are skimmed at mostly.

And while I make a point of hating anything written by Sybex Body Language Advanced 3D Character Rigging by eric Allen & Kelly L. Murdock isbn:9780470173879 is a excellent guide to getting started with making animations. It's Written for the Maya computer modeling program But the rigging instructions that explain what you need to do where were written by one of the lead modelers at Bryce. If you study the subject in Blender and it makes no sense once you get so far the instructions in here makes "What do I need to do next" very clear.
</rant>

People in this community have skills elsewhere and might be surprised by what they could do for Uru if they stopped getting tangled up with how others are doing things or want them done, and just tried out their ideas how they already know how to do them..

_________________
Waymet

I think when Cyan's tools are released things will be no different from PyPRP (except for the fact that you are using Max and they may be more complex than PyPRP).

Here's why I think they may be harder.

PyPRP: Made by fans, made to automate a lot of internal PRP stuff. I mean... we're not the pros--we need to make things easier for ourselves.

Cyan's Exporter/Plasma: Made by pros and for pros. Being offered to the fans as a last resort. I have seen a few pictures of their GUIs and it doesn't look that easy. I mean, you have to deal with the internals of Plasma. Unless you want to use your time learning about Spans and SceneObjects and how they should hook together rather than age-building then this is not what you want.


Yeah, prefab is a nice idea. But somehow I don't really get what the point of having an age that's not made by you--it should reflect your skill level rather than your prefab-thirst .

I think the very best would be to have some easy age-editor/creator. Completely themed, easy to learn, to the point.

I feel that people end up learning lots of Blender stuff when they don't really need it for age-building.

Making a 3d editor would be a huge undertaking. I don't know if anyone's up to that task yet.

The take-home message here is: Blender is hard, Max is hard; there is no place to hide when you want to age-build.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Lontahv that is the difference between Cyan and the hackers that started Age building.

For all the talk of puzzles in Myst; Uru:CC is a practical desert devoid of even the hint of a puzzle. Kadish tolsa has the pillar puzzle and ahnonay is well ahnonay, the rest of the prime ages are a wash in puzzles most other games use in one level to train you for the other ten levels where they don't hold your hand.

That's where things like Ed is talking about come into play.

Ages need to have a bit of a redesign; I personally see this most easily done with with a prefab kit so anyone can try their hand but that is just my opinion. If you want to push multiplayer team aspects you have to consider choke points, multiple paths to the same objective, and the rewards and consequences to your choices. The teledahn bucket ride was never meant to have a delay and the control room is fairly pointless except for the cloth/elevator you can hit once and be done with.

Not taking the bucket ride in CC means you lose a clue, but in MO:UL not taking the ride would mean very little. CC was setup in a very linear one shot way since it was a boxed version of the game. Considerations like choke points where it takes a team to meet a challenge; even a weak one like the bucket ride, can be ignored. Cyan does it and everyone that has turned a hand at Age creation does it because Cyan asked everyone to keep it offline making it pointless extra work since one person can't work it. There is no reason to put in very minor changes like taking a hallway from A,Stairs and a Room from B, to get a alternate path to C where the happy bahro dance if everyone spends their time in a bucket ride......

Quote:

Cyan's Exporter/Plasma: Made by pros and for pros. Being offered to the fans as a last resort. I have seen a few pictures of their GUIs and it doesn't look that easy. I mean, you have to deal with the internals of Plasma. Unless you want to use your time learning about Spans and SceneObjects and how they should hook together rather than age-building then this is not what you want.

That's bull and you know it, not even the pros hand code that sort of stuff the Game Engine handles it. The "Pro" knows how the game engine handles the information yes or can look it up and manually change something if needed, but the majority of their work is done just like anyone else does it in the modeling program.

_________________
Waymet

Err... if their tools just export the stuff that you model in Max why are they manually attaching seemingly every object to their scene nodes (this is an automatic feature in PyPRP)?
http://http.developer.nvidia.com/GPUGems/elementLinks/fig01-07.jpg


What I'm trying to say here is: I am certain that with their tools you need to know 3dsMax+Plasma. This is a lot like with PyPRP how you have to know Blender+PyPRP. I think the notion that their plugin is something that can just know Max, build something and export as-is is faulty.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

I think I was the one to bring Mr. Finch's water article up over at the Guild of Writers........

For anyone reading this water in Uru is one of the most programmable features in the game that is also capable of real time rendering on the screen. The graphic Lontahv is quoting is part of a article by Mark Finch (Formerly of Cyan) about creating realistic looking water, and most likely a screen shot of the water control panel in Plasma.

Beware there be college level math hiding in them there waters.

I never said it was automatic or easy I just said the majority of the work was done in the modeling program. Nothing more and nothing less.

P.S. The "Objects" you refer to is the water itself, it is attached to the scene node as a method of animation that allows it to be driven a lot like a skeletal animation. I don't know it for sure but there is a very good chance that is how the water is animated in Uru since you bring it up. But the Water is still animated however it is animated by the engine regardless of whether it's the pyprp or Cyan plugin setting the control variables found in that picture.

Later this discussion is heading into deeper waters then I want to get into at this time of night.

_________________
Waymet

Wavesets are not animated. And also... the water is not attached directly to the Node. There's a little box there that has an "add or remove reffs" type thing. This I'm thinking belongs to the object itself (there's no reason really to have that for wavesets alone). So, from that I'm concluding that for most features/objects/visuals would need to do that kinda thing. 'Cause it looks to me like if you want to make a visual cube you'll have to go: <ref to node> <ref to DrawInterface>.

Just conjecture on my part.

Also, you may notice that a lot (all?) of the modelers also helped with the programming a bit (or knew quite a bit about it). Take Mark Finch for example... he implemented stuff and then he used it (water ripples for instance). So, I think that the Max plugin will be stewed in Plasma internals.

*me stops getting this topic off track before the mods have to get grumpy*

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

TheNobleRobot has a point: so far UCC Ages haven't really been 'designed'.. Many of them have been experiments that somehow turned into full Ages with time, and those that were actually designed and planned were not designed with puzzles in mind. There are some (thankfully) but not the majority. Among other reasons that's because our work is not structured, we tend to work as individuals not as teams with enough skills to create whole puzzles. A puzzle need a variety of skills: game design, visuals, sound, and coding. That's at least four different people to make it happen.
And, to make it short: it's difficult and it requires some focused efforts and some organized people. UCC Age creators are volunteers individuals, hence lack of focused efforts and organisation. But let's not lose hope, we're making progress all the time, and there are some promising projects being worked on.

Lontahv wrote:

I think the very best would be to have some easy age-editor/creator. Completely themed, easy to learn, to the point.

I feel that people end up learning lots of Blender stuff when they don't really need it for age-building.

Making a 3d editor would be a huge undertaking. I don't know if anyone's up to that task yet.

*coughUruBlendercough*
That's the obvious way to go. Best of both worlds: free and easy to use. Of course that'd also be a ton of work.. But would that be worth it? I think so. Especially if we want to include new people in the UCC community. The entry barier is just too high..

Quote:

Wavesets are not animated.

:ROTFL:

I needed that. I know what you meant but that sentence struck me as really funny. So much of this would have been different if Cyan had planned for a modding community from day one but they didn't and so everyone does what they can. Any Game modder worth their salt knows there can be a lot of code tied up in something as small as a button you press. Puzzles, NPC's, even the KI are deceptively simple in the game but what you see in the game is the tip at the end of a programming iceberg.

<shrug> People serious about learning game modding learn that fact soon enough.

Anyway I hope Aloys is right about hope for the future because BlenderUru is a interesting idea but the responses in that thread make me wince. Still I will always have a warm fuzzy place for the original pyprp devs who started this wild ride. C++ may be a strict language but it is very modular if you follow the coding conventions.

_________________
Waymet

They'll still be the same warm and fuzzy devs (or at least the ones that are currently working on it). The funny thing about this is that we're planning for PyPRP 2.x to be based on a C++ library that Zrax wrote.

So, it wouldn't be all that strange to stop work on the Python API code and just link it directly to Blender or link it to a new program.

We're all still warm and fuzzy. Err... yeah.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Bummer. No more contribs from me them.

_________________
D'Lanor (ɹǝʇunч puǝƃǝן uɐqɹn)

♪ KI# 33949 ♪

If all goes as planned we'll still have to deal with Blender's Python API (so there will still be large amounts of Python).

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Ah cool. /me likes Python.

Will there still be Alcscripting? The reason I ask is that many people are investing their time in learning that. Perhaps a status update about these plans on the GoW forum is in order.

_________________
D'Lanor (ɹǝʇunч puǝƃǝן uɐqɹn)

♪ KI# 33949 ♪

I dunno, I think Alc-Script will still be around (at least so that people who learned it can still use it). It's really too early to fill in the details (I'm just starting a few tests myself--really just playing around). Part of my plan for it (I can't speak for all the PyPRP devs here--though I think they want this too) is to get rid of a lot of the alc-script stuff that shouldn't be alc-scripted--like render-flags etc.

GUIs will/may play a big part in 2.x (depends on if Blender has made some stuff less insane). My goals for this is mostly:

- Saner easier to understand plugin code (lots of stuff will need rewriting because it'll be using the C++ lib--so, just blender interpreting features mostly rather than actual Plasma classes and export functions).

- User-friendliness

I don't really think that this is evolved enough to post on the writers' forum. This info was just posted at random here... dreams, thoughts, etc..

We are just on version 1.5.0. Got a long ways to go before 2.0 is more than a few tens of KB in a testing folder locally on my HDD.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker