Modding

NOTE: I strongly recommend reading the development blog (link above) before reading this, as this evaluative piece references the blog several times.

At the start of the project, I set out to learn a new system and create a project with these skills, as outlined in my Statement Of Intent (Blog Post 1). As such, there was a significant amount of time at the beginning of the project where time was not put into creating work, but rather into learning the functions and how to create assets using XML, specifically the way XML is integrated into RimWorld and how the game reads and writes these files. I discovered that XML code acts very similar to a form of data storage, and that the values within the data fields of XML are read by RimWorld to create anything from weather events, animals, biomes, health effects, characters and weapons. Anything that is a part of a RimWorld game has a corresponding XML file, and by creating my own XML files, I can create new, independently standing aspects of RimWorld. Whilst this meant that work itself on the project started out delayed, it meant that I was able to move into a rapid prototyping stage straight away. As such, this stage of development proved useful to me.

The rapid prototyping stage was also a success. At this point, I was still learning the core of RimWorld modding, such as file structure, syntax and developmental capabilities, but also began creating easy, small mods to prove that I could create new assets, such as the gun mods I created shown off early in the blog (Blog Post 3). The loop of Copy > Edit > Test > Edit became apparent here, that being the developmental cycle of RimWorld modding. When creating a Mod for an object, it is beneficial to copy a pre-existing assets XML data to act as a starting point. You then overhaul this data, creating, editing and removing fields and values as needed. This data file, over many, many edits then becomes its own entity in-game, and can act as a stand-alone game object. Then, testing to see how this new asset works, and following this testing up with further editing, enables the player to create new assets with XML data. Whilst it did take time for work to start being produced as mentioned, as I was learning an entirely new system by myself, I was able to use these rapid prototypes as a means to learn this development cycle, and as such, looking back on it see this stage of development useful as well.

