sesu8642 / feudaltactics Goto Github PK

Woyld you be open to a PR that just tinkers with the UI a little tobpush some elements around?

Initially I'd like to do the following:

1. Add padding where the green arrows are
2. Try right aligning the text near the red arrows
3. Move the dice in line with the other elements (once oadded out, should be straightforward to tap)

If you are happy with these, I would also like to propose some other tweaks to the Scene2D skin:

4. Swap the Window and the Button skin. The window has a nice subtle beveled edge I usually associate with buttons, while the buttons have a quite-pronounced border I usually associate with windows.

5. Explore reducint the padding of menu items in portrait mode.

6. Explore capping the width in landscape

7. Explore improvements to the drop down widget:
8. Add paddint to tge left of the words so the highlight appears with padding.
9. Experiment with different 9 patches so the items behind don't show in the corners, and it may also help with the padding issue. Perhaps try the button or window skin, or reduce the size of the rounded corners.

I realise you don't likely want all of these, but may like some. Hence the itemisation. Feel free to say no to any or all of these. If you like the sound of it, I can propose small PRs for each so you can judge each on it's merits. I will also take into consideration what it looks like on desktoo when making any changes.

Let me know what you think. And thanks for the awesome game!

Could we get a more detailed income statistics? Like Slay apparently has. With additional/separate values for (a) income based on territories, (b) salary for units, (c) savings from last round.

On that note, could you change the income statistics to NOT having an effect when I pick up a unit? Say I have a kingdom of four tiles with a peasant and one tree. If I just select the kingdom, the income says "1", if I pick up the peasant the income says "3" which is quite confusing. Because this number is never correct and just keeping the "1" would in most cases closer to the actual truth. Especially in phases where I wait for money to accumulate, I often get a wrong impression of the number of turns this will take, when I happen to pick up the unit instead of just selecting the kingdom.

The game sometimes crashes when you try to skip the Ai's first move. After restarting the game i can continue with my first move. Unfortunately, I could not reproduce the error permanently. I'm using v1.1.2

Hi! First of all thanks for the awesome game and the readable code!

I noticed that sometimes it seems I have all my fields covered but then they get conquered by peasants anyways. First I thought it was just that I missed that gap in my defenses but now I caught the bug red-handed:

