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, 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.
Thank you for reading, Wiktor
Diary Page #11: Systemic Architecture (Part 1)
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 2024, 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.
Thank you for reading, Wiktor
Diary Page #10: Rebirth
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 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)
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 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
Diary Page #9: Music of Selenwald
Dear Scholars,
Those of you who are members of our Discord server community may have noticed I am very passionate and enthusiastic about music in video games as it's my favourite genre of music (if "genre" is even an appropriate term here), which always accompanies me when I work, evoking vivid memories from my beloved game series and inspiring me in my own creations. Naturally, I wanted Selenwald live up to my auditory standards and have a memorable soundtrack that greatly fits the game's atmosphere.
First Pieces
It all started back in 2021 when I met Markus Zierhofer - a composer and one of the people behind Audio Creatures. I immediately knew he would be a great fit for the project as he quickly understood the vibe I was after and was excited about the references I suggested. Not much time passed before he began working on the first two pieces - an exploration track and a combat track, both of which he nailed.
The first track required quite some iterations before it took its final form but we eventually found the sweet spot. The combat one though, that was quite a different story! I was in a bus when Markus sent me the first draft version but I've left my earphones at home so I couldn't check it out just yet. I carried on, unaware of what awaits me. When I finally returned home and played it I immediately got goosebumps. A moment later I realized I'm smiling ear to ear. What was to be just the first draft, felt like a masterpiece to me - exactly what I wanted. Here's my original reaction:
Thus, Selenwald received its first tracks to be used in game. There was a small problem though. Most of the in-game music should have some things in common to ensure consistence. Something to connect them - a common motif to be explored in various moods and colours in the upcoming tracks. The main theme was needed to provide this definitive central point. However, this wasn't a priority for the time being.
Main Theme
Two years later when I spoke to Markus at Game Industry Conference here in Poznań, he mentioned he's looking for new pieces to compose because he's preparing to do some live recordings soon. I thought it would indeed be a good moment to finally tackle that main theme as I even—coincidentally—had been gathering some references for it in the past couple of weeks.
However, there was a slight misunderstanding..
I knew Markus owns and plays lots of instruments himself so I thought he simply wanted to replace some of the usual sample-based virtual instruments with the recordings of him playing (at least for those parts that are played by a small amount of instruments at once). I did not originally realize what he meant was an actual orchestra.
He and his colleagues at Audio Creatures together with German Film Orchestra Babelsberg gathered a bunch of indie studios and organized a consolidated recording session for many tracks at once. This made the whole thing surprisingly affordable and manageable. Then, after some waiting, the mixing and mastering were done and Selenwald had what most indie developers believe to be an unreachable dream - an epic main theme played by a live orchestra. In the end Markus have proven some people—including me—wrong!
Also, the initiative—which they dubbed Live Score Berlin—turned out to be so good they're making it into a recurring event and the submissions for this year's edition are closing soon. I hope some other fellow indie developers find as much value in it as I did.
But enough talking - here it is. Make sure to listen it until the very end. I hope you like it!
I'd tell you of everything that inspired this theme but actually.. why don't you tell me instead? Can you guess which three musical pieces influenced Selenwald's theme the most? Maybe you can even catch some secondary inspirations? Give it a try in the comments below or over at the Discord server.
And here is a short clip from the recording session itself:
The Struggles
As a final note, I'd like to give you the update on the matters I tackled in the last entry - particularly my financial situation.
First of all—once more—a big thank you to everybody who supported me financially over at Ko-fi. The amount of support has far surpassed my expectations and helped a great deal.
The bad news is that the situation still hasn't gotten much better. I occasionally get a bit of paid freelancing work to get by, but I still haven't found anything more stable as the talks with studios I discuss possible contracts with are taking forever. Thus, I'm partly living off of money borrowed from friends. It is hard to stay productive with the game's development while under such stress of financial insecurity but I'm doing my best to make some progress every day, even if my overall productivity is temporarily much worse than it is in normal circumstances.
If you hesitated the last time and kind of wanted to help but ultimately didn't do it or you read the diary entry so late you weren't sure it's still relevant, I confirm that it still is. I don't offer anything in return yet but if you simply want to help, you can do it here.
Thank you for reading, Wiktor
Diary Page #8: Call for Help
Dear Scholars,
I never thought I would write about anything negative as I am usually all fine and the development of Selenwald is going well.
However, due to the current unusual circumstances I have decided to write this particularly personal entry. I'd want to tell you about the distress I'm in at the moment and about how you can help me make the dark clouds go away.
Those present in our Discord may have noticed I haven't posted much about progress this month. Unfortunately, the reason has been that there just wasn't a whole lot of progress being done during that time. This January was one of the roughest months in my life. Let me tell you about what happened.
Death
First, Tinka—my dear cat—died on January 8th after an almost 3-year long battle with lymphoma. Luckily, despite it being an incredibly painful loss, I've managed to deal with grief relatively quickly. After all, this didn't come with a surprise and I had a very long time to prepare for it. It is impossible to ever be fully ready to lose someone we love but at least a small part of me has accepted this long ago. Still, it took me a week to get back on feet.
Unfortunately, I also fell sick at the exact moment I lost Tinka, probably due to my—usually strong—immune system suddenly giving up due to grief. This will become relevant later on in this story.
Famine
Then, unfortunately it turned out my usual client has completely run out of work for me, which I wasn't quite ready for. I would be if not for my recklessness in pursuing the dream of making Selenwald a reality as soon as possible and constantly living on the edge. But I digress. I've been actively searching for new work ever since but due to the terrible shape the game industry finds itself in currently, it's very hard to find any. On top of that so many people are being laid off every week there's an enormous competition for every scrap of work. Finding freelancing contracts has gotten so hard and unsustainable I decided I'm going to ditch it now after 10 years of doing it and try to find a permanent part time position instead. Freelancing has always been wildly difficult but now it's getting even worse, despite my decent rates. I'm really sick of it now and would love a tiny bit of stability. Alas, finding a part-time job is just as hard as finding freelancing contracts so I'm now also considering full-time positions. Not only that but I'm open even to ones that require relocation to a different country. It's a matter of survival.
Unfortunately, my job hunting has been fruitless so far and I ended up in a terrible financial situation. I barely have enough money to live through the first half of February and even if I eventually find work it will likely take at least a month until I see any money. There's just no time because I need this money now. I have friends whom I can ask to lend me money, but they're not rich and I can't borrow a whole lot so I still need to find work as soon as humanly possible. Otherwise I'll be facing homelessness soon. Even though I'd likely have more than one option of where to temporarily stay if such scenario happened, it would still be a lot of hassle, stress, and wasted time - a major slowdown for Selenwald's development.
Pestilence
All these calamities happening in such a short period have made me experience a panic attack a week and a half ago, first time in my life. It was so bad I decided to call an ambulance, thinking there's something wrong with my heart. Turned out I was all fine and what happened to me was likely caused by stress combined with that infection whose symptoms haven't fully went away by that time. But of course I wasn't in a mental place to fully believe the medics so despite my financial trouble I decided to visit a cardiologist to get thoroughly examined and make sure I'm fine. He confirmed my heart is all well and this was tremendously reassuring. Gave me the peace and the courage I needed to keep looking for work without worrying about my health.
For some reason I still have a cough after almost a month after getting sick (despite having taken medicines) but I'm sure it's nothing serious and will visit my doctor again next week.
Support
With that said, I have no idea what will tomorrow bring. I'm hopeful I will find work soon but there's still so much stress on me at the moment (and pressure to keep applying for jobs) I won't be able to fully resume the work on Selenwald until I know for sure I won't lose the roof over my head or die of hunger.
Thus, I decided to set up a way for you to aid me - something that some Discord members have suggested long ago. If you care to support an indie game developer in his journey to bring you something unique, exceptional, and made with true passion, you can now do so by following the link below: https://ko-fi.com/wiktorwasowski
I know the community isn't nearly large enough to enable me to live on donations and switch to full time Selenwald development (though it's a nice dream scenario to fantasize about) but at this time of crisis every tiny amount helps. You can also consider sharing this story with someone who may be interested in helping out.
Whether you choose to donate or not, thank you for being with me on this journey, even if you're just a silent observer. Let's hope everything goes back to normal soon.
Thank you for reading, Wiktor
Diary Page #7: The Decision
Dear Scholars,
In my previous entry, I pondered the paths of seeking a publisher or investor versus embracing full independence for the journey. Today, I'm excited to announce my decision to finally cease my pursuit of a business partnership. It was a time consuming process that ultimately proved fruitless because of what state the games industry finds itself in right now. Due to some expected crash, it's nearly impossible to secure funding for a game even by an established studio, let alone a debuting one. Without the further need to keep polishing the publisher demo in hopes to appease some people in suits, I can now dedicate my energy entirely to the long term goal of bringing the game to your hands as soon as possible. This means my "Plan B" is being put into motion and that is preparing for an Early Access release, which would otherwise be skipped if I managed to get funded via a business partnership.
As part of this pivot, a public testing event is on the horizon, likely in late summer this year, and most certainly before the year's end. Depending on how this unfolds, we might see a public demo by the end of 2024 or, at the latest, in the first half of 2025, with a realistic aim for Early Access in the second half of 2025.
Depending on the reception of the alpha tests and/or the demo I might also consider running some form of crowdfunding to ensure I can pursue the goal without interruptions, or even hire additional people along the way. Being able to work on the game full time has been my dream ever since the project started.
Thus, 2024 promises to be the year when you'll finally step into the world of Selenwald! Keep an eye out for future diary entries and join the Discord community for frequent development updates and some occasional discussions.
In the upcoming entry, I'll venture deeper into the core of the codebase refactor discussed previously. I'll explain its purpose, illustrate with examples, and take a closer look at the nuances of code architecture design. For the current and aspiring programmers, this might prove a useful resource. Meanwhile, those with a general curiosity might appreciate a glimpse into how games are crafted from the ground up.
With this in mind, I wish you all a new year filled with energy and enthusiasm that mirrors my own.
Thank you for reading, Wiktor
Diary Page #6: Crossroads
Dear Scholars,
It has been nearly a year since the last entry. If you're concerned something might not be right, I'm here to reassure you it's actually very much the opposite. It has been an incredibly productive year so far and the restrain from writing dev diary entries was one of many, small, conscious decisions I made to ensure I can put as much time into Selenwald's development as humanly possible and arrive to a point of having a feature complete playable build.
Feature complete
I know what you're thinking - the release must be right around the corner, right? Well, not so fast. Let me clarify. While it's a remarkable milestone worth celebrating, it might not be what you expect.
To set the stage, let me shed light on my primary development objective over the past months (or should I say years). As I might have mentioned previously, I aim to sign a deal with a publisher or an investor to raise funds to wrap up the game within a realistic timeframe. This is a non-trivial amount of money that is required to recruit the necessary talent and allow me the luxury to focus exclusively on Selenwald, without the distraction of freelance work that currently sustains me. The problem is.. times are extremely difficult now. Publishers and investors have never been as cautious as they are now. They rarely fund/publish games which aren't already very close to getting released. For a debut title by a new studio such as mine, especially that—although not working entirely alone—I carry the entire weight of the project on my back, it is imperative that I have a playable demo which feels as close to the final game as possible. Being an indie developer with no money, this is a massive, and incredibly difficult undertaking. But it is achievable and I do finally have a playable build that has all the essential features in place.
The essentials
Yes - when I said "feature complete" I didn't mean every single aspect of the game is implemented. There is absolutely a lot of programming work still left to do (not to mention the actual content) but core systems and mechanics which are the backbone of Selenwald are finally in place. This includes:
very complex and elaborate procedural generation system
ranged combat with skillshot style aiming
dynamic melee combat with dodges
trait and stat systems allowing for deep character development and customization
stealth system allowing for sneaking by, assassinating, and even pickpocketing
character senses
unique inventory system
spell conjuring system
dialogue system
simulated character disposition system with factions and relations between every single creature
meta-progression
lighting and field of view working together to create a fog-of-war-like visibility system
procedurally generated playable characters
and more!
Now some of these systems are still in their infancy or rather in the state known as a "minimum viable product". For example, the magic system is currently in a very simplified mechanic used temporarily until the target solution is implemented. It works and roughly shows the idea of how are spells going to function but doesn't have the desired depth yet.
There are also features that are missing entirely but are deemed inessential. That includes, for example, procedural environmental puzzles with traps. Are they important? Yes, they are going to fit the vibe and the pacing of Selenwald very well. No classic dungeoneering is whole without some optional intellectual challenges. But they're not absolutely needed for the primary gameplay loop to feel complete (and solving them will never be the only way to progress through the university). Therefore, adding them isn't of high priority.
Then what's the underlying challenge when so many features are already in place? Why doesn't it signify that the game is nearing its completion? The core reason lies in my fundamental goal: fundraising. With my primary strategy being to align with publishers and investors, it was crucial to present as many of the planned features as possible and showcase the game's potential in terms of fidelity and quality. Those who are considering funding the game need a comprehensive glimpse of its various facets, and they need to envision its final calibre. To accelerate achieving this representative state of the game, I opted to prioritize the external presentation, even if it came at the compromise of some internal components. This compromise is what we often refer to as "technical debt".
Technical debt
Imagine building a house. At first, you might use shortcuts or temporary solutions to quickly erect the structure and see how it looks. Maybe you use tape instead of nails in a few places, just to get the walls up. This is efficient in the short term and lets you visualize the end product, but over time, that tape will wear out and might cause problems. If left unattended, the walls could collapse. In game development, "technical debt" refers to these temporary or quick-and-dirty solutions implemented to achieve immediate progress. But just like the tape in our house analogy, if not addressed, these solutions can lead to bigger issues down the road.
While the concept of technical debt might seem concerning at first glance, it's important to recognize the silver lining in this approach. By aiming for a feature-complete demo—even if it means relying on less-than-ideal solutions—I've actually gained a clearer understanding of the project's architectural needs, which are largely determined by the design elements that crystallized during the demo's creation. Diving headfirst into crafting a "perfect architecture" from the outset isn't always the wisest choice. Often, what appears to be a sound structure in the initial stages might not align with the evolving demands of the project as it progresses. By first navigating the "messy" path, I've been able to identify the project's true requirements. Armed with this knowledge, I'm now better positioned to refactor and mold the architecture into its optimal form. Think of it as sketching a rough draft before creating a masterpiece; the former informs and enriches the latter.
Shifting to full production
It might be tempting to think that, with the demo in its current state, it's prime time to unleash it onto the public. However, there's a key distinction to make here: while it's structured to capture a publisher's or investor's interest, it's not quite ripe for public hands just yet. To make it really playable and enjoyable, it would require an addition of more content, and a significant polishing of the existing systems and content. But diving into either—content or polishing—without addressing the underlying "dirty" architecture would be unwise and short-sighted. Now, with the "publisher demo" stage achieved, it's the optimal time to shed that technical debt by delving deep into a refactoring process. This strategic choice means that for the next couple of months, additions to the content and features, as well as the necessary polish, will be on pause. Therefore, those eagerly awaiting a public pre-alpha test or sneak peek will need to exercise a bit more patience.
The magic of refactoring
Here's the bright side: this upcoming refactoring is going to be a game-changer. Once undertaken, it will immensely accelerate the pace of further development. Introducing new content will become almost effortless, and the overall game structure will stand on a more robust foundation. With the goal of achieving a modular design, the revamped code will be far less susceptible to bugs. And on the off chance a bug does manage to creep in? They'll be significantly more transparent and easier to address.
Also, one of the unexpected benefits of adopting temporary solutions was that it provided me with a sandbox to experiment with various architectural design patterns. This hands-on approach was enlightening. It illuminated which strategies were viable and which ones faltered. There were moments when I believed I had pinpointed the perfect design, only to have that belief challenged when applying it to certain segments of the code. But these trials and tribulations have been instrumental. They've forged a clearer, more informed vision for the game's architecture. After all, sometimes it's through our missteps that we gain the most clarity. It has been a taxing journey, piecing together a complex puzzle with what felt like duct tape. But now, with these invaluable insights, I'm eager to transition Selenwald into its most efficient and elegant phase of development.
The tipping point
Selenwald's journey is at an undeniable tipping point. I now possess a compelling publisher demo, and the horizon ahead is populated with various negotiations and dialogues leading to a potential partnership with a publisher or an investor (or both). This conventional route—aligning with a publisher, or potentially teaming up with an investor and external marketing experts—has been my primary blueprint for Selenwald's trajectory so far. There have already been ongoing dialogues, and the feedback from publishers has been very positive.
However, we must acknowledge the current state of the gaming industry: it's in a state of flux, marked by uncertainties. Even with the game's favourable reception, securing a partnership—especially one that feels just and equitable—could be a formidable challenge. With all these variables, a pressing question casts its shadow: "What if I don't find the right partnership?"
Plan B
As with any ambitious endeavour, it's essential to have a contingency plan, and Selenwald is no different. If the upcoming discussions prove less fruitful than hoped and the refactoring phase reaches its culmination before an agreement with publishers or investors materializes, I may find myself at a crossroads. Staying completely independent may ultimately become the chosen path.
After years of unwavering commitment, pouring immense time, energy, and resources into Selenwald, the notion of trading a significant revenue share for publishing or financing aid becomes less compelling. While the financial assistance remains crucial to bring onboard the necessary talent and expedite the game's completion, the roadmap could see a transformative shift. Rather than gunning for a grand release after two more years of funded development, wrapping up by the end of 2025, I might reorient my sights. The focus could shift towards crafting a public demo, laying the groundwork for a potential early access release, possibly bolstered by a crowdfunding initiative. This trajectory implies that you, the eager player, might get a taste of Selenwald sooner than anticipated. However, it also means that the timeline for the game's final and polished release (leaving Early Access) could extend largely beyond the initial 2025 projection, given the inherent limitations of crowdfunding compared to the substantial backing a publisher or investor could offer.
Each day brings us closer to critical decisions that will chart the course for Selenwald and the studio. As the story continues to unfold, I'm gearing up with my never-ending enthusiasm and motivation to finally dive into the codebase rework I've been dreaming of for way too long.
Thank you for reading, Wiktor
Diary Page #5: Reliefs and a Relief
Dear Scholars,
I usually try to focus on one thing per entry but this time I have several different things to write about. I'll try to keep them condensed in return. [note from future self: alas, I failed]
Behind the scenes
The process of creating games was always something I was very passionate and enthusiastic about - not any less than about the end goal to release the game and see people enjoy it. Because of that the idea of live streaming the development process has been lingering in my head for a long time. The reason that I've waited so long to do it is probably that I haven't really had time to do much 3D art in the recent years since programming has always been the most time consuming and high priority thing to work on for Selenwald. I also mostly stopped doing 3D modelling for hire years ago because I needed a more time efficient way to earn for a living. Tech art (shaders, tools, etc.) and programming are paid better and they excite me no less than 3D modelling so I transitioned naturally. Ironically though, it's art that's the most interesting thing for people to watch as indicated by a little poll I conducted over on our Discord server. The most requested topics were 3D modelling and shaders/VFX so I chose to create a model of a fireplace and then make a fire effect to burn inside it.
Half-improvised
Creating a full blown 3D model from scratch using a traditional workflow is something too complex to be done from scratch within a time span of a single stream session, let alone along with the VFX. In order to make the show more digestible I decided to split it into two separate sessions.
My friend Jakub was kind enough to lend me some professional lighting equipment and a camera and after a failed foul start caused by some hardware and connection problems I've managed to get my first stream going.
The goal of this first session which took place on 4th January was just to create the 3D model, without the fire effect. As I said, the traditional workflow would still prove too long for such a prop to be done over ~3 hours (especially that my 3D modelling skills are very rusty these days). This is why I've chosen to model a fireplace in the first place as it wouldn't require me to go through all the usual steps - it's an unusual prop. Typically when you create a 3D model for a game, you need to go through the following stages (as I've described thoroughly in Dev Diary #3):
Draft / block-out (making sure the dimensions and the general form are good)
High-poly (modelling a high fidelity version of the model with tons of geometry)
Low-poly (modelling an optimised, simplified version of the model that will be used in the game)
Baking (transferring all the detail from the high-poly to the low-poly through special textures containing all sorts of information on the form, enabling the low-poly version to imitate the high-poly one)
Textures (creating textures by utilising the baked maps in a texturing software)
Implementation (exporting the final version in a way compatible with the game engine's pipeline and setting everything up in the engine)
However, in the case of this model only 3 stages were required:
Draft / block-out
Low-poly
Implementation
Why was that? That was because this fireplace was about to become part of a modular wall set that uses a workflow called trim sheets. In short, this technique is great for creating models that share common features and mostly utilise tiling patterns such as bricks or repeating reliefs. It enables you to go through the full high-poly modelling and texture map baking workflow only once in the beginning, creating a special texture set known as a trim sheet. Once you have the trim sheet, you can very effortlessly add more and more props that use it. Moreover, once you have many props using a trim sheet you can also create additional trim sheets using the same conventions you used when distributing patterns across the original trim sheet. This way you can easily create additional sets of props that share geometry but still look quite different - a more advanced version of so called "re-colours" if you will.
Both the trim sheet and the wall pieces that use it were originally created by my former colleague Aleksander and then finished/remastered by me.
Although I'm happy about how the model turned out, it still needs some tweaks as much of it isn't finished from a technical standpoint and it may need some additional details here and there. I intend to either finalise it before streaming the fire VFX creation or do it live alongside it - time will tell.
The continuation
The next session is planned to take place on the upcoming Friday (20th January) at 7:00 PM CET over at the Twitch channel. Although it is unlikely for the date to change, I will send a notice via our Discord server in case it does. Join it if you don't want to miss the broadcast.
They can talk now!
One of the most important things I've worked on recently was the dialogue system (which I made with the help of a framework called Dialogue System for Unity) and the disposition system. I have the basic setup ready and will soon bring it to a usable state so that I can implement a first friendly NPC and give existing hostile characters more character. That's right - hostile characters can be talked to on some occasions as well. Everything depends on their disposition towards you. Technically there's no distinction between enemies and friendly NPCs aside from the difference in disposition which you can influence.
Everything on the screenshot is work in progress!
I made the statue my debugging friend because it doesn't move much and doesn't attempt to kill me. However.. that doesn't necessarily cross out the possibility that you will be able to "converse" with it in the final version of the game.
For now, I placed the dialogue interface on the side because the traditional cRPG placement in the bottom has some serious downsides - not only it heavily limits the space on the screen but also partly conflicts with the existing UI in Selenwald. Besides, I've finally found some time to play Disco Elysium (which, by the way, also used that framework I bought) two months ago and have seen how well that kind of layout works there so I'm going to leave it like this for the time being. However, that doesn't mean it won't change since there some other viable options I consider. As a matter of fact, a lot of the elements in the current UI (mostly in the character/inventory screen) are very likely to change in the future.
That being said, I'll likely talk more in-depth about the dialogue system and the disposition system in another Dev Diary entry once they are developed further. Also, I plan to have the disposition system tied to other systems in quite a unique and interesting way so I'll gladly tell you more in the future.
Restoring order
Take a deep breath since you're about to read about the most thrilling story so far. Have you ever walked around with a full bladder for several hours that felt like ages to finally be able give in to the blissful feeling of letting it loose? Such a mundane thing, yet what a feeling it is! And that's exactly what what I felt when I finally brought order to all of the Selenwald's source files (primarily of 3D art) a couple of days ago after not finding time to do this for a year and a half. It took me around 3 days but it was well worth it.
As boring as it may sound, I find it very exciting for a good reason and want to tell you what mistakes I made along the way and what are some good practices related to storing source files (and working with people who send them to you in the first place).
So the trouble started as soon as I started to regularly hire freelancers in 2021. Most people are terrible at keeping their files neat so if you don't explicitly tell them how to name files, how to organise data between files and which files to send you for feedback, you're going to end up with a terrible mess of files that don't make sense and there's clearly too many of them but even their authors no longer remembered which files are good and which aren't so they sent you all of them for you to figure out yourself.
Accepting and keeping files like this kind of works at first when it's fresh and are in the loop. That's the trap because you're likely to leave it like this because you currently know what is what. And it will cause pain a couple months later when you need to find something among these files. It gets even worse if you leave the received files scattered across many locations - some in the Downloads folder, because hey, files have their "Created Date" and "Modified Date" so you don't really need to categorise anything. Files will be easy to scrub through if needed, right? Wrong! With tons of .zips and folders named like drive-download-20230118T194202Z-001 you won't even know what's inside, let alone decide what's actually the recent version. Especially that the "Modified Date" can get easily changed on many occasions without your intention and will also be changed by the source control system once the files are stored. You just can't rely on those. On top of that, people are likely to send you stuff in different pieces. For example, maybe they sent a folder of the final files but it turned out they forgot something so then they sent only what was missing. And you end up with 2 packages which both contain final files (and possibly some duplicates which makes things more confusing).
Things get even more messy when you're out of space and need to keep things on external storage devices. For me not only this happened but my primary monitor has died in January 2022 (and I was so broke at that time I couldn't afford a new one nor having the old one fixed) so I had to abruptly move my workstation to my laptop so I can have 2 screens again (it's impossible to work in gamedev with less than 2 monitors, trust me). So now some of the source files were on my stationary PC, some on my laptop, some on my portable SSD, some on my Google Drive and some on the cloud repository where the game project resides. If this doesn't sound like a nightmare I don't know what does!
And the thing that was making me anxious all the time was that many source files were not stored online. I was constantly worried that in a case of a tragedy such as my apartment going down in flames with both my computers inside, I'd permanently lose some some important source files. The project itself is - of course - hosted in a version control system since the very beginning. I used GitHub in the early stages of the development and later moved to Plastic SCM. But I was reluctant to put the source files there as well. And was was that?
Even neatly organised source files for a single 3D prop can weight like 2-3 GB which is more than the actual project files of the game are going to weight for a solid chunk of the development time. Now if your files are a mess, then they can easily weight several times more. For example, the source files I had for the game's UI weighted over 50 GB because they contained several packages I received from the artist and I didn't organise them while it was still an easy thing to do. Just dumping so many files into the source control sounded like madness to me as it would cost a lot of money to keep so much stuff up in the cloud so I only stored them locally. However, later on I realised that keeping source files in the source control system - just like the project itself - is the correct solution but I still needed to manually go through all the files and open them up one by one to make sure which are good and which aren't. That was the price of not enforcing order since the very beginning. Anyway, I knew doing the work now would enable me to compose a package of a manageable size and avoid worrying about bills eating me up.
Now that I've done it, my repositories containing both the project files and the newly uploaded and ordered source files weights over 75 GB which isn't bad. Everything is now relatively easy to find. And the stress is gone. What a relief!
Lessons learned
So what are my takeaways from the source files adventure?
Rigorously enforce naming conventions that have the date included. You can't trust the dates assigned automatically. I was actually taught to do this when worked for CView Studios / 4A Games several years ago but somehow forgot to introduce this in my own project. The convention I am likely going to use from now on is: [AssetName]_[FileType]_[YYYY]-[MM]-[DD]_[OptionalID] So for example: CutStoneFireplace_LowPoly_2023-01-18_2.fbx This would mean that this is the 2nd version of the low poly model of the fireplace received today. Also, the proposed date format is important here because this order will make it work with alphabetical ordering making things sorted chronologically.
Instruct people on how to best organise the data so that you don't end up with different elements of the same thing scattered across many files.
Immediately place all received files in one place. The best place would be the the target folder in the repository workspace, ready to be pushed to the server once you receive all the final ones and delete clearly useless old versions.
Absolutely use a version control system for source files, just like you use it for the game project files. Just remember to have a separate repository for it so that the game's repository stays lightweight. Alternatively you can use a service like OneDrive, Dropbox or Google Drive but I think proper version control like Plastic SCM is just better for this and you don't have to pay for 2 similar services at the same time.
I hope you learn from my mistakes and save yourself some trouble by having everything both well organised and safe in the repository from the very beginning!
Thanks for reading, Wiktor
Dev Diary #4: September/October 2022
Dear Scholars,
There is something satisfying in bringing an imaginary world to life in a physical and tangible form. Although it doesn't beat the joy brought by the sole process of the world's conception and development, the sensation of touching baroque style furniture, wallpaper, and decorations makes it seem like Selenwald is no longer confined to a program.
Selenwald has recently seen the light of day for the first time. It was shown at Poznań Game Arena - a gaming expo in Poznań, Poland. One of the major things I was focused on in September was bringing the rough demo to a somewhat presentable state so I wouldn't feel bad showing it publicly. Luckily, despite having many flaws and requiring a lot of assistance and explanation, it has made a much better impression on players than I had anticipated.
If you were there, thank you for visiting and playing - it was nice to meet you! If you weren't and you feel like you missed out on playing the game, no worries - there will be more opportunities in the future. On top of that, remember that the demo was still a very early version of the game that's not fully indicative of the final experience so you didn't miss that much after all!
One step closer
As some of you might already know, I'm actively looking for a publisher and/or an investor. It is imperative that I partner with one because I need to hire over a dozen of people to finish Selenwald in reasonable time and I am in no way capable of covering such costs all by myself.
In case you're wondering - crowdfunding is not a viable option for the project yet. It would require an enormous following for it to actually work and cover the entirety of development costs. Don't get fooled by crowdfunding campaigns that aim for sums like $50k. Games are much more expensive to make unless they have a tiny scope and can be done entirely by one person in a short period of time. If developers of more ambitious games run campaigns with small goals like this it probably means one the following scenarios:
the game is already fully funded and crowdfunding is only used as way of marketing
the game was funded but the studio has run out of money before finishing the game so it's looking for some additional cash
the developer or the publisher wants to sell pre-orders (for example, Steam rarely allows indie games to sell pre-orders directly on the platform so crowdfunding might be an alternative)
the developer is inexperienced and runs a crowdfunding campaign before realizing how expensive the development is really going to be which may lead to some bad things
Anyway, back to the topic. I'm already in contact with a lot of publishers. But what is it that prevents me from moving forward and signing a deal with one? Publishers and investors typically require several things in order to consider funding and/or publishing a game:
vertical slice
development schedule
budget breakdown
A delicious pie
What on earth is a vertical slice, you ask? It is part of the game development jargon and a metaphor for a playable demo that feels like a short excerpt of the finished game - a single slice of a tasty pie with all the layers. Now that's a bit of a problem. In the case of a system-heavy game such as Selenwald, having an actual, true vertical slice would mean being probably like half way through the development process. Selenwald now has a playable demo that is far more advanced than a mere prototype but also far from having all its systems and features in place. This means that publishers that strictly require a full blown vertical slice are a no-go because getting to that stage of development without external money would take too much time. However, I am also trying to get more government funding but more on that later. Luckily, some publishers are already expressing their will to publish Selenwald without requiring a demo in a more advanced state than it's currently in. Therefore, this bullet point can finally be crossed out!
Money and time
The other two, tightly related things required by publishers are a detailed budget and a crystal clear roadmap which will prove I actually know what I'm doing. That is something I have roughly had for a long time. I knew what the approximate total budget is going to be, how many people need to be hired and how will the budget be distributed. What I haven't had until very recently is the project schedule planned out all the way until the release. So far I've only ever created tasks for up to a couple of months ahead. However, time has come to carefully plan out everything until the release. Not only it is needed in order to provide an overview of which project milestones could realistically be expected at which deadlines but it's also the only real way to confirm that the budget was estimated correctly. In a perfect world every single project task should be laid down upfront. And that's precisely what I've been recently doing.
The perfect plan
In case you don't know much about game development, the headline of this paragraph is a bit of a poetic stretch. In this industry no such thing as a perfect plan exists. Like the documentation, most plans are out of date the moment they are written down. However, it's still extremely useful to go through it and prepare as much as possible before the project enters the stage of full production. Now is the time to identify some possible problems, determine exactly how many people will need to be hired, and calculate the total cost that is close enough to ground truth to be treated as such. So how to actually go about calculating the budget? There are mostly two ways - making a detailed spreadsheet or creating tasks inside a project management tool right away.
For me the choice was simple. Lots of tasks needed to be prepared so this time I skipped making a spreadsheet altogether as I would later need to manually transfer the tasks anyway. Additionally, project management tools have proper metrics so there wasn't really anything I could gain from making a gigantic spreadsheet.
The right tool for the job
I have been using HacknPlan as my project management tool of choice ever since I started making first prototypes for Selenwald in 2016. What is it, really? It is something akin to Jira and Trello but made specifically for game development. If you're an existing or an aspiring game developer and you don't use it, let me show you why you should consider trying it out on your next project.
Of course it has an obligatory Kanban board where you can keep your tasks on display. It also has a lot of metrics, various planning tools (including a Gantt chart), is pleasant to look at, and is highly customisable. However, there's one feature that makes it stand out the most.
The tree of life
The Design Model is probably the most important reason I like HacknPlan so much. It's a tree-like structure that lets you map out the planned features and content in your game. Design Elements are entities separate from tasks. They can be arranged in a hierarchy and each design element can have a description. It's basically a nice alternative to a classic Game Design Document but it comes with some clever solutions that also tie it to the production planning infrastructure.
In my opinion the single most important feature of HacknPlan is that every task (that isn't already parented to a Story task) can be parented to a Design Element. Here's what makes it so useful:
Work becomes oriented around content and features No more searching through different boards to find all tasks that revolve around a certain enemy in the game just because the enemy was being worked on continuously through different milestones. U can simply select the enemy in the Design Model and immediately see all the relevant tasks.
Changing task names Imagine that when you start working on a character you only know that they're going to be a mage you first encounter in a tutorial. So you name the first task "Draw concept art for a tutorial mage". You have some discussions in the task's comments, you make the art and close the task. Then much later in the project you decide that this character is named Diana and all further tasks around her mention her name (e.g. "Write dialogue for Diana"). Now good luck if someone wants to go back to that old discussion in the comments but nobody remembers where it was and you can't just find that old task by the name Diana. That problem is gone with the Design Model because when you start working on a placeholder character you create a Design Element for them right away (e.g. "Tutorial Mage #1") and tie all tasks to it. It becomes your go-to place whenever you want to discuss it and you can later rename the entity to "Diana" while retaining the link to that first task (still named "Draw concept art for a tutorial mage"). Everything remains connected and you won't ever lose track of the old tasks still using placeholder names.
Wiki-like structure There's a useful feature that lets you easily link tasks and Design Elements to each other inside their descriptions. This eliminates the drawbacks of the linear nature of a tree hierarchy and enables the user to easily find elements from different branches using a network of links.
Feature/content based metrics You can very easily see what is the progress on specific parts of the game as every Design Element has its own metrics based on the tasks associated with it. Every entity with tasks gets a progress bar and the metrics propagate up through the hierarchy.
Design Elements as task templates You can duplicate Design Elements together with all the tasks that are attached to them. This way they serve as templates and you don't need to manually create separate sets of task for every e.g. weapon in the game. Plan out just one and quickly make as many clones as you need.
GDD exporting In case you ever need an old fashioned Game Design Document that nobody reads, you can always export the Design Model tree into a linear text format.
The current status
I haven't finished building the detailed production plan yet but here's some data in case you're interested in numbers:
3103 tasks have been created in total so far
2093 tasks are currently open
the open tasks add up to 3787 work days, which approximately means that there's work for 12 people assuming a 1.5-year development time or 9 people assuming a 2-year development time
These numbers will further grow as I wrap the schedule up in the nearest future but hopefully it already gives you some insight on how much it takes to make a game such as Selenwald. By the way, this is typically one of many responsibilities of a producer. Obviously, here that's just another hat I need to wear but in the future there will be a dedicated person to handle production in the team so I can spend more time directly working on the game.
Something brewing
While partnering with a publisher is the most likely future for Unnamable Arts, I'm still always on the lookout for alternatives. One of such options are government grants. They would not be enough to fund the entirety of development but could help me grow Selenwald enough to make crowdfunding a possibility. Most programs have very specific requirements and rarely fit Selenwald. Others are a bureaucratic nightmare and the enormous effort isn't always worth the money. But recently a nice little program popped up and I decided to apply. A success would help tremendously. The results should be revealed next week so make sure to join our Discord server if you're still not a member as I will surely share the news in case I manage to get that financial help.
Thank you for reading, Wiktor
Diary Page #4: Boards and Metrics
Dear Scholars,
There is something satisfying in bringing an imaginary world to life in a physical and tangible form. Although it doesn't beat the joy brought by the sole process of the world's conception and development, the sensation of touching baroque style furniture, wallpaper, and decorations makes it seem like Selenwald is no longer confined to a program.
Selenwald has recently seen the light of day for the first time. It was shown at Poznań Game Arena - a gaming expo in Poznań, Poland. One of the major things I was focused on in September was bringing the rough demo to a somewhat presentable state so I wouldn't feel bad showing it publicly. Luckily, despite having many flaws and requiring a lot of assistance and explanation, it has made a much better impression on players than I had anticipated.
If you were there, thank you for visiting and playing - it was nice to meet you! If you weren't and you feel like you missed out on playing the game, no worries - there will be more opportunities in the future. On top of that, remember that the demo was still a very early version of the game that's not fully indicative of the final experience so you didn't miss that much after all!
One step closer
As some of you might already know, I'm actively looking for a publisher and/or an investor. It is imperative that I partner with one because I need to hire over a dozen of people to finish Selenwald in reasonable time and I am in no way capable of covering such costs all by myself.
In case you're wondering - crowdfunding is not a viable option for the project yet. It would require an enormous following for it to actually work and cover the entirety of development costs. Don't get fooled by crowdfunding campaigns that aim for sums like $50k. Games are much more expensive to make unless they have a tiny scope and can be done entirely by one person in a short period of time. If developers of more ambitious games run campaigns with small goals like this it probably means one the following scenarios:
the game is already fully funded and crowdfunding is only used as way of marketing
the game was funded but the studio has run out of money before finishing the game so it's looking for some additional cash
the developer or the publisher wants to sell pre-orders (for example, Steam rarely allows indie games to sell pre-orders directly on the platform so crowdfunding might be an alternative)
the developer is inexperienced and runs a crowdfunding campaign before realizing how expensive the development is really going to be which may lead to some bad things
Anyway, back to the topic. I'm already in contact with a lot of publishers. But what is it that prevents me from moving forward and signing a deal with one? Publishers and investors typically require several things in order to consider funding and/or publishing a game:
vertical slice
development schedule
budget breakdown
A delicious pie
What on earth is a vertical slice, you ask? It is part of the game development jargon and a metaphor for a playable demo that feels like a short excerpt of the finished game - a single slice of a tasty pie with all the layers. Now that's a bit of a problem. In the case of a system-heavy game such as Selenwald, having an actual, true vertical slice would mean being probably like half way through the development process. Selenwald now has a playable demo that is far more advanced than a mere prototype but also far from having all its systems and features in place. This means that publishers that strictly require a full blown vertical slice are a no-go because getting to that stage of development without external money would take too much time. However, I am also trying to get more government funding but more on that later. Luckily, some publishers are already expressing their will to publish Selenwald without requiring a demo in a more advanced state than it's currently in. Therefore, this bullet point can finally be crossed out!
Money and time
The other two, tightly related things required by publishers are a detailed budget and a crystal clear roadmap which will prove I actually know what I'm doing. That is something I have roughly had for a long time. I knew what the approximate total budget is going to be, how many people need to be hired and how will the budget be distributed. What I haven't had until very recently is the project schedule planned out all the way until the release. So far I've only ever created tasks for up to a couple of months ahead. However, time has come to carefully plan out everything until the release. Not only it is needed in order to provide an overview of which project milestones could realistically be expected at which deadlines but it's also the only real way to confirm that the budget was estimated correctly. In a perfect world every single project task should be laid down upfront. And that's precisely what I've been recently doing.
The perfect plan
In case you don't know much about game development, the headline of this paragraph is a bit of a poetic stretch. In this industry no such thing as a perfect plan exists. Like the documentation, most plans are out of date the moment they are written down. However, it's still extremely useful to go through it and prepare as much as possible before the project enters the stage of full production. Now is the time to identify some possible problems, determine exactly how many people will need to be hired, and calculate the total cost that is close enough to ground truth to be treated as such. So how to actually go about calculating the budget? There are mostly two ways - making a detailed spreadsheet or creating tasks inside a project management tool right away.
For me the choice was simple. Lots of tasks needed to be prepared so this time I skipped making a spreadsheet altogether as I would later need to manually transfer the tasks anyway. Additionally, project management tools have proper metrics so there wasn't really anything I could gain from making a gigantic spreadsheet.
The right tool for the job
I have been using HacknPlan as my project management tool of choice ever since I started making first prototypes for Selenwald in 2016. What is it, really? It is something akin to Jira and Trello but made specifically for game development. If you're an existing or an aspiring game developer and you don't use it, let me show you why you should consider trying it out on your next project.
Of course it has an obligatory Kanban board where you can keep your tasks on display. It also has a lot of metrics, various planning tools (including a Gantt chart), is pleasant to look at, and is highly customisable. However, there's one feature that makes it stand out the most.
The tree of life
The Design Model is probably the most important reason I like HacknPlan so much. It's a tree-like structure that lets you map out the planned features and content in your game. Design Elements are entities separate from tasks. They can be arranged in a hierarchy and each design element can have a description. It's basically a nice alternative to a classic Game Design Document but it comes with some clever solutions that also tie it to the production planning infrastructure.
In my opinion the single most important feature of HacknPlan is that every task (that isn't already parented to a Story task) can be parented to a Design Element. Here's what makes it so useful:
Work becomes oriented around content and features No more searching through different boards to find all tasks that revolve around a certain enemy in the game just because the enemy was being worked on continuously through different milestones. U can simply select the enemy in the Design Model and immediately see all the relevant tasks.
Changing task names Imagine that when you start working on a character you only know that they're going to be a mage you first encounter in a tutorial. So you name the first task "Draw concept art for a tutorial mage". You have some discussions in the task's comments, you make the art and close the task. Then much later in the project you decide that this character is named Diana and all further tasks around her mention her name (e.g. "Write dialogue for Diana"). Now good luck if someone wants to go back to that old discussion in the comments but nobody remembers where it was and you can't just find that old task by the name Diana. That problem is gone with the Design Model because when you start working on a placeholder character you create a Design Element for them right away (e.g. "Tutorial Mage #1") and tie all tasks to it. It becomes your go-to place whenever you want to discuss it and you can later rename the entity to "Diana" while retaining the link to that first task (still named "Draw concept art for a tutorial mage"). Everything remains connected and you won't ever lose track of the old tasks still using placeholder names.
Wiki-like structure There's a useful feature that lets you easily link tasks and Design Elements to each other inside their descriptions. This eliminates the drawbacks of the linear nature of a tree hierarchy and enables the user to easily find elements from different branches using a network of links.
Feature/content based metrics You can very easily see what is the progress on specific parts of the game as every Design Element has its own metrics based on the tasks associated with it. Every entity with tasks gets a progress bar and the metrics propagate up through the hierarchy.
Design Elements as task templates You can duplicate Design Elements together with all the tasks that are attached to them. This way they serve as templates and you don't need to manually create separate sets of task for every e.g. weapon in the game. Plan out just one and quickly make as many clones as you need.
GDD exporting In case you ever need an old fashioned Game Design Document that nobody reads, you can always export the Design Model tree into a linear text format.
The current status
I haven't finished building the detailed production plan yet but here's some data in case you're interested in numbers:
3103 tasks have been created in total so far
2093 tasks are currently open
the open tasks add up to 3787 work days, which approximately means that there's work for 12 people assuming a 1.5-year development time or 9 people assuming a 2-year development time
These numbers will further grow as I wrap the schedule up in the nearest future but hopefully it already gives you some insight on how much it takes to make a game such as Selenwald. By the way, this is typically one of many responsibilities of a producer. Obviously, here that's just another hat I need to wear but in the future there will be a dedicated person to handle production in the team so I can spend more time directly working on the game.
Something brewing
While partnering with a publisher is the most likely future for Unnamable Arts, I'm still always on the lookout for alternatives. One of such options are government grants. They would not be enough to fund the entirety of development but could help me grow Selenwald enough to make crowdfunding a possibility. Most programs have very specific requirements and rarely fit Selenwald. Others are a bureaucratic nightmare and the enormous effort isn't always worth the money. But recently a nice little program popped up and I decided to apply. A success would help tremendously. The results should be revealed next week so make sure to join our Discord server if you're still not a member as I will surely share the news in case I manage to get that financial help.
