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 multipleGameScene
. This conflicts with Godot composite game design principles. - 1.0.7: There is no Visual Script
Action
to transition to a specificGameScene
. This must be manipulated through SceneTransition LinksIs Change Switch Variable
, and aProjectSwitch
orProjectVariable
.
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.
GDScript can force multiple
GameScenes
into the SceneTree. Not recommeded. ↩︎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… ↩︎
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’sWorld2D
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 GodotCanvasLayer
node that is not following the Viewport. ↩︎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. ↩︎