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

[Sykar]

For a moment I read this as "Slavs of Magic"... I guess I had a little too much Cheeki Breeki!

 

[Taka-Haradin puolipeikko]

 

[Abu Antar]

 

[Taka-Haradin puolipeikko]

 

[Wulfric Pinewood]

Thank You but it is too autistic for my brain.

 

[sipibaki]

Thank you, Taka and Abu that you keep posting my small screenshot Saturday progress tweets!

As you can see by those tweets as well, we are still hard at work on the campaign map, its look, and the way the player can interact with it. I have summarized our progress so far and made a new devlog about it.

https://steamcommunity.com/games/1442610/announcements/detail/2975175813416039114

Devlog #9 Deep-dive into the mind of the invasion

This devlog is about how the campaign AI can interact with the world, and the player.

Spoiler

Devlog #9 Deep-dive into the mind of the invasion

Hello everyone! In the previous devlog laid down the goals of my design on the campaign, and now I would like to show you where these goals led me, and what will be the player up against in their fight for freedom!

The heart of the invasion forces, the armies:

The most important thing the AI has to change the game state is their armies. They all start in their headquarters at the start of the month, and as the month progresses, they are all going to conduct different types of missions. Take a closer look at one of them:

There are 5 small orbs and 1 big orb floating above every army. The 5 orbs represent the army level. The more orbs are burning, the higher its level. You can think of an army level as difficulty, as it describes how hard the mission will be if the player tries to counter that army. The big orb job is just to show if the army was successful (purple) or not (red) in its mission, plus it can be shattered if the army is damaged. Under the orbs, you can see the 3 squadron leaders which represents the type of enemies you can encounter if you counter this army. This largely depends on the enemy science level and the army difficulty level.

The primary conflict zones, the missions:

Armies conduct missions on territories depending on their planning at the start of the month. The AI takes into account the current game state, for example, how much supply it has, what its progress on their agenda goal, and updates how dangerous it thinks the player is. Common mission types :

- Tax collection: This mission if successful will increases the enemy supply. In addition, it has a small negative impact on loyalty. Prioritized if low on supply.
- Crackdown: This mission if successful will have a big impact on the loyalty of the territory. Prioritized if agenda is not yet fulfilled.
- Abduction: This mission if successful will increase the enemy science. In addition, it has a small negative impact on loyalty. Prioritized if they feel the player is dangerous.

Other missions which they will only do if they feel threatened:

- Terror mission: This mission cost supply for the invaders. This mission has a big impact on the loyalty of the territory, but the exact size of the impact will depend on how many people the player can save.
- Destroy information network: This mission aims at the player spy network. If the player does not counter it, they lose their spy network. The player can counter these missions which are being conducted by the armies if they detected them, and that leads to the tactical portion of the game.

Buildings to stake territory:

-The player can build spy networks (left) that increased the detection rate of enemy missions to 100% on the territory they are built, plus gives a bonus to the passive detection chance for every other territory in the region.

-The enemy can build bases (right) on a 0 loyalty territory at the end of the month. This cost supply for them locks the territory down (so they can't conduct missions there) but they will gain passive income. Plus the player will have to destroy the base if they want to liberate the territory.

Science, the wheel of progress:

One important aspect which I have not yet talked about is science. The enemy has a small passive science income, and it will prioritize it if it deems the player too dangerous. Science level primarily affects 2 things. For one, it affects how many armies it can field, and at what level. The other one is the actual squadrons which you can meet on tactical combat. For that, we have a handy screen for the player to always see and check the possible enemies:

There are 7 squadrons on the screen. When the enemy reaches a new science level, a new squadron will arrive from the right and pushes all other squadron downs 1 step. The army composition depends on the position on this line. For example, against a level 1 army, you can meet with the leftmost 3 squadrons. In practice, this means as science increases, new harder squadrons appear in the high-level armies, and the low-level armies will "inherit" the pushed-off squadrons. So the player will have ample time to prepare for new squadrons arriving if he fights against the lower-middle armies.

The enemy science screen goal is to make it clear for the player what he is up against, so you can check out the squad's composition, and individual unit statistics as well:

So that's it for today's dev diary. See you in the next one!

 

[Abu Antar]

 

[Taka-Haradin puolipeikko]

 

[sipibaki]

https://steamcommunity.com/games/1442610/announcements/detail/2956038141924821371

Devlog #10 The proof is in the pudding, testing the campaign design

This devlog is about the changes brought forward from testing. Plus explaining a few new things added to the map.

Spoiler

Devlog #10 The proof is in the pudding, testing the campaign design

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.

Information overload:

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):

The good the bad, and the ugly, the agenda system:

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.

The diversification of cities:

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.

Closing thoughts:

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!

 

[Abu Antar]

 

[Taka-Haradin puolipeikko]

 

[sipibaki]

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

https://steamcommunity.com/games/1442610/announcements/detail/2956038141924821371
Devlog #11 The first peek inside the resistance base

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.

Spoiler

Devlog #11 The first peek inside the resistance base

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!
Home sweet home:

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.
The age-old question, which is mightier, the pen or the sword:

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.

You will be judged:

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.
Closing thoughts:

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!

 

[Infinitron]

Slaves of Magic is a fantasy turn-based tactical RPG, inspired by XCOM with a few hints of roguelike elements, to make sure every campaign provides a unique challenge to overcome! You will need your wits to adapt to the ever-changing enemy bent on enslaving humanity with magic!

 

[sipibaki]

Infinitron, you were again faster than me to post our new trailer, thank you! What I can add is that there is an accompanying devlog as well for the trailer.

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

Devlog #12 The new trailer
A new trailer, some insights into it, and things that couldn't make it into the trailer in time.

Spoiler

Devlog #12 The new trailer

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



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!

 

[sipibaki]

 

[Rarre]

I loved guild wars skill limit so I am here reakky interested

 

[cyborgboy95]

 

[vazha]

You realize the word "slave" in the title is not a mere coincidence when the developer proudly presents a hoe as a two-handed weapon )))
Intrigued, will follow this.

 

[sipibaki]

 

[sipibaki]

 

[Taka-Haradin puolipeikko]

sipibaki can you loot corpses in game?

 

[sipibaki]

sipibaki can you loot corpses in game?

Detailed looting of characters is not planned. Most likely there will be only mission-specific looting. For example, there are resources on the map which you need to gather before the enemy does.

 

[sipibaki]

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

Devlog #13 The anatomy of skills in a turn-based game.
This devlog is about how we created a modular skill system, which is easily editable and moddable using JSON files.

Spoiler

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!

 

[cyborgboy95]

 

[cyborgboy95]