[Design] Character Introductions

What I find most inspiring about creativity is the ability to craft a fantasy world, beautiful, new, magical, and completely alien. I have written before about the world-building in Daughter of Dreams and how I wish Somnar to be something different and unique. I consider this game to be a work of epic fantasy, and the story-telling is one of my key design pillars going into this project. The story may not be realized in the game itself until much later in the process, but I have begun designing characters and writing snippets of dialogue from the start. Today I want to introduce those characters. They are merely concepts, so they may change throughout development, but I think their essence will remain the same, only refined.

Sonya is the Hero of Light, who once lead the charge against the City of Shadow, and drove away the enemy, in an event known as the Great Victory. Now, she has been summoned from the ancient past to defend Somnar once again from the dark sorcerer Charon. She is a disciple and soldier of Ta'Reya, and fights with a Sorrite spear destined to defeat the darkness.

Lydia is the Prophet of Light, sent to aid Sonya in her mission. Lydia is an ardent follower of Ta'Reya, and was chosen for her kindness, sincerity, and loyalty. However, the weight of responsibility makes her uncertain, and the grim necessities of war lead her to question even her most deeply held beliefs. But she must persevere in the face of darkness, lest Charon succeed in his nefarious goals.

Duran is an outcast, unwanted by the followers of Light and the common-folk alike. He suffers from a Cinder addiction, a substance which leaves him nonfunctional on the best of days. Furthermore, he bears a dangerous curse, one more terrifying in its power than even the dark magic of Charon. He joins Sonya in an effort to finally commit himself to something valuable, and perhaps free himself as well.

Angela and her familiar, a Void Owl named Kree, herald from a distant land. Angela is an investigative historian, hoping to uncover the lost legends of Somnar, the truth of what happened in the Great Victory. Among those tales, she hopes to find evidence of her ancestors, whom she believes to have originated from the heart of Somnar, yet fled when the City of Shadows fell.

Charon, the dark sorcerer, and the last witness... He has returned to wreck his revenge of the followers of Light, for they once vanquished him generations ago with the aid of Ta'Reya. But they have weakened since, and now he hopes to reverse the flow of time and return the City of Shadow to its former glory. Yet he will find his efforts stymied by an anomaly--Sonya the Hero of Light, human and yet immutable and nearly invulnerable to magical attacks.

Ta'Reya, the God of Light, is the beacon of hope for the followers of Light. The legends say that when the people prayed, Ta'Reya set fire to the Moon of Night, and she is the reason that Somnar has two suns, and will never again to be shrouded in the sinister dark of night. Now Ta'Reya acts again to save Somnar, bringing the Hero of Light back in the hour of need, so that she may vanquish Charon and prevent night from falling again, forever.

Sai'Ra is the God of Pain, among the most dangerous beings to walk the Void. He prefers to work indirectly, and frequently offers his power to mortals seeking great power. He extracts only the smallest price: their eternal pain and anguish. His reach is vast, and his motived are arcane and unknowable... Duran is one who bears the curse of Sai'Ra, and the God of Pain is not quite finished with him yet.

The story throughout Daughter of Dreams will be character driven, a necessity for a procedurally generated game, as it is much harder to tell a linear plot. The interactions between characters will be essential, and I hope to create a flexible system where the various characters may leave or rejoin the current party depending on events in the story. Their unique powers will be expanded upon as I work on the combat prototype, and the specifics of the plot are currently being worked out behind-the-scenes.

What I have presented here is only a brief introduction to the characters. This is an ambitious project, and there is much more depth to the characters that is not revealed in this post. I can't wait to show more details of Daughter of Dreams as I continue to make progress. There may not be many more story information though, as I want to keep most things spoiler-free. Finally, I'd like to thank my brother, who created the concept art used in this post, and will be doing most of the character art for the game itself.

[Programming Notes] Turn-Based Combat System

This week, I implemented the core systems of the new turn-based combat system for Daughter of Dreams. This is one of the most technically complicated pieces of code I've written, though it may not seem like it. The challenging part for me was making it as simple as it is. I believe what I have will be powerful and flexible enough to expand easily to support the entire combat system (and probably in-game cutscenes as well, though GML 2.3 sequences may still be a better option). Abilities are modular, and can be assigned to any entity (player characters and enemies), and the combat engine can transition between states fluidly, as well as undo actions.

What It Looks Like

So far, the combat prototype has two main operations. A character can be selected from any number of playable characters, and they can be given an order to move according to basic grid-based movement. These are merely the simple actions I implemented to test the system. As the game expands, I will add new actions that will be supported by the foundational code that makes up the combat system.

Two playable characters with grid-based movement.

System Overview

The combat system is currently comprised of two primary components.
- A finite state queue of functions which return true or false.
- An index of actions assigned to combat entities (playable characters and enemies).

The logic for the finite state function queue is as follows:
1) Run the current function when the update method is called. (Usually in the step event).
2) If the function returns true, progress the queue to the next function.

Next, an action is defined globally, and can be assigned by reference ID to any entity.

- The action includes all the data required to display the action on the UI.

- The action execute method can assign required values for the entities.

- The action can add functions to the combat function queue to define the logic of the action.

Class definitions shows the essential attributes and operations of each component.

System Implementation

With these components in place, the logic for starting a new combat scenario is as simple as adding each step of the combat cycle to the combat function queue. The logic of each step is handled internally, moving to the next state once that function returns true.

Each step (combat_start, combat_player, etcetera) can divert from the primary cycle by inserting more functions in the combat function queue at its own position. For example, the player phase will allow the player to choose actions for their characters. When an action is chosen, the associated functions are added to the combat function queue.

The final combat cycle can be represented with this flowchart. The primary combat cycle is the Start > Player Phase > Enemy Phase > End/Restart. Each player or enemy action diverts the primary cycle by inserting other phases into the combat function queue. Furthermore, actions could be canceled at certain steps, by instead inserting the previous phase. (For example: with Choose Attack, on "confirm" input, insert Choose Target, but on "cancel" input, insert Player Phase again).

System Pros and Cons

This method is powerful because it is easy to transition from each state to any other state, just by appending the next associated function. It handles the turn-based aspect of the combat with the simple logic of the function queue. Each state is handled in order, one at a time. Actions are modular, so they can be assigned to and used by any entity, instead of programming every ability for each entity.

The downside of this system is that at the moment, the function queue cannot accept parameters. Every function used for combat abilities must return true or false, and be designed to run every time the function queue update method is called. If additional variables are needed (such as timers, or damage values), they must be declared outside of the scope of the function. It is possible I will expand the function queue to use parameters as well, but it will complicate the system.

Additionally, while actions are modular, they also require more code this way than they would if each was more specialized. The move action as it stands uses four separate functions (initialization, player input, drawing, and execution). However I believe the flexibility outweighs this complication.

Stray Thoughts

In the future, I hope to regularly post programming notes to cover the more interesting systems that I develop for Daughter of Dreams. I am learning a lot, and I hope if I share what I've been doing that others might find it useful too. Also, if anyone knows of useful articles or posts covering similar topics, please let me know and I will include them in the resources section.

Resources

• This article informed my approach to modular actions, though my implementation is a little different. Game Programming Patterns - Command

[Progress Update] New Ideas and Turn-based Combat

It has been a long time since I wrote a blog post. Over the summer I had been working on Daughter of Dreams significantly, but unfortunately, most of my designs ended up not working out. Considering the start of a new quarter at college, which was an especially busy quarter for me, I decided back in September to take a break from Daughter of Dreams until I had significant free time again. This has turned out to be a really good decision, and the ideas I had during the summer have been maturing during my break. What I have now is much more solid, so I am excited to now begin in earnest with the development of Daughter of Dreams, as the quarter is over and I have the entire month of December to focus and get some game development done.

I'd like to start this new phase of development with a new blog post covering the most significant changes to my plans and designs. My goal for the month of December is to get a fully working prototype of the combat system into the hands of my alpha-testers. I've been working on character design and story as well, but those are backburner until I have a game engine running.

Turn-based Combat

