Aethermancer News

How time flies by! After the years spent making Monster Sanctuary, we are happy to be at one of the best parts again: sharing a new game with testers for the first time!

Our studio has been working on Aethermancer since mid 2021, and today, we announce the start of our upcoming Alpha. I’m sure you all can imagine that this is an exciting, but also a little nervous time for us at moi rai games, since this will be the first time people get to interact with our newest game, Aethermancer.

[previewyoutube][/previewyoutube]



Important note: Testers won't be allowed to share gameplay footage in streams or videos, so please keep that in mind if you want to be a tester!
To keep it fair, we are conducting a raffle in our Discord server until April 17th (check #announcements). For every 500 participants, we add +5 tester spots!



Most people are familiar with a Beta, where a game is ready for testing, but can have a few bugs or glitches. The difference with an Alpha, however, is that it’s more rough than that. Instead, the game itself is somewhat further from complete, and anyone who tries it will expect to encounter many bugs. Additionally, an Alpha will be missing various key story and gameplay features in comparison to later versions.





If it’s so unfinished, why would we want others to look at it? Because we have a lot to gain by doing so! By having some people outside of our direct dev team experience the game and record feedback, it can give us insights which we may not have noticed from our perspective. We can always try to plan for anticipating how people will interact with our game, but nothing beats an actual hands-on approach and hearing directly from the players. Using this kind of info can help us evaluate how we’re doing, and if we feel like we’re accomplishing our goals or going in the right direction. Theoretically, we could wait for Aethermancer to be a little more complete before its first introduction to the playerbase, but getting an early checkup can diagnose potential issues earlier as opposed to later. Essentially, we prefer a more community-driven approach to our development processes, like we did with Monster Sanctuary.



If you’re concerned about being qualified, don’t worry, because it’s not overly complicated. What you do is: play the game, report bugs as you see them, and write your feedback about it. “What if I don’t know what to write about?” Have no fear, for in addition to free-form writing in specially designated Discord channels, we will also have a preconstructed survey form. Not only does this make it easier for some to record their thoughts when being asked specific questions, but it also allows us to collate and quantify data into easier-to-digest formats. Having these multiple formats allow differing people to better express themselves for our consideration during the continued development of Aethermancer.



While those participating in the alpha won’t be able to publicly stream game footage, we do have a dev stream scheduled. To be announced next week!



Why are we doing a Raffle? Since running an alpha takes time and resources for us, we have to have some kind of limitation on who can participate in it. To help ensure a certain level of fairness, we have decided to utilize a raffle system to let in a certain amount of people. “But what if I don’t get in?” Don’t worry, because our Alpha occurring means that we’ll have a publicly available demo soon-enough™. So, it just means that it’s a matter of time till everyone can play around with Aethermancer! Join our Discord here to participate in the raffle!

[h2]Hey and welcome to another devlog![/h2]



The world of Terastae is riddled with bugs and odd shapes. I got invited by the creators of this magical world to take a deep dive into all the wondrous flora and fauna.

I, as an entomologist, love the hidden world of bugs and naturally, I had to go and see for myself. For you, my fellow entomology enthusiasts, I have written this guide on how to find bugs and explore them safely. Of course I’ve also shared my experiences here with our lovely Team that granted me access so they can find them too!

In preparation the team told me to still take a monster with me just in case. You never know what or who you come across, right? So my first stop was at the Monster Shrine to pick my companion, The shrine however thought I wasn’t allowed to reincarnate a monster and I was therefore handled like a pack of tomatoes at the grocery store.



One of the most common places to find these small crawlers is at the corners of the cliffs, they especially like those tiny nooks and crannies. Here it's important to keep your surroundings in mind as getting stuck is a real threat. However, regularly you can also find something amiss. This keeps things interesting and, at least to me, makes it worthwhile to check every single corner. Have you experienced the joy a person can get by gently pulling a bug out of the wall?



Alternatively shifting perspectives is another important tool when looking for bugs.being on a heightened terrain making it so you can see further ahead. What some people tend to miss however is that jumping down in between a fence and a cliff for example, makes some bugs emerge from the height. These creatures are so fascinating that I'm usually stuck there for hours just staring at them. Of course, at some point I leave, but it's truly something else.



I continued my journey and was amazed when I saw that not only I was on the hunt for bugs, but some monsters were doing the same thing, copying my techniques. Look at this Ooze's bug hunting skills!



Sometimes you encounter some friendly beasts that just want to cuddle, the environment is not always their ally though, as you can see here:



While most bugs get scared off if you're running by fast, some seem to be attracted by my movement. This made me curious, so I dashed around and found the most peculiar of bugs I’ve encountered so far. Somehow, the bug interacted with the monsters inhabiting this world and made them dizzy and wonky whenever I ran into them. I have to admit, it was quite fun!




Before my trip I was warned about some rare occurrences that 'might happen' while on the lookout for bugs but I didn't realise the severity of the situation until I got stuck in a flying tent myself! After calling for help for a while I finally decided to take matters into my own hands and use some of my unique skill set to get out of the situation. After reporting this incident to the team, they told me to immediately report those since they are hazardous to the inhabitants. Speaking of stones, I discovered something very interesting; I could walk through some of them



After discovering all these awe-inspiring bugs, I felt that it was time to rest, so I decided to take a look around to find a good place to relax. After some scenic detours I discovered this lovely pond and decided to walk through the water. Some monsters wanted to join me regardless of how many times I showed them how easy it was, they just couldn’t enter the water for some reason. So I decided that it was futile to teach them and just cooled my own feet for now.



At the end of the day, I asked to see the monsters up close and personal in combat, but that's something I’d like you to explore for yourself. Unfortunately, the team immediately started removing all the beautiful bugs I discovered during my trip. They said it was important to prepare for the first visits from people outside of the team. It may be a little sad, but I know better, and am aware of this fact: there will always be new bugs to discover or some might re-emerge after a while due to the changes made!

[h2]I hope I could inspire some excitement for bugs and otherworldly shenanigans with this Devlog, and I can't wait to see how everyone will experience this wild adventure alongside me! [/h2]

Hey and welcome to this new devlog that is full of T I L E M A G I C !



I'm Malika and this devlog is all about the tile magic in Aethermancer!
First off, there are two reasons why we use tiles in Aethermancer.
For one, the level generation requires a flexible tool box to put together the environment, and tiles work as the basic Lego bricks to set the foundation. On the other hand, it saves time. Even if I were to draw the entire environment by hand, I would copy-paste certain unimportant and repetitive segments to save time. Tiles do just that.



Broadly speaking, tiles can be described as images that are arranged in a grid.
Most commonly they are rectangular, but in fact they can come in many varying shapes. There's even 3D variants placed in a three-dimensional grid.



The above is a classic example of dungeon tiles from the old Pokemon Mystery Dungeon: Explorers of Sky
But we're getting off track. The tiles used in Aethermancer are 2D sprites and placed on a square shaped grid and can be separated into three types:

• Borders - they include fences and similar objects that are used as a separator
  
• Terrain - it defines the ground texture
  
• Walls - the walls are basically the separator to indicate higher elevated terrain
  

I'll be focusing on the Border type fence tiles going forward and it's going to get a lot more technical as I will be introducing Tile Magic aka Auto Tiling to you.
While tiles can theoretically be placed without care for their neighbors, this wouldn't look very polished. Just look at these lonely fence tiles.



Instead, it makes sense to have tiles change depending on their surroundings. After all, these interconnected fences look much nicer.



Ensuring that a placed fence tile automatically adjusts itself to its neighbors is what auto tiling is all about. And making auto tiling work requires both a comprehensive set of rules that work in all different placement scenarios and a full tileset that covers all variants needed to visually represent the changes.
In the fences' case, I use a tiling method known as Wang tiles. More specifically, the fences use the 2-edge version.



Think about it: In the previous example with the fences, each fence tile wants to add a connection to the side where it has a neighbor. Since they are square, they can have 4 sides and respectively up to 4 neighboring fences that they could connect to.
That's why, if you look at it more abstractly, each fence tile can be divided into 4 parts like so:


Each segment can either be connecting or not connecting. This makes for a total of 15 different cases - the amount of different tiles that is required to cover all cases (If you were to rotate your tiles, it would be even less for a total of 6 cases. But that wouldn't work with the perspective of these fences).
It's because of the 2 different states (connecting or not connecting) applying to each edge, that this tiling method is called 2-edge Wang tiles.

Here's the resulting fence tileset.



You might notice that there are two completely non-connecting fence pieces. They are basically the same in terms of rules. It's a case of: the single fence pole looked weird, so I added another version but couldn't bear to throw away the first approach. It might come in handy, right… right?

The auto tiling requires one rule for each tile.
Here is what this looks like in unity:


As with so many things in game development, the set in its current state has one major downside:



The tiling rules are telling the fences to behave this way: to connect to all neighbors. Still, nobody would build fences like this.
Instead, it should look somewhat like the following picture.



It took quite a bit of trial and error, but in the end I solved this issue with more auto tiling magic by adding another set of rules to the same tileset.

What if we could tell the tiles that there is an inside and an outside to a fenced off area?
To do this, I added a 16th tile to the set that was ~drum roll~ empty!



Then I added additional rules that checked if the neighbors and corner neighbors are also fences.


Take this new rule as an example. Before it would have created a three-way connector if it had a top, right and bottom neighbor. Now it also places a straight piece. This is because it knows that its right-hand neighbor fence also has a north and south connector.

In addition to these alternate rules for existing tiles in the case that all the surroundings are occupied by fences, including the corners, an empty tile will be used instead.

I know this is all rather confusing. And I'll admit that the whole thing gets a bit complicated. It took me a few trials and failed approaches to complete a working set of rules.
But I'll spare you the gritty details and demonstrate the auto tiling of this awesome set with 16 tiles and 31 tiling rules.



I can guarantee that drawing fences with auto tiling is weirdly satisfying.

[h2]I hope you had fun reading about tile magic despite it getting a bit technical! Maybe you're even ready to create your own satisfying auto tiling set?[/h2]

Hey and welcome to this new devlog where we will go on a secret mission to sneak into the map generator and see how it works.



In Aethermancer we use procedually generated maps for our overworld, that are based on different biomes. If you want to learn more about what our maps in general look like before we get started, feel free to check out this tour of Terastae we did earlier this year. I will keep this non-programmer-friendly since we'll mostly be talking about the logic and system behind all of our maps - so let's get going!



Depending on how you want to generate the map, there are multiple routes you can go. In general there are two types I would distinguish: You can use noise as the base (Minecraft does this) or you can use rooms (most roguelike/roguelites use this). Since we need quite a bit of control over what we generate and how much space we need, we're using a room-based system. However room-based does not mean that you will be trapped in one section of the map, it’s more used as a base for the generation and will still allow you to roam around the map and explore.



So the first thing we need is a general layout for our map that is based on rooms. Depending on what exactly you want those can look quite different. Below is what one of our maps would look like, which we will use as an example for now. All of our areas have four points at which they can connect: North, East, South, West. Depending on which points are connected, we end up with different shapes for our areas: O-area (1 connection), I-area (2 connections, which are counterparts), L-area (2 connections, which are not counterparts), T-area (3 connections) and X-area (4 connections).



Okay, now we have the basic structure for our maps but if you run across that map, the shapes are a bit ... meh. So instead of using the basic shape of each room, we use something called area prefabs. These contain predefined shapes (and a bunch of other things) which we use to define which part of our room is accessible and inaccessible. We are using a mix of these area prefabs that are then procedurally filled as well as completely hand-crafted, premade areas. For the sake of this devlog we are ignoring premade areas.



But there's one thing about these prefabs that is restricting them. If we have a room that connects North & South we can't use a prefab that connects East & West right? So we would need two different ones. If we now look at O-, L- and T-areas, we would also need 4 different ones just to cover every direction once. That seems like a lot of work so why don't we use a trick and do some sneaky magic to get rid of our problem? The solution we're looking for is rotation. By turning our area prefab we can make it fit for all rooms of the according type. Now we (in theory) only need one are prefab per room type, but if we use more than that it adds even more variety to our map. We use quite a few currently and there's always the option to add more.
Now we have a map that has a defined accessible area. Which is cool but ... we actually need to decide what goes where and how we want to fill the whole map? If we just filled it with tiles depending on if it's accessible/inaccessible that would be really boring ... and we don't do boring at this company so let's make this map pretty! For that we're using subbiomes which define how a room gets filled in terms of terrain and props. So depending on what subbiome and what area prefab we use, we end up with different rooms, which is pretty neat. Now that the accessible part looks cool, let's get to work on the inaccessible part!



So the first thing we'll need to do is determine how much of the inaccessible part of the map we actually need. There's little use in generating a bunch of things on the other side of the map if no one is ever going to see it, because they can't get there. So we're simply going to extend our current outer border depending on how much space you can usually see on the camera.
Let's figure out what cool stuff to place and where we want to put it. We could come up with a general structure of what we want the inaccessible area to look like and place that everywhere but again ... that's kinda lame. So let's divide the outer area into chunks, we're using the lazy flood fill for that. The nerds that want to learn more about how it's done can check out this video, for everyone else: We now simply have multiple smaller areas we can work with instead of one large one.



Previously I mentioned that the subbiomes have more information stored in them, among other things they also store what type of inaccessible subbiome can be placed next to them. This enables us to place inaccessible subbiomes with more intent so that things feel well placed instead of misplaced. Each biome can have its own type of border (e.g. water or fences) as well as a collection of different props that get placed in the area.



Okay now our map look quite nice and like a charming place to fight monsters. Now that's all, right? Well you know, it's a pretty good map but ... isn't it ... kind of ... boring ... in some places? Don't burn me just yet because we have more exciting stuff to add to the map! What if we wanted to aim higher and ... add heights?

For that we'll use a simplified version of the Wave Function Collapse. You can use Wave Function Collapse for a bunch of things but we will mostly use it to determine what kind of height we need where, which is a lot simpler than other cases where you can use it.
In our case we have the following basic rules:

• Each area has four sides (North, East, South, West)
  
• Each side can either be connected or not connected to another area
  
• Each side can either be a height or not a height
• If two areas are connected, the connecting sides have the same properties (since they are kind of one thing)
  

Keeping these rules in mind, we can determine for each connecting side whether it is a height or not. Any non-connecting side could be either, so for them we randomly decide whether they are a height.



Okay so now we know which side is what but ... what now? Well, the good thing is each of our area prefabs also has a height prefab for each combination, so we can use them to determine what positions end up being heights (aka what the actual heights look like).
This system makes sure that all combinations make sense and while also giving us a lot of freedom of how we want each height to look like. As long as the sides connect with the right heights, we can do all sorts of weird and cool stuff with heights without risking the map being unuseable (in most cases, there are still some restrictions as there are with almost everything).



[h2]I hope this devlog gave you a glimpse of what is going on behind the map generation of Aethermancer! We do have a bunch of other things that are going on in the map generation, but this devlog is already quite full with information so we'll keep that for another time.[/h2]

In today's devlog, we're pulling back the curtain once again to unveil one of our most versatile tools for making Aethermancer: Gradients. These unsung heroes in our toolkit are the secret sauce that breathes life into our visuals. Now, I know we're delving into the technical nitty-gritty, but fear not! We'll kick things off gently, gradually wading into the intricacies that make Aethermancer tick. There's a bit of something for everyone on this journey. Are you ready to witness the alchemy behind the scenes? Let's dive in!

Let's lay the groundwork: What even is a gradient? A gradient is a smooth transition between two or more colors. We can use it on a texture to avoid harsh edges, or we can use it to visualize the change of a color over time (called "Location" in the screenshot), which is ideal to take our animations to the next level.



Let's take a look at the fire in the game for example. Without a change in color the fire would look monotonous, static and, well, not really like fire.



Now if we use a gradient, we can breath some life into the inferno. We start with vibrant yellows and whites, converging at the heart of the fire to create a scorching, radiant core. Then we seamlessly transition to fiery reds and further to deepening hues of dark, red-ish brown. This allows us to mimic the nuances of actual fire.



Gradients don't always have to be linear though. We can also adjust them to take on any form we want. We could bend them into the shape of our monsters, or in this case the shape of the Aethermancer themselves (well, actually the dash if you want to be nit-picky):



Here's where it gets interesting. We're not transitioning between colors anymore. Instead this gradient describes how bright or dark parts of the image should be. With this brightness gradient we can make different parts of the Aethermancer glow. Now let's dim the lights and step into the game so we can take a look:



Now that we've established that we can use gradients to not only hold colors, but also other information, here's another example, that you might already have seen in action if you've followed the development of Aethermancer for a while.



Gradients like this allow us to mark different parts of our monsters for different effects by overlaying this gradient on top of the monster. Each hue holding an encoded information. This example comes into play when a monster meets their fate in combat. The dark tones mark the parts of the monster that disappear first, while the bright parts are the last ones to disappear.



I know it is hard to imagine, but the power of gradients doesn't end there. We can do more cool stuff, when we don't limit ourselves to the exact shape of a monster when we make gradients for them. A while ago I shared this blobby looking image on our Discord:



To the untrained eye it might not be immediately apparent, but Dark Elder is hidden in this texture. Each pixel in this gradient texture contains the information how far away it is from the outline of Dark Elder. A white pixel is 32 pixels away on the outside of the monster, a black pixel is 32 pixels away on the inside of the monster and a medium grey is exactly on the outline of the monster. (For the more technically inclined, this is called a signed distance field or SDF).



With this gradient we can create outlines of an (almost) arbitrary width, without having any issues.



For comparison, before we had that possibility we used to make outlines by displaying the monster multiple times with a slight offset. That works reasonably well for thin outlines (1-2 pixels), but breaks apart once you want thicker outlines or when you have a lot of pointy elements like Naga's spear



We're also using gradients and gradient textures in a lot of other places, like the Aether crystals, the wind simulation, our fake 3D, our lighting and more. But this devlog is already pretty long, so I won't cover them here. If you are interested in hearing about any of those topics or want more information on any of the topics in this devlog, let us know!

[h2]Hope you guys enjoyed this look into some technical details of Aethermancer. If you want to directly ask our Tech Artist Basti about VFX topics, head on over to Reddit to a little live q&a:[/h2]
r/AethermancerGame