xRegnarokx When you have such a big, general-purpose object/node/whatever you must always try to think if it can be broken down into smaller pieces. For example, you mention that ships have health, so you could create a custom "Health" node where you define all the variables and methods related to this: hp, take_damage(damage_amount), heal(heal_amount), die()...Your ships can be selected? Create a custom "Selectable" node that handles all this functionality. It will much easier to deal with your ships if you have these small, independent pieces than if you have a monolithic ship node that tries to do everything and mixes everything all at once. It will also allow you to quickly create new types of ships and give them these behaviours, or modifications of these behaviours, without breaking anything else.

      correojon Okay, my ships don't hold really any func, just variables. They are moved/selected/ordered/attack via other nodes giving them commands. They just hold variables in order for other nodes to change as they get damaged and as they move and such.

      Right now I have it like this...

      TurnControl(orders unit movement/activates) -> MyUnits(registers input and sends signal depending on input) -> ShipMove(Takes ship information and passes it to MapGrid) -> MapGrid(plots viable movement hexes, and sends the command to move back) -> ShipMove(now moves ship to the hex that MyUnit registered the click on).

      When I have weapons I plan on having those referenced possibly in a RefCounted, or some other way (haven't figured out what I'll use to implement that section yet.)

      So ship holds all the variables for itself, I thought that'd make it easier to save, maybe I'm wrong in my thinking.

          xyz Awesome, it is good to know about the scene tree aspect. So, it'd be better if they are custom resources that are referenced but not instantiated into the scene to maybe use a RefCounted?

          An example would be a reference to a weapon that doesn't physically exist in the scene tree but you want to pull data.

            xRegnarokx

            Resource might be a step better than RefCounted for data objects. You can embed them in the scene or save them in res//.

              xRegnarokx You should stay away from Objects, RefCounteds and other such computery stuff. The intended way to build things in Godot is by using scenes. You'd be well-off thinking only about scenes when figuring out the "big picture".

              A scene is meant to work as a specific thing in your game. If you were making a tabletop game, each thing that you can point a finger at and say - that's X, can and should be represented by a scene in Godot. Such things can be big (like a human player) or small (like dice). Complicated things (like a gameboard) can be assembled from many smaller things (like hexes, drawing cards, counters and figurines).

              So assemble your game from actual things and make each thing a Godot scene. Here's an example.
              Scenes for my game:

              • Map (single for level, many levels) - consists of other things listed below:
                • Hex (many, various types) - represents terrain, can hold a single unit
                • Unit (many, various types) - move and fight on hexes
              • Player (several) - commands units on map, can be controlled by human or AI

              You can see that in my breakdown I don't have any smart sounding abstract things like "controller" or "processor". The intent is to make those "real" things work as they would in the real world. The Player commands and passes/receives information, the Unit receives commands and moves or fights, the Hex displays terrain etc... Try to keep clear of programming and abstractions when organizing the project. Instead, model your system as if you were making it out of wood.

                  xyz Awesome sounds good! Yeah, I have been trying to simplify my code, where I have a node handling each unique action.

                  Example:
                  TurnControl - starts move turn and attack turn
                  ShipMove - moves ships
                  MapGrid - handles data to give to other nodes for map coordinates, and calculates eligible tile for movement, attack ect..

                  So, I have been trying to simplify as well as streamline the communication between nodes.

                  • xyz replied to this.

                      xRegnarokx Those are again some abstract functionalities you for some reason want to ascribe to random nodes. Why? Your TurnCotrol and ShipMove are not things. They are bureaucratic go-betweens that have no reason to exist in a well designed system. Turns are controlled by players, and ships are moved also by players or by themselves following the orders from players.

                      So instead nodes named TurnControl and ShipMove, you need to have scenes named Player and Ship. These will represent exactly those things.

                      Each scene will have to have a script attached to its top node. This script should contain functions that perform actions that the thing is capable of doing. So, for example the Ship thing may have functions like: move_to(), attack(), take_damage(), set_weapon(), get_hitpoints(), etc...

                      Now the Player thing can communicate with any Ship thing by calling these functions. It can order it what to do or check its status. Just like a player in a board game would do with their units on the board. In object oriented programming we call those functions an "interface". It's the means by which other things manipulate that thing.

                      In the above example, the Ship thing is autonomous. It can perform actions that Player requests of it but Player doesn't need to know how exactly the Ship does it. The Player need not to care about any nodes inside the Ship. It just has to call functions provided in Ships' "interface" and reap the results. This greatly simplifies Player's life. In other words, each thing keeps the details of its inner working to itself, making it self-contained and thus easier to maintain and repair if it breaks down. In object oriented programming, this is known as "encapsulation".

                          xyz You should stay away from Objects, RefCounteds and other such computery stuff. The intended way to build things in Godot is by using scenes.

                          (If you use the default SceneTree. But mentioning custom MainLoop is probably a bit too much and off topic here, still may be worth being aware of it...)

                          • xyz replied to this.

                              Megalomaniak My answer was specifically for OP, after seeing what they struggle with through half a dozen previous question threads they started.

                              That being said, I'm not sure it would be worthwhile to go with a custom main loop from GDScript. You'd need to maintain some alternative system to organize all scene data. This sounds like a lot of per frame iteration. GDScript may have hard time keeping up the performance there.

                                  xyz That being said, I'm not sure it would be worthwhile to go with a custom main loop from GDScript.

                                  Yeah I recon it makes sense via C/C++ or perhaps Rust or something to that nature and only for a very strict need that the SceneTree can't cover.

                                  • xyz replied to this.

                                      xyz Okay, so I was trying to have nodes that controlled each aspect rather than have a massive code that controls everything.

                                      So I should control everything related to the ship directly within the ship node, and call the func with the parent node.

                                      Where would I place my tile map in relation? As the parent node? Also, what would my structure look like with UI for ships, would that be as children of ships? I guess my structure was designed trying to prevent having a lot of signals calling up and callbacks to transfer needed data, as well as hige quantities of code held in each node. I tried to use my parent to connect and give the parameters for when to start a phase. Then use the nodes for specific actions (move, attack, UI, AI, camera etc...). So, I guess I've either been reading counterdictory things about structuring or am misunderstanding good structure.

                                      So would you say it should be tilemap->player->ship->shipUI/shipcomponents
                                      Where would I put AI node, gameUI, and camera ect...

                                          Toxe I have read it, I'll try reading it again with what people have said here in mind so make sure I am understanding it.

                                            xRegnarokx You're constantly mentioning nodes, but you never seem to mention scenes. And all I was talking about in my previous long winded posts are scenes 🙂 Are you at least familiar with the concept of scene in Godot, and how to use scenes to create reusable game components?

                                                Megalomaniak Yeah I recon it makes sense via C/C++ or perhaps Rust or something to that nature and only for a very strict need that the SceneTree can't cover.

                                                I see it primarily as a way to create a system that completely circumvents nodes and tree-like organization of scenes, like ECS or something similar. Doing this would make a lot of editor functionality useless. That's one additional reason to do it via native code and just use Godot's servers and other useful classes like a framework. It would be nice to see a project that attempts this.

                                                  xyz Yes I am familiar with scenes, so all of the nodes I was talking about (except ships) are in one scene. So the parent TurnControl
                                                  it determines if it is move phase or attack phase.
                                                  I have its children
                                                  ShipMove, ShipAttack, MapGrid, AI, GameUI, AIUnits, MyUnits, Camera

                                                  (I could combine these into more general code, but I've read a lot of things that talk about breaking code up into small specialized bits rather than having them handle a lot of different aspects)

                                                  ShipMove interacts with MapGrid to plot movement, and move ships (either players or AI).
                                                  ShipAttack interacts with MapGrid to find eligible targets and to attack them.
                                                  MapGrid just plots positions on the Map
                                                  AI controls the enemy ships AI logic calling either ShipMove or ShipAttack in order to act.
                                                  GameUI handles all UI features and interacts with necessary nodes, mainly communicating with parent.
                                                  AIUnits and MyUnits handles receiving attacks and changing variables within ships to reflect the attack.
                                                  Camera is just Camera.

                                                  This is how I currently have my scene set up. This will be instantiated under my level scene which will handle victory conditions and any unique dialogue or interactions.

                                                      xRegnarokx I don't think you fully understand what scenes are for and how essential they are in building a modular game system. Maybe read again the section on scenes at the link posted by @Toxe.

                                                      Roughly deducing from your description, I'd have each of the following as a scene:

                                                      • main scene
                                                      • dialogue
                                                      • main_ui
                                                      • player and/or player_ui
                                                      • map
                                                      • ship
                                                      • ship_ui
                                                      • camera_rig

                                                      Instances of each can be siblings inside main scene.

                                                      The script functionality you now have distributed through some nodes, should be refactored as follows:
                                                      ShipMove, ShipAttack - goes into -> player and/or ship
                                                      MyUnits, AIUnits -> player
                                                      MapGrid -> map
                                                      Camera -> camera_rig

                                                          xyz Would you suggest having main scene then become my TurnController, or would I control turns through the main_ui?

                                                          Also how would you suggest I handle the AI logic, as its own scene or bundle it up into player?

                                                          Would/should I instantiate these into a scene after I construct them and then save the scene together in order to make loading it simpler for changing levels?

                                                          I've also read the article three times now, and for me it still doesn't make clear how to set up my scene structure. All my nodes are loosely coupled and as far as they can be independent of any code outside themselves. (They require information from the map, and the map from the requesting node for calculating tiles based on ship location)

                                                          I guess naming something player that also controls the enemy for me makes clarity on what they do an issue. If I were to read those I would wonder how the person controls the AI.

                                                          The rest of what you've suggested makes sense and in general bundles like things together.

                                                          So if I understand you would place func() within ship that player would just call to tell it to_move(), to_attack(), damaged() ect... So, player would handle the inputs (and I am guessing passing the needed information from the map to the ship) while the ships code would change the position, health, and determine weapons damage ect...

                                                          • xyz replied to this.

                                                              xRegnarokx You can get answers to those questions by trial and error. The gist is to use scenes (instead of nodes) as main organizing units of your system.

                                                              The global state of the game, including turn management, can go into something that's "above" players, commonly that can be a script in the top node of the main scene, named something like Game.

                                                              The Player scene should keep lists of all the things that a real world player would have in their mind - which units they own, how those units can move, it should be able to query and asses the state of the map etc... It could also have a toggle switch that lets it be controlled either via ui input or by ai logic built into itself. That way you can instantiate the player scene for example twice, and flip the ai switch for one of them. Or you can flip that switch temporarily to play the next move for the human player. Or flip it for both players and let the ai play against itself...

                                                              The actual scene instantiation moment really depends on the needs of your game and purpose of each particular scene type. For some it's more convenient to instantiate them manually in the editor while others may need to be created at runtime. For example if your game can have 2-4 players. You'd instantiate players at runtime, after the number of players has been selected.