elexis

I want paths where there's a texture in the middle, to the right of the path a parallel stream and then trees parallel to that path. Just using BFS to extend the area of some PathPlacer doesn't cut it, because we want the trees only parallel to the direction of the path but not at the start and end of the path. These were unintended artifacts in most use cases. So the only way to accomplish that would be to have the PathPlacer return the direction of the path at every position that is part of the placed area. Since not every placer has a direction information, this metadata would have to be optional. So it seems including yours, there are two use cases of Placers generating custom position metadata that Painters should use, so maybe createAreas should be able to support passing arbitrary position metadata from the Placer to the Painter? Painters should still be able to work as independent of such metadata as possible and only parse it if its technically inevitable because the information would be lost after the Placer ran or would be too time-consuming to recreate. Can we test the hypothesis and find more use cases? Edit: It seems the catch is that the Area needs to save the metadata and changing the Vector2D object seems messy, so all Placers and Painters would have to construct and parse { "position": vector2d, "metadata:" foo } everywhere which is not too attractive either. Edit 2: The paintRiver function does such a thing for instance and it was already used for one non-river for that reason (the transition of the fertile land to desert on jebel barkal consisting of parallel textures). Started converting it to a BFSPathPlacer, but it's also limited, because one can't use it for a circle segment area for instance. Meh.

Step 13: Create separate paths for the different rings inside the oppidum, otherwise paths are too crowded in its center. Add bushes between buildings and paths. Step 13: Oaks and fences at the ditches, bushes inside the city.

In which way was it epic?

I heard it not only reduces FPS but even freezes on some machines for the duration the key is pressed?

Step 9: Some of the bridges become fortified gates. At the wooden bridges small paths start, at the fortified gates, larger roads lead away from the city. Bushes are added to the walls. Step 10: Fortresses near roads are added to try to address the balancing problem that all scripted opponents would only attack the 2-4 players closest to the city. We observe a big balancing problem with the random paths. Step 11: To connect all of the players with the central strip, player paths are added to random places on the road. It's the places where the shallows going to be. It becomes evident that one of the concerns that is visible in the very first design sketch will turn out to be a severe balancing problem: The shallows can be walled off easily, then all scripted enemies will take the path through the left side instead of attepting to destroy the walls; i.e. the players on the left get's all scripted enemies, the players on the right side none. This means either the map design must fundamentally change (for instance making the entire stream passable), or the scripted enemy must be ordered to destroy the closest buildings instead of trying to reach a point behind that obstacle (sucks to create a different bot strategy for every map) Step 12: Adding farmland and farmsteads near the ditches to make the city more vivid and realistic.

Step 6: The ditches require bridges to pass. City fortifications usually had a path around the city walls too (yellow). To fire up more inspiration and give a more realistic impression, adding Forests and more generic Roads. Step 7: Adding the buildings with the CityPainter created when Jebel Barkal was introduced. Time to get rid of the ugly sketch textures and find something that looks better but isn't fine tuned at all. Step 8: Instead of asking Stan to create variants of the bridge models for different sizes (like we have for foundations and rubble), I decide to increase the size of the bridges to fit the model, yielding a more impressive fortification. The terrain at the bridge painted with the wood texture.

Implementation Having gathered enough design constraints, the implementing of the sketch is started. It will be easier to implement the sketch and derive new design goals and inspire new ideas from the implementation rather than to try to imagine something great and predict all possible complications that weren't thought. Step 1: Player positions, main streams Step 2: Confluences of the stream, city area, main road Step 3: Civic Center with a little stream or ditch around it. The central attractor and eyecandy of the city is the purple area and will become some kind of marketplace. Step 4: The oppidum receives a set of walls. There are paths (yellow) around the walls to make it more rich than Jebel Barkal. Step 5: A ditch around the walls makes this a lot more attractive. Paths from the CC to the gates of the fortification invoke an initial city structure.

Map Idea The next step was to generalize some of the design properties worked out in the sketch analysis and apply them to a new map in a different context. One of the problems of Jebel Barkal is that the central area is occupied by the city, one can only use the lower 35% of the map effectively. So this time I thought to put the city on the left side. To be able to use a greater part of the map for player purposes, the players are located on opposing ends, rather than confined to one half of the map. The Irrigation canals on Jebel Barkal made it not only easy to wall off, but also prolonged the distances to travel between players, and split the map into compartments. That can be maintained and defended independent of each other. On maps without natural barriers, map control is often total. So on this map we could have these compartments again by adding streams and confluences of the streams. To distribute the gaia attackers more evenly on the players, I don't align playerbases in a linear but an alternating pattern. There must also be shallows so that the scripted opponent can reach the enemies at the back. Due to the design trait to be able to wall off compartments of the map near confluences, it would be likely that gaia is walled out from the middle strip of the map. So there must be a safe path for the scripted opponent / gaia in the middle of the map, horizontally. Legend: Black: player locations Purple: scripted opponent city Light blue: Streams / water Green: Safe economy, trade Blue: shallows, direction of playerbase expansion Red: Places of frequent fights

This thread will be used to document the development of the new mapgeneration script that should become a proper successor of Danubius and Jebel Barkal, i.e. a procedurally generated scenario map for arbitrary amounts of players, mapsizes with a scripted opposing city with fortifications depending on a difficulty setting. The theme of the map are the forests of Gaul, the opposing enemy village is an Oppidum again. Map Design The design is the most decisive step during feature development. I start with the terrain design and show how it shapes gameplay. Since the primary aim is to create a better map than Jebel Barkal, I first analyzed what made Jebel Barkal a success. You might want to take a look at the Jebel Barkal - Illustrated Walkthrough in case you are not familiar with this map yet. The below sketch displays: red: fights (location where fights occur frequently) green: trade (location where fights rarely occur, that are safe for women and trade carts) blue: expansion (locations that are feasible to build new bases at or expand the current base progessively) white: barriers (here irrigation canals that allows quick and effective walls) We record and evaluate the observations about the map design: Most maps are circularly symmetrical, which makes them one-dimensional and so the gameplay becomes one-dimensional as well. Most maps consist of a random composition of natural resources, trees, lakes and hills. This means there is no information, no meaning, in the terrain, no essence, nothing shaped by man, no points of interest. On Jebel Barkal, there are four distinct areas with a unqiue biome and different meanings / use cases for players to reside there. Water: Low Risk / High Reward Fish is faster income than fields Collect wood remotely in a safe location Transporting siege engines quickly and directly to the enemy base Survival on the water after being wiped out on the land Fertile Land Low-Risk/Low-Reward: The only location with feasible amounts of wood, even abundance Farthest distance to the opposing city Irrigation canals allow easy walling. Allies very close by to help out quickly and effectively. No mines and few space to build, one has to build up trade or expand. Desert: High-Risk/High-Reward Very attractive as mines occur in abundance and other places don't have mines at all Very unattractive because the occupying units are dislocated, there are no natural barriers, no wood, no neighbors. So the location is an easy target for the opposing city, hard to defend and maintain. Hill: High-Risk/High-Reward: Conditional Use: Since the hill is heavily defended an since the home base is usually already established, the hill can only be captured in games that last long enough for one player to be lose the entire home base, but have enough of an army left over to wipe out the large number of troops on the hill. It can and does occur in Diplomacy games more often than in team games. Once the mountain is conquered, one can pickup treasures and build a base that is extremely easy to defend. The city in the center of Jebel Barkal is the most significant difference to every other map due to the following gameplay design traits: Balancing factor: Military buildings spawn different attackers per building, so there is proportional reward for the player to take out individual buildings. Surprise factor: The city is composed of different buildings every time. Eyecandy factor: Since the city is not created by a player after the gamestart but at map generation time, the terrain can be changed in accordance with the city, i.e. there are different ground textures in the city and for paths, there are trees and ditches. This is currently the only way to show how men shaped their environment and makes everything appear much more naturally, resemble actual cities or villages. Problems of the Alpha 23 Jebel Barkal map (see also #5150): There is no victory condition or other sufficient incentive to invade the city on Jebel Barkal. Players have to play with the general Conquest and other conditions. So it is economically much more feasible to destroy the multiplayer enemy rather than the opposing city. We see the city only being taken out in rare diplomacy games where one player claimed the hill. Balancing is hard and has to be derived experimentally. Examples: Hardly varying Soldier count is by far not as relevant as Elephant/Siege Engine count varying drastically. It should not depend on map generation (randomly 0 to 10 elephant stables on a normal sized map). Lag: Since there are much more buildings and gaia units around (up to 8 * 150). Formations make it quicker, but can also have separate problems, especially pathfinding ones. In the next post I will show an idea I had after the above analysis and set aim.

Yes, that line is correct. Capture rate is proportional to building health except that it doesn't get any easier with the last 10% (because ownership changed too quickly then).

The point is that players should use siege engines to destroy buildings and walls, not infantry. Capturing becomes easier the more the building is destroyed.

(Thanks to the one who flagged downloadapps as a spammer.)

