Alpha Devlog

During the alpha phase my main goal was to get the battle system fully functioning and ready for testing later.

To do this I created 3 major scripts:
The game manager, which exists in every scene of the game and keeps track of data and game state between scenes.
The battle manager, which holds all the data for one battle and controls how the battle flows.
And the UI manager, which handles player input and relays it to the battle manager.

Within the battle manager I created a class, Fighter, that contains data for each participant in the battle, their ID, position, health, the move they current have selected, which moves are available to them, a path to which sprite they should use, etc.
I made a constructor function that takes in all this data, creates a new fighter object, and sets up all of the in-game objects needed for it.
I also made a function to add pre-defined fighters to the battle, using an enumerator to select between them.

because of all this, enemies and allies can be added to a battle with just these single function calls.

The skill options in the UI are organized using Godot's BoxContainer nodes.

This lets me add every possible option into the box, and show or hide them depending on if the fighter performing the action has those actions available. The BoxContainer automatically stacks the options vertically with no spaces no matter how many or few are present.

Every option has an inactive and an active sprite that I show and hide based on which item is selected.

Each fighter has a marker object on the timeline.
The markers move on their own (using speed data from the battle manager) until they reach a defined point on the timeline.
When they reach that point, they send a signal to the battle manager, along with their ID to tell it which fighter it is, and the battle manager will either show the UI for that fighter for the player to select an action, or refer to the AI's algorithm to select a target and an action.

If a fighter is attacked while they are casting, they are countered and sent back halfway through the "Wait" phase.
Once the marker reaches the end of the bar, the action that the player or AI selected is processed in the battle manager, and health and mana values are updated. 
After this the battle manager checks to see if any fighters have died, removed them from the battle, and then checks if the battle has ended (all enemies are gone, or the player is gone)
After the end of a battle, the battle manager tells the game manager to update the player's stats so it can be referenced in future battles.

Health and mana bars use the TextureProgressBar node. They use 4 different signals to recieve data from the battle manager, update hp and mp for both the player and ally. Whenever a move is performed, these signals are sent from the battle manager with the new values to update the bars.


Negotiations can now select between 3 random questions and use the proper formulas for calculating recruitment chances.
Questions can call the negotiator script to add a correct answer to the tally and to move on to the next question at the end.

After three questions the proceed() function will check the recruitment chance and randomly decide if the negotiation succeeds or fails.

The player and enemy sprites are displayed using the Y-Billboard mode, which keeps them facing the camera, but doesn't rotate them up or down.
Previously I was doing this through a custom script that kept the plane the sprite is on facing towards the camera, but this method is simpler and avoids issues with the player clipping through walls and floors.



I'm currently working on getting the dungeon overworld and puzzle into the game, and getting the transition between the overworld and battle scene to be consistent.
The materials I'm using on the greybox here are placeholders just to give a general idea of what the walls and floor are made of.