Slaves of Magic
Demo hotfix is live
We have delivered another patch to the demo with the following changes:
- Fixed performance issues for users with multiple graphic cards. The problem was that it sometimes defaulted to the weaker card, causing issues. Now it should properly default to the stronger video card.
- Fixed a rare crash with the door open command.
- Fixed shield visually respawning to the unit's hand after being destroyed.
- Fixed that doors sometimes remained closed when the AI opened them in the fog of war.
- Fixed the hook shield skill, now it is not permanently disabled.
- Fixed Reform formation skill not properly giving immunity to attack of opportunity while swapping multiple units.
- Increased enemy unit quality to make the harder difficulties a bit more challenging.
Demo release date announcement
We are happy to announce that our new demo for Slaves of Magic will be released on September 22, and will be part of the Steam Tacticon festival!
Devlog #18 Filling the void with content
Start menu improvements
Let's start with our new background for our start menu:
We wanted to have something a bit darker than our previous background, and of course, just like the previous one, it is animated in-game as well! But while we were at it, we have also added proper access to the settings menu while you are in the game, so no more going back to the main menu to change the volume settings anymore.
Another important improvement is that we have added situation-sensitive tutorial popups. These will help new players to explain the basics of the game at the relevant times. These can be turned off in the settings menu for everyone else.
Tactical phase improvements
In line with the darker tone, we replaced the mono-color edge of the map with a bit more sinister:
The idea here is that the commander(player) is looking at the battlefield through a scrying orb. Hence the purple fog that surrounds the map.
Another important improvement is that we have redone the UI with the mentality that it should be readable at every zoom level, not just fully zoomed in, as we saw a lot of people playing at least partially zoomed out. I think the result speaks for itself:
New enemies:
There are 2 new enemy types to encounter. Let's start with the Inquisitor priest:
The part of the old clergy, who freely followed the new gods have established the Inquisition, which job is to uphold the new order. Those inquisitors that have been deemed worthy received magic staff and training in using magic.
Gameplay-wise they can only go into a so-called leader spot in an army, at least in the early game, so that means their number will be super limited. They are stronger than your average grunt though. In their case, while unarmored they have access to magic. Don't want to spoil their full spell list just yet, but their basic spell is called guiding light.
This spell does not do a lot of damage, but it guarantees to hit the target and ignore armor damage reduction. Plus makes the target easier to hit till the end of the round which makes it the focus of other enemies as well.
For the elite enemies, check out the dwarf soldier:
They are troops that represent forces that came with the invaders from the other dimension. How or why they are aligned with the invaders is a mystery for the resistance at the moment, but the fact remains, that they are here, fighting for the false gods and they have superior armor to anything humans have ever produced.
New options for the resistance:
Of course, to handle these new challenges, the resistance has received new toys to play with.
The resistance now has access to heavy armor as well. Not as good as the dwarf one of course, but if the user can handle the stamina and movement penalty, it will make them last longer on the battlefield. Deploy your heavy unit well to counteract their slower speed.
In the demo, every resistance unit will start from level 3 to give the player room to personalize their team. That means you will have attribute points to spend on well, attributes, plus 3 skill slots. Of course, there is a default team ready to go for those who will just want to jump to the combat portion of the demo. Some example skills like aggressive stance:
This skill belongs to the berserker attribute. While active, the unit has improved attack but reduced defense. As it is a stance it can be toggled on or off. You have to pay its activation cost when you activate it, plus at the end of every round, so to get the most ideal stamina consumption you want to leave it on for as long as possible.
The next skill is called reorganize formation:
This skill belongs to the soldier attribute. Normally you cannot go through units, but when you activate this skill you will be able to swap places with friendly units. The swap does not provoke an attack of opportunity. While in itself the skill is not really flashy, it is a great utility skill. It makes repositioning in melee a lot easier, plus can be used to save for example a low-health unit that is engaged with someone.
Let's check out a weapon skill next. This one is called hook shield:
This skill belongs to the axe-wielding attribute, and I think the gif is very telling of what it does! Drastically reduces the enemy shield block chance as the axe user hooks their shield. The one tiny issue with this skill is that it counts as an attack and does no damage, so you will need some friends to take advantage of the situation!
Closing thoughts
Those who are following us for a while might wonder why I have not shown anything from the campaign portion of the game in this devlog. The reason for that is that we decided that this demo will be only combat-focused. The player will be able to check out the campaign map as well, and indeed they will be using it to choose the mission and organize their team, but the forward time button will be turned off.
The reason we choose to hold back the campaign portion is two-fold. For one, I felt that with the campaign portion included, it might be too long for a demo format. I'm still committed that I want to give you a chance to try it out and gather feedback about it, but probably in a different format like a limited-time beta or in early access.
The other and the admittedly bigger reason is that I felt that the campaign portion, especially the base building and the world map interaction is still a bit shallow. I have a few ideas on how to add a bit of extra depth there, but that will be a topic for another time!
So that's it for today's devlog!
New gameplay trailer!
We have a new updated trailer for the game, which you can see on the store front page, or you can check it out on youtube here:
Devlog #17 The calm before the storm
Devlog #17 The calm before the storm
Hello everyone! This devlog's biggest focus will be on the teleporter room, which is an incredible piece of equipment, and the biggest prize of the resistance movement!
Preparation for the mission
In the beginning, the player will have 6 teleport pads so that will be the party limit. With additional resources and research, this can be increased to 8. The basic gameplay loop is to set up a team for combat, do the mission, then teleport back.
Units that don't make back are lost forever, and even those who did make it back will need a resting period. The length of it depends on the extent of their injuries, but even uninjured troops will be tired. Tired troops can be sent to another mission in a pinch, but then they become depressed and will need a longer rest. So the player will need to manage their troops well if they don't want to end up like this:
We did a bit of an upgrade on what exact enemies you will face during a mission as well. As a reminder, the invaders have their own armies on the campaign map and will conduct different kinds of missions. Now, they are spread thin, especially in the beginning, so there is a big difference between army sizes, which basically decides the difficulty of sabotaging the given army. The enemy has a science level as well, which will decide the units of the different army's fields. Like so:
Every army is set up from 4 units in this list. Like so:
The level 1 army consists of the leftmost 4 units, the lever 2 then shift 1 to the right, etc. The enemy squadrons in the given combat map are set up using these 4 units. And when the enemy improves their research, new units will appear at the rightmost spot of the list and shift every other unit down by one. So units that were part of only the hardest armies will eventually be part of the easiest armies. This process does mean that the player will have time to prepare to counter the new units before they appear in large numbers on missions.
New equipment
We have the animations for one-handed mace, one-handed axe, and shields.
Shields will work a bit different than simply reducing the chance to hit. They do not interfere with hit chance, rather every character has a separate shield block chance. This is mostly influenced by their skill in using shields. If a character with a shield is hit (and not from behind), then we roll another and check the character block chance. If he manages to block then the shield will take the damage, otherwise the character. Axes have a bonus against shields, so they will be the best weapon to destroy them, but other high damage dealing weapons can work in a pinch as well.
Ui improvements
On the UI front, we have created icons + bars to show the unit's stats, instead of using just text.
So that's it for today's devlog! One small piece of information, the prelude alpha demo will be removed from the Steam store on May 31st to avoid confusion with our planned new demo. It will be available from the full game's Steam page when it will be ready.
Devlog #16 The heart of the resistance, their members!
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.
Devlog #14 Holiday inspired changes to the combat system
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.
Devlog #13 The anatomy of skills in a turn-based game.
Devlog #13 The anatomy of skills in a turn-based game.
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.
Character animation system:
As promised in the previous devlog, the creation of character animations with arms is progressing nicely.
What do we want from our skill system?
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.
The naive solution:
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.
Identifying the core parts of a skill:
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.
Example:
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!
Devlog #12 The new trailer
Devlog #12 The new trailer
Hello everyone! With great pleasure, I can present you our new trailer! Check it out here:
[previewyoutube="OcmNXuFO214;full"]
Now, that you saw it, let's talk a bit about the new animation system for skills.
The new animation system:
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!