World Builder.

[Argh]

I normally do not send people elsewhere in the Forum, but I'm going to make an exception, this once- Moderators, if you want to move the thread in question, now that I have a working piece of software, feel free.

If you're a mapper, and you have not been following this thread about the World Builder software I'm working on, please read it, and ask questions. World Builder is going into early testing, to give AI developers and other interested parties a sneak-peek, but this mainly involves you folks and game developers for Spring, so I think you guys should check it out.

[lurker]

Here. I improved the neutralizer gadget. And .lua attachments aren't allowed. Maybe trepan's fix was only for the one subforum?

[Argh]

Cool, updated. There are probably other places where things can be consolidated.

[lurker]

Yes. I just took a look at FeatureReplacer. That can use a bunch. I'll get to it when I have time after classes.

[smoth]

did you add the feature from the feature resource thread? Those features are handy.

[Argh]

I added some stuff, but due to the way they need to be packaged, basically it was a couple of mishmashes in there, mainly using LathanStanley stuff with a lot of rework from me, and some of aGorm's stuff from AfterShock V2, plus some stuff I developed on my own. A lot of the content got reworked several times, as my code evolved and I standardized stuff.

What I really need, and haven't had time to get to, is buildings that look modern --> futuristic (I'd prefer stuff that could be used for both without raising eyebrows), preferably buildings that share a common texture set. I.E., clever stuff where 5 things used a single 512 and lots of trickery to hide their common origins would much, much more useful than stuff that uses a 256, but is not designed for modularity, and stuff that uses 1024s and is not amazingly awesome is right out, except as singletons. You don't wanna try building a city with them, even with culling, you'd kill people's machines. Also, since these are Units... they can do anything a Unit can do. Factories with smoke coming out've the stacks and some blinky lights, anybody?

I'll look over what's available again, see what's there.

[edit] I'd forgotten about that generic building mesh. Cool, I'll see if I can whip up an insta-city with that, maybe even have it "degrade" based on damage, with SFX... hehe...

[edit2] Er, it's not in your collection, Smoth. Oh well, I'll just make one, so I can start tackling this problem and making example code, since I know people are going to want city-generation as a feature immediately...

[lurker]

More streamlined code attached. And you need a way to disable healthbars so specs don't see them.

[Argh]

Can't, short of a LUA method (which might be slower than just letting specs see them), I'm already hiding them via what engine currently allows. Lemme look over the code, then back to working on buildings...

Hmm. Checked the code. The angle / height stuff should probably be packed within the sections where RandomNumber has already picked the object, for efficiency's sake. No need to run it every grid coordinate, it saves a fair amount of processing time that way, since RandomNumber doesn't hit every square evaluated. I'll edit it and post it, just a sec...

Also, SizeOfUnitX,Z needs to remain in the inner loop, so that people can customize it for smaller solvers easily. I know, they could always just run multiple passes, but that's overkill for the vast majority of cases, tbh.

[smoth]

check ur pms argh.

[Argh]

Ok, fixed that, and a lot of other issues that came up. Now everything's packed into one local function ValidateMe() that runs only if RandomNumber picked a valid target, and validates the chosen square of arbitrary size X,Z, and I've put variables back into the RandomNumber pick sections to give mappers more control over their objects. Anything that can possibly be stuck within the RandomNumber picks needs to go there... hmm... I just thought of another speedup...

Last thing that this thing really needs, in terms of validation, is a way to get the metal values- both highs and averages, I think. I think it's bad that "forests" are being placed on mine spots- players will howl.

I can't think of a cheap way to do this, that won't result in a lot of misses, but I'm puzzling it over.

After that... I've gotta adjust everything one more frame forwards in sim, so that game designers get frame 1 reserved for their use, to place game-specific crap (creeps, treasures, what-have-you) and then frame 2, instead of frame 1, is then reserved for mappers to place really specific stuff they don't want overwritten by World Builder's iteration(s), like a fancy model of a castle, or a giant, animated volcano, or whatever. Then it's time to get mobile agents in the mix

[edit] Put new version up. See below.

[Argh]

Wheeeeeee. Getting the metal values is going to be fricking expensive. It took several seconds to compute, with a value of 4 map-units square. It bloody well worked, though.

I'll try something larger, like 32, and see if I can get decent results, faster.

[Argh]

And... we have a metal-detection algorithm. Adjustable according to metal values, too!

It's reasonably fast, checking 32 map unit grids, seems to result in near-perfect hit rates, and it reports metal values back, in the version, so that you can check results vs. clear spots. I'm commenting that out in the production version, of course.

Plus I've added a safeguard added to the code to prevent the "trapped coms" problem I've seen a few times, due to large-sized coms in P.U.R.E.

The only thing I can think of adding to this part of the code is to maybe put the expensive stuff, like the check for Units and Metal, outside the ValidateMe() loop, and run them only if the Unit being generated is blocking, so that it'll run even faster, on average (and not lose ground-cover).

[aGorm]

Well, it's definatly different... Not sure I like the way it makes a clump of features 1 unit, but then, meh .
If say you already embeded world builder into a map to take care of features (IE; cause you had your own stuff you wanted it to do) would a mod side version not run? (Or atleast the feature replacment/tree gen stuff, things like mod specific items would still need to go down...)? Or is the a way you can flag in a map not to run it at all, IE If your Acid Bridge would be daft with these and the crystle features are fine as they are...

Oh and.. features arnt visible unless there in your units sight range? That will need a fix. And Also they ghost into some weird uber unit...

aGorm

[Argh]

Not sure I like the way it makes a clump of features 1 unit

The clumping is to keep performance up. You don't have to use clumps- that's .S3O-side and BOS-side stuff, not the LUA. And a "clump" can be whatever you want. I'm just using big clumps because it's the most efficient thing to do.

You can just plant single trees, if you want to. However, I don't recommend it, it will not run well, due to LOS checks (the flip side of POV culling).

I suspect that if you don't bother running any time-based scripts (like the smoke code I have on the trees and stuff) then you can probably use a lot more single objects. However, you still don't want to place single trees, it gets rid of most of the performance advantages over Features. I'll look into how fast I can push that up, but clumping is probably the way to go most of the time, tbh. Of course, a "clump" can be whatever you want it to be- three giant trees, or hundreds of small grass planes...

The ghosting is because they're a Unit, and Spring ghosts Units to their state at Create(), instead of their state after Create(), which has always annoyed me, but meh, not much I can do about that. What annoys me is that it appears that you cannot turn ghosted stuff off, nor can you LUA it to not bother drawing the ghost.

Engine-side changes are probably going to be necessary- not drawing the ghosts would also help performance, probably by a lot.

If say you already embeded world builder into a map to take care of features (IE; cause you had your own stuff you wanted it to do) would a mod side version not run?

The plan is to run things in this order:

1. Game-specific stuff. If a game wants to place objects on the gameworld, it gets first dibs.

2. Custom singletons placed by mappers. If, say, you have a model of the Taj Mahal, and you want it placed at grid coordinates 1400,24238, then you'd do this then.

3. One or more random placement solvers. You're just looking at a single, map-wide solver in that demo. In the future, I expect people to have pre-built solvers and content as part of this- they'll be able to pick out "Forest no. 1", and run it from grid coordinates 0,0 to 1000,10000, then have "Desert no. 3" and run it from 1000,10000 to 10000,5000. And so on. This is just a very crude beginning.

There are no plans to flag a map so that game-side code can't run, period. Sorry, games have to come first.

Instead, I'm reserving very specific times for everything to happen, so that it causes minimal problems. If a game needs an Abandoned Fusion Reactor at a specific place, it's there, period, and nothing spawns on it. I don't think most games are going to want to transmogrify the maps in major ways, so I suspect most will tread very lightly, if at all, just as they do now.

It works the way it does right now purely because it's a demo, not because I think it's ideal.

Oh and.. features arnt visible unless there in your units sight range? That will need a fix.

We can fix that, per Unit, by making that particular Unit AlwaysVisible via LUA, I think. I'll make sure there's an example of that in the code, I don't think it'll be hard to get done.

However, you do not want to do that, for most things, like little plants or what-have-you. Save it for giant things, like an animated model of a volcano or whatever. Not little stuff. It'll cripple performance otherwise.

That's why maps with giant numbers of Features have terrible performance- they're not being culled. If Features could be culled, then I'll make a version of this that places thousands of cull-able Features, instead of hundreds of clumps of Units mixed with a few spectacular things. It'd still have problems- they'd be different problems.

However, I dunno when / if we're going to see this, nor how much more performance it'd give, and of course, they wouldn't be able to be animated, have death animations, etc., which is ultimately one of the priorities here- I think that Features that look great in screenshots, but aren't interesting during games... are nice, but not that interesting, tbh- at least with the super-pretty stuff in Dawn of War, they kept players out of it, keeping suspension of belief- it'd be hard to pull off in Spring, and every time I watch a "tree" insta-gib into a trunk, I cringe, frankly.

In short I'd rather see fewer things, but with great animations and sounds, than massive numbers of things that aren't at all interactive. But that's just my preference- this code can be used for any approach, of course

Players who want to see massive detail can just turn their IconDistance to the max- trust me, in P.U.R.E. at least, you can see as much detail as you want to.

[aGorm]

There are no plans to flag a map so that game-side code can't run, period. Sorry, games have to come first.

No game specific code, no, I didn't want that, I ment, IE, if someone ran AutumWood, It spaning a load of trees and stuff would be... not right. Seeing as how all that effort went into making AutumWood and the large trees, having them magiced away, or mearly having extra features added even, would ruin the map.

Making way for say, some sort of mod side objective (maybe a factory to capture or somthing) sure, but wiping all the current features and replacing on a map like that would be... bad. Not sure if you quite see what I'm getting at.

Basicly, what I think I'm getting at is that, PURE includeds world builder to sexs up maps, (and other mod's would asumadly also start to use it) there needs to be a way for the mapper to stop teh mod interfering in the Features part of the map, if its been handled by the map already. Even if that means no features what so ever (Trees on the moon?? that would be as bad as a "tree" insta-gib into a trunk...)

You see what I mean?

For instance... I see this as a chance to add some extra cool features to aftershock... whilst leaveing some of the current features in as features. (Or if in future you add the ability to make it add features as features, I could prob use that), however, game side code would then mess with everything thats been placed specificly, and insted of enhancing could ruin the maps good looks...

aGorm

::EDIT::
Oh and

However, you do not want to do that, for most things, like little plants or what-have-you. Save it for giant things, like an animated model of a volcano or whatever. Not little stuff. It'll cripple performance otherwise.

Actully, having features not visible when not in unit sight compleatly breaks the imersion for me. Things like the tiny plants on aftershock being culled, i could agree with, but anything visible as more than just a pixel when you tab zoom should always render. This goes especialy for the method your currently using were they totly block things, as you could set of an attack on teh otehr side of the map, only to find your tropps got stuck half way in a forest that wasn't there when you last looked... (due to it being culled)

::FINAL EDIT:: Oh and AftershockV2 has 5000+ hand placed features and I can play it happily at 1920 x 1200 4AA against an AI player at 25FPS, and my compter isn't that good.

[Forboding Angel]

Agorm...

You're making a mountain out a a molehill.

Just let the feature get created and then worry about tweaking the heck out of it. I need something like this for evolution somewhat badly... Also, mods can restrict the maps that that mod can be played on btw, and eventually this will prolly happen with evo, but that time is a little far off, because sometime soon I have to crap out somewhere around 20 maps... NO I am not looking forward to it, but something like this will make the massive task much more bearable.

[Argh]

No, these are good points here, and this brings up all sorts of philosophical issues.

Basicly, what I think I'm getting at is that, PURE includeds world builder to sexs up maps

Only in the demo, mind ye. I don't see a lot of reason why game designers would want to "sex up" maps, frankly, automatic or not. I think worrying about that is kind've pointless, tbh. My guess is that map-makers will do all the "sexing" on their own, given the tools, and release new "versions" that are the same ol' map, but using a tweaked version of this code that suits their needs.

It's a fun toy for P.U.R.E., but rather impractical, given that I don't want trees showing up on the moon or whatever. I could block it, or change the behavior based on the map, and I may do that until mappers start making scripts and getting on board, but meh, it's a pretty silly thing to do. It'd be better for mappers to pool their 3D stuff and use it from a common package, then tweak to fit their needs. No reason for game designers to be involved at all, unless they're going to be placing stuff that's specific to their designs.

Think of this as a form of L3DT, basically. It's a creative tool. It's not going to be very useful for situations where it's just being deployed on stuff without due regard for what's there, frankly.

Actully, having features not visible when not in unit sight compleatly breaks the imersion for me. Things like the tiny plants on aftershock being culled, i could agree with, but anything visible as more than just a pixel when you tab zoom should always render. This goes especialy for the method your currently using were they totly block things, as you could set of an attack on teh otehr side of the map, only to find your tropps got stuck half way in a forest that wasn't there when you last looked... (due to it being culled)

Well, the blocking factor is due to the fact that your troops don't know they're there yet, not that it's invisible. It's about exploration, basically. And not having stuff be the same way every time. Which is both good for replay value, and makes building complex content a lot easier.

Why make players play in a static place, anyhow? That's ultimately rather boring. At any rate, I'll look at the whole can-be-seen-from-everywhere stuff and see what happens. That'd take care of that, but it's probably going to make performance go downhill.

At any rate, everybody can have what they want. Mappers who want complete control can build stuff that gives them complete control. It's not super-hard. You could hand-place everything with .give, then script it to all be placed as a single giant script. Tedious, but meh, some people don't mind tedious. Or just do them as Features, in the traditional way, and take out the line obliterating them, and just use this for specific stuff. The game-side code won't obliterate the Features unless the game designer wants that to happen... and guess what? You can't stop them. It's just how it is.

