What changed
0 fixes3 additions2 changes0 removals
changedThe 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.
changedBut 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.
addedBut why?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.
addedBut why?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.
addedBut why?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
Selenwald changes
changedThe 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.
changedTechnical 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.
addedNon-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.
addedNon-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.
addedComplex 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
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
