Tutorials

The creation of a turn based battle system

by Ixayou (PM)

See everything made by this user or team.

Current Language: English
Helpful
of 9 vote(s).

Planning phase

Too many inexperienced developers make the mistake of skipping the planning of their system, and start working on their games right away. I can not tell you enough how important this phase is. Don't start working on your game before you know exactly what you want to be in it! This will save you a lot of work, and will make your project more organized as a whole.

 

Stats

First off you need to figure out your stats. In this phase I always create a note or a document where I write which stat does what, and how the character is affected by it. You need to think through this part carefully, and make sure the stats are all balanced, and that there aren't too many for you (or the player) to handle. If you want a very simple turn-based battle system, you might just be fine with stats for HP, attack and defense. Fewer stats like these will make your game a bit easier to develop. If you want a more advanced stat-system, however, you need to make sure that all of the stats have a purpose, no stat overpowers another and that they all make sense. You might want to take things such as magical damage, magical defense, ranged damage and evasion to consideration. There are no limitations, however, as your game will be your own viritual universe. You can create whatever stats suits your game the most. But like I said, make sure that they are all balanced and have an equally important purpose.

You also need to consider how stats will increase as the character levels up (if they do). You might want to just make a simple curve in the engine that makes the stats raise themselves, or raise certain stats depending on a characters chosen class, or let the character raise their own stats each time they level up. Remember, whichever feature you create for this also have to be balanced, and should not make the character overpowered in your game.

Below is my default stat-chart. Feel free to use it if you wish.

The character is able to add 5 to one of these stats each time he levels up
HP:
The character's health. Character left unconcious when HP is 0. 
AP: The character's energy to perform physical, ranged and overall non-magical attacks.
MP: The character's energy to perform magical attacks. 


These stats are determined by worn equipment and carried items
Weight:
How much the characters inventory weighs. Determined by the weight of all carried items. Maximum carried weight is determined by strength.
Defense: The characters damage reduction. Determined by worn armour.

The character is able to spend 3 skill points of any of these stats each time he levels up.
Strength: Determines the power of physical attcks, and maximum carried weight.
Dexterity: Determines the power of ranged attacks, and the accuracy of physical attacks.
Agility: The character's physical quickness in battle (regenerates AP) and their ability to evade physical and ranged attacks.
Intelligence: The power of magical attacks. Hostile damage spells require intelligence.
Wisdom: Accuracy of any magical spell (the chance of a spell being successful). Non-hostile- and hostile effect spells require wisdom.
Willpower: The characters mental strength to evade magical spells and effects. Also regenerates MP.
Perception: The characters ability to see, smell and sense the world around. Determines ranged accuracy.
Luck: How lucky the character is. Affects how often critical hits occur, or when a hostile action is completely evaded (or the hostile action fails completely).

When I created these stats, I had some keywords in mind that I needed to balance out using stats:
physical damage: strength
physical accuracy: dexterity
physical evasion: agility

ranged damage: dexterity
ranged accuracy: perception
ranged evasion: agility

magical damage: intelligence
magical accuracy: wisdom
magical evasion: willpower

So basically I had three key elements based on three attack types. I made a simple chart of the three attack types, and which elements I needed to create stats for. In my system I also have factors such as MP regeneration and AP regeneration. This is because when a battle starts, all character's MP and AP starts at 0 and regenerates untill they have enough for an attack. So stats such as agility and willpower determines who will attack first (and most often) in a battle. My battle system is my own though, and you may want to do this differently. But this is an example meant to show that every stat should have a clear purpose within your system, and balance out with the rest.
 

 

Number of characters in battle

You need to determine how many characters can be in battle at the same time. A lot of you may want to keep it limited to one-on-one battle, which will probably be the easiest option. Personally I like keeping it to a maximum of three playable characters, and a maximum of five enemies. This might require one to repeat every player script three times, and every enemy script five times. I admit, that is not the easiest way of doing it, but there is a way to simplify this, and we will talk about that later. You may want to do it differently, though, and  if you're a skilled programmer you might want to add the ability to have unlimited players and enemies in battle, and have player and enemy scripts loop for the amount of players and enemies there are. Remember that you will also have to create an interface solution to whatever you come up with. Make these desicions carefully regarding your own skills as a programmer, and how much time you wish to spend on your project. The best thing you can do is to think realistic, and not add more characters than you can handle.

 

The dynamics of the battle

There are a lot of different types of turn-based systems out there, and only your imagination (and programming skills) limits your own system. You need to think about how you imagine your battle to take place. What determines whose character's turn it is? Which options will the player have during their turn? Will the system also be time-based, or will the time halt whenever it's somebody's turn? Also, will the player be able to move their position during their turn, or between turns? Pherhaps you want a card-based battle system?

My own system I am developing as I write this tutorial, will be time-based. All of the characters have both an AP and MP stat, which starts at 0 at the beginning of each battle, and regenerates in a speed depending on their stats (agility and willpower). Once a character has enough AP or MP for one of their attacks, their interface field will be enabled. Time halts once that playable character's interface field is clicked on, so that the player can take their time to decide on which action they want to do. Once the character has chosen the action type (they can choose between physical, ranged, magical, defensive or item), then a window will pop up listing all of their actions within that type. They can choose between the available actions, then click on the interface field to whichever character they want it to take effect on (may be both hostile and ally, depending on the action). The active character will complete their action, and time will keep flowing. Once an enemy has enough MP/AP for an attack, a script will make them randomly decide wether they want to use one of their attacks, or regenerate more AP/MP for a more powerful one. 

You have to figure out all of the details beforehand, and plan on how you're going to program it. During this phase it can be a good idea to make a simple chart of events. Just keep it simple at this stage, don't go into planning the scripting just yet. Just create a chart of available options that can happen during the flow of battle, and events or sub-options related to them.

 

Planning the interface

What some developers may not realize, is that the interface is about 90% of the battle system. Most of the events are happening within an interface, the rest are animations and scripts within different attacks, which are mostly just for looks. Every good turn-based battle system has a good interface which is user-friendly, easy to understand, forgivable, give feedback and should stick to the default standards of such battle systems. A good layout will also serve you well in most cases.

User friendly

When an interface is user friendly, it usually means that the user don't have to go a long way to find whatever they are looking for, and they should easily be able to go back from where they are in the interface to a previous point. Say, if the player wanted one of their party members to do a ranged attack, then the way there from the main screen in-battle should be as short as possible. The way there should not be over complicated and should not take time, and the way back to the main screen should be easily available. In this case users should also be able to cancel any action they have set in motion, unless the action itself is already taking place. For example, once a player has chosen which action to do and is about to choose which character to perform the action on, the player should still be able to abort the action if the whole action has not yet been confirmed. At all stages of the interface, the player should easily be able to go back one step.

Easy to understand

The player should never be in question as to what the different options in the interface are. Make sure that every option is clear as to what it's purpose is, and every icon must be simple, well-drawn and understandable. In this part, it is always a good idea to take the users own associations into consideration. For example, when you see the icon of a letter, you will most likely associate it with mail/e-mail or a message. If you see an icon with a house on it, you will think of a home, and associate it with a main screen. If you see an arrow pointing left, you will think of the direction backwards, and an arrow to the right will make you think of the direction forwards. In the same way, the user will most likely associate an icon of a sword in it with attacking, a shield with defending, a magic wand/hat with magic and a bow/arrow/gun with ranged actions. If you decide to use icons, then make sure they are simple, and that the user don't have to be in doubt about what they mean.

Also, wether you are using icons or not, the player should never be in doubt about where to find the action they are looking for. They should not have to search. Whenever you have created your interface, then I suggest having a friend or somebody who has never seen it before try to navigate around in it. If you see them searching around for whatever they are looking for, then you may want to rethink your use of symbols and directions.

Forgivable

No matter how solid your interface is, no matter how easy it is to navigate within and no matter how easy to understand, users will always make mistakes. This is why your interface needs to be "forgivable". This means that whatever the user did previously, they should always be able to undo it. This means that once they decided which attack they wanted to perform, or which party member should attack, they could have chosen the wrong one, and may be wanting to undo it and choose another one. Always be open for user mistakes, because they will always happen.

Feedback and clarity

Your interface must always give the user feedback about the results of their previous action. If one of their actions triggers a script, but the user don't see it visually, they might wonder wether or not the action did anything at all, and might even do the same action several times. It should always be clear what the results of the users previous actions were, so that they know which action to take next. For example, when a character chooses an attack or a magic spell from a pop-up window listing all actions, and the window disappears once they have chosen it so that they can choose which character to use it on, it should be clear somehow which action is chosen. What I did in my game, was that once the user had chosen an attack and the pop-up window closed, the name of the chosen action appeared right next to the mouse cursor. That way, they user both knew that an attack had been chosen, which attack had been chosen and also gave the player the feel of directing it to wherever the mouse clicked.

Pop-up messages can also be a way of achieving feedback and clarity. If you make the player use an item from the inventory, you might just want to do it as simple as showing a message saying something like "(character name) used (item name). (result of item used)". For example, "Hero used healing potion. Hero gained 10HP". This will avoid that the player wonders wether or not they used the item, and make them use it several times just to be sure.

Sticking to the standards

The easiest way to make an interface understandable and easy to use, is having it resemble something the user has already seen before. Many battle systems follows a certain standard. Take a look at the screenshots from Chrono Trigger and Final Fantasy. (Taken from google pictures 8.8.2014)

These are two entirely different games. However, you can still see a big similarity between their interfaces. They both show the character's HP/MP, as well as available options for that character. This is a pretty default set up that most users are already familiar with, and might be a good base for whatever you are creating. Do some research, look at other games' battle interfaces and see which elements keep appearing in most of the games. If they all keep using it, then appearently it works, and the player might have seen a similiar interface elsewhere and might find it easier to make themselves familiar with yours.

Below is a quick screenshot of my interface. Keep in mind that I am working on this battle system as I am writing this guide, and at this point I've only got to work on the interface and not actual gameplay itself. Anyway, look at the screenshot and compare it to the ones above. I've sticked to the old standards, making the interface recognisable by many users. This has saved me a lot of work when it comes to making the interface understandable.

 

Layout

While taking all of the above steps into consideration, you need to create a sketch of your layout. The easiest way to do this, is to take a piece of paper and pretend it's the users screen. Mark different areas of the screen where different content will be placed. The best way to do this is to sort the content into different groups. Keep one area for visual animation. Keep one area for user navigation, and place similiar information in the same area. For example, I keep information about all of the party members in the bottom left screen area, and information about the enemies in the top right (also to represent opposition against eachother). Do some research about creating an eye-appealing and meaningful layout, and sketch it all on paper before the actual creation. This can save you a lot of work if you suddently find out that the layout you were working on, needs to be changed. Making a quick sketch is a lot easier than creating an actual interface.

(taken from google pictures 8.8.2014)

 

Event chart

Now that you're done drawing your interface, you may want to create an event-chart for every option available in the interface and the result of every option. There are different ways to do this, and you should do whatever proves most helpful for you. The best idea is to sketch down the most elementary commands, then think about how to script them later on. Charts like theese are mostly made to show the flow of the interface events.

 

 

 

Planning your battle-system fundamentals

Okay so you have planned out most of the details of your game system, sketched an interface layout and maybe even it charted it out in an event chart. Still, a big program such as a battle system needs to be built, and you need to figure out how it's all going to be put together. Like I've been saying earlier in this article, I am not going to tell you how to create your game. This part is mostly for you to figure out. However, take some of these things into consideration.

Simplify scripting

How will you build your system to contain as few scripts as possible, while still keeping the same playability? You need to be able to plan out how one script you make, will be usable for every similiar case. Avoid re-using the same script over and over, while only changing a couple of details. Also avoid creating a comparison branch with 10 different outcomes depending on one detail. Instead, create a variable for those details that usually change during player navigation, and run the same script for every case.

For example, I have created variables such as Player_1, Player_2 and Player_3 to contain the actor ID of the playable characters which are in-battle. I do the same for enemies using variables such as Enemy_1, Enemy_2 ect. These variables are set before the battle starts. Also, I have variables such as Active_Character and Target_Character that saves the actor ID of the character which is making a move, and which character that move is directed towards. That way I can script the action's events sepparately using these variables. I also have a variable for the chosen equipment area for the action (physical, ranged ect...) so that I only have one window for listing the actions within the type the player has chosen to use. Also, I have a variable named Action_InUse for the action that is chosen. It may also be a good idea to have variables for all of the involved characters' starting position, so that they can easily find their way back should they move during an attack.

You also need to find a way to simplify enemies' attacks or attack patterns. This can be done very differently. Personally I store all attacks/magic as inventory items, just like I do with the playable characters. I also call them out the same way I do with playable characters.

Using a few simple variables like this will simplify your scripting a lot. These variables are the very fundamentals of any battle system I have ever created.

Mathematics

You also need to decide the mathematical equations of different attacks depending on your stats. Remember, keep it balanced with stat progression. Don't overpower any character too quickly. A good idea is also to create a branch tree of how these equations will take place in script nodes.

Ability to implement features later on

Find a way to make your system open to adding features later on, such as different attacks, items and such. Don't make your battle system a static one, with the same attacks being used over and over again. Make it dynamic, with the ability to easily add a new type of attack, both for playable characters and for enemies.

Keep in mind that you're creating a whole game, not just a battle system!

Make sure that whatever you create your battle system to become, it needs to be easily added to your game, and the battle system should be easily accessible to whatever in-game content you are creating. What I have done, is to create a custom event that starts a battle from wherever or whatever I am developing in my game. I can easily choose which characters should participate, and which enemies. And I can make the battles take place in any map, wich any character position. What you need to do is create your system so that it fits into your game, or so that you can build your game around it if you're starting from scratch. The last one might probably be the easier option.

 

Previous Page
A guide to creating your own turn based battle system
Next Page
Building phase

There's been a total of 25557 views(s).
There's been 8850 people that have viewed.