Slaves of Magic News

Hello everyone! This month, we have done a lot of work on one crucial aspect of the campaign map, the barrack which houses the resistance units!

[h2]No two men alike[/h2]

Let's take a closer look at the recruitment page:



The inherited difference between units is their traits. Instead of just giving a unit lesser health, better attack, or whatnot, I wanted to highlight everything that is unique to a given unit at a glance. Positive traits are shown as green, and negatives as red. Every trait has a numerical value, and by summing the trait's values, we get an overall estimate of how good a given unit is (and you can sort by this value on the recruitment page by the way!).

This value is being used to decide how likely a given unit is to appear on the recruitment list, which itself is refreshed at the start of every month. Sub 0 value recruits are the worst and have a low chance to appear by default, 0 values are the norm, and all of the 1-2-3-4 values have their own category. I don't want to mention concrete percentages just yet, as those will surely still change with balancing, but the player will be able to improve their recruit pool by building and improving a recruitment center in their base, to increase the quality of their recruits.

[h2]Knowledge is half the battle...[/h2]

Take a look at a unit statistic page:



After you have recruited your units, you should decide how to spend their attribute points. This is a big divergence from the way XCOM handles levels and skills, but those who played the original GW1 will find it familiar. The basic idea is that units gain attribute points when they level up. Then these attribute points can be used to learn/improve a certain attribute which will provide a passive benefit, plus increases the potency of every skill of the given attribute in some way.

Let's take the sword-wielding attribute for example. For every level, the unit passively gains +5 defense and +5 attack when they are equipped with a sword. The levels in order are beginner, amateur, professional, expert, and master. To learn a new attribute, you only need to spend 1 attribute point, but for every additional level, you will need to spend one more than the previous level.

The max level of a unit will be 8, and the unit will gain attribute points for every level up. In addition, a level 1 unit only has 4 open skill slots which they can use. At every even level, another one will open up.

[h2]...the other half is the equipment![/h2]

The only thing that is left is to equip your unit with the correct gear for their job! The equipment is straightforward, so I wouldn't dwell on it too much, beside that you can bring 2 sets of weapons to combat. It will take 1 action to switch between them. The skills are basically part of the equipment as well, you will be able to place any skill which is known to the resistance into the empty slots. The only requirement is that the unit needs to be at least a beginner in the attribute to which the skill belongs.

What I would highlight is that there is a job system in place. The player can create a job with any arbitrary name, and save the current unit equipment settings into that job. So for example the player can create a warrior job template once, then he can just set that template to every other unit which he wants to take the warrior job. Plus you can sort the units by their job name as well.

[h2]Closing thought[/h2]

So that's it for today's devlog! But before I leave, I want to talk a bit about a new playable demo that is in the work. The demo will include both the strategic and tactical portions of the game together. We wanted to share this build with you at the summer Steam festival, but sadly, we need a bit more time to properly polish it for public consumption. So our new target for this demo will be the autumn Steam festival.

Hello everyone! This devlog has 2 parts. The first one is about our general progress since our last devlog, focusing on eye candy, then the second one is a bit more technical and focuses on our modular AI.
[h2]Progress so far[/h2]

The last barrier to testing how all the new things worked was to teach the AI to make sense of it. The AI possible options increased by quite a lot, as now it not only needed to decide what the current character should do but to which character is the best to activate at any given moment. This, in turn, increased its thinking time to around 0.05 seconds in our developer machine. This doesn't sound too bad, but because so far the game only ran on 1 core, it blocked the drawing of a new frame by that amount. So every time the AI turn started, we had a jitter. Example:



This was unacceptable, so it was time for me to separate the AI calculations to a different core, and thanks to that, the jitter is no more.

Another new feature that got added is the standard attack of opportunity system. If a unit leaves a tile that is on an enemy zone of control, then the enemy will get a free basic attack against that unit before it would leave it.



The enemy has learned to use the teleporter as well, enemy reinforcements will arrive by the use of their own teleporter. The player can see where they will arrive 1 round before their arrival.


The new animation system worked perfectly in the testing. In my opinion, it really enhanced the presentation.



Then we did a lot of small improvements as we realized problems while testing. One big thing was that I wanted the player to be able to see at a glance which units have already activated and which ones did not, while not being too obtrusive. We found that the character outlines could relay this information to the player without too much of a problem. So characters that have not activated yet will have their outlines, while those who did do not.



Another thing that I wanted to have a bigger emphasis on is the seeable enemy counter. Especially when it changes! So we moved it to a more prominent location on the UI and gave it an animation when it changes.


[h2]The brain of the AI[/h2]

I talked a lot about modularity and modability of skill in our 13. devlog and these points are super important for our AI as well. I want to give modders the tools to not only create new skills but to be able to teach the AI how to use them as well. To reach these goals, the core of our system is a so-called Utility AI. For those who want a more in-depth explanation of what that is, I can recommend this great GDC video which I think is a great introduction to the topic here!

