Continuing with A*

Continuing on from my last post, Further Implementing A*, I have continued to refine its implementation into the game.

I have now got units following the path given to them, with the path being fixed upon starting movement. The unit will now appear at the end of the path, moving to each position, currently instantaneously, so there is no visual representation of movement displayed. 

Units now have a movement limit. While a path can be drawn across the grid, the unit will only move as many spaces as its move limit allows it to.

I am still having issues with diagonal movement. I believe that I will need to adjust the neighbours being found in the grid class, and the values being assigned for movement in the pathfinding class. While I have looked online for various solutions, e.g. Stack Overflows answers (A star algorithm without diagonal movement) but so far have been unable to find anything that I can grasp and adapt to my current code.

Now that I have the units moving along their given path, I feel I have a couple of choices on how to progress:

• Continue with the pathfinding
• Pros
• Attempt to remove diagonal movement
• Create visualisation of unit paths and movement
• Cons
• Been previously delayed by pathfinding issues, do not want to repeat
• Could cause further delays in timeline

• Implement AI
• Pros
• Get back on track with timeline
• Potentially make progress on a personally worrying aspect of the project
• A fresh aspect of the project to break me away from pathfinding
• Cons
• Would need to refine later down the road once weaponry have been implemented

• Implement weaponry and inventory
• Pros
• A fresh aspect of the project to break me away from pathfinding
• Ready for AI implementation
• Cons
• Takes focus away from other key areas of the project

I believe, when broken down, my best bet would be to look towards weaponry implementation now. I add " A fresh aspect of the project to break me away from pathfinding" as a pro, as I believe that if I focus too much time and effort into this singular aspect, a mountain will be made out of a molehill, and I will be less and less inclined to work on the project out of fear/panic. 

By shifting away from pathfinding, even if it's for just one week, I will be able to approach it again from a fresh angle, that will aid me in finalising it. While there are still more Pros leaning towards AI implementation, I feel the extra work that would be required later down the road, to alter the AI to work with weaponry, is completely unneeded extra work. 

Should I implement weaponry now, shifting the Rock-Paper-Scissor system over onto that, I will be able to focus much more heavily on the AI, without having to overhaul it later on. While it does throw off the order of my timeline, I should be able to end up in the same position as I would be following my current order, whereas I worry that AI implementation or continuing pathfinding will delay me further.

Week	Timeline	New Timeline Milestones
15	Refine the RPS system, and introduce weapons that break away from the base system	Implement what I have learnt about A* into the current build of the game, so player units move using the A* pathfinding
16	Refine AI within the game, so they can intelligently attack units based on position and weapon	Ensure that the A* pathfinding is correctly implemented, and look to implementing terrain modifiers within the map
17	Continue to refine AI	Research further and implement AI into the game, ideally with refined goal-seeking mechanics
18	Implement an inventory system, allowing units to equip different weapons, and the use of a health potion item	Ensure the AI is functioning to an optimal level, able to seek out the most efficient target
19	Look into a levelling system, and how this can be implemented	Implement a weapons system to take on the RPS system
20	Implement the levelling system, and start refining stats mechanics	Ensure the weapons system functions correctly, and research into levelling mechanics

Easter Break	Refine the unique support concept, creating a document outlining the mechanic, and its uses	Refine the unique support concept, creating a document outlining the mechanic, and its uses
Easter Break	Continue to refine the support mechanic, and start implementation if possible	Continue to refine the support mechanic, and start implementation if possible
21	Ensure the AI, movement, levelling, and combat mechanics are operating as desired	Finalise support mechanic implementation, and refine stats for combat mechanics
22	Start looking into a mobile conversion, and implement if possible	Ensure that any map modifiers are functioning correctly, and AI is functioning efficiently
23	Start or continue to implement mobile conversion	Look to start moible conversion
24	Finalise mobile conversion	Finalise mobile conversion

Further Implementing A*

Following on from my earlier post; A* Pathfinding, I have now started to implement the A* pathfinding I have learnt into the core of the game, but have reached small snags up to this point.

I have now got a visible grid being instantiated along with the node points, with both node and tile having each other as variables. I have been able to tweak and apply GameManager.cs into the A* build. Units are spawning, and can be moved around the map, as they could with the original pathfinding.

The mouse can now operate as the target position; Once the player starts to move a unit, the target transform will go to any tile moused over, with the path being painted in the scene editor via the use of gizmo's.

