next »

[OuthousedStudio]

Introduction

Hello everyone, from Outhoused Studios!

We of Outhoused Studios are working on a new game (Working title "Echoes in the Deep"). It's a dark fantasy roguelike with heavy influence from a variety of known titles in the roguelike genre like Darkest Dungeon and Child of Light.

In this devlog, we talk about the steps we've taken so far, which mostly has been about getting to know each other, starting to make decisions like what our studio (or team) name is, what we're each working on, and what our game's about.

Please find our devlog here





Introducing the team


Fernando's been in gamedev for 13 years, and has very versatile gamedev experience. He has a lot of gamedev tech expertise as well as experience in storytelling, and has also been exposed to a variety of game engines. He's released a few games before and has participated in many game jams. He's worked both as a tech lead and as a dev. He's super passionate about game mechanics and loves to game.

Emile has been learning and applying game development and design for the past six years. He loves to create worlds and lore for tabletop role-playing games and video games, and has participated in many game jams. The most important things to him in his work are to foster a positive work environment, to always keep learning and to work as a team.

Ivan is a Unity developer generalist who “freelanced” for the development of many games throughout his career, most notably Pixel Ripped 1989 and Rise of the Third Power. He's known for having the magic touch when it comes to optimizing graphical quality and performance, while producing awesome storytelling segments through visual effects and animations.

Jacques, has been dabbling in gamedev in Unity for five or so years. I have no released titles to my name but I've participated in a few gamejams. I'm a hard worker and I'm very proud to be part of a very motivated team.

What we aim to achieve with this project


A good thing about this team is we're really trying to limit and clearly define our scope. As such, our main deliverable for the moment is an MVP in which we showcase really the most basic loop of the larger game we plan to make. This MVP will consist of some number of fights, interspersed with some upgrading segments. At the end, we'd have a boss. This MVP would last about five to ten minutes.As for the game itself, in gameplay it would be a roguelike game with an active combat system. We would have a system similar to that of child of light where instead of the combat being completely turn-based, everyone is essentially racing against time to cast their abilities, we believe this would bring a great sense of dynamism to an already very exciting combat experience. As for lore, for the moment we're leaning on the eldritch dark fantastical side, with no clear commitments as of yet, as we're mostly focused on the functionality of the MVP.

What we've achieved so far

As this is the start of the project, our main achievements so far mainly revolve around setting up the foundations for a successful work environment moving forward

We've so far established

- our studio name, and purchased a domain linked to it
- a Discord server in which we're able to centralize communication with the team
- a code repo on Github
- a means of documenting things; we're using a simple Drive, where we share things like meeting notes and action items, coding standards, game design documents, and so on
- a miro board, where we stay aligned on more visual matters, and for game design feature iteration in the ideation
 stage
- a means of defining tasks; we're using Trello, it's working really well for us especially given its easy integration with Github

Art ideation, early stages showcase

We've also begun exploring what we want our visual style in the game to look like. Obviously this is a process we will iterate over a few times before we know what we want to keep but for the moment we're exploring art styles in the following styles.

First we have a style which is very similar to one of our big inspirations, darkest dungeon. Note the claustrophobia and closeness we feel with the characters.

Second we have a further, more JRPG vibe going on, notice the characters are further apart and there are many more layers to this approach, so while it's nice, there are also some impacts to performance.


Thanks so much for reading and following our journey, we'll keep you updated as development occur!

The Outhoused Team

[OuthousedStudio]

Welcome everyone to the second devlog from Outhoused Studios, on our latest game, Echoes in the Deep. In this devlog, we'll be taking a look at the flow our resident master at AI-generated background art, Ivan, is using to make our beautiful dark fantasy visuals.





Note that as this is a flow intended to find images for a background to our game, we will be generating horizontal images.

On the tools used

For our MVP phase (what we could also refer to as pre-alpha) we're using an online tool called Playground. We're using this tool as paid users.

This tool has a lot of advantages for our use case, namely

- allowing you to freely use the image-generating model you train on their site, as well as locally
- providing a seris of easy-to-use AI image editing tools
- auto-saving changes made to both model and images, so if ever connection is lost there's no need to manually re-apply everything

Overview of the flow

The flow is broken down into the following steps

1. Creating the image
   a. We create a prompt that will be used to generate an image that suits our setting
   b. Using our prompt, generate a series of small low-resolution images
   c. We select whichever image best suits our needs
2. Upscaling and cleaning the image
   a. We remove any imperfections on the image, and use AI tools to fill the gaps
   b. We split our image into a series of squares, to be individually upscaled
   c. Upscale the squares
   d. We recombine our upscaled squares and eliminate the seams between the squares

At this point we have obtained a beautiful high-definition background image that suits our esthetic.

Creating the prompt for image generation

When creating the prompt used to create the image, it's important to use as specific a prompt as possible, while noting that playing with the order in which you mention certain details can affect where those details are placed in the image. For instance, the closer to the beginning of the prompt some detail is, the more well defined it will be in the resulting image.

In the devlog, Ivan uses a prompt that specifically mentions a variety of details, and even artists and art styles, in order to really refine the vibe we're going for with our art.

Generating a series of small low-resolution images

For our purposes, it's fine to generate relatively low-resolution series of four images, and from there we can select which is best. In our devlog, we go through several iterations of generation before finally settling on an image that we find both interesting artistically, and with respect to our game's esthetic. We also choose our image knowing that it will be a good image to apply simple visual effects to, like clouds flowing by, or flames dancing.

Selecting the image

Finding the right generated image is itself an art. We selected as criteria that we wanted something against which a battle could take place, that has a dark gothic castle and that was visually interesting with respect to the balance of colours in the scene.

Removing imperfections on the image

Imperfections we had on the image we chose revolved around there being religious symbols on our chosen image, and on there being some rocks closer to the viewer. We want our background to be properly behind the action, so obviously we needed to remove those pesky close-up pebbles.

Using the object eraser, we're able to remove an object, such as some unwanted (in our case religious) object, and AI will use the surrounding pixels will be used to fill in the gap.

Using the simple eraser, we're able to remove the closer rocks and then use an auto-fill option to fill in the spots that the rocks were previously occupying. We made it such that where there were once rocks, our AI image generator simply substituted more fire. We also made further edits to the fire itself, as there was sometimes some unwanted additional details being added to the flames, for this we used the object eraser once again.

Splitting the image into a series of squares

The name of the game after removing imperfections on our image is to split the image into a series of smaller squares to be individually upscaled. In our case, we had an image with a width four times greater than the height, so we used four squares. This meant duplicating the image four times and cropping out the unwanted parts such that we be left with only a square.

Upscale the squares

Given our image squares, we upscale each of them to increase their individual resolution and clean them up of any overly complex details. At this point, they are ready to be recombined into a single image

Recombining the squares and eliminate the seams


In recombining the squares to re-form a single image, the flow is simple, we want to stick our squares together and, one at a time, stick them back together. We eliminate the seams between the squares by erasing the parts of the squares that are touching, leaving a bit of extra room at the foot and head of the seam to allow for the generative AI to fill in the gap between the squares and get a little bit creative with how it repieces the images together.

We repeat this process for all four of our squared images.

Once this is done, we have our beautiful background image!

We hope you've enjoyed this instalment of our devlogs! Please contact us at [email protected]

[OuthousedStudio]

Welcome back to another Outhoused Studios devlog!

This time we're going to make another progress update since the last time we checked in. Last time we went over the steps we've taken so far in planning our MVP. We introduced the team, the tools we were using, and our basic plans for the future. Since then, a lot of things have come more into focus. Today we'll be talking about how we went about making a plan for the character stats, status effects, and abilities we plan to include in our MVP.





Character stats and status effects


We spent a lot of time designing character statuses and status effects. It might sound like an easy thing to accomplish, but we were surprised by how quickly things could become complex. We started thinking about status effects to try and inform the rest of the combat experience, but this wound up getting us thinking about lore, and we started working on that, which was good, but ultimately not the direction we wanted to take for the moment. After a week or so we huddled together and decided that we should prioritize a minimum of features in order to really flesh out the bare bones of our MVP. Finally, after about three iterations over both character statuses and general status effects, we whittled down a list of features we absolutely wanted for our MVP.

Character stats would be made up of health, speed, resistances, and critical chance.
Status effects would be made up of
negative status effects, or debuffs:

• Burning
• Cold
• Shocked
• Exposed

positive status effects, or buffs:

• Charged
• Concealed
• Guarded
• Hastened
• Vigilant
• Inspired
• Defending
• Dodging

Please note that some of the above only became obvious to us after we started defining the characters that would be available to the player in battle, which I'll present to you soon.

Battle actions

We also established which actions a combatant would be able to perform in the context of a battle

• Move
• Use active ability
• Defend
• Dodge

Character stats and status effects

We also established which characters would be available to be added to the player's party. We voted on this, and we came out with the following playable character classes

• Hunter
• Rogue
• Knight
• Wizard

From there, we started thinking about which abilities specific characters could have such that the game be balanced. This led us to define important concepts like active abilities and passive abilities, as well as the effects of different abilities.

What comes next

Moving forward, we're going to be implementing these abilities into our game's code. This will be our next big milestone. In particular, given we have specific abilities that specific characters have (each character has eight abilities), we will set as our next deliverable that each character is able to initialize themselves with their expected skills.

Thanks so much for reading, please contact us at [email protected]

[OuthousedStudio]

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 [email protected]

[OuthousedStudio]

Welcome to another Outhoused Studio devlog! This time we're going to talk about the lore of the game, where some of our inspiration came from, as well as how the lore ties into the gameplay of our game. We haven't delved too deep into lore for the moment, as obviously our attention is mostly on the delivery of our MVP, but it was important for us to align on it early in order to be in sync as a team with respect to the gameplay and the world when we develop our game.





Lore of the game

The context of the game Echoes in the Deep is partly inspired by a manga called Made in Abyss. The player will explore a gargantuan hole filled with all manner of dangers and creatures. We thought that this loop would work perfectly with the roguelike genre; with each failed attempt to reach the bottom, the player will learn and improve, increasing their odds of success with every attempt. The ever-changing nature of the hole and a diverse roster of characters will guarantee variety between runs.

Elemental alignment

Every character will have a random elemental alignment, or affinity. This elemental alignment dictates which elemental damage is added to some of the character's special abilities. Taking wizards as an example; these have a powerful elemental storm skill which can damage several enemies. This skill would be boosted with the respective elemental alignment of the wizard. Elemental alignment is a measure of a character's worship of a certain deity. In exchange for their devotion, the character receives some boons as well as the ability to weild the element related to their god.

Elemental alignment is just one of the ways we are trying to enmesh game design and lore in order to provide our players with a cohesive experience.

Thanks so much for reading, please contact us at [email protected]

Please follow us on our social media
Youtube: https://www.youtube.com/channel/UCAcGI--HC-lrY8bYf_Q4R3Q
Instagram: https://www.instagram.com/outhousedstudio/
X: https://twitter.com/OuthousedStudio

[OuthousedStudio]

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 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. This time we're going to talk about how we've set up a party selection scene and how this fits into the context of our MVP.






How this fits into our MVP


Beginning with how a party selection segment fits into our plan for our MVP, we plan to allow the player to select their party from a roster of characters, and that party would be the player's party for the remainder of the MVP. In other words, they'd first choose the four characters they want to take with them, from the knight, mage, hunter, priest, brawler, and hunter. Notice the priest and brawler haven't been spoken about before, and indeed we haven't defined any abilities for those characters as of yet.
The purpose of the party selection screen is to allow the player to choose the characters they want to have in their party for the upcoming battle, as well as to choose the party slot configuration. Recall that where characters are is significant to the combat experience. You'd probably want your knight to be further to the right, or closer to the enemy's party, for instance. We want to affect the position of each character in the party by selecting the character to be moved and then selecting the slot to which we want to move that character.
We're not sure yet whether we want to have the player choose their party members only once at the beginning of the MVP, or whether we want them to have the freedom to make changes to their roster between fights.

