A small RPG demo project using tactical grid battles and advanced gameplay mechanics.

In this game the player commands an army of survivors through multiple missions, recruit new survivors and upgrade facilities in the base of operations (our good old town scene). Missions are selected on a mission map when leaving the base and are unlocked on the mission path as you advance.

There’ll be no detailed tutorials for this project, as it’s meant to be tested and explored on your own. You can find some explanations on different features (and where to find them in the project) further down below.

This project is based on the Demo Project (the result of the game tutorials) and uses both ORK Framework and Makinom, as well as the connection plugin.

Download the Mission Grid Battles project for Unity 5.6, 2017 or 2018. After downloading, extract it and open the project in the Unity editor – this isn’t a .unitypackage file to be imported into a project, it’s a complete Unity project.

 

Download Project Unity 5.6

Download Project Unity 2017

Download Project Unity 2018

The Mission Grid Battles project was created in colaboration with Kevin Zhang from Dead Monarchy Studios to showcase how ORK can be utilized in tactical grid battles.

The following isn’t an in-depth tutorial, just a short explanation and where you can find the setup in the project. In case you’re looking for detailed tutorials, I’d recommend checking out the game tutorials (especially when just starting with ORK Framework) and the grid battle tutorials. If you’ve got questions about this project, join the discussion in the community forum.

Features

Some of the general gameplay mechanics:

  • Non-battle player
    The player (the general of the survivors) isn’t part of the battle group and can’t be used in battles.
    This mechanic is e.g. useful for games like Pokemon, where you control someone who isn’t fighting in battles.
    Check out the startEvent game event to see how this is achieved.
  • Passing days
    An in-game day mechanic is tied to multiple systems, e.g. the game’s progression.
    Different things can happen on each new day.
    Learn more about this below.
  • Research
    Battle loot mainly consists of artefacts, that can be researched to create new weapons.
    Facilities in the base can be upgraded to reduce costs for recruitment and research duration.
  • Random names
    The combatants (player and enemy) generate a random name using text files and Makinom.
    The names are a combination of randomly selected first and last name of various real world pirate captains!
  • Recruitment
    Combatants can be recruited by purchasing them in a shop.
    Some might even join you on their own when a new day starts.
  • Wage
    The player’s combatants expect to be paid for their hard work, reducing the player’s gold each day.

Some of the battle gameplay mechanics:

  • Phase battle system
    Each faction fighting in a battle selects and performs actions in their own phase.
    The player can freely select the order in which combatants perform an action.
    You can learn more about phase battles in this how-to.
  • Battle grids
    Battles take place on grids, where combatants need to move on the grid to get into use range of attacks an abilities.
    You can learn more about battle grids in this how-to and this gameplay tutorial series.
  • Attacks of opportunity
    Moving past a combatant of an enemy faction can cause them to attack the mover, interrupting the move when landing an attack.
    Learn more about this below.
  • Grid formations
    Enemies form formations and attack the player with a united front.
    The player can also use formations and gain boosting status effects by moving everyone into their positions.
    Learn more about this below.
  • No battle menu
    The player doesn’t use a battle menu to select actions, using only the shortcut slot system instead.
    Learn more about this below.
  • Loot item box
    The loot gained in battle is stored in an item box and can be retrieved when returning to the base after a mission.

General gameplay mechanics

Here are details on some of the general gameplay mechanics used in this project.

Game controls

The game is mostly controlled by mouse input, both player/camera controls as well as the UI are set up to utilize mouse input/movement. In battles, you can pan the camera by moving the cursor to the edge of the screen.

Battles don’t use a battle menu and require input via the shortcut slot system – actions can be activated by either clicking on a displayed slot in the HUD or pressing the according input key (1-9 and 0). You can end the turn of a combatant by pressing space and switch between targets (during target selection) by pressing Tab.

The rest of the controls are the same as in the demo project (game tutorials), i.e. you can also use the arrow keys to navigate menus, use accept (enter) and cancel keys (right control). A menu screen for inspecting the group’s status, read mission logs and bestiary entries can be called using the menu key (escape).

Base of operations

The base of operations offers different NPCs to access the facilities – some facilities can be upgraded via the research system.

Facility upgrades are done using passive abilities on the general combatant (i.e. the actual player that isn’t participating in battle). Each upgrade gives the corresponding ability a level up. The level of facilities that can be upgraded is visible by the number of cubes behind the NPC, each upgrade adds another cube.

Here’s a list of available facilities/NPCs:

  • Survivor Recruitment (Yellow NPC)
    Used to recruit new survivors for your ranks by purchasing them in a shop.
    Upgrading this facility will reduce costs for recruitment.
  • Upgrade Survivors (Red NPC)
    Used to change the equipment of survivors.
  • Upgrade Facilities (Blue NPC)
    Used to research facilitiy upgrades.
  • Research Projects (Green NPC)
    Used to start researching found artefacts to receive new weapons.
    Upgrading this facility will reduce research durations.
  • Supplies Management (Purple NPC)
    Used to see all available equipment as well as currently active research projects.
    Equipment can directly be equipped as well as research projects cancelled.

Missions

You can embark on missions by leaving the base of operations, which opens a mission select scene (where you can also return to the base of operations). Clicking on one of the missions (the spheres in the mission map) will prompt the player to start the mission and, if accepted, opens a group menu to select which survivors should take part.

Going on a mission will reduce the stamina of all participating survivors at the end of the mission. The game doesn’t feature any items to restore health or stamina, the player needs to manage who to take on a mission to ensure they survive the encounters. Health and stamina is restored by 10 each new day.

The goal of each mission is to reach the end of the mission scene, which usually requires to fight against enemies. You can go on the same mission multiple times, but enemies only respawn after 5 in-game days.

Passing days

You can only go on one mission per day – after returning from a mission (either by reaching the end or aborting it by leaving through the mission entrance), the exit of the base is blocked by a gate (cube). You don’t have to go on missions, though, i.e. you can start a new day whenever you want (in the base).

You can still use all facilities of the base, but you need to end the current day by clicking on End Day in the HUD (lower left corner) to start a new day.

The newDay game event handles what happens when a new day starts, it’s used via a global event (World > Global Events in the ORK editor). The event itself also uses other global events to perform sub-tasks that happen each day. The global event is called through a click action in the Days HUD (Menus > HUDs).

The following things happen on a new day:

  • Wage is paid
    The wage for all survivors that are in the player group will be removed from the player’s gold.
  • Recovery
    All survivors will receive 10 HP and 10 Stamina, i.e. if they’re badly hurt, you might want to let them rest for a few days.
  • New survivors to recruit
    The survivor recruitment will receive new recruits until there are 10 available again. This is handled by the updateSurvivorRecruitement game event.
  • Research duration
    Research durations are in in-game days, i.e. the duration is set to Manual mode and each new day reduces all active research durations by 1.
  • Daily event
    An event happens each day, you either receive a new survivor, a specialist survivor (a more powerful combatant) or the base is under attack (starting a battle). This is handled by the dailyEvent game event.

Random combatant names

The combatants use the Init Game Event setting to perform the setRandomName game event whenever a combatant is initialized. This event starts a Makinom machine and set’s the combatant’s name (the combatant is available via the action selected data key).

The Makinom machine performs the generateRandomName schematic, which loads first names and last names from text files into string variable lists and generates a random name by combining a randomly selected value from those lists. Finally, it sets an ORK variable (which is used in the ORK game event to set the combatant’s name).

Battle gameplay mechanics

The general battle mechanics using phase battles and battle grids has already been discussed elsewhere, so in this section we’ll focus on some unique mechanics.

Battle UI

The player doesn’t select actions via the battle menu an uses the shortcut slot system and control maps instead. The battle menu is stopped from opening by disabling Auto Call Menu in Battle System > Phase Battles (or whatever other battle system type you’re using) and not use an input key to call the menu (i.e. using the None input key, if you don’t have one in your project, I’d highly recommend adding one to disable inputs where they’re not needed). The available shortcuts are displayd by a Latest Turn HUD, which shows the currently selecting combatant (only for the player group), see the Turn Combatant Shortcuts HUD setup for details (in Menus > HUDs).

The grid move selection is always active during action selection, i.e. you can just one-click move somewhere. This is enabled by selecting Always in phase battle’s Player Auto Grid Move setting (Grid Settings in Battle System > Phase Battles). Clicking on one of the shortcuts (or pressing the corresponding input key) will activate the target selection (or directly use the ability if it doesn’t require target selectin, e.g. calling a formation), a 2nd click/press will cancel the target selection.

