1. The Shadowed Rune
  2. News

The Shadowed Rune News

Halloween update: The Night of all Souls

The Halloween Update for ‘The Shadowed Rune’ is now available!

Face the dungeon on the “Night of Souls”: the Awakened Ghosts are waiting to scare you and steal your soul... Use the new Bone Mask to defeat them and collect as much candy as you can to regenerate your stamina...

One last thing: watch out for the new Labyrinth of Terror before facing the Guardian Golem...

Are Maia and Brishen ready to defeat the darkness?

[previewyoutube][/previewyoutube]

Patch Notes:

- A new mask has been added: the Bone Mask, which allows you to deal physical damage (physical damage, for example, can break cracked walls, just like the Earth element).
- Halloween Pumpkins and Soul Candies have been added. These candies will give you stamina points and experience.
- A new enemy has been added: the Awakened Ghost. It is immune to darkness, so it’s best to use other elements to defeat it.
- The boss room has been modified, and a new room called the “Labyrinth of Terror” has been added, featuring puzzles, enemies, and lots of darkness...
- Various bugs have been fixed, and some quality of life improvements have been made. For example, when opening the Compendium, the default tab is now the Arcane Spells tab.
- Enemies can no longer deal contact damage while being destroyed.
- The wind element can now put out fire

The Halloween update will be available until November 17, so don’t miss the chance to play it!

Dev Diary III: We launched demo!



Demo Launch!

It's been a few months since the last development diary, but it was all for a reason: I’ve been working hard to launch a demo in September! Also, we presented the game at our stand at Indie Dev Day in Barcelona, so we had to put in extra effort to polish the game as much as possible. But now, with the demo complete, it’s time to take a breath, relax, and share all the updates with you:

1º NEWS


Many months have passed since Roguelike Jam 7. After the Jam, we started the project from scratch, considering everything needed to create a complete game, keeping what worked and discarding what wasn’t necessary. In May, we completed the first demo to send to Indie Dev Day and participate in IDD. From May to August, I’ve worked on a second demo with a complete foundation, ready to be expanded with hundreds of levels, items, enemies, and spells.

- The dungeon system presented in the previous Dev Diary is complete, so the next step is to create levels to fill the system. I used this system in the demo to fix a seed and handcraft a dungeon by linking a series of separate rooms to test that everything works correctly and that the experience is what we intended.
- Artifact, chest, shop, and reward systems, with a small sample of each system in the demo dungeon.
- New enemies with various abilities and variants.
- A final boss with multiple phases.
- A multitude of new puzzles, traps, secrets, and dungeon-specific mechanics.

2º KEY FEATURES


[h2]RUNE SYSTEM[/h2]

[previewyoutube][/previewyoutube]

Real-time combat with the ability to swap rune orders at any time to modify your attacks and adapt to enemies using the power of the runes: Seven elements are included in the dungeon for you to experiment with.

One of the things I will keep improving and explaining after the demo is the Transfer system that each element has.

Besides elemental damage, which is obvious, the runes have a special characteristic that is shared with all the equipped elements. When you cast a spell, the active element determines the type of damage, but all equipped runes will enhance the spell with their extra features.



For example, Wind makes spells bounce off walls. If you cast a fireball with several wind runes equipped, the projectile will bounce several times before destroying itself. However, if you use water runes instead of wind, the projectile won’t bounce but will penetrate multiple targets. The elemental effects are explained in the compendium.

Additionally, each extra element of the same type adds two additional projectiles, just as powerful as your primary one. The key to the system is understanding which auxiliary runes are worth equipping:

Do we want projectiles to bounce? Create explosions? Chain together? Or maybe move faster? There are also additional synergies to experiment with: Each element followed by the same type adds a bonus, and if the last element matches the first, you get another…

Ready to create your build?

[h2]ARCANE SPELLS[/h2]



Arcane spell system that you can discover and use based on the order of your equipped runes.

Expert players will find as they progress through the game that unknown spell messages appear to unlock. These spells break the normal system and can be anything from healing spells, summoning, large explosions, or special projectiles.

Some of these spells are very powerful, so they had to be limited and balanced in some way: mana crystals. These crystals can be collected in the dungeon or as rewards for defeating enemies and are consumed when using spells. Managing these crystals is key to casting arcane spells at the right time.

[h2]ARTIFACTS[/h2]

Mask and artifact systems, which modify gameplay in unexpected ways. To save time managing the inventory, all artifacts you find are added to the top of your interface. You can consult the compendium at any time to check their characteristics.



Currently, there are 3 types of artifacts:

Masks: You can only have one in your inventory, and you can equip or remove it at any time. Its effects only apply while it’s equipped. If you obtain a new mask, it replaces the previous one.

Rings: Provide passive effects that are always active.

Potions: Add an extra effect, either immediate or lasting for a set time. Consuming a new potion will replace the previous effect.

Compendium: After the spell and artifact systems, the Compendium is the 3rd pillar of the game. Once found, it records all the items, arcane spells, characters, and enemies you encounter. Each entry will have a brief description and even some lore, so you can learn more about the story of 'The Shadowed Rune.'

You can check the Compendium at any time, making it a useful tool for viewing spell formulas or understanding the characteristics of some activated artifacts.

[h2]3º SOUND DESIGN[/h2]


We have updates here as well: Félix Herrero, a professional musician, joins the team. He has composed several tracks for the demo that give it a unique and special touch.

At the same time, we’ve worked on a dynamic music system for combat. The same exploration theme transforms into combat music when a battle starts, maintaining instruments and the song's position. Listen carefully—it’s impressive!

We’ve also added some voice acting for special moments to enhance the atmosphere during exploration.

4º ACCESSIBILITY


One of my major goals for the game is to make it as accessible as possible. We’ve even integrated accessibility into the game’s lore.

After starting tests with the Steam Deck, the first step was to add an option to enlarge the game’s text when necessary, making the experience perfect on this platform and small screens.

Additionally, I’ve added a system for help texts that can be activated or deactivated, indicating which keys to use for common actions beyond attacking or dodging. For example, during testing, we found that players were not using Arcane Spells because they forgot which key or button to press to unlock and activate them, so we added this tooltip.

Finally, within the mask system, we created a special mask designed for playing with young children or players with aiming difficulties. When equipped, the player will automatically attack the closest enemy. As mentioned, the description of this mask indicates that it was created to help "novice sorcerers," so it is fully integrated into the lore.

5º DEMO CONTENT


The demo can be played in both single-player and two-player modes, so don’t hesitate to start in cooperative mode, as it doubles the fun.

The demo works as a "vertical slice," so the player starts with more life and 5 rune slots. This way, the initial difficulty is slightly reduced, and progression is controlled over a shorter playtime, allowing players to experiment with advanced combinations.

The demo includes:

- The story prologue, which serves as a tutorial. It’s divided into three sections that will teach you the basic mechanics of runes and element combinations.
- A special fixed-seed dungeon: It’s generated with the random generation system but always with the same seed, so the experience is controlled and you can enjoy a balanced and fun experience. Upon completing the dungeon, you’ll face a challenging final boss (not everyone defeats it on the first try).
- There is also an option to jump straight into the dungeon, skipping the tutorial and camp.
- Additionally, although the dungeon is not random, the items and artifacts are, so in each playthrough, you’ll find different objects, potions, and masks to try out various builds.
- Lastly, several arcane spells are activated for discovery and use, just by finding their rune combinations. You can create healing spells, summon flamethrower turrets as combat support, and more.

Here’s a gameplay video by Chiadow, a friend who recorded a super cool video about the game, with interesting gameplay:

[previewyoutube][/previewyoutube]

6º WORK PLAN

After the demo launch on September 24th at 6:00 PM, I’ll spend a few weeks fixing any bugs that might appear and listening to the community for feedback to implement gameplay improvements, content, etc.

That said, we’ll gather all the feedback from the demo and start preparing the Early Access version, focusing the next few months on creating all the necessary content to launch it in the first half of 2025. When will it be ready? When the game is done.

Development Diary II: Random Dungeons

Hello again! Over the past few weeks, I've been busy preparing for the Indie Dev Day in Barcelona and promoting the game (I'll have a small stand there).

However, I managed to find time to develop one of the systems I had pending to implement. Although it was planned in the GDD, implementing it in the game can always present challenges.

As I mentioned in the previous development diary, the goal was to work on smaller dungeons, between 4 and 6 rooms (including entrance and exit), so they are relatively short (about 5-10 minutes). The tower where 'The Shadowed Rune' takes place consists of 7 main floors. Each floor is divided into several sections. Each random dungeon will be one of these sections. The last section of each level will be a boss fight. After defeating it, you'll ascend to the next floor of the tower. All sublevels will share the same theme.



