Slaves of Magic - tactical turn-based RPG inspired by XCOM and Guild Wars

[sipibaki]

 

[sipibaki]

https://store.steampowered.com/news/app/1442610/view/5046848227483394861

Devlog #14 Holiday inspired changes to the combat system

This devlog is about 2 big changes to the game, moving away from the XCOM pod system, and the introduction of a new phase system.

Spoiler

Devlog #14 Holiday inspired changes to the combat system


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.

Goodbye movement/attack phase!

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.

Moving away from modern XCOM pod system.

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.

 

[Taka-Haradin puolipeikko]

New speed value based turn order reminds me of how Battletech handled initiative.

 

[sipibaki]

New speed value based turn order reminds me of how Battletech handled initiative.

Yes, basically that is the inspiration for the system in the game right now.

 

[sipibaki]

 

[cyborgboy95]

 

[sipibaki]

https://store.steampowered.com/news/app/1442610/view/4687689963512389633

Devlog #15 Taking a closer look at the brain of the AI

This devlog talks about the progress since the last devlog and goes into the details of how the modular AI works in Slaves of Magic.

Spoiler

Devlog #15 Taking a closer look at the brain of the AI

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.
Progress so far

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.

The brain of the AI

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!

 

[cyborgboy95]

https://www.indiedb.com/games/slave...5-taking-a-closer-look-at-the-brain-of-the-ai

Devlog #15 Taking a closer look at the brain of the AI
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.

Spoiler

Progress so far
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.

The brain of the AI
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! As always, you can show your support to the project in the meantime by wishlisting the game on Steam here.

 

[Darth Canoli]

It looks better and it's way faster too.

Let's keep an eye on this one.

 

[cyborgboy95]

 

[Iluvcheezcake]

BEHOLD!

SLAVS OF MAGIC!

WISHLISTED

 

[cyborgboy95]

 

[Taka-Haradin puolipeikko]

*barrack.
Barack is ex-president of Canada.

 

[sipibaki]

*barrack.
Barack is ex-president of Canada.

Oh well, Twitter posts can't be edited so I will forever bear the shame of this typo, but I checked and at least I spelled it correctly inside the video!

 

[sipibaki]

 

[Abu Antar]

Video of character screen.

 

[sipibaki]

https://store.steampowered.com/news/app/1442610/view/3195875659165657620

Devlog #16 The heart of the resistance, their members!
The focus of this devlog is on the resistance members and how can you manage and recruit them.

Spoiler

Devlog #16 The heart of the resistance, their members!

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!

No two men alike

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.

Knowledge is half the battle...

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.

...the other half is the equipment!

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.

Closing thought

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.

 

[Abu Antar]

For today's #screenshotsaturday, a bit of quality of life update for the barrack! While we don't have classes, the player will be able to save any character build they make as a job, which will then can be applied to other units. #indiedev #indiegame #turnbasedtactics

Spoiler

 

[sipibaki]

 

[Taka-Haradin puolipeikko]

Is 8 absolute max party size?

 

[sipibaki]

Is 8 absolute max party size?

Yes, the plan is that the initial size is 6, which will be upgradable to 8.

 

[FriendlyMerchant]

So when does this come out?

 

[sipibaki]

So when does this come out?

Well, the current plan is to have a new demo at the autumn Steam festival. It will include basically the first 1-2 in-game months of a campaign, with a small set of enemies and skills, to give a taste of the early game for the player, plus to gather feedback. That is the goal we really want to hit but after that, it's not that clear yet. We might come out as early access at the end of the year, but if you are asking when it will be "done", probably sometime next year.

 

[sipibaki]

 

[Kev Inkline]

Weren't Ufo1 and 2 maps also generated?

Yes, the original Ufo maps were generated as well. I think the only XCOM game with premade maps is the first Firaxis remake.

It's obviously inspired by Battle Brothers:

No arms do (link explaining the joke).

It is inspired by Battle Brothers, though the artist really wanted legs in our case, so we have those :D . The reason for doing it is pretty much the same, to reduce the number of animations the artist has to do. It is even more important in our case as unit facing is an important part of the combat system, so even with using mirroring, we have to do 5 directions.

What kind of sicko wants legs but no arms?