Alpha Devlog 2: A Workflow Example, Creating the Guild

I recently decided to implement the guild, the analogue to the hamlet in Darkest Dungeon. It's a place where you return after each dungeon run to hire new adventurers, resupply, and cure whatever ailments affect your adventurers. During the process I made screenshots to detail the process. I hope it helps you gain some insight in how the content design workflow is handled.

I had some earlier projects before Ero Witches, and they all got abandoned when it came to the content design part. In fact, getting all systems up and running (movement, combat, UI) is the easy part. Adding all the content is the hard part, which is also why many people prefer to keep adding new mechanics when building a game, the scope creep isn't a bug it's a feature. So having a good workflow for it is rather useful, and the one I'll detail works for me.

Gathering Ideas

The first thing I did was jot down some ideas of buildings that had to be in the guild, as well as what those buildings would do. There's always a desire to just make a single item and then start coding already, but that's a horrible idea. Many of the problems you'll face come with scale. It's hard to know what the buildings would have in common if you have only thought of one building.

In fact it's something I see often in Youtube tutorials. The guy will make an inventory with one or two items, which is worthless, since many problems with design only start surfacing once you have more of them. Anyway, this means that I wanted a semi-complete list of all buildings. So, in my best handwriting, I cleanly and neatly wrote this all down:

Flat Data

Ideas aren't worth much if you can't put them into the engine. For this I use Excel. Spreadsheeting programs are extremely useful for tasks where you want to be able to quickly write down and modify data. Imagine that you want to double the damage of all your weapons in a normal editor, you'd have to open each individual weapon and modify the damage value. In a spreadsheet, you just modify everything at once. It also makes it extremely clear what you need to add if you want to expand your data. There are of course problems with data validation (you can write whatever you want wherever you want) but I'll tackle that later.

Anyway, I first need to put the ideas from before in a format that will work for later processing by the editor. Thinking from an object oriented point of view I quickly decide on the following:

So I'd need two Excel sheets, one for the buildings itself, and one for all the effects a building could have.  The buildings were pretty simple, like everything in the game it's an item that will want an ID, an icon and a name. With here an additional standing image to show to the player just like in Darkest Dungeon, and then all the effects that are unlockable within this building. You'll notice I somewhat gave up near the end, feeling that I already had enough content to get a decent workable prototype

The effects are less straightforward, and many things I want these effects to do don't exist in the game yet. But that doesn't deter a gamedev, I'll just pretend that these are implemented and write the script that would implement it in a column. Later madodev will have to implement it then. This is important though, don't limit yourself to things that are already in the game, treat your content creation as a design document of things you will want to include.

I also decide to add some fields for "slots" within the building. For example putting an adventurer on such a slot in the tavern will lower their lust and give you some gold. And again, I don't let reality deter myself from pretend script writing. Morale, an analogue for the torch in darkest dungeon, isn't even in yet. But it will be in eventually, and at that point those maids will have to increase it.

Anyway, the whole process of thinking up these things and then getting this data into Excel took about three hours. It's important to note that none of this is balanced, but that's not the point. You need a basis to start your game design from. It's a bit like the ship of Theseus, surely at the end of the journey the ship will be completely different. But you can hardly start sailing without a ship in the first place. Anyway, below is the final data for building effects.

Import

I have some neat Macros (taken from StackOverflow, the OG ChatGPT) that convert these Excel sheets into txt-files. Which means I just have to read those into Godot to get all the data I need for the project. 

Of course there is no guarantee that any of the data in the Excel is correct. Maybe I misspelled gold somewhere, or linked to an incorrect icon in the icon field, or whatever else can go wrong. That's why many games make their own tools with built in validations, so the developer can't input wrong data. But, as mentioned before, that slows down the process. So I prefer to do the validation when importing the data into Godot.

I start by putting together all txt-files in a certain folder into a dictionary.

Then I loop over each of them by ID, and print out the data that is available from the source file.

Then I do some checks whether the data is correct, and send myself a kind reminder to fix it if it isn't. Importantly I don't stop the game if something is missing. I might decide not to add icons immediately, and wait until I can do more of them in one go, but still want to do something else in the meantime. The warnings also give me a nice list of todo's, which does boost productivity.

Once all data is verified, it can be used to create a resource. For example, based on data from the import, I can now create building resources to be used in the process.

Those resources are made in a Singleton/Autoload Factory. So if I want a building I just write Factory.create_building(building_ID), and poof I have the resource.

UI

So, now we have  the resources we need to start creating the UI. This part was the Engine agnostic one, so I spent the most time on it. Once this data is in the Engine, it depends on your Engine what you do with it. But in short, I construct my UIs as follows:

So you have a Panel with a bunch of Blocks, each which can have a bunch of Blocks again. In code it looks like this:

Another thing that's important to mention is that your UI should never change the underlying data. I have a specific guild resource that keeps track of all adventurers and what they're doing during the day. All the UI is allowed to do is call functions on that guild resource. If the guild resource is changed, it will reset the entire UI based on the content of the guild resource. So, in fact, the UI only displays stuff, it's not allowed to think by itself. It seems very inefficient, but I haven't noticed any optimization problems due to this, and it means that UI bugs become pretty much non existent.

Screenshots

Anyway, the devlog has gone on long enough. So here's some more screenshots (all under construction) if you made it through all the technical stuff:

Upgrades.

Slots within buildings.

Adventurer Overview.

Dungeon Selection: