Classes and Movement

Carrying on from my previous post, Running into Issues, and attempting to use debug, I have now

implemented a class system, that will change the base stats of the units, and how they interact with

other classes.

Movement has now been further refined. The player will click on the "Move" button, which will allow

the unit to move to any space on the map at this present moment. A unit can only move once per turn,

and can now attack units adjacent to themselves. Depending on the class of the current unit and 

opposing unit, modifiers may come into play, giving the current unit positive or negative accuracy and

attack modifiers.

Units now have an "Actions" limit, allowing them to perform two actions in one turn. 

All code relating to changes can be found below.

For my next step, I intend to:

• Look at creating a separate class for unit classes
• Have AI units moving next to, and attacking player units
• Adding a movement limit.

Running into Issues, and attempting to use debug

Following on from my previous post; Map Implementation, I have continued to follow YouTube user Paul Metcalf's tutorial, Unity3D Simple Tactics Turn Based Game Creation Tutorial Part 2: Combat .

I will be posting commented code upon completing this part of the tutorial, this post is intended to highlight an issue I ran into, and how I attempted to fix it.

Relating back to the code in Map Implementation, two booleans were added to the Player class:

These booleans were added, so that the current unit would know if it was in a state ready for movement, or combat. The movement formerly added will now function only if the moving boolean is true. This was done through the Move function in the UserPlayer class:

The Move function was then set to a UI Button:

 As seen in the snippet of code above, if moving is false (represented by "!moving"), moving should be set to true when the function is run.

When the game was run with the above settings, I could not get the current unit moving. I could not understand this at all, so tried a few different fixes to see if I could progress.

Coding Fixes
To begin with, I attempted to change the code slightly, adding a debug log, changing variables, attempting to call the player in different manners. These are all shown below; this is within the Move function in the Userplayer class.

Having tried all of the above, I decided to take another approach:

Debug Mode
Though I have not formally used it before, I decided to attempt to use the debug functions within MonoDevelop, to see if this would help me find the answers to my problems:

I set the debug to start running once the if statement was activated.

Once the function had started, moving is definitely set to false, before it has attempted to switch to true.

Once the function has moved passed "moving = true", it is evident that moving is now set to true.

Yet, regardless of the above, moving on the current unit was still set to false.

At this point, I turned to my lecturer Chris for hopefully a hint. After a brief look at it, he brought to my attention where I was telling the button to get the Move function from; a unit prefab that was in the scene, unrelated to the loaded game.

This meant that I would have to relocate the button functions to an object that was always in the scene, such as the GameManager. So after a quick tweak, I made the change:

Now, the draw on the players list, calling on the current unit moving via the currentPlayerIndex int, and changing the variables through that method.

In hindsight, it was a silly mistake to make; I had believed for some reason I was assigning the button to the player prefab as a type, rather than as a singular game object. Once I realised the mistake, it was a simple fix, but I believe I have gained useful experience from this;

• Pay attention to what objects are being assigned, and make sure to check if it is the object, or object type, being assigned.
• The debug log is a helpful tool, for breaking down functions one step at a time, allowing me to view what the function is doing at every point it runs.
• If in doubt when trying to run a function off a prefab, move the function into a constant class, and try it with external access to the base class it's effecting.

Map Implementation

With my final project, one of the aspects I wanted to get out the way was the map. I had planned to do this using the aid of a blog run by Red Blob Games. While I have referenced only the Introduction to A*, I will be using the majority of the blog, starting with a post on Grids and Graphs, and, as the majority of work shown on the blog is Python based, an accompanying A* Implementation guide.

Having taken some time to go over what has been covered in Grids and Graphs, I was concerned that I had proverbially jumped into the deep end. To help me get my groundings again, I decided to look towards YouTube for tutorials that may aid me in map creation. I quickly came across the video Unity3D Simple Tactics Turn Based Game Creation Tutorial by user Paul Metcalf. This tutorial is the first in a seven part series on created a turn based tactics game. I believe this series could help me implement early elements into my game, while allowing me to gain a greater understanding of the code I am working with.

I have followed through the first tutorial, which focuses on creating a grid-based map, and implements a basic movement mechanic

The map, created through a grid, and two player units

