Arvutigraafika projekt 2019/20 sügis

• Model 2 types of units (one for melee and one for ranged types). For starters, the difference will be in color.
• Animate the units. Most animations will be the same (since the models are almost identical) with the exception of the attack animation
• Read about turn-based games and how to implement them in Unreal Engine (previous experience with Dungeon Domain should be of help)

Milestone 1 report

I have reviewed the materials regarding modelling, animating and exporting materials in Blender and porting them to Unreal Engine 4 (links later in the report). I have finished with the initial modelling process of the units:

• I will be using a single model (for now) for both of the unit types
• Model is rigged and weights were manually assigned to all bones.
• Their difference will only be in color (still to be implemented, was outside of scope)
• Both models have the same animation sets (movement, attack, death as seen on the animations below). The only difference will be that "close combat" unit will be using the punching animation whereas the ranged one will be using the shooting one (with the small recoil pattern)
• I have created a model for a firearm to be used by the ranged units. Currently, there is no "joint" animation, that will be done in Unreal Engine directly (I will simply attach the gun to the appropriate model).

Surprisingly, there is not much information about turn-based games on Unreal Engine forums. While the initial analysis was fruitful in regard that now I know there will be a lot of further research on-spot, I still found some tutorials on how to make a chess-like game setup. Additionally, I looked into some sample AI combat mechanics, to get a grasp of how to implement the core element of the game.

Something that spiked my interest was Advanced Turn Based Toolkit, which could be used for the preparation phase as well as combat phase. However, its price makes it not worth it.

Used Materials:

• How to Animate in Blender
• Blender to UE4 Animation Pipeline
• Quick Character Rigging in Blender: Animation Tutorial
• Blender to Unreal Engine 4 Basics 004 - Basic Animations Setup
• Create Multiple Animations in Blender and Import into Unity
• weight painting/skinning | tutorial | Blender | Quick
• UE4 Simple Turn Based Strategy (prototype)
• Turn-Based RPG Template Documentation
• Turn-Based RPG Template
• Unreal Engine 4 - Turn Based Strategy - Blueprint Tutorial [ITA] - -7: "Grid for movement" - 1/...
• Unreal Engine 4 - Turn Based Strategy - Tutorial [ITA] - 0#: "Create Project
• Unreal Engine 4 Tutorial #1 - Start Chess (part 1)
• Making a JRPG - thoughts and where to start?
• Unreal Engine 4 Simple AI Allies And Enemies Fight System Without Behavior Tree
• AI and Behavior Trees
• Red Blob Games - Hexagonal Grids
• Reddit - how to make turn based RPG combat

Weapon intended for ranged units

Demo version of a ranged unit

Melee, ranged (shooting), walking and death animations

• Finish the textures for unit models
• Build "map"/game area layout without any functionality yet

 ** optionally attempt to implement grid snapping, similar to this

