I'm Index Librorum (aka Prohibitorum), and this is a showroom for my maps and other projects.

For most of these maps, the terrain, map-wide assets, and stratum masks are made using Quadspinner's Gaea. For questions related to my workflow, contact me on discord or here on the forums. (though discord will get you a reply significantly faster)

Gaea tutorials

All tutorials may also be found on the FAF wiki.

• Basic introduction to Gaea and how to use the program to create a heightmap for FAF maps
• Producing terrain masks in Gaea
• Texturing in Gaea

All projects:

Project Mesa, Project Situs Impactae, Project Praetensus, (Adaptive) Project Dust, Project Tabula, and Project Luminary, Adaptive project Luminary Maxima, Project Albus, Project Vortex, Project Fluxus, Project Mesa HD, Project Tumulus, Project Glacies.

Unless otherwise mentioned, all maps shown here are in the vault.

Latest Project:

We need ice for our drinks, commander. Remove these enemies and secure that ice! -- Licensed under CC BY-NC-SA 4.0. Based on a map design by StaySane0.

Click here for more information on Project Tumulus.

Well this is embarrassing. We were supposed to drop on the other side of this plateau... Looks like the enemy is already setting up bases there too. Kindly remove them so we can pretend this mistake never happened.

Project Tabula is a 20x20km map, although the main playing area is closer to 15x15km. Eight commanders may be spawned on top of a large plateau, which has a partial collapse in the middle effectively creating three main lanes. Access to the terrain beyond the plateau is blocked; although planes may use the airspace, units can not be dropped outside the plateau.

This is the first of my maps that uses clouds. Feedback on this feature in particular is highly appreciated.

The map is licensed under CC. BY-NC-SA 4.0 and is compatible with AI.

Gaea tutorial: A basic introduction to mapping with Gaea

The various map projects I've made have all been made possible by Quadspinner's Gaea, a terrain design application for VFX and games. Gaea is an industry standard and a great tool to significantly speed up creating or increasing the complexity of masks, heightmaps, and decals. Because of FAF's peculiarities and the fact that the game is more than a decade old, the process of producing these assets using Gaea is a bit involved. Being the shiny beacon of enlightenment that I am, in this tutorial series I will explain my process for creating all the relevant map assets in gaea (see figure 1). This specific tutorial will discuss the basics of Gaea and how it can be used to create the main heightmap for your terrain.

Figure 1: a breakdown of the map Project Luminary to show all the assets generated in Gaea. Note: some of the stratum textures are stock-FAF textures and were not created in Gaea, but are here included to illustrate the different components of the map.

Prerequisites

This tutorial assumes you've got a basic understanding of image editing and FAF mapping. Additionally, while this specific tutorial will explain some of the basics of visual node based programming, the technique Gaea uses to create the assets, it is recommended that you take some time to familiarize yourself with the concept and Gaea in particular. This 6-minute video is highly recommended, as is giving the general documentation for gaea a read. Using this node system may look daunting at first, but is very intuitive and easy to learn.

Required tools

Required for this tutorial is a copy of Gaea (the indie version is free to use and more than sufficient for maps up to 20km), which can be downloaded here. Additionally, an image editor such as Photoshop or Gimp is required, though the free to use online photoshop-clone Photopea works fine too. Finally, you need to have installed the FAF map editor.

Footnotes marked as '[0]' where needed. Notes are added to the bottom of the tutorial.

When specific nodes are referenced, they are highlighted like this: Node. Specific parameters for these nodes are written like this: Slope, 30, 90, 0, to specify a Slope node with Parameters 30 (min), 90 (Max), and 0 (Falloff).

Introducing Gaea

Gaea is a graph-based application for creating terrain and focussed on providing techniques to simulate realistic erosion. To create these terrains, different nodes are linked to eachother. Nodes affect or combine with other nodes to create complex shapes and structures. While working in Gaea, you will navigate between several panels.

The workspace

As of June 2023, a typical workspace in Gaea might look like Figure 2. The workspace can be configured to your preferences, with different panels moved or scaled. The largest part of the screen is taken up by the viewports and the graph surface. The viewport shows you the terrain and masks, the view of which can be rotated, scaled, and panned. Optionally, you can press the 2D button in the viewport toolbar to show the second, top-down, viewport. Below the viewports, you will see the graph surface, where your nodes and their connections are displayed. Clicking on a node will show the contents of that node in the viewports.

! Tip: you can lock the viewport to show one specific node by selecting the node and pressing F on the keyboard. The node will be marked with a small green circle on the bottom right of the node to indicate the viewport is locked on that node. This is very useful when you are adjusting parameters of nodes earlier in the chain, but want to see the result on a specific node later in the chain. Press F again while selecting the node to unlock the viewport.

Figure 2: Typical workspace of Gaea. Colored accents added to highlight the different panels. Red: Main toolbar. Orange: Toolkit containing various nodes. Yellow: Viewport, 2D viewport, and viewport toolbar. Green: Graph surface. Blue: Properties panel.

The toolbox contains all the nodes you can put onto the graph surface. Nodes are grouped by type, and have a specific colour to signify which group they belong to.
Clicking on a node will also reveal the properties panel for that node. Here, you can adjust the effect or contents of the specific node.

Above all the other panels is the main toolbar, which contains a few important things to discuss. First, the viewport resolution can be selected in this panel. It is generally recommended to select the resolution that you will be exporting your heightmap in. Gaea recalculates the terrain and parameters of the nodes every time you switch resolution, and the resolution can drastically affect how the terrain is shaped. Aside from the obvious increase in fine details, you might find that elements have changed shapes or moved when comparing different resolutions.

! As the terrain changes based on the resolution it is rendered in, creating high-resolution map-wide decals might result in some mismatch between the heightmap and the decals. A method to prevent this will be discussed in the tutorial on map-wide assets.

Figure 3: Showing the differences between the viewport at 0.5k, 1k, and 2k resolution. Note the increase in fine details.

Another important section of the main toolbar is the save button. Attached to the save button is a smaller button labeled with (+). This button will create a version-copy of your project: if a project is named 'Project Luminary V1', clicking this button will create a new savefile labelled "Project Luminary V1001". The next time you click the button, the new savefile will be labelled "Project Luminary V1002". I cannot stress enough how important it is to regularly create a new version. Since before I started using Gaea, the undo and redo buttons have been rather dysfunctional. Maintaining a recent version of your project will ensure you do not lose large sections of your work when you inevitably have to undo changes that the undo-button refuses to process. Note that the save-files Gaea creates are very small: do not hesitate to create new savefiles.

Nodes and graphs

