Planet size contest ;)

I made a video looking at the planet editor, and I took a look at size comparisons.

Here is a link to that section:

http://youtu.be/lUmsb2e90Jg?t=1m31s

For those of you that didn't like the scale of the current mountains.

Wow, that looks really nice. It seems like a way better scale for height variation then what's currently in the alpha.
A video maybe?

That looks like a whole-lot of no-fun to play on.

Care to elaborate why?

High-ground and terrain advantage have been staples of RTS for a long time. They add strategic reasons that make holding some bit's of terrain more useful than others. Currently, PA's maps feel a little flat, and although the amount of vertical range may vary from planet to planet, a bit more would be welcome.

And did such... excessive undulations in the playing field make for good SupCom matches?

SupCom has one serious problem: it's hard to see real terrain height sometimes. In PA it's should be much easier because spherical maps. I personally feel that one-height level maps in PA which present currently isn't perfect.

If you say so. I don't think "because spherical maps" is a good argument though.

Wavy land like that, on the same scale as building bases, they're either going to look ugly clipping through terrain, ugly "sticking out" perpendicular from the point they're on, or ugly as the terrain dynamically flattens around them leaving them with a cliff on half the sides.

With hills that big you would be constantly shooting the ground and forced to zoom in close to work out which part of the terrain you can actually fight on. Could we do with some slightly bumpier terrain? Yes a bit, but not nearly that much.

In my opinion, the issue with SupCom was one more of unit intelligence than terrain contours. I agree it was irritating to watch units continuously pour all their firepower into a small hillock. However, I would rather retain the terrain, and have units move to where they have a clear line of fire when they attack. This creates genuine reasons to hold high ground as the very nature of ballistic simulation means units climbing the hill will be at a disadvantage to units already on the hill. Furthermore, it creates variety in unit choice. Units with a high fire arc are better for dealing with these regions than units with a low fire arc, the caveat being that high-arc shells are slower, and easier to avoid. I would certainly expect bots to have a better time of dealing with hilly areas, and would love to see the interplay of these factors reflected in the game.

The problem isn't hills, it's how the units use them.

All of which cost CPU cycles. Now the AI must not only predict its shot with reguards to the enemies movement... but also find the "best" place to fire from?

Where is that place? So every single unit must scan a non-insignificant area around themselves, transposing an imaginary version of itself in those places to find a firing solution?

And what happens when if finds that place, or places? which does it move to? the nearest? What happens when the enemy has moved when the unit gets there and the solution is no longer valid?

How many calculations are you running, every tick of the simulation... for Every. Single. Unit?
Are you sure thats a tenable solution?
Are you sure those calculations wont break the server?
Are you sure that if they don't break the server, that it is the best use of CPU cycles?

Come on, this isnt the first RTS game that has to deal with this "problem". I´m no programmer, but i´m sure there are good solutions to this.

But maybe i´m with you to have a more "plateau"-stil with "ramps" to get on, than constantly "wave-like" mountainareas...

SmallCpu that's gorgeous!!!!!

I want to see more!

....ever

In lieu of unit intelligence of that kind, it would require more micro by the player. Just looking at those mountains I can see some pretty devastating angles to attack from that could get you killed without being able to shoot back, which actually sounds pretty interesting perhaps as an option for a single planet.

Then why have we never seen a game take advantage of those solutions of which you speak?

TA had a workable solution. You can't say CPU usage was a problem with that game

The solution doesn't have to be perfect. It just has to mitigate it enough to be useful, and, most importantly, be predictable. This doesn't mean randomness can't be used, just that how it is applied should be known to the player.

Didn't TA make the unit move in a random direction and try again?

And... at the time... CPU usage was a problem for TA.

I remember when I had to measure my CPU clock speed in megahertz... and it's a small number I'm talking about too.

If that's all it did, it still worked. Shouldn't be too hard to make it even smarter.

I first played on a Pentium II 233 MHz, 128MB RAM. That was pretty beefy at the time :lol: