As it is now, turns are completely linear as if our units were all standing in line. In a tactics battle, things are a lot more complex. Units with a higher speed stat should be able to act more quickly in general, but other exceptions to the rule might exist. Final Fantasy Tactics for example would include status effects such as Haste, Slow, or even Stop. In this lesson we will create a new class to determine when each unit on the board gets to take a turn while keeping things flexible enough to account for all of these types of scenarios.
To fully select targets for an ability we need a few more steps. We began with specifying a Range. In this lesson we will implent a variety of Area Of Effect components which are applied based off the selection from the range. In addition, each ability may have multiple “effects” – each of which may specify a unique set of valid targets. I will provide a couple of implementations for these as well, so that we can have a completed targeting selection loop in place.
Abilities such as attacking or using magic are part of a large and complex system. In this lesson we will take the first step toward this implementation by providing several classes that can be used to control the range of any particular one.
We’ve been modifying stats for a while now, but it’s not very desirable to have to switch the inspector to debug mode just to see their values. In this lesson, we will go ahead and create a Stat Panel view, which shows an avatar along with his or her name and a few important stats. There will actually be two of these panels, one for the currently active (or selected) unit and a second for the target of an action.
In this lesson we will show how to define a variety of jobs and store their data as a project asset. Although we have done this before (with conversation assets), this time we will be creating prefabs programmatically. By choosing prefabs over scriptable objects, we have the ability to take advantage of components such as the features which we introduced in the previous lesson.
In this lesson we will begin adding Stats to our game. Experience and Level are particularly important stats, so we will begin by focusing on those and show how we might distribute experience between heroes in a party. As enough experience is gained, the level of the hero can also be incremented. Along the way I will also address how one system might create an exception-to-the-rule in another system and offer a solution on how to allow them to interract while keeping things as decoupled as possible.
In this post we will continue to flesh out the UI by adding the Ability Menu. This menu will allow the user to determine what phase of a turn is active- such as moving, attacking, etc. as well as what to do during a turn- such as what kind of skill to use during an attack. We will actually implement the menu where possible (Move), and anything we haven’t gotten to yet will use placeholder content (Attack, Magic etc). We will also see how to support canceling a move and be able to restore an earlier state.
This week we will implement the UI components from the previous lesson in a Conversation UI element which would appear as part of a cut-scene before and/or after battles. The panels will hold a little bit of text along with a sprite showing who is speaking. A bouncing arrow will indicate when there is more to read and using the input “Fire” event will cause the conversation to move on to the next message or the next character who will speak, etc. These panels can appear in any corner of the screen (which could indicate the direction of a speaking character relative to the player), and will animate in and out of the screen as needed.
The user interface (UI) is one of those areas you always end up spending a lot of time implementing, and every game needs one in some form or fashion. I have built up a variety of reusable libraries in the past, but with Unity’s new UI tools I find myself starting over again. If you’re like me, the anchor and pivot system provided by a RectTransform may have been a bit confusing. I like working with it pretty well in the inspector, because I can modify the anchors and pivot to any corner for easy placement. In code, it wasn’t quite as easy, so this lesson is dedicated to the creation of a few reusable components which will, hopefully, make all our lives easier for awhile.
Pathfinding can be a relatively advanced task, mostly because the logic takes a moment to grasp. We will be using a form of pathfinding to highlight all of the tiles that a unit can reach. When one of those tiles is selected the unit will follow the best path to the target. To make it more interesting, I will add three different movement types: a walking unit which must go around enemy units and tiles with too large a jump delta, a flying unit, and a teleporting unit.