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.
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!
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!