FIRST STEP: BATTLE SYSTEM EXPLORATION
Welcome back! Today I’ll tell you more about our core gameplay, the battle system.
As I said in the first post, me and my team wanted to make our combat a turn based strategy game, with the player feeling about a war going on.
THE CAMERA
Let’s start with a big question; 2D or 3D? In the development, both productions have their pros and cons. 2D is simpler as there are no 3d models, no animation and rig (the process of making a 3d model animable) to do, but it could be trickier to solve different graphical problems, like having shadows and lights.
We decided for a 2.5D (https://en.wikipedia.org/wiki/2.5D) . It’s a sort of compromise for our needs and resources we have. As our team lacks 3D artists, we can actually only develop 2D assets, but we wanted to make it as beautiful as possible. So we chose to simulate the appearance of being three-dimensional just by using 2D images and with an isometric view.This is the result. It seems 3D but actually it’s all 2D , as you can see the image below the white cubes are real 3D Objects and how they could be placed to form the real grid behind the fake 2,5D view. It’s all about perspective !
THE MAP
Our first choice for implementing our battle system was to make a single square grid, with a variable size between 16 to 30 cells.
The concept of our maps are pretty simple. There are different cell types, generally the most important one is the ground, which has no particular features. Then there is a liquid cell, for example water, that can be deadly to certain units, and then there is a block cell, for example the mountains, used for blocking some kind of attacks. Finally there could also be other special cells with different bonuses or maluses. For example the forest gives the unit a defense boost when he’s on it.
PROCEDURAL GENERATION
The map generation is all procedural and it works in a simple way efficient way:
It looks firstly for the planet data: the size limits, the cell types it has, how much liquid and blocks it should have, etc…
After it decides the size of the map, it spawns all ground default cells. Then it decides how many cells for each type we would like to spawn, based on the planet data.
For example we start with a map of 16 x 16 = 256 total cells.
the planet has a chance to spawn between 5 and 15 % water , and for our example it choose 10% , it means 25,6 (rounded to 26) cells are converted in water
We start with liquid cells. We wanted to make the liquid cell more prone to spawn near each other, to create larger areas covered by the planet liquid. So we make a basic weighted random algorithm (check https://starbeamrainbowlabs.com/blog/article.php?article=posts/239-Weighted-Random-Number-Generator.html for more info) and each time a liquid spawn on the map , it would give more weight value on its neighbors cells to spawn other liquid. The images belows should give a graphical view of what I’m saying.
Then we continue with all the other cell types, but this time we usually set the weight uniformly, so there were no forced aggregations. After all cells are converted, the map generation is done.
We tested this process hundreds of times and we saw what we expected, there were usually larger lakes and some isolated water cells around the map. The map generation was working!
THE BATTLE SYSTEM
The battle system consists in 4 phases
Phase 1 : the pre battle.
This is where you see all the info about the planet, the objectives you have and the rewards. This is purely used as a transition between screens.
Phase 2: the placement.
How do we put the units in our combat at the beginning? We could do a chess-like start with 2 sides occupied and a good neutral area between them, but if you think about it, it would be too much equal when there would be a planet defender and someone who is attacking. We need some sort of difference between the two sides. So we thought of a placement divided in 2. The defender is the one who starts to put his troops. He knows the objective and can decide first in all the maps where to begin. But after he places his first troop , then he’s limited to place the others near the first one.
When he puts all his troops, then the attacker can put his units.he knows where the enemies are and he can put them everywhere on the map but not too near to enemies. After he places everyone, the battle begins.
Phase 3:the battle.
Each unit is sorted with his initiative at the start of each round. The fastest unit begins and he can move and/or attack with one of his skills. When he ends, the turn will go on to the next unit. And go on until there is only one faction left. This is where
Phase 4: the results.
The battle ended and now we are looking at the stats of the battle itself. We have all kinds of data: who won, who was killed, if someone ranked up, etc.. Not useful in skirmish mode.
THE UNDO
We implemented a way to undo your actual turn and reset what you have done. You can’t actually go back on already ended turns, and if you die inside your turn, you will lose the chance of reset. The use of this undo system is limited by a module that you can upgrade later in the game. This is our way to tell you that if you screw up a battle, there are no second chances!
ACTION AND SKILLS
Each unit has a set of skills for attack and/or support. During your turn you can actually see how each skill is working, its range and damage. One of the most important skills is the abduct. Abductions are the only way to gather DNA samples from neutral species (and enemies too) so that you can later use them during the mixing process.
If you have success on abduct, the enemy will disappear and you will gather some DNA after the battle ends.
LET’S TALK ABOUT THE AI
One of the most complex systems in the game is the AI. The AI should be intelligent enough to understand each skill where to use it and the best moves it can make to win the game, but at the same time it should be dumb enogh to let the player win with a good challange. Too hard and you will be annoyed , too easy and you will be bored. To having a good time with our battle system,. we need to find the perfect compromise.
The idea behind our AI is that it looks at all possible moves (for “move” I intend the combination of movement and attack it can do with its 2 action points) it can make during its turn and gives a value based on “the general effectiveness of that move”. Then it sorts all the moves with these values and it picks up randomly one the first choices. The big problem is defining what makes a move “good”.
Generally speaking , there are a few values to take account of. The position on the map, if the position is reachable from an enemy and if it can attack an enemy, and then what enemy is that and if it can kill it. These are just a few ideas that to explain everything in detail I would need a single post only for that.
THE FIRST TESTS
The first thing we needed to verify was how fun and entertainment the combat system was. We put up this screen and made some people try it. Feedback was really positive and although there are many aspects to balance and fix, the overall concept was working nicely. Yay!
