Spring RTS Engine

Ok, for my purposes, it only needs to run once. So don't worry about CPU costs- it's going to be very costly, but only for one frame. After that, it's not going to run again. I run a second pass, making everything Neutral, etc., but that's straightforward, and it already works. So, two frames of big CPU usage, then it all calms down, and it's down to script speed, LOS issues, and other performance drains, but this will help a lot, because I can then play with the size and frequency of clumping to help mitigate this, instead of relying on the frequency of Trees and random factors.

The stuff for mobile actors will need to check the blocking map, if I'm going to want to place them during gameplay, and that will be rather expensive, but that's a problem for another day.

So, checking the blocking map and mapping out "no-go zones" for the Commanders should be fine. Simply block out a 96X96 zone around each Commander, or the closest matching set of grid coordinates, and that's fine.

As for sizes, in an ideal world, it'd read a config, which would tell it that it was looking for a "good spot" that was 32X32, 64X64, or 96X96- I think any larger than that is probably pointless, as it'd lead to a lot of bad solutions. Then, once it's found a given "good spot", I can put in logic placing actors with X,Z units of the spot's center, to confuse the issue of it using a grid-based system and make it feel natural (it'd be good if the x,z coordinates of that center were readily-available in an obvious-to-Argh variable, like "centerOfGoodSpotX,centerOfGoodSpotZ" lol

If this is only run once that simplifies things. Would you only want it to give you nice big areas like that? I was planning something better to place individual units, but I can make a faster, simpler version that just finds you large areas at somewhat lower resolution.

Faster, simpler is probably better. Once it's found a "good spot", the logic needed to randomly place an object within a random X,Z of the centerpoint is trivial, and I have already written some COB stuff that handles the rest. I'm going to have a shot of my "mini-forest" concept up here in a bit, when I get done messing with the uvmaps- large amounts of randomness, looks like a clump of forest, but only one Unit is involved, to cut down on LOS-handler issues (that's the killer- I've solved everything else).

Getting closer now. Just need to adjust a few minor things.

BTW, that scene is rendering at 90+ FPS, on my rig. Up from 50, before I started lowering the frequency of objects by using these big meta-objects. Should really help performance a lot. Too bad we don't have !#*@*! hitboxes, though, hit-detection's going to be a pain. Pathfinding is simple for now- it's impassable terrain. Meh, that's how the vast majority of games deliver this kind of eye-candy, and I don't really think players will complain a lot.

Yes, I can see that with cities, meta-objects could have set "streets", 4 wide or so, and the buildings could be procedurally generated within the "blocks" within... could be very cool.

Smoth, what about those buildings you have? They're really low-impact individually, right? They might be perfect for this, frankly.

Oh, and Lurker, just for reference... those are 18X18 meta-objects there, to give you a sense of scale (that's Supreme, not Small, heh). I'm thinking city blocks can use 16X16 meta-objects, and be awesome as hell to look at, yet perform very well, with enough scripting.

I hope it's obvious why that's cool

Argh wrote:and I don't really think players will complain a lot.

we are still talking about Spring players amirite?

.. you obviously have a vastly different experience of spring players than i do ^_^

and if they are units, not features... you could give them a factory-type yardmap and a script that 'opens' the yardmap on creation. (assuming they are a building and not a very very slow mobile unit.)

This is awesome...

Well I'm going with the more complicated system after all. I think I finally have the basic algorithm coded, after a few hours of immeasurable glee. n being the diameter of placed objects, it can do most of the placement processing in O(n) time, with a little O(n^2). But it's 3AM and time to do my homework.

I think I'll probably set it to use 4x4 resolution. It depends on the speed test results.

and if they are units, not features... you could give them a factory-type yardmap and a script that 'opens' the yardmap on creation. (assuming they are a building and not a very very slow mobile unit.)

Not possible, given that I'd need a Yardmap that was custom-mapped to the randomized positions of the sub-objects. I read KDR's new addition to the SVN (support for "y" yardmaps, and what sounds like a way to access it through scripting, although I may have just mis-read that)...

Even with that, I'd need a powerful solver to get this issue licked. The final locations of things are indeterminate (and should stay that way, imo- static implementations are fail).

I think I finally have the basic algorithm coded, after a few hours of immeasurable glee.

Glee! Er, I mean, "gosh, I hope that you didn't hurt yer brain doin' that". I'm really looking forwards to a method of placement that doesn't rely on the arbitrary tree-placement on most maps, and some random math...

Soo... for example... how waould a mapper go about placeing a tree in a certain positon with this system? Is that possible? Or do u have to let it place them randomly within an area specified??

Also... if things are units... are they reclaimable?

So many queastions... but no time to type them up. It looks good but im paranoid this is goona take contole away from a mappin perspective...

aGorm

To answer your questions, in brief (I could go on and on, I've been waiting for this to become possible for a very long time now):

1. If you want a tree at a very certain position, you'd just script it. Easy enough to do, and I'll include example code. This isn't about single trees, though.

The random stuff is basically there to save you a lot of time, and to make your maps more interesting. Static maps just aren't very interesting, compared to stuff that's more dynamic. And the randomness adds a lot of replay value.

For example, you can put minefields into a map, that won't be at the same positions every time. Players know there will be mines, but will not just be able to go to a given spot and get rid of them.

As another example, say you want to do a dense jungle terrain on a map. Before, this was practically impossible to get good gameplay on, and required enormous time investment by a mapper. When this is done, you'll just be able to set up a LUA Gadget that will auto-populate the map with stuff- and it'll look different and new every time.

Moreover, each object can do different stuff. In fact, they can do anything a Unit can do- which is, well, basically anything, given what can be done with LUA. For example, you could have a randomly-generated forest, with a scripted, non-random object in the middle, that, if captured, allowed units to be teleported elsewhere.

Or you could script in a custom Ancient Mecha, that waits to be captured by a player, and then is controlled by that player (I have an example object like this, that goes from Neutral to able to fight other players, already working).

And, when I get to it, you'll also be able to add mobile actors- Units, basically. Some could be hostile to players, some could be helpful, and most neutral- things like animated animals, for example.

Lastly, by combining LUA with COB, I've already built some fairly sophisticated procedural-content stuff. That's what that cluster of "trees" demonstrates- each "tree" is part of a single object, manipulated via COB to go random places, be at the right height relative to the map, and when the cluster of "trees" is dead, they have death animations!

I have one more demo object I want to try and build today, after I've slept- a fully procedural building. It'll have elements that look vaguely like a ruined temple, but each version will be a bit different, because different parts will be moved around, hidden, and so on. I've gotten quite good at building models with a lot of clone parts, and so forth, due to work elsewhere, so I'm thinking that I can probably pull this off. If you see the rocks and various other flora in those shots, especially that hillside one- that's one object you're looking at! Pretty major COB required, and a very interesting .S3O, but not rocket science!

So, basically, I do *not* want to take away control from mappers. In fact, I want to make it possible for mappers to build much more interesting content, and lower the amount of time it takes them to build great maps.

Random placement of objects will help a lot, because instead of a static work of art, you can have non-static elements, mixed with static ones, to make player experiences never quite the same way each time, and if I get my wishlist items (that blocking-map thing is one of them), you'll be able to make very sophisticated stuff, but with much higher performance than with static Features, and much easier to work with.

But you do not have to go the random route. You could use this stuff to build totally static maps, but with much more interesting content. At first, this is going to be in the control of game designers (i.e., me, P.U.R.E.'s next version, as a showcase), but I'd like control to revert to mappers, where it belongs. Gadgets can be run map-side, and this is probably the place to do this.

Ooh, and I should note, also... that this finally provides a very, very concrete reason to pool stuff together, and build "feature packs", like the olden days.

2. Units are absolutely reclaimable, if they are set to be (there is a reclaimable=0 tag for Units, IIRC, if not you can just make it take pretty much forever). The only major problem with reclaiming is that area-reclaim commands don't work on Units. That's not as big of a deal as it sounds, though, because with this stuff, you're generally going to use far fewer procedural objects than you'd use Trees, for example.

Trust me, I've been testing everything

Hmmm... so let me get this stright... If I used this for trees... and then someone wanted to build were the trees were, the tree wouldn't get reclaimed, infact the building would show it cant be built there?

Only... that seem a tad of a step backwards (even if there are about 20 steps forwards in other areas... my models are all set to be randomly generated by cob scripts, so I can make my forests way better in 1 swoop.)

Also... I disagree and say area reclaim is important.

Also... random tree polacement is cool, as long as you can set were to place them.. does that make sence? Not just 1 tree... but say I could go I want a forest of 30 of theses trees HERE, and a forest of these trees HERE... get what I mean? Random... but were I want them.

aGorm

Hey Argh, want me to start throwing some buildings together so that we can have procedural towns / villages / things? Ideas for buildings (these would all be different sets, ie 'Houses' would be a group of procedural houses etc):
-Houses (two storey, one storey, large, small etc)
-Flats (with garages and cars etc)
-Wind power thingies (turbines and a control station)
-Solar farms (randomly placed panels etc. Turn to sun for extra win!)
-Actual farms (greenhouses, buildings, sheds, grain silos etc)
-Power stations (buildings, turbines, grids, chimneys etc)
-Warehouses (obvious)
Could even have little turret things and defensive shields if you'd like

Guessmyname wrote:Hey Argh, want me to start throwing some buildings together so that we can have procedural towns / villages / things? Ideas for buildings (these would all be different sets, ie 'Houses' would be a group of procedural houses etc):
-Houses (two storey, one storey, large, small etc)
-Flats (with garages and cars etc)
-Wind power thingies (turbines and a control station)
-Solar farms (randomly placed panels etc. Turn to sun for extra win!)
-Actual farms (greenhouses, buildings, sheds, grain silos etc)
-Power stations (buildings, turbines, grids, chimneys etc)
-Warehouses (obvious)
Could even have little turret things and defensive shields if you'd like

Yes, please.

Guessmyname wrote:)
(randomly placed panels etc. Turn to sun for extra win!)

Animated for extra win. Starcraft-like features anyone?

Dam I sooooooo want this... it better be everything I hope it is.

aGorm

aGorm wrote:Hmmm... so let me get this stright... If I used this for trees... and then someone wanted to build were the trees were, the tree wouldn't get reclaimed, infact the building would show it cant be built there?

Only... that seem a tad of a step backwards (even if there are about 20 steps forwards in other areas... my models are all set to be randomly generated by cob scripts, so I can make my forests way better in 1 swoop.)

Also... I disagree and say area reclaim is important.

Also... random tree polacement is cool, as long as you can set were to place them.. does that make sence? Not just 1 tree... but say I could go I want a forest of 30 of theses trees HERE, and a forest of these trees HERE... get what I mean? Random... but were I want them.

aGorm

It's probably possible for one of the spring devs to add a unit tag that allows units to be area reclaimed. For the mean time you will need to be careful with your implementations since like you say, if someone were to want to build a building where a tree is it would be alot of work. But after the tag is made it would simply be a matter of making sure the tree unit had the area reclaim tag.

Me likes the buildings. Can I have 'em?

Doesn't guess give you virtually everything he does anyways?