Steam Community :: Selenwald

Selenwald

All Discussions Screenshots Artwork Broadcasts Videos News Guides Reviews

Selenwald

0 in Group Chat

Selenwald is an action roguelike RPG that combines challenging combat with strategy and resource management. Take control of random adventurers to fight and sneak your way through eldritch horrors roaming the ever changing halls of Selenwald university.

Visit the Store Page

Most popular community and official content for the past week. (?)

Diary Page #12: Systemic Architecture (Part 2)

2 Jan

Dear Scholars,
Continuing where I left off in the first part, I would like to show you the building blocks of my new architecture and how it compares to the typical ways of working in the Unity engine.

Inspiration

The idea for how the code architecture in Selenwald is going to look didn't come out of nowhere. The biggest influences were:

my past experience with Entity Component System (ECS) style framework (Entitas[github.com], to be specific) which I had previously worked with on a different project,
Brian's Bucklew's talk on the systemic and data driven architecture used in Sproggiwood and Caves of Qud,
my own journey of gradually making Selenwald more and more data-driven (mostly through various ways of utilising Scriptable Objects, heavily influenced by Ryan Hipple's talk on this subject) throughout the recent years.

Not ECS
Whether you're familiar with ECS frameworks or not, I should make it clear that my architecture is not an ECS despite me using the terms "entity" and "system". They are just convenient names that I stuck with. One of the key distinctions is that my systems are a combination of systems and components known from ECS - they contain logic but also data. Thus, every entity that uses a specific system has its own instance of it. Also, the Entity class and System-derived classes are MonoBehaviour scripts attached to game objects which is still "the Unity way" adding logic to objects. This comes with some overhead and I have plans to make Systems regular classes instead of MonoBehaviours to make the game loop a little bit faster. However, it's not a high priority and it can easily be done in very late stages of development. That being said, I will never fully utilise the performance benefits that actual ECS frameworks are known for because—like I said—creating an ECS wasn't my goal here. I just borrowed some ideas from it.

Entity
Every object in the game is built of two things - the Entity class instance and a stack of ordered systems. The main purpose of the Entity class is to gather special events which are how systems communicate with each other in a decoupled way (without knowing about each other). An event might be something like having a collision with another entity, receiving damage, or triggering the action of picking an item up from the ground. What's important is that these events are actually just data containers with unique types.

The System Stack
Now what actually happens during a frame? First take a look at this diagram showing the system stack on a timeline. Under the hood, each system type has an explicit order assigned. Bear in mind that the entities you can see here actually have much more systems but I skipped them to shorten and simplify the example.

When a frame starts, the Entity class on each object in the game gets rid of the events from the previous frame and prepares events that were deliberately triggered by some systems in the previous frame to fire on the next frame (so the frame we're currently looking at).

Then, the system with the lowest execution order executes on all entities that have it. No events have been raised at this point yet (except for some exceptions like the deliberately deferred events I mentioned before) so these early systems usually raise their own events and process their internal data instead of reacting to events sent by other systems. An example of such a system is the Player Controls System. It contains all the logic necessary for processing input. That logic includes queuing the commands so that you can—for example—press the attack button before while your character is still performing a dodge move so that they attack as soon as the unskippable part of the dodge animation finishes.

All these possible input commands end up triggering these special events I've already mentioned. If we take the Dodge Event as an example, it contains an Action Move (my wrapper for a character animation) and a direction. Now the fun part is that when the Player Controls System sends out this event, the Action Move is empty because this system is not responsible for deciding what exactly should happen. It merely initiates the dodge but how it happens and whether it even happens depends on what other systems does the entity have. Another important behaviour to mention is that events only reach systems that come after the one that sent them, unless the event is set to deliberately fire on the next frame and go through the entire stack.

Now, let's proceed down the stack - if the entity owns the Dodge System, that means the entity knows a dodge move and has it stored in the Dodge System's settings. So when the Dodge Event arrives, the Dodge System captures the event for a moment and injects its animation in this Action Move slot I mentioned.

Then the event continues to be received by other systems along the stack. Let's say this entity is a character that earned a special trait that changes the dodge animation to some fancy acrobatic move. How would it be done? That trait would be a whole new system - let's call it the Acrobatic Trait System. That system would come after the Dodge System, also capture the Dodge Event and override the Action Move that was originally set by the Dodge System or do nothing if the Action Move has not previously been set - after all we want this trait to upgrade the dodge move but not do anything if the character can't dodge in the first place.

In summary, when the entity changes it's not actually the systems permanently changing their settings. The old dodge animation is still there, stored in the Dodge System which still tries to apply it when the entity wants to dodge. The way entities change and evolve is by having systems added or removed on the fly. An animation override was added on top and the Dodge System doesn't have any clue that something is changing the animation later down the line.

The final destination of the Dodge Event is the Animation System where events carrying animations get processed. The event recognizes that the Action Move in this event has been successfully populated and based on the properties of this animation executes it or not (e.g. some animations such as idles may have lower priority and can't interrupt others, while staggers should interrupt other actions).

Something worth pointing out is that the Player Controls Systems is not the only system capable of sending out the Dodge Event (and the like). The AI System also does it. However, the AI needs to be processed late in the stack so the events raised by it are triggered in a delayed way - they wait until the next frame and then go through the entire system stack.

Modularity
What I just described is an architecture in which various parts of the games logic are decoupled. In traditional Unity programming patterns (or the lack thereof) it's natural for various components to reference each other directly, use and modify each others' data, call each others' methods, etc. This is fine for games with narrow possibility spaces. Because there are not that many interactions between systems, you can just explicitly code all the required behaviours. However, things get tricky if you're making a game that's very sandboxy in nature and the possibilities are virtually endless due to how various systems can interact with each other. That's when decoupling them becomes a solid approach. This means making them less aware of each other and making them only process some elementary, intermediate data without the care of where that data came from and where it goes. It comes with a drawback - it may make the code a bit harder to read and debug because you don't immediately see the chain reaction that has led to a problem. However, an approach like this makes code more resistant to game-breaking bugs and easier to expand because adding new systems usually doesn't require you to rewire the entire logic. A properly created system should work with existing systems out of the box. Now, while there is a smaller risk of problematic errors, the risk of having goofy bugs increases. Those are bugs that don't necessarily break the game but introduce weird behaviours and exploits due to interactions between systems that weren't even predicted by the developer. However, that's precisely the charm of sandbox games, isn't it?

Consequences
If you've read the above, you may already have some ideas on how this enormous possibility space can be used. Also, as you likely noticed, the only thing separating the player character from an NPC is the Player Controls System. That means that a mind control spell would merely need to remove this system from the player's character and add it to a different entity (human or not) and it would just work. In non modular frameworks the player character would likely be coded and constructed differently from other creatures, making it challenging to introduce a mechanic like this. A lot of mechanics that would be quite challenging to introduce normally, become trivial with a modular architecture because everything follows the same rules.

Unfortunately this is a double-edged sword. There are also things that took me very little time when I originally made them in the old codebase but took an unexpectedly long amount of time now. Such example is the inventory system. That's because previously items such as weapons and potions were a completely separate kind of an object as compared to creatures. It was very limiting but also relatively simple to work with. Now that items are just entities capable of having any systems, this part of the game got quite complicated. Even such a basic thing as getting the item's icon so that it can be displayed in the UI requires first sending a proper event on the character, having that event received by item-carrying systems such as Hands System or Outfit System, propagated further to the contained entities (the items held in hands, pockets, etc.), and finally received by the UI systems that requested the icons.

Such architecture basically makes the time required for adding new systems less exponential, which is good for games that scale, but adds some flat overhead to everything so that some seemingly simple pieces of logic still need to follow the rules and go through the system stack pipeline.

Constructing entities
But how are entities being defined in the first place? How are the complex hierarchies of 3D animated game objects constructed? That's another major distinction between my architecture and the traditional Unity workflow as it flips the idea of prefabs upside down. And this is where the time efficiency gain is the most dramatic. That's what I'll tell you about in the next entry.

As usual, a small reminder that if you want to support the development process, you can do it at Ko-fi[ko-fi.com].

Thank you for reading,
Wiktor

Selenwald

slow

just a fyi if every character will be moving that slowly around the map I dont think I will like it.

Celo

2 Aug @ 3:47am

General Discussions

Diary Page #11: Systemic Architecture (Part 1)

1 Dec, 2024

Dear Scholars,
It is time to finally give you some behind-the-scenes look at what makes Selenwald tick - especially that it has been a while since the last entry and you deserve something more than just a status update. This entry will be first one of a small series on the code architecture because the topic is too big for a single post.

The first thing I'd like to write about is the reasoning behind what has been in the works for a very long time. As I mentioned in the past, I have started a massive code rewrite exactly a year ago. It was never supposed to be a minor refactor or a mere clean-up but rather a complete change of the underlying architecture. Scary? Sure! Needed? Absolutely.

But why?

Technical debt: Back when my main development goal was to get a publisher or an investor, my priority was to create a publisher demo that's representable enough to communicate the vision and show a glimpse of the final product. During that stage it is natural to opt for quick and dirty solutions rather than future-proof ones because real production would start after money arrives and all the bad could would be scraped then. The problem was that the fundraising process lasted several years for Selenwald (and ultimately failed because of the simultaneous worsening of the health of the games industry). This has accumulated a tremendous amount of baggage as I needed to keep focusing on short term goals for such an extended period of time.
Non-modularity: When the prototyping stage of Selenwald's development began, I didn't fully grasp the systemic depth this game would ultimately achieve. Its immersive-sim characteristics, with various systems interplaying in a simulative manner, have later become one of its most captivating features. Yet, the initial code architecture wasn't fit for this. The logic was highly specific, turning any addition or interaction between systems into a spaghetti code maze which has become bug-prone, hard to maintain, and increasingly complex with each new system.
Non-moddability: While modding support isn't something I want to have right upon the game's release, I absolutely want to add it at one point. Selenwald is one of these games which are perfect for modding due to their systemic design and sandbox gameplay. Thus, the code and especially the data structures should follow some good practices that would enable relatively frictionless modding integration. The old code wasn't terrible in this regard but had a lot of room for improvement.
Complex content authoring: Related to all the points above, even creating a single new enemy was fraught with complications and error risks. My original reliance on prefabs, one of the basic building blocks in the Unity engine, became a hindrance for a game as procedural, systemic, and aspiring to moddability as Selenwald. For example, any creature (human or not) would have lots of behaviour scripts attached to various bones and set up manually. This coupling of logic with the animation rig was needed for many systems but the workflow was just very cumbersome even after Unity introduced Prefab Variants and Nested Prefabs. If you wanted to take a finished creature and create a similar one with all the systems intact but a different model (especially with a different rig) - it just wasn't possible to do. You would have to manually setup the new creature again every time or create complex editor tools that would partly automate the process (but still create completely new prefabs that have no relation with the ones they were based off of). I knew a paradigm shift was needed.

The Core
But what this "architecture" thing even is? It's basically code that serves as a foundation for everything else, the relations between data structures and systems, as well as rules for writing specialized logic. Some of it is defined by the engine - Unity in this case. For example, the base building blocks in Unity are scenes which contain game objects, which in turn can be saved as prefabs to serve as reusable pieces you can edit in one place and see the changes reflected in all their instances. Game objects (and thus prefabs) contain code blocks called components - either built-in (like Rigidbody, Mesh Renderer, Light, etc.) or custom scripts. Another important element of the whole ecosystem are scriptable objects which (among other uses) are a very handy way to store data that can be shared among various unrelated prefabs.

The way the engine is structured imposes a specific workflow. However, sometimes it is necessary to think outside the box and create your own foundations that are still connected to the engine's way of handling things, but offer a different interface at a higher level. For example, it is natural to have every level on a different scene as this automatically handles loading appropriate assets to memory and unloading them when the level changes. But there are some cases where the entire game could sit on a single scene. This can be a viable approach in procedural games like Selenwald because the way of loading and unloading data needs to be handled in a custom way. After all, we don't know which assets are needed at a given level until we actually generate it. This is just a simple example but sometimes other seemingly critical parts of the engine become a hindrance and need to be reinvented. In Selenwald's new architecture I've almost entirely moved away from prefabs. This is something unthinkable for most Unity developers but this was a truly liberating change for this project. Why? I'll get to the technical details in the next entry. Don't worry - this time you won't have to wait several months for it! I'll do my best to write it before the end of December.

Anti-Vacation
Finally, I'm excited to report that I'm soon taking a vacation from my day job. And it's going to be a long one because I haven't used almost any of the paid time off available for me ever since I started the job in April. It's going to be a whole month, starting on December 7th and ending on January 6th. I honestly totally forgot about how much vacation time I have available so this came off as a bit of a surprise. Of course, I'm going to spend most of it working on Selenwald which excites me a lot because the last time I was able to spend an extended time working exclusively on it was December 2023, so almost an entire year ago. I hope I will use this opportunity to catch up a bit and finally get the demo close to the state which is functional enough to get some playtests rolling - something I had originally hoped to already have by now. I still can't give you any reliable date for the demo release but it's definitely getting closer and closer!

Also, a small reminder that if you want to support the development process, you can do it at Ko-fi[ko-fi.com].

Thank you for reading,
Wiktor

Selenwald

Diary Page #10: Rebirth

22 Jul, 2024

Dear Scholars,

It has been a while since the last entry. Usually that means an exceptionally busy period and this was no exception! I'll give you a personal update first and then tell you about some of the progress we've made in Selenwald's development recently.

Stronger than ever

First of all, the last 3 months were an incomprehensibly busy period for me. I've always worked a lot but recently I've managed to beat any of my previous personal records, working ~90h weeks quite consistently. No worries though - I'm also physically active (cycling every single day), eat healthier, and most importantly I'm feeling great mentally, so it's all fine!

As those of you who are on the Discord server[discord.gg] already know, all the struggles I've had for over 3 months beginning in early January have finally ended. At the end of April I started a long term job at a studio I've been freelancing for for around 1.5 years prior. Due to having accumulated debts during the job-hunting period, I've started at a full time position to first get back on my feet. However, my intention was to switch to 4/5 after 3 months. In addition, half-way through that full time period, I've taken a side gig with a friend. On top of that, I decided to focus on improving some aspects of my life during that time - getting some overdue medical tests done, buying stuff I *desperately* needed to buy for a long time and optimizing the hell out of my daily routine to waste as little time as possible.

Despite all this, I still managed to spend an impressive amount of time working on Selenwald (especially during the last month) but that was just the beginning because that transitional period is now coming to an end. I have just switched to the aforementioned 4/5 and my side gig is also ending very soon. With all the optimizations I made (along with sacrificing any entertainment), I will now able to spend more time on Selenwald on average than I ever have.

Getting closer

As I've mentioned in some earlier entries, thanks to having decided to finally cease my attempts to get a publisher or an investor for independence's sake and thus not having to constantly focus on the short term goal of polishing the publisher demo, I have started a long overdue, massive revamp of the code architecture in December. I have originally planned to have it finished by now but unfortunately those misfortunes struck me in January. However, most of the rework is done and I am very pleased with the results. Finally, almost every piece of code works in perfect harmony. The new system is very robust. Coding new systems feels like a breeze now and implementing new content is trivial. Additionally, the framework makes for a great foundation for future modding support.

Here are some new things I made during the last 3 months:

many fixes, improvements, and optimizations to my new architecture, including pooling for event objects that all systems communicate with
a node editor (I intend to use it for AI behaviour and dungeon generator settings authoring in the future)
entity preset previews (a tiny but very helpful QoL feature for faster development)

And here are some old systems that I rewrote inside the new architecture during the last 3 months:

field of view obstacle system
fog of war system (along with massive optimizations and a dramatic increase in quality as compared to the old solution)
a significant part of the core AI logic
doors (it's not as trivial as it sounds - see "The Door Problem"[lizengland.com])

What's left

There are still a bunch of non-trivial systems in need to be moved to the new architecture (and some of them, like the UI logic, should be done from scratch because the old code is so dirty it's completely unusable) so it's still too early to open a bottle of champagne. The most important ones are:

dialogue system
user interface
occlusion system (high obstacles becoming semi-transparent when they occlude areas that should currently be visible to the player)
the rest of the AI logic
character generation (using outfit pieces)
likely some other things I'm yet to realize I forgot about

There is also quite a lot of very small systems awaiting a rewrite. However, thanks to the new architecture, such systems take almost no time to implement. For example, reimplementing the night vision system (that relies on the fog of war system) took me literally around half an hour.

Another thing related to the rewrite that needs to be done is the migration of existing content to the new format. Only some of it is done and most will be moved in bulk once all systems are rewritten. However, that's another thing that has been dramatically simplified by the new architecture. Hell, this was one of the primary reasons behind the rewrite - making content implementation extremely fast and easy.

In summary, the end of the rewrite is clearly visible there on the horizon. What's worth noting is that the end of this whole undertaking will be a tremendously important milestone that will pave the way for the first public demo. Despite the delay, I'm still hopeful for the first playtests to take place until the end of the year. The nearest months will tell how realistic this deadline is.

Not all heroes wear capes write diaries

Don't forget I'm no longer working on Selenwald alone. Maksim has been creating 3D art for quite a long time now. In fact, he started exactly 2 years ago! Even though he's not spending nearly as much time on the project as I am, he has made quite a collection of great art by now. To not leave you with just text, let me wrap this diary entry up by showing you some of what he's been up to for the last couple of months.

He started two sets of models simultaneously around December/January and recently wrapped up the last one of them. Today, I'd like to show you the first one - a large modular set of walls counting 17 pieces for the procedural dungeon generator to build levels from. Like the other wall collections, this one also consists of various straight pieces, inner and outer corners, a door, a window and a standalone column. It's been done using the trim sheet technique. This means it will be very easy to add more new pieces to this set without the need to do any additional high poly modelling, baking, or texturing.

This set of walls also functions as a library that will be filled with books. It was inspired mainly by the Spanish renaissance Library of the Monastery of San Lorenzo de El Escorial[en.wikipedia.org] which Maksim has personally visited and photographed.

I hope this will satiate your appetite for now! I still plan to start a series of entries where I could do a deep dive into the intricacies of Selenwald's code and also show you how some of the unusual mechanics work but I want to first finish the rewrite. Besides, writing such technical logs can take a lot of time (easily a full day) so I only want to get into it when I know I can actually deliver interesting and educating content. This will happen - I just don't precisely know when yet.

Thank you for reading,
Wiktor

Selenwald

Is this game still in development?

The dev diaries have stopped for awhile now.

Shell Beach

20 Sep @ 9:48pm

General Discussions

This is going to be amazing!

Can't wait! :)

Kybernetes

24 Feb @ 7:48am

General Discussions

See More Content

No more content. So sad.

You can help: share a screenshot, make a video, or start a new discussion!

Returning to where you were last on this page...

Cancel