One issue so far, is the order of movement. At this time, when a unit goes to move, rather than going from seeker position to target, the unit appears at the target, and moves back to its original position. Rather than following along the path square-by-square, the unit continues to shoot immediately to the destined position. This is one major aspect I believe must be locked down, as it is the biggest impediment at the current time.

As a more minor issue, I am struggling to have the tiles change colour to create a visible path line to the player in the game, rather than just the scene manager.

My next steps will be:

• Ensure a unit is travelling to the end target
• The unit moves square by square, instead of travelling as the crow flies
• Basic visual movement feedback for the player

Basic Design Components

In my rush to start coding my SRPG mission, I overlooked basic design aspects, so, on recommendation from the feedback received for the presentation, I will use this post to outline these aspects, to help create a clearer picture on what exactly the SRPG mission will be.

Set-up
The player is presented with a grid-based map. Two groups of units will be visible; player units, and enemy AI units.

Objective
The objective of the mission is to defeat the enemy team.

Rounds
The player will play through the mission in rounds. In the first round, the player will be able to move and attack with all their units, in any order. Once the player has finished their movement, the AI units will then move and attack. Once the AI has finished, the round will end, and the next round will start. This continues until only one team remains.

Unit Actions
Every unit can move, and attack, on their turn. Between these two actions, the player will also be able to access and use that units inventory only once per turn. Otherwise, the unit will be able to move, and if in position to, attack. Once the attack has been completed, the units turn will end.

Movement
The player will be able to move a unit a number of spaces less than or equals to their movement limit.

Combat
The player will be able to use a unit to attack an enemy unit, once they have moved a unit adjacent.

Stats
Every unit has a collection of stats, that effect their combat capabilities

Strength
Effects the units basic damage output.

Defence
Effects how much damage can be absorbed before health is effected.

Accuracy
Effects the chance of the units hit landing.

Health
How healthy the unit is. If health reaches 0, the unit is dead.

Damage Roll
Effects the units damage output, by essentially rolling an x sided dice to apply bonus damage.

A* Pathfinding

Following on from my previous post, Moving On, I have started to look into an A* Pathfinding Algorithm. To help me get to grips with it, I have replicated an A* algorithm tutorial from YouTube; Sebastian Lague's first 3 Unity Pathfinding Tutorial videos.
 Through this, I have managed to replicate the A* demonstrated, fully commenting all code used, to show my understanding of what I have replicated.

This has given me a great start into A*, but the code I have replicated will need to be heavily modified, as there are parts of it that do not operate or fit the design envisioned for the final artifact. This will include:

• Removing any diagonal movement
• Diagonal movement is rarely to ever seen in SRPGs, so keeping to standard style, I need to remove any diagonal movement, and have the pathfinding working through vertical and horizontal movement
• Mouse tracks target node
• Rather than having a target node set for the target position, I intended to have the mouse be able to move among squares, changing the target point. In consideration towards the code already implemented, it may be an idea to have the mouse position set as the seeker, and the unit moving as the target
• Have a grid matching the nodes
• I wish to implement the grid style created for the original build of my game, so players can still be given basic visual feedback in the movements and choices.

Along with this, I have now had my presentation to explain to lecturers where I am with the project. Following this, I have been recommended to go back to the design, and outline the basic components of my game, e.g. defining what a turn is. This will be my next major step, before pushing onto the A* implementation.

Moving On

On Thursday 4th February, I had a meeting with one of my lecturers, Chris Jane, to discuss the issues I've had with movement, and about the upcoming presentation that will be presented on Monday 8th February. This presentation will be an update of my work to the lecturers of the course. I will discuss what has gone well the project so far, what has gone awry, and what my next steps should be.

While I had intended to overcome the foreach loop I was struggling with, as mentioned in my last post, Further Movement Issues, and wrap up basic AI, I was recommended to move past those, and start implementing the A* Pathfinding Algorithm into my project. While I did some light research into into it at the beginning of the project, I still have yet to wrap my head fully around it.

My next step will be to conduct further research into A* Pathfinding, and attempt to grasp the basics of it. This will hopefully be implemented into the project with a couple of weeks at the most. Following this, I will prepare for my presentation, which will include a revised timeline for the project, as I feel there are aspects of the project that were not prioritized correctly, and as I have fallen behind by a couple weeks, will need to be re-ordered.