The two-dimensional iteration

Initially, we went for a more two-dimensional approach, with the player party being displayed similar to a series of cards on a table. We implemented a system for selecting the party with mouse clicks. At the time where we made this, we were not yet considering the position of our party characters. This layout looked great and worked very well, but a few weeks later we found ourselves considering a more three-dimensional approach.


The three-dimensional iteration


We found that having a more three-dimensional approach allowed for us to bring the player more into the world of the game. Obviously the background of our three-dimensional selection menu is still subject to change, but it's a good start for the moment! We also added a side panel to later fill with more specific details about the characters being selected. We're now more satisfied with the esthetic of our party selection menu.
We've implemented the functionality of being able to select which characters are added to the party, as well as where the characters are positioned within the party. This is done by clicking the target and specifying a destination, in both cases.

What's coming next


Next on the road map for us is going to be to define a battle scene in which both player party configuration is loaded and enemy party configuration is initialized. This will lay the groundwork for the battle scene, in which our core gameplay experience will be defined.


Thanks so much for reading, please contact us at [email protected]


Please follow us on our social media!

Youtube: https://www.youtube.com/channel/UCAcGI--HC-lrY8bYf_Q4R3Q
Instagram: https://www.instagram.com/outhousedstudio/
X: https://twitter.com/OuthousedStudio

[OuthousedStudio]

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 how we're going to set up a party selection scene and how this fits into the context of our MVP. This time we'll talk about the progress we've made in our battle scene, namely with our ATB combat bar, and the things we've realized on the way.





Our progress on the ATB combat bar


We've said in the past that we want our combat experience to be very dynamic. We also said we were interested in turn-based combat. Our solution, which we find to be a happy middle ground inspired by Child of Light, is to have an active turn based combat system. This means every character moves along the select bar in order to reach the selection point. The selection point is the point at which characters select the ability they want to cast. From there, the player must move along the perform bar to reach the perform point to actually perform the chosen ability. The speed at which a character moves along the select bar is determined by their initiative. The speed at which a character moves along the perform bar is determined by the character's initiative, as well as the perform time of the ability. For instance, some more powerful abilities might require more time to be cast, during which time the player might be open to possible interruptions.

Please note that we also took casting time interruptions into account during the status effect creration and there is a status effect that allows characters to resist interruptions during their casting (wizards in particular).

So far we've implemented an ATB combat bar that consumes our party exported from the party selection screen. From there, a default set of enemies are generated to oppose our chosen party and all battle participants are moved along the select bar with respect to their initiative. Once there, they can select an ability. We've stubbed this in for now. After that, they move along the perform bar with respect to the ability perform time, and once they reach the perform point, the battle participant performs the skill, and an animation in the style of Darkest Dungeon plays before battle is resumed.

What we realized on the way

Something we realized while working on this was that we absolutely needed to find a way to segregat different sections of the combat experience in order to reliably test those sections. It's really annoying, for instance, to have to start from the main menu, select a party, and then get to the battle scene in order to test whether the characters are properly moving along the ATB bar, so we're going to spend some time thinking about how we can better isolate this for development. We're also likely to have the same problem for selecting abilities and ensuring that those abilities have the intended effect on their targets, so this is another reason for us to find a better way to compartmentalize segments of the combat experience.

What's coming next

Next on the road map for us is going to be to define the manner in which we're going to segregate parts of our combat experience, as well as working on the skill selection mechanism.

Thanks so much for reading, please contact us at [email protected]

Please follow us on our social media!

• Youtube: https://www.youtube.com/channel/UCAcGI--HC-lrY8bYf_Q4R3Q
• Instagram: https://www.instagram.com/outhousedstudio/
• X: https://twitter.com/OuthousedStudio