Mock-up for a non-interactive combat system for FreeOrion

Megalomaniak more helpful if you could provide the error in english.

How ?
Godot gives it to me in French...

braindeadbzh
Is there a non-microsoft repository where to open this issue ?

Megalomaniak

Oh, OK.
"Impossible to charge extension's script from path : « res://addons/cardengine/card_engine.gd ».
This may be due to a programming error in the script.
The extension « res://addons/cardengine/plugin.cfg » has been disactivated to prevent further errors".

No relevant scene is built since I get this error whether I try to activate the plugin in an already existing scene or on a completely brand-new one.

This from 3.3 to 3.5.0.

Megalomaniak Microsoft doesn't own the contents of the repo tho, they only acquired the service provider. It's one thing if you don't want to host any of your code there but reporting issues to the relevant repo shouldn't really be an issue realistica

Well, this requires an account in the devil's book, doesn't it ?
I do have one from before they were acquired (though they weren't free software at that time either) so I probably can soil my soul the way you recommend it, yes.

Done : https://github.com/BraindeadBZH/godot_card_engine/issues/20

Saint Ignucius have mercy on my poor soul !

Apparently the plugin works and I just don't understand how to use it.
Problem is, I still don't understand.
"this repo is supposed to be used as a template" : how to do that ?

braindeadbzh Past the whole repo content into your project

Well, I chose CardEngine over CardGameFramework specifically to prevent having to do that (it makes the learning curve way steeper)... but I guess what has to be done has to be done.

braindeadbzh Add the Autoloads

There were four autoloads automatically activated. I guess that I should keep them that way ?

Now I'm a bit at a loss : if I "do not overwrite existing files" how do I start my game rather than the demo ?

braindeadbzh the idea being to create your project from the demo

How to do that then ?

I tried (in Godot 3.5) db0's Card Game Framework since it has a "quickstart" documentation (on the EEE site alas) and I vaguely understand what it's telling me to do, but I'm stuck at the 2.1.6 step : I'm told to load my new inherited thingies under "Script variables" in the inspector but there is no "Script variables" in the inspector ?
How am I to make it appear ? I'm seeing the inspector of the new inherited main scene, am I doing this wrong ?

I'm surprised to not have written it anywhere I can find it, but what blocked me two years ago and up to now is not only that I didn't understand at all how to use one of the Card frameworks, but also that when designing the checkerboard I wasn't able to find the lift.

I have no idea how to make the screen responsive and for a mock-up I won't care to try, so I just put the tiles at the size they seem to fit best in my eyes.
But that means that there are too many tiles to fit on my screen, so I need a vertical and horizontal lift to navigate the full checkerboard, and I was completely unable to find how to do that.

I get that I could just move the camera with clamp and use arrows to do that (since I don't have another use for arrows in my combat system) but a lift makes way more intuitive to the user where what he sees on-screen is relatively to the full checkerboard.
I'm surprised to not be able to find how to get a lift, then.

To explain more clearly what I want to do :

### Goal :
I want to build a non-interactive combat system for FreeOrion, the 4X game inspired by Master of Orion.

The current combat system is minimal (ships fire at each other in four rounds, after each round ships that had damage superior to their hit points are destroyed).

It was planned to have a 3D combat mode to replace it, but then the dev team understood that it would pose a big problem in multiplayer, since it would force players not engaged in combat to wait for the players engaged in combat to have resolved their combat before a new turn could proceed.

So any interactive combat mode is now excluded from the game by the core design principles.

To make the combat interesting while non-interactive, my idea is to put the interactions before combat.

To get that I want to use a formation system :

• each player designs a certain number of formations (well, to be precise, formations and combat doctrines)
• each fleet chooses a formation before combat
• once combat occurs, the ship positions corresponding to the formation and the orders corresponding to the combat doctrine are executed and resolved
• after combat and end of the turn, players can look at what happened during the combat

### Implementation

I believe that formation/combat doctrine and combat log should be done on the same board.

UI
This board should be a checkerboard of (by default, but parametrable) 9 columns and 9 rows.
One player having the top 3 rows to place their ships and the other one having the bottom 3 rows (the three middle rows being no alien's land).

These rows and columns will be grouped by three ("top", "middle" and "lower" rows, and "left", "center" and "right" columns).

On the design screen :

Tokens corresponding to ships categories (not the ships themselves, since the formation is generic, not for a specific fleet) are put by the player (singular : each player designs their own formation and combat doctrine) as they wish on the three rows that are theirs.

Cards corresponding to the orders that it's possible to give (the combat doctrine) will be in a stack, I guess on the left of the screen.
Note that these cards are to be selected, not drawn (that is, the player can choose which cards he wants to play).
Also cards are not "spent" when used : if you give the "fire" order to a row, you still have the fire order available to give to other rows, columns or whatever¹.

These cards are put, each turn, either on squares of the checkerboard, on rows, columns, big rows ("top", "middle", "bottom" as per above), big columns, on the "big squares" produced by big rows and big columns (e.g., "top left" or "middle right" etc.), and special out-of-the checkerboard groupings (Species I guess, and Task Forces).

Cards are put round per round, but since they are not executed, they stay on the screen.

Nothing happens during the design phase, players just put the ships and cards.

Resolving combat :

Combat resolution will be entirely off-screen in FreeOrion as it is done server-side at the end of the turn (the global game turn, not the combat turn).
Players will only get combat logs.
These combat logs should be rendered using the same panel UI I guess.
So the mock-up will do combat resolution and combat log rendering simultaneously.

** On the Combat log screen** :

The board is the same than the design screen's one, save for the card stack (the cards used for the combat doctrine are shown on the checkerboard and the out-of-the-checkerboard groupings, but the card stack of unused cards isn't).

Ships are put on the checkerboard according to each player's formation (one player top, the other one bottom).
Planets in the system are also put on the checkerboard.

For each round there is a precise schedule of what order is executed first (movement before fire, for example).
Following this schedule step by step, all orders of the same priority are executed (in no particular order; there should be no race condition).
The orders executed are shown, and the corresponding cards removed from the board.
Results of these orders are also shown (ships destroyed, for example).

This for the four (by default) rounds.
I guess this should be done in two modes : a general animation showing the whole process, and another mode where the player clicks on a button to advance each step to the next one.

I think that's it ?

¹ Writing this makes me realize that maybe it would be more interesting to have the cards actually be spent when used; not sure about the whole consequences though, I'd have to think more about it. So for a start we'll have the cards not spent.

About how to transform this idea into Godot code :

• For the checkerboard :

I plan to use the same principle than the tutorial "Make a Strategy Game in Godot" referred above : each square being an Area2D ("tile", with a tile sprite).
So, 81 tiles, named "1R1C", "1R2C" for "first row first column, first row second column", etc.
Up to 9R9C, obviously.
I plan to do their grouping strictly in logic (that is, no "row" nor "column" node, but a two-dimensional array variable that holds the references for each tile)), but if I'm wrong and a "row" node would be a better design, feel free to advise.

These tiles being not completely adjacent (for esthetic reason) but with a small gap between them.
And over a starry background.
The tiles probably will be semi-transparent (also for esthetic).

I guess the logic should be done in the "main" scene ?

Actually I'm not sure whether I should use one main scene for both the design screen and the combat log screen, or do separate "sub-main scenes" for both and have one uber-main scene to call the "design screen scene" and the "combat log screen scene" .
If it's the second option, I don't really know how to do it, actually.

• For the right area :

The right area (I wrote left area in the previous message but I guess that right is more intuitive) should have some UI information : round currently played, tactical points available (if I implement the concept, so not in the first version), number of orders available (total/used/left), a pile of tokens for the ships, and the stack of cards.
Except for the ships and the stack of cards, a set of BoxContainers should do the trick.

I have no real idea about how to design the stack of cards, but there are tutorials about this on the net, so I guess that I can figure it.
Or use one of the Card framework, if I understand its code (which I currently do not).
Not sure what's the better UX to let the player choose the card he wants (something he'll do repetitively, so needs to be really easy) : a few stacks for the main categories or orders, or one big stack that deploys when clicked to show all the possible cards ?

For ship tokens I guess that a simple Area2D should do the trick.
They'll have real interaction with the rest of the game, except that in the design screen they need to be handled by the player (dragging and dropping them where s/he wants them to be on the checkerboard) and in the combat log they need to move from one square to another, probably show an animation when they fire (maybe a different animation for different types of shooting), show an animation when they're hit, and disappear when destroyed.
No idea if that requires a collision shape or not (I'd guess probably not, but I don't know what is needed for the drag-and-drop behavior).

On the design screen I probably will need to allow the player to instantiate the tokens : since tokens represent actual ships in the combat log screen but ship categories in the design screen, I think that I'll want the player to divide his "heavy ships" in two or three units (for example, to have one on each flank).

I will need UI rules for how to place multiple ship tokens on a single square of the checkerboard, I guess.
One solution would be to have a generic token represent "multiple ships" and on hover over the square, show an enlarged square with all the tokens aligned side by side.

I'm not entirely sure how to put the cards on the checkerboard.
Obviously for rows and columns a BoardPlacementSlot (if I reuse db0's CardGame tutorial, or if I do something similar from scratch) should be at the base of each column and at the left of each row.
For "big rows" and "big columns" it should be possible to have a BoardPlacementSlot a bit lower (for columns) a bit further to the left (for rows) each three row (or maybe a bit left of center of the center row of each trio ?).
The question still pending is whether I need BoardPlacementSlots on each square or if the player should just put the cards on each square directly...
It's mostly a UI question, the code should be roughly similar in both cases.
Also for "big squares" I'm not sure where to put the BoardPlacementSlots so as not to disrupt the checkerboard esthetic.
Maybe a small-ish rectangle at the base of each "big square" that enlarges to the size of a card on hover ?

For the cards that will be used out of the checkerboard ("task forces" and "Species-specific orders", I'll simply put BoardPlacementSlots on the right or on the bottom.

• For the code to resolve combat, I feel quite confident.

I plan to do all in the script attached to the main scene (or subscene eventually).
That's probably a sizable amount of work, but most of it is abstract in nature, not really specific to Godot.
And quite simple in its essence : get the orders, compute the consequences, update the variables that are affected by those consequences.

• Saving and retrieving the combat doctrines is where I don't really have a clue.

Since the design phase is made by each player separately, for generic fleets, and the combat is solved when actual fleets meet, I need to save each formation and combat doctrine (i.e., what is designed on the design screen) at the end of the design phase, and to load those formations/combat doctrines as well as the list of ships for each fleet before solving combat.
Someone above provided this documentation https://gdscript.com/solutions/how-to-save-and-load-godot-game-data/ so I guess that I can just apply it ?
I don't really understand how (and especially where) I'm supposed to call these saved files, though.
Also I'm not sure if I need to have one big dictionary for the whole data (that is, the position of ships, and the orders given each round), have separate dictionaries, separate files, or nested dictionaries.
For the fleets, I need a nested variable (list of ships, then for each ship its characteristics) and the documentation mentioned above doesn't cover this case.

Just for the mock-up it's probably useful to design a simple "fleet building screen" where the players can select the ships that will be engaged in combat, from a few preselected models (rather than the nearly-infinite variety of actual FreeOrion games).
That seems easy and I should have only minor difficulties implementing it (mostly that I don't know how to implement a drag-and-drop behavior).

I think that's it ?

LienRag Actually "lift" is a direct (and bad) translation from French "ascenseur".
What I meant was the scrollbar - I can't find a way to implement one.

Thanks to the kind person who's helping me, I'm trying chunuiyu's Card Framework, which is simpler than the other two and quite well documented.

And it made me think of something else : since I'll be using cards for the orders given, it could be interesting to have those have card values.

Not sure yet how to decide the value of each card in the final game; I guess that for the mock-up just drawing them at random (it's very unlikely that a battle will use more than 52 cards) should work fine.

Then we make those cards follow the rules of Poker, the cards representing tactical brilliance : for each square, big square, row, column (and for the checkerboard in general), at combat resolution phase, we compare "hands" and the winner gets an advantage for what happens there.

Cards add for each level : that is, the hand for square C1R1 is composed of the card (if any) played at square C1R1, the card (if any) played at Column1, the card (if any) played at Row1, the card (if any) played for the "big square" going from C1R1 to C3R3, the card (if any) played at Big Column1-3, the card (if any) played at Big Row1-3, and the card (if any) for the whole checkerboard.
These hands are known after each round, so if there are more than 5 cards in these hands, the player chooses which ones to "discard" (that is, the order will still be executed, but the card won't be used for comparing the hand to the enemy's).

Actually, what would be even more interesting would be to have each player decide which game he'll be playing with his cards, but I haven't found a way yet to make that work so I'll drop it for this mock-up.
And to avoid complexifying the mock-up too much, it may be better to have the option to use these card values/poker comparisons or not, so it's possible to learn how it works first without the poker part.

Anyway, Poker is interesting because of bets, and I'm specifically designing a non-interactive combat system, so alas I can't have interactive bets in it (or maybe at a meta level ? but I can't think of something interesting right now).

So what I'd have is a sum of "audacity points" for each player, and in the design phase the player bets these audacity points on each location (for each round, while the sum is for the entire 4-rounds battle; so a player can't bet on each location unless they have a huge amount of Audacity Points, which they won't).

Bets, contrary to cards, do not add for different levels of each location : you bet either on the column or the square (or the row, or whatever, I mean). You can bet on both if you spend audacity on both, but if you bet let's say 2 Audacity on square C1R1 and 1 on row 1, you have 2 A on square C1R1, not 3.

To win the upper hand in any location, the player must have both bet more or equal than the opponent, and have a better hand of cards (tactical brilliance doesn't work without audacity).
If the player who win the bets has a lower hand, nothing happens (audacity doesn't work without tactical brilliance).

Obviously this should incite players to bet on the locations where their hand is the best, which doesn't make for a very interesting game.
I mean, the game works if they try to bet on where their hand will best their enemy's (since they can't know it for sure, which makes the betting interesting), but if they just bet there they have their strongest hand (comparatively to their other hands, which they entirely know), it's not very challenging.

So I guess that each time the player plays a card, as long as he still has Audacity Points available, he has to make a bet on a specific location where he hasn't put a bet yet (and that bet can't be changed after that).

That means I guess that a player chooses one order, gets the card value assigned to that order ("ace of spade" for example) and has to play this order now - no backsies¹.

Also, if a player wins the bet and the hand, it means that their audacity and tactical brilliance pays off, and s/he gets an advantage on that location that is multiplied by the total of the bets put there (audacity backfires on the loser).
(I'm not entirely sure of the effect of that last rule on the balance of the game, so if someone has a better understanding of it/more ideas to help this balance, I'd be glad to hear them)

Which advantage is chosen by the player (on a per-turn basis rather than per-location I guess, so as to avoid clogging the UI) : more damage dealt, less damage received, more speed for their ships, less speed for enemy ships, better stealth, easier achievements, ...

So what that means for the Godot scene :

• A counter for the Audacity points

• A label area (with a drop-down menu ?) to choose the advantage provided by having the upper hand during the current round

• Near each card slot a way to place a bet (another counter I guess ?). One too on each square (since square won't have dedicated card slots)

• At the end of each round in the design phase, an animation showing each location with more than 5 cards, and a way to signal which excess cards will not count for the hand

• A way to check the hand for each location for the current round, at every step of the game

• In the combat resolution phase, an animation showing the bets and hands for each location, and another one showing the locations where each player won

• Probably an animation on each location where one player won, to show what advantage applies

I think that's it ?

Once it's integrated in the full FreeOrion game, one problem is that once a player has met the enemy combat doctrine, its bets are well known and it's easy to tailor counter-bets against them.
Note though that tailoring combat doctrines to counter enemy combat doctrines is the core principle of this non-interactive combat system (as you never know which combat doctrine the enemy will choose among the many they have).

Still, it's probably useful to avoid tying completely the bets to the combat doctrine.
Probably, allowing to change one's bets a little (maybe one Audacity Points each turn ? or a small number tied to the Empire's characteristics ?) would make the game more interesting.

¹ Another option would have the player see the card values for each possible order, and each type s/he picks a card s/he has to play this card, and another card for the same order - but with a different card value - is drawn and added to the possible order cards. The value for the new card would be known after the player has picked their card, but before they play it.
So if s/he picked a "move&shoot" order bearing a five of hearts, and the new "move&shoot" card is a king of diamonds, the player may choose to put the five of hearts in a different location than they previously intended, in order to put the king of diamonds where it brings the most benefits.