The blue dots indicate where my kingdom was connected. The dark blue dot was my capital (If I remember correctly). One of the light blue dots was part of the connection as well (don't remember which one).

The screenshot shows the state immediately when I got control for my turn again after the kingdom being separated.

Money of the lower part of the kingdom is 5, which is consistent with it's capital being destroyed after being separated from the upper kingdom by cutting the light blue dots. Money of the upper kingdom is 14, so it looks like the process was: 1. separation by conquering light blue, 2. destruction of lower kingdoms capital.

I think both tiles were covered by the (former) capital but even if I misremember from the Image it is clear that brown shouldn't have been able to conquer the dark blue tile, because either it was the capital or the capital was already where it is right now. In both cases it can't be conquered. I am 100% sure that the "new" capital is the one in the top kingdom next to the tree.

I had a look at the code already, but so far I couldn't find out whats wrong. Maybe something with getStrength() or getOffenseTileScoreInfo()?

I am running with ./gradlew desktop:run on commit 31f8dee in linux.

(Desktop) When you have someone selected, it seems like the "Esc" key is the natural one to de-select. However, clicking that takes you back to the main menu (pause action....incidentally pause is an odd concept for a turn based game).

Could it be updated so that if a selection is active, it de-selects that on the first press. Then another esc will take you back to the main menu.

(Android) Interestingly this already works with the back button in the android client. Though there isn't a general convention I'm aware of this person indicated that they also think esc should perform the equivalent of the back button.

Ahhh, but the back button in android doesn't go back to the main menu.

It's a suggestion I received via email. One potential issue is that there could be "loop" situations in which the game never ends. As long as the player can exit at any time, it shouldn't be problematic.
But what happens if showing the enemy turns is disabled in preferences? A loop situation in that case would lead to a crash. Maybe the preference could be overridden in that case.

Most of the time, screen rotation is disabled on my phone.
But this game still rotate.
Is it possible to stay in portrait mode if the phone is conhigured not to rotate ?

See #40.
It needs to be easy for users to get crash report information for reporting.

I just played the current development version (by the way, it would probably be best if you changed to version number to something other than a stable version, for example v1.0.1-dev, or v 1.0.1-alpha, etc). In this match brown lost all its units and they turned into gravestones. But before it was brown's turn again, the gravestones turned into trees. Don't recall the order of players exactly, I can post parts of the log tomorrow, but let's just say, after brown was my turn, then came pink, then white, then the gravestones transformed, then came green and yellow and then was brown again. Shouldn't that process wait until it's brown's turn again?

The buttons on the bottom (and presumably pause) have transparent backgrounds so on several occasions I have tried to click something close to them, but accidentally clicked the button.

It is nice to see what is behind them, but I think it would be better to make the clickable area opaque or at least a deeper translucent so that it is clear where will register as a click.

Here are some ideas for game mechanics that I had or received as feedback from others. Generally, I want to preserve the Slay mechanics as is in some way. New mechanics could be part of a separate mode or even a successor to the game.

• new unit: catapults that can destroy units from the distance
• trees being useful (e.g. by giving wood)
• destroying a capital gives money
• capitals get stronger when they have a certain amount of money
• limited movement range for units

When you rotate the screen while it displays a message, it causes the message to display/render badly. In this case, only part of the messagebox appears. (Tested with "you might have forgotten to do your moves for a kingdom" message. )

Give the user the ability to select how many teams they want to compete with....max at some number that keeps the colors sufficiently distinct.

Along with this, the ability to pick start order....user first, user random, user last. First is a distinct advantage.

Multiple people reported to me that the difficulty is rather high. The difficulty of a session depends on the intelligence of the bot players as well as the generated map. I think that the varying difficulty of the maps is a good thing. I have great fun beating maps that seem almost impossible at first. However, some generated maps are actually impossible on certain bot difficulties. I don't think that I can fix this. That said, if you play against easy bots, impossible maps should not occur regularly.
Another problem is that the medium difficulty bots are in practice not that much worse than the smart ones.
I would like to improve this by making the easy and medium difficulty bots a little dumber.

after ending my turn the game crashed with the following call stack (including a bit of context leading up to the crash):

[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] conquering tile 'Position: (-18.0,13.0) Color: 00ff00ff, Kingdom: de.sesu8642.feudaltactics.gamelogic.gamestate.Kingdom@70685436; savings: 12, Content: null' with stored unit 'BARON'
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] acquiring a new unit
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] conquering tile 'Position: (-19.0,14.0) Color: ffaaaaff, Kingdom: de.sesu8642.feudaltactics.gamelogic.gamestate.Kingdom@4b0a9690; savings: 0, Content: de.sesu8642.feudaltactics.gamelogic.gamestate.Capital' with stored unit 'SPEARMAN'
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] acquiring a new unit
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] selling previously bought castles again
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] picking up all available units
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] defending most important tiles
[de.sesu8642.feudaltactics.gamelogic.ingame.BotAi] protecting the kingdom with leftover units
YOUR TURN
Exception in thread "main" java.lang.NullPointerException
        at com.badlogic.gdx.scenes.scene2d.ui.Table.computeSize(Table.java:806)
        at com.badlogic.gdx.scenes.scene2d.ui.Table.layout(Table.java:953)
        at com.badlogic.gdx.scenes.scene2d.ui.WidgetGroup.validate(WidgetGroup.java:113)
        at com.badlogic.gdx.scenes.scene2d.ui.Table.draw(Table.java:108)
        at com.badlogic.gdx.scenes.scene2d.Group.drawChildren(Group.java:124)
        at com.badlogic.gdx.scenes.scene2d.Group.draw(Group.java:58)
        at com.badlogic.gdx.scenes.scene2d.ui.WidgetGroup.draw(WidgetGroup.java:170)
        at com.badlogic.gdx.scenes.scene2d.ui.Table.draw(Table.java:126)
        at com.badlogic.gdx.scenes.scene2d.Group.drawChildren(Group.java:111)
        at com.badlogic.gdx.scenes.scene2d.Group.draw(Group.java:58)
        at com.badlogic.gdx.scenes.scene2d.Stage.draw(Stage.java:129)
        at de.sesu8642.feudaltactics.ui.screens.IngameScreen.render(IngameScreen.java:411)
        at com.badlogic.gdx.Game.render(Game.java:48)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:387)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:192)
        at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:166)
        at de.sesu8642.feudaltactics.desktop.DesktopLauncher.main(DesktopLauncher.java:15)
