New Scenario: Himalaya

[Jubalbarca]

Just finished this new scenario!

Mace VS Mauryans, three big valleys with lush vegetation below and towering snow-capped peaks above. Slightly inspired by the incorrect theory about the village in the Himalayas people once thought was a leftover of Alexander's army. There's a river down one side of the map, and the middle pass is blocked at the foothills end by a forest. This map is NOT suitable for AI use at least if you're playing as Macedon (should be better with the Mauryans) because the nearest metal for the Mauryans is behind the forest so they'll walk up the side valleys and through the Macedonian base to try and get to it.

I'm also working on an RMS script to make Himalayan maps.

Downloadable here as with all my other scenarios: http://www.exilian.co.uk/forum/index.php?topic=1078

[Nolanjoker]

wow, nice work, we will play your maps in the new alpha XIV!

[quantumstate]

That looks nice. Very pretty.

For maps designed to be played as normal games you should have 1 large stone and metal mine in each players base. Otherwise it really distorts how the game plays.

[Shield Bearer]

Looks really cool Although, I don't think palms trees were predominant in the Himalayas region

[Jubalbarca]

qs: Even had I done that, I think the metal issue would have triggered as soon as the initial mine had run out; I may make a more AI-friendly version if there's demand, but my scenarios at the moment are really designed to be more fun multiplayer challenges than the standardised RMS scripts so I'm not worrying about that too much.

Sb: True, I wanted to give it quite an Indian feel though, I was kind of making things up as I went along as may be obvious

[oshron]

personally, i think the mountains should be more peaked; they look a bit too rounded here, if you ask me

[Thorfinn the Shallow Minded]

Well, unlike common thought, there are many mountains which have rounded and flat peaks.

[Jubalbarca]

I just find it's hard to make good-looking spikes. And the gradients aren't actually that unrealistic as Thorfinn points out.

[sanderd17]

I've been thinking about a "peak" elevation brush. When you press that brush, it keeps the center height of the brush, and the height on the edges or your brush, but modifies all heights in between towards a straight line between the centre point and the edges. But I just can't find where the mathematical behaviour of the brushes is defined.

[wraitii]

Sanderd17: probably in source/tools/atlas/game interface/handlers/elevationhandlers.cpp

Atlas source is a real mess, defining a brush is done in like 3 places...

[Jubalbarca]

That'd be really useful

[sanderd17]

Sanderd17: probably in source/tools/atlas/game interface/handlers/elevationhandlers.cpp

Atlas source is a real mess, defining a brush is done in like 3 places...

Oh, how handy

I'm rubbish at icon design though, so if someone could design an icon for "creating a peak", that would be great.

[Mythos_Ruler]

A forest brush would be nice. :/

[sanderd17]

i'll do the simple one first. maybe I'll understand the brush code by then, and can also work on some forest brush. Btw, how do you see the interface of the forest brush? How would you like to select your entit(y/ies), or select the density of the bush? should the forest become double as dense when you go over it twice?

[quantumstate]

Some thoughts about a forest brush that I had

The simplest idea I have for a forest brush is to have a density setting and a single tree type selection. Trees would be collision checked so two trees cannot be placed in the same location, so to get a mixed forest you would pick a low density and then go over it multiple times with different tree types selected.

For multiple tree types at once the simplest is just multiple selection in the entities box. What would be nicer would be a whole new GUI page so tree sets could be created. This would make things easier for users since they can just pick presets, and advanced users could create their own sets. The GUI would just have a list of trees with a list of proportions.

For the painting there are two ideas I came up with, first (which I prefer) is that during one mouse press if you overlap the previously painted area it won't add any more trees, this could easily be implemented with a buffer the size of the map which would be painted and new trees could only be added to unpainted areas of the buffer. The other idea is to only add trees in the area that was not covered by the brush in the previous frame. This means if oyu went back over a area that had been painted it would add more trees.

[fcxSanya]

For the painting there are two ideas I came up with, <...>

Another alternative can be the airbrush-like behaviour (where the brush generates entities with a constant speed independently of what is already 'painted' in the same area), it sounds simple to implement and would allow the variable density (with smooth density changes) forests to be 'painted' without changing the brush settings.

[sanderd17]

If someone wants to try out that pike brush, here it is: http://trac.wildfire...com/ticket/2059

See the screenshot to compare bumps made with the regular tool, and bumps with the new one (same settings otherwise)

Some thoughts about a forest brush that I had

The simplest idea I have for a forest brush is to have a density setting and a single tree type selection. Trees would be collision checked so two trees cannot be placed in the same location, so to get a mixed forest you would pick a low density and then go over it multiple times with different tree types selected.

For multiple tree types at once the simplest is just multiple selection in the entities box. What would be nicer would be a whole new GUI page so tree sets could be created. This would make things easier for users since they can just pick presets, and advanced users could create their own sets. The GUI would just have a list of trees with a list of proportions.

For the painting there are two ideas I came up with, first (which I prefer) is that during one mouse press if you overlap the previously painted area it won't add any more trees, this could easily be implemented with a buffer the size of the map which would be painted and new trees could only be added to unpainted areas of the buffer. The other idea is to only add trees in the area that was not covered by the brush in the previous frame. This means if oyu went back over a area that had been painted it would add more trees.

There is even an other possibility: paint regular terrain, and have an "entity fill" button. So you can fill a certain terrain type with certain entities (either only one patch, or all patches of the same terrain type). As most of the time, you want trees over a forestfloor type terrain, I think this would work pretty well.

@fxSanya, your implementation would be simple to do, but hard to use. You can't let the number of entities depend on the speed the cursor moves (unless you add them really slowly).

[feneur]

I think it might be wise to consider that such a brush could be used for other things than forests. I mean sure, forests is probably the most likely, but unless there is a good reason not to I think it should be possible to paint with any entities the user may like. Perhaps the selection could be limited to trees by default though, to make it less confusing for new users.