As mentioned, nodes are sorted by type and colored accordingly. Generally, basic nodes that create a type of terrain are green. Nodes that transform or adjust other nodes are generally light blue or teal. Nodes that apply erosion or aggressively 'damage' terrain are light or dark orange. A different, darker shade of orange is reserved for Data nodes, which are nodes that can be used to mask or select parts of the terrain based on certain parameters. When creating textures, the purple nodes will allow you to work with colour.

Nodes often have one or more inputs, and one or more outputs. A Combine node, for example has three inputs and two outputs. Hovering over the little dot marking the node's in- or output will show the name of the port and indicate whether or not a connection is required for the node to function. Ports that need a connection have the same colour as the node-type, while optional ports are grey. Additionally, many ports have a designated input for masks. Adding a node (A) to the mask-input of another node (B) allows you to restrict the effect of node (B) to the specific area determined by node (A). Connections to a mask-input are always coloured purple, to indicate the type of connection.

Nodes that are improperly connected will have a red-dotted border and display the text "error". A node that has not been rendered yet will show as a blue-dotted bordered node. Clicking on this node (and, if required, un-locking any previously locked nodes from the viewport) will prompt Gaea to calculate the effect of the node and display its contents. Nodes that are selected will be marked with a blue glow. The node will then turn into a solid-bordered node, or if failed, be marked with an error.

! Sometimes, Gaea runs into an error that it refuses to get unstuck from. In most cases, it suffices to select the whole graph and press the 'Force a Refresh' button at the right bottom corner of the graph surface. If this does not resolve the issue, double check your connections (a common mistake is to connect to a secondary input rather than a primary input) or restart Gaea.

Figure 4: A properly connected and selected node, an unrendered node, and a node that was rendered but produced an error. Note how the first node has three inputs, one of which is a mask, and one output.

Node parameters

Each node has a particular set of parameters that can be adjusted to change the result of the node. Some of these have obvious effects: the Height parameter for the Constant node affects the height of the flat plane that the node generates. Common parameters include Scale and Seed. Seed in particular is a very powerful parameter common to nearly all nodes: changing the seed value randomizes the noise used to generate the effect of the node, which changes the outcome significantly (see figure 5). Other parameters are less intuitive, and require some experimenting to understand how the node is affected.

Figure 5: Four copies of a mountain node with identical settings but different seeds.

Creating a heightmap for FAF

Creating your first terrain

Primitives

Whether you have a design in mind or are hoping to combine nodes until something presentable falls out, you're going to want to start out with one of the primitives. This category of node is coloured green and serves as the basic building blocks for your terrain. Half of this category consists of 'plain' primitives: the Constant node produces a flat plane, the Gradient node produces a ramp or a cone. Different types of noise generators are included as well, such as Gabor, LineNoise, Voronoi, and Multifractal.

Figure 6: A selection of primitive nodes: Constant, Gradient, Gabor, and MultiFractal.

Geo primitives

The other half of this categories includes more complex presets of common terrain features. Among these Geo Primitives you will find nodes such as Badlands, Crater, Mountain, Canyon, Dunes, and Island (figure 7). Many of these advanced nodes can be recreated by combining 'plain' primitives, but as they are rather complex it is often easier to use the Geo primitives.

Figure 7: A selection of geoprimitive nodes: Badlands, Dunes, Crater, and Canyon.

Adjustments Nodes

To start adding things together, you'll need some nodes from the next main category: the adjustments nodes. The Combine node does what it says on the tin: you can combine two different nodes into one using different blending modes and strengths. Figure 8 shows the result of blending the Badlands node and Crater node from figure 7 together using four different blendmodes.

Figure 8: Blending Crater and Badlands using the blending modes Embed, Subtract, Divide, and Insert.

The other be scaled, rotated, and repositioned using the Transform command, while the Clamp node gives you good control over the global height of the terrain.
In my map Project Mesa, for example, I created the basis for the various pillars using a Gradient, Radial node, which I then repositioned and rescaled using the Transform node, and merged with the main terrain using a Combine, Embed node.

Erosion Nodes

Once the basic design of your map has been established, you might want to take a look at the various Erosion nodes. These nodes create rugged looking terrain, simulating decay over time from exposure to the elements. They can be applied to separate elements if you are combining multiple elements into one whole, be limited to specific areas using masks, or can be applied to the whole terrain at once. The Wizard node is a powerful erosion node with many presets that will be adequate in most situations (figure 9).

I want to caution against using Erosion excessively; units in FAF do not like rough terrain: it messes with pathing and blocks shots. While erosion adds lots of detail to a map, consider that the main areas that units fight on should be smooth and relatively flat whenever possible. Naturally, this is of no concern in areas that are limited to air or navy only.

Figure 9: A mountain and three variants with progressively stronger and more aggressive erosion (Wizard) applied. Note the formation of fine details, debris, and lots of sediment.

Modifier parameters

The properties panel of all nodes contains a set of buttons at the bottom right that allow for common modifications to nodes. Several of these modifications have their own nodes with the same effect: the Clmp and Clip buttons imitate the Clamp node, and the Blur button functions as the Blur node.

Aside from these modifications, there are two more settings that are very useful. Be pressing the '>' button, two further options appear. The Influence parameter allows you to reduce the overal effect of the node. The Drop to Floor checkbox lowers the contents of the node to the lowest possible limit, which can be very useful after combining several layers together.

Figure 10: This panel containing modifier parameters is present on all nodes and allows for adjustments without having to add more nodes. The Drop to Floor checkbox is not visible by default and will only show up when pressing the chevron to the left of the buttons.

Using nodes as masks

Using greyscale values to create terrain

So far, we've discussed how nodes can be used to create the terrain for your map. To understand how nodes can also be used to create masks to select specific parts of the terrain, we need to quickly discuss what it is these nodes are creating.

In games such as FAF, a greyscale image creates the terrain. Every pixel of the image has a greyscale value, which ranges from 0, complete black, to 256, complete white. The value of each pixel corresponds to the height of that pixel when it is used to render the terrain. A full white pixel is at maximum height, while a black pixel is at the minimum height. Any values between 0 and 256 correspond to a height somewhere in between the minimum and the maximum.

Gaea similarly translates greyscale pixels to terrain. By default, the viewport renders the resulting 3D terrain for you, but by changing the display mode we can visualize the flat greyscale image. Right clicking on any node and select Show as, Mask, or by selecting a node and pressing T, will change how the viewport renders that node. You will now see the greyscale pixels for your heightmap.

It might be that the greyscale value is still overlaid on the 3D model, rather than shown as a flat plane. This is because Gaea always shows two layers: the node and the underlay. The underlay is the geometry that Gaea projects the contents of a node on top of. This is generally selected automatically, but similarly to how you can freeze a node into the viewport by pressing F, a node can be chosen to serve as underlay frozen by pressing G. To visualize the greyscale image as on a flat plane, you can create a Constant, 0% height node and select that as underlay.

