Embark on a dark fantasy roguelike adventure, inspired by Darkest Dungeon & Child of Light! Explore procedurally generated dungeons, face menacing creatures, & unravel mysteries in a world cloaked in darkness. Engage in strategic, active turn-based combat, utilizing skills & party compositions to survive. Immerse yourself in atmospheric visuals & an immersive soundtrack as you delve into a story rich with ancient evils & fateful choices. Are you ready to brave the darkness & uncover its secrets?

Post news Report RSS Devlog 4 - Progress Update: Implementing Skills Data

In this devlog we review some decisions we made on the structure of our combat, the process we went through in our decision making, and finish with how we went about implementing the skills that we came up with in our brainstorming.

Posted by on

Welcome to another Outhoused Studio devlog! This time we're going to make another progress update since the last time we checked in. Last time we went over the characters that would be available to the player in our MVP, as well as the skills each character has. This time we're going to talk decisions we made about how battle would work in our game, as well as how we went about making a system to get the player skills into the context of our game.

Decisions we made on combat

Something we had to talk about in our team and come to a hard decision to was whether or not positioning would have an effect on combat. For instance, are characters fighting in a sort of face-to-face one-on-one configuration, or are characters in slots, and does position matter? In addition, given characters are in slots, do we then need our attacks to affect specific positions? In the end, we wound up going with a system where character positioning matters, using position slots.
In other words, characters who specialized in close-range combat, should be at the slot closest to the enemy party, and that slot would also correspond to the slot typically most in range of the enemy attacks. It became clear that we'd want to keep our weaker ranged battle characters further back from the enemy party and our tankier characters meant for defending or soaking damage should be closer to the enemy party.
The impact of this decision on the skills was that it meant that skills had to be specific with respect to what their target was. We had to go beyond simpler terms like "melee" and "ranged", we also had to specify the specific type of enemy, sometimes as well as the quantity.

Figuring out how data would be transmitted to the game

We spent some time considering what exactly our data structure would look like. We knew we had a bunch of loosey-goosey data types we had to make work together, so we settled on using JSON files to define our skill data.
We needed a way to define skills in an extensible way such that we could express complex properties related to skills, such as properties that modify the potency of a skill, or skills that depend on some other factor being true. This was easily the hardest part of making all this skills stuff work. The difficulty came from having these skills we knew we wanted to behave in certain ways but then figuring out how to make data structures to reflect those expectations. If ever someone is reading this in the future, and is trying to make the similar conversion from abstract to concrete, our advice to you would just be to take it slow, start at the beginning, and don't ever be married to your ideas. In particular, try to imagine how the skill data will need to be interpreted by the context of the game to inform the state of the game to lead from one action to another. For instance, if I have a spell that's a fireball and it targets a specific enemy, I need to be able to know how much damage this spell will deal, who specifically the target will be, the mana cost, these are all things we need to factor into this process. Diagrams can be super helpful at this stage, and can also help you stay on the same page with your team members.
We went through many iterations in this process, as often we would think we found an okay system, but then when we went to implement it, we just would find it impossible to read, or just that there were some shortcomings in the system we were using. We worked on this for a solid week or two, and finally we have something we're pretty happy with.

Side note: character specific stats

Something we didn't mention last week was that another thing we implemented after figuring out which characters we would have in our game was the stats related to each character. We allocated health, critical chance, and other properties to each character and implemented a save and load feature.

What's coming next

Next on the road map for us is going to be the implementation of a party selection system. The plan is to allow for the player to select their party, and once we have this working, we're going to turn our attention to the battle mechanism and flow of combat. These latter items might take some time though, so we'll check in with some other stuff until this is ready.
Thanks so much for reading, please contact us at contact@outhoused.me

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: