I'm not sure how many of you remember how it worked in RTS games of the old days (hint: TA wasn't the only RTS with such mechanics), but for the younger players you could as well try WoT or alike to get hold of this topic. What I'm talking about, is the impact of gravity on unit movement. Right now, there is none. If it was pathable, even the most heaviest tank could climb a 90° "slope" with ease. Actually without even slowing down. Some goes for the opposite direction, visually moving down a hill has no effect at all. So much for what we don't have in the game yet. But that opens another question: What does it actually mean in terms of gameplay to have gravity involved into traversing terrain in a specific direction? For once, it creates some type of one-way street. Movement on such terrain is asymmetrical, it's much easier to advance in one direction than it is to go the other way. In the worst case, you will even need to make a detour to bypass the one-way street. Second, it's also a method to create more diversity between planets. The impact of terrain on movement depends heavily on the gravity field of that planet. On a moon, even fat tanks are capable of crossing most difficult terrain. On a planet with Jupiter's gravity not even a spider bot might be able to traverse a simple slope. Last, but not least, it allows for more unit diversity. You know the "bots vs tank discussion", where it usually ends with the claims that bots and tanks either have incomplete role sets or they will become essentially equivalent. Tanks and bots being able to take different paths can make them have very similar roles (and controls!) while in combat, but behave completely different when it comes to options in choosing the attack vector. We do have a hard hack-around in the game currently with Bomb-O-Bots capable of ignoring obstacles completely and Dox being amphibious, however these features are very situational and usually don't play a role. That leads to yet another question: Why does the hack not behave as expected? As for this question, one has to look at how the maps are actually generated. Obstacles are placed in a random fashion without any intent, only with the characteristic that blocking objects form more of an isle in middle of a plain, rather than actually shaping paths. Just some examples: We have oceans, but we don't have rivers. Without rivers, e.g. naval is usually stuck in most maps. We have mountains, but these mountains don't form mountain ranges. And if they still do by chance, they don't have any passages at all in return. Canyons are forming large scale obstacles, but they are usually far away from any other feature. Alls these problems inherit from the way these maps are generated. Random noise generator generates two 2D noise textures and features are then assigned according to these textures. So essentially, features are placed completely random. That, however, is not how maps in RTS or real terrains are usually designed. When creating a map, you would usually start by defining a set of locations which are supposed to be of interest, e.g. resource clusters, crossings, build/battle fields, shallow and deep water. Then you start building paths in between. Usually you want to make sure that all areas of the same pathing type are reachable in some way (that's also what the current terrain system in PA achieves, at least for either naval OR land), but you don't want to fully mesh adjacent regions in most cases (that's where PA fails). Instead you want to specifically create one-way streets, passages with limited capacity (e.g. a choke) or natural barriers which are only open to specific units (e.g. cliffs or fords). Then you start extruding the defined locations and define the precise locations and dimensions of the intersections, according to the intended traversability. Once the outlines are defined, you can generate the elevation map to shape one-way streets, completely impassable terrain and water levels, and start placing obstacles along the borders where no, or limited, pathing was intended. Finally add art assets to the individual regions themselves and the map is done. And now for the final question: What other issues are to be expected? Pathing works slightly different in PA than it did in older games. You can't calculate for units to take a run-up with the goal based shared navigation field. That means, that the path chosen always has to be the "safe path" where units could always climb all slopes from stand. This also means that slopes actually have to affect the top speed rather than the acceleration, meaning that units can still accelerate normally when moving upwards so that the cost calculation isn't screwed over. This is not physically accurate, but still plausible enough. Accounting for different gravity is rather simple though. "Planets gravity" * "unit gravity scalar", and top speed on a specific terrain expressed as "base top speed" * (1 - "pitch" * "gravity") whereby a pitch of 1 expresses a 45° slope. If "pitch" * "gravity" exceeds [-1,1], the terrain is blocked for that unit. (It won't be able to move upwards, and it wouldn't be able to break when going downwards either.) Having a feature like this was clearly originally intended when diverting between bot and vehicle tech (and it was implemented in TA too), but as you can also see there is still a lot of work to be done before it can be put to any good use. TL,DR: Having gravity and slope angle affect movement speed (up to complete stop) allows for more one-way streets in maps, as well as more variance in between planets. Having units respond steppless to terrain difficulty rather than defining hard limits allows for more diversity between units, apart from the fixed role scheme. Map generation process isn't suited yet either. The generator needs to be aware about creating directional passages and detours on purpose, rather than just placing obstacles randomly somewhere in the landscape. Graphics to visualize some of the stuff and/or POC may - or may not - be added later on.
As far as visualizations you could add cliff effects (rock texture) on slopes that not even bots can climb, and some sort of rockslide texture or partial cliff texture (cliff with patches of dirt/grass/snow/sand) on slopes that bots can climb but vehicles can't. They should make it so that units can go down slopes that they can't go up but at a reduced speed, because making them take a damage penalty but go full speed would need a specific command to make them use these paths or player would get mad that their units took a dangerous path and damaged themselves, which would be a PITA. And making them take no damage penalty at all would just be weird (tanks flying off of cliffs into combat without any penalty) For slopes that anything can go up or down but with a speed boost/penalty just leave it looking as-is. For the slopes that only bots can go up at a reduced speed, give them the same speed penalty while going down the slopes as they get going up (if you've tried sprinting down a really steep hill, you know why) This seems to me like the easiest way to implement it while letting players easily see the hard boundaries of both unit classes. Adding different textures for all slopes IMO would take too long and be hard to distinguish anyway, but not adding it for the most important ones would be frustrating (like currently when a fissure in the ground barely extends into a lake beside it, but your tanks can still go through the shallow water around the side of the fissure, but you can't tell until you drive them over there and try it because it's just on the edge of deepness that they can cross through)
This is all very technical stuff, and can probably be saved for later, but one thing that probably could be easily implemented right now is how a terrain effects a unit's movements. How vehicles with treads would behave in certain terrain types: Snow: Vehicles move slightly slower and take longer to turn. Dirt: Vehicle travels just like they do now. Grass: Vehicle travels slower than it does on dirt, but faster than on snow. Sand: Vehicle moves slower than in snow. Heavily impedes vehicle turn rate. Rock: Vehicle gains a small speed boost. Metal: Vehicle gains an even larger speed boost. How wheeled vehicles behave on terrain types: Snow: Vehicle slips and slides, and generally has a hard time moving about. Dirt: Vehicle behaves normally. Grass: Vehicle travels slower than on dirt, faster than on snow. May slide around a bit, grass is pretty slippery IRL. Sand: Vehicle becomes excruciatingly slow to move and turn. Rock: Vehicle gains a moderate speed boost Metal: Vehicle gains a moderate speed boost, slips and slides like on snow. How bots behave on certain terrain types: Snow: Bots slip and slide, may fall over. Heavier bots will slip less frequently than lighter ones. Dirt: Bots behave normally. Grass: Bots behave normally. Sand: Bot becomes slower. Rock: Bot behaves normally. Metal: Bot gains small speed boost. Tl;dr: Don't drive in snow or sand, kiddies.
Sorry, "what you see is what you get", it's been one of Uber's core ideologies for the game. Basically a unit will never do something out of the ordinary, you can always tell what it can do and it never changes. Though I suppose you can at least see the terrain differences.
I guess terrain affecting units could probably be implemented as an optional thing when starting a game, like dynamic alliances.
And now a bit more fleshed out process for procedually generating planets with increased gameplay value. Critics and suggestions always welcome, because I think I feel like actually implementing that stuff. If you found any flaws in the concept, go forth and tell me. Central claims A map should always be designed with intention of providing interesting game play. A map consists of zones. Adjacent zones can be interconnected by pathways. Zones can differ in size, role and terrain type. Pathways can differ in flow capacity, passability towards certain unit types, and one-way characteristics. There should always be at least one valid path to reach a zone from any other zone. Claim #6 does not apply when a broken pathability is intended, e.g. islands on an ocean planet. A map is defined by type, size and location of zones on a planet of a given size, as well as defined passages with traversability attributes. In addition, a global seed determines random placement of features. Generation phases Map generations starts with generating a set of root zones. These zones determine the location and presence of distinct terrain features like oceans, land masses or special terrains. Based on rule sets, additional zones are added adjacent to already placed zone. This is an iterative process which only ends when there are no more rules matching to any location on the map. The order in which rule sets are tested, is determined by the global seed. Each zone generated this way has a assigned a weight which expresses eviction of adjacent zones. A Voronoi diagram is built with this weight in order to determine adjacent regions. Passages for adjacent regions are added based on rule sets. This is an iterative process which only ends when no rule can generate any more passages. The order in which rule sets are tested, is determined by the global seed. All unused / blocked passages are filled in with dummy passages. At this point, the map is merely an abstract graph which defines all strategic component of the map. This state defines the entire map already and it can be used to regenerate the map. A map can therefore either be distributed as a sole seed or in this form. This allows for hand crafted maps using the same procedural generation process as for purely random generated maps. This intermediate state is small enough to be distributed over the Internet on demand. Relative elevation of adjacent zones is computed based on-one way characteristics of passages. Unpassable passages don’t yield any constraints. Absolute elevation of zones at each border is computed based on relative elevation and hard constraints such as ocean zones having a minimum water depth and land zones having a maximum water depth. This is an iterative relaxation process which aims for fulfilling constraints generated by the previous step as well as avoiding large inclines inside each zone. Cliffs occur naturally when two adjacent zones differ in average elevation and there is no constraint which enforces matching border elevations. Edges from the Voronoi diagram are copied and tessellated. Newly created vertices are being moved based on rule sets to generate outline which are more organic / natural for the corresponding zone type. Impassable zones are computed by taking all edges generated in the previous step where the passage isn’t 100% passable. For passages with limited flow capacity, gaps are inserted which match the desired capacity. Passable and impassable edges are both stored. Final elevation map is generated by using computed border elevations for all passable edges and interpolating elevation inside each zone. For non-passable edges, average elevation is used instead. For the center point of each zone, the originally intended average height is being used. Passable edges of adjacent zones are being matched. Final height map is smoothened by applying a blur filter. Interior and exterior features are being added to zones based on rule sets. Exterior features can be matched on impassable edges and can be declared mandatory, e.g. concrete walls on enclosed sides of a fortress biome. Non-mandatory exterior features are optional if an mandatory, blocking feature has already been used to block of an edge. Interior features must not block pathing from any edge to any other edge. Original on Google Docs: https://docs.google.com/document/d/1kV-ElGRALbk8bxE2UAKgMbAVA6T6ov8vKjFPF9CHKpg/edit?usp=sharing TL ; DR: Forget about it. You can't cheat around reading it.
I'm a total newb in this area. Was just wondering if this procedure is deterministic and if it allways result in a "coherent" map ?
Deterministic: Yes, as long as rules are always applied in a deterministic order. Being able to restart the generation from an intermediate state requires an additional re-initialization of the RNG at the corresponding points. Version control for rule sets would even go a step further in determinism than what PA currently provides. (Currently, if Uber changes any of the terrain feature declarations, this also affects replays. Meaning that different features can be placed in the same location.) Coherent? That can't be guaranteed. I'm not sure, but I think it might be possible that the zone generation process runs into a state where it is forced to place zones adjacent to each other which have incompatible types, so traversing is impossible. E.g. deep ocean right next to highlands. But chances should be rather low for such events to occur if there are no misbehaving rules. When I say RNG, I actually mean a pseudo RNG which generates a seemingly chaotic, yet deterministic sequence of numbers when initialized with a constant seed.
Thanks a lot man. Very interesting. Any idea if it's reasonable to assume the way planets are generated can be altered with modding ?
I do think so. Right now, it's already possible to swap out the rule sets for planet generation by mod. I think its safe to assume that it will also be possible to provide entire custom planet generation procedures which just yield a list of features for CSG and brushes together with some base geometry.
Yea, this would be very cool to see. Its very had to have diverse unit interactions when the playing field is generally the same across maps. Look at starcraft, and how much of the game revolves around chokes and ledges. As for your implementation idea, I'm going to look over it a bit more carefully later, but one thing you might have left out. Since you are placing a pretty large emphasis on making passage ways between zones, then I would think you also need a way to enforce or at least be aware of the pathability of the entire border region. You could enforce this using elevation differences, but that might not always make sense, if for example your rules generate a desert zone next to a forest zone but with similar heights, then you cant really have a limited capacity passage. Instead, you would need to generate a mountain range along that border, and then cut the passage through that. I am not sure I did a good job of explaining this all, did that make sense?
It does make sense. It's the 3rd last step of the generation process, and obstacles are then placed in the last step, called "exterior features". Elevation difference alone doesn't define borders. It's nice to have, since it allows the use of more cosmetic appealing features like cliffs rather than walls, but it's not required to separate areas.
