@nine2 I got it just right now
The last one is a bit of a close up :D.
Edit: after inspecting, there are still a few artifacts. But a lot less visible than the previous set of artifacts.
@nine2 I got it just right now
The last one is a bit of a close up :D.
Edit: after inspecting, there are still a few artifacts. But a lot less visible than the previous set of artifacts.
A work of art is never finished, merely abandoned
This is in the GPG editor ! It doesn't use any stratum layers yet so there is still loads to gain.
I discovered what caused the artifacts: terrain that is too 'perfect' or 'smooth' causes the sediment to pile up. The piled up sediment causes artifacts.
I think the boundaries straight-line are some artifact from how the erosion splits up the terrain into blocks, allowing it to run on multiple threads. But that is just a guess.
The same location, but now without those artifacts .
A work of art is never finished, merely abandoned
@nine2 the river delta's are back but that is not the point - I'm trying to incorporate the idea of visual cues that you mentioned. I've just figured out how to make the decal stop suddenly without it looking strange, clearly indication that a piece of terrain can be considered flat from that point onwards . It is done via applying masks at the right places before and after eroding.
I've also been experimenting with allowing a stratum layer to 'leak through' so that there is detail up close. As an example the dotted circles have a stratum layer just slightly going through, where as the completed circles do not. The different is a significant boost in detail when you're zoomed in.
It does provide more 'control' over the color of the decal, which is a double edged sword: it allows you to more easily tweak it but its harder to see the end result without having everything together in the GPG editor.
Without all the additional noise and at a lower resolution:
Clearly shows where the ramps are - perhaps I can color tone the ramps a bit more so that they are more easily identifiable from mountains
A work of art is never finished, merely abandoned
@nine2 it is still under production. For now, these images will have to suffice .
A work of art is never finished, merely abandoned
Updated Mellow Shallows to version 14:
Updated Pool of Entropy to version 3:
A work of art is never finished, merely abandoned
Springtime (the map shown a lot previously) is in a finishing state! The map was made for one of the developers of the LOUD community. It was a remake of 'Valley Passage' but then more aesthetically pleasing.
The map had a few goals in mind:
Therefore this map has a 'core' and an actual map file. The core file solely (ab)uses the ozone editor to construct the general layout and uses stratum masks to construct masks that can be used in World Machine.
A screenshot that is taken at roughly the same location, depicting the general layout
This is all fed into World Machine and then used in the actual map file. If anyone would want to 'move a mountain' later on then I'd change it in the core file, run it through the world machine template for this map and then update the actual map file accordingly. A large portion of the process is because of this procedural in a non-destructive manner.
Center of Tatsu is another map that I've been working on. It is the first design of this topic:
A screenshot that is taken at roughly the same location, depicting the general layout and a few stratum layers used for masks in World Machine and the according output
The aim of this map was to solidify the workflow. And solid it certainly became. I was able to completely remove Photoshop from the equation which is critical because Photoshop is both commercial and slow software. The workflow is more automated by the use of a script. The only reason I required Photoshop was to convert the files to the .dds format. As an alternative Image Magick is used for that in combination with a script:
#!/bin/bash
# Variables used throughout the script
resolutionMask=256
resolutionHeightmap=513
target="../center_of_tatsu.v0001/"
for entry in "output/"*;
do
# determine old file location
fileOld="${entry%.*}"
ddsOld="$fileOld.dds"
# determine new file location
fileNew=`basename $fileOld`
ddsNew="$target/env/decals/$fileNew.dds"
# only change if file we want to convert is newer
if [[ "$entry" -nt "$ddsNew" ]] || [ ! -f "$ddsNew" ]; then
# convert the file
echo "Converting: $entry"
magick "$entry" -define dds:compression=dxt5 "$ddsOld"
# move it to the new location
mv "$ddsOld" "$ddsNew"
else
echo "Skipping: $entry (not updated)"
fi
done
This is only a snippet of the script. But essentially there is no more manual labour in converting the textures to the correct format / size. Now I can click and go - go get some coffee, talk to my neighbour, study a bit, end up at the toilet and then when I'm back all the textures produced by World Machine are converted and stored at the right locations.
On top of that it is significantly faster than Photoshop - converting an 8k texture could take up to an hour in Photoshop, where as it takes about a minute with Image Magick.
When developing the map I used 2k or 4k textures rendering the generating / conversion time to at most a minute, allowing me to quickly assess the results in the old GPG editor. By using the /EnableDiskWatch
program argument the textures are automatically updated and therefore the results can be seen without restarting the editor.
A work of art is never finished, merely abandoned
Back again with an update on my first map: Auralian - The Core!
To get an idea, this is how the initial version looked like:
And this is how it looks like now:
The aim was to learn and apply various techniques:
The map is by no means competitively interesting. But it can be a solid map for your first few games.
A work of art is never finished, merely abandoned
It depends a lot .
Typically there are multiple phases:
And all of these can take various amounts of time. The iterations phase depends on how much time was spent on the design phase. The implementation phase is typically one long sit to construct the template with the desired properties. After that it is flexible. Unless suddenly new properties need to be added.
As an example you can see this post from the mapping tournament. Archsimkat and I discussed that map in detail many times over, only to restart the design phase because we messed up the scale .That map has over 40 hours of work in it. Where as Auralian - The Core was not quite that time consuming. It was a remake, therefore the design was clear and it was more about making the template.
A work of art is never finished, merely abandoned
Autumn and especially Mauve are frustrating to play because there are exact locations where you have to put your engineer/ACU to edge build a factory, which also has to be in the exact right spot. Sometimes there is even a tree group in the spot where you have to place the factory so it is not clear that it will work. If you mess up either placement then your units fail to edge build and go for a long walk.
Edge building is a mechanic in this game, so you have to consider if you want your cliff to be edge buildable when making maps. If you don't want people to edge build then make the terrain rough and block placement using reclaim. If you do want people to edge build then make it clear that you can, maybe put factory tarmac decals in the spots the way it is done on Owl Cliffs. Most importantly, test out all the places to make sure they work as intended.
@ludmilla I agree
I've been working on a way to fix this issue. As an example in Kaali:
There is a small spot where you can move the engineer, and a larger spot where you can then build the factory. Slowly but surely this will be added for Autumn and Mauve too.
A work of art is never finished, merely abandoned
You could argue that it's up to the player to test the maps they are going to play and to look for buildable cliffs. That's part of preparation and can make some small difference between good players.
So you could have some "easy maps" where you mark the buildable spots and some "hard" and more competitive maps where people have to figure it out themselves
I see your perspective. And I agree that there should be some advantage to having played a map before. But these cliff building situations can be tricky and if you make a mistake it may as well cost you the game.
Some of my older maps will receive updates to support a similar feature to that of Kaali and future maps will have them too. I will make it a map option to turn it off for those that wish to play without - but it will likely be on by default (including for ladder) unless people really want it off.
A work of art is never finished, merely abandoned
I do not want anyone to be required to prepare to play a map. Maps should be designed well enough that you can just start playing and clearly see what is possible on the map. The strategy and decision-making parts of the game are what should be emphasized and things that get in the way of them should be reduced. Where you can and edge build or not is just a game/map rule, making the decision to edge build somewhere is actual gameplay. If you don't know the rules of a game you are unable to play or enjoy it to its full potential. It is the job of a game designer or mapper to clearly communicate the rules to the player. It is the job of the player to reason about those rules and try to make smarter decisions than their opponent. Making the rules hard to learn and forcing the player to intensely study the map or game code beforehand is just stupid.
Anytime I have to actually send an engineer/ACU to see where I can edge build, put my ACU in the water to see if it gets covered, check if a unit can travel over a hill, fire TML into a mountain to see if it works, or some similar activity I am taken away from gameplay and sent back to the rule learning phase. I consider these to be failures on the part of the mapper to effectively communicate the rules. Mappers have an extraordinary responsibility because so much of this game is map-specific. It seems to me that most of them do not understand this responsibility and just throw random stuff together.
That is one passive aggressive post to map makers in general
I am in the lucky position to be A, a decent player to some degree and B, have several tournament players that are willing to give their time to help work on a design carefully. You're making claims about 'responsibilities' that 95% of the mappers can never adhere to simply because they are either not A or don't have B. Claiming that they 'do not understand' this responsibility is harsh.
Of course they want to make a map that works. Why would someone spent hours on hours to make a map just to see it never being played because of some issue that appears obvious after the fact. I think your point is valid that there are some things to consider, could you make this into an effective list / guide that map makers can read? Like a checklist for common gameplay elements that the map should adhere too.
A work of art is never finished, merely abandoned