In very simple layman's terms, it works like this: The AI has possible actions, and every action gets a value between 0-1, which tells the AI how desirable that action is. Then the AI chooses the highest-rated action to execute. In our case, these actions will be the skills(plus their input) the AI can use.

All right, so we can add/remove actions(skills) to the AI so that is great. But how do those actions get evaluated? We are adding a behavior to the action (which is basically a set of considerations) which will calculate it for us. What are these considerations? These are parts of my code that check something in the current game state and return a value between 0-1. For example, there is a health_damage_dealing consideration, which will check how much % of their current health the target would lose by the skill average damage, and it will return that. So if the enemy would lose 100% of their health, this would return 1.

These considerations are the building blocks of the AI. Sadly, modders will not be able to add new considerations to the game but will be able to freely add or remove which considerations are used creating new AI behaviors plus change how to interpret the value coming out of these considerations by redefining the curve which the value goes through before being used.

These behaviors are being defined in JSON files the same way as skills, so they are easily readable and editable. The behavior of the previous example looks like this in practice:



The linear curve defined there basically just there to say to use the consideration value. But if you wanted the AI to target the unit that would have the most remaining health after the attack, you can just reverse the slope of the curve, and that would mean if the consideration return 0, the real value returned by this will be 1.

So that's how our modular AI works in a nutshell. I will of course need to provide documentation of all the possible considerations, curves, and their inputs, but after that, the community will be able to create and modify the game AI to their hearth content. Plus of course, this modularity makes it possible for us to iterate faster on the AI as well.

So that's it for today's devlog! A lot of progress has been made, and I hope we will be able to give you something to not only read but to try out as well in a not-so-distant future!

Hello everyone! As per usual I get inspired after the holidays, and that means changing the combat system yet again! There are 2 big changes that I want to talk about today.

[h2]Goodbye movement/attack phase![/h2]

Separating the movement/attack phase to give heavier emphasis to the movement and speed of units was good at reaching my desired goal of sufficiently differentiating slower/faster units. The problem was that the player had less control over the order of execution. Luckily, in the holidays I get to know a game called Battletech, and their phase system has inspired me on how to solve this issue while keeping the slower/faster unit differentiation!

In the new system, every character will have a speed value, which corresponds to which phase it can activate. This will largely be defined by the equipment of the character, but there will be skills to modify this temporarily. When a phase is active, only the units with the correct speed value can activate, and if both the player and the enemy have activable units, it will alternate between them. In addition, it will be possible to wait. In that case, all units which were activable will reduce their speed by 1 temporarily. When all phases are done, a new turn begins. The UI was updated as well to reflect this. At the top, you will be able to see the current phase and the active team:



Your party will be shown on the right side of the screen, showing the character speed, which characters are activable, and which is selected:



My goal with this change is to give the player more options to affect execution order. For one, moving and attacking happen at the same time, so coordinating that is easier. Plus in the case of multiple units with the same speed, the player can decide the order of activation. The reason I think this is important is that I want to encourage comboing with different units, and order of execution is important for that.

[h2]Moving away from modern XCOM pod system.[/h2]

The other big change will be about how a mission start, and how are enemy units activated. Previously, it worked like in the modern XCOM games. A pod is inactive till they don't see a player unit. The big problem with this system is how important it is to avoid activating pods, and how that discourages aggressive play. An inactive pod is a pod that will not attack you in the enemy's turn, even if they wander into your team. On the other hand, if they activate in your turn (even if that was your last activation), they will act on their turn against you. So the player is encouraged to reveal as little area as possible while fighting with ideally 1 pod of enemies.

What is our alternative? In our new system, every mission starts with a planning turn. You will see the map surrounded by the fog of war, and you will know your goal location. You will then have planning phase skills, like scry, which let you check out a part of the map a limited amount of times like so:



Then using the intelligence you gathered, you can freely place your units nearly anywhere on the map. Even in the fog of war if you so desire! Just you run the risk of teleporting into the middle of an enemy pod that way ;) :



By the way, you can see that the animations for our first enemy, the Redeemed are in the game as well!

So after the planning phase, we jump straight into the action. The enemy pods will be alerted of the player's teleporting unit's location and will start actively hunting them. Plus additional enemy pods can teleport in if the player takes too long to finish their goal. So basically, after jumping in, the player's goal is to finish the mission objective as soon as possible, then teleport out.

So that's it for today's devlog. I'm super happy with how these systems turned out but what do you think? Of course, the best would be if you could try it out in action, but you will have to wait a bit longer for that I'm afraid.

Hello everyone! This devlog will be a bit more technical than usual, so I will start with some general eye candy before going into today's main topic.

[h2]Character animation system:[/h2]