At this point, I can now create a square, grid-based map, that can have the width and length set. At this point in time, they use the same number, so will always come out as a square. There are also two player units that spawn on the map, one in the first square available, the other in the last. The game sets the player in the first square as the first player unit; the player can click on a square, and the unit will move towards that square. Once the unit has moved onto the square, it becomes the next units turn, who can do the same.

Below, I have the code I have used fully commented.
This is NOT my own code. All code was taken from the YouTube tutorial above unless stated otherwise in the comments. I have commented all code to both show my understanding of the code and tutorial, and further refine my coding knowledge as a whole.

GameManager.cs
The GameManager class is attached to an empty object in the game, that in this case also holds the lighting and camera as children.

Tile.cs
The Tile class is attached to the square prefab, so that every position on the grid has the Tile class attached.

Player.cs
The Player class is not set to any object, instead, the UserPlayer class uses it as a parent class.

UserPlayer.cs
The UserPlayer class is attached to the UserPlayer prefab, allowing any player to move available player units.

One of the main issues I have with this code at the moment, is that while a unit is moving, it is possible to select another tile to move, with the units turn not stopping until they have reached a destination tile. I have overlooked this for now, as I intend to implement higher level coding and pathfinding still.

From what I have done here, there are personal tweaks I am looking at implementing. These include:

• Disallowing two units on the same space
• Stopping mid-movement destination tile changes

My next steps though will be to focus on the implementation of classes, and a working Rock-Paper-Scissor combat system.

Second Lecturer Meeting

                One Monday I had another meeting with my lecturer, Chris Janes, to continue discussing how I should be tackling my final project.

                I have now been advised that, due to my project being centred on coding, I should create minimum, medium, and maximum milestones:

·         The minimum target should be achievable by December / January, but will be the minimum level of work put into the project should time estimates go askew.

·         The medium target is what I should be aiming for by May. This will include all aspects covered by the minimum target, while further expanding on those aspects, possibly seeing extra elements added.

·         The maximum target is what I would ideally like created by the end of the final project. These are goals more aimed at being implemented if I end up under-scoping the medium targets. This doesn’t mean that I should not aim for these goals. These instead will be goals that I will have to push for, but must take into account that I may not get all goals in this criteria completed.

So far, these are the targets I ideally plan to aim for:

·       Minimum

o   Targets

§  A single-level, grid-based map, with no modifiers

§  Have simple stats implemented for units

·         This will include:

o   Health

§  When a unit runs out of health, they die

o   Strength

§  Affects how hard a unit can hit

o   Defence

§  Affects how much damage will be negated

o   Speed

§  Affects the hit rate of units

o   Movement

§  How many spaces a unit can move

§  3 Player units, each with a unique class

§  3 Enemy units, each with a unique class

·         Rather than completely unique classes, these will be the same classes used by the player characters, but with modified stats

§  Basic AI that can approach and attack player units

§  Have the rock-paper-scissors system implemented

·         This is what the classes will be based around. One class is “rock”, one “paper”, one “scissors”. I would consider the system “in place” when it is clear that “rock” will always beat “scissors”, and so on.

§  Multiple options at the end of movement

·         When a unit has completed movement, a small menu will pop-up, giving the player a list of options to choose from.

·         E.g. if the player unit stops next to an enemy, they will be given the options “Attack” or “Wait”.

These are the key targets I will be aiming to have within my minimum target. I believe that I will be able to hit these targets by the end of January, if not earlier. I believe that the grid-based movement is going to be my biggest issue at this point, but should be simple to implement once I have my head fully around it.

·         I believe, from previous experience with C#, that implementing the classes will not be a difficult task, rather balancing the numbers for combat, as I will want to make sure that a unit with class X will draw with X, be able to beat Y, but will lose to Z.

o   One of my recommended early tasks is to create the classes first, and have this grounded as one of my starting points, as the main focus of this final project is the combat.

o   I envision this as a simple 2 x 1 grid, a player unit, and an enemy unit. The player will be able to cycle through classes for both their unit and the enemy unit. On their turn, the player will be able to engage with the enemy, and vice versa. Should a unit die, they will respawn on the next turn.

Enemy

Player

o   As I will be balancing numbers a lot, I believe this could become a helpful tool for the development of my project.

·         One aspect I am unsure about is the grid-based movement. While this was covered to a degree using node-based movement in the second year of the course, I will need further research into grid-based movement.

·         I have concerns about the enemy AI. Not so much in getting them to engage in combat, and more again about movement; making sure they are moving correctly, and attacking within the limits given to them.

