• 2D
  • Mock-up for a non-interactive combat system for FreeOrion

It's been a while that I want to improve FreeOrion combat system and had the idea of having it be a non-interactive tactical card game (like exposed here).

Due to the lukewarm reception, I decided to make a mockup of it myself.

I wanted to do that in PyQt (in order to learn PyQt) but it took me time to find a good tutorial and in the time it took, FreeOrion decided to switch to Godot.

Since making the mockup in PyQt would mean having to throw away the mockup to redo it entirely if the decision to make it part of the game would be made by the core team, making it in Godot suddenly made much more sense.

So I tried to learn Godot, and now a few months after beginning it I finally finished the first tutorial "Dodge the creeps". Which means that I understand what a Scene is, know that Nodes exist and have a vague idea of what they are, globally understand the idea of connecting things (though what and when exactly is more fuzzy), and have a vague understanding of GDScript syntax.

Watching a video about a Godot card game, I also understood that my "game mat" is actually a two-dimensional array, and that giving properties to the cards (like "held", "played", "discarded") is probably a good idea.

But that's the extent of my knowledge as of now, and I'm not sure about where to begin. The 'Dodge the creeps" tutorial made clear that there are a lot of possibilities in Godot, and didn't really teach about how to find them (only how to use the one it gave as examples).

Are there simple tutorials that I should read or watch to be able to start my mock-up more efficiently ?

Where can I find simple assets (tiles, background, spaceships, effect cards) to start making a mock-up of the mock-up ?

What are the steps that I should design before beginning, and which can I make up on the go ? I have a fairly clear idea of what I want, but not of how it translates into code.

Is there some existing simple project of which I can take the code (if its license permits it) for parts that are similar to what I want to do (putting the "game mat", putting the cards/tokens on it, playing the cards) ?

5 days later
2 months later

So I finished the aforementioned tutorial (which I found really good) and now I have a better idea of where I'm going.

One thing I have no idea about though is whether it's possible to use a database, even a simple one made of text files ?