<===========--> 87% EXECUTING [1h 42m 16s]

Autosafe worked, so no progress was lost.

I am running with ./gradlew desktop:run on commit 329d372 in linux. I don't have android SDK installed but I don't think this should be related. usually the game just fails to start first try and complains about the missing SDK and the second try works flawlessly.

From an email I received: "A guidebook for cool strategies, sorta like an outline of strategies like divide and conquer etc". Could be realized as an optional "advanced" tutorial. Or maybe even a video.

It would be nice to have an option to always show the current protection level of tiles (perhaps even of enemys), than it would not be necessary to click on a unit. And even, when clicking on a unit, the interface currrently does not take into account the protection, for the selected unit itself. I am also often confused, when I clicked on a unit, that then the tile is empty, and I forgot where exactly it stands - it would be better to let it stay there but give it 50% opacity (or something similar).

Another wish: store last X seeds in a list, so it would be possible to play again a previous map (especially when not won).

Btw: great game! Don't add too much new features (or at least make them optional), because it impresses by its simplicity (the learning curve is not too steep).

I played on hard, loose, large map and the game ended in a 'stalemate' because the highest level units would not engage witg each other. The other game allowed you to fight other 'barons' under certain conditions.

Here are some things that I would like to refactor at some point:

• the UI, especially the ingame screen hast too much logic which should go somewhere else, e.g. determining whether the winner changed during a bot turn
• texts should be in some resource file (translatable later)
• the complexity of some methods is way too high and they should be split up
• autosaving needs be more efficient and save less data (there are performance problems on huge maps)
• the event bus is a little overused which causes very (too) loose coupling at some places
  • the loose coupling makes sense between frontend and backend as well as internally in the UI
• there should be way more unit tests
• visibility of many classes and methods is too high
  • could be limited to package but I like to use packages for organizing the structure too much
  • maybe Java 9 modules could help but the project is stuck with 8 for now
• json serialization/deserialization using the libGDX API is tedious and relies on hardcoded package names
  • better use Jackson or Gson as GWT compatibility is no longer relevant

I just published a release candidate for 1.2.0.
Since I did some refactoring I would like some users to try the release and report potential bugs in this thread. If you read this and have some time, please help. Also make sure to report back if you tested it and didn't find any issues.

While in a game, there are the four main buttons on the bottom of the screen (undo, buy unit, buy castle, end turn). The problem I have with these buttons is that they span the whole lower section. When you move the map such that there are movable units on the same level as the buttons, you can't access them anymore unless you move the map once more. That in and of itself isn't problematic, but the issue I have with this situation is that it is either hard to recognize when this happens and you accidentally clicked one of the buttons or even devastating for your position in some situations. Hard to recognize, if you triggered either of the buy buttons or the undo, as the change on the map usually is rather minor and not directly apparent, devastating if you triggered the end turn button instead of picking up a unit.

To solve this, I would suggest to either make the buttons smaller such that their hit-boxes are only slightly larger than the icons themselves. Alternatively (or in addition), it would already be a huge improvement, if these buttons had a visible outline/hit-box. If I saw that below some line all area is assigned to some of the buttons, I would immediately know, not to try to select a unit that is shown below that line (the upper border of the four buttons).

If you don't shrink the buttons, you might as well consider making the (floating) buttons non-see-through. There already is the floating menu button that also hides some parts of the map and that's no problem either.

This graphical glitch sometimes happens. I suspect it is a rounding problem with the coordinates.

The S-M-L map sizes are good, but some larger options would be even better.

Another more general option would be to give the player the ability to pick the number of spaces they want to play with.

I'm definitely not new to the JVM but gradle poses some problems to me from time to time. So, I hope I'm not totally wrong with asking this question here.

When I was installing java (independent of this game), I was going for the most compatible JVM version and I decided to install version 17 (specifically openjdk version "17.0.4.1" at this point). But I ran into problems launching this game using the wiki guide. Because when I attempt to run the desktop:run command (or even launch gradle without any actions) I get the following error message:

Could not compile settings file '/home/alex/Documents/projects/FeudalTactics/settings.gradle'.
> startup failed:
  General error during semantic analysis: Unsupported class file major version 61

As I said, each time I'm confronted with gradle, I still have to get familiar with it again, so I did a bit of research and tried a few things to make it compile/run. But all failed:

• Specifying JDK 17 in several ways I found online resulted in the same message.
• Running the project with a newer installed gradle version caused incompatibilities (see next point, essentially the exact same message)
• Upgrading the wrapper with the installed version caused a "build.gradle not compatible with newer gradle versions" message
• Upgrading the wrapper using the wrapper action cause the "unsupported class file version" error again

I used a newer gradle version explicitly because the "unsupported class file version" message suggests that running older gradle projects with newer JVM versions will not work at all for some reason and the gradle docs (at least if interpreted in some way) seem to support that idea. Which to me seems odd, though: A more recent compiler/JVM should always be able to handle older class files / gradle configs, so I'm a bit lost here.

A few questions at this point because I don't want to mess around with my system too much in case you can already tell me this:

• Is there a reason for using an older (already deprecated) gradle version? This seems to be the main problem for me.
• Do you know what the gradle-JVM-compatibility is supposed to indicate? Because to me this should only mean that with gradle version xx you can't compile source files newer then java version yy, but (somewhat) independent from the compiler version used (usually this shouldn't mean that the compiler can't be more recent then version yy).
• Is it possible that java 8 is more or less the only exact version that can compile/run this project? If this is the case, you should make this explicit in the wiki. Because both version 8 and version 17 are LTS versions and the JVM is usually perfectly compatible with older sources.

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.

The ideal situation would be to give the player an option of where to place kingdom capitals in cases where new placements are necessary (the old capital being captured, the kingdom being split). But this would slow down the game significantly as each player potentially would have to be active in every enemy turn. But the way capitals get moved in the current version is definitely a disadvantage most of the time.

I don't have a clear suggestion on how to improve the situation, but I had a few thoughts that I wanted to share:

• if you capture a capital, the new capital is one of the neighboring tiles. That both has pros and cons. pro: the remaining tiles still have some limited protection. con: the same enemy could capture your new capital in the next turn, again leaving you with very little money. Hence, it might be a better idea to freely place a new capital somewhere not near the borders if possible. But as I said, this can leave you open as well, so I don't know if this could be an actual improvement.
• if you split a kingdom, the new capital of the newly formed kingdom is near the attack as well. For splitting, I would actually prefer for the new capital to be father from the attack position.
• Regardless of which tiles are candidates for the new capital, I would suggest a more strategic placement. Because the current placement seems pretty random.
  • One option would be to choose the least protected tile, or the tile that would offer the most amount of protection in the remaining (border) tiles
  • Another option would be to choose the most central tile. Imagine a four-tile kingdom in the shape of a diamond where the capital is one of the "central" tiles. If someone captures this capital and the new capital is placed on one of the outer tiles, this leaves one tile vulnerable. Placing the capital on the other central tile would still protect all remaining three (on a low level of course). Center placement and protection placement will work out similarly most of the time, but differently in others. Hence, I provided these two ideas.
• If you had a settings menu, each player might be able to specify which strategy the game should use in case a new capital has to be placed. Because every play strategy favors other capital placements. If I play quite castle-heavy, then moving any new capital to the inner tiles of my kingdom would save me from losing money every turn as no enemy will be able to rush for my castle. But if your strategy makes use of the capital as a point of protection this surely won't be ideal.

The apk generated in the CI builds is unsigned and cannot be installed easily. It would be good to sign it with test keys.

I played a match today and at some point, the game hard crashed. Reopening the game put me in the situation I was in before and could finish the (almost won) game.

This crash apparently was at the exact time where the "you have almost captured the world, want to end here?" message box would normally appear. Because I never got the message in this match before or after the crash.

The seed was: 1675510407298 (medium size and density) with AI level hard

And here's the screenshot of the point in time it crashed / how it looked after reopening:

@cyberbeat gave some input about this in #49.

There should be a list about the previously played games containing the parameters (seed, map size, difficulty etc.) including whether the game was won or not and possibly in how many turns.
Icing on the cake: share the parameters with others somehow so they can try to beat you.

In cases where i can see I wont be able to sustain the whole army tbe next turn, it should be a valid tactic to decrese army size in advance as to not forfiet the entire army.

This will allow "rush" tactics that eat the money reserves for a direct attack, for example to target an enemy castle, and then cut down the army size before it implodes.