I should probably put my philosophical position in here, even though I know it's probably an unpopular one with you mappers. Basically, I think that designing maps around mods was a bad thing from the start. I think that making the map formats TA-centric, and tied to a one-time format that wasn't reversible without the original content was a big mistake. I think that taking control away from game designers was colossal folly. Game designers should be in control of how a digital artifact operates.

Now, we are. LUA has set us free.

If a game design is built that doesn't like steep slopes- guess what, game designers can shrink your mountains down. If they want everything to feel like it's a different scale, ditto. If they want glowing, ugly Neutron Ducks everywhere on your map... they're going to get it. If they want to randomly vary your heightmaps... that's perfectly easy. I know that putting it that bluntly is going to cause cringes among you folks. I don't want to scare you, and I have no intention of doing this kind of thing. But it's possible to do now. I can't put that genie back into the bottle. Nor do I want to. It gives other gifts.

This approach gives you a terrific amount of freedom, too.

Freedom to, among other things, creatively re-interpret your maps, over and over again, with far less time involvement. How long does it take to compile AfterShock V2 after tweaking those Features, aGorm? An hour? Well, what about not having to redo a FeatureMap to change stuff? Just tweak some code, make a few new models, and voila... change happens, new stuff shows up, and no need to revisit the process of compiling it, ever again. Tweaks for things like altitude and frequency are just a few variables away, and you can fire it up in Spring and see the results in seconds, not minutes or hours. Why operate any other way? I don't see any real advantages, frankly. Why make only one map every six months, like you have been when you can make a dozen really nice ones in the same amount of time?

The issue of detail is another thing that touches on philosophy, so I'll cover it here.

Basically, that's for mappers to adjust, but players get the final call, now that I have a semi-practical method. Players can adjust their IconDistance settings to whatever they want, to adjust what gets culled. The whole idea there is to let them manage the performance of their machines. If they have problems with framerate, they can set it really low, or vice versa. It's not an either/or thing. Nobody loses, unless you want to force people to all see the same thing, which I would not be inclined to agree with. Try setting your IconDistance to 1000, .give 50 ScoutCraft and fly 'em about, on any given map. Watch what happens. Lots of detail gets revealed, then gets hidden when no longer in view.

ftershockV2 has 5000+ hand placed features and I can play it happily at 1920 x 1200 4AA against an AI player at 25FPS, and my compter isn't that good

Don't confuse my choices with what's possible By tweaking a few things here and there, we could pack far more objects onto a map than would be sane- it's not a limitation of the software.

It shouldn't be about how much, though- it should be about maximizing the player's experience. Which includes performance targets, in my book. 25FPS is not an acceptable level, to me, which is why I don't test P.U.R.E. on BlackLake Swamp, even though my machine can manage that, barely, with everything turned down and some minor action going on. I'm looking for targets of no more than 150K tris on-screen per pass, per frame. That means that on-screen foliage and etc. may only go into the 50K range, before performance is very obviously degrading due to polycount. It's a bad idea to throw polycount and huge texture sizes at stuff that's fairly small anyhow. There have to be better solutions. But I'm not going to be ultimately responsible for how this works on a given map, so meh, do whatever you want- I just think that just because this tool *can* pack more details in, at the same performance spec... doesn't mean it's a great idea.

[aGorm]

You're making a mountain out a a molehill.

Ummm... the only answer I can think of is "No Im not", Im affraid.

Forb... have you run it yet? I mean.. you wre asking for screens so I assume not...

And... seriosly.. is there anotehr mapper here otehr than myslef that has seriosly tryed to do stuff with features? As far as I knwo Im teh olny one thats realy tryed to push teh boundries... so surly that gives me some weight in discussing new ideas.

aGorm
::EDIT:: read assuming i posted first

[Argh]

And no, I don't think you're making a mountain out've a molehill, either. You're just not seeing the whole mountain yet It's a powerful tool. Like all powerful tools, it's going to take some getting used to, and practice, before it does what you want it to.

Nor is it perfect. I didn't even have the core algorithms even working until last Friday, for goodness sakes, and I've been moving as fast as I could to get the demo done, since I knew everybody was getting impatient with me, or thinking I was touting vaporware.

I'll be looking at your requests, and I'll try to accommodate them. I'd much rather that this operated as well as possible, short of the engine-side stuff that needs to be changed, which I've already requested some of, and will make a formal request for the rest when I get a list together.

[Forboding Angel]

Agorm, I have quite a few maps with over 8000 features placed, which includes trees and such, but regardless of the numbers game. Does errotep crossing, industrial mountain, Iron Mountain.... Does none of that count in your book as pushing feature limits?

TBH, atm there isn't a lot of leeway for features, and I welcome anything that gives me more control.