If the image is dark and you would like more contrast to see the different structures, you may press the Show raw data button and the Enhanced view button on the right side of the view port (figure 11).

Since the greyscale value of each pixel is a number, we can easily make selections based on these values. The Data category of nodes contains a lot of nodes that we need to do such selections. The Height node lets you make selections based on the height of the terrain, which corresponds to the higher greyscale value. Similarly, Slope allows you to make selections of pixels that are at a certain angle, by calculating the relationship of a pixel with its neighbours.

For a more extensive introduction to Data nodes to create masks, please see the Gaea tutorial on Masking.

Figure 11: The 3D image, and the corresponding greyscale representation of the raw data for the heightmap. The three greyscale images show the heightmap projected on the 3D model, on a flat plane, and on a flat plane with Enhanced view enabled.

Using greyscale values to select

The greyscale values can also serve to create selections: effects of nodes can be limited to only areas that are white, and not be applied to areas that are black. Greyscale values between white and black correspond to a percentage of the effect being applied. As all nodes contain essentially nothing more than a greyscale image, the outputs of nearly all nodes can be used to make such selections.

By using masks, you get infinitely more control over how nodes are applied. One example might be limiting where erosion is applied. In the fourth panel of figure 10, the erosion is applied to the whole mountain. As an example, we will now limit the erosion to only half of the mountain.

To do this, we first set up our mountain and apply the Wizard erosion node. Then, we create our mask. The mask that we need to limit the erosion to only half of the mountain is a mask that is half white, and half black. Only in the white regions will the erosion effect be applied. To create a full white heightmap, we could take the Constant node and set it to 100% height. Using a Transform node, we could then move the Constant node halfway off of the workspace. As there is no information on the now empty half of the heightmap, these pixels will be black. The results is a heightmap that is white in one half of the image, and black on the other half. When we then use the output of this Transform node and chain it as the mask-input of the Wizard node, we get the result we intend (figure 12).

Figure 12: The erosion effect is applied to half of the mountain using a mask. Panel 2 and 3 both show the same node, but the display mode differs. The bottom panel shows the Graph to create this effect. The Fold node shown was used to slightly alter the result of Mountain node, and does not affect the process of making a mask.

Naturally, this specific effect is not something that would work well for a FAF map, but clearly illustrates the principle of using masks.

Other nodes

There are several other useful nodes that you might use to create more advanced materials for your map. These include the Normal Map node, which can be used to create map-wide normal map decals, or the Light node, which can be used to create map-wide shadow decals. As these nodes are more complex, they will be discussed in detail in another tutorial.

Creating symmetry

As Gaea is designed to create realistic and natural terrain, it does not create symmetric terrain by default. In contrast, competitive FAF maps require symmetry to ensure no team has an advantage over the other. Luckily, by combining a few nodes we can create seamless symmetry for all kinds of terrain.

Symmetry of basic terrain

The most simple way to create a symmetric heightmap is done by using the Flip and Combine nodes. The Flip node allows for three different types of mirroring: Horizontal, Vertical, and Both. By combining the flipped copy with the original, you get symmetry.

Figure 13: An example of how the Flip node can be used to create three different kinds of symmetry: Horizontal, Vertical, and Both. Combine, Add, 100% was used in these examples.

Rendering your height mask

When you've completed your terrain, you can export it for importing into the FAF editor. To do this, take the last node in your graph and mark that node for export by selecting the node and pressing F3, or by right clicking it and selecting Mark for Export. The marked nodes will now show up under the Build tab in the top right. Adjust the relevant settings:

• Change the filetype of all masks to .raw
• Method should be left on Normal Build
• Resolution should be set to the size corresponding to your map's heightmap (257px for a 5km map, 513px for a 10km map, 1025px for a 20km map).
• Colorspace should be left on sRGB
• Range should be left on Raw, although alternatively this may be set to Remapped to rescale the whole terrain if it proves to be too tall for the FAF editor, see below.
• Baked Cache may be left on Use

After selecting where Gaea should dump the generated files, you can render the files by pressing Start Build.

Rescaling height