The challenge? Making these 'mini-dungeons' interesting. As the game's description states, the key is to combine action levels with puzzle levels that force you to use elements to solve them. Therefore, the room positions must be random and offer enough variety to surprise the player.

Each floor has a theme based on an element, but that doesn't limit the appearance of others. However, it does influence the type of puzzles that will appear.

Another reason for dividing the structure into rooms is to facilitate cooperative play. It's clear that completely disconnected rooms could be created, where you move from one to another without returning to the previous one. But I think we would lose one of the strengths of 'The Shadowed Rune':

Each room (called Chamber in the programming) is designed separately, to test it with semi-random bases of connection between objects - activators - runes - enemies. Others will be more closed puzzles, but I hope to have enough variety to avoid repetition.

The initial idea is that the room can be completed with the elements it provides. This ensures that the player doesn't get stuck because they lack an element or a previous rune. But if they have other equipped runes and other elements available, they could access secret areas, solve puzzles more easily, and get better loot. (The game is filled with small rooms and hidden areas with storerooms and loot that can be accessed with the right runes, without compromising the normal progression of the adventure).

This also allows you to complete the entire level and, before crossing the last door, decide to take a small detour and explore areas that, with a recently obtained rune, might lead to a hidden area.



On the technical side, I can share that each tower floor is laid out as a 4x4 grid (16 cells) (enough to create different types of layouts). When you leave the camp, the character enters the first level of the tower: "The Flooded Basements."

At that moment, the game starts generating, choosing one of those 16 cells as the target and moves, creating a path according to the programmed algorithm until it reaches the fixed limit or completely blocks. In that case, it places the character in the initial room, and the adventure begins.

I am creating this system from scratch, without using third-party code, to ensure I have control over it at all times. The main design challenge was to create a basic layout for the 16 tower positions and ensure that the paths are always connected during creation.
These were the first tests, only with terrain and some objects:



Going deeper for those who might find it useful. Each room is designed in a small, closed level. Once tested, it is saved in files for later reuse. This way, we can have hundreds of rooms without loading them all into memory, as only the necessary ones are loaded, even allowing the combination of “tiles” and “instances” in separate files for even more combinations.



Once everything is initially set up, we design the rooms with basic walls and floors and include collisions adjusted to the Z-axis. Now the code knows which room to place in each space. However, it doesn't know if there are other rooms next to it, leaving many paths open. I tried to solve this by creating small storerooms and dead-end paths, but it didn't convince me. These small storerooms could be part of the already created rooms, without needing so many additional elements.



The appearance created was a bit "strange" since it left remains of rooms that couldn't be played because they were inaccessible, so this first iteration was discarded.

Once again, we returned to the design phase and changed the way rooms are created. In the first version, all open rooms were created based on their position, whether it was a corner, etc., but always with the maximum number of open paths. This created a lot of debris in the form of tiles and inaccessible objects.

For the new version, I segmented the layout creation into three phases:

1st Phase, a zone from the 16 available is chosen, and the starting room is created.

2nd Phase, using a 4-direction system, the dungeon layout is created. At this point, the rooms haven't been created yet, only marked which rooms are activated for the dungeon.

3rd Phase, as the dungeon is already created, we can now sequentially check the relationships between rooms. Each room checks the 4 directions (north, south, east, and west) and chooses its most suitable layout with the necessary connections. This way, each room now has more consistency, and I don't have to find patches to close open paths.

Here are the results after the first tests:





As you can see, the dungeon now "looks like a dungeon," with everything connected. However, the system still needs refinement. I added checks to ensure that when a dungeon doesn't generate with a minimum size, it resets the generation. It should also always create an entrance and an exit door. If it doesn't, the generation resets again. These steps are invisible to the player since the generation occurs during level transitions with a fade to black, making these small delays imperceptible. We'll continue improving the system later, but for now, it's sufficient to move forward in other game areas.

The most interesting part of this is content generation:

Each room, once its layout is chosen, can be filled with whatever we want, as long as it respects the entrances and exits. This means I can create hundreds of small rooms with different layouts, even separating decoration content.

Currently, I am considering variations of different basic layouts:

Large room, rounded, narrow, diamond-shaped, divided into sections, divided corridors, etc.
And each with different content variations adapted to the layout:
Enemies, puzzles, traps, enemy waves, bosses, treasures, shops, and combinations of the above.

The difference between an empty room and one prepared with content (this way, the scale of each room is better seen).