The HUD also shows the currently equipped weapon of the combatant – clicking on it opens a weapon list and allows changing the weapon on the fly. Since abilities are gained through weapons (i.e. Equipment Abilities set up in Inventory > Weapons), this is an easy way to change the actions that are available to the combatant. See the Turn Combatant Info HUD setup for details.

The shortcut slots are automatically filled with newly added abilities (and remove abilities that are lost), this is set up in Menus > Shortcut Settings in the Default Auto Add Slots and Default Auto Arrange Slots settings (the Default Shortcut Assignments settings handle adding shortcuts for base actions like the attack, rotate, move and end turn commands).

There are also virtual controls (using a Control HUD) on the top right corner to rotate and zoom the camera. A battle log is displayed in the lower right corner, using a Console HUD (see Battle Log HUD setup) and the settings defined in Game > Console Settings.

Attack of opportunity

As stated above, an attack of opportunity (AOO for short) can occur when a combatant moves past a combatant of an enemy faction, i.e. moving over a cell in attack range of an enemy. If the enemy’s attack hits the combatant, the move is interrupted and the combatant stays on that cell. This mechanic is added in the gridMoveCommand battle event, which is used by the Move Command set up in Battle System > Battle Grid Settings.

The AOO itself is set up in the AOOPerformMoveBy battle event, which is called by the gridMoveCommand battle event via a Call Battle Event node. The grid move battle event will search for all enemies of the user and store them into a found objects list (using a Search Combatants node). The AOO battle event is called twice in the grid move battle event, before the first move to a new cell (for cases where a combatant moves away from an enemy) and as part of the grid path loop (i.e. moving from cell to cell).

The AOO battle event uses a Grid Move Out Of Range node to find all enemies (from the previously found enemies), the user will move away from on the next cell. The attack itself is started as a Sub Action of the grid move action by using an Use Battle Action node. A sub action will be performed as part of the current action of the battle event and not be part of ORK’s action queue, i.e. it’s not part of any turn/action order and doesn’t disrupt the battle.

There’s also a 2nd AOO mechanic implemented, which is available to the player by equipping an AOO Sword or AOO Sword 2. Instead of attacking enemies that are passing by, this AOO targets enemies that stop in attack range (e.g. when moving directly to the enemy). This is done by additional battle events used before and after the gridMoveCommand battle event and are set up in the Move Command settings as well.

The AOOCheckMoveInRange battle event is used before the grid move battle event and searches for all enemies with AOO status effects applied (which are auto effects when one of the AOO swords is equipped). The found enemies are again filtered by a Grid Move Out Of Range node, but this time it checks for moving into range with the last cell of the path.

The AOOPerformMoveInRange battle event is used after the grid move battle event and lets all previously found enemies that are in attack range attack the user via a Use Battle Action node (again, as a Sub Action).

I’d recommend to check out the battle events to see the setup in detail, as there are also other things involved (e.g. a chance check to limit the times of attacks).

Grid formations

Grid formations are set up in Battle System > Grid Formations and can used by both the enemy and the player. The enemy’s battle AI will use a formation and move into their formation positions – the leader will only move after the formation was finished and waits for the others to move into formation again.

The player can use a formation via an ability, the combatant that used the ability will be the leader of the formation. Moving all combatants on cells that are part of the formation (i.e. finishing the formation) will grant boosting status effects to all members. The player can move the combatants on any cell that are part of the formation and they’ll use that cell as their position, i.e. the player doesn’t need to mind moving on specific positions in the formation.

Updating the formation is done at the end of the gridMoveCommand battle event, which is used to perform grid movement.

Loot

The battle loot isn’t immediately added to the player’s inventory and put into an item box instead. This is done in the gridVictoryBattleEnd battle end event in the Collect Battle Gains node, where it shows the battle gains and adds the loot into the missionGains item box (ID).

The item box doesn’t need to be in the scene, as it’s identified via it’s item box ID and can be accessed via the event system at any time. However, to actually open an item collector and let the player take things out of the item box, it needs to be added to a scene – which is done in the base of operations after returning from a mission.

The item box is opened automatically when returning from a mission, if there’s something in the item box. The item box is placed in the base scene (1 Town, see the Mission Gains Item Box game object) as an Item Collector with the start type None (to only start it via an event)

The item box is opened in the backToMainBase game event with a Start Item Collector node, after checking if there are items in the box and finding the game object with the item box. Afterwards the event checks if researchable artefacts are in the player’s inventory and adds the corresponding research tree (and removes the artefact from the inventory).