How do you organize your quest data files?

[alexgleason]

Here's how badly disorganized I am:



It's becoming an actual blocker for me. I'm afraid to create new maps and experiment because I don't want to worsen to this mess.

I may solve this by writing documentation on how Vegan on a Desert Island's files are organized. But I'm curious if anyone has already done this, or has any insight to offer.

Some parts I'd like to cover:

• Dialogs - when do you create folders? Do you categorize by area, by character, by time period? How do you organize branching dialog?
• Maps - same as above.
• Sprites - when do you create new a sprite sheet? what is the folder structure?
• Scripts - same as above.

[Max]

Lol, that stresses me out. Personally, the only things I want in my maps folder are subfolders, more subfolders, and a debug room.

My world is broken up into islands, which helps. But for each island's folder, I've got 4-10 overworld maps, and each area has a unique name. Then any towns have folders for building interior maps, and there's a folder for any small caves in the overworld. Anything mini-dungeon to main dungeon has its own folder inside its region's folder. Every island has the same file structure. I also wish I was a bit better organized, haha, but I think everyone always will.


I do my dialogues similarly. Every island has a folder for NPCs, observations the protagonist makes to herself (or reading books and posters), and signs. Inside each of those folders, there's sub folders dividing the category geographically, so like, signs in the forest region of Goatshead Island. There's maybe only one or two in some subfolders when you divide down this much, but it's consistent and I know where to look for stuff.
I think a fairly typical structure is like:
oakhaven_island/npc/oakhaven_port/portside_shop/shopkeeper/3
For major characters, sometimes they'll have several subfolders for each time you encounter them or different phases of a quest they're involved in, or else sometimes there will be different folders for the same character in different regions. This inconsistency bothers me but it's too late at this point!


It seems to me like you need some paths like maps/forest/tree, or maps/beach/water_dungeon/3. I don't know if your overworld makes sense to divide into regions with areas in each region, but if it even makes sense for a few areas, you should do that before you get even more disorganized, if it's stressing you out. Good workflow and workspaces lead to better work!

[alexgleason]

Thanks so much for writing this out! This exactly the type of info I was hoping for.

[llamazing]

Do you define the world property for your maps? If so it makes sense at a minimum to split into directories based on the world, and then maybe more subdirectories on top of that as needed.

For dialogs, I first split them into directories based on which menu is used for the dialog (and the dialog_box.lua dialogs being the most prevalent don't need a dedicated directory).

In my Cythera project I had additional dialog menus for system level messages (like "do you want to save?"), and I had a sleep menu dialog that had exactly one dialog. For the regular dialogs (with NPCs), I separated them by the NPC, and in my project NPCs could travel between maps and were still considered the same entity (so it didn't make sense to separate the dialogs by map). My dialogs were also way more complicated than most Solarus quests, so the details beyond that are probably not relevant.

For scripts, I usually create a subdirectory to group related scripts together (like if there are multiple subclasses each defined by their own file). I also usually try to separate actual scripts from the data, making one file that ends in .lua and another that ends in .dat, but only when it makes sense to do so. There are multiple reasons for doing it this way:

• Data files have a separate license from the script itself
• Easier maintenance: can replace just the script file with the latest version and data remains unchanged
• Better conceptually because each quest using the script will likely customize the data but not necessarily the script. So it segregates things between the things you'll probably want to modify (the data) from the things that only advanced users will want to touch (the script itself).