Another use for this mechanic is to decrese army size in order to facilitate a baron. When I know I need a baron i currently need to avoid making speerman, as they block me financialy from making the baron. killing the speerman when the time comes will allow me to make the baron when needed without secrificing my military power before hand. This at the cost of killing the spearman.

This last mechanic should be considered in opossition to the possibility of combining spearman to create a baron, in which case the cost of the spearmen will not be waisted.

From time to time it happens that there are no other kingdoms left on the map beside my own, but the game doesn't notify me that "all enemies have gave up". This happens only very rarely because usually the enemies give up before I can even destroy all other kingdoms. I would classify that as a bug.

But to me that is an indicator of a more general problem. I think the game should handle the case differently, if you actually managed to destroy all kingdoms and effectively tell you that you "conquered the whole island". Because while you technically might not have yet, no-one will be able to prevent this realistically.

And, if you ever add a general settings menu to the game, you might want to add an option to turn off the "all enemies gave up" message all together. Because if the idea of the game is to conquer the whole island some might actually enjoy to be able to do that without being interrupted.

An option that could have an interesting impact on game play would be to provide a configurable minimum kingdom size for the initialization.

I.e. if the min size is set to two, when the game starts there won't be any non-kingdom tiles available....that wouldn't be very fun as there would probably be a lot of stalemates for the first few rounds. More interesting when it is set bigger...e.g. 10, then there are a bunch of ready to fight kingdoms right away.

I have no idea how to build a generator that could do this. I think it would have to be a multi-stage operation.

Suggestion I received via email: show how often the player won and lost. Some metrics I can imagine:

• number of maps generated
• number of maps started
• number of games won and lost (as mentioned, possibly per difficulty)
• number of games exited before winning or losing (possibly per difficulty)
• seed played the most

Would it be possible to have a global game settings menu where I can choose my color out of the active color scheme? I'm not a fan of always playing blue.

Furthermore, have you made sure that the color scheme is appropriate when it comes to users with any colorblindness / visual impairment? I don't suffer any of these issues, but I know that it is really easy to fall into this trap and choose colors that some might not be able to distinguish (and being called out for that). In case you're unsure, use the above settings menu to offer a range of color schemes to choose from so everyone will find some working scheme.

Love the game! Even though I'm not very good at it 😄

The savings text is white, with no outline or background. That makes it hard to read when it is over tiles which are white or yellow.

Could I suggest some or all of the following:

• Larger font
• Solid background
• Stronger outlining

This is similar to #2

In the current state where all you can do is play against AI, this isn't really an issue as even the smartest AI has flaws, but given that we might see a PvP mode at some point, and because even the AI can screw you up some times, I wanted to point out a problem with the game and suggest some ideas of how to improve the situation.

I want to say upfront that I don't know the details of Slay by heart, hence, I won't make any statements of whether something (both the situation we have today or my suggestions) is true to the original game. Still, I believe that we shouldn't stick with bad behavior, just because Slay at some point in time decided that this was the way to go.

Because even the smallest kingdoms should be able to act in the first round, you start with five money per tile. That was a smart decision (by Slay). But as soon as we consider trees, this situation becomes illogical. Because in the first turn (at least for this game) the game doesn't subtract money for tiles with trees. So, a two tile kingdom with a tree can still act in the first turn. While I understand the idea here to not further penalize kingdoms with trees (given that it wasn't your fault that there was a tree), this edge case somewhat breaks the principle behind blocked tiles.

The bigger problem is your initial money if another player captured tiles of your kingdom before you played the first time. If an opponent captures some "border-tile" (aka tiles that not connect parts of your kingdom), you start with one less money. If an opponent cuts off larger portions, you start off with that amount of money less. UNLESS of course, some of the cut off tiles had trees on them, then you don't lose money for cut off tiles with trees. Personally I think that this is even more wrong than both situations on their own.

If some opponent destroys your capital, you start with money equivalent to the number of tiles at the start of your turn. The same happens if a cut off portion forms a new kingdom. So, simply by having your capital being destroyed, you lose out on the majority of your initial money and in almost all cases have no way to actually play in the first turns (not just the very first turn).

See these two images of the same level being shown as it was displayed on the level selection screen and when I was able to play for the first time:

The kingdom in the middle part starts with 25 money because a tree tile was captured. The kingdom in the left has 10 money (despite the tree). The former 4-tile-kingdom in the bottom part starts with 18 money. This level doesn't have any examples of kingdoms with destroyed capitals, but I'm confident that my description of these situations were accurate as well.

