Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

New Capital for merged kingdoms #19

Closed
d-albrecht opened this issue Sep 10, 2022 · 3 comments
Closed

New Capital for merged kingdoms #19

d-albrecht opened this issue Sep 10, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@d-albrecht
Copy link

Hey,

first up: awesome game! I discovered it via f-droid at least a week ago and since then play it daily (and a lot), although I haven't yet stepped up to medium AI (I can beat easy at least half the time, but am not yet equipped enough to beat anything more clever). Still, I enjoy it really much and will probably post a bunch of ideas here.

This time I wanted to ask why merging several kingdoms behaves the way it does and whether changing this wouldn't be more predictable.

It took me some time to figure out experimentally what happens if two kingdoms get combined and reading into the code confirms my assumption. If a unit from kingdom A closes the gab to kingdom B, the capital in kingdom A gets removed. This seems pretty predictable on this scale. But a single unit can (while this will only happen really, really rarely) combine up to three kingdoms. In this case the capital that will "survive" will be of one of the two kingdoms that the unit didn't originate from. But which one will be chosen is pretty much random / dependent on an implementation detail (the order in which neighbor cells get provided by the helper class). For example, if the whole map was rotated 180° the "surviving" capital would probably be the other one.

To make this a bit more straight forward / predictable (where a capital gets moved to when your enemy captures some of your territories is already "random" enough, I'd say) my suggestion is to keep the capital of the kingdom that the unit originated from. That would also make sense from the game idea side of things, the "connecting" kingdom clearly was the dominant/active kingdom, while the "connected" one(s) haven't done much in this situation. That way the number of kingdoms that get connected at the same time would never change the exact way that the merge turns out.

This could (if I haven't missed something) be accomplished by just swapping the second and third argument in this line.

@Sesu8642
Copy link
Owner

Hi,
thanks for your feedback!
I know the difficulty is pretty steep at the moment. I will tweak that for the next release.

I think I copied this behavior from the original. But you are right. When three kingdoms are combined, it is pretty unpredictable for the player. Keeping the capital of the kingdom that does the conquering was also suggested in this comment. While I generally try to be faithful to the original game mechanics, I think a minor improvement like this does make sense to implement.

@Sesu8642
Copy link
Owner

@d-albrecht the line you identified was indeed correct. Done!
@bioderm implemented your suggestion here.

@d-albrecht
Copy link
Author

I must have overlooked the fact that this game was inspired by some existing game. Hence, I wasn't aware that there was a "right" way to handle some aspects of the game. But looking into the original rule set I found out that the "right" way to choose the capital is as flawed as your way was. It, too, can cause ambiguous situations. Whether you decide based on size, money, army strength, number of trees, etc, you can always run into situations where you would need a tie breaker. And then just using the tie breaker instead creates a way easier rule in the first place and makes it easier for new players to grasp the game. That was, why I asked if this idea would be a valid change. The easier the rule set is the easier it is to include such facts in the in-game tutorial such that new players don't have to test this out on their own but just can know it right from the get go.

@Sesu8642 Sesu8642 added the enhancement New feature or request label Sep 20, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants