1
TLDR: Devs are wrong, it can be done. They can use computers and automation to do most of the tedious work of mapping, and if it's designed at all well, it will make balanced and interesting battlefields - likely surpassing the current ones we fight on. They can focus on CW and other cool things, and only have to make new stuff to go in the maps once in a while. Instead of map development being measured in terms of weeks per map, we will instead get maps per week.
Based on my knowledge of programming, I strongly disagree with the devs' viewpoint. Any task that can be reduced to procedures and equations can be automated, and there are ways to use the human labor at PGI far more wisely than just generating a map once in a while. Automating this process will free up human labor for work on community warfare, new mechs, and other very cool things. There is a lot that the developers and players could gain from this.
To start, we need to understand what a map consists of. The most obvious feature is terrain - that stuff our mechs walk around and stand on for the majority of the match. It starts off as a perfectly flat and tesselated plane, and it uses a greyscale heightmap to 'shape' this plane into a curvy and more visually appealing landscape-ish thing.
Why use a greyscale heightmap? The value (darkness/lightness) of a single pixel in the heightmap image can be used to derive the height of a single vertex on that plane. The heightmap allows developers to store an ENORMOUS amount of data about the game environment in a deceptively small file.
Once the heightmap and terrain shape are derived, there are textures (batches of images) which are overlaid onto the heightmap. This has the benefit of making the terrain not invisible, and also look pretty. A single texture on the terrain would be very boring, so there are multiple textures applied in layers; more of those greyscale images control the transparency of these textures, so that you get some nice-looking variance. The next time you are in a map, take a look at one of the smooth boundaries of a steep hill - you'll see the two textures bleed into one another.
Still, even with just terrain, the maps would look very bland and uninteresting. This is where models come into play - additional 3D geometry placed into the game world. Almost all of the 'interesting' stuff in MWO's maps consists of these models. All the buildings are models. All the destroyed bridges, all the rocks, and all the chunks of debris are models. Just like terrain, these have their own corresponding textures - but are not defined by a heightmap as the terrain is. All of these models have an X, Y, and Z coordinate position, as well as an XYZ scale (to determine how large and/or stretched the model is), and an XYZ rotation (to determine which way the model is facing).
Sometimes maps have water; this is a highly tesselated plane, just like terrain, except that it is non-colliding (stuff can pass through it), and the vertices move up and down all on their own, just like ripples and waves in water. This is usually accompanied by an imaginary volume, telling the game to draw water splashes instead of dust clouds when our mechs walk through it - and in the case of lava, to heat up or damage mechs. These imaginary volumes are useful in all sorts of ways - in fact, they're what tells the game that you're standing in a capture point.
Now it's time to begin identifying what parts of this can be automated, and develop an outline of a procedure to automate the map-making process. It's doubtful that we will ever have fully autonomous map generation, and have a thousand fresh maps released every tuesday - but we can probably use automation to step up map production to 5+ maps per week.
First, a randomizer needs to determine attributes about the general environment. This means determining if the map will be a forest, or a desert, or a tundra, or a city. A 'biome' if you will. This step is important, that way the game knows not to use swampy textures and desert cactuses on an airless moon. This step could be made non-autonomous, and manually set by a mapper quite easily.
Next, we need a heightmap for the terrain. There are already plenty of heightmap generators out there, which generate heightmaps according to criteria such as the desired sharpness and height variations of terrain features. It is fairly easy to produce random cliffs, or random mountains, or random rolling plains.
Specifically, for the purposes of MWO's heightmaps, once a heightmap is generated, we need to apply either a reflective or a rotational translation of the heightmap, so that there are two identical sides to the map. At this point, every hill and every cliff will have an exact mathematical duplicate for the opposing team. Then, at the boundary, we need to smooth these features via mathematical averaging of the heightmap data along any unusually sharp cuts.
The program needs to pick two approximately flat areas (on the heightmap, an X by X pixel region in which the value does not vary greatly) to place bases for assault. The bases will be placed in mirrored pairs, keeping each side identical so far. Conquest maps are more forgiving in this regard, and don't require perfect mathematical duplicity; a mapper spending two minutes and plopping down five conquest points in the map is completely fine.
After this, it is time to place major models - things which tangibly affect game balance. As you have likely noticed in-game, not every cliff is a simple chunk of geometry - sometimes, it is a wholly separate model, partially sunken into the terrain. Examples of 'major' models would be Tourmaline Desert's massive crystal spires, and Viridian Bog's mesas and clifftops that often require jump jets to access. For the purposes of the programming, 'major models' is anything that would greatly affect game balance, and provide ample cover.
The placement of major models would also be reflectional or rotational, so that each team gets a mirror duplicate of the map's dominating features. Similarly, the placement of these models would be governed by criteria defined on a per-model basis, to avoid cliffsides and spires inadvertently spawning inside one another and causing a huge mess. These features would only spawn if no other major models spawned without being separated by at least 150 meters or so.
Now it's time to make the two sides different - but not to an overwhelming degree. On the second heightmap pass, we apply a randomize effect, slightly raising and lowering the terrain, but not enough to sharply affect the already terrain-defining features. This is so the two sides do not look perfectly identical, and instead feel unique and distinct when finished.
Now we begin applying textures randomly to the terrain, to fit the biome specified earlier. A second pass will apply textures based upon slope and absolute height, so that there are no irritatingly awful sand cliffs or similar nonsense. A tiny bit of geometric pattern recognition in this phase would go a long way.
Now we can start placing minor assets, based on the (new) heightmap data. Stuff like radio towers, small rock outcrops, and pieces of cliffs jutting from existing terrain-cliffs. This, again, would be heightmap-dependent. You'll never have a radio tower try and spawn in the middle of a crater, or have a building try and spawn on a cliffside. Similarly, you'll never have the oddball-cliffside that decides to spawn in the middle of a largely flat desert; those will spawn only at sharp differences in the heightmap's value.
Now the program can add 'clutter' assets - stuff like random shards of gravel, cars, and trees. This is stuff that only looks pretty, and doesn't really affect the map or balance at all. These will be texture-specific, based on the existing textures on the terrain. Thus, you will never have trees growing out of a mountain of solid obsidian, or sharp chunks of gravel reminescent of rockslide-debris appear on shoreline or sandy textures.
Water is fairly simple as well; define a minimum height underneath which the terrain defaults to flat, and a desired uniform texture (underwater silt/mud/whatever). The water 'plane' can be placed by hand, and defining a single water volume underneath the map (except the water-covered bits) is fairly easy.
All that remains thereafter is fog color & density, weather conditions, sky conditions, lighting, and player spawnpoints, all of which can be placed by hand and finished into a working map quite quickly. Additionally, things such as tunnels will require a bit of love from the mappers, as that requires special transparency and noncollision within the terrain, and some manual touch-up of the seam between terrain and model.
Keep in mind this is an ultra-basic description of what the map-generator would resemble. Entire base-zones, flank-zones, and center-zones could be created from wholly seperate heightmaps, merged together into one heightmap and model-populated, delivering huge, impressively complex, and balanced environments by the dozen or by the hundred.
"But ABFalcon, having 1000+ maps in the game is bad, because it would take up more disk space than I have, or make the download take a really long time!"
Maps do not work that way. A map is just a heightmap for the terrain, a list of the textures the terrain uses, a few transparency maps to control which textures appear where, and a large list of XYZ coordinates that tell where the models are. It is NOT maps which take up huge amounts of hard drive space - it is the highly detailed 3D models and 2D textures which take up gigabytes of space. Once those assets already exist in the game's file architecture, a map needs only to indicate what goes where.
"The devs already said they weren't doing this, why bother suggesting it?"
Sometimes the devs cannot see the forest for the trees, and unusual or atypical solutions do not get considered. Also, for better or worse, the devs have indeed changed their mind in the past, and went back on things they said.
"THESE MAPS WOULD BE BORING AND RUIN THE GAME BECAUSE REASONS, RAWR, HEAR MY RAGE!"
Randomness existing within clearly defined mathematical guidelines will make the maps plenty interesting. In fact, they will be much more interesting than the handful of well-memorized and beaten-to-death paths resulting from having far too few maps. Imagine having to improvise and explore on every map, because the same map rarely turns up more than a few times a month. Near-mathematical mirrored maps are also much more balanced.
Edited by ABFalcon, 03 December 2014 - 12:36 AM.