Here are my suggestions:

• This would only solve the lesser issue, but we could exclude trees from the initial game generation. Trees then would only appear from gravestones, capitals, or neighboring trees.
• As the first suggestion would more or less remove a huge chunk of the trees that will be visible in a game, we could do that but bring back that some trees appear randomly.
• Generate some units similarly to how trees are randomly generated. That would limit the chance of opponents capturing your tiles in the first place. And then subtract the costs from your initial money balance.
• Alternatively you could let the players play a set-up round. In this round you can spend money on castles and units but the only valid placements are the tiles of your own kingdom. So, in the blue five-tile kingdom in the middle, I could have placed a peasant next to the tree, to protect every tile, or cut the tree. But I couldn't connect the single blue tile south-east of the kingdom, as I wasn't allowed to capture the yellow or green tiles in between. Only starting with the second round all players are allowed to play offensively and capture any new tiles.

I'm not sure if that were all the ideas I had or if I forgot some, but I think that covers a lot of my ideas.

The thing is that I understand that the player order is related to the kingdom sizes of all players to counteract the unbalanced random creation, but if some opponent manages to destroy your capital, this puts you in a really bad position that this kingdom rarely is able to recover from.

No matter how you play the game, it is highly likely that at some point you will have exactly one kingdom. Whether this is by combining all kingdoms or getting some destroyed by others. Would it be possible to automatically select this single remaining kingdom as soon as it is my turn, such that I can immediately click on "buy unit" or "buy castle"?

It is possible that you "get back" to having several kingdoms afterwards, and hence, the automation has to check each round/turn if it should trigger. But I see no obvious reason to have the player do an additional yet unnecessary mouse click / display touch. And if you want to select the kingdom manually, nothing will stop you from doing so, it will just have no real effect to select the only remaining and already selected kingdom.

https://monitor.f-droid.org/builds/log/de.sesu8642.feudaltactics/2#site-footer

This is a known issue of AGP 4.1, could you please upgrade it to 4.2 or above? Thanks!

Good suggestion i received via email. The suggestion was to make it copyable on click/tap. It should be somehow visible to the user, maybe there can be a copy button next to the random button. In the ingame menu where the seed is displayed, clicking the label could copy it.
It would be even more comfortable to have the ability to save some seeds as favorites. Could be an option in the message when the game ends.

The readability of texts like in the tutorial is pretty bad. The font comes from the skin. Could be solved by using a custom skin. Maybe there are other solutions.

I have read that you like to challenge yourself with almost impossible looking games, but I would prefer if the game would generate more fair start points. I know that I have the option to regenerate the map, but to me it would appeal more if a higher percentage of the generated games would immediately match my taste of difficulty. For example, it isn't uncommon that I only get one kingdom with only two tiles and all other tiles of my color are spread out across the map (on small maps). Usually with another player nearby that has a kingdom of four tiles or more. This other player could in theory eliminate me before I even get a chance of playing.

And I know that fairness is hard to define. But one metric could be number of territories in some kingdoms. So, in the example above, only two of my tiles would count as "in kingdom" while the others are effectively dead. Another metric could be "size of largest kingdom". All of these metrics could have some margin (either absolute or percentage based) as it will not be possible to generate only fair games if the fairness criteria are too narrow.

If we got a general settings menu, this could either be a simple on/off-switch or a slider denoting the acceptable margin. I read that you don't want to add too many new options to the game selector screen and that's a reasonable stance, so - also given my other ideas - a general game settings menu would really help with this and other ideas to let the player set parameters that would apply to any generated game.

In the current version of this game the only option to place newly bought units is to place a peasant onto an own kingdom tile. But there are cases in which I have 20 or more money but no free kingdom tiles to combine the unit to a spearman (imagine a two-tile kingdom with a capital and a castle). Or the only tile to combine them would be any that ended this unit's turn (a tree for example). But if I were able to create spearmen, I would be able to conquer something. Based on what I have read of the AI code, I'm pretty sure that the bots could do that. So, human players are in a bit of a disadvantage here. Based on videos of Slay I watched so far, this game offered this option as well.

I saw/experienced that you changed/capped the initial amount of money of the kingdoms. I have a few questions about and problems with the new state.