The learning process itself was a success, and featured many different forms of information. The RimWorld Wiki itself has a tutorial aimed at those learning modding for the first time (which can be found at https://rimworldwiki.com/wiki/Modding_Tutorials), whilst forums and communication channels such as the official RimWorld Discord channel, which I joined due to the large modding community present, acted as suitable methods of conversation for those seeking to help with and needing advice and guidance. Personally, I feel that my drive to seek out resources and learning activities, and the process of teaching myself what I needed to know regarding this new system was a success, and was an incredibly beneficial learning experience.

Once a suitable level of knowledge regarding XML and RimWorld modding in general was attained, I began work creating extensive documentation to showcase my plans. Personally, I feel that creating documentation alongside my work allows me to track, plan and evaluate my work far better than without. I feel that planning my work ahead of me using project plans results in a far clearer visualisation of the workload ahead of me and what is to come within the project. Once I felt that the documentation was in a suitable place, I began development. I used the documentation to assist me in creating the project, and was able to complete a major goal of mine in just over a week. This shows that, with the education and documentation provided to myself that I created, I am able to work at a more than suitable pace for this project, and make substantial progress using what I have acquired.

Despite the workflow of the project going off to a great start, I quickly came across issues that greatly slowed me down. A full explanation of the issues can be found in the blog, but to summarise, I mistook the capabilities of an XML file and what it could do (Blog Post 8). I thought that by using the aforementioned process, of copying an asset and repurposing it, that I could create a new one. However, the asset in question; a <thoughtDef> (a tag that when applied to a character, gives them a “thought”) responsible for making a character think lower of another character if they had the “Ugly” Trait, could not be repurposed, as whilst this <thoughtDef> has an XML file, it only acts as a connector for the file and the hard C# code of RimWorld. Whilst I know some C#, this knowledge only extends to 3D character controllers and mechanics and functionality to do with those. The code of RimWorld, and the knowledge to manipulate and write code similar to it, were aspects of developing mods that I knew would be out of scope to learn alongside XML. As such, I came to realise that there were aspects of this mod that would be, unfortunately out of reach for me.

Once the present issues were resolved, I was unable to work on the project for a sustained period of time due to prior arrangements. Alongside this project, I had been tasked with creating a game as part of a team project, SpiritSweeper. As we neared a crucial point in development, we, as a team, focused our efforts on creating a vertical slice for our game to showcase in a major pitch meeting, seeking to acquire funding for our game through a program that we, as a team, had dedicated a significant amount of time towards. As a consequence of this, however, it meant that I had less time during this time of focused work to work on this mod. This was unfortunate, and despite the fact that I dedicated an immense amount of time to our team game which proved useful to the success of the project, this was time that I couldn’t get back for my mod.

Once the meeting had been and gone, I was able to dedicate more time into this project, and got back into researching and working towards the completion of the mod. However, a similar issue that affected me in the past cropped up again. The Titans, a key cornerstone of the project, would not be able to be completed. This wasn’t due to a factor of me incorrectly scoping the project, or it being locked behind a skill I didn’t know. This issue was due to the fact that it would literally be impossible to make the Titans perfectly: in the source material, they only ever ate human beings and completely ignored animal life, a primary source of the uncanny-ness to their design, at least, early into the original story. In the mod, however, this was not replicable, as there was no value to set the Titan XML value to only ever eat humans (read blog post 9 for more information, as well as an explanation as to why this wouldn’t work due to the way RimWorld handles dietary information for creatures). This was a key part of a major goal I wouldn’t be able to accomplish, not due to a lack of knowledge or failure on my part, but because it simply was not possible.

This would be a reoccurring issue: the inability to create aspects of the mod perfectly, only get close, perhaps over 90% of the way there, but be unable to get that last 10% complete not due to a lack of skill or knowledge, but because it was simply not possible. The ODM Gear, for example, a new asset I added, would function near to what I originally set out to create. However, instead of being able to create a new resource meter and have that drain when in use, as I intended to, I had to use a pre-existing resource and have the ODM Gear drain that instead. Sometimes, as was aforementioned with the <thoughtDef>, something would be unable to be created due to a lack of knowledge of C#. However, aspects like the Titans and ODM Gear would simply be unable to be completed, due to the sheer impossibility of the fault of the functionality of the original game. Hence, these assets are considered 90% to their full functionality. Despite this, the workarounds described in the blog result in a player experience similar to what a 100% complete asset would be, such as the ODM Gear requiring the player to be cautious with its use at the risk of a character being unable to use it for a while, albeit by making the user incredibly tired when using it instead of draining a physical resource when in use.

I was concerned regarding this level of completion, but ultimately pushed forwards. By reducing the scope as, due to the aforementioned delays, there would be no way that all of the intended assets could be created, and focusing my efforts on creating enough assets to create a suitable gameplay loop, I was able to produce a mod suitable for submission. I focused on showcasing the 90% that I could produce, a 90% that I learned an entirely new system for, and a 90% that I am quite proud of. By pushing forwards this way, the mod managed to get to a stage where it could function on its own as part of a RimWorld add-on. There were no bugs or gameplay issues to be found after hours of testing; one could add this mod to their RimWorld mod folder and play with it with no negative consequence to their gameplay; the additions the mod provides simply being an additional portion of gameplay to the original game. Due to this, I can say overall that this project was a success. Despite many fallings, I was able to push through and create the best project that I could, something that I am proud of, and something that, after I spend some time adding some polish to the mod where I can, I plan to release to the Steam Workshop.

This additional work will not be part of a project, rather I am choosing to do it because out of anything, it will be fun. This project was ultimately a learning experience, and one of the major things I took from this learning was that modding games, and modding RimWorld in particular, is fun. The process of researching, breaking down and repurposing a game and discovering the underlying data, taking it apart and putting it back together to create something new, is a process I find incredibly gratifying to go through. Creating anything is an inherently fun process for me, and taking up modding RimWorld as a hobby of sorts is something I look forward to in the future. The learning process was a long, difficult but incredibly rewarding one, learning the new systems that I did is something I am incredibly proud of, and enabled me to create this project to this level. I will then take away from this learning process skills and the knowledge to continue modding these projects in this way, and move forwards with these skills.

The work that I created can be potentially described as a translation: the creation of this mod has seen me translating story content from Attack On Titan from plot points and story components into game objects and assets in RimWorld. One metric to judge the quality of the mod itself is the quality of this translation: how well was I able to replicate the individual assets in-game?

The Titans, for example, are near-perfect. The biggest flaw comes from their diet; as mentioned extensively in the blog, they hunt most animals, not just humans. There are plot aspects about Titans in the original story that I am not attempting to recreate here, but these were redacted from the beginning of the project due to scope. As such, the merit to judge them on would be based on the project plan viewable in the blog (Blog Post 6). All aspects of Titans, apart from their diet, are suitable for the mod. Despite this, the missing functionality takes away part of the “experience” of the Titans; an uncanny aspect to them that they only ever seek out humans, and leave all other animal life alone. Despite this, from an evaluative viewpoint, I can say that I am happy with the Titans.

This mindset extends to the Titan Walls; the functionality for which is detailed in the blog as not walls, but rather incredibly large columns. I detailed their development early in the blog - a part of the project I feel was successful.

The ODM Gear is a part of the mod I have mixed feelings about. Where I feel that my ability to create a high-quality mod here faltered, my skills as a designer somewhat make up for this. What I mean by this is that as a translation directly, it really wasn’t that strong of a success, several aspects of the ODM Gear failed to make the translation, primarily due to scope, such as animations to show the grapple system, a gas/fuel system mechanic, and the restriction of use to areas with high rising solid terrain, eg buildings or trees. These aspects are all functionally possible in RimWorld, but were cut due to scoping restraints. Despite them being cut, a “smoke and mirrors” approach was taken to, with a low scope, get as close to the intended functionality as possible. The gas/fuel system, for example, was meant to restrict use by acting as a resource that would be gathered over time, and depleted when the ODM Gear was used. To get as close to the resultant experience as I could, I added a stat debuff to the ODM Gear when it is being used; the character's rest need will drain far faster than normal. This means that the player still has to manage the use of the ODM Gear wisely, or else the resource (the characters need for rest) will deplete further. Further detailing of the ODM Gear functionality can be seen in the blog.

The ODM Gear, as mentioned, comes in two parts, the Gear and the Blade. The Blade asset itself was meant to include a new damage type, Anti-Titan damage, to have an increased effectiveness against Titans, but normal melee weapon effectiveness against everything else; the Titans themselves would have a modifier making them take more damage from the Anti-Titan damage type. This was a solid plan, but the scope required to create a new damage type was too large, as it required knowledge of hard C# code. However, I realised two things: I can set the damage type to a pre-existing damage type, so that whatever damage type I set the ODM Blades to will have the same effect, as long as I add a weakness to this damage type to the Titan XML data. I looked over the other damage types melee weapons were capable of, such as Slice, Stab, and Poke, but found none of these suitable, as they were used frequently by other melee weapons. I did, however, find a damage type suitable for this: Bite. The Bite <damageDef> is used for biting, namely a melee attack by an animal. So, in order for this damage type to be used, I had to set it so that the ODM Blades technically “bit” the opponent, that Titans were incredibly weak to being bitten, and that there were nothing else that could “bite” titans. The first two were easy enough, simply change the values that I had already created and created a structure for in the XML data. The third, however, was already done, as the Titan, due to immense size, could not be bitten by anything else. This is because RimWorlds predator/prey system has a size aspect to it, a predator has a value within its XML code to determine the maximum size of its prey. Titans are set to, as the name suggests, a far larger size than any other creature in the game, and therefore are not hunted, meaning that nothing can “Bite” a Titan, meaning that the use of this damage type for the ODM Blades was actually suitable.

As a side note, I added the prey restricting value to the Titan XML data, and set it so that, while it still eats everything else the same size and below, Titans will not hunt creatures larger than humans. This means that their diet is restricted, to some degree after all.

This shows an evaluation of the work that I have created, how happy I am and why with the major assets created, as well as what workarounds I utilised to mitigate major roadblocks I faced.

Personally, I feel that as a worker during the project, I struggled, but ultimately tried my best, pushed through and achieved something that I feel I can be happy with. There were several, major roadblocks that I came across, prior engagements that halted my progress, and in all honestly times I considered dropping this project entirely and restarting anew. Despite these numerous setbacks, through careful planning, scoping, and a lot of smoke and mirrors within my designs, I believe that I created a project that I am happy with, learning new skills and systems along the way. Skills that I will take forward with me to develop and work on separately from any prior work engagement, as aforementioned, for the fun of it; modding is something that it turns out I simply enjoy.

As the first mod I have ever created, and the first major product outside of Unity Engine, let alone the first RimWorld mod, a learning experience and an attempt to push my skills and boundaries outside of my comfort zone, this project was a success.