If, upon importing the heightmap into the FAF map editor, you realize that there is an issue with the vertical scale, you may want to adjust your heightmap. There are a few easy ways of achieving this. The Clamp node lets you scale the whole heightmap proportionally. Connect this node to the last node of your graph and adjust as necessary. Similarly, under the modifier parameters (those little buttons at the bottom right of a node's parameter panel) you will find the Raise modifier, a circle containing an X. This parameter behaves nearly identical to the Clamp node. Lastly, by setting the Range setting under the build menu to Remapped, and setting the maximum value to some fraction of 1, you can rescale the terrain.

Some trial and error is likely required to find the right scale.

Common errors and checklist

If you are running into problems with importing your heightmap to the FAF editor, please check the following:

• Verify you are using the correct resolution
• Verify you exported the heightmap in the .raw file format.
• Try changing the Baked Cache setting to None and re-render.

If Gaea is producing errors and you cannot get it to work, please check the following:

• Verify that the offending node is properly connected. Remove connections and try again. Nine times out of ten you accidently connected a non-primary output to the next node that cannot use that particular type of data, or connected one node to the a secondary input of the second node.
• Force refresh the complete graph.
• Replace the bugged node.
• Restart Gaea.

If Gaea refuses to render your heightmap, attempt the following:

• Add a Transform node to the end of the graph, and mark that node for export. Some nodes are known not to produce an output, but the Transform node is known to behave as expected.

Remaining questions

If you are left with questions or need help, your best bet is to check with people in the FAF discord Mapping-General channel. Alternatively, you may send me a PM on discord, or leave a message on this forum.

"Under pale moon,
Across the snow
...
Did we not lose, a hundred times?
Did we not win, a hundred times?"

Hello. It has been a while.

Project Albus is my first snow-type map, featuring large ice and snow covered flats. This 15x15 km map supports up to 8 players and consists of 5 lanes. The center lane is rather wide, while the lanes in the corners have several areas that serve as chokes. While the two large mountains serve as a barrier separating the main and the side lanes, the mountains can be crossed by small groups of units, albeit with some difficulty; You'll have to remain vigilant against enterprising enemies trying to raid through them.

This map was a real pleasure to create, and uses several new techniques and tricks. First and foremost is the use of asymmetry: you'll notice that the ice floe in the corner ponds are different between the two map halves. To ensure that this difference in terrain does not affect gameplay, the two ponds have been made inaccessible using terrain types. Units will not be able to access this part of the map, air units excepted.

Experiments with asymmetric texturing have worked out rather well, and textures have been applied in a more organic manner. While the main playable area has identical terrain, textures are not applied symmetrically, creating a sense of natural distribution of the snow and ice. Additionally, some experiments with creating texture masks in Gaea have led to some improvements, and I believe the quality of the masks has increased significantly compared to my previous maps.

Future iterations of Adaptive Project Albus are pending on feedback, and might lead to an adjustment of mexes and reclaim. As per usual, any feedback is welcome either in this thread, or via discord directed to Prohibitorum.

The map is licensed under CC BY-NC-SA 4.0 and is compatible with AI.

A long post, I'll try not to get too wordy. (Edit: I failed)

FAF in decline: your core argument

Thing's don't grow forever, and gaming communities have a tendency to stagnate and decrease over time. FAF has not been different, but is special in that we continue to have a large core of active players. I agree with you that we need to do our best to keep that going. I disagree with most of your suggestions on how that should be done.

Your core argument, that the rest of the post is based on, is your belief that competition and connection issues are not the largest cause of players leaving, but that many people are not happy with how the game is being run. You specifically mention moderation as a problem.

I think you are in an environment where you hear a lot of grumbling of likeminded players that has given you that impression. I think that impression is wrong. A significant majority of games in FAF are PvE games: skirmishes against AI or Co-ops. Almost none of these players are affected by moderators, because these games do not spawn tickets. Similarly, the vast majority of the playerbase (PvE and PvP alike) isn't active in the discord or the forums, and never hear from a moderator. If those people leave, it is because of them losing interest, finding another game, or having issues with FAF.

I will try and get the relevant statistics for you.

Selfish moderation

I'd start with saying that reviewing tickets for games that a mod has themselves not played in is inherently non-selfish, given it requiring quite a bit of volunteered time. However, I will understand your point as specifically about particular moderator policies, and having issues with particular individual moderators.

This is does not mean every moderator is selfish but I feel it necessary to call out moderators who became moderators because "their reports weren't doing anything" or because they wanted a certain policy enforced harder

If you want to call out specific moderators, then be specific and call them out. I've recently mentioned in my post here that "I signed up to the modteam about half a year ago to help clear the massive backlog of reports we had, because I was annoyed by how my reports seemingly had no effect.". I'm assuming this is what you are referring to.

I'm struggling to see how "I want to join the moderator team to help clear the backlog" is in any way selfish. Are you misunderstanding what I mean when I said "my reports had no effect"? I do not mean that my reports didn't have the effect that I wanted, it means that the reports were never addressed. I had one or two reports in the system that hadn't been looked at in more than half a year. I joined the moderator team to solve that issue. And we have, the backlog is now clear. Most tickets are now seen by a mod within 24 hours. None of this is selfish.

These moderators often lack seniority and understanding of the game but most importantly they do not represent the high level community because they have never played with them.

Some info about how the modteam works.

• We do not consider seniority relevant: all the mods generally have an equal voice, with the exception of Teamlead/Headmod Giebmasse.
• None of the mods specifically represent a particular part of the community.
• Changes in rules, or discussions on how rules are applied, are internally discussed without regard for seniority or community status and require consensus within the team. For some changes this is easy because most mods agree. With others this requires several weeks of discussion. In the end, no moderator policy is enacted by any single mod.
• If a player receives a ban, they can appeal it by email to [email protected]. Appeals are received and handled by Giebmasse, and where necessary internally discussed with the whole modteam. The moderator who initially handled the ban does not have a stronger voice in this discussion than any other member of the team.
• If a mod is not sure about a decision, they check with the team for a second opinion. This happens frequently.

Because of these points, it is very very difficult for any given mod to take action on anything without the rest of the team approving it. For the 2100 tickets that I've cleared in the past 6 months, I can think of maybe 3-5 situations in which an action was overturned. This also means that:

banning and censoring players who use words that individual moderators do not like

is simply not how things works.

Unpopular policies

Three policies in particular are called out:

• Base Ctrl-K
• Censorship (Or as the mods call it: moderating verbal abuse and basic civility)
• Username changes

Base Ctrl-K

General background info:

The position of the moderator team is that killing your whole base is griefing. If you believe the game is over, you may vote for a recall. If your team disagrees and you really do not want to continue a game because you're tilted or believe the game is lost, you can leave the game. This is with the understanding that this is infrequent: players that leave in the middle of a game consistently might be considered griefing as well, although this is mostly applied for people that leave very early. We prefer people leaving over the verbal abuse and toxicity we sometimes get reports for when tilted players stay, though.

The reason why we have this rule (and this rule is, as far as I know, ancient), is that destroying your whole base forces your team to lose. When you start a game, you agree to play a game. This means that you play it until one team has won. If you cannot convince your team that the game is lost, by starting a recall vote, then your team clearly signals that you are wrong and/or they want to continue to play. It is not your right to decide for the rest of the team that they need to stop playing.

This is most common at the high level but can happen in lower level games.

This is incorrect. Base Ctrl-K happens at all levels of play.

Players mainly base control k to stop someone from playing on when the game is clearly lost and everyone wants to play the next game but someone is refusing to recall.

See above. The recall system works on a vote system, and only in small teams is it possible to have 'one' (1) player that can block the recall. If you think this system needs to be changed to that it's easier to recall, write a forum post about it; it doesn't have to be a thesis. You'll likely have my support.

Regardless if you disagree with me the problem with this moderation policy is that the vast majority of the high level community is perfectly fine with base control k. ... In the high level community almost no one reports for base ctrl k or flaming because in general these things do no bother us.

And if you play games exclusively with people who are in favour of others Base Ctrl-K'ing, you won't hear a peep from the moderators. We do not go through games from high rated players to look for offenses: we only act when we have received a report. Similarly, we generally discard reports by players who have not taken part in the game themselves. We have in the past had players that were looking for offenses of specific players by going through their replays, and we do not accept that behaviour. However, when you play with people who do not agree with you base Ctrl-K'ing when you decide you're done playing, then you will have to take their opinions into account. Which means following the official FAF rules.

high level community believes it should be legal and they are completely ignored by the moderation team which has greatly angered players and has caused several to quit.

Rules can be changed if there's enough support for them. I do not remember seeing a forumpost about wanting to change this rule, but I may be wrong.

Censorship (basic expectations of civility)

We have, since forever, community rules. These rules include rules on speech. I do not believe that a basic level of civility is beyond what we may expect from our community. These rules are widely supported: from the top of my head I estimate that about a quarter to a third of reports we receive are for verbal abuse. People say some genuinely vile stuff when angry, and people rightfully expect that the moderators take action on it.

These rules are also enforced in our discord. Arguments, disagreements, and being angry with other players are all a part of having a large community, and do not need moderator action. However, we expect players to be civil to each other. We take action against bullying of new players, against slurs, against racism, against homophobic language, against death threats and wishing death upon players or their family. These examples happen often and frequently: we get tickets several times a week. Exactly what language is acceptable and what isn't remains an ongoing topic of debate. There are no clear lines here, because every person has their own idea on what counts as verbal abuse. Similarly, the opinions in the moderator team vary widely. We have found a balance that we believe is fair.

As with all things private, we do not care about private conversations. We do not look for offense wherever we can find it: we only moderate games that are reported to us, and moderate the public community channels. These channels include Aeolus and the official FAF discord. What you say and do outside of these channels is not our concern. The public channels, however, are a place for ALL players, which means we maintain a certain standard; within them you are expected to follow the community rules.

These rules are not new, and are not particular to FAF. Every single large gaming community has these or similar rules.

The username rule update

The discussion regarding these changes is ongoing. See the relevant thread for our arguments and viewpoints. We are still taking in feedback and continue to discuss the matter internally.

None of the feedback was ignored, several changes have been made.

Response to suggestions on changes to the mod team

Higher standards for the acceptance of moderators.
I propose that Moderators have at least 1500 games at least 5 years of experience and for new moderators to have had at least 100 games in the past year before they are accepted. A possible minimum rating could also be discussed.

New moderators are added to the team very rarely. Their admission is voted on, and their background is vetted for previous bans and offenses. I do not believe stricter guidelines are necessary, but don't have a strong opinion on this. 5 years experience seems excessive however, especially given the median account 'age' likely being much lower than that.

I also call for some form of immunities for high level members of the community as well as senior players that are not as high rated but have thousands of games.

I do not believe that we will ever implement changes that favour one group of players over the other, for the simple reason that seniority does not give you a pass to be a dick. If you wish to be immune to the general FAF rules, you may host your private games with people that are similarly not in favour of specific rules.

When you play with the larger community, you will be expected to follow the rules of the larger community.

Lastly I call for the ability to hold some kind of referendum to fire unpopular moderators.
The premise that a moderator can do whatever they want with no accountability must change.

Your premise is wrong: there is no situation in which a moderator can do whatever they want. As explained, no single moderator acts alone. Neither does a moderator have immunity: the team lead is at any point in time able to remove a moderator from the team. Possibly (I am unsure of this) the board is as well.

Firing based on popularity is also not likely to ever become a thing, for obvious reasons: people mostly interact with moderators when they get a ban. People who get a ban are most often unhappy with the ban. This means moderators get unpopular.

Moderation, and moderation policies, are not about popularity, they are about being necessary and/or right. I believe this is one of the reasons why the discussion about the rename policies has been so ineffective: one side is arguing the change is not popular, while the other side is arguing that the change is necessary. They are two different conversations.

---

I'll see about finding the data on new players, active games, number of mod tickets, and bans handed out over time. I think it'll be useful.

Several interesting updates!

Project Mesa HD

Project Mesa was the first map I ever made. It was also the first project I made in Gaea. Consequently, on both the map-making side and the Gaea side there was a lot of room for improvement.

So improvements were made! Released under the new name 'Project Mesa HD', the new map features several fixes to the terrain (which mostly focus on flattening and scaling the map to solve height-related issues), some changes to the mex layout, better reclaim, and much improved use of decals. Pictures at the end of the post.

I have one or two areas left that I can work on to further improve the visuals of this map and may update again in the future, but for now you can find Project Mesa HD in the mapping vault and in this month's 4v4 matchmaking queue.

A github repository for project Mesa assets and project files

I have released a github repository which contains a growing set of decals and textures related to the Project Mesa HD map. The textures and decals will soon become part of the main FAF repository, and thus become available for everyone to use through the FAF editor.

Along with these new mapping assets, I have included the Gaea project files that were used to create the map and assets. If you're interested in working with Gaea, you may want to have a look at how I've created this map and the decals.

---

I've played a few games where one player request a short pause to deal with an IRL matter. Often this runs along the lines of there being someone at the door, or them having to take a phonecall; you know, incidental stuff. Most of the times when this happens all players don't mind a minute waiting, but every so often there is a player who immediately unpauses, and refuses to wait even when other players explain that there is a need for a pause.

Additionally, as a moderator, I've seen several reports for people requesting we take action when this happens. However, under our current rule set this behaviour is not strictly a bannable offense, and we've left it up to the individual moderator to handle the matter.

I understand that this is frustrating however. I'd like to poll the community to see if making this situation a bannable offense has any support, or if people feel strongly about maintaining the way we currently deal with this behaviour.

If you have suggestions for how this should be moderated, or think it shouldn't be moderated at all, please share!

(This comment contains my own opinions and thoughts and is not necessarily supported by the moderation team as a whole)

This newly discovered garden world would be a great place to start a new farming colony, commander. Secure it for us! // Licensed under CC BY-NC-SA 4.0. This map is AI compatible.

Project Tumulus is a 5x5km map made for 1v1's. This map's relatively simple, featuring a decent amount of mexes, lots of reclaim to manually click, and a nice autumn theme on low rolling hills. A good fit for the 500-1000 1v1 bracket.

While there are enough rocks scattered across the map, in such places that you'll have to send your engineers to go out of their way to get them, most of the mass on this map is actually part of the tree groups. The higher rated players may find a challenge in making sure at least some of those tree groups remain intact clumps, or in making sure that no clumps survive on the other side of the map.

I would like to suggest that any game that is ended as a draw using the draw button should not award or subtract rating points from any of the players.

Recently, it has become much more common to have at least one player disconnect at some point during a game. These issues have been reported and are no doubt worked on. In the mean time however, it has become clear that we lack a way to declare that a game should be ended or unranked because of problems of one kind or another.

Currently, when you use the draw button, the game understands this to mean that both teams are equal. As a consequence, the lower rated team gets assigned points, and the higher rated team loses points. However, unlike games like Chess, it is (near) impossible for a FAF match to end up in a genuine draw. For this reason, this logic does not make sense and the button's function should be changed.

I imagine the the easiest option to fix this issue is to either set the game as unranked, or award a default 0 points to all players, once a draw has been accepted. Alternatively, a new button specifically made to unrank a game could perhaps be implemented. I do not know how to code however, and I am sure that smarter people than me have better ideas.

It has been frustrating to have more than half of my games be spoiled by connection issues, and to lose points on top of that after accepting a draw is just not a great experience. Please make this change.

@jip Thanks everyone! Cool to get first prize. Thanks to Jip for organizing this, and to our lovely judges for the grading and feedback.

I've contacted Jip and received the license for Gaea. Had some ideas for new maps on the backburner, time to get them going!

Congratulations to the winners!
Thanks for Jip for hosting and our esteemed judges for the grading.

The feedback is very on point and I agree with pretty much all the feedback Project Vortex got. Unlike previous projects, I never really fell in love with this map, and it shows in how rough it is in places. Was a good challenge nonetheless.

I'll be back for first place next time

Lack of communication between different dev/balance/content teams and community, instability of connections, client being buggy and slow.

The fact that the game is still being actively maintained needs to be praised, though. It's not common to see this kind of activity in a decade old game.

V7 of Project Albus has been released:

• After playtesting the map, some mexes have been added, others removed, still others moved to new locations to better balance the slots.

• Reclaim has been slightly rebalanced.

• The blinking 'beacon' type building was removed from the civilian bases, because it was very distracting.

• Some changes to decals and texturing should make the terrain, including the mountain passes, easier to read.

• Project Albus has been submitted for review for the matchmaker pool.

Over the past few months, I’ve been digging into various aspects of FAF data — initially for moderation-related purposes, but the scope quickly grew into a broader analysis of FAF player activity, rating dynamics, and behavioral trends.

This thread can be considered an unofficial continuation of an earlier post by @tatsu from back in 2020, which itself was a continuation of the thread from 2012 on the old forums. See: FAF Statistics Megathread and FAF stats (old forum).

I will start with a general introduction to the data sources, goals, and some of the quirks that come with working with FAF’s historical records. I will also explain what data I have collected. If you have suggestions on further statistics or visualisations based on this data that I have not yet included, comment your suggestions and I'll have a look.

Future posts will dive into specific topics, with accompanying visualizations and summary tables.

Goals

This thread visualizes various statistics based on data pulled from the Forged Alliance Forever database through the API. This data was collected with the aim of getting a clearer understanding of the FAF player base and its interactions with moderation. The goals of this analysis were:

• Track trends in active player counts and rating distribution — who’s playing, how much, and how the landscape changes.
• Identify long-term trends in player retention, smurf behavior, and rating inflation/deflation.
• Explore moderation data to better understand the volume and nature of reports, bans, and appeals.
• Provide data-backed insights for both community discussions and FAF governance (e.g. balance, matchmaking, moderation policy).
• Improve transparency by publishing findings, allowing others to cross-check and build upon them.

This data may guide future efforts by the various FAF teams, including for example the promotion team and the moderation team.

Data description

Overview

This analysis draws on three primary datasets: players, reports, and bans, containing data starting from the beginning of the FAF project in February 2012.

Players data was collected from the API’s /data/players endpoint and contains information such as the account registration date, username, and playerID. This data was combined with select data from /data/gamePlayerStats, which contained information about which players played in which games and /data/leaderboardRatingJournal, which contained info on player ratings. By combining these, further information such as the date of the last played game, the number of games, the lifespan of the account, or the time it took for a player to play 10 games was calculated.

Reports data contains all the metadata related to reports, including report status (whether the report was discarded or completed, for example), the IDs of the reporter and reported players, the report description and game, and which moderator handled the report.

Finally, information from the bans dataset contains all related metadata including the ban reason, duration, and category.

A complete list of the variables for the three datasets will be posted below.

Data acquisition

Data was collected through the FAF API using a number of custom python scripts. Specifically, the endpoints /data/bans, /data/moderationReports, /data/players, /data/gamePlayerStats, and /data/leaderboardRatingJournal were used to collect all existing data. Together, this resulted in about 50GB of data in JSON format, which was later processed to CSV format.

Some of these endpoints cannot be fully accessed without an authorization token with at least moderator privileges, as some endpoints—the data/players endpoint in particular—produce data that contain private information that falls under GDPR regulations. In line with GDPR guidelines on data minimization, data such as player emails or steam-links were not collected.

Unusual features of the data

Due to a number of reasons, some of the data in these datasets does not follow expectations. Examples include:

• While most playerIDs correlate with account age, this is not the case for all playerIDs. Especially for accounts made in 2012, though also at later dates—at least up to 2016—it may occur that younger accounts have a lower ID than should be expected.
• Some data on user accounts was not properly recorded until February 2016.
• While bans were given out prior to May 2017, these dates have not been recorded. Rather than having been left empty or filled with a placeholder value, these dates were apparently set to 2017-05-10. As the ban expiry date was properly recorded, some bans have a negative 'ban duration' value.
• While the time of creation for a report was recorded, the update time was not. Consequently, for reports that were discarded and thus do not have an associated ban—from which the update time can be derived based on the ban’s creation date—it is impossible to determine when they were processed.
• Because of the various data artifacts that are present in the players dataset, for several graphs the choice was made to exclude all data from before March 2016. This will be mentioned alongside the graph when applicable.

Data accessibility

As it has been longstanding moderation policy to not share the details of reports and associated bans with the wider public, the datasets collected for the analysis of moderation-related statistics will not be released. If you're part of a FAF project (e.g., balance, moderation, events) or just an interested player and would be interested in access to more detailed data, feel free to reach out. I’m happy to provide anonymized raw data segments on request if you want to dig deeper or cross-check any findings.

Data analysis

Data was processed, analyzed, and visualized using a combination of Python and R scripts, with a lot of help from ChatGPT (I suck at programming). I may at some point release the relevant code to Github when I can be bothered to clean the code enough to be presentable.

List of collected and calculated variables:

Dataset	Columns
players	player_id, create_time, last_login, username, has_accountlink, games_played, first_game_time, last_game_time, tenth_game_time, hundredth_game_time, thousandth_game_time, time_to_10games, time_to_100games, time_to_1000games, create_year
players_by_bracket	year_month, rating_bracket, active_players_10games
players_all_ratings	player_id, latest_rating
bans	ban_id, level, player_id, ban_create_time, ban_expires_at, ban_reason, author, revoke_reason, revoke_time, related_report, ban_revoked, ban_duration_days, units, ban_permanent, ban_category
reports	report_id, report_status, reporter_id, reported_user_ids, report_description, game_incident_timecode, game_id, moderator_private_note, moderator_notice, last_moderator_id, create_time, related_ban_id, last_moderator_name, ban_create_time, ban_expires_at, ban_reason, ban_revoked, time_to_ban
games	replay_ID, end_time, lobby_name, start_time, rated_validity, victory_condition, host_player_ID, gamePlayerStats_IDs
Gamestats	gamePlayerStatsIDs, rating_deviation, rating_mean, player_color, player_faction, score_time, team, replay_ID, player_ID

Analysis: Playerbase

User registrations

Based on the data from March 2016 onwards, FAF has gained on average 2668 (+/- 678) new users every month. Month by month numbers fluctuate significantly, possibly in response to the SupCom:FA game being sold with a discount, or due to the effect of third party promotions such as game casts and tournament streams.

Graph 1: Count of created accounts by month. The data for February 2016 was not shown as its value was a significant outlier (12666).

Yearly registration numbers have been fairly stable at around 28000 since at least 2017. However, the effect of the corona pandemic is distinctly visible in the significant increase in new users in 2020.

Graph 2: Sum of created accounts by year. Peak of the pandemic lockdowns happened in 2020. Data for February 2016 not included.

Another way of visualizing this data is to show the cumulative registered users.

Graph 3: Cumulative registered users over time. Data for February 2016 not included.
From these graphs we can conclude that FAF continues to have a relatively stable influx of new players.

User activity

However, registration does not equal activity. In fact, a significant portion of the users that register an account never log in, register a steam account, or play more than a few games. To visualize this, in the graph below accounts are divided in 7 bins: the accounts with no steam or GOG link, accounts that are linked but played 0 games, and accounts that played at least 1, 10, 100, 1000, and 10000 games. This data is then plotted as absolutely numbers of accounts (first graph) and as the proportion of the total accounts registered that month (second graph), visualizing the shift in total number of games played for the accounts over time.

Graph 4: User activity up to April 2025 by date of registration

Graph 5: Proportional user activity up to April 2025 by date of registration.

For each month the accounts registered in that month are divided in categories based on the number of games they played up to now. These values are plotted as proportion of all accounts for that month.

A few things immediately jump out. Because newer accounts will have had less time to reach a lot of games, the proportion of games with higher number of games decreases as the accounts get younger. Those rare few accounts with more than 10,000 games, for example, are all registered before 2020, with most of them having been registered in the first 2 years of the FAF project.

Another noteworthy observation is that the proportion of accounts without an account link—that is, accounts that were registered but never were connected to a steam or GOG account and thus cannot play any games—has significantly increased since 2024. These accounts may not be genuine accounts, and instead be the result of attempts at breaking FAF services (related to the DDOS attacks FAF has been experiencing since around that time) or attempts to create accounts to spam the forums with spam and advertisements (as has been happening in the past).

Users and Players

It is noteworthy that there is a large proportion of users that have played fewer than even 10 games. To look at this further, it makes more sense to only look at ‘players’, which I here define as any account that has played at least one game.

Graph 6: Proportional player activity up to April 2025 by date of registration.

This graph clearly visualizes how almost half of the playerbase have played fewer than 10 games: 44.2% of the total playerbase, and 49.5% of all players registered in the past 5 years. Moreover, this proportion seems to be increasing in more recent years, with as much as 60.6% in the last year.

For larger number of games this could again be explained as a result of new accounts not having had the chance to play a large number of games, but given that this data only includes accounts up to the 1st of March and thus all accounts are nearly 2 months old at the time of writing, it should not be excessive to expect players to have played 10 games.

Time to reach 10 or 100 games

That is an assumption, however. To verify this, the mean and median time to reach 10 or 100 games was calculated for all accounts that had played at least that many games. Some players represented outliers, such as those that registered accounts in 2012, but did not play more than a handful of games until more than 10 years later. Such outliers were removed by only analyzing the data from players who completed 10 games within one year of registering.

Table 1: Summary statistics for times to reach 10 or 100 games.

Year	Time to 10 Games – Mean (SD)	Time to 10 Games – Median (IQR)	Time to 100 Games – Mean (SD)	Time to 100 Games – Median (IQR)
2012	55.8 (87.5)	13 (58.1)	619 (887.9)	242.1 (599.5)
2013	37.2 (68.9)	7.8 (27)	645 (925.6)	191.6 (786.9)
2014	42.6 (77.2)	8.1 (31.3)	646.7 (850.8)	254.8 (810.5)
2015	45.9 (81.7)	8 (35.1)	628 (806)	267.1 (781.1)
2016	33.8 (70.1)	5.7 (18.8)	553.1 (701.1)	223 (732.5)
2017	35 (71.5)	6 (19.9)	501.8 (637.5)	202.4 (681)
2018	33.7 (70.7)	5.9 (19.1)	433.1 (543.5)	179.1 (587.9)
2019	38.3 (75.6)	6.3 (22.6)	360.7 (444)	166.2 (444)
2020	31.4 (66)	6 (18)	304 (382.2)	125.1 (375.2)
2021	33.3 (68.9)	6.2 (19.8)	264.6 (310.7)	132.9 (314.6)
2022	33.4 (68.2)	6.2 (19.8)	213.2 (249.6)	93.3 (276.7)
2023	34.3 (68.3)	7 (20.4)	174.5 (172.6)	104.9 (224.3)
2024	25.4 (52.6)	6.5 (16)	95 (86.7)	59.9 (92.7)
All years	36.2 (71.6)	6.8 (22.6)	445 (646.4)	167.8 (494.9)

A quick reminder for those who have forgotten their stats 101 course: the standard deviation (SD) measures the spread of data around the mean (the average). A high SD means there is a lot of variation in the data. When data has a lot of variation, it is often better to look at the median instead.

The median is the value that sits at the middle of the data. In this table, it represents the number of days it takes for half of the players to reach 10 or 100 games. The interquartile range (IQR) measures the spread around this middlepoint. It measures the range between the 25th percentile and the 75th percentile. Or, more simply said:

• In 2024, the median time it took for players who played at least 10 games to reach 10 games was 6.5 days, with an IQR of 16 days. This means that 75% of all players that played at least 10 games, played them within 14.5 days after registration.

• The median time it took for players who played at least 10 games to reach 100 games was 59.9 days, with an IQR of 92.7 days. This means that half of all players that played at least 100 games, played them within 106.2 days after registration. Incidentally, the fastest player on record to play 100 games after registration played those games within 0.2 days.

This data shows that there is a lot of variation in how active players are, but also shows that most players need about 6.8 days to play 10 games, and 167.8 days to play 100 games. The data from the table was plotted in the graphs below.

Graph 7: Distribution of time it takes for players to play 10 games, by year. Median marked.

Graph 8: Distribution of time it takes for players to play 100 games, by year. Median marked.

From this data we can conclude that it is not unreasonable to expect accounts that are older than 2 months to have played at least 10 games. This means that the increase in the proportion of newly registered players in the last year that have not played at least 10 games to 60.6% is the consequence of other factors. There are several reasons for why this percentage has increased. One immediately obvious candidate is the connectivity issues that have plagued FAF in recent years.

While it is impossible to definitively determine what the reason is that players quit early on, at least without having these players full in a survey or otherwise directly asking them why they stop, we can have a look at some other data to see if the connectivity issues are the cause. The number and proportion of single-player games, coop games, and multi-player games may offer some insight, for example. Similarly, comparing the average duration for which an account stays active between players that near-exclusively play single-player and multi-player, as well as the change in this average over time, may be interesting. This data will be looked at later.

Does it make sense to have a ACU wreck instead of a stone tombstone? I know the ACU explodes in a big bang but if all my 2000 best faf friends are willing to suspend disbelief on the ACU chasis being able to withstand a nuclear explosion well enough to leave a blackened wreck I won't argue against it. But yes, nice function, let's keep it.

This once lush and verdant garden world hosted a classified UEF research facility, researching the first components of the Black Sun doomsday device. We do not know what happened, but all that is left now is a crater and the scattered remnants of the research complex, the planet razed to the ground. // CC BY-NC-SA 4.0. AI compatible.

For this tournament I submit Project Vortex. The map was designed as a all-out navy brawl: every bit of terrain gained will come with another mex for you to claim. Small islands, many with mexes and/or chunks of reclaim are scattered across the map. Most of these islands are low enough that frigates will be able to shoot over them, although some larger ones have some cliffs and mountains.

The spawns are located on the top left and bottom right corners, with two players starting in the water. To start off, these water spawns get two hydros, but will then have to find dry land to expand their powergrid and build non-navy factories. The remaining corners provide some more reclaim, as well as larger islands that allow for some very aggressive forward factories.

Thematically, this map shows the result of a scientific disaster: all that remains of the research facility that was once present on this planet is a large crater in the center. What survived of the buildings from the research complex was blasted outwards, and later moved around by the water that ended up filling the crater. The effects on the region as a whole was disastrous: no life remains. Only the charred husks of what were once large forests teeming with life provide an indication that this was once a verdant garden world. Across the map you'll find many buildings that have since gotten stuck or washed ashore of the many islands. Some newer structures include UEF cranes and a civilian base, indicating that the UEF has started salvaging efforts.

The center of the crater remains a danger to this day, and it is not recommended that commanders are dropped into the deep.

On this classified planet claimed by the Aeon Illuminate, researchers worked years on developing novel surveillance technology. The research, codenamed Project Luminary, resulted in a working prototype, the creation of the Eye of Rhianne, and later on even a minitiurized version which can be installed on the commander. Ever since, the surveillance abilities of the Aeon are without peer. // Licensed under CC BY-NC-SA 4.0. Contact the map author on FAF discord for feedback. This map is compatible with AI.

Project Luminary is a 10x10km map, and is my entry for @Jip 's 'Princess Burke' Mapping tournament. This section of the secret and classified Aeon planet is designed for six people and is best played using the Aeon race, as the terrain allows hover tanks to shine.

Expect aggressive gameplay: players are likely to have to multitask navy, air, and land at the same time, as many mexes are easily raidable by all three options.

The map is licensed under CC. BY-NC-SA 4.0 and is compatible with AI.

Design

As the tournament for which this map is my submission requires an Aeon-themed map, several aspects of the design—both major and minor—are themed to reflect this.

I decided to imagine a map that would serve as the location for the research station that developed the Eye of Rhianne. The map design somewhat resembles an eye, with a pupil-like platform in the middle and an 'iris' as the main island. The name is similarly derived from this concept. A luminary is someone who enlightens others, or refers to 'that which lights up the surroundings'. Given that an Eye of Rianne literally lights up the darkness, the name is a great fit.

Key recurring features are circles, geometric shapes, and precisely placed props. (I spent an inappropriate amount of time carefully shifting the decals, buildings, and props until they lined up exactly. Please someone notice T.T)

Frigates will be having a fun time contesting mexes on the shores, but will have to keep in mind that the shore will never be far away, and Aeon hover tanks might want to use the same space to flank around any PD installations.

Other fun facts:

• This map uses just over 2000 decals, two of which are a map-wide normal map and a map-wide Albedo/Shadow decal
• The map-wide albedo is mostly transparant, but helps a lot with color correction and cliff details
• The map-wide assets took 2 hours to render at the required 8k resolution, during which my PC froze and could not be used for other stuff. This had to be done four times. (My PC is ten years old and desperately needs a replacement. If you're reading this and you're rich, please buy me a new pc. Help.)
• There are only 4 circle-type Aeon-ish decals. To create the various patterns, I stacked and combined these in different combinations to keep everthing interesting. Getting everything lined up was super fiddly and a massive pain and please don't make me do this again.
• The centerpiece features 3 small transport ships (because naturally, the people living in that base have to get off their little platform somehow.) These transports have their own little designated landing zone, though at the start of the game they decide to relocate for some reason. (Compare the third and last picture). I suspect either some roughness in the terrain or too close proximity to other structures, but I haven't figured that one out yet.
• I added very subtle waves and clouds because they look beautiful. The clouds are only visible if you zoom all the way out, because it's deeply annoying to not be able to properly see the things you're trying to focus on.
• Not including whatever mass you get from the structures (about 5k, estimated), the map contains 23K mass reclaim and 65K energy reclaim. Most of the mass is stuck in little tiny rocks, so while a steady stream of reclaim is available, we shouldn't see too large of spikes in income.

Images

@evildrew Your post is rife with generalities, but lack specifics. You spew accusations, but refuse to support them. For shame.

Have you seen @ComradeStryker 's posts? The lad wrote an essay's worth of suggestions so large, it had to be cut into several chapters and included a table of contents. He went into detail explaining the problems as he saw them, and offered specific solutions. And you know what happened? Several of these suggestions have since been adopted.

If you have a problem with the current balance, that is the post you should emulate.

You say the recent changes have ruined map designs. Which maps are these? You seem to have been unable to find any room in your post to name specifics. A quick look at the last 200 games you played shows you near-exclusively play two maps: a survival map, and a map that looks like what Settons would have been if Settons was a 10x10. You complain about a lack of strategic diversity and staleness, yet have you considered that perhaps your refusal to play more than two different type of games might be the cause of that? Is it not more fair to admit that you have a very specific preference for a very limited type of game, and that you don't like the balance changes that have been made? That would have been a post worth making, I would think.

Instead I get this barely coherent tirade describing a group of very motivated players, who are donating their effort and free time to improve a 15-year old game, as a "cancerous oligarchy". You call them "self-centred", inferior candidates, and imply they equal corrupt politicians and dictators. Do you hear yourself speak?

We need ice for our drinks, commander. Remove these enemies and secure that ice! -- Licensed under CC BY-NC-SA 4.0. Based on a map design by StaySane0.

Project Glacies is a 10x10km map made for at most 4v4. The map is a rework and redesign of a map originally designed by StaySane0, who was kind enough to give me permission to adjust his original concept. Changes involve significant changes to the heightmap, a redistribution of mexes and reclaim, as well as a complete overhaul of the textures and decals. Assets from my previous map Project Albus were used for the design of this map.

As with most of my maps, there is a good amount of reclaim spread out all over the map, with larger chunks of reclaim on the route most engineers will take to reach mexes. Those players with the extra APM to spare will find it rewarding to give the manual reclaim orders to their expanding engineers.

This map also features clumps of dense forests, which also contain a hefty amount of mass and energy. Like with Project Tumulus, keeping the tree clumps intact will make scaling your economy significantly easier. Some slots may find that an extra greedy build of starting with 2 factories and no mexes is just about possible if you pay enough attention at manually reclaiming the trees.