·         While I do not believe that stat implementation will be overly difficult, use of the speed stat will have to be balanced carefully.

o   The base concept for the speed stat is; the difference between two units speed stats will determine the percentage chance of landing the hit.

o   I am unclear on the use of percentage, so this will require further research into the implementation of percentage chance, but this will aid me later in my medium targets.

o   Constraints

§  No weapons or external items

·         While I do want to include items and weapons into the game, I would much rather make sure that the base combat mechanics are working before adding modifiers onto them.

§  Prefab objects only

·         As the core of my project focuses on coding, there is no need for me to worry about creating models for this project. Instead, I will use simple prefabs to represent objects in the game.

§  Simple map design

·         As, again, I am focusing on code, I do not want to worry about an overly complicated map at this time. My current thoughts are two land masses, separated by a river, and two bridges.

An example of how the grid may be laid out.

§  No narrative, dialogue, or story

·         Keeping focus again on the code, I will not be fleshing the game world out in any way past naming the three classes.

·       Medium

o   Targets

§  A multi-level, grid-based map with one kind of extra modifier

·         The map designed for the medium target will have two levels to it, with a bonus being given to any unit that attacks someone on a lower level, and a negative for any unit attacking someone on a higher level.

·         I will also be implementing a basic modifier square that will appear multiple times, and imparts the modifier when the unit is on that square. E.g. a square that represents a forest increases speed by 3

§  3 Player units, each with a unique class

§  5 Enemy units, each with one of three classes

§  Have weapons implemented

·         Weapons within the game will create the base damage stat in the game, with the strength stat modifying how much damage is done, and the opposing defence stat reducing this.

§  Have the rock-paper-scissors system implemented through weapons

·         Rather than having the RPS system focusing on the class of units, it will be implemented into the weapon types used by those classes.

·         I will also be looking to include weapons that break this system, E.g. a weapon type X that is designed to have superior performance against weapon type X. This way, a dominant strategy, as discussed through previous readings, should become more difficult to create.

§  AI that can approach and attack player units, taking unit weapons and map modifiers into account

·         The AI will position themselves as best possible, taking into account any map modifiers they can use to their advantage, and will attack using the best weapon possible, depending on the unit they are engaging.

§  Have a form of health potion implemented

·         This will be some form of item a unit may use on their turn to restore health, instead of attacking.

§  Implement “Critical Hits” in combat

·         I want units to have a chance to perform a “critical hit” in the game; a strike that will do x2 or x3 base damage

·         A new stat, “skill” will be implemented with this, which will focus on improving critical hit chance.

·         This should allow players further freedom in creating a preferred strategy, by having weapons that focus on the use of critical hits, allowing a risk vs. reward strategy to form

§  Implement a levelling system

·         I need to have a system that allows player units to gain experience, and increase in strength via level ups.

·         XP will be rewarded for defeating enemies, but I have yet to decide on how stats will be altered

·         I have two concepts for the level up at this time:

o   Have percentage chances for stat increases, based off the class of the unit. E.g. a strength focused character will have a higher chance of increasing strength than health.

o   A Dungeons & Dragons style level up, where players are given a certain amount of points to put into stats, but the higher the stat is, the more points must be used to increase it. E.g. to increase strength from 1 to 10 costs one point per increase, 11 to 15 costs two points per increase, 16 to 20 three per increase, etc.

§  Implement a unique support mechanic

·         One key component I have drawn from my readings is the need for a unique mechanic. These seem commonly done through support mechanics in strategy RPGs, with a player further able to increase stats for their units.

o   Example 1: In Advance Wars: Dual Strike, players pick a commanding officer before every mission. This CO will give bonuses to certain types of units on the field.

o   Example 2: In Fire Emblem: Awakening, player units can be placed next to each other, allowing them to fight together in combat, or join as one unit, imparting large stat bonuses, with the ability to switch between the two joined units.

·         I am as yet unsure to what sort of mechanic I would implement at this point, requiring further research into unique mechanics employed by other strategy RPGs.

§  Further expanded options at the end of movement

·         Following on from the end of movement menu implemented in the minimum targets

·         The player will now be able to check their units’ inventory, equip a specific weapon, or use a health potion.

These are the key targets I will be aiming to have within my medium target, and realistically the minimum outcome I would like out of this project.