I want to make three different though connected things, one panel to design the tactical doctrine, one panel to make choices about the fleet composition of the next fight (that part is just for the mock-up, as if my proposal is integrated into FreeOrion then it's the FreeOrion strategic map which will provide the fleet), and one panel to show the resulting fight.
So the first panel needs to be savable to disk (with the player's decisions on the save) so as to be usable in different actual fights later.

What is the best way to do that ?

I'm really copying the tutorial so far (adapting it to my needs).
One question about it : is there a consequence for the grouping of tiles into a "tile" node ?
What I mean is that my tiles will be logically grouped into sets; should I put the relevant tiles into a "set" node for each set (so a set1 node with the 9 corresponding tiles in it, then a set2 node with the next block of 9 tiles, and so on) ?
Or do I treat the logical grouping in the script and just keep all the tiles in the "tile" node ?

In terms of 2D assets, there are free and paid ones on Itch.
https://itch.io/game-assets

Database access is possible, but it's mostly unnecessary. If you are just reading from files, you can use a spreadsheet, which you can export as a CSV file and read in Godot (this is like a ghetto database). For read/write you probably want to use JSON.
https://gdscript.com/solutions/how-to-save-and-load-godot-game-data/

For 2D tile-based games, you can create a TileMap and a TileSet. The map is like the whole world that you see on screen. The set is the options for tiles. You can make multiple sets, one for desert theme, on for a forest, one for a town, etc.
https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html

    cybereality

    Thanks, I guess that I'll have to learn JSON then...
    I know a little bit of YAML, so I guess it shouldn't be too hard.

    I wasn't aware of TileMaps and TileSets, thanks for the tip.
    Though, reading your link (I didn't test it as a godot project yet) I wonder if it's not overkill for what I want : basically, my game will be a checkerboard with ships on it, and cards to be placed on columns, rows, or tiles to give these ships orders.
    The logical grouping of tiles will be into rows, columns, ... so that when an order is given on a column (for example) all the ships placed on the column should apply it. Some effects will also target a whole set of tiles.
    I want also to have "parent tiles" i.e my 99 checkerboard is also a 33 checheboard (i.e it's possible to give an order to the "left front parent tiles" that will apply to the 9 tiles that are in the 3 front rows and the 3 left columns), that would be another set of tiles.

    Do I need a TileMap for that ?

    Since in the definitive version I want to have a (2n+1) checkerboard rather than a 9*9 (n being the number of combat rounds as defined in the game settings, something that will be given to the combat system by FreeOrion) I guess I do (in order to use "autotile") but for the mockup is it useful ?

    Writing this, I realize that the tiles would need to be in different sets (a single tile is both member or a row, a column, and a "parent tile"), so I'm not sure that TileMap is the right node to use...

      I don't have a lot of experience with tiles, but from what I have, it's very easy to paint up a large board with tiles, but when you need to manipulate a certain tile in some way, it's not intuitive.
      For expanding a tile, If you are working with rectangular sprites, it's very easy to change their scale. They won't look any clearer, but they will be larger, but you might be able to start the scale larger and then scale it down for the board. You could make it a class, and then keep other things with it, like stats, or extra sprites, and then position them locally to the tile when it's expanded.

      I wrote 9x9 and 3x3 checkerboards, the editor automatically converted it into italic apparently.

      LienRag

      A TileMap is just a convenient way of painting the same set of images repeatedly, sometimes with collision shapes in them. You could use a dictionary keyed on vectors to keep track of your tiles. You could assign them to groups and call methods in every member of a group simultaneously. When I think database I usually translate it into Dictionary in godot.

      I would avoid json for what you're doing, since it doesn't handle native vectors or rectangles. It's easier to use store_var() to save the data or nodes directly.

        duane

        I'm not sure if I need vectors ?
        Tokens on the checkerboard will need to move, so maybe vectors are a good option, I have actually no idea about how to use them.
        Tokens will move from one tile to another, and change facing inside the tile, but it's a strict position : the token is on a tile or it is not, there is no "moving half-tile".

        I know what a dictionary is but not sure why it should be keyed on vectors ?

        I thought to use an two-dimensional array for the tiles, since intuitively it seems the most adequate way to have a coordinate system.

        duane You could assign them to groups and call methods in every member of a group simultaneously.

        That seems to be the right way to do it, thanks.

        duane I would avoid json for what you're doing, since it doesn't handle native vectors or rectangles. It's easier to use store_var() to save the data or nodes directly.

        I don't think that I need to save vectors nor rectangles ?
        I need to store the tokens position (which tile they're on and what is their facing) on the first turn and the orders given to them, that's all.
        The orders are cards to be placed on BoardPlacementSlots if I understand the documentation of the GodotCardGameTutorial that I just read, so I just need to save the turn, the order label, and the slot it is using.

        The idea is that the players define "tactical doctrines" in abstraction, and when a battle occur, it is solved by applying the relevant "tactical doctrine" (so, initial ship positioning and orders) to the actual fleets.
        So what I need is to store each tactical doctrine separately (in the mock-up, I intend to have only one tactical doctrine).

        I wasn't able to find documentation about store_var ?

          A Dictionary is flexible, it could be used to simulate a 2D array.

            LienRag

            In my roguelike, I keep a lot of objects confined to a virtual grid by assigning each of them a vector (of two integers) showing their position. I never store any of them in any structure. When I want to find one, I just loop through all the children of their parent object, looking for a particular coordinate (vector). Since the game is turn-based, it doesn't have to be especially fast.

            If I needed more speed, I might take each and assign them to a Dictionary by "dic[Vector2(<x>, <y>)] = <object>". You can use 2D Arrays in gdscript, but I find it more complicated. That's just one way to do things.

            store_var() is a method of File that stores a Variant in a binary format. It supports (as far as I know) all of the native godot objects, so it can be simpler than json.

              You can also load CSV files into Godot. This gives you basically a 2D Excel spreadsheet. I used this for a project to store text and stats and stuff. It's a little harder to save in Godot, but for reading it works well and you can use LibreOffice Calc (or Excel) to write the data, then export as CSV. Sort of like a ghetto read-only database.

                5 days later

                cybereality A Dictionary is flexible, it could be used to simulate a 2D array.

                Really ? How exactly ?

                cybereality you can use LibreOffice Calc (or Excel) to write the data, then export as CSV.

                Not really, except maybe for testing.
                The idea is that the first phase (designing the tactical doctrine) should save each tactical doctrine, and that the tactical doctrine can then be used with various fleet composition.
                So the ability to save to the format is paramount.
                I guess JSON it is then, since I don't really need to save any Godot object.

                Maybe I can use CSV for ship data though, since these ones are not to be modified by the combat system (in FreeOrion they are designed in separate panels), and the mock-up only needs to read them.

                duane In my roguelike, I keep a lot of objects confined to a virtual grid by assigning each of them a vector (of two integers) showing their position. I never store any of them in any structure.

                I downloaded your roguelike but it's quite huge.
                Could you pinpoint one example of this more precisely ?
                From what you write (without having seen the code) I don't understand the advantage of your way.

                  LienRag

                  There's not much to see, really. The monsters are added through a slightly complicated chain of events as children of the dungeon, which inherits from TileMap. So, when I want to check a particular grid location I do

                  func map_unit(pos:Vector2):
                  	for c in get_monsters():
                  		if c.grid_position == pos:
                  			return c
                  
                  func get_monsters():
                  	var out = []
                  	for c in get_children():
                  		if c.get('is_creature'):
                  			out.append(c)
                  	return out

                  That's a simplified version.

                  The advantage for me is that I don't have to maintain the objects in two places. They're always going to be part of the scene tree, so if I use another structure to track them, I'm duplicating effort, and creating the possibility of the two getting out of sync (which actually happened when I was doing it that way).

                  Note that I'm checking for an "is_creature" property instead of using "is Creature" to check the object type. That's just because gdscript 1.x still has huge issues with cyclic references. In a project with a lot of code, it becomes impossible to use typed variables with custom class names or even to use the "is" keyword without errors.

                  I just offer that as an alternative. There are lots of ways to do it.

                  2 months later

                  Since there are only tiles, tokens and cards in the game but all the player's actions will be on the cards, I guess I'd better use already existing card games resources.
                  But apparently there are many different ones, at least two : the Card Game Framework by dbo and the Card Engine by Braindead.

                  Which one is best to use ?
                  I really need only simple things :
                  1 - A list of different cards
                  2 - A few decks to draw from
                  3 - Animation to show the cards in each deck when one wants to draw (it's not random drawing in my game, the player chooses the card he wants - so I guess functionally it's more a "hand" than a "deck" but UI wise they'll be shown as decks on the board)
                  4 - Ability (and the corresponding animation I guess) to choose a card and play it on the board (on BoardPlacementSlots I guess).
                  5 - Ability for BoardPlacementSlots to hold (and show) many cards on it
                  6 - Ability (and the corresponding animation) to check which cards are on BoardPlacementSlot

                  And that's it.

                  I dabbled a little bit with one of them (dbo's I guess) before I changed computer and had to re-download everything (which led me to understand that there are more than one) and apparently the way to use it was to open it with Godot and then add my scenes inside of it ?
                  Isn't it a bit heavy and cumbersome ?
                  Do both framework (or others I don't know of) work that way ?

                  I'm much prefer have clear snippets of code/ressources that I could import into my project and then modify according to what I need.

                  4 days later

                  Well, I tried BrainDeadBzh's framework CardEngine and looked a bit at its documentation.

                  But it says "To create a database press the "Create new database" button."
                  Where do I find this button ?
                  There's a screenshot of the button but on a panel I don't know where to look for.

                  Or is the addon just not working ?
                  I got "Impossible de charger le script de l’extension depuis le chemin : « res://addons/cardengine/card_engine.gd ». Cela peut être dû à une erreur de programmation dans ce script.
                  L'extension « res://addons/cardengine/plugin.cfg » a été désactivée pour prévenir de nouvelles erreures." when trying to enable it in the Project Settings/extensions panel.

                  I did try CardEngine in different versions of Godot but to no avail, I still get the same error message.

                  I also tried a different add-on to test whether I was doing something wrong, but this other add-on works.

                  The error message seems simple enough, but I don't understand why it appears : I checked that there is actually a card_engine.gd file in addons/cardengine and its syntax doesn't seem different than any other plugin's.
                  It's also, as far as i can see, correctly referred to in the plugin.cfg file.

                  It would probably be more helpful if you could provide the error in english.


                  as per github repo :

                  Currently under development, do not expect it to work.

                  Everything is work in progress.

                  You can maybe open an issue on the repo tho. @braindeadbzh seems to be registered on the forums so perhaps they can confirm if this is the preferred way to move forward.

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

                    I mean you could translate it, either yourself or using a translation app or such. As the one requesting help I'd say the onus is on you to make helping you as low barrier as possible. This is not limited to just translating errors given but also including things such as providing more info about how the relevant scene is built, what the node structure is like, what signals might be connected and to where, etc.

                      LienRag Is there a non-microsoft repository

                      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 realistically.

                        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.

                        12 days later

                        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 ?

                        If you think you have all the files in place in your project directory, you might be missing the necessary AutoLoads that need to be present before activating the plugin.

                        You also need the project.cardengine file at the root of the project which contains folder paths that should exists.

                        Well, lets go through it in order: Have you set up the appropriate autoloads as shown in the image?

                        Do you have the project.cardengine file in your project root? You might have to poke @braindeadbzh about providing an example project.cardengine file perhaps if there is no documented example of what paths it should hold.

                        The project.cardengine file from the repo can be use as it is, most of the projects won't need to change the content.

                        I never really took the time to describe how to install CardEngine into an existing project, the idea being to create your project from the demo. But a simple way could be (NOT TESTED - BACKUP YOUR PROJECT BEFORE):

                        1. Past the whole repo content into your project (except git files)
                        2. DO NOT overwrite existing files
                        3. Add the Autoloads
                          7 days later

                          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 ?

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

                            Only the ones that point to a script in addons/cardengine are necessary the other are only there to support the demo.

                            LienRag 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 ?

                            If you did not overwrite any file when pasting CardEngine into your project this should not have changed the main scene.

                            LienRag How to do that then ?

                            If you start from the demo, then you can follow the documentation

                            2 years later

                            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.

                              6 days later

                              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.

                              8 days later

                              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.

                              9 days later

                              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 ?

                              10 days later

                              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.