1. Question: Does the reduced amount of money play a role in the player order? Because while larger kingdoms still mean higher income overall, the new capped amount can mean that a player with a single very large kingdom can come last, but several other players might have more money (summed over all kingdoms) and can quickly/easily sabotage the large-kingdom-player. So, either the ordering is according to kingdom size or money. Both wouldn't be ideal. But as - after the first round - player ordering doesn't make much of a difference, I think that the initial money should primarily be responsible for the first round (and therefore overall) player ordering.
2. Problem: When some other player moves first and can take some tiles from you, this reduces the initial amount of money. The problem I have with this situation is that if some other player cuts off some tiles and you still have at least four tiles, then you start off with less then 20 money. I feel like the "capping to 20" and the "reduced money at the start" negatively synergize to further penalize the players that move last.
3. Question: What made you choose 20 in particular? The capping was done to stop some players taking over too many already owned tiles, right? Then why exactly 20? That still means that the early players can capture owned tiles. To make players act more defensively, I probably would have chosen 15 (assuming some absolute cap). That means all players with at least three tiles can still buy a castle, but can't capture foreign territory.
4. Problem (sort of): I feel like the capping to 20 is rather arbitrary. And I'm not sure if this is the right way. I think it could be more appropriate to apply some function to the number of tiles, that still give you more money for more tiles, but the additional money decreased with more tiles. 2 => 10, 3 => 15 (so that you are still able to buy a castle first turn), 4 => 19 (only +4), 5 => 22 (+3), ..., to the point that starting from some tile-amount you only get 1 money more per additional tile. Or something similar. As +5, +4, +3, +2, +1, +1 would get really small very quick, you could also use +5, +4, +4, +3, +3, +3, +2, +2, +2, +2, +1, ... Or something in between.

It would be helpful if you could see a count of the number of productive tiles in an enemy kingdom just by selecting that kingdom. The information is already available to the player, but they have to count the tiles manually, which is not much fun. Knowing whether the enemy has enough tiles to support their current army is strategically useful. I suggest this information be shown after selecting an enemy kingdom, where it currently shows your selected kingdom's savings and income. E.g. instead of "Savings 10 (+2)" something like "Enemy Income 19".

If you play a game to the end (continue when the enemy gives up), and start another game, the game crashes just before your first turn.
I had hoped it was fixed with a7b10fc, as the symptoms are quite similar, but the problem is still in version 1.1.4.

The hud buttons look completely different from the ones in the menu. It would be cleaner to have the buttons be part of the skin.
A custom skin could also solve #2.

What if you could see the order of the players somewhere on the screen?

The bottom is already taken and the top is quite crowded as well, so I'd suggest to have a bar at either side that indicates (a) who had the first turn, (b) whose turn it currently is, and (c) who will come next

The top position would always be the player with the first turn. Then all the other players in order. This should be visible on the map selection screen already, so that you know who would act before you even got to play. The current player could be indicated by an arrow, or a border around the color or something else. If one player is no longer participating, you could either remove the color from the bar, or cross it out, or whatever.

You could even use this to indicate the state of the game. You know how Slay has bar charts to indicate the number of tiles each color has? You could also include that into the side bar as well, in terms of sprites. If there is a gravestone on your color, that means you are out. if there is a tree on your color, then you have a very weak position, if you have a peasant, you have some tiles, if you have a baron on your color, you have (almost) wiped out everyone else.

That's a quick draft of what I imagine (without the sprites):

When using the desktop version installed via flatpak, it seems that preferences are not kept when I close and reopen.

I'm using

Feudal Tactics                                     de.sesu8642.feudaltactics                                           1.1.5                 stable                   system

on Ubuntu 22.04.2 LTS

I change show enemy turns to false, but next time it is true again. also it doesn't remember cpu difficulty, map size and map density.

In both portrait and landscape mode, Android's on-screen keyboard completely covers the little text box where you can type a seed in, making it very annoying to try to input any custom seed. It's still possible to input the seed, you just can't check to make sure you're doing it right without hiding the keyboard over and over again.

Ideally, the seed input box should be able to raise itself over the virtual keyboard to remain visible as you type. Or it could just be at the top of the screen in general, but I can understand not wanting to separate the pre-game settings like that.

For Android 13 apps can provide a monochrome launcher icon that can be used by launchers: https://developer.android.com/develop/ui/views/launch/icon_design_adaptive