Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Eddie Anderson wrote: That part was OK. I thought that I could fix that problem by moving one of my units onto that tile (to enforce my claim to it). That works in commercial civ. It's the natural expectation. This unhappiness function could be called envy. Envy would cause a city near a superior civ to suffer additional unhappiness based on its PF distance to a superior civ. Nice idea. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 On Friday 09 November 2007 12:47 am, Jason Dorje Short wrote: I have to agree with per that changing the borders system is an unfortunately tricky problem. Having consistent/realistic/logical/fair behavior in all cases may not really even be possible - I know that civ3 and smac had just as many if not more border goofs than our current system. If this is a step toward making freeciv more civ3-ish, I'd like to request that a means be kept to continue to have civ1 and civ2 like play. Randy Kramer ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Jason Dorje Short wrote: A triple-loop is also rather tedious (possibly too slow with a very large number of old cities in the game). A simpler loop is possible if we make border assignment context-based and impose the restraint that borders can expand only one tile per turn. Four (4) passes over the number of tiles, instead of one (1) pass over the cities? That's tedious? This is some new use of the word tedious. What I found tedious was trying to read 900+ -owner uses (in two branches simultaneously) to find the ones that were assignments instead of references In the computing point of view, by definition the number of cities is always less than the number of tiles, by orders of magnitude. The context-based borders are not simpler in any computational sense, because the execution is data dependent and therefore harder to debug! iterate all tiles iterate adjacent tiles look at the owner source mark tile for reassignment based on the highest factor iterate all tiles assign/reassign tile as marked Wow, that's both slow *and* data intensive (another temporary variable per tile per player). But not as bad as the current code doing the adjacent tile search twice! The hard question is what to do to a unit/fortress/city when the tile under it gets reassigned. This part will end up being more coding (though less argument) than the borders changes themselves. No new code necessary. A unit reassigned converts to the new owner, attacks, or leaves. An occupied fortress cannot be reassigned. An unoccupied fortress has no border/vision of its own. A city cannot be reassigned. It *should* be able to be converted, by proximity to a superior civilization, at which time it self-reassigns. As a side note, I do think context-dependent borders are more stable than context-independent ones. For instance with the above algorithm if the factor (culture) formula was changed when you loaded an old game you would find that borders changed to match the new formula, but did so over several turns. The context save first occurred in 2.1.0 two weeks ago, so there's not much in the way of old games that change over several turns. Any other savegame has to start from scratch. Vision in fits and starts with little carved out discontiguous blocks (see the picture) just isn't workable (and is annoying in practice). And I actively dislike the idea that buggy savegames won't be fixed until some gradual and unpredictable evolution That's what I'm trying to redesign. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Randy Kramer wrote: If this is a step toward making freeciv more civ3-ish, I'd like to request that a means be kept to continue to have civ1 and civ2 like play. That's part of the idea. The current code is not parameterized. (Per preferred one-size fits all -- long wanted the game to leave its origins as a clone, emulator, and multiplayer hack of the commercial games it drew its inspiration from, and instead streamline the rules and interface to make it one, good single-player game.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 On 11/9/07, William Allen Simpson [EMAIL PROTECTED] wrote: I also examined the 467+ -owner [and 10 tile_get_owner] references in 70 files. [Why, oh why, do folks not use the accessor functions?] And fixed them! Not using accessor functions is not a bug, it is a feature. I would rather get rid of the pointless accessors than make them mandatory. But why are we discussion that in this thread? with deterministic borders, the algorithm can be run on loading games, and not be dependent on saving large tables. The size of the tile owner table in the savegame is not a problem. Another important constraint is that the border code should never take a tile from one player and give it to another. Once a tile is taken, it is *not* reassigned automatically by the borders code. Of course, this is one of the things I've already said I disagreed. One of the excellent features of civ3 (for those of us who think this is more than a shoot-em-up) is the cultural expansion of temple, library, etc. Peaceful conversion! So the reason you want to change the current borders rules is because you want to turn this game into civ3? I think that is a really bad idea. ... You can also never take ownership of land underneath the feet of non-allied units. Seems reasonable. A novel way of preventing border expansion, until the units move Saw that in the code. This is of course not compatible with civ3-like cultural borders. This removes a lot of complications that tie in with the diplomacy and unit rules. For example, what happens if you are in a peace treaty, and suddenly the borders shift underneath your carefully built defensive line of units? That's a feature! In civ3, you are sent a message, and allowed a turn to move without an implied declaration of war. Then you run into another constraint that the new borders/diplomacy code is based on: Never assume that the user reads messages. The way that messages are implemented in Freeciv, and perhaps must be implemented in order to have a semblance of real-time multiplayer, you cannot make such an assumption, because you cannot throw a modal click-me-to-remove dialog at the player with the message. I think that in order to do what you want to accomplish with the borders code, you also need to change how diplomacy works, and how messaging works. If you intend to make carbon copies from civ3 in these areas too, I think you will be removing most of what is original about Freeciv's rules. And I think that would be really sad. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 On Friday 09 November 2007 07:44 am, William Allen Simpson wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Randy Kramer wrote: If this is a step toward making freeciv more civ3-ish, I'd like to request that a means be kept to continue to have civ1 and civ2 like play. That's part of the idea. Good--thanks! Randy Kramer ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 On Thu, 8 Nov 2007 William Allen Simpson wrote: Egor Vyscrebentsov wrote: Does this mean that there will never be other source than city? (I can't see place for fortresses in this algorithm.) Even in the current code, the test for cities and fortresses et alia is in the same place. To me the main difference (in results) of your algorithm is that it doesn't fill all tiles (all border sources, if be more accurate.) Current code doesn't require city to be the source of border in tile where the fortress stays. Maybe there can be other iterator than city, say border_sources_iterator. (where border_source is union, for example.) [I understand that this has its own contras.] Can influence function be scriptable? Probably. But since that would slow it down to a crawl, I'm not sure anybody would desire it. I know that I want too much :) But what I really want is that the code will support idea that this function _may_ become scriptable _someday_ and will not require massive rewriting when/if this day will come. -- Thanks, evyscr ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 William Allen Simpson wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Jason Dorje Short wrote: A triple-loop is also rather tedious (possibly too slow with a very large number of old cities in the game). A simpler loop is possible if we make border assignment context-based and impose the restraint that borders can expand only one tile per turn. Four (4) passes over the number of tiles, instead of one (1) pass over the cities? That's tedious? This is some new use of the word tedious. What I found tedious was trying to read 900+ -owner uses (in two branches simultaneously) to find the ones that were assignments instead of references In the computing point of view, by definition the number of cities is always less than the number of tiles, by orders of magnitude. Perhaps. But consider the worst case, where there are a large number of high-culture that are spaced closely together (is there a limit to how far city influence can extend?). In this case you could end up iterating over every tile many, many times. And this case, rare as it is, is exactly the one that we should be concerned about since maps with no cities have no problem with computation time anyway. Oh and by tedious I meant for the CPU, not the coder. Bad choice of word perhaps. The context-based borders are not simpler in any computational sense, because the execution is data dependent and therefore harder to debug! Ya. The hard question is what to do to a unit/fortress/city when the tile under it gets reassigned. This part will end up being more coding (though less argument) than the borders changes themselves. No new code necessary. A unit reassigned converts to the new owner, attacks, or leaves. So you give the unit one turn to attack or leave or it gets converted on the following turn? What if it is entirely surrounded by the newly-claimed non-allied tiles and cannot get away in time? Is that going to be a common scenario? An occupied fortress cannot be reassigned. An unoccupied fortress has no border/vision of its own. A city cannot be reassigned. It *should* be able to be converted, by proximity to a superior civilization, at which time it self-reassigns. Can a fortress be converted? Vision in fits and starts with little carved out discontiguous blocks (see the picture) just isn't workable (and is annoying in practice). Somehow I missed seeing the picture. But if you're talking about granting vision to everything within borders, it follows that you want contiguous borders, yes. How will your system deal with ocean? Is that just included in the factor() function that assigns tile influence based on the city's culture? And I actively dislike the idea that buggy savegames won't be fixed until some gradual and unpredictable evolution That's what I'm trying to redesign. Okay. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Egor Vyscrebentsov wrote: Maybe there can be other iterator than city, say border_sources_iterator. (where border_source is union, for example.) [I understand that this has its own contras.] I've not been sufficiently clear. The code that I already checked in has cities (positive identity), fortresses, airports, etc. (negative identity). Same stub structure (vision_base). Probably same iterator! I know that I want too much :) But what I really want is that the code will support idea that this function _may_ become scriptable _someday_ and will not require massive rewriting when/if this day will come. Sure. Good design criteria. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 William Allen Simpson wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Randy Kramer wrote: If this is a step toward making freeciv more civ3-ish, I'd like to request that a means be kept to continue to have civ1 and civ2 like play. That's part of the idea. The current code is not parameterized. (Per preferred one-size fits all -- long wanted the game to leave its origins as a clone, emulator, and multiplayer hack of the commercial games it drew its inspiration from, and instead streamline the rules and interface to make it one, good single-player game.) Some sort of balance is needed that gives decent rule flexibility without the huge proliferation of options that is overwhelming for users and never get tested enough for coders to keep them current. For borders you don't have to worry though: the option of just turning off borders should always be present and is what civ1/civ2 do. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 On 11/8/07, William Allen Simpson [EMAIL PROTECTED] wrote: One of the difficulties encountered trying to add vision to borders: the current algorithm for borders is non-deterministic and context based, relying on a history (the previous turn iteration). Instead, I propose a deterministic algorithm, based on static data such as city turn_founded and a (configurable) multiplier. Any larger change to the borders code will have large repercussions on other parts of the code, especially diplomacy and movement. There is a lot of thought and debate behind the current design, and not all of the constraints that shaped it may be immediately obvious. I would suggest that before you change it, at least post the design you have come up with here for discussion. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Per I. Mathisen wrote: I would suggest that you hunt down some of the old discussions and read them before embarking on this. There are lots of constraints involved here, and I may not remember them all. Thank you, as part of my research, I looked at all 300+ list messages over the past 2 years (since I joined) with the word border in them. Such as PR#13718, PR#14548, PR#14589, PR#14982, PR#15169, PR#17163, and others that carried over I also examined the 467+ -owner [and 10 tile_get_owner] references in 70 files. [Why, oh why, do folks not use the accessor functions?] And fixed them! The single most important reason why I rewrote the original borders code and made the current one was so that it would run only on turn end, instead of during the turn as did the previous code. This removes a ton of complications, and I would strongly suggest that you do not change this design parameter. Wasn't planning on it, but with deterministic borders, the algorithm can be run on loading games, and not be dependent on saving large tables. Another important constraint is that the border code should never take a tile from one player and give it to another. Once a tile is taken, it is *not* reassigned automatically by the borders code. Of course, this is one of the things I've already said I disagreed. One of the excellent features of civ3 (for those of us who think this is more than a shoot-em-up) is the cultural expansion of temple, library, etc. Peaceful conversion! And of course, civ4 rather celebrated the use of the culture bomb (using special leaders). ... You can also never take ownership of land underneath the feet of non-allied units. Seems reasonable. A novel way of preventing border expansion, until the units move Saw that in the code. This removes a lot of complications that tie in with the diplomacy and unit rules. For example, what happens if you are in a peace treaty, and suddenly the borders shift underneath your carefully built defensive line of units? That's a feature! In civ3, you are sent a message, and allowed a turn to move without an implied declaration of war. I suggest you change these rules only with great care and careful consideration. Sure. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39845) RFE: deterministic borders and vision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 William Allen Simpson wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 Per I. Mathisen wrote: I would suggest that before you change it, at least post the design you have come up with here for discussion. I have to agree with per that changing the borders system is an unfortunately tricky problem. Having consistent/realistic/logical/fair behavior in all cases may not really even be possible - I know that civ3 and smac had just as many if not more border goofs than our current system. Specifically, one of your complaints is that the current system is context-based. But the reason for this is that having tiles change hands between peaceful nations is majorly problematic when peace treaties are designed to prevent invasions. Having cities or fortresses change hands based on cultural influence (or whatever you call the engine behind border generation) is militarily or socially imbalancing. In general I don't see a problem with context-based borders - if nothing else it makes backward-compatibility easier when border algorithms are changed since the old border setup will always be factored in when things change. That said, the current border system is certainly not perfect itself (as I said a perfect system is likely impossible.) That's what this RFE thread is for In pseudo-code: iterate players iterate cities set cultural influence (probably game.turn - turn_built) iterate circle determine distance factors if factor(this) factor(existing-source) replace owner and source You have to be careful that the order of player iteration doesn't matter. If set cultural influence is an actual step that must be done for all players before any reassigning is done. Also in turn-based mode it should be done separately for each player during (at the start of?) their turn. A triple-loop is also rather tedious (possibly too slow with a very large number of old cities in the game). A simpler loop is possible if we make border assignment context-based and impose the restraint that borders can expand only one tile per turn. iterate all tiles iterate adjacent tiles look at the owner source mark tile for reassignment based on the highest factor iterate all tiles assign/reassign tile as marked The hard question is what to do to a unit/fortress/city when the tile under it gets reassigned. This part will end up being more coding (though less argument) than the borders changes themselves. As a side note, I do think context-dependent borders are more stable than context-independent ones. For instance with the above algorithm if the factor (culture) formula was changed when you loaded an old game you would find that borders changed to match the new formula, but did so over several turns. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
