All Questions


posted to: Selecting a target

Battler Scenes, Anchors, and Sprites

When I ran into the following part of the lesson, I was somewhat confused:

To place the anchors for a given battler, open their scene and right-click on BattlerAnim. In the context menu, toggle Editable Children.

The reason for the confusion was that up to this point in the lessons, I had yet to create standalone scenes for the Bear/Bugcat.

In the lesson The active turn queue in the core systems chapter we were instructed:

In the image below, Bear and BugCat are two instances of Battler.tscn. In our demo, the ActiveTurnQueue node has the encounter’s battlers as its children.

following which, I instanced Battler.tscn twice under the ActiveTurnQueue node in the CombatDemo.tscn.

In the lesson Taking and inflicting damage in the core systems chapter we were instructed:

I prepared a scene with the following node structure, with our ActiveTurnQueue and two battlers: one for the player and one for the enemy.

In which I simply changed the names of the previous Battler.tscn instances in the CombatDemo.tscn.

Given that up to this point I only created instances, to customize the anchor points I would need to toggle Editable Children twice: once on the Battler node, and then once again on the BattlerAnim node.

Upon checking the final project example, I found that there were standalone scenes created for the Bear and Bugcat and that these two scenes are where it was intended for us to toggle Editable Children on the BattlerAnim node. Additionally, I found that each of these scenes added a Sprite node under the BattlerAnim > Pivot node branch; though, perhaps adding the sprites comes up in a later lesson.

  • Nathan Lovato replied

    Thanks again for taking the time to write detailed reports. Indeed, the instructions need change. I'll work on that.

    In this demo, the battlers aren't what they'd be in production, in a larger game. The idea would be to maybe export an extra property on the battler class to assign it an animated skin and let it pass it to the BattlerAnim node. Something along those lines.

    As we only have sprites in this demo, and when prototyping, I'd recommend doing whatever's simplest and works; in this case, adding sprites as a child of BattlerAnim.

    I'll address this to wrap up the 0.5.1 update.

  • A
    ThePirateKing replied

    Thanks for looking into it!
    I'm trying to reproduce what's in the final code for now, and I'm wondering how you made the scenes for Bear and BugCat. I added a Battler root node to a new scene but it seems scene root nodes don't have the 'Editable Children' toggle in their context menu.

    How do I create a Bear scene with Editable Children using a Battler node?

  • A
    ThePirateKing replied

    I figured it out :)

    The Bear and Bugcat scenes don't 'Add Child Node' to create the root scene node, they Instance the Battler scene as a root. Perhaps the 'Editable Children' is only available for instanced nodes?

    This also makes me curious about the details of instancing vs adding nodes to a scene. Do you have any supplementary course material to help me go over this?

  • Nathan Lovato replied

    I duplicated the battler scene for each battler. You can do either that or inherit from the battler scene, but as explained in the updated lessons, I don't recommend using scene inheritance.

    Duplicating scenes is fine at the prototyping stage, that is, until you need many battlers. When you get there, the main recommendation I'd give is to export a variable on battler instances to set a sprite or animated character to use in the inspector. Then, you can pass that data to the BattlerAnim node in Battler._ready() and let it initialize itself.

  • Nathan Lovato replied

    One difficulty for us with those tutorials is that every problem in code is highly contextual. I can fake the problem of needing over a hundred different characters, and imagine a solution, but until I've faced it in a real production, I can only hint at possible ways of solving the problem.

    As the size of a game scales, you have to adapt the solutions to your project's code structure, right. And so I think even what I wrote above may not apply so easily to a large RPG. You may need tools, or you may want to externalize all your data (for example, have a spreadsheet with all your characters' stats and base data outside of Godot, and use that to generate battlers?).