• Reading about HUD and how to implement it (will be necessary for displaying the key game information.

Milestone 2 results\report

• Due to hardware issues I had trouble making the textures as I wanted to have them and had to resolve to "minimalistic" approach - blue characters being melee and purple being ranged. This color difference should be sufficient for distinguishing the units in-game.
• Imported the units into the project.
• Due to aforementioned issues with hardware, could not fully create a map.
  • Core map elements are done
  • "aesthetics" are not implemented
• For HUD and UI, i decided to settle on the "inventory-like" storage mechanic - the "shop pool" and "storage pool" will be rendered on HUD and will not be created on the map itself. Then, using Drag and Drop mechanics, player will be able to place the characters on the map.

->

• Implement UI
  • Implement Buying units and their placement mechanic
• Implement game loop (preparation phase, followed by action phase). No actual "actions" during action phase yet.
• Read about AI navigation and combat.
• optional create pawns for units

Milestone 3 results\report

• Game loop was implemented. The following diagram demonstrates the carcass of how the game loop should work:

• The main logic of game loop is triggered by Unreal Engine's events - when player presses "End Preparation" button on the HUD, HUD fires an event that is caught by Game Mode that handles this "start action phase" event (makes internal processing, fires its own event that will be listened to by all entities necessary, i.e. units). Game Mode also handles the action phase timer (currently set to 15 seconds for simplicity and speed reasons), however in an unoptimised way - by default Unreal Engine works with "ticks", which, in crudeness, correspond to a new frame being drawn. This creates a huge problem due to becoming a hardware-dependent application (if one's framerate is 15, the tick events are fired way less often than, let's say, for one with framerate of 60 or 144).
• After action phase timer is finished, Game Mode fires a global "action phase ended" event. HUD listens to this event and disabled the countdown timer, enables the "End Preparation" button.

• Implemented shop mechanics and placement.
  • Issues with collision mechanics - game will still spawn a unit even if another unit is placed on location
  • Shop is dependent on money - cannot buy if amount of Thrones (throne gelts, currency) is insufficient.
  • At the end of each action phase, a fixed amount of Thrones is added to the player.
• Last minute addition: managed to implement collision checks to apply on spawning. Now you cannot "buy" a unit if the default spawn location is obstructed (has another unit spawned).
• Countdown Timer With Game Over
• Unreal Engine User Guide - Event Ticks
• Why use event tick at all?
• UE4 - Creating a Timer
• HTF do I? Event Dispatchers in Unreal Engine 4

For AI in Unreal Engine:

• UE4 - Dynamic Combat System - Creating New AI
• Totally Unreal UE4 Tutorials

https://gfycat.com/HauntingBrightGrub

• Fix unit placement
• Enable unit rearrangement after placement.
• (optional) begin implementing the AI.

Milestone 4 results\report

Changed the spawning procedure so that, when spawning a unit, game checks for all existing units and sees if the spawn location is already "occupied". A better way would be to use collision overrides, but I could not get UE to handle those properly with skeletal meshes (works with standard actors and other objects, but not skeletal meshes). Implemented second "HUD" widget for "drag and drop" functionality. When unit is clicked (handled by the unit, seems easier to process "on click" events that way), it fires off an event to the widget that handles the transfer and snapping of attached unit. Player cannot place a unit on the same "tile", which is controlled by collision.

Player cannot spawn another unit if the spawn location is "occupied"

Player can move the units on their side only. Cannot "stack" units on the same tile

• Implement movement logic for units
• Implement combat logic for units
• (optional) find and fix issues with the implemented elements (if there are any)

Milestone 5 results\report

Implemented unit behavior using Unreal Engine's behavior trees (image below). This required a lot of fixes and a complete rework of unit architecture (now controlled by AI, not just a skeletal mesh). Now Unit is controlled by Character object, which is controlled by AIController, which is guided by Behavior Tree (via Tasks) which uses Blackboard. Fixed several game loop issues. Opponent's units are hard-coded for now. Implemented both melee and ranged unit mechanics - all units have "attack range" value, which affects how precisely close to the targeted opponent they need to come to in order to start attacking.

Unfixed issues:

• When game action phase ends, all units are reset to their initial positions. Issue is, sometimes they continue carrying on the last decision they made, ignoring the updated settings.
• Due to transition of unit architecture, all unit animations were gone.

• Fix animations for units
• Fix units logic resetting at the end of the action phase (90% will need external help)
• Add visuals for ease of use and understanding - NPC health bars, better texts for user action feedback (defeat notification, unit limitation notifications)
• Add Estonian translation (since I only have 5 texts, should be easy)
• optional add some SFX to unit actions

Milestone 6 results\report

• Managed to re-import old animations and rig them up. Currently implemented walking, hitting, shooting animations. Added hitting/shooting sounds to attack animations. Death animation just makes the unit invisible, plays the death sound, leaves the team colored "death mark" on the spot.
• Logic was fixed by replacing the condition mode from "result change" (which would try to finish the subtree as far as possible) to "on value change" (which would stop the subtree execution if the watched value is changed).
• Improved the UI (added wave counter, NPC HP bars, phase notifier, game over notifications)
• Estonian translation exists for the Robotex Expo version
• Improved AI navigation - AIs can walk through each other. It is easier to do it this way than to try and implement recalculation of path based on other AI positions and paths
• Added enemy "scalability" - enemy will get a new random unit each round
• hidden feature: can rearrange enemy units :D

Milestone 6 version of the Preparation Phase UI for the player

Milestone 6 version of the Game Over UI for the player, shows how many waves you have lasted

Red area highlights if the area you are trying to place the unit is already occupied

NPCs can walk through each other

When unit dies, it plays a death noise and leaves such mark on the map. The mark's color is team-dependent

Robotex 2019 results

Cons:

• Action phase duration felt too long (30s)
• Game over screen was not displayed properly
• Units would idle instead of attacking each other due to too strict Ai resetting policy

Pros:

• As there were multiple projects in the room, people still would visit the stand :D
• Visitors would play multiple rounds until defeat is achieved (would not abandon the game mid-round)
• Visitors did give verbal feedback (though were reluctant to do so in a written form)
• Visitors expressed interest in a more... fixed product, saying it would be interesting to try it out once it is done