Making tactical units - A devlog
ฝัง
- เผยแพร่เมื่อ 20 ก.ค. 2024
- Let's talk about how the data behind units is structured, how artwork is implemented, and how I'm handling unit AI in my tactics game.
00:00 - What I'm making
01:40 - Unit data
04:35 - Artwork
08:33 - Unit AI
Text version: shaggydev.com/2023/09/04/tact...
The previous devlog: • Developing a tactics e...
An introduction to Utility AI: • An introduction to Uti...
GDC talks of interest:
www.gdcvault.com/play/1012410...
www.gdcvault.com/play/1021848...
Every time I am soo hyped when I see you uploaded a video. Thanks for the great videos!
I literally check the channel every day haha
Nice! Super excited both for more detailed discussions on the Kaiju Klash spin-off dev, and even more so to see what comes of the sci-fi tactics game!
I bought the game and it was fun! Thanks for sharing your knowledge ♥️
Thanks for checking out the game! Glad you enjoyed it!
I wrestled with y-sort vs. z-level in a game, but eventually I just embraced the Godot way and arranged the nodes in the node hierarchy. Like you, I had kind of templated types with attachment points, and what helped was the RemoteTransform node (or whatever it's called).
07:46 In terms of performance: No idea, if it can help you in this case, but there is a .set_process(false/true) method for nodes in godot. I'm using it in my game, where i have a big object-pooling-system and set_process on every node, that i add or remove from the tree.
That's an easy way to stop calculations on nodes, that you don't use on the gamefield.
Y-sorting is such a pain in Godot... I recently made a 2D game with this exact style with the orthographic top-down view, and struggled finding a good solution that didn't create a bunch of other problems.
Have you considered just switching to 3D, use an orthographic camera, and render the sprites as billboards using the Sprite3D node? Keep the 2D look, but use 3D under the hood. It adds additional overhead for sure, but I feel like it's completely worth it in the long run. So many other modern games use this method, and you can start to understand why...
Hmm, that's an interesting idea I hadn't considered. Gonna keep that one in my back pocket...
The bit that confuses me with Godot is when to use Nodes vs Resources.
If I recall in the last video a CombatantGroup, Unit etc were nodes in the tree. Have you now swapped to just using resources or are you describing a mixture of both?
Sorry if this is a daft question.
No worries, I could have made this a bit clearer. Unit and CombatantGroup are indeed nodes in the tree, as the Unit scene represents the "physical" entity in the world. The Resources I showed in this video, though, are the data that drives the physical side.
So when a Unit needs to be created, the Unit scene (which is a Node2D) gets instantiated and loads the data it needs, such as its parts, from the UnitDefinition (which is a data-only Resource).
This makes it so that data and their representation can be abstracted away from each other, letting me work with the data that drives a unit without having to load a physical entity into the game world I may not need.
@@TheShaggyDev
Thanks for the reply.
Makes total sense and thought that was the case.
I took inspiration from your previous video on structuring Groups/Units and had been planning out how a save system could work within this structure and came up with a very similar system as you described here.
Happy to know I'm on the right sort of track!
Great video btw!
You definitely should be able to use y-sort with z-depth changing just fine. Disabling (or not accidentally enabling, as it's off by default) y-sort within each child node should prevent it affecting the rendering order of its own children, allowing you to handle their render order by relative z-depth. It would be strictly less useful if it didn't work this way. If you are still using Godot 3.5, the y-sort node is only supposed to sort its own children and not the children of those children by default...In fact, I think I had to create a hacky solution to cause sorting of child nodes, gave up and just wrote my own y-sort because of this back when I was still using 3.5. I haven't worked with y-sort yet in 4.1, so take this with a grain of salt, but based on several search results I've read about this, the y-sort property in ordering on a given node2D only tells it to sort its children, not to have itself be sorted. So, turn off y-sort in anything you don't want to be sorting its own children, and you should be good.
Thus far I have not been able to get the two to play well together in Godot 4. Even just a simple scene of sprites seems to break y-sorting once you get z indexes involved, but I do point it out in this video in the hopes someone can prove me wrong 🙃Since the new CanvasGroup node also doesn't play nicely with z-indexing, I'm lead to believe there's a few different options for handling 2D ordering in 4, but that they are not all compatible with one another.
Would sinply adding the body part scenes in the correct order not fix it? (Y sort is done on the top level unit node, and children body parts are drawn by order of adding them). Or am I missing something? I guess you would have to position them at the anchor points manually from code.
The issue with that approach is that the each part can have sub-sections that need to be in a different order than where the overall part needs to go. Torso might need to be in the middle, for instance, but some detail on it should be in front of the legs and some other detail in the very back.