As promised in the previous devlog, the creation of character animations with arms is progressing nicely.
[h2]
What do we want from our skill system?[/h2]

Now, to the main topic, the skill system. Let's define our goals as usual first:

• We need it to be modular, as we want to create a lot of skills as easily as possible.
  
• We need them to be moddable outside the code, as we want to give the community the ability to tweak skills if they want to, or create new ones easily.
  

[h2]The naive solution:[/h2]

When I first started working on this project I wanted to create a playable prototype as soon as possible so I went with a naive solution I think worth talking about before I rewrote the system. Basically, I created three types of skills. Attack skills, movement skills, and buff/debuff skills. It is a great simple system, quick to set up, intuitive, at first glance modular, so what is the problem?

The problem is when you want to create an attack skill with a buff/debuff effect if hit for example. Or a skill that involves movement as well. You can get around this by copy-pasting the relevant code into the main skill category, but it is a big no-no in the programming world. Mostly because if you want to change something in one place, you need to remember to change the copy of it too. More chance to make a mistake, which we want to reduce not increase! Not to mention it will create a messy code that is hard to read.

[h2]Identifying the core parts of a skill:[/h2]

So, we need to go deeper than the type of skill to reach the real building blocks from which a skill can be created modularly. In our new system, a skill is created from 4 major parts.

• Default parameters every skill has. These are things like skill name, sound/animation effect corresponding to the skill, etc.
  
• Targeting module(s). This module defines which tiles are valid as input for a given skill.
  
• Affecting module(s). This module defines which tiles will be affected, and its input is the chosen tile/tiles of the targeting module.
  
• Execute module(s). This module defines what happens on the tiles. The input for this is the chosen tile/tiles of the affecting module.
  

These are the building blocks of how we define skills in our game. What modders (and us as well as we are developing) will be able to do is to use the modules I created, re-parameterize them, and link them together in any way they like to, as these are freely editable in JSON file format. Like building with lego, just the modules are the lego pieces, and the end result is a skill.

[h2]Example:[/h2]

Here is the JSON file of the basic sword attack:



Human readable and editable. Thankfully not even too long, because every parameter has a default value, and you only need to write it out if you want to change that value. It is using the melee_targeting module, so choosable tiles are the ones in melee range. Line_to_target affecting module basically means to draw a line from the character to the chosen tile. Every tile in that line is affected. The width parameter defines the width of the line in tiles. And the attack_execute module means it is going to do an attack against the unit in the affected tiles, using the weapon damage by default. The skill in the game:



To demonstrate the power of this system, let's say I want the basic attack to be a sweeping attack, so to not only attack the tile that was chosen but the tiles next to it as well. All you need to do to edit the line_to_target affecting parameter width value to 2. That will make the line wider to the target so that we attack in a cone, like so:



I think it is pretty neat that we can do this without touching the code! Of course, we should replace the animation with some sort of a sweeping animation as well for better visual feedback (just replace the self_effects in the JSON) but I think this gets the point across. In addition, I intentionally kept the example simple. I only used 1 module each, but you can add multiples as well. Want to create an attack that hit twice? Add another attack executes. Want to add a debuff to the skill? Just add the proper debuff execute module to the skill.

So, this is the backend rework I was working on while the animations are being done. It took a while to get this system working, but I believe it will speed up the process of adding skills into the game by a lot plus it is mod-friendly if the community wants to tinker with it. So that's it for today's devlog, and speaking of community, if you are interested in Slaves of Magic you can show us your support by wishlisting the game!

Hello everyone! With great pleasure, I can present you our new trailer! Check it out here:
[previewyoutube][/previewyoutube]

Now, that you saw it, let's talk a bit about the new animation system for skills.

[h2]The new animation system:[/h2]

One of the biggest changes is the new way we are creating our combat animations. In the old version, we animated the actual weapon the character is using like so:



While it looks okay, but there is a big practical problem with it. We plan to have around 8-10 skills with every weapon. If we want distinct animations for all of the skills, that would mean every new weapon of this type will need the same number of unique animations.

The new way of just concentrating on enlargening the action we want to present with an exaggerated animation breaks the connection between the weapon and the skill animation. Example:



So the oblivious advantage is that we only need to create every skill effect once. But there are other benefits of this approach as well.

For one, we found these exaggerated animations to be a lot more readable. It is immediately apparent for the player what weapon the enemy uses, and with a bit of experience, what is the skill type being used (as skills and effects are color-coded).

Another big benefit was that now basically, skill use is completely separate from the user and its equipment. And that means we can ditch the invisible arm, and it is feasible to do fully animated characters! Well, one other caveat is that we needed to restrict the facing of the characters to only 4 directions as well. Sadly we weren't finished with them for the deadline of the trailer, but I leave a super early prototype here for presentation purposes:



So that's it for today's devlog, and see you next time!