With in-game lighting:



How do you complete each level?

By reaching the room with the closed door. Each level will have a closed door that opens by fulfilling a condition in that room. The player must discover it:

Solve a puzzle in the room.
Defeat all the enemies in the room.
Defeat a mini-boss.
????

Thanks for reading! See you in the next Devlog!

Dev Diary I: From Jam to Steam

First of all, I would like to thank everyone for their support. I am super happy with the reception 'The Shadowed Rune' has received. My commitment now is to develop the best game I can and be completely transparent with the community. That's why I've decided to start a series of development diaries, sharing details about the game, the progress, and explaining why I've made certain decisions. This way, you can learn more about the game, and at the same time, I can hear your opinions, receive your feedback and suggestions, and make the game even better.

Development Diary I: From Jam to Steam - Everything Starts with the Tutorial


The Shadowed Rune was born as a Jam game, created in 2 weeks. After receiving positive feedback in the voting, I decided to prepare a new version, researching lighting and gathering feedback on what worked and what didn't.

The main feedback was the significant difference in mechanics between the tutorial and the "dungeon." I created a very detailed room to teach you the main mechanics. But the next room was a huge level full of enemies, pots to break, and runes to collect. The problem was that it quickly became repetitive, the level was enormous, and it was easy to get lost and find the way to the Boss from the Jam version. I took all this into account in the GDD for the next version.

The 1st decision was to redo the tutorial after creating a solid foundation. Using the Jam base, I rewrote and optimized all the code to prepare it for a larger game without any poorly programmed elements that could limit it. The tutorial was crucial in this game since it has more complex combat mechanics than other games, especially being a family-friendly game that you could play with your child or partner. I wanted to respect the story I was creating but also avoid constant system messages that stopped the action (it was also a hassle to press text 10 times every time I tested something). The solution I found was to create pop-up texts when approaching certain places in each room.



This tiny character was already planned to appear later in the tower as a being who likes mana crystals and trades them for other items. It was the perfect opportunity to help explain basic functions like "push/dodge," rotating runes, or deleting them. Additionally, it would also give hints if someone got stuck.

The 2nd decision was to make the game cooperative from the start. It would be local co-op with an online option via Steam's Remote Play Together. Once I rewrote the control of the first character from scratch to add some improvements, creating a second player was easy, but making everything fit was another story... the game is designed to be played with keyboard and mouse and gamepads, but each player needed to choose their character, have their own key mapping, and this had to be shown in the game. Imagine the mess, especially using Game Maker where nothing is pre-made, and you do everything from scratch... For example, one of the features I had to discard almost immediately was the camera zooming out, because if players separated too much one of other, the lighting system caused a significant drop in performance. It was a shame because it was a very useful effect without resorting to a split screen.



When you control a single player, you have two camera options. If you move the mouse/right stick, you can look in that direction like in 'Nuclear Throne'. But if you don't touch the stick or mouse, the camera centers on the player, and you can play like classic 2D Zelda, even if you don't need to fight, you can control everything with just the keyboard...

In co-op mode, the camera works more simply, centering on a point between the two players and always staying centered. This limits the players' movement (they can't go off-screen or separate much), but in boss fights, it gives a lot of freedom, usually keeping the boss in the center of the room with enough visibility to dodge and attack, just like when there are many enemies.



The main challenge in the last month has been coordinating everything so that the game and story work whether you play solo or co-op. It didn't seem right to start playing in co-op and then tell the second player, "Hey, you have to wait 5 minutes to play." So, when you start playing, we take the opportunity to introduce the second character, Brishen, and how he finds his artifact. In single-player mode, you find Brishen later with his rune artifact already equipped.

The 3rd decision I made after receiving feedback and considering the co-op mode, lighting performance, and the game's concept was to reduce the size of the dungeons. The two levels that make up the current tutorial are proof of this, as they are small, detailed levels.


First view of the tutorial area.

Additionally, not having huge levels helps ensure players don't separate too much or feel the need to. It also allows me to create more detailed levels with puzzles, combats, and treasures. Smaller but with more quality and even better performance.

What I'm planning are levels with between 3 and 6 rooms at most, each with different challenges to overcome. The challenge now is coordinating the creation of hand-made rooms with random elements and then placing those rooms in a dungeon connected randomly but logically. I've already done some tests, and the results are promising... but I'll talk about that in the next development diary. Thanks for reading!