The first major change to my design is to develop a turn-based combat system. This deviates from the common design of a Zelda-like, which usually has real-time action combat. However, I do not think this is a requirement, as I believe a Zelda-like depends a lot more on key item progression.

The combat in Daughter of Dreams specifically is not fully designed yet. But there are a few features I am considering. I will expand this as I develop the prototype.

• I will use small numbers for combat values, like the way it is done in the classic Paper Mario games. This allows for a more strategic type of turn-based combat, compared to large number systems, as the player can predict exactly how much damage their attack will do and which strategy will be most effective.
• Combat will be positional, like a tactical RPG. I am thinking that the combat will take place on a grid, and attacks will target particular cells in the grid. I believe this will create a unique element to the combat, and allow me to design abilities that require more strategy than simply which will do the most damage.

There are several reasons that I decided to shift to a turn-based combat system. A turn-based combat system is much more theoretical than real-time. I mean that the enjoyment of turn-based combat depends less on the art and animation, and more on the pure design and balance. This plays into my strengths, as I am primarily a designer and programmer, and not an artist. Additionally, a turn-based system better supports multiple characters being present, as they become members of the combat party. This will help with the story-telling of the game, which I want to be a major focus.

Story Structure

I have written previously about the world-building of Somnar in Daughter of Dreams and I believe those elements will mostly remain the same. I have not yet shared many details of the plot itself, but I would like to write about a few ways that the new combat system will allow me to tell a more engaging story.

• The story will depend on many different characters joining the party. This allows me to explore the interactions between characters, have character development, and create conflict through their interactions. Before, I felt restrained to having the main character lead the story on their own, with others becoming background characters limited to specific interactions.
• Characters will maintain their progress between cycles. Daughter of Dreams has always been planned to be procedurally generated, where the main story takes place over multiple cycles. My plan is for character progress to save between cycles. This includes character development and combat abilities and the experience they have gained. With the new design for combat, there can be a sense of progression that is earned over time, through many cycles.

Dungeon Design

While I am shifting to a more RPG style turn-based combat system, I still want to preserve the Spirit of Adventure that is key to Zelda-like games. I have not considered this aspect very much yet, but I do plan for there to still be procedurally generated dungeons, though the puzzles may depend more on unique dungeon-specific mechanics than key item progression. There is also an opportunity to allow particular characters certain abilities in the overworld (outside of combat), which I will explore as I develop the prototype. Overworld and dungeon exploration, as well as puzzle-solving, are still key design pillars.

Stray Thoughts

This is just a summary overview of some of the ideas I have considered during my break over the past few months. I will hopefully expand more on particular elements once I have more design done on paper. I plan to write several more blog posts soon, covering more about Daughter of Dreams and a few other topics. Finally, my priority now is to create the combat prototype. Stay tuned for updates!

[Progress Update] Inventory System

I have made some very good progress over the last several weeks. Primarily I have focused on creating the inventory system for the game. Items serve an essential role in Daughter of Dreams. First, there are the many key items which allow the player to progress through the game. Additionally, the player will collect other optional items, including healing items, charms that grant combat bonuses, crafting materials, and upgrade items. Items are especially important as each region of the game will have its own items, making each one more distinct and interesting. This blog post will cover the features I have finished so far, and explain some of my reasons for different mechanics.

The Inventory Interface

I found it was very challenging to develop the user interface for the inventory for this project. The primary issue is that with the low-bit pixel art, the screen space I have to use is very limited. I wanted to make sure I could show all the information in a compact, but still readable manner. What I ended up with was a grid showing the items, and the name of the highlighted item at the bottom. To show more information, the player presses the B button on the controller, and it will show a dialogue option with the flavor text and options for using the item.

Navigating the inventory and eating a sweet glob.

This method allows all the information to be shown, but I would prefer if the item lore text could be shown while hovering over an item in the inventory. However, the lore is not essential information, and if I were to show it I would need to sacrifice a lot of screen space. The second issue I have with this method is that if you want to use many items, you have to click several times each time to do so. However, as shown in the GIF, you can equip any item to each of the face buttons. If you equip an item first, you can then use it outside of the inventory just by pressing the face button.

I think this is a good solution, at least for now. I will continue to improve it, and hopefully I can show more information on the main inventory screen with some additional tweaks to the design.

Item Rarity

All the items you can collect in Daughter of Dreams have different tiers, indicating how likely they are to appear in loot chests, and how much they might sell for. Among regular items there are dull items, common items, rare items, and legendary items. Some unique items (such as your key items) have the special tier, or the Sorrite tier.

Excerpt from Design Document - Different item tiers.

A special property of legendary items is that they will only ever appear once. Once you obtain a particular legendary item, it will never appear in loot chests again, even if you lose the item by selling it or otherwise. I hope this will make legendary items extra exciting, and of course, legendary items have by far the most powerful abilities.

Status Effects

Status effects are special properties that can be applied to any entity, including the player and enemies. For example, burning an enemy will deal damage over time. Freezing the enemy will prevent it from moving, and deal critical damage if it is attacked while being frozen. Status effects can be applied to entities when they are hit with particular attacks (such as a flaming weapon), or applied to the player when they use a consumable alchemy item.

Consuming a small potion to get the regeneration status effect.

Alchemy items can be assigned to affect the player with any number of status effects, for a particular duration and amplitude. The duration of the effect sets how long the effect will last, and the amplitude will determine how powerful the effect is.

Charms

One feature I really wanted to include in Daughter of Dreams is the ability to customize your combat abilities with extra equipped items, like badges in Paper Mario or charms in Hollow Knight. Charms in Daughter of Dreams require charm orbs to equip, and once equipped provide modifications to the player’s base combat stats, including increasing damage of a particular type that the player deals, and reducing the damage of a particular type that the player receives.

Equipping Charms - Daruk's Fortitude and Pendant of Light.

Many other things are possible with charms, so long as I can add them to the combat stat list. Some other examples include elemental resistances, healing effectiveness, status effect duration, freezing status resistance, and any others that might mix up the combat a little bit. I hope this will provide new options to players and encourage different strategies and play styles.

Excerpt from Design Document - Some different charms.

Crafting

There is one more major feature, which is crafting. This is in many ways an extraneous feature. The game could be fully designed without any sort of crafting, and so I hesitated to implement this feature. But, there are a few reasons I decided to add this feature. Crafting adds much more purpose to items in the game. Each region in the game will have its own set of items, and its own crafting recipes. Additionally, crafting provides me as a designer with more ways to include new items that help make different areas more unique.

Crafting a slimy potion using Green Glob and Strange Leaf

Crafting a new item requires some quantity of one or two other items. You must unlock recipes first by collecting recipe scrolls. There will be many recipes, such that it is unlikely you will unlock all the recipes in one playthrough. Instead, unlocked recipes will carry over between save files. Once you have unlocked a recipe, you can select it from the crafting list (tabbed over from the inventory screen), and choose the recipe to craft it. My goal is to include many crafting recipes using nearly every item in the game. Particular recipes will be useful in specific areas, or combine items from different areas to create more powerful items.

Stray Thoughts

Thanks for reading! I am very proud of how the inventory system came out, and I am glad to share the result with everyone. I actually finished the inventory a few weeks ago, but I have lacked the motivation to focus on my game for a little while. Of an additional note, the GML 2.3 updates are around the corner, and I will need to spend some time then updating this system with new data structures. Next, I will be designing the Flayern area and adding those elements into the game to start doing some terrain generation prototyping.

[Design] The Unique Biomes of Somnar

One of the key challenges of designing a procedurally generated game is in avoiding repetition, and maximizing variety. Procedural content has a tendency to grow stale through repeated play sessions, as the player is eventually able to identify the patterns in the generation, and they end up having the same experience each time, even though the map itself is technically shaped differently. I am approaching this problem from two angles in Daughter of Dreams. First, I am designing the algorithms themselves to produce the most varied content I can manage. Secondly, I want to create variety through the environments in which the game takes place.