Consider the english string "word1 word2 word3" that would be translated to "translation1 translation2 translation3 translation4". But its indeed better to avoid such things. Another example are translated txt files and map descriptions where some words are colored.

The lobby use policy enforcement team proclaims unban in few hours.

Same question here, how is the rain implemented? (As the camera isn't moving it could also be a single 2D texture cheat) The rain we currently have is extremely low performant and rotates with the camera tilt which is incorrect as mentioned by wow.

I wanted some overview also about the unit composition of oneself, possibly of allies too. Like 10 trade carts, 20 infantry, 30 houses, 2 civic centers (with buttons showing these entities upon click or something), perhaps that would be logically related and could be shonw in the same screen. Also needs scrolling I guess.

The point I was trying to make is that we not only have to consider OOS that are bugs on our end but also the possibility of players utilizing it as an exploit in order to not get a rating change. We must know that it cannot happen often before we rely on that fact. I also have the impression that we'd only have to simulate very few games with your proposal (but we must be certain). Maybe, but by definition it was a rated game, so it were true to the name if it would apply a rating in any case. If we don't apply a rating in some cases, we must check for and rule out exploitability. In this case the player would have to know how long he would have to remain connected to the game just to get the rating of the leaver. For instance if we leave a 5 minute margin before marking the disconnected player as a loser, then the one sitting in the game must be aware when the 5 minutes started and how long he has to sit there. (Another edge case: What if both players have computed the same gameresult but the report wasn't sent quickly enough before the disconnect? I guess that's also rare enough, especially if the "you lost/won, leave?" mesagebox would only come after the report was sent and received.)

You are right; simulation can be omitted in the case of players remaining online and agreeing with the rating and that this is more performant than always simulating. Simulating only after the game ended would mean that the rating is adapted hours after the rating changed, so it would be necessary that this only a rare occasion. Sure we can't construct some exploit? I guess you are right, but we must prove we didn't forget some case. Is someone is changing the code (to fake rating or by having some semi-legit GUI mod that removes mod version checks) the only case in which one'd have to simulate? If both players disconnect before the disconnect clause reduces the rating, then the player that disconnected first gets the rating reduction, hence not having to simulate in that case? Independent of your improvement, what do we do if there is an OOS error? The server can detect it, but it can't determine if the rejoiner computed the wrong state due to a code error or abuse.

Reserving a right implies being able to grant it. There are many licenses possible, people can write their own rules. The point was mostly to clarify to users that his own files are not covered by the GPL v2+ (which covers the other half of the directory).

Currently it's technically impossible for us to moderate ingame chat because we don't have access to the data. If we process userchat, we have to add it to the privacy policy and then some people will complain that there was bullying or anything else in userchat hosted in our game and then we have to moderate that too or justify ourselves each time it is reported. I guess if there was WFG hosting we could still only relay the chat and not store it, thus continuing to have it impossible to moderate that. (Seriously we have more important things to do than kindergardening.)

If one client (player or observer) is lagging, all of them are. The game can only progress at the speed of the slowest simulating or laggiest one. So a WFG hosted server for unrated games only had the advantage that the host can't alt+f4 to kill the game anymore. Notice that it's easily possible that WFG hosts games but doesn't simulate them (but then we don't know the winner of the match unless trusting player consensus which might not be given). WFG hosting everything also means that this service being slow or down affects all matches. ((Still we want the dedicated server ability, but the main question is the feasibility and need for WFG to host rated matches. If there is any effective alternative, we should consider it.) Policy question effectively. Saneness of playing on scenario or random maps can also be questioned (survival of the fittest, demo maps)

I would also assume an alpha 22 mod being installed and enabled breaking alpha 23. You may want to rename your user.cfg in the path (-_-) mentioned if you already can't start the application, or just delete the mod.

The dedicated host feature itself should be possible because players want to host for each other anyhow. But which other overwhelming benefits do you see? It also has significant disadvantage for WFG to host games. For instance I see it as a benefit that WFG can't look into usergames, it should be players business if they decide to fight each other and I'm lucky that we can't moderate it unless it leaks into lobby chat. But if we host things, we have to host userchat too, need to change the policy. Second disadvantage is that it costs more effort to setup a custom lobby. In the worst case it costs lots of CPU power (i.e. actual money in some orders of magnitude, possibly even multiple computers) if we are forced to simulate the game too (and I think we might have to if we want to know the winner of the match). Also it prevents rated modded games unless we installed the mod on the host then. So I want the dedicated server feature anyhow (I wrote a half finished patch, one that added a chat hack to allow players to setup a game in 2015), But it would still be better to not have WFG have to have to host rated games, but I didn't see an alternative yet.