[Conceptual] Encounter and On-Map alternate Battle Systems

[Brasten]

A conceptual discussion and examination of ways to create Battle Systems outside of the pre-code Action game systems.

The current tools AGM+Godot have, and what tools AGM is missing to make a design possible without advanced Godot tools.

---

Topics to cover include, but not limited to:

• Battle Screen: transitions to another scene or visual screen, and back when combat is done
• On-Map, aka Chrono Trigger: combatants stay in the current Scene and move to combat positions
• Turn-based: combatants take turns, either sequentially or another organizational order. E.g. ordering based on a “speed” value.
• Real-time: combatants act on their own timers, or on the Process tick of the game engine. They may interrupt other combatants or act simultaneously.
• Pseudo-turn-based: Any mix of Turn-based and Real-time systems, where combatants have to wait for another combatant to finish an action.
• Fix-position, or battle-line: combatants take up set positions, and only move with pre-set animations
• Dynamic-position: combatants are free to move. Positions may or may not be important.

Action Game Maker and Godot Systems

The AGM Database is critical to all of these. Understanding how to setup and modify User Databases, Project Variables, and Project Switches is a required skill for making a Battle System.

---

The Godot SceneTree and how AGM Nodes work with it is another vital system to understand. AGM takes control of Scene management through the Scene Transition tab. Which is really important in how res://AGMaker/core.tscn functions.

If you are not familiar the SceneTree and tree order you will need to read some of the Godot documentation. Tree as data structure term appears frequently in the Godot systems.

• Short: Top of the ScreneTree layers behind anything lower in the tree.

During runtime, the current GameScene will be added as a child of GameScenes. When the Action:EndScene happens, SceneTransition will remove current scene and replace it with next, by Link logic. This limits AGM to one active GameScene at a time.^[1] Links can also switch scenes before an EndScene, so check your Link Conditions.

• 1.0.7: There is no Visual Script Action to load multiple GameScene. This conflicts with Godot composite game design principles.
• 1.0.7: There is no Visual Script Action to transition to a specific GameScene. This must be manipulated through SceneTransition Links Is Change Switch Variable, and a ProjectSwitch or ProjectVariable.

GameScenes are constructed from multiple Layers^[2]. Layers in this context are Parallax2D nodes. They are given special privilege in Visual Script with Layer Actions:

Under the GameScene or Parallax Layers are the required ObjectRoot nodes. These are responsible for the operation of GameObjects. If a GameObject is not a descendant of an ObjectRoot, it will not function correctly. The immediate ObjectRoot ancestor is where Action:GenerateObject will place a new GameObject. At the bottom of that ObjectRoot’s children.

MenuScenes are intended for use as static GUI elements. Control nodes that do not move with the Camera^[3] and stay positioned relative to the Screen. These can be special scenes can be Action: OpenMenu and CloseMenu.

The UIObjectRoot node is just an ObjectRoot, same as for GameScenes. You are supposed to put GameObjects intend for UI Visual Scripting under it. All the graphical heavy lifting is done by the CanvasLayer. Make sure to child Control nodes under the CanvasLayer. You will also want to think about setting the Layer number. This overrules SceneTree order, for what gets drawn visual over top of everything else.

The order you OpenMenu can be important. Remember tree order. The most recent MenuScene is added to the bottom of /root/CoreScene/GameScenes. These SceneMenus do not close on a scene transition. Instead the new GameScene will be added below them in the SceneTree.

This is where those CanvasLayers really become important. By default GameScenes are on Canvas Layer 0, along with anything else that isn’t the descendant of a CanvasLayer node. The MenuScenes have their CanvasLayers defaulted to 1 , so they will automatically render on top of GameScenes ^[4]

Why was this background on Nodes important?

Because a Battle System can be setup in some very strange ways.

Some quick examples.

• You can create a BattleLayer out of an extra Parallax2D (shown above). That can be Enabled and Disabled. With a BattleSystemObject under its ObjectRoot.
• You can put non-Control nodes into MenuScenes, and have Visual Script GameObjects still running across different scene changes.

Understanding SceneTree and the Nodes is a part of the conversation on how and where to place GameObjects that will run the Battle System scripts. Before this even gets into non-AGM Godot APIs and GDScript options.

---

1. GDScript can force multiple GameScenes into the SceneTree. Not recommeded. ↩︎

2. This English terminology is confusing, but par for Godot. Which turns the word “scene” into mush from overuse. Visual Layers, Collision Layers, Physics Layers, GameScene Layers, CanvasLayers, Z-Index layers… ↩︎

3. Godot Camera2Ds are a little weird in function. The game Window can’t actually move about the 2D game world. So the Viewport kind is slid around (transformed), based on the camera’s World2D position. Take two sheets of paper, hold one above the other. Your eyes are the game Window. Move the bottom sheet around, that’s the Camera2D moving the Viewport about. The top sheet is a Godot CanvasLayer node that is not following the Viewport. ↩︎

4. There are Godot _process , _input, and other SceneTree execution implications to a GameScene being below the SceneMenus, by tree order. That could cause unexpected edge cases. I haven’t had time to test them as of this post. If you’ve understood SceneTree, you’ll understand the _process order down the tree, and _input up it. ↩︎