To this end, I am designing the game world to be split among a small number of very distinct biomes, each of which can be uses as a base for any of the terrain generation. However, I want to go beyond just having varied aesthetics or graphics for each area. To do this, each biome in the game will be designed with its own complete set of mechanics, including enemies, items, crafting recipes, boss fights, traps, and other interactive objects. All of these elements will be designed individually, and I want to focus on making them all interact in interesting ways with the elements around them. (Something like Breath of the Wild's chemistry engine). This is a lot of work, but I believe I can keep the total scope fairly small, and still get more content variety than I would with a bunch of less unique biomes.

My goal is that by creating these distinct biomes, I can change the game experience each play-through in a fundamental way. The skills the player develops in one biome won't work the same in another biome. I want each area of the game to feel and look different, and also play different, requiring new skills and strategies for each new area the player encounters. Then, I may also combine elements of each biome to create entirely new mutations on the base experience.

A selection of different biomes from The Last Librarian.

World-building of Somnar

These distinct biomes are built into the lore of the game world. Somnar is a land of dreams... It is magically unstable to the point where it is destroyed and recreated on a regular basis. The new lands that arrive each cycle do not follow any necessary consistency. Somnar is barely habitable at all, and every place within it is completely extreme, stark and unforgiving. Somnar can be thought of as a completely alien planet. My goal in the world-building is to make a completely distinct universe. The rule is this: nothing on Somnar should even slightly resemble something we might be familiar with on Earth. Everything is made up from scratch.

This gives me incredible freedom with my imagination. This approach to the world-building allows for any possibility, and by incorporating it into the procedural terrain generation and the story, I think it will help solidify the style of the game and make it feel distinct from any other game. For this aspect of the story-telling, I was particularly inspired by the book series The Edge Chronicles, which I read as a kid. I still remember distinctly so much about the unique world of those books, the inconceivably strange creatures, the Gloamglozer, Sky Pirates, Banderbears... I may not even have a chance of rivaling the world-building of those books, but they certainly provide a vision to strive for.

Flayern Forest

So now I'd like to share some of my ideas for the first area which I will fully develop myself for Daughter of Dreams. It is Flayern Forest... the Forest of Hate. It is completely uninhabitable by humans, for it is already inhabited by the Plants. The wilds of Flayern writhe with twisted life, dangerous, poisonous carnivorous plants. The colors are unnatural... the foliage is a dense myriad of vibrant pink, blue, and red. The only green is the river--the toxic waters that give life to the Plants of Flayern.

Concept art for Flayern Forest -- The trees loom over the still, toxic waters.

There are many types of these evil Plants, many forms of which could barely be conceived of to exist. The ferns bare sharp fangs designed to snag their victims. Sentient vines creep among the undergrowth, trapping and entangling any stray wanderer, so they may soon be dissolved with acidic saliva. Some of the demonic Plants are not even rooted to the noxious soil, and prowl the forests... great beasts on the hunt for vulnerable prey.

Concept Art for Flayern Forest -- I went over there and took notes on what I found!

But among the twisted brambles lie the secrets of the forest. The most succulent and delicious fruits grow deep in the forest, on the branches of the sacred Kafka tree. Many of the most aggressive plants are good to eat, once they have been safely gathered. Indeed, the legends say that all life in Somnar originated from the primordial rivers of the Flayern Forest...

Needless to say, I am excited to start implementing some of these elements into the game. None of this is finalized by any means, it's all just crazy ideas. I've had some of the most fun ever coming up with these concepts, and this is only the beginning. Flayern is just one of several unique environments I hope to allow the player to explore. It is a proof of concept. If I can make Flayern fun to explore, then I will continue to develop new areas. Let me know what you think!

[Design] Zelda-like Games

As I begin development on Daughter of Dreams I find it critical to create a proper definition of what I am exactly trying to accomplish. The concept behind this project is a “procedurally generated Zelda-like game.” But, what exactly is a Zelda-like? How does a procedurally generated Zelda-like differ from any other procedurally generated game, such as a roguelike or a survival game? In this blog post, I will share my thoughts on the core design elements of a Zelda-like game, and elaborate further on what my goals for Daughter of Dreams are.

A Zelda-like is a game where progression is accomplished by obtaining key items.

In my opinion, this is the core design of a Zelda game, and what makes it different from other action-adventure games. In Zelda, you do not gain experience points that level up your stats. Instead, you obtain new items (the Hookshot, the Bombs, etcetera) which directly enable the player to access new areas of the game. Critically, key items unlock progression in three primary areas of the design: Combat, Puzzles, and Exploration. Here is an outline.

Key Items and Exploration

- New items unlock new areas of the overworld. (Metroidvania world design).

Key Items and Puzzles

- Key items are used to solve puzzles.

- Especially in dungeons, a staple of Zelda-likes.

Key Items and Combat

- Enemies are designed to be defeated with a particular item--they are puzzles themselves.

Key Items and Exploration: The first design element of a Zelda-like is the way in which key items allow the player to explore new areas of the game world. For instance, getting the bombs allows the player to blow up rocks that are blocking a path. This is the same style world-design that characterizes the Metroidvania genre. Every new key item allows the player to explore new areas of the world. However, compared to Metroidvanias, mainline Zelda games usually have a very linear overarching structure, where you find one item at a time. But, I do not think this is a requirement of the genre (rather an area where Zelda might improve). Thus, the distinction between a Zelda-like and a general Metroidvania must come in the other two elements.

Hollow Knight - Using the Shade Cloak ability to reach this upper ledge.

Key Items and Puzzles: Different from Metroidvanias, Zelda-like games have a very strong focus on puzzles, especially in dungeons. Particularly, the puzzles in Zelda-likes require using your key items in a specific way in order to get past the obstacle. Puzzles build on previous mechanics throughout the entire game--as you gain new key items, learn new mechanics, and discover new uses for your key items. The best Zelda puzzles require thinking of a creative use for your items, and applying it to the problem. The specific way that dungeons are designed to create this experience is a blog post all on its own. The point is that the puzzles in the game utilize the player’s items for their solutions.

Key Items and Combat: The final element of a Zelda-like is combat and enemies. Key items are not just tools for exploration and solving puzzles--they are useful in combat as well. Enemies in Zelda-games (especially bosses) are often designed to require a particular key item to be defeated. In this way, Zelda enemies are puzzles as well, and they provide a practical use for your items when you aren’t navigating dungeons or exploring new areas.

Link's Awakening (Switch) - Using the shield to stun this Bokoblin.

How to Procedurally Generate a Zelda-like?

From this definition, it becomes clear many of the challenges with creating a “procedurally generated Zelda-like.” Primarily, there is the difficulty of generating a sense of progression from the items which are collected. In a rouge-like, the order of progression does not especially matter--you work with whatever items you get, and the terrain is generally traversable with any set of abilities. In a Zelda-like, there needs to be terrain and puzzles generated according to which items you obtain. Further, these obstacles should build on previous mechanics. For example, once you get a second key item, you now should be solving puzzles which require both of your new abilities.

The element of enemy design is a little easier to manage. Enemies can be handcrafted to work well with particular key items. Thus, it is only the matter of well designed enemies, and having a large diversity of enemies for different key items. (Procedurally generating new enemies is a whole other level, which I will not be tackling any time soon).

Link's Awakening (Switch) - Using the Hookshot to cross a large gap.

The structure of a procedurally generated Metroidvania world I also do not expect to be super challenging. This can be accomplished with a simple check of locks (key items) and keys (simple obstacles). However, dungeons and especially specific puzzles will be very difficult. Dungeon overarching structure shares many elements of the overworld generation, but the puzzles within dungeons are more complicated. In part, I may create many handcrafted rooms to test certain puzzle mechanics, but the combinations of puzzles are exponential compared to what I would have to make for a normal Zelda-like, to account for every order which you could obtain the key items. I have a few ideas for this though, which I will elaborate on in the future.

This makes clear the primary challenge of this project, and what I must do to accomplish my goal. Without key items that are used to solve puzzles and progress in the over-world, I have merely made an action-adventure game. Now, that is still cool, but I want to make something more interesting than that. Hopefully I can create algorithms to structure an experience around gathering key items.

Stray Thoughts

I have a few more things to mention regarding Zelda-like game design. First regarding open-world Zelda-likes, such as Breath of the Wild, or the original Legend of Zelda. With my definition of a Zelda-like, open world Zelda games does not utilize the way that key items are tied to exploration. In this way, I think that BotW is lacking an important aspect of what it means to be a Zelda game. It still feels like a Zelda game, because of the emphasis on puzzles (shrines), and because there isn’t progression in any other form. But, it isn’t quite the same.

What I’d like to see in the future of Zelda is a stronger emphasis on Metroidvania world design. This could make a game world where progression is tied to key items, but the exploration is also non-linear by providing many choices for the order which you obtain items. I think this could make a better Zelda game than the open-world design that we see in BotW.

Breath of the Wild - Using Magnesis ability to solve a puzzle.

In addition, there is an element of soft progression which is present in Zelda-likes. Generally, later areas in the game, even if they are technically accessible with your current key items, are designed to be more challenging than earlier areas. This encourages a particular order of play, even if that progression is not directly dictated by the items you have. This is generally good design practice, and can be used in Zelda-likes to add more structure to an open-world experience. (This is what I did in The Last Librarian).

Finally, I want to talk about the story in Zelda-likes. The Legend of Zelda series does not have a very strong emphasis on the story, but I do not think that is a requirement of the genre. The world of a Zelda-like can be greatly improved by an epic story and well developed characters, and I’d like to see that more in future Zelda games as well. This is certainly an aspect of the game that I will focus on in Daughter of Dreams (and I did so as well in The Last Librarian). The narrative in a game can serve a critical role in building the world and keeping the player engaged.

The Last Librarian - The Ebreath Mountains are balanced to be the sixth area, but you could go there as early as third.

Conclusion

So here, at least for the purposes of Daughter of Dreams my formal definition of Zelda-likes as a genre. If you think I missed something, please let me know. Here are a few other resources.

• Mark Brown -- Boss Keys This Youtube series covers the dungeon design of every Zelda game. I can’t recommend it enough.
• GMC Forum Thread I posted here a while ago, in preparation for writing this blog post. Feel free to add to the discussion, and see some other perspectives. (Thanks to those who helped me out with ideas for writing this!)

[Design] Main Project Goals

I have written some about Daughter of Dreams already, but today I am preparing to start sharing development progress more actively. For that purpose, I am writing a post that goes into more detail about the specific goals I have for this game. I've done a lot of design work over the last few weeks, and I think I have a much better idea of the specific tasks I will need to accomplish for this project to be completed.

For those who are new, Daughter of Dreams is a procedurally generated puzzle-adventure or Zelda-like. I have published a puzzle-adventure game already, The Last Librarian, and I would like to expand on the experience I gained to make a new game that can be enjoyed endlessly. Daughter of Dreams will feature a procedurally generated overworld, randomly generated dungeons, as well as a strong story and unique, generated lore. I am excited about this project, because it builds on what I've learned about level design for Zelda-likes, and is technically much more challenging than my previous games. I will have to use many new algorithms in order to replicate the hand-crafted puzzle experience that you would expect from this type of game. From here, I'd like to elaborate more on some specific aspects of the design for this new project.

The Last Librarian - Seroth's Tomb (Procedurally Generated Mini-Dungeon)

Procedurally Generated Dungeons

Center to the Zelda-like experience, are the dungeons. Dungeon design is my personal favorite area of game design, and I am intrigued by methods to procedurally generate a Zelda dungeon experience. For this game, I am not merely making mazes with locks and keys--that had been done before. In my experience, dungeons in procedurally generated games can often end up feeling bland or unmemorable, compared to handcrafted dungeons. I believe this is in part because it is difficult to incorporate an interconnected aspect to procedurally generated dungeons (and levels in general).

In an effort to overcome this weakness, I will be generating dungeons that feature cross-dungeon, state-changing puzzle mechanics. These kinds of dungeons are described as "puzzle-box" dungeons by Mark Brown in his video essay series on Zelda dungeon design: Boss Keys. I have designed dungeons like this before, especially the Water Palace in The Last Librarian which sees the entire dungeon being frozen or unfrozen to enable different paths. (See images to the left).

Other examples from the Legend of Zelda series include the Water Temple (OoT), Stone Tower Temple (MM), or the Lanayru Sandship (SS). What is unique about these types of dungeons is a puzzle mechanic that radically transforms the entire structure of the dungeon. Procedurally generated dungeons using a cross-dungeon mechanic will (I hope) create dungeons that more closely replicate the uniquely Zelda dungeon experience that I am looking for.

Procedurally Generated Overworld

The overworld in Daughter of Dreams will be the space the connects the dungeons together. While each dungeon is a contained, puzzle focused experience, the overworld design will be more open. This part of the game focuses on exploration, in a similar way to the overworld in The Last Librarian. For this, I am inspired by Metroidvania world design, especially Hollow Knight. The challenge will be ensuring that the explorable space expands as the player obtains new items and that the difficulty in the overworld (and the rest of the game), scales well as the player makes progress in the game.

As part of the design of the overworld, I am taking some inspiration from Cadence of Hyrule, a procedurally generated Zelda game in its own way. In Cadence of Hyrule, the underlying systems of the generation allow for many solutions to the same puzzles. For instance, you may push blocks, or move them with bombs, or pick them up with the gauntlets. I describe this as the element of interactivity, and it aids procedural content generation in always allowing for an intended solution via the game logic, but additionally allowing experienced players to get past sections in other creative ways. This element of interactivity is also seen in the level design of Breath of the Wild and is why some games, like Link to the Past work well as randomizers. (Link to the Past Randomizer).

Cadence of Hyrule - Overworld Map

In my own game, I will need to design key items and puzzle mechanics that are broadly applicable and work together as a system. This will give me the most flexibility as a designer to create procedurally generated puzzles, that will always have a solution, but do not get repetitive as there are a variety of ways to overcome the puzzles. I had some elements in The Last Librarian which allowed for finding alternative solutions to puzzles, particularly the ability to carry the bomb with the boomerang and bounce arrows off the boomerang. However, the impact of these interactions was limited, and I would like to expand on this design element much further in Daughter of Dreams.

Overarching Story and Procedural Lore

Finally, central to Daughter of Dreams will be a well-developed story. The story is an aspect that is often weak in procedurally-generated games, due to the complexity of incorporating a story into a game world that is constantly changing. The story is also not a particular focus of Zelda games either, but that is not a limitation of the genre. My goal for the story in my game is to incorporate the way that the game is procedurally generated by having the plot play out over the course of many play-throughs, remembering story progress made in previous runs.

There are two facets to the story in Daughter of Dreams. First is an over-arching story based on the changing nature of the world. This part of the story will be character-focused, allowing me to tell the story regardless of the current setting through well-developed characters. Each character has their part of the story to tell, and they will share it when they are cued to based on various factors throughout the gameplay. Additionally, the game world will be enriched through procedurally generated lore. Each playthrough will be uniquely marked by original lore, inspired by the style of lore in Hollow Knight (or--as I understand it--Dark Souls).

Hollow Knight - Overworld Map

Obtuse lore like this is ideal for procedural generation, as it is intentionally vague. So long as what is being generated is consistent with the over-arching story, there can be a lot of variation in the actual flavor text, tombstone engravings, idle dialogue, and other lore details. Thus, each player may paint their own picture of what happened in the past of Daughter of Dreams and decide on the implications of the lore on their own. I also have a budding idea about incorporating the player's own previous playthroughs into the lore, but I don't quite know how I want to do that yet.

Conclusions

I hope this gives you a better idea of my goals for Daughter of Dreams. I expect this project to be done before the end of 2022, and the time until then I will be fully focused on Daughter of Dreams as my main game project. I will do my best to share my progress and new ideas throughout the entirety of the development. Most updates will be on this blog, especially as I go into detail on the actual methods of procedural generation. I will also share updates and screenshots to my Twitter (@CloakedGamesDev). Be sure to subscribe to this blog if you are interested in the development process.