Slaves of Magic News

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!

Hello everyone! Today's devlog will be about the inside of the resistance base, and some other scenes which you can encounter while you are managing your operation. Quick disclaimer, everything you see is a work in progress, especially the font!
[h2]Home sweet home:[/h2]


As you can see from the picture, we are not doing anything super innovative at the base building portion. We will have the nowadays typical ant farm set up for the inside of your base. As time progresses, you will be able to dig out more rooms for your base and place a variety of buildings. The one-room which you will always start with is the teleporter, which is responsible to get your small resistance force to the mission site and back.
[h2]The age-old question, which is mightier, the pen or the sword:[/h2]

What is an Xcom-like game without research? So, we will have not one but two separate research trees, one for the smiths, and one for the scholars. The general idea will be that the smith tree will govern the equipment research and learning new martial skills, while the scholar tree will be more about every other non-martial skill and about learning magic. Of course, there will be some interconnections between the trees so you can't completely ignore either of them, but we want to give the player a real choice in which one he/she focuses on.




[h2]You will be judged:[/h2]



Another important part of the Xcom experience is the end-of-month report. As you are depending on the resistance territories for supply, the council will mark your performance every month. It summarizes all the actions the enemy and the resistance did and their consequences. For example, if the enemy gathered enough science, it shows the new enemy squadrons you will need to face from now on.
[h2]Closing thoughts:[/h2]

This devlog was a bit shorter than usual because we are really hard at work in our preparation for the next #pitchyagame which will be on November 2. We want to finish our last big visual update to the combat portion so that we can show that as well. Without spoiling too much, I think we finally managed to figure out how can we make every skill visually impactful while keeping the workload reasonable for the planned 100+ skills. Can't wait till we can show it to you! Till then see you around!

Hello everyone! Today's devlog will be about things we changed since the last time, thanks to the testing we have done, plus to show you the mostly finished map.

[h2]Information overload:[/h2]

Check this picture, where every territory has a spy network and an enemy base:



I think this picture became super noisy. Hard to see what is relevant (cities and armies) and what is not, so in the end, we canned the idea of the enemy base and the spy network to be on the map so dominantly. Instead, we made it so that they are part of the cities they belong to, clearing up the picture.

New enemy base:



New spy network (yes, is just a flag, not as nice, but a lot more functional):



[h2]The good the bad, and the ugly, the agenda system:[/h2]

Let's start with a reminder of what I mean by the agenda system. My initial idea was that the enemy will have a random goal (mostly to conquer a random region) and it has 2 months to complete it. If the enemy can complete X number of it, depending on the difficulty level will make the player lose. There was 2 problem with it. For one, I started to think about how long I want my campaign to be. XCOM long war mod was great in a lot of regards, but it was too grindy for my taste. I realized that the game will need to take around 6-10 in-game months time. So only 3-5 chances for the enemy to score its objective. The other problem was that it is way too easy to cheese its objective of conquering a region with just 1 action which increases the loyalty of a region from the player.

So what is my solution? Well, I just defaulted back to the good old loss condition of losing too many territories. Easy to understand, works well, as if the player loses too many territories that it makes it impossible to come back, it instantly ends the game. But I still liked the general idea of the enemy focusing on regions, so I didn't throw it completely in the bin, just repurposed it. The enemy will be focusing their loyalty-reducing missions on a region (which will be the starting region of the player, in the beginning, just to make sure the player will have missions in the first month). But if the enemy sees too big of resistance (too many missions were countered by the player) it will change its target. The enemy will remember this though, so this will increase the likelihood of terror missions in this region, as a retaliation. This gives the feeling of the enemy being revengeful which I quite like.

[h2]The diversification of cities:[/h2]

Now, onto the new stuff. A lot of time was spent to make the regions and cities more distinct visually, and mechanically. Hopefully, you already saw this in the opening picture, but here are the 4 different cultures and their main cities:

In the north, you can see people building cities around mountains. These mountains are rich in ores, so you will find a high concentration of smiths in these regions.



As we go a bit more south you will find people living in a more temperate region. These are rather balanced regions, with just a slight preference for one resource.



The southwest portion of the map, gives home to a big desert, with a few oases here and there. These oases are the centers of the people living here and are renowned trade centers, so these regions are highly focused on supply income.



Lastly, the southeast portion of the map gives home to a more eastern-like culture, home of the biggest philosophers of the lands. No surprise then that these territories have a bigger concentration of scholars than any other.



The player will have to take into account the region 3 income types when he is deciding where to build additional spy networks in addition to the loyalty and defense benefits it provides. Plus the region bonus, if the player builds a spy network into all of the territories in the region.

[h2]Closing thoughts:[/h2]

So as you can see, the campaign map is close to its final form. We still have work to do on the base building portion, and to create a few menus for science/smith/barracks but otherwise, it starts to really take shape. The enemy AI works, can upgrade its armies, beat the people into submission, be revengeful if it meets opposition. I can't wait till we can actually link the combat portion with the campaign part!