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.
Hello. Yes opening an issue is the best way if you encounter a bug with CardEngine.
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 ?
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.
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 ?
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):
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
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 :
### 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 :
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.
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.
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.
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 ?
