Skirmish Maps - Number of Players

[coworotel]

Hello,

Now it is possible, in skirmish maps, to choose "unassigned" for a player, and the player will just stand there doing nothing. Why not have an option to disable a player in skirmish maps, so they can be used more times? (For example, if I make a skirmish map for 8 players, they could just "disable" some players and make a 2v2 match etc.) In that case, any entity with that player number would not be generated. Is this a good idea?

[Guest]

I suppose it conflicts with the whole purpose of why skirmish maps were added. Fixed terrain, fixed player position and numbers, but with the freedom of choosing civs.

[coworotel]

I thought that was more for scenarios... For example, now I am working on a 4 player map, and it would be nice if it was possible to make 4 players matches on it, but also 1v1 matches between player 1 and 2, and 3 and 4 (the ones on opposite sides). I have the option of duplicating the map: one for 4 players, one for p1 vs p2, and one for p3 vs p4.

I thought the purpose of skirmishes was similar to random maps, but without being randomly generated (which has many advantages: it's easier to make for non-programmers, it is usually more carefully crafted, etc.).

[Nescio]

Personally I never really understood the purpose of skirmish maps, nor why they are the default; I would appreciate it if this could be changed to random maps (`gui/common/settings.js` function loadMapTypes()).

And it would be nice if it were possible to randomize the number of players on random maps.

Edited March 28, 2019 by Nescio

[elexis]

∃ ticket

41 minutes ago, (-_-) said:

I suppose it conflicts with the whole purpose of why skirmish maps were added. Fixed terrain, fixed player position and numbers, but with the freedom of choosing civs.

The question is what the use of the starting units of an "unassigned" player is. The players who report it see 8 starting units and 1 CC idling the entire game a. And that on all maps.

But skirmish maps serve the same purpose as scenario maps, just come with the civ-replacement feature, and the purpose of a scenario map is to come with an map created in atlas. Consider someone would create a map that comes with large prebuilt cities. If the civ replacement (SkirmishReplacer) would delete all buildings, it might not just nuke the 8 starting units and starting CC, but possibly half of the map.

So perhaps the map should be able to specify whether it allows nuking playerslots or not. That could be rephrased as a playernumber dropdown.

The only counterplayer to maps restricting gamesettings is that players prefer to have their settings persisted when they browse through the maplist.

In singleplayer the issue doesn't impact so much, but in multiplayer it's quite drastic. One clicks on host, X players join, then players negotiate the gamesettings step by step. While it would be handy for the developer to first select a map before players can join, players prefer to negotiate the map after having joined and after having made several wishes already. So resetting the gamesettings too often will make the gamesetup stage much more timeconsuming. But persisting settings where possible, but secretly changing some of the settings without the players noticing when switching the map is also very unexpected. So it's a dilemma. The only resolution I could imagine to that is the gamesetup displays a history of which settings precisely changed. So if the host scrolled through 30 maps but then one changes the victory condition from "conquest" to "none", or replaces an "unassigned" playerslot with an AI, then all players might be informed if it's presented well AND all gamesettings would be persisted where possible during mapchanges.

Then one could allow skirmish maps to offer "unassigned" if and only if the map maker is ok with the starting player entities to be deleted.

As mentioned, ticket somewhere.

[wowgetoffyourcellphone]

10 minutes ago, Nescio said:

Personally I never really understood the purpose of skirmish maps, nor why they are the default;

The random maps are ugly (a couple are nice). The skirmish maps are not ugly. 

[coworotel]

9 minutes ago, elexis said:

So perhaps the map should be able to specify whether it allows nuking playerslots or not. That could be rephrased as a playernumber dropdown.

If we use the "unassigned" instead of a player number dropdown we can choose which players to remove.

9 minutes ago, elexis said:

Consider someone would create a map that comes with large prebuilt cities. If the civ replacement (SkirmishReplacer) would delete all buildings, it might not just nuke the 8 starting units and starting CC, but possibly half of the map.

Shouldn't these maps should be scenarios? I think it is a clearer distinction between the concept of scenario and skirmish if we consider skirmish = non-randomly-generated random map.

In any case, what is the current purpose of "unassigned"? Does seem very useful to have a civ. there without a player or AI controlling it...

[elexis]

11 minutes ago, Nescio said:

And it would be nice if it were possible to randomize the number of players on random maps.

Would require some UI to configure that, but idea is good enough for a trac ticket. If you write one, people will remember it beyond the scope of this thread.

12 minutes ago, Nescio said:

Personally I never really understood the purpose of skirmish maps

Create a map in atlas and allow the player to chose gamesettings, especially civs. Random maps are written with code (thus impossible to create for many), Scenario maps have fixed gamesettings. Didn't we have a patch that adds this exlpanation as a tooltip?

1 minute ago, wowgetoffyourcellphone said:

The random maps are ugly

Maps look as good as people make them, regardless whether it's in atlas or with code.

The random maps have become progressively better and more complex over time. It's expressed in the lines of code: Mainland 200 lines, Red Sea 388, Danubius 800, Jebel Barkal 1500, Oppidum 1800.

The big selling point to random maps have is that they generate the terrain and entities after the playerchosen gamesettings, number of players, biome, difficulty, resource selection, ... whereas scenario maps are always the same thing every single time. The atlas map types dictate what map the player can experience, but the random map is adapting to the players choice.

The randomness aspect is not so dominant, it's more "procedural mapgeneration" than "random map generation".

One can use procedural maps also to load an premade atlas map in a random map and just put random forests and mines on it with code.

But we need an entirely new software create random maps that are as detailed as LordGoods assemblies. The random maps opreate on a grid that is few men wide. We would need to increase the resolution of the grid by a factor of 4 or more. But that would make the code probably 16 times slower or worse. Challenge accepted though to create an as good random map to compete with LordGoods screenshots, but it will be hard to figure out a performant system and code to create the complex actor patterns.

[Guest]

3 minutes ago, elexis said:

But we need an entirely new software create random maps that are as detailed as LordGoods assemblies

If we are talking about the same path thing, not necessarily. The current tools may not be able to replicate it a 100 percent, but it can come close. The following was an attempt at using the paths with arbitrary buildings in a random map. Far from perfect, but does look better than if those were not there.

Spoiler

The thread is going off-topic though.

[elexis]

The paths were created in atlas or with code? Cant read

23 minutes ago, coworotel said:

If we use the "unassigned" instead of a player number dropdown we can choose which players to remove.

One doesn't really know which playerslot will determine which playerposition, whether removing the 2nd or 4th slot would turn out to be a good idea. There was one or more tickets describing a feature where players can select the starting position they're assigned to (and how players could chose a group-placement pattern for random maps).

[coworotel]

21 minutes ago, elexis said:

One doesn't really know which playerslot will determine which playerposition, whether removing the 2nd or 4th slot would turn out to be a good idea.

In skirmish maps and scenarios the mapmaker can give a name to players, so if there are names like "Guy in the mountain", "Guy in the river" etc. it would be easily identifiable. And also if the host know the map, which happens when you play a skirmish map many times.

[elexis]

Are the algorithm and code to that pathplacer a trade secret?

[Guest]

Spoiler

If the implication is uploading to Phab. Been there, done that. :-/

 

Edited March 28, 2019 by Guest

[Stan`]

Fail, retry, fail, retry, that's how learning goes.

[elexis]

Spoiler

"Nice question, I will answer a different one" - Martin Sonneborn 

More wondering about the feature design than the source.

[elexis]

On 3/28/2019 at 4:52 PM, stanislas69 said:

Fail, retry, fail, retry, that's how learning goes.

If every try results in a failure, it would be a failure to continue trying the same thing. The step of adapting the dependent variables is missing to expect something other than a confirmation of previous measurements. So I personally don't encourage people to upload more patches if we don't have the capacity to review them, especially if the people already uploaded a number of unreviewed patches. Been there, done that not getting any reviews. If is noone donating their service but people who can provide the service, the question is how to convince them to provide the service. While contributors have been following the Phabricator guideline to upload patches, almost noone went further than that and asked individual developers personally and somewhat persistently whether they can commit a patch, and why that patch is really important for 0 A.D. to have. Reviewing a patch because one wants to please an external contributor motivates some, but if you can show that a patch is important for every player (for example players suffering mental damage when encountering gamebreaking bugs after having spent an hour to build their base), then the chances to get the patch committed are increased, based on the actions of the external contributor more than the member. Been there, done that. Ideally the workflow is: fail, retry, succeed a little bit, retry, succeed more. Seeking out members who don't review patches but are entitled to doesn't imply unkindness. If someone wishes for a commit but doesn't get it, the question is not to upload more patches but how to get to that commit with the given people who have commit access and haven't vanished entirely yet. So maybe it would be better to recommend people to upload their patches _and_ try to find a reviewer than only recommending the former. The latter is a communication problem, so it is bilateral, i.e. a variable that can be modified by both participants.

[elexis]

On 3/28/2019 at 10:37 AM, (-_-) said:

If we are talking about the same path thing, not necessarily. The current tools may not be able to replicate it a 100 percent, but it can come close. The following was an attempt at using the paths with arbitrary buildings in a random map. Far from perfect, but does look better than if those were not there. 

Random maps support loading PMP files, so one can create that scene in atlas and let teh random map place some of these. That, or hardcoding sizes would be one way to achieve the screenshot with the least effort on random maps. Certainly you made me explore more possibilites how to implement that.

[Guest]

Or, you can just calculate the boundary using the obstructions' shapes and sizes. For producing that screenshot, I did hardcode the path decal length IIRC. The screenshot was taken a long time ago.

Re: the other post. There are many other factors involved in a project which influence one's desire to keep going.

Edited March 30, 2019 by Guest

[elexis]

I said something wrong, the PMP file only contains the terrain, the random map support would need support loading the XML file for that mentioned approach. Might be a good tool to have.

One of the problems with the more generic approach is that these VisualActors don't have obstructions nor footprints. Otherwise they'd be so large that we could continue to use the mapgrid with fixed tilesizes of 1. Perhaps that could be used as a base for implementing the lower resoluted grid. In the first pass the random map is created as usual, then the 4*4 higher resoluted, bad performant, grid is initiatalized and only used for VisualActors. That way one could save some memory and performance. On the other hand, maps need to create the random maps in a specific order, first the terrain choices that consume the most area, then the paths, and then filling the rest around the paths. So that would invalidate the approach to put all visual actors last, if the paths are visualactors.

Hardcoding the visualactor size isn't out of the ordinary, since random maps hardcode the tile distances (>= obstruction sizes) all the time. The more difficult task is what to do after having obtained that information. A similar problem occured in Jebel Barkal where the buildings inside the city should be rotated so as to face the path. (Looks more natural and units are spawned on the path, less often in between the buildings). But it was an uncomfortably complex problem that would consume more than one day, not few lines of code and then would only be solved for that one map unless one can abstract the code to reuse it on other maps in similar situations. I had actually written an algorithm for it, but it was too slow, something like 10 seconds, so I had to ditch it. The same problem is faced when we want to create paths that are much smaller than tilesize of 1. For example if you want to have a path that is 0.5 tiles wide, a tree 0.2 and at 0.8, and then create a waving path, not a straight line. Consider this screenshot, the tiny little fences, the perfectly enclosed wheat, the little path parallel to the fence. https://wildfiregames.com/forum/index.php?/topic/24645-specialized-building-decals/&do=findComment&comment=359393 It's solveable, but it's hard. And if it would be solved, it would give a huge benefit. Imagine our maps would look as good as on that screenshot. Other than the implementation being challenging, the question is also figuring out how the cities were planned. The one on LordGoods screenshots looks much more natural than the one on jebel or oppidum. Saw this documentary recently. That guy had shown that historic cities didn't grow by extension over time but were planned on a drawing board with a compass to create harmonic geometry in the city. So I guess I need to ditch the idea of hoping to get away with the existing PathPlacers and not using a simple deformed checkboard as a cityplan. (Even if one would create the city in atlas.)

To also post something on topic: https://trac.wildfiregames.com/ticket/1306

[Guest]

18 minutes ago, elexis said:

For example if you want to have a path that is 0.5 tiles wide, a tree 0.2 and at 0.8, and then create a waving path, not a straight line.

A way could be to subdivide the path to even more nodes. (in that screenshot, a node is present on the center of each path decal iirc.)

And then we can calculate normals and translate the trees appropriately. The issue?, computationally intensive and it would need a lot of points to look decent.

Also, the path on that screenshot is by all means, 0 tiles wide.

I gues it is worth mentioning that the connected houses thing was pretty much a PoC done in the previously described method. I currently do not have any plans to actually implement this in a decent way)

(split the topic or something if you want to keep this thread on topic)

Edited March 30, 2019 by Guest

[Guest]

Since I was bored, I actually spent time visualizing this.

I would still advocate for all paths with width < 1 to have width 0. In such a case, the whole process would look something like this.This captures all the mentioned issues. The first one is too low res to do anything meaningful around it. There are just far too few points for interpolation. There is a limit to how smooth it can be done considering the static length of the visual actor itself. The smaller path on the right with much more points can somewhat do the trees on the side thing. But there is a trade-off with looks and performance. (Normal calculation might be significant.). Interpolation is inevitable even in that case.

Spoiler

i could be approaching this whole thing the wrong way around, but that was what I came up with then. What do you have in mind if any?

Edited March 30, 2019 by Guest

[elexis]

2 hours ago, (-_-) said:

calculate normals and translate the trees

That's about the same approach as used for buildings on Danubius. It uses the linear wall placer. But it's a terrible hack, because the entities that have an offset (here buildings) cover a significant area, can overlap. Those wallbuilder values are a set of magic numbers that were basically obtained by trial and error.

Currently one first places a path, then one can place paths at distance 0 to 1 near it. This way the trees border the path directly without having to compute any angles or coordinates. But that only allows symmetric path decoratives. It's not possible to have a path and left of it one kind of tree, on the right side a small stream. To achieve that, we would need a pathplacer that applies different painters depending on the distance to the path. To place fences and visual actor paths, these painters would still have to be informed of the angle, which could be achieved by passing functions angle => Painter instead of just a Painter instance. That won't work with the central createArea idea of mapgen, but I guess that's inevitable. To gain a greater resolution that tilesize 1, one could just assume higher resoluted grids and do performance optimizations.

The same approach angle => Painter could also be used for some ObstructionPlacer to achieve paths going around a building. One could obtain your and probably LordGood's screenshots with that, and obtain the connecting paths by connecting two random nodes that don't collide with any of the buildings or path tiles.

So I guess we need createVectorArea, PathVectorPlacer, ObstructionVectorPlacer, and these somehow consuming Painters and VectorConstraints.

I'm leaving a ping for @historic_bruno since he mentioned to be back recently and had created the random map PathPlacer 7 years ago that is used by every better map in 11152 /#892. Perhaps he has an idea how to create a random map script that looks as great as LordGoods sceenshots at

On 7/22/2018 at 12:44 PM, LordGood said:

 

 

[elexis]

10 minutes ago, (-_-) said:

Normal calculation might be significant

(x, y) -> (-y, x) should be cheap enough, so it depends on the number of calls mostly.

The important part is to abstract this somehow. The magic of random maps is that one can do anything with the createArea(Placer, Painters, Constraints). Every feature so far could be refactored into a Placer, Painter, or Constraint, so one could combine all of that arbitrarily like Lego bricks. It sounds like we just need to extend, or transfer the concept to vectorfields, or whatever this is. I guess.

16 minutes ago, (-_-) said:

Interpolation

Well we have a PathPlacer algorithm that comes with interpolation, one can vary the number of nodes on the path, it's modeled by some sine waves. It sounds like that part of the problem is solved already, it only needs to be extended to pass the angles and distances to the path to the painters, and possibly constraints, and it must be performant enough.

I guess the performance problems of using high-res grids (if going for those grids to begin with) could still be limited by using the high-res grid only for the operations that need it, and the regular grid for the ones that don't, while updating both grids when painting (tileclasses). I don't know further, so I'll make a tea.

[Guest]

Even if a tile is divided to 4 sub-tiles. the high-res grids can only be used if they are restricted to the area where they are needed. A bunch of high-res grids of the whole map would probably be impossible (oom). Then again, I suppose it is preferable to avoid them unless it becomes absolutely necessary.

The following is relevant only if the high-res grids are constructed for the whole map and depends on some other things like how the much more precise tileclasses would work.

Spoiler

For a giant map, the high-res grids would cost a minimum (I guess some of those need to be larger than a u8) of 4194304* bytes for each grid if something like a bit vector is not used. There is a u16 heightgrid, a u16 texture grid and thousands of Entity instances. The rmgen runtime has only 96 MB. I think I read a few posts here on the forum regarding giant random maps already hitting the limit if there are many entities.

* I don't know whether additional memory is allocated by JS.

 

 

[wowgetoffyourcellphone]

2 hours ago, elexis said:

Those wallbuilder values are a set of magic numbers that were basically obtained by trial and error.

IMHO, as an aside, regular walls should be remodeled to be standard lengths