- Joined
- Apr 16, 2004
- Messages
- 6,831
Not an expansion, it’s a standalone game.
You will not be able to import your character from Underrail. Infusion has a separate protagonist.
Release date TBD.
**************************
I'm correcting an error that the editors at this prestigious magazine overlooked for too long: the lack of a dedicated Infusion thread.
Infusion's announcement:
Developer logs, newest at the top. If there's an associated codex thread, it's linked.
as a reminder to everyone, Styg is the moderator of this forum and has engaged in some of those devlog threads. there's more info in them if you want to dig.
You will not be able to import your character from Underrail. Infusion has a separate protagonist.
Release date TBD.
**************************
I'm correcting an error that the editors at this prestigious magazine overlooked for too long: the lack of a dedicated Infusion thread.
Infusion's announcement:
Hi guys,
Back in October I mentioned that we started working on a new standalone Underrail campaign. This is still true, but we've also decided that we're going to give the engine a major upgrade which will help us create a much better game, both visually and mechanically. The thing is - there are certain design and technical decisions that were made early during the development of Underrail that are very limiting to us now, but are not easy to change just due to the amount of content that would have to be redone. So instead of taking a hammer to our beloved game, we're going to improve upon all these things (that we yearned to do for years) in a fresh stand-alone game that will still be based on the same engine core and gameplay mechanics. We call this game Underrail: Infusion.
I'm not going to list all the things that we intend to change/improve upon in Infusion, but I will say that they include both the visuals, as well as mechanics and world design. I'm going to try to post more frequent dev logs, as I did back in Underrail's alpha days, as to keep you guys in the loop. All that you see in these early days you should consider to be work-in-progress. I don't expect we're going to enter full production any time soon - not this year, for sure, as for now we're just focusing on improving the engine, the toolset and optimizing the content pipelines.
First thing I want to show you are the new environment graphics. Keep in mind that Infusion will be taking place in a completely different part of Underrail, so this is not a rework of any existing tile set, but a new one.
I've done a lot of work on the rendering engine and the way the assets are organized and rendered which allows Mac to more easily produce and organize a bunch of different variations of the same object, and also to easily animate them or give them other visual properties and behaviors without having to go into the gameplay code. Inversely, gameplay stuff can now be easily implemented before the assets themselves are made as they are only loosely coupled. This is going to greatly improve our efficiency when churning out new content. Technically, we're sticking with the same tile size (96x48) but we're going to make the tile relatively smaller in regards to objects, that is, everything is going to get bigger, which will increase the graphical fidelity. This is going to affect various combat mechanics as well, but we're discuss this at a later date.
That's it for now. We have more exciting stuff that we've been working on in the meantime as well, but it's not quite ready to be shown still. Let us know how you guys like the new visuals.
Also, in a few months you can expect the new content update for Underrail. This one is probably going to be released on experimental branch first and will stay there for a while, just due to the nature of the gameplay changes I've made. I'm sure you'll all be very happy with the changes, but just in case you might want to experience psionic characters in their current form before that happens.
Cheers.
Developer logs, newest at the top. If there's an associated codex thread, it's linked.
https://rpgcodex.net/forums/threads/infusion-dev-log-7-new-armor-mechanics.148869
https://stygiansoftware.com/forums/index.php?topic=10348.0
November 17, 2023
Hi guys,
It's that time of the year again. All the stars and planets are in the right position and it's time for an Infusion dev log.
We already showed you the extent to which we upgraded the visual aspects of the engine, but the mechanical changes that I've done so far and am yet to do are just as extensive, and perhaps more radical. I'm going to talk about them one by one, in separate dev logs, as I continue to test, tweak, and refine them.
Our immediate goal with the engine and the game is to (re-)implement a number of items and mechanics, get a few areas together, and get the game in a state where it can be played for real, so to speak. Mainly so I can better asses how all these changes work in practice, but also so we can produce a short demo video and show you the game in action for the first time.
* * * * * * * * * *
So, anyway, let's get to the changes to the armor mechanics and damage resistance in general.
In Underrail, the damage resistance was divided into percentual resistance and flat threshold. Incoming damage would be reduced either percentually or by flat amount, whichever would reduce more damage in any given case. This caused a lot of balancing problems. Threshold was generally either useless or overpowered (especially when stacked in early game), while resistance was hard to progress with armor quality, as its percentual nature made it already scale innately.
All these problems really came to forefront when I was implementing different types of shotgun shells in Expedition. Balancing usefulness of different shells in this system was just impossible and it took a lot of tweaking to make it even remotely decent with liberal use of seemingly arbitrary threshold and resistance ignore factors. At one point I was tempted to just implement a completely different interaction for the shells specifically, but decided against it for the sake of consistency.
Another problem with the old model was that all resistances stacked globally. Meaning: resistances from boots and helmets were equally effective as body armor and they all aggregated when it came to interacting with incoming damage. This made me really hesitant to put a lot of resistances on helmets and boots because, on one hand, I didn't want them to make the high resistance armors completely broken by just maxing (or near maxing) out all the resistances and, on the other hand, I didn't want these items, because of their high resistances, becoming mandatory for characters that use ligher armor in the body slot.
There are other problems too, but these are the main issues, I think.
So how does the Infusion's new system differ from the old one?
In Infusion we're going to have a lot more gear slots, mainly from separating body armor and helmets into multiple component slots. This will provide the player with a lot more damage resistance sources. But unlike in the old system, these resistances will not stack. Instead, they will all interact with any given attack separately. So whenever you're struck somewhere on the body, the game will check what armor covers that spot, and it will interact with that armor piece. If there are multiple pieces, it will go through each of them separately, from the outer toward the inner. E.g. you might have some minor resistances on the overcoat that will interact with an incoming bullet or a stab before your torso armor.
For now, I have no intention to allow the player to choose which part of the target's body they're attacking (Fallout style), but there will be different special attacks / stances that will influence this (e.g. decapitate). Also, elevation and size of attacker and the target will also play a role here. So, for example, attacking someone from an elevated position will give you a better chance to hit them in the head and worse (if any) chance to hit their feet.
Different types of creatures will have different body part arrangements. For humans it is as follows: Head (5%), Torso (55%), Arms (10%), Legs (including the pelvis) (25%), Feet (5%). The number in brackets is the current working chance to hit distribution for a generic ranged attack. These numbers will vary for different attacks and situations, but it should give you some general idea what areas are going to be most important to cover with armor in most situations.
Depending on the armor design itself, it may end up covering one or more body parts. In the example of an armored rig/vest, which is the only crafted armor at the moment that's implemented, in addition to covering the torso, it can also provide some additional protection to arms and legs.
Let's go through the examples above. The armor on the left only provides cover to 80% of the torso part. Like the icon indicates, it does not cover the stomach all the way down. We'll talk about the intricacies of coverage later.
The armor in the middle, however, also sports sleeves and a groin guard. The groin guard covers the rest of the belly in the torso part and also covers the groin area, of course, which falls under the legs part. The sleeves cover the shoulders area of the arms part.
The armor on the right has sleeves, but no groin guard.
Regarding coverage, the way we're going to determine at which point an attack lands in a given body part, and so if it interacts with an armor segment that provides partial coverage, is still under consideration. The tooltip here provides just the coverage percentage, but the icon itself is trying to further illustrate what area of the part is covered. Having 20% coverage in arms at the top (shoulders) is not the same as at the bottom (hands) as both of these can be layered over. It doesn't make much sense that, if you are wearing gloves and shoulder pads, a bullet attack can go through both of these.
The way I treat the coverage number, which is esentially a floating point pair (e.g. 0.8-1.0 for shoulders, 0.0-0.2 for hands), is that 0 is the lowest point of the body part and 1 is the top point of the body part and 0.5 is the middle.
* * * * * * * * * *
Now, if you are an RPG mechanics connoisseur, as you surely must be if you made it this far into the dev log, you might be looking at that armor at the left and thinking how fun it's going to be to get hit by stray bullet to the torso right below your endgame crafting-maxxed armored vest and instakilled 20 hours into your ironman DOMINATING run. And I share your enthusiasm for suffering. However, as this kind of experience might not be pleasurable for most players, there are some additional considerations that I'm going to have to give to this.
One of the mechanics that are in place right now is that there is such a thing as grazing shots, which are basically hits that deal about half as much damage. They occur when the attack roll is within the graze part of the hit chance, the size of which is determined by attack-to-defense ratio. I don't want to get into too much details regarding this right now, as the topic is extensive and this dev log is already too long (it warrants its own). What is relevant for the example above is that the farther you are into the graze area of the roll, the farther the hit lands from the center of the body part.
So, basically, the lethal bullet hit described above would deal half the damage, giving you a better chance to survive. Whether this will be enough to make these situations acceptable, remains to be seen through testing. Just know that I am aware of this potential problem with the system.
So what about other body parts? Are we going to have to cover every bit of our body with heavy armor to avoid the similar scenario? What about getting hit with a plasma gun critical to the pinky toe while wearing tabis? Well, first of all, the chance to get hit in the feet is quite low, outside insects biting you or stepping on caltrops or acid.
Additionally, each body part has its innate damage taken modifier and they are currently set to these values: head - 150%, torso - 100%, arms - 40%, legs - 60%, feet - 25%. So the armor value of your footwear is not nearly as important as your body armor, while if you don't wear a helmet to a gun fight, you're taking quite a risk.
All these numbers are subject to change, of course.
* * * * * * * * * *
The last point I want to cover are the armor values themselves. As you might have noticed, the old format of percentage resistance / flat threshold is gone. What we have now is resistance / soak / material type.
Firstly, ignore these particular numbers, they are just random placeholders. I haven't gotten to writing real component specs yet. That said, let's go through all these values.
Resistance is the first line of defense, so to speak. It is checked against the incoming damage in order to determine what percentage of it will go through the armor. The formula goes something like this (there's also armor penetration, armor bypass and other mods, but for simplicity's sake, we're going to ignore those for now):
damage_done = incoming_damage * (incoming_damage / (incoming_damage + resistance))2
So if the resistance and damage values are the same, the incoming damage is multiplied by 0.25. That is, quarter of it goes through. If the incoming damage is twice the resistance, it's multiplied by 0.43, and for the other way around it's 0.1.
This formula is subject to change, of course, pending testing. But the general idea is that the ratio between damage and resistance is what determines the percentage reduction instead of it being fixed on the item. This makes the resistance much easier to scale/progress.
After the formula above is applied, soak value is deducted:
final_damage_done = damage_done - soak
So, unlike threshold, soak will now be an important stat throughout the playthrough as it is always applied at the very end, reducing already percentually reduced value.
The final property of damage resistance is the material type. I haven't started implementing this yet, but the idea is that this will modify the inputs to the formulas above, and maybe even formula itself, depending on the type of the attack and the type of material. For example, kevlar is going to be really good against bullet attacks, but not that good against other attacks.
* * * * * * * * * *
That's it for now. There are a lot more mechanical changes that are either implemented or are being implemented, so expect more dev logs in the near future. But then again, I always say that and then skip nearly a whole year without posting.
Also, follow me on Twitter, where I post smaller tidbits occasionally.
Cheers.
https://stygiansoftware.com/forums/index.php?topic=10348.0
November 17, 2023
Hi guys,
It's that time of the year again. All the stars and planets are in the right position and it's time for an Infusion dev log.
We already showed you the extent to which we upgraded the visual aspects of the engine, but the mechanical changes that I've done so far and am yet to do are just as extensive, and perhaps more radical. I'm going to talk about them one by one, in separate dev logs, as I continue to test, tweak, and refine them.
Our immediate goal with the engine and the game is to (re-)implement a number of items and mechanics, get a few areas together, and get the game in a state where it can be played for real, so to speak. Mainly so I can better asses how all these changes work in practice, but also so we can produce a short demo video and show you the game in action for the first time.
* * * * * * * * * *
So, anyway, let's get to the changes to the armor mechanics and damage resistance in general.
In Underrail, the damage resistance was divided into percentual resistance and flat threshold. Incoming damage would be reduced either percentually or by flat amount, whichever would reduce more damage in any given case. This caused a lot of balancing problems. Threshold was generally either useless or overpowered (especially when stacked in early game), while resistance was hard to progress with armor quality, as its percentual nature made it already scale innately.
All these problems really came to forefront when I was implementing different types of shotgun shells in Expedition. Balancing usefulness of different shells in this system was just impossible and it took a lot of tweaking to make it even remotely decent with liberal use of seemingly arbitrary threshold and resistance ignore factors. At one point I was tempted to just implement a completely different interaction for the shells specifically, but decided against it for the sake of consistency.
Another problem with the old model was that all resistances stacked globally. Meaning: resistances from boots and helmets were equally effective as body armor and they all aggregated when it came to interacting with incoming damage. This made me really hesitant to put a lot of resistances on helmets and boots because, on one hand, I didn't want them to make the high resistance armors completely broken by just maxing (or near maxing) out all the resistances and, on the other hand, I didn't want these items, because of their high resistances, becoming mandatory for characters that use ligher armor in the body slot.
There are other problems too, but these are the main issues, I think.
So how does the Infusion's new system differ from the old one?
In Infusion we're going to have a lot more gear slots, mainly from separating body armor and helmets into multiple component slots. This will provide the player with a lot more damage resistance sources. But unlike in the old system, these resistances will not stack. Instead, they will all interact with any given attack separately. So whenever you're struck somewhere on the body, the game will check what armor covers that spot, and it will interact with that armor piece. If there are multiple pieces, it will go through each of them separately, from the outer toward the inner. E.g. you might have some minor resistances on the overcoat that will interact with an incoming bullet or a stab before your torso armor.
For now, I have no intention to allow the player to choose which part of the target's body they're attacking (Fallout style), but there will be different special attacks / stances that will influence this (e.g. decapitate). Also, elevation and size of attacker and the target will also play a role here. So, for example, attacking someone from an elevated position will give you a better chance to hit them in the head and worse (if any) chance to hit their feet.
Different types of creatures will have different body part arrangements. For humans it is as follows: Head (5%), Torso (55%), Arms (10%), Legs (including the pelvis) (25%), Feet (5%). The number in brackets is the current working chance to hit distribution for a generic ranged attack. These numbers will vary for different attacks and situations, but it should give you some general idea what areas are going to be most important to cover with armor in most situations.
Depending on the armor design itself, it may end up covering one or more body parts. In the example of an armored rig/vest, which is the only crafted armor at the moment that's implemented, in addition to covering the torso, it can also provide some additional protection to arms and legs.
Let's go through the examples above. The armor on the left only provides cover to 80% of the torso part. Like the icon indicates, it does not cover the stomach all the way down. We'll talk about the intricacies of coverage later.
The armor in the middle, however, also sports sleeves and a groin guard. The groin guard covers the rest of the belly in the torso part and also covers the groin area, of course, which falls under the legs part. The sleeves cover the shoulders area of the arms part.
The armor on the right has sleeves, but no groin guard.
Regarding coverage, the way we're going to determine at which point an attack lands in a given body part, and so if it interacts with an armor segment that provides partial coverage, is still under consideration. The tooltip here provides just the coverage percentage, but the icon itself is trying to further illustrate what area of the part is covered. Having 20% coverage in arms at the top (shoulders) is not the same as at the bottom (hands) as both of these can be layered over. It doesn't make much sense that, if you are wearing gloves and shoulder pads, a bullet attack can go through both of these.
The way I treat the coverage number, which is esentially a floating point pair (e.g. 0.8-1.0 for shoulders, 0.0-0.2 for hands), is that 0 is the lowest point of the body part and 1 is the top point of the body part and 0.5 is the middle.
* * * * * * * * * *
Now, if you are an RPG mechanics connoisseur, as you surely must be if you made it this far into the dev log, you might be looking at that armor at the left and thinking how fun it's going to be to get hit by stray bullet to the torso right below your endgame crafting-maxxed armored vest and instakilled 20 hours into your ironman DOMINATING run. And I share your enthusiasm for suffering. However, as this kind of experience might not be pleasurable for most players, there are some additional considerations that I'm going to have to give to this.
One of the mechanics that are in place right now is that there is such a thing as grazing shots, which are basically hits that deal about half as much damage. They occur when the attack roll is within the graze part of the hit chance, the size of which is determined by attack-to-defense ratio. I don't want to get into too much details regarding this right now, as the topic is extensive and this dev log is already too long (it warrants its own). What is relevant for the example above is that the farther you are into the graze area of the roll, the farther the hit lands from the center of the body part.
So, basically, the lethal bullet hit described above would deal half the damage, giving you a better chance to survive. Whether this will be enough to make these situations acceptable, remains to be seen through testing. Just know that I am aware of this potential problem with the system.
So what about other body parts? Are we going to have to cover every bit of our body with heavy armor to avoid the similar scenario? What about getting hit with a plasma gun critical to the pinky toe while wearing tabis? Well, first of all, the chance to get hit in the feet is quite low, outside insects biting you or stepping on caltrops or acid.
Additionally, each body part has its innate damage taken modifier and they are currently set to these values: head - 150%, torso - 100%, arms - 40%, legs - 60%, feet - 25%. So the armor value of your footwear is not nearly as important as your body armor, while if you don't wear a helmet to a gun fight, you're taking quite a risk.
All these numbers are subject to change, of course.
* * * * * * * * * *
The last point I want to cover are the armor values themselves. As you might have noticed, the old format of percentage resistance / flat threshold is gone. What we have now is resistance / soak / material type.
Firstly, ignore these particular numbers, they are just random placeholders. I haven't gotten to writing real component specs yet. That said, let's go through all these values.
Resistance is the first line of defense, so to speak. It is checked against the incoming damage in order to determine what percentage of it will go through the armor. The formula goes something like this (there's also armor penetration, armor bypass and other mods, but for simplicity's sake, we're going to ignore those for now):
damage_done = incoming_damage * (incoming_damage / (incoming_damage + resistance))2
So if the resistance and damage values are the same, the incoming damage is multiplied by 0.25. That is, quarter of it goes through. If the incoming damage is twice the resistance, it's multiplied by 0.43, and for the other way around it's 0.1.
This formula is subject to change, of course, pending testing. But the general idea is that the ratio between damage and resistance is what determines the percentage reduction instead of it being fixed on the item. This makes the resistance much easier to scale/progress.
After the formula above is applied, soak value is deducted:
final_damage_done = damage_done - soak
So, unlike threshold, soak will now be an important stat throughout the playthrough as it is always applied at the very end, reducing already percentually reduced value.
The final property of damage resistance is the material type. I haven't started implementing this yet, but the idea is that this will modify the inputs to the formulas above, and maybe even formula itself, depending on the type of the attack and the type of material. For example, kevlar is going to be really good against bullet attacks, but not that good against other attacks.
* * * * * * * * * *
That's it for now. There are a lot more mechanical changes that are either implemented or are being implemented, so expect more dev logs in the near future. But then again, I always say that and then skip nearly a whole year without posting.
Also, follow me on Twitter, where I post smaller tidbits occasionally.
Cheers.
https://rpgcodex.net/forums/threads/underrail-infusion-dev-log-6-new-environment-renderer.145469/
https://rpgcodex.net/forums/threads/infusion-dev-log-6-new-environment-renderer.145461/
https://stygiansoftware.com/forums/index.php?topic=8939.0
December 6, 2022
Hi guys,
We're finally ready to give you a sneak peak in the new and improved Infusion environment visuals. We've done extensive work on the 2D rendering engine, and while there are still things to improve, we're quite pleased how it looks now. Keep in mind, though, that all the scenes you'll see below were made for demo purposes only and do not reflect how the actual game levels will look.
(enlarge image 1) (enlarge image 2)
First thing we did is increasing the asset resolution significantly. We increased the size of the base tile from 96x48 to 160x80, which resulted in the asset size change you can see below.
Next, for all our prerendered graphics we're also exporting normal and height maps, which allows us to have smoother lighting, but, more importantly, it enables objects to clip through each other. This solves so many problems with sprite ordering and also allows us to easily combine items into interesting environmental compositions.
(enlarge image)
Another important thing that we introduced is actual tile height and sloping, so we no longer have to simulate it with assets that are otherwise logically flat - which used to result in weird discovery and lighting artifacts. This will allow us create more interesting maps, as well as have gameplay mechanics that relate to height (such as falling down, climbing, in-area elevators, etc). We're also going to have to adjust many existing mechanics to take elevation into account, but that's a story for another dev log.
(enlarge image 1) (enlarge image 2)
We've also improved how shroud and fog of war works. It's now much smoother and will no longer leave weird gaps in the map while it's partially discovered as often happens in the old game.
There's still much work to be done with the rendering engine - fluids, decals, creature shadows, post-processing effects, and also many minor tweaks, so stay tuned for more updates. Once we get a bit more assets done, we're going to make a video to show you how the engine looks in motion. In the meantime, let us know how you like the new visuals.
Cheers.
https://rpgcodex.net/forums/threads/infusion-dev-log-6-new-environment-renderer.145461/
https://stygiansoftware.com/forums/index.php?topic=8939.0
December 6, 2022
Hi guys,
We're finally ready to give you a sneak peak in the new and improved Infusion environment visuals. We've done extensive work on the 2D rendering engine, and while there are still things to improve, we're quite pleased how it looks now. Keep in mind, though, that all the scenes you'll see below were made for demo purposes only and do not reflect how the actual game levels will look.
(enlarge image 1) (enlarge image 2)
First thing we did is increasing the asset resolution significantly. We increased the size of the base tile from 96x48 to 160x80, which resulted in the asset size change you can see below.
Next, for all our prerendered graphics we're also exporting normal and height maps, which allows us to have smoother lighting, but, more importantly, it enables objects to clip through each other. This solves so many problems with sprite ordering and also allows us to easily combine items into interesting environmental compositions.
(enlarge image)
Another important thing that we introduced is actual tile height and sloping, so we no longer have to simulate it with assets that are otherwise logically flat - which used to result in weird discovery and lighting artifacts. This will allow us create more interesting maps, as well as have gameplay mechanics that relate to height (such as falling down, climbing, in-area elevators, etc). We're also going to have to adjust many existing mechanics to take elevation into account, but that's a story for another dev log.
(enlarge image 1) (enlarge image 2)
We've also improved how shroud and fog of war works. It's now much smoother and will no longer leave weird gaps in the map while it's partially discovered as often happens in the old game.
There's still much work to be done with the rendering engine - fluids, decals, creature shadows, post-processing effects, and also many minor tweaks, so stay tuned for more updates. Once we get a bit more assets done, we're going to make a video to show you how the engine looks in motion. In the meantime, let us know how you like the new visuals.
Cheers.
https://rpgcodex.net/forums/threads...v-log-5-character-model-customization.144104/
https://rpgcodex.net/forums/threads/infusion-dev-log-5-character-model-customization.144097/
https://stygiansoftware.com/forums/index.php?topic=8781.0
August 3, 2022
Hi guys,
In this dev log, I'm going to give you a little sneak peek of what character customization will be possible in the new engine. Today, I'll only be showing and discussing male characters, but you can expect analogous customization for females as well.
As I mentioned in the previous dev log, we're now using PBR (physics based rendering) for characters. Might not be that apparent in the screenshot below, as all the characters are naked, but it'll definitely make a lot of difference once we start equipping them with gear made of different materials..
Of course, first and foremost, you'll finally be able to pick a skin color. Then you'll be able to select your hair style, beard and mustache styles and colors. Both skin and hair colors will be chosen from a predetermined list, so no orc, alien, or other unnatural silly characters will be allowed.
You'll also be able to choose a face from a predetermined list, though this will probably have the least visual impact due to the size at which models are rendered.
Characters also support having piercings, tattoos, scars and the like, but we'll see how we're going to make these accessible to player. For the most part, you'll probably not be able to choose these at characters creation, but will instead have to earn them along the way.
The most important feature, for me at least, is the body type variety. This you will not be able to pick freely, but instead, your visual body type will correspond to your physical attributes: strength, agility, and constitution. Strength will make you bigger, while agility will make you leaner. Constitution has a more complex interaction with your visual appearance as it is both a measure of physical sturdiness and endurance.
These things will also, generally, apply to the NPCs, so you'll be able to gauge their physical properties from their appearance.
That's it for now. I know a lot of you are very interested to see some environment screenshots, so hopefully we can get those out relatively soon as well. I think you'll be quite impressed with the upgrade from the previous game.
Cheers.
https://rpgcodex.net/forums/threads/infusion-dev-log-5-character-model-customization.144097/
https://stygiansoftware.com/forums/index.php?topic=8781.0
August 3, 2022
Hi guys,
In this dev log, I'm going to give you a little sneak peek of what character customization will be possible in the new engine. Today, I'll only be showing and discussing male characters, but you can expect analogous customization for females as well.
As I mentioned in the previous dev log, we're now using PBR (physics based rendering) for characters. Might not be that apparent in the screenshot below, as all the characters are naked, but it'll definitely make a lot of difference once we start equipping them with gear made of different materials..
Of course, first and foremost, you'll finally be able to pick a skin color. Then you'll be able to select your hair style, beard and mustache styles and colors. Both skin and hair colors will be chosen from a predetermined list, so no orc, alien, or other unnatural silly characters will be allowed.
You'll also be able to choose a face from a predetermined list, though this will probably have the least visual impact due to the size at which models are rendered.
Characters also support having piercings, tattoos, scars and the like, but we'll see how we're going to make these accessible to player. For the most part, you'll probably not be able to choose these at characters creation, but will instead have to earn them along the way.
The most important feature, for me at least, is the body type variety. This you will not be able to pick freely, but instead, your visual body type will correspond to your physical attributes: strength, agility, and constitution. Strength will make you bigger, while agility will make you leaner. Constitution has a more complex interaction with your visual appearance as it is both a measure of physical sturdiness and endurance.
These things will also, generally, apply to the NPCs, so you'll be able to gauge their physical properties from their appearance.
That's it for now. I know a lot of you are very interested to see some environment screenshots, so hopefully we can get those out relatively soon as well. I think you'll be quite impressed with the upgrade from the previous game.
Cheers.
https://rpgcodex.net/forums/threads/underrail-infusion-dev-log-4-laying-the-foundations.143718/
https://stygiansoftware.com/forums/index.php?topic=8710.0
May 31, 2022
Hi guys,
As we promised with the last Underrail dev log, since February we've been focused exclusively on the Infusion project. Here's a little update on how that's going.
We're still ways off from having anything resembling an actual game, as I'm still working intently on the engine and the tools. Much of the old engine is either being changed or scrapped and replaced and it's going to take some time before we can get the new stuff operational.
I'm going to give you now a quick overview of some of the engine work done, and then perhaps we'll get into more detail about these various systems at a later point. A quick note for those of you who have grown accustomed to our standard Underrail (1) dev logs which are usually centered around some upcoming update or a specific set of features: these in turn will be a bit more free-form and will cover whatever we're focusing on currently. They are there not to get you hyped or present you with a polished product preview, but rather to just give you some insight into the game's development and assure you're it's actually taking place.
Firstly, I redid the entire dialog engine and editor and we're now sporting a neat flowchart editor instead of the old tree-based one. I've also added some new technical features that are going to allow us to more easily write more robust dialogs.</p>
Secondly, I've decided to redo the AI from scratch. This time, I'm implementing it as a full-fledge state machine that I'll actually be able to debug properly. We want to add all kinds of proactive and reactive behaviors (inside and outside combat) to our NPCs and to do that we need a robust system such as this. I'm going to go into more details about this in some future dev log.
Next, for the purpose of the first two features, I implemented a simple scripting language that we can use to quickly embed code within our systems without having to write C# functions in Visual Studio. This should make the development much more agile in some areas.
Finally, there are some visual features that have had to be revamped, such as the 3D model renderer. We're now using physics based rendering. I've post any new character renders right now, though I will leave you with that beauty at the end.
I don't have any new fancy environments to show you either, and actually we have regressed with the amount of environmental assets that we have, as we increased the sprite resolution in the meantime and need to re-render the old stuff. This was a necessary step in future-proofing the game, so by the time it comes out, it won't be completely outscaled by monitor resolutions like with our first game.
I'll quickly mention that projectile and particle systems are operational, but are currently lacking (any) content.
That's it for now. I haven't given you much content to comment on, but let us know your thoughts anyway. I've created new General section for discussing Underrail: Infusion on the forums, so feel free yo post any thoughts and the like there, as well.
Cheers.
https://stygiansoftware.com/forums/index.php?topic=8710.0
May 31, 2022
Hi guys,
As we promised with the last Underrail dev log, since February we've been focused exclusively on the Infusion project. Here's a little update on how that's going.
We're still ways off from having anything resembling an actual game, as I'm still working intently on the engine and the tools. Much of the old engine is either being changed or scrapped and replaced and it's going to take some time before we can get the new stuff operational.
I'm going to give you now a quick overview of some of the engine work done, and then perhaps we'll get into more detail about these various systems at a later point. A quick note for those of you who have grown accustomed to our standard Underrail (1) dev logs which are usually centered around some upcoming update or a specific set of features: these in turn will be a bit more free-form and will cover whatever we're focusing on currently. They are there not to get you hyped or present you with a polished product preview, but rather to just give you some insight into the game's development and assure you're it's actually taking place.
Firstly, I redid the entire dialog engine and editor and we're now sporting a neat flowchart editor instead of the old tree-based one. I've also added some new technical features that are going to allow us to more easily write more robust dialogs.</p>
Secondly, I've decided to redo the AI from scratch. This time, I'm implementing it as a full-fledge state machine that I'll actually be able to debug properly. We want to add all kinds of proactive and reactive behaviors (inside and outside combat) to our NPCs and to do that we need a robust system such as this. I'm going to go into more details about this in some future dev log.
Next, for the purpose of the first two features, I implemented a simple scripting language that we can use to quickly embed code within our systems without having to write C# functions in Visual Studio. This should make the development much more agile in some areas.
Finally, there are some visual features that have had to be revamped, such as the 3D model renderer. We're now using physics based rendering. I've post any new character renders right now, though I will leave you with that beauty at the end.
I don't have any new fancy environments to show you either, and actually we have regressed with the amount of environmental assets that we have, as we increased the sprite resolution in the meantime and need to re-render the old stuff. This was a necessary step in future-proofing the game, so by the time it comes out, it won't be completely outscaled by monitor resolutions like with our first game.
I'll quickly mention that projectile and particle systems are operational, but are currently lacking (any) content.
That's it for now. I haven't given you much content to comment on, but let us know your thoughts anyway. I've created new General section for discussing Underrail: Infusion on the forums, so feel free yo post any thoughts and the like there, as well.
Cheers.
https://rpgcodex.net/forums/threads/underrail-infusion-dev-log-3-real-time-3d-models.135662/
https://rpgcodex.net/forums/threads/infusion-dev-log-3-real-time-3d-models.135660/
https://stygiansoftware.com/forums/index.php?topic=5913.0
August 26, 2020
Hi guys,
One thing that we wanted to overcome for a long time when it comes to Underrail's engine are the limitation of the prerendered character models, and in Infusion we're finally going to do it. Character and creature models are going to be rendered in real-time in a style as closely matching that of the (new) prerendered backgrounds as possible in order to retain the established visual feel of the game.
This is going to allow us to display the exact gear on your character, as well as NPCs. If they are wearing a crafted piece of armor, you'll be able to see exactly from what materials it is made (type of leather, carrier vest, metal, etc) and what kind of enhancements it has. Same for the weapons. Also, this will allow us to model the unique pieces to complete that experience of wielding something as awesome as, say, Balor's Hammer. Some mechanical changes when it comes to itemizations are going to follow with this change as well. I'm currently inclined to make the pants a separate slot and I also have an idea for another slot, but I'm going to talk about that more later down the road.
Furthermore, you'll now be able to customize your character by picking their haircut, facial hair (as well as color of these), and skin tone, and maybe even adding tattoos and other features on top of that.
Also, this will allow us to add a lot more animations to characters and creatures which, in addition to the eye candy, will also make the combat more readable as potentially special attacks can now have their own special animations.
Let us know how you like the new models.
Cheers.
https://rpgcodex.net/forums/threads/infusion-dev-log-3-real-time-3d-models.135660/
https://stygiansoftware.com/forums/index.php?topic=5913.0
August 26, 2020
Hi guys,
One thing that we wanted to overcome for a long time when it comes to Underrail's engine are the limitation of the prerendered character models, and in Infusion we're finally going to do it. Character and creature models are going to be rendered in real-time in a style as closely matching that of the (new) prerendered backgrounds as possible in order to retain the established visual feel of the game.
This is going to allow us to display the exact gear on your character, as well as NPCs. If they are wearing a crafted piece of armor, you'll be able to see exactly from what materials it is made (type of leather, carrier vest, metal, etc) and what kind of enhancements it has. Same for the weapons. Also, this will allow us to model the unique pieces to complete that experience of wielding something as awesome as, say, Balor's Hammer. Some mechanical changes when it comes to itemizations are going to follow with this change as well. I'm currently inclined to make the pants a separate slot and I also have an idea for another slot, but I'm going to talk about that more later down the road.
Furthermore, you'll now be able to customize your character by picking their haircut, facial hair (as well as color of these), and skin tone, and maybe even adding tattoos and other features on top of that.
Also, this will allow us to add a lot more animations to characters and creatures which, in addition to the eye candy, will also make the combat more readable as potentially special attacks can now have their own special animations.
Let us know how you like the new models.
Cheers.
https://rpgcodex.net/forums/threads/underrail-infusion-dev-log-2-shiny-particles.133041/
https://stygiansoftware.com/forums/index.php?topic=5762.0
May 16, 2020
Hi guys,
We're slowly wrapping up the work on the next content update for Underrail. This one is going to be mostly oriented towards the water areas in terms of content, and, as hinted before, will also feature mechanical changes to psi. It's coming soontm and I don't really have anything more to say about it until it arrives, so instead I'll show you something cool that we've made for Infusion.
We're developing a particle system for the updated engine that will allow us to quickly make nice looking and varied effects. Besides being an upgrade to the previous system visually, the more important aspect of it is that it will allow me to more easily add new psi, special, and item abilities, because now I can quickly make effects for those, which was the most tasking part of the process. Also, the level designers will be able to use the new system to further customize the areas and really bring the environment to life.
Let us know how you like new visuals.
Cheers.
https://stygiansoftware.com/forums/index.php?topic=5762.0
May 16, 2020
Hi guys,
We're slowly wrapping up the work on the next content update for Underrail. This one is going to be mostly oriented towards the water areas in terms of content, and, as hinted before, will also feature mechanical changes to psi. It's coming soontm and I don't really have anything more to say about it until it arrives, so instead I'll show you something cool that we've made for Infusion.
We're developing a particle system for the updated engine that will allow us to quickly make nice looking and varied effects. Besides being an upgrade to the previous system visually, the more important aspect of it is that it will allow me to more easily add new psi, special, and item abilities, because now I can quickly make effects for those, which was the most tasking part of the process. Also, the level designers will be able to use the new system to further customize the areas and really bring the environment to life.
Let us know how you like new visuals.
Cheers.
https://rpgcodex.net/forums/threads...n-a-new-standalone-underrail-campaign.132226/
https://rpgcodex.net/forums/threads/dev-log-65-codename-infusion.132224/
https://stygiansoftware.com/forums/index.php?topic=5761.0
March 11, 2020
Hi guys,
Back in October I mentioned that we started working on a new standalone Underrail campaign. This is still true, but we've also decided that we're going to give the engine a major upgrade which will help us create a much better game, both visually and mechanically. The thing is - there are certain design and technical decisions that were made early during the development of Underrail that are very limiting to us now, but are not easy to change just due to the amount of content that would have to be redone. So instead of taking a hammer to our beloved game, we're going to improve upon all these things (that we yearned to do for years) in a fresh stand-alone game that will still be based on the same engine core and gameplay mechanics. We call this game Underrail: Infusion.
I'm not going to list all the things that we intend to change/improve upon in Infusion, but I will say that they include both the visuals, as well as mechanics and world design. I'm going to try to post more frequent dev logs, as I did back in Underrail's alpha days, as to keep you guys in the loop. All that you see in these early days you should consider to be work-in-progress. I don't expect we're going to enter full production any time soon - not this year, for sure, as for now we're just focusing on improving the engine, the toolset and optimizing the content pipelines.
First thing I want to show you are the new environment graphics. Keep in mind that Infusion will be taking place in a completely different part of Underrail, so this is not a rework of any existing tile set, but a new one.
I've done a lot of work on the rendering engine and the way the assets are organized and rendered which allows Mac to more easily produce and organize a bunch of different variations of the same object, and also to easily animate them or give them other visual properties and behaviors without having to go into the gameplay code. Inversely, gameplay stuff can now be easily implemented before the assets themselves are made as they are only loosely coupled. This is going to greatly improve our efficiency when churning out new content. Technically, we're sticking with the same tile size (96x48) but we're going to make the tile relatively smaller in regards to objects, that is, everything is going to get bigger, which will increase the graphical fidelity. This is going to affect various combat mechanics as well, but we're discuss this at a later date.
That's it for now. We have more exciting stuff that we've been working on in the meantime as well, but it's not quite ready to be shown still. Let us know how you guys like the new visuals.
Cheers.
https://rpgcodex.net/forums/threads/dev-log-65-codename-infusion.132224/
https://stygiansoftware.com/forums/index.php?topic=5761.0
March 11, 2020
Hi guys,
Back in October I mentioned that we started working on a new standalone Underrail campaign. This is still true, but we've also decided that we're going to give the engine a major upgrade which will help us create a much better game, both visually and mechanically. The thing is - there are certain design and technical decisions that were made early during the development of Underrail that are very limiting to us now, but are not easy to change just due to the amount of content that would have to be redone. So instead of taking a hammer to our beloved game, we're going to improve upon all these things (that we yearned to do for years) in a fresh stand-alone game that will still be based on the same engine core and gameplay mechanics. We call this game Underrail: Infusion.
I'm not going to list all the things that we intend to change/improve upon in Infusion, but I will say that they include both the visuals, as well as mechanics and world design. I'm going to try to post more frequent dev logs, as I did back in Underrail's alpha days, as to keep you guys in the loop. All that you see in these early days you should consider to be work-in-progress. I don't expect we're going to enter full production any time soon - not this year, for sure, as for now we're just focusing on improving the engine, the toolset and optimizing the content pipelines.
First thing I want to show you are the new environment graphics. Keep in mind that Infusion will be taking place in a completely different part of Underrail, so this is not a rework of any existing tile set, but a new one.
I've done a lot of work on the rendering engine and the way the assets are organized and rendered which allows Mac to more easily produce and organize a bunch of different variations of the same object, and also to easily animate them or give them other visual properties and behaviors without having to go into the gameplay code. Inversely, gameplay stuff can now be easily implemented before the assets themselves are made as they are only loosely coupled. This is going to greatly improve our efficiency when churning out new content. Technically, we're sticking with the same tile size (96x48) but we're going to make the tile relatively smaller in regards to objects, that is, everything is going to get bigger, which will increase the graphical fidelity. This is going to affect various combat mechanics as well, but we're discuss this at a later date.
That's it for now. We have more exciting stuff that we've been working on in the meantime as well, but it's not quite ready to be shown still. Let us know how you guys like the new visuals.
Cheers.
as a reminder to everyone, Styg is the moderator of this forum and has engaged in some of those devlog threads. there's more info in them if you want to dig.
Last edited:
