-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Countable scopes approach decision #11527
Comments
Approach 3 is right out - how do we know to "link" those specific modifiers and not others? |
Approach 1 seems good, although I don't understand what we need the awkward [Number] part for |
Approach 4: If we decide to go there eventually, then keep this as small and simple as possible... If someone digs up a code template, CC0 or PD, to copy most of, could be done in a week. After all, parsers are common. Edit: 1 What's simplest of those approaches? To code and maintain? Maybe 2 - complexity concentrated in one place, namely parsing parameters left to right keeping track of last selected scope. Drop "Number" - any parameter whose scope is unambiguous isn't required to specify one, similar code complexity as requiring pairs throughout. Requires scope names to be uniquely different from any countable name though. Can use some of my experimental data model - a countable being an interface that can be implemented by an empowered Enum or by non-enum dispatchers like the Stat one. But the value getter would receive a Scope parameter from the upstream parser, and the interface should likely get a supportsScopes function for validation. All of that code could then be easily reused in UniqueParameterType.Formula. Footnotes
|
I suggest you to opt for the blend of 1 and 2 approach The aforementioned example "return true when there is more than 25 cities on the entire map" would be like this <when [Global Number of Cities] [] is greater than [25] []> These empty parameters would be places to insert a limiters of the specified filter <when [Global Number of Cities] [Enemy] is greater than [10] []> The second example would return true if there are more than 10 cities of hostile civilization. The general syntax would be like this: <when [countable] [optional limiter(s)] is greater than [countable] [optional limiter(s)]> What is your opinion? If you don't understand something or if you want additional examples, feel free to ask me. |
BTW, we should somehow attach buildingFilter to cityFilter, allowing to choose cities that have the specified building. Example: Returns true when there are more than 10 cities with University As you can see, there is an obvious problem with wording. Maybe we could inject some words when the buildingFilter is used as cityFilter? So, it would display like this: When Global Number of Cities with University building is greater than 10 I hope you understand. |
@yairm210 @SomeTroglodyte @RealBamboolord @woo1127 Please review my proposal |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
Before creating
Problem Description
A month ago, I've implemented the Countable comparison conditional uniques.
Currently, they only support numbers, year, stats and resources
I strongly believe we should overhaul that mechanic, in order to support a wide range of numeric game variables:
In that case, we need to know which scope do they apply to. For example, population can apply to one city, civilization or the entire map.
Same with number of cities. We need to know whether it applies to specified civilization(s), or the entire map.
To demonstrate this, I show you three approaches towards countable scopes, with examples.
All of these examples do the same - return true when there is more than 25 cities on the entire map
The examples are described in Desired Solution and Alternative Approaches
Related Issue Links
#11389
The original issue and the list of proposed countables
#11308
The pull request adding the countable uniques
Desired Solution
Approach 1 - Additional scope parameters
<when [Game-Wide] [Number of Cities] is greater than [Number] [25]>
Alternative Approaches
Approach 2 - Scope-specific names
<when [Number of All Cities] is greater than [25]>
Approach 3 - Countable limiters and modifiers
<when [Number of Cities] is greater than [25]> <@game-wide>
Additional Context
My thoughts:
Approach 1, in my opinion is the best. The drawback of 4 instead of 2 parameters is not really an issue.
Approach 2 requires making a huge amount of countable filter values (possibly even hundreds which is contradictory with modding philosophy)
Approach 3 makes it difficult to distinguish between countable limiter/modifier and the next conditional (all conditionals must be true to make an unique active). There is also a problem regarding the scope of the second countable.
If you want to opt for Solution 3, you will need to add some kind of countable limiter/modifier, denoted by different character (maybe @, pronounced as "at")
@yairm210 @SomeTroglodyte @RealBamboolord @woo1127
We need to decide between these three approaches. Maybe we should make a poll?
The text was updated successfully, but these errors were encountered: