Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you may not be able to execute some actions.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Image editing tools, such as:
Map editing tools, such as:
On the 30th of September, 2020 the Ozonex editors renders water differently than in the game. Thus it is not representative to what you would see while playing. On the contrary, the GPG editor utilizes the exact same procedures as the game does and is therefore representative. If this is no longer the case when you read this - do notify me and I'll remove this paragraph .
For this article I assume that you have extracted all the textures the game has to offer. If you have not done so and / or do not know how to extract all the texture, I advise you to check the FAQ in the overview article. There is entry explicitly on how to do this properly to allow the GPG editor to generate the correct relative paths to the textures.
Normal map A normal map is commonly used in older rendering engines in order to create detail that cannot be represented by the geometry of a shape. This is quite a sentence and I encourage you to look at the following article:
Water map A water map is a lot like the common normal map, but with a different interpretation of the alpha channel. And because of this difference I do not just call them normal maps, but water maps because the alpha channel is only taken into account when it is used to render water. This article describes the exact interpretation in depth.
It is important to understand the goal of this article. Personally I like to work backwards: we start looking at the end result along with the context and then try to understand how this is accomplished.
A visual comparison between different types of wave normal maps
For more context on what this all means I encourage you to open up the GPG editor and import the following water settings:
You can either download the file or create a new file with a .lua extension. Once inside the GPG editor you can import the configuration via File -> Import -> Water.
For this article we'll look into how the waves on the water surface take shape. This is accomplished by combining various water maps. We'll discuss where we can find the assets regarding to water that the game provides, how we can interpret these assets and how we can make our own.
The game provides a bundle of water maps by default. These are used throughout the default skirmish and campaign maps. Assuming that you have extracted the textures correctly previously, you can find them at:
%InstallationFolder%/textures/engine/
Once inside you'll find a bunch of water maps: waves.dds (no foam channel)
waves000.dds (no foam channel)
waves7.dds (completely white foam channel)
waves001.dds (with foam channel)
waves6.dds (with foam channel)
For each image, the normal map is in the top left and the alpha channel is in the bottom right part.
You are not limited to using these - any repeating normal map can be used! You can think of normal maps that are generally used as strata textures. This can create all kinds of interesting effects. A typical normal map will have an opaque alpha channel - this may cause the water surface to become completely white. When this happens, read the next section carefully: not all normal maps are fit as a water map out of the box.
A water map is the typical purple-looking normal map one would expect, including an interesting interpretation of the alpha channel.
The latter indicates whether or not there is foam on the water. Foam is generated when the total foam value after combining the various water maps is larger than 1.0 (more than white). This effect is generally not visible because the majority of the wave maps provided to us have a black alpha channel. The only reasonable assets that generate the effect is waves001.dds and waves6.dds.
Water of the map Paradise, with foam on the top left and without foam on the bottom right
When you open up the standard map Paradise (scmp_035) you can see one of those water maps among the water properties, in turn generating a small foam effect.
Enable the Water layer (F9) and click on 'Water Properties' in the toolbar of the editor. The tool window will respond and change into a 'Water Properties' window. For this article we're interested in the very last properties: the texture, direction, speed and frequency of the water maps.
Showing the properties in which we're interested in for this article
Assuming that you have extracted the textures correctly previously, click on the '(...)' button and navigate towards the location where they should be stored:
Choose any of the water maps and start experimenting with them.
Other interesting properties are the direction of a normal map, its speed and how often it is repeated on the water surface. You can change these live in the GPG editor:
Direction: Water starts movingtoward top/north. Increasing the number will rotate the effect clockwise.
Speed: The speed in which the water moves, the lower the value the slower the water moves.
Frequency: The size of the texture on the surface. Lowering the value causes the texture to be tiled more on the water surface.
Toying around with the water maps and these settings can create all sorts of interesting effects. From here on the journey is yours. Feel free to share your findings in the comments below!
A visual comparison after changing some of the wave normal maps
You can store water maps inside your map folder. For stratum textures and decal textures there is a specific location where these should be stored. For water there is no hierarchy that you need to use in order for the game to find the files. It is good practice to store them inside the env folder that the other textures require in order to function - this keeps it organized.
As an example, you can store them in: %MapName%/env/
For this tutorial we'll use the following normal map:
You will need an account to be able to download the normal map. The website is free and you will get 15 points for free each day allowing you to download seamless textures. If you are aware how hard it is to make these kind of textures then you know we are practically robbing them via their own freemium model. Do take note of the license on the textures - as an example we cannot share them without explicitly using them and you need to mention the source in the description of the map.
Any normal map texture from the internet will likely have a fully opaque alpha channel. We just learned that this is used to generate foam on the surface therefore you may want to make it black or give it some interesting shape. Save the texture in the .dds format. You can do so by opening it in your favorite image manipulation program that supports the .dds format, such as Gimp or Adobe Photoshop. Use BC3 / DXT5 as your compression algorithm.
A visual example of water that appears to have really large waves in it
When you upload the map to the vault the name of the folder of your map is changed. The path to your custom textures is not adjusted accordingly, in turn the game cannot find the corresponding textures.
To approach this you can use the Ozonex editor to bump your map version which creates a new folder with the correct version and in turn you can use the GPG editor to set the corresponding paths to the new folder structure. When uploading the name of the folder of the map no longer needs adjusting and everything will be good.
With Supreme Commander we are in a unique position in which we can not only toy around with the graphical assets, we can also see how these assets are used in the rendering pipeline of the game. The (HLSL) shaders can be found at:
%InstallationFolder%/gamedata/effects.scd
To strengthen our understanding of this article it is nice to see how the assets are used in the rendering pipeline. For this article, the following bit of code inside the water2.fx file is particularly interesting.
float4 HighFidelityPS(...){ // (...) // calculate the normal we will be using for the water surface float4 W0 = tex2D( NormalSampler0, inV.mLayer0 ); float4 W1 = tex2D( NormalSampler1, inV.mLayer1 ); float4 W2 = tex2D( NormalSampler2, inV.mLayer2 ); float4 W3 = tex2D( NormalSampler3, inV.mLayer3 ); float4 sum = W0 + W1 + W2 + W3; float waveCrest = saturate( sum.a - waveCrestThreshold ); // average, scale, bias and normalize float3 N = 2.0 * sum.xyz - 4.0; // flatness N = normalize(N.xzy); float3 up = float3(0,1,0); N = lerp(up, N, waterTexture.r); // (...) }
The waves that makes the water appear so alive is nothing more than a summation of a bunch of normal maps, each at a different position to simulate the idea of movement.
The values mLayer0 up to mLayer4 are computed in the vertex shader, at an earlier stage of the pipeline. In turn these values are used to get pixel information from a texture using tex2D along with the according texture samplers that describe how certain situations should be taken care of and the coordinates that we wish to sample.
After which the various normal maps summed together, resulting in a single vector. The vector is first used to compute the wave crests values that in turn are used later as part of generating the white foam on the surface water. Take note that the foam value solely uses the alpha channel! The normal is adjusted accordingly to match the fact that we added four normal maps together. It is then used for lighting, reflection, refraction and speculation computations down the road.
The flatness that we can define in the editor is applied as a linear interpolation between the up vector and the normal computed at the surface of the water. The more we flatten the water, the less of the computed water normal will be used and therefore the water will appear to be more uniform.
For more information on the operators used:
You' are using water maps that have (completely) white alpha channels. The alpha channel is interpreted as foam. If you want to use those water maps, change their alpha channels to black (no foam) or some other pattern to introduce foam in a more natural manner.
For the first normal map that has a white alpha channel this doesn't have an effect. Foam is rendered on the water surface when its value is larger than 1.0. In other words: when the combined normal maps have an alpha channel that is more white than white itself.
Two examples of problems with foam
When you upload the map to the vault the name of the folder of your map is changed. As an example,
from: %MapName%/ to: %MapName%.v0001/.
The path to your textures is not adjusted accordingly and in turn the game cannot find the corresponding textures when you download the map from the vault.
To approach this you can use the Ozonex editor to bump your map version and then use the GPG editor to set the corresponding paths. The Ozonex editor already prepares the correct name of the folder of the map. When you upload the map no adjustments are required and therefore no renaming happens.
For more information on normal maps in general:
For more textures that you can use in your projects:
If you have interesting sources, approaches, opinions or ideas that are not listed yet but may be valuable to the article: feel free to leave a message down below or contact me on Discord. The idea is to create a bunch of resources to share our knowledge surrounding development in Supreme Commander.
If you've used this resource for one of your maps feel free to make a post below: I would love to know about it!
Special thanks to @keyser for providing feedback on the article.
I was wondering if it would be possible to have read-only sections of the forum where only a specific number of people (from a given group, for example) can write to.
Specifically I am referring to the balance team having this option. Not because I don't think they are doing a great job but because I think their discussions can provide a great deal of insight to (new) players.
If this would be possible, the balance team has a clear section in which they can discuss everything without interference. And the community can read this and make new topics to ask questions and / or make suggestions in the 'general balance section'. The original section that is 'read-only' for anyone but the balance team remains concise.
An example of why I think this is relevant:
I'm not 100% confident if these are guaranteed balance changes or not, but if it would be, people are generally unaware (beforehand) unless they stumble upon it accidentally. And then you can ask 'why', which is not explained in the pull requests. I bet there has been a discussion about this somewhere that reveals all kinds of insight but I can't find it and I'm confident that a lot of other members are unable to find it too.
And again: without judging whether the change is good or bad: I think the discussions can provide insight to (new) players. And those insights are key to the game and I feel they should be on the forum. But, if and only if it can be protected by the suggestion mentioned earlier. Otherwise I can see myself (accidentally) diving into a topic with a context that I'm clearly not aware of, or ask questions that have been answered months ago and cluttering up the whole (original) discussion.
As a visual example:
Where the 'internal' balance discussions can only be written to by members that are part of the balance group (as there is a 'council of setons' group, 'moderator' group, etc)
edit: I do not speak for the balance team - this post is the result of a discussion I had with another member. I hope someone from the balance team can come on in and share their tale.
At the moment of writing the Ozonex editor renders the water quite differently. In turn the rendering of the water that you see in the Ozonex editor is not representative to what you'd see in-game. The GPG editor uses the exact same procedures and is therefore completely representative.
The primary usage of these elevation parameters is to both define the water surface and the range of the water ramp.
Surface Defines at which height the surface is. There can only be one surface of water - multiple surfaces to support maps with varying water height is not supported. Is also used as a marking point as to where the water ramp starts.
Any value above the surface will share the same value as the one on the surface. Uses the pixel in the most top left corner of the water ramp.
Deep Has no meaning of any kind. It is an aesthetic parameter as it is mentioned in the shader that renders the water, but never referenced anywhere in a computation. Has no game play effect of any kind.
Abyss Defines at which height the water ramp is at its lowest. Has no game play effect of any kind - solely used for coloring the terrain underneath.
Any value below the abyss will share the same value as the one on the abyss. Uses the pixel in the most top right corner of the water ramp.
Water with a surface in the left top slice, water without a surface but with the water ramp applied in the right bottom slice
The sun color parameters influence the color of the reflection of the sun. This reflection is a form of specular lighting and the options for the specular lighting are below the header 'Sun and Fresnel', discussed below. The sun color is a typical RGB color component as one would expect.
The values range between 0.0 and 2.0, which allows you to overload the color significantly. This is useful in the case that color is reduced due to shadows of some kind. Typically the range is between 0.0 and 1.0, representing values between 0 and 255 in integral-based colors.
Red The red component of the sun color.
Green The green component of the sun color.
Blue The blue component of the sun color.
A slice with red and a green sun color
The reflection of the sun is unrelated to the angle of the sun defined in the lighting settings. It is always most visible when looking perpendicular at the water, where as the reflections are invisible when looking parallel with the water.
Surface color and interpolation The surface color parameters influence the color of the surface itself. It colors the entire surface based on an interpolation of depth of the water. Lets look at the code to find out how this plays out in practice:
float4 HighFidelityPS(...) { // (...) // as found in water2.fx // we want to lerp in some of the water color based on depth, but // not totally on depth as it gets clamped float waterLerp = clamp(waterDepth, waterLerp.x, waterLerp.y); // lerp in the color refractedPixels.xyz = lerp( refractedPixels.xyz, waterColor, waterLerp); // computations such as reflections and wave crests }
The waterDepth is a value in the range between 0.0 and 1.0. At 0.0 we are at the surface height, at 1.0 we are at the abyss height. We defined these values earlier. The water depth is clamped between the two interpolation values. This has a set of consequences:
That means that if we have a minimal value that is larger than 0 all the water will always have some surface color and isn't transparent. This causes a visual annoyance when zooming out described in another article:
Now that we're aware of this we can also understand why the water becomes opaque when we up the values: we are interpolating between the refracted image of what is behind the water over a single color that we defined ourselves. When we up the values, all that remains is the surface color we defined.
An inconvenient error is that the depth of the water is inaccurately defined. This isn't as obvious when you view the water from up top, but it becomes clear when you view the water from an angle.
The reason for this is that the surface is changed in color, but not the color of the terrain behind the surface. That color is changed according to a water ramp, which we'll touch upon in this article and discuss in another.
Reflections of the sky and water crests will always appear on the surface - these are computed and combined after the surface color computations are complete.
Essentially what the surface color and its interpolation values describe is how clear the water is. Take the water from that cup standing next to you in comparison to water that you mixed with lemonade: the former is clear (hopefully) and the latter is almost opaque.
Reflection is the idea that water reflects light of its environment back to its environment. This is effect becomes more apparent the more parallel our viewing angle is with the water.
Refraction is the idea that water changes the angle of light that passes through it. This effect becomes more apparent the more perpendicular our viewing angle is with the water.
Sun A linear interpolation as to how reflective the sun should be. Not sure where this is being used directly.
Sky Determines how much the sky (cubemap) should be reflected.
Unit Determines how much a unit should be reflected.
Refraction Determines how strongly the water distorts anything that is under water.
The sky reflection parameter has precedence over the unit reflection parameter. If there is no sky reflection, then there won't be a unit reflection either. This correlation exists because the sky reflection parameter is used, on its own, to determine whether we reflect anything at all.
float4 HighFidelityPS(...) { // (...) // as found in water2.fx // lerp the reflection into the refraction refractedPixels = lerp( refractedPixels, reflectedPixels, saturate(skyreflectionAmount * fresnel)); // (...) }
As a result, if you decrease the amount the sky is reflected you'll also decrease the amount a unit is reflected by the water. If there is no sky reflection then only the refracted pixels and the surface color remain.
If you have interesting sources, approaches, opinions or ideas that aren't listed yet but may be valuable to the article: feel free to leave a message down below or contact me on Discord. The idea is to create a bunch of resources to share our knowledge surrounding development in Supreme Commander.
If you've used this resource for one of your maps feel free to make a post below: I'd love to know about it!
There are no requisites for this section.
This introduction part will try to motivate you as to why decals can be important to both the experience of the player and the perception on the product as a whole. Essentially it is the finishing touch on a beautiful cake, the final mile of a marathon or the last tweaks on that hobby of yours.
And exactly that is why it is one of the hardest phases of the development of a map: it is already fleshed out, the resources are in place, the strata are done and as a whole its seems to be already good and playable. Why spend hours and hours on those decals?
Well, good of you to ask. Lets go on a journey together.
It is important to understand what it is that we're trying to achieve. With my students I like to work backwards: we start looking at the result and try to understand what it is trying to tell us. And let us start off good with some animated content of maps that are either in the vault or under construction. The purpose is to try and understand what it is that these decals mean to you. What is their added value in your own experience?
Hymn and Bone: there are no decals in the slider.
Fifth Nomad Mission: there are only decals in the slider.
Seton's Clutch: There are no decals in the slider
Next off we have a bundle of images of maps. Feel free to post your map down below and I'll ponder on whether it fits the next series. All of them have 2 sections that do show decals and two sections that do not show decals. Again, the purpose is to try and understand what all of this means to you.
Nomad Mission 5, under construction as of writing
Long John Silver, under construction as of writing
Mellow Shallows
When looking at the examples, determine what it is that you think that decals are doing to the map according to you.
Wild Path
Seton's Clutch, before Forged Alliance
Rainmakers Survival
Don't stop here. Experience it live yourself - open up one of the following maps in the Ozonex or GPG editor:
The GPG editor crashes when it is trying to open up a map made by the Ozonex editor that is saved as version 60 (forged alliance), instead of version 56 (vanilla). You need the Ozonex editor to open these up and save them in version 56 of the map file format in order to open them in the GPG editor.
You can find maps that you have downloaded in:
You can find the default maps at the installation folder of Supreme Commander Forged Alliance.
There is a Hide all and Unhide all button to quickly switch. You can find it under Decals -> Tools.
Use CTRL+A to select all the decals. Then press Delete. You can now quickly switch between a view with and without decals via using CTRL + Z and then deleting them again.
I hope this gives an idea to you as to what decals mean to you. This can be anything - there is no good or bad here. Use this as your argumentation.
The next topics cover as to what decals mean to me. We don't have to agree and a discussion is always welcome.
Decals on their own do not affect the simulation. After all, they do not make the terrain more bumpy or change the terrain type - it just looks more bumpy or more grassy. Nevertheless, to me they do affect the interpretation of the simulation. In other terms: to me decals have influence on the gameplay.
Let me elaborate via the usage of strata. Typically a rock stratum is used for places that are expected to be unpathable, such as cliffs, mountains and steep hills. This is done in almost every single map. Especially the default maps that are shipped with the game both learn us and use this association to make it easier for the player to understand the simulation.
In its essence: the rock stratum communicates some form of state to a player: this piece of terrain is likely unpathable.
Other instruments that communicate state are:
And that is how we get back to decals. Decals allow you to tap into a source of associations that the player typically learns throughout playing the game. This source of associations can be used to make your map easier to understand. As an example, would you say there is a hill on this bit of terrain?
After some careful consideration you'll probably say: 'Yes, of course! Look at the lighting on that piece of terrain. There must be some elevation there.' And you're right: there is.
Typically though, after play testing the map with new players, people build turrets behind the hill such that the hill blocks all projectiles flying towards units that are in front of the hill. In turn this forces me as a map designer to question as to why this is.
The reason turned out that even though the state was communicated through lighting, it was communicated too poorly. People do not have time to inspect the terrain when they are playing a real time strategy game. And because the lighting wasn't that significant, people just generally just overlooked the hill.
To communicate 'the hill' better I decided to place a few decals on it.
After which I never had the complaint again of their turrets shooting some hidden hill. Players either made their turrets in front of the hill. And if not, at the very least understood what went wrong and that they could've known about it before hand.
Therefore to me, decals can help you as a designer to communicate state.
The magic circle is an interesting concept in which a user accepts to drop the normal rules of the physical rules and replace them by new rules - allowing you to enter a world such as a game, or a movie, and emotionally live along with that world.
It is the reason that people can cry at the end of a movie: they accepted the environment which describes whether or not a user can accept a new reality as a truth - and in turn, accept anything that follows from that reality.
One can argue that initially when you start playing a game decals can help a lot to capture your imagination. It is what makes the world feel more acceptable - imagine playing this game the first time when all of the maps had no decals on them at all. The gameplay may be just as interesting. All the trailers, footages of the game and other PR material on the other hand would appear blunt and less appealing to you. In turn, you would be less quickly drawn towards the product.
The same still holds if you do not play the game competitively but more casually. The graphical appearance of a map can introduce all kinds of play and allows people to see a higher contrast in this world of play, or, step into it more easily.
We started off with a question what decals are for you. Throughout the article we have tried so far to answer this question by comparing maps with and without decals. The hard truth is however that the majority of popular maps barely have any decals on them at all.
Some people were discussing this fact in the Map & Mod Making Discord channel, and they have a good point. When we take the top 20 of the 18th of August, 2020 then the results are as following:
The overall consensus is that decals aren't that important for a map to be popular. Surely people may enjoy aesthetics maps, but generally, they won't choose a map for aesthetics. They choose a map for the game play experience that the map facilitates. And decals aren't a part of that choice.
There are maps out there that do not have that many decals, while still being appealing all on their own. And there is something to say here: decals are not a necessity. In my opinion they are a powerful tool to enhance an experience, but they cannot create the experience on their own.
A map that is beautiful on its own with a mere 318 decals on it, of which 44 are unique
And all of this brings us back to the original question: is it worth spending time on carefully placing decals on a map? This is question that is for you to answer - some will say no, others will respond with an astounding yes. I hope this article allows you to make this argument with yourself.
For more information on the magic circle:
A few good talks from GDC about level design:
This is a blog post on where you can find the current decals, how you could potentially edit these decals and how to add them back into your map. Take note that I am no designer, hence the 'edits' will be relatively simple.
This blog is also useful for adding custom stratums and, in the near future when it is supported, custom props.
We'll go through the steps with a case study for the one of the missions of the Nomad campaign.
Interesting sources A list of sources that you can use as inspiration for new decals, stratums and textures in general.
A video tutorial by @Morax about the same topic, with the focus on stratums instead of decals:
Tools
If you cannot afford Photoshop then you can use Gimp as an alternative. Gimp supports the .dds format used by Supreme Commander by default.
Take note that Supreme Commander also supports the .png format by default.
The case One of the nomad maps have lava in them. The map doesn't use the default stratum textures for lava, hence creating cracks like in Haven Reef is rather difficult.
The expected results:
The current results:
As you can see the colors do not match as nicely as one would like. Therefore we decide to make a small but evident change to the textures.
Where to find the original decals of Supreme Commander The game itself typically resides inside your Steam folder, from there you can go to:
Copy the file and change its extension from .scd to .zip. Extract the .zip file you just 'created' - the contents contain all the stratum textures of the game, nicely organised per theme.
The files we need for this case study are:
On Windows 10 .dds files can be visualized in the Explorer. Make sure that your view is not on details but instead of large or very large pictograms.
On editing decals I cannot pin point what to do for every possible edit. But I can give you some pointers and will tell you what I do to my textures to make them fit in more.
First of all, lets talk about the alpha channel. This isn't a separate alpha channel as one would typically expect, instead the base layer is not a background layer - it is a separate layer that has alpha encoded directly into the layer itself.
The channels of the decal
The layers of the decal
Therefore whenever you work with an alpha channel, think in terms of layer transparency. This is also useful to know when you search on the internet.
In our case we simply want the colors of the decal to match the colors of the stratum. Take note that the decal has different colors in photoshop than it has in the editor - this is due to the lighting settings of Supreme Commander that are applied to the decal. You can change these settings in the editor.
For the purpose of this blog we want to match the color of the decal with the color of the stratum used commonly on the plateau's. This allows us to more easily 'hide' the decal, making our life easier in the long run. We can do this by navigating to Image -> Adjustments -> Match Color and then choosing the stratum we exported along with it as source.
The original decal
The adjusted decal
Other tools that are certainly interesting without breaking any tiling patterns are:
And pretty much anything inside Image -> Adjustments is generally worth knowing about its existence.
Adding the decal back in Now that we have made our adjustments it is time to make it available within the Editor and within Supreme Commander for usage.
Navigate towards your map. We refer to your map folder as root. Add in the following folders to your map:
Save your decals in .dds format in the decals folder and save any new stratum textures in .dds format into the layers folder. Take note that this nicely matches the structure of the original env.scd file that we extracted earlier.
For the future, you can add in custom props by storing them into root/env/props.
From this moment on the decals and / or additional layers should be visible in the Resource Browser of the Ozonex editor. Choose as Type the Map folder, and the corresponding Category. From this moment on everything works as expected and you can even load in the decals from the old GPG editor.
The outcome of the change
The difference is small but it is now nearly invisible unless you pay really, really close attention to the decal work and know what to look for. In both cases, players either don't do that or they don't know what to look for. All is beautiful.
About you If you have interesting sources that aren't listed yet: feel free to contact me on Discord or the Aeolus in Forged Alliance Forever! Take note that for the latter, if I did not respond, I may have missed your message.
A map for Supreme Commander: Forged Alliance (Forever)
A long forgotten salt lake that was once facilitating an experimentation facility of the Aeon faction
The map is designed to be either played as a 1 vs 1 or a 2 vs 2. Both teams start on the main land with the intention of one team member moving for the island. The mass doesn't contain any high-concentrated reclaim locations. The expansions should be clear from the design of the map.
There is reclaim on this map. This includes:
The map has various pieces of code to add additional feeling to the map. This includes:
The map has over 2700 decals in order to make it pretty. That is a lot of them.
The water looks different in this image than how it would be rendered in game
The map is based on the TA map Long Lakes
I do not expect to win considering my map doesn't look a whole lot like the original but still have slight optimism because of the sentence 'and lastly how you've chosen to convert the gameplay into FAF' .
This is a part of a series on water within Supreme Commander. You can find other series at:
This article dives into the idea of water ramps.
A ramp is nothing more than a very thin gradient. Typically a ramp is a texture with a height of 1 and any with that is some power of 2. The reason for the latter is performance. A few examples of ramps, with a significantly larger height, are already available to you:
waterramp.dds waterramp_eg.dds waterramp_evergreen02.dds waterrampSwamp02.dds
A ramp heavily relies on transparency, hence these may look different depending on your theme of the forum. Typically a ramp looks like this in Photoshop where the block pattern indicates that the texture is transparent there.
For this article I assume that you have extracted all the textures the game has to offer. If you haven't done so and / or don't know how to please review the FAQ in the overview article. There is one explicitly on how to do this properly to allow the GPG editor and the game itself to find the textures.
Water ramps are used in Supreme Commander to color the terrain at each pixel, depending on the depth of the pixel. The functions takes in the depth as an argument that is relative to the surface and abyss parameters. At the surface or higher we expect no coloring of the water, where as a in the abyss we expect the full coloring of the water. Think in terms of lemonade: the deeper you put something in the less visible it will become.
The game provides a bunch of water ramps by default. These are used throughout the default skirmish and campaign maps. Assuming that you have extracted the textures properly previously, you can find them at:
Inside you'll find a bunch of water ramps:
The best way to see them is either through the explorer in Windows 10 or by opening them up in Photoshop. On Windows 10 if you represent images as large pictograms it can, at times, interpret .dds files properly allowing you to see its color scheme.
At the moment of writing the Ozonex editor renders the water quite differently. In turn the rendering of the water that you see in the Ozonex editor is not representative to what you'd see in-game.
Select the Water layer and then click on 'Water Properties' in the toolbar of the editor. The tool window will respond and change into a 'Water Properties' window. For this article we're interested in the 'Texure Maps' and particularly in the 'Water Ramp' texture.
At this point I assume that you have extracted all the textures the game has to offer, as described in the frequently asked questions (FAQ) section of the introduction. Click on the '(...)' button next to the water ramp texture and navigate towards:
Choose any of the water ramps available and start experimenting with them.
You can store water ramps inside your map folder. For stratum textures, decal textures and props there is a specific location where these should be stored. For water there is no hierarchy that you need to use in order for the game to find the files. It is good practice to store them inside the 'env' folder that the other textures require in order to function.
For this tutorial we'll use the following water ramp:
Put the texture in the map folder and then select it accordingly with the GPG editor.
It makes you wonder why there hasn't been a custom rainbow water ramp before'
When you upload the map to the vault the name of the folder of your map is changed. The path to your custom water textures is not adjusted accordingly, in turn the game cannot find the corresponding textures.
To approach this you can use the Ozonex editor to bump your map version. This creates a new folder with the correct version, and you can use the GPG editor to set the corresponding paths. When uploading to the vault the name of the folder of the map matches its map version and therefore no longer needs adjusting. The path remains the same and everyone can load in the custom water textures.
With Supreme Commander we're in a unique position in which we can not only toy around with graphical assets, we can also see how these assets are used in the rendering pipeline of the game. The (HLSL) shaders can be found at:
To strengthen our understanding of this article it is nice to see how the assets are used in the rendering pipeline. For this article, the following bit of code inside the terrain.fx file is particularly interesting.
// as defined in terrain.fx // apply the water color float3 ApplyWaterColor( float depth, float3 inColor) { #ifdef DIRECT3D10 float4 wcolor = tex2D(WaterRampSampler, float2(depth,0)); #else float4 wcolor = tex1D(WaterRampSampler, depth); #endif return lerp( inColor.xyz, wcolor.xyz, wcolor.w ); }
The shader code shows us that we are only interested in the first row of pixels, using the depth argument to determine what pixel we should use. The depth value is clamped between 0.0 (surface or higher) and 1.0 (abyss or lower). We use the alpha channel wcolor.w to interpolate between the input and the color retrieved from the ramp. The input is in this case a color too: the color of a fully shaded bit of terrain.
The code shown is part of the shader that renders the terrain - the water itself isn't changed. The water is influenced indirectly by the water ramp through refraction, causing the water itself to change color.
Terrain with black and red stripes on it
The editor or the game cannot find your water ramp and therefore uses the default texture to make sure at least some texture could be loaded and shown. This default texture has no transparency and therefore the terrain, even the bits and pieces above water, completely disappear in the interpolation.
One cause is that the textures that you unpacked are at the wrong location. Make sure that the paths are: Good: /textures/engine/waterramp.dds Bad: /gamedata/textures/engine/waterramp.dds
Another cause when you use custom textures is that the map version got bumped but you didn't update the path accordingly. As an example, when uploading to the vault the folder name is adjusted if it doesn't match the map version accordingly.
If you've used this resource for one of your maps feel free to make a post below: I love to know about it!
Waves add in a feeling of the environment being alive. It is visible on all default maps that have water of some kind and on custom maps when people know how to generate these. This article is trying to assist the community on the latter.
A bunch of waves on the shores of the map Mellow Shallows
On the 30th of September, 2020 the Ozonex editors doesn't support generating waves. On the contrary, the GPG editor has a procedure in place that allows you to generate waves on maps. If this is no longer the case when you read this - do notify me and I'll remove this paragraph .
Navigate to the water layer (F9). In the toolbar of the editor you'll find three little buttons named 'Edit Water Properties', 'Water brush' and 'Water waves'. Choose the latter. This will change the tool window into the Waves window.
Highlighting the actions described earlier in the GPG editor
The new tool window is basic in its nature: you select a wave, choose a depth for them to be generated on and hit generate. Waves will be generated in such a way that they orient to the shore. Slowly but surely the waves will start to spawn. It can take a while for the waves to be visible - some of them have a long animation time including a fade in time.
There isn't a lot of creative freedom in this feature. You can manually select waves but you cannot transform or rotate them. You can delete them. You can delete all the waves by clicking on the reset button.
Generally you want to use multiple types of waves and foam. The longer the animation of the wave the further away from the shore you'd like to generate them. Watch out for waves directly intersecting the terrain - this will create hard lines between the wave and the terrain and it generally looks bad. If this happens, generate the waves at a deeper shore depth. Generating the same type of waves multiple times is not uncommon and can be used to increase the density of the waves.
Personally I like the 'Incomming', 'Incomming2', 'Foam' and the 'Long slow break' waves. I toy around with them on different shore depths, generating one after the other. It is vital to both check how it looks on beaches as checking how it looks near cliffs or reefs of any kind.
If you have interesting sources, approaches, opinions or ideas that aren't listed yet but may be valuable to the article: feel free to leave a message down below or contact me on Discord. The idea is to create a bunch of resources to share our knowledge surrounding various fields of development in Supreme Commander.
At the moment of writing the Ozonex editor doesn't support weather markers. You'll need the GPG editor to get this all to work.
Weather generators are rare, if not at all, used by maps in the vault. A lot of the original maps were supposed to use them but the code to generate the weather is all commented out. In turn, maps generally have no weather at all.
Weather on the map Rainmakers Survival
Generating weather is fairly easy but you need to know the exact steps. The GPG editor allows the creation of the proper markers. Creating and customizing the weather involves three steps: placing the proper markers in the GPG editor, editing the script file of the map and then editing those markers inside the save file through a text editor.
Open up your map and open up the marker tools (F6). From there on navigate completely to the right and at the end you'll find the markers:
Place one of both of them in the center of the map. Then save the map and close the GPG editor - this prevents you from accidentally overriding the next step. You can have multiple generators, but for the sake of the article, I'll assume that you only have one.
You can view and edit the properties of a marker inside the editor. Select a marker and extent the 'Marker Editor' window vertically. This will reveal all the properties of, for example, a Weather Definition marker.
The weather can not be rendered and inspected inside the editor. You'll need to open up the map in Forged Alliance in order to inspect it. Constantly copying your map from the editor folder to the game folder is a bit of a pickle - therefore we use a text editor to edit the properties. This allows you to iterate more quickly when you restart your map to inspect the results.
Open up the _script.lua file from your map in your favorite text editor. A typical script file from a non-adaptive map looks like this:
local ScenarioUtils = import('/lua/sim/ScenarioUtilities.lua') local ScenarioFramework = import('/lua/ScenarioFramework.lua') function OnPopulate() ScenarioUtils.InitializeArmies() -- optional, only if applicable ScenarioFramework.SetPlayableArea('AREA_1' , false) end function OnStart(scenario) end
We want to add in the weather thread so that clouds are slowly generated over time. Change it to:
local ScenarioUtils = import('/lua/sim/ScenarioUtilities.lua') local ScenarioFramework = import('/lua/ScenarioFramework.lua') -- for weather generation local Weather = import('/lua/weather.lua') function OnPopulate() ScenarioUtils.InitializeArmies() -- optional, only if applicable ScenarioFramework.SetPlayableArea('AREA_1' , false) end function OnStart(scenario) -- for weather generation Weather.CreateWeather() end
With the current weather definition and generator clouds should already be generating. Start the game, disable fog of war and make sure that it is. Then it is time to start tweaking!
If you have no vision over a weather generator marker then you will not see the clouds that are being generated.
Open up the _save.lua file from your map in your favorite text editor. Any editor will suffice, as long as it has a search function.
Search the file (CTRL + F) for 'Weather Definition'. You'll find in the markers chain a marker that looks like the following:
['Weather Definition 00'] = { ['WeatherType03Chance'] = FLOAT( 0.300000 ), ['color'] = STRING( 'FF808000' ), ['WeatherType01'] = STRING( 'SnowClouds' ), ['WeatherType02'] = STRING( 'WhiteThickClouds' ), ['WeatherType04'] = STRING( 'None' ), ['WeatherDriftDirection'] = VECTOR3( 1, 0, 0 ), ['WeatherType01Chance'] = FLOAT( 0.300000 ), ['WeatherType03'] = STRING( 'WhitePatchyClouds' ), ['WeatherType04Chance'] = FLOAT( 0.100000 ), ['MapStyle'] = STRING( 'Tundra' ), ['WeatherType02Chance'] = FLOAT( 0.300000 ), ['hint'] = BOOLEAN( true ), ['type'] = STRING( 'Weather Definition' ), ['prop'] = STRING( '/env/common/props/markers/M_Defensive_prop.bp' ), ['orientation'] = VECTOR3( 0, -0, 0 ), ['position'] = VECTOR3( 522.5, 68.8418, 541.5 ), },
These values are scrambled - they can appear in any order. The important bits are:
All values are case sensitive. As an example, it is 'Dsert' and not 'desert'.
Values that are not used by the code but by the editor:
Each theme has its own list of weather that can share names but look different. Therefore choosing the right map style is important. We can find all the available weather as comments in one of the lua files of the base game:
Map Style Types: Desert Evergreen Geothermal Lava RedRock Tropical Tundra Style Weather Types: Desert LightStratus - Evergreen CumulusClouds - StormClouds - RainClouds - WARNING, only use these a ForceType on a weather generator, max 2 per map Geothermal Lava RedRock LightStratus - Tropical LightStratus - Tundra WhitePatchyClouds - SnowClouds - WARNING, only use these a ForceType on a weather generator, max 2 per map All Styles: Notes: ( Cirrus style cloud emitters, should be used on a ForceType Weather Generator, placed ) ( in the center of a map. Take note that the these are sized specific for map scale ) CirrusSparse256 - CirrusMedium256 - CirrusHeavy256 - CirrusSparse512 - CirrusMedium512 - CirrusHeavy512 - CirrusSparse1024 - CirrusMedium1024 - CirrusHeavy1024 - CirrusSparse4096 - CirrusMedium4096 - CirrusHeavy4096 -
This defines all the weather that is available. The RainClouds and SnowClouds generate rain and snow respectively - these should be used sparsely. An unlisted entry is 'None', which indicates that the no weather may be generated at all.
Search the file (CTRL + F) for 'Weather Generator'. You'll find in the markers chain a marker that looks like the following:
['Weather Generator 00'] = { ['cloudCountRange'] = FLOAT( 0.000000 ), ['color'] = STRING( 'FF808000' ), ['ForceType'] = STRING( 'None' ), ['cloudHeightRange'] = FLOAT( 15.000000 ), ['cloudSpread'] = FLOAT( 150.000000 ), ['spawnChance'] = FLOAT( 1.000000 ), ['cloudEmitterScaleRange'] = FLOAT( 0.000000 ), ['cloudEmitterScale'] = FLOAT( 1.000000 ), ['cloudCount'] = FLOAT( 10.000000 ), ['cloudHeight'] = FLOAT( 180.000000 ), ['hint'] = BOOLEAN( true ), ['type'] = STRING( 'Weather Generator' ), ['prop'] = STRING( '/env/common/props/markers/M_Defensive_prop.bp' ), ['orientation'] = VECTOR3( 0, -0, 0 ), ['position'] = VECTOR3( 518.5, 68.6699, 542.5 ), },
As an example on the range variables: if the absolute value is 90 and the range is 15 then the final value is randomly chosen from the range [75,105].
All values are case sensitive. As an example, it is 'None' and not 'none'.
It is always good to dive into the code and discover how values are used in computations. This will bring in more perspective as to what is possible and leaves out speculation on what you feel it is doing.
Let's start off with reading out the markers - turning the concrete data into a more abstract form that allows us to construct the weather.
function GetWeatherMarkerData(MapScale) local markers = ScenarioUtils.GetMarkers() local WeatherDefinition = {} local ClusterDataList = {} local defaultcloudclusterSpread = math.floor(((MapScale[1] + MapScale[2]) * 0.5) * 0.15) // Make a list of all the markers in the scenario that are of the markerType if markers then for k, v in markers do // Read in weather cluster positions and data if v.type == 'Weather Generator' then table.insert( ClusterDataList, { clusterSpread = v.cloudSpread or defaultcloudclusterSpread, cloudCount = v.cloudCount or 10, cloudCountRange = v.cloudCountRange or 0, cloudHeight = v.cloudHeight or 180, cloudHeightRange = v.cloudHeightRange or 10, position = v.position, emitterScale = v.cloudEmitterScale or 1, emitterScaleRange = v.cloudEmitterScaleRange or 0, forceType = v.ForceType or "None", spawnChance = v.spawnChance or 1, } ) // Read in weather definition elseif v.type == 'Weather Definition' then if table.getn( WeatherDefinition ) > 0 then LOG('WARNING: Weather, multiple weather definitions found. Last read Weather definition will override any previous ones.') end WeatherDefinition = { MapStyle = v.MapStyle or "None", WeatherTypes = { { Type = v.WeatherType01 or "None", Chance = v.WeatherType01Chance or 0.25, }, { Type = v.WeatherType02 or "None", Chance = v.WeatherType02Chance or 0.25, }, { Type = v.WeatherType03 or "None", Chance = v.WeatherType03Chance or 0.25, }, { Type = v.WeatherType04 or "None", Chance = v.WeatherType04Chance or 0.25, }, }, Direction = v.WeatherDriftDirection or {0,0,0}, } end end end return WeatherDefinition,ClusterDataList end
This shows us what data is relevant and transformed into another format. We can also see that there are a lot of sane defaults provided. And last but certainly not least: we can see what the new names for the data is that is used throughout the code.
function CreateWeatherThread() local MapScale = ScenarioInfo.size // x,z map scaling local WeatherDefinition, ClusterData = GetWeatherMarkerData(MapScale) local MapStyle = WeatherDefinition.MapStyle local WeatherEffectsType = GetRandomWeatherEffectType( WeatherDefinition ) //WeatherEffectsType = 'StormClouds' if WeatherEffectsType == 'None' then return end local numClusters = table.getn( ClusterData ) if not WeatherDefinition.WeatherTypes and numClusters then LOG(' WARNING: Weather, no [Weather Definition] marker placed, with [Weather Generator] markers placed in map, aborting weather generation') return end // If we have any clusters, then generate cluster list if numClusters != 0 then local notfoundMapStyle = true for k, v in MapStyleList do if MapStyle == v then SpawnWeatherAtClusterList( ClusterData, MapStyle, WeatherEffectsType ) notfoundMapStyle = false end end if notfoundMapStyle and (MapStyle != 'None') then LOG(' WARNING: Weather Map style [' .. MapStyle .. '] not defined. Define this as one of the Map Style Definitions. ' .. repr(MapStyleList)) end end end
For each cluster, which is a generator, the data that has been transformed before is being used to call the function to start generating clouds on top of those generators.
The cloud types are directly determined from the given map style that is defined in the weather definition marker - only the cloud types form that style are available because that is where the code is searching for to find a matching type.
function SpawnWeatherAtClusterList( ClusterData, MapStyle, EffectType ) local numClusters = table.getn( ClusterData ) local WeatherEffects = MapWeatherList[MapStyle][EffectType] // Exit out early, if for some reason, we have no effects defined for this if (WeatherEffects == nil) or (WeatherEffects != nil and (table.getn(WeatherEffects) == 0)) then return end // Parse through cluster position and datal for i = 1, numClusters do // Determine whether current cluster should spawn or not if ClusterData[i].spawnChance < 1 then local pick if util.GetRandomFloat( 0, 1 ) > ClusterData[i].spawnChance then LOG( 'Cluster ' .. i .. ' No clouds generated ' ) continue end end local clusterSpreadHalfSize = ClusterData[i].clusterSpread * 0.5 local numCloudsPerCluster = nil if ClusterData[i].cloudCountRange != 0 then numCloudsPerCluster = util.GetRandomInt(ClusterData[i].cloudCount - ClusterData[i].cloudCountRange / 2,ClusterData[i].cloudCount + ClusterData[i].cloudCountRange / 2) else numCloudsPerCluster = ClusterData[i].cloudCount end local clusterEffectMaxScale = ClusterData[i].emitterScale + ClusterData[i].emitterScaleRange local clusterEffectMinScale = ClusterData[i].emitterScale - ClusterData[i].emitterScaleRange // Calculate weather cluster entity positional range local LeftX = ClusterData[i].position[1] - clusterSpreadHalfSize local TopZ = ClusterData[i].position[3] - clusterSpreadHalfSize local RightX = ClusterData[i].position[1] + clusterSpreadHalfSize local BottomZ = ClusterData[i].position[3] + clusterSpreadHalfSize // Get base height and height range local BaseHeight = ClusterData[i].position[2] + ClusterData[i].cloudHeight local HeightOffset = ClusterData[i].cloudHeightRange // Choose weather cluster effects local clusterWeatherEffects = WeatherEffects local numEffects = table.getn(WeatherEffects) if ClusterData[i].forceType != "None" then clusterWeatherEffects = MapWeatherList[MapStyle][ClusterData[i].forceType] LOG( 'Force Effect Type: ', ClusterData[i].forceType ) numEffects = table.getn(clusterWeatherEffects) end // Generate Clouds for our cluster for j = 0, numCloudsPerCluster do local cloud = Entity() local x = util.GetRandomInt( LeftX, RightX ) local y = BaseHeight + util.GetRandomInt(-HeightOffset,HeightOffset) local z = util.GetRandomInt( TopZ, BottomZ ) Warp( cloud, Vector(x,y,z) ) local EmitterGroupSeed = util.GetRandomInt(1,numEffects) local numEmitters = table.getn(clusterWeatherEffects[EmitterGroupSeed]) local effects = clusterWeatherEffects[EmitterGroupSeed] for k, v in clusterWeatherEffects[EmitterGroupSeed] do CreateEmitterAtBone(cloud,-2,-1,v):ScaleEmitter(util.GetRandomFloat( clusterEffectMaxScale, clusterEffectMinScale )) end end end end
This is where the generators are turned into emitters. All the data is transformed (again) into the proper format that dictates how large the emitter can be, how much it should spawn and at what height it should spawn.
The type of a specific generator can be overridden when you force its type - this is determined when the type of emitter is chosen. Even for the forced type it only searches through the weather available in the selected map style for the forced type.
The emitters are attached to a (dummy) entity. If a player has no vision over this entity then the attached emitters do not spawn.
Make sure that:
INFO: Weather Definition { INFO: Direction={ 15, -30, 0, type="VECTOR3" }, INFO: MapStyle="Tundra", INFO: WeatherTypes={ INFO: { Chance=0.30000001192093, Type="WhitePatchyClouds" }, INFO: { Chance=0.30000001192093, Type="WhitePatchyClouds" }, INFO: { Chance=0.30000001192093, Type="None" }, INFO: { Chance=0.10000000149012, Type="None" } INFO: } INFO: } INFO: Weather Effect Type: \000WhitePatchyClouds
Your title reads as everyone in the community is in consensus with your tips. Yet, there is another topic (https://forum.faforever.com/topic/180/understanding-team-maps) that clearly shows that this is not the case.
I think the title would be more appropriate as 'Moses the Red's vision on map design' to clearly indicate that this is your opinion.
Besides that - I am happy that you wrote it out. All this can do is spark new discussions either on the forums or through other channels and that is what matters most. Discussions allows one to place his / her understanding or vision of the topic at hand in a new perspective.
@YouTheNoob Ram is in fact the limiting factor in any program that aims to be efficient. See also:
Which is a course about program optimization. There are two whole lectures dedicated to how RAM (and the CPU cache) works and how you can 'feed the beast' the most efficiently.
And about your suggestion on the thread count / processor usage: The game is threaded (render thread, sim thread, audio thread, etc) - but the sim thread (the limiting factor) is not subdivided into various threads. And that is why we have sim drops while 'leaving' all that computing power unused.
And to remain on-topic: a CPU with a large cache that can work with fast memory is beneficial - more beneficial than having a 5ghz CPU.
where is that file located exactly? I'll add it in the original post
A recent problem has risen in which mods are repeatedly uploaded for testing purposes. In turn, the vault is repeatedly updated by authors that make only minor changes. Generally the testing happens without any additional players - therefore the testing could also be performed locally.
This article attempts to deal with this issue as it is not required for the majority of mods to be uploaded for testing purposes. In turn, this will prevent:
All mods that you use are stored locally on your hard drive. They can generally be found at the following location:
C:/Users/%USERNAME%/Documents/My Games/Gas Powered Games/Supreme Commander Forged Alliance/mods
Replace '%USERNAME% with your username. If the 'mods' folder does not exist then you can create one. Store your mod, as any other mod, in this folder.
The FAF client stores a lot of data on your hard drive. They can generally be found at the following location:
C:/ProgramData/FAForever
What is especially interesting is the 'bin' folder that contains the executable 'ForgedAlliance.exe'. Double click this executable to launch the game without the interference of any client with the patches provided by the FAF community.
You can start a skirmish session and select the mod(s) you wish to test.
A few tips with regard to the development cycle:
You can open up the moho log as usual with 'F9' or by searching for 'toggles the debugging window' in the Key Bindings menu (F1).
You can let the game re-load any disk changes that you make in the mounted (accessible) folders of the game. You can do so by adding /EnableDiskWatch to the list of arguments when launching the game. This can be achieved via creating a shortcut to the executable and then adding /EnableDiskWatch to its target at the end. As an example:
C:/ProgramData/FAForever/bin/ForgedAlliance.exe /EnableDiskWatch
There are numerous sources out there to help you get going. As an example:
And a visual guide:
Tutorials with regard to mods are rather scattered at the moment. Feel free to contribute and assist in cleaning it all up. This article is by no means an introduction to making mods.
No - both locations (the original one mentioned in this article) and the fallback location is mounted (accessible) for the game, allowing you to use either location.
It may be in the model itself, e.g., that it floats slightly above the y = 0 plane.
@techmind_ You cannot disable all UI mods - that is not part of the equation. We introduced a sim-call to allow spread attack / move to function. This allowed a UI mod to directly interfere with the sim and because everyone has the same sim code it doesn't desync. Hence, we can remove that specific call again.
Your example (of ecomanager) uses engine UI calls (and is unrelated to this topic as far as I am aware) and we can therefore never disable it - just make it harder to use.
edit: I believe it uses this engine call:
and is being used here:
Which is unrelated to the sim call we introduced to allow spread attack.
From a coding perspective we either allow all of these type of UI mods (this mod from @Mach, SpreadMove, the flanking mod that @Speed2 mentioned), or we do not allow any of them: by removing the sim callback that enabled it in the first place.
And because anybody has full access to all the local lua source code you cannot prevent some UI mod from accessing the sim call while allowing others since you can remove the code that 'prevents' that from your local code - e.g., as long as the call is there it can be used.
As @biass mentioned: there is no regulating this as it would takes hours on hours of time. That is infeasible.
Therefore the choice boils down to:
Edit: you can not disable all UI mods - that is with the engine (that we cannot edit) absolutely impossible. You can only make it harder to use UI mods - but that is counterintuitive in my opinion.
@BRNKoINSANITY Of course! I understand - I just wanted to mention wondering whether other people agree to the observations . I just really like the video - I hope it helps people understand the game more.
@Tagada Yes, it is quite useful - but it feels strange when it happens to you .
@BRNKoINSANITY With regard to your balance eco video: From my perspective there are more resources in the game than just mass, energy and build power. I think there is also:
You can trade attention into mass / energy (manual reclaim) or into more build power (more factories / engineers) or into more presence (micro during a battle). And your opponent can cost you attention (harassing) or presence (forcing a battle), as they can cost you resources (lose extractors / power generators).
And attention is one of the resources that depends on the player. If are you relatively slow than you won't be able to compete with someone who can react a lot faster (or: can pay attention to the right things).
Overall great work on both of them, 10/10 would subscribe again.
So because of your video people can magically use the seraphim exp bomber like one large projectile.
Being a 1800 that is really not that good, I feel you. But, if you watch some replays of high-ranked players, understand the meta on some maps (seton, gap, etc) then you'll get yourself up to '1300' pretty quickly. Generally it is a meta thing that players are either unware of, or too aware of and get stuck in it.