·         I am going to have to do a lot more research into enemy AI to achieve these goals, as I will want the enemy units to feel like much more of a threat to the player, creating dynamic gameplay that the player must keep adjusting to.

·         I will have to look further into how weapons can be implemented into the game, and how best to base the base combat stats around them. This will require research into how other strategy RPGs approach this.

·         The critical hit system is something I am still relatively unclear on, requiring me to look into other games use of critical hits, but the knowledge I gain from creating the hit chance through speed should feed into this; both will follow a percentage chance, with critical hit chance being at generally lower rates compared to hit chances.

·         The levelling system could prove an interesting challenge, depending on how I decide to progress with it, as percentage chances, as explained above, are unknown territories for me, so should I go with that method of levelling, it will push my skills that much further, whereas the Dungeons & Dragons style levelling system would be much easier to implement, from previous experience with in-game stats.

o   Constraints

§  No more than three items a unit

·         This limit applies to both enemy and player units. The player units will start with set items that demonstrate combat in various ways.

§  Prefab objects only

·         Once again, no focus on design, only on the coding aspects.

§  No narrative, dialogue, or story

·         See above.

§  Simple map design

·         See above. The map shall contain more than the minimum target map, to allow greater use of movement, and the surround terrain/modifiers.

·         This doesn’t mean I shall be creating a 30 x 30 map with multiple risen levels, and large areas of modifiers.

·         This instead will be a map that can demonstrate the use of risen levels, a small area that demonstrates the use of modifier squares, and limited amounts of design taken into account for bottlenecks, dead-ends, and other tactical aspects that tie into the combat.

·       Maximum

o   Targets

§  Alter the game so it is mobile-ready

·         One common requirement or desired skill I came across in the job search was experience on mobile games. Should I reach the maximum targets, I would prioritise getting the game on mobile as it will be one of the most beneficial aspects I would really like to include, but feel would be over-scoping should it be included with my medium targets.

§   A multi-level, grid-based map with three extra modifiers

§  Five Player units, each with a unique class

·         This will expand on the three base classes, adding two forms of ranged class into the game.

§  Twelve Enemy units, each with one of five classes

§  Further weapons available

·         This will include ranged weapons, both for previous types of weapons, and in the form of new weapons.

§  AI that can predict how a unit may move, can position themselves using this information, position to attack in groups, and make use of tactical bonuses (E.g. making use of a bridge as a bottleneck)

·         If possible, I would like to create much more advanced AI, that take all the above into consideration when moving.

§  Implement stat-modifying items

·         These will be items that are used for a one off stat boost, for X amount of turns, or X amount of battles.

§  Implement armour

·         Armour in strategy RPGs is uncommon, but I believe it could add a lot to customisation options for players, if implemented correctly.

·         This would affect the defence class, possibly even taking movement and speed into account too.

§  Implement class changes

·         A system that would allow players to not directly change their class, but level it up to a superior class, starting them at level 1 again.

·         The class improvement would give vast stats improvements immediately, and could potentially unlock a new kind of weapon available to the unit in question.

Should I be able to reach the point of hitting my maximum targets, I would definitely be prioritising getting the game mobile ready. This is the key target to me in my maximum targets, shortly followed by AI. The maximum targets feel a lot rougher than my minimum and medium targets, so may be altered as time goes by, but for the time being, I am happy with the targets I have set myself. My constraints will be the same as medium, but the item limit would be changed to six, from three.

Marking Criteria

                While I believe that further research may be required for a more complete set of marking criteria, this is what I have, though I feel I will need to definitely refine these further:

o   Quality of the AI implemented

o   How well the map contributes to tactical choices

o   Quality of the combat mechanics implemented

o   How much of an impact the unique support system has

Timeline

                I have yet to look into the timeline properly, as I believe I require further research, specifically into grid-based movement, to get a much better idea of the time periods I will require for research, and actual time spent coding. I hope to look into at least a couple of different methods, and attempt to re-create them, in order to get a feel for grid-based movement, and later create my own code to implement movement.

                Once I feel more comfortable with the grid-based movement, I will be looking at implementing basic combat, with a very simple AI that will just attack the player. Following on from that, I will be working towards my minimum goals, but my priorities to begin with are movement, combat, and AI. I will need to look into them before the proposal is complete, to create as accurate a timeline as possible.