WALL OF TEXT INCOMING!!!
TLDR; I would be interested in one or both of the following suggestions. 1. A fancy file browser for managing my assets and art resources, with a focus on adding labels or tags to help filter results or workspace to what I want to work with. A pipeline tool that takes an organized asset folder, and provides code or some means for a game engine to know how to understand said folder structure so that simpler code or commands could be used in making the game, ie to change a character to a talking image with the code automatically keeping track of the mood or going to a mood neutral version of the image.
So I'll attack this from a more technical artist or programmer background, but note I haven't really finished a project, just build up skills and techniques/tools. From what I understand, many other users and active devs use renpy, but I myself am not familiar with its use.
My main thing is organization, reusability, and readability. Classical goals for any programmer. But organizing what? Mainly, art resources; backgrounds, characters, different moods, outfits, time of day, etc. even keeping a record of versions sometime. Mainly this is organized by using standard folders and smart naming. But this poses 2 issues, 1. the data is still raw, and 2. it is organized hierarchically.
By raw, I mean, it is just images, It is still up to me to manually code in access to images and tagging them. It doesn't lend itself to easily being incorporated into a project. That is to say there is no automation. And not that it would be easy to automate, even as is, it still isn't in a format that the game will use. Be it unity's resource manager (which looks to have gotten better with the 2019 versions), or monogame's contentManager class and pipeline tool, both work to package all the game data into fast to run/load binaries, and access to resources takes ugly code, where as renpy compiles at runtimes and allows for the simpler use of clean keywords such as MC for the basic main character image or dialog box. I'm shifting to Godot but haven't exported anything so I don't know how it'll handle things.
If anything the crux of my concern or the weakness in my workflow is a resource manager or pipeline tool that works with my other tools (mainly the game engine or game engine editor)
Issue 2. Hierarchical organizations, aka folder inside of folders, I find tends be a terrible way to organize vast and complex data sets, and a weakness of all current systems. For example, background art vs character art vs 3D models, are all separate, so perhaps each is their own folder. Then inside of the characters folder, maybe a folder for each character, and then maybe inside of there there are more categories, by it art type by mode or time of day but which should be the parent folder and the child file, which is of more importance? and inside of those folders are more folder or files that further break down the classification of art assets. But then you have to recreate such structures for each equivalent folder in similar character folder for other characters.
There is an issue in programming, or the object-oriented philosophy of programming, where to save code you can have object inherit properties of a 'parent' object, but add more details. The simple example of making a cat object and a dog object, both can have a sound effect and an art piece. Both game objects could inheret from an "animal" object that tells the code that it can make a sound effect and have art, but the children objects (ie cat or dog objects) will specify what sound file to use. The issue with more complex code, or in file management with lots of art assets, is that there then becomes a philosophical issue, as we try to break down the problem further and further down in an attempt to be organized, but becomes so philosophical and detail-oriented that start to have a crisis, "what really is a chair, what is a chair at its core" and other silly dumb things.
The simple solution that I have concluded is instead of hierarchy, simple a use of labels would be enough. Labels to filter out the content to get what you need. Labels could even be hierarchical, ie an "art-happy" tag not only specifies that the asset to display is of the category label happy, but the label name 'art-happy' also implies that this is specifically used for art type assets (as opposed to happy music assets). But the "art-happy" tag could also be a child tag of "character" where it is specified that in order for an art piece to fall into the "art-happy" category, it must first be art of a character, preserving the hierarchical order.
What I mean to suggest here with this wall of text is, it would be nice to have essentially a file browser, with more features. Since operating systems by default operate using hierarchical files structures, files would still need to be organized either in a hierarchy (ie the character folder, with sub-characters folders, and emotions folders per character folder), but there could be other files to accompany these folders, that lets this special file browser know how to handle this data (ie the ability to use tags, to quickly sort out the content you want to inspect).
I have tried working on something similar myself, but since most of my work is for experimentation and fun, I don't do anything right or complete, I just do quick shortcuts to see if the results are what I want. IE doing a quick render in Blender, posing the body without actually saving keyframes or the pose, just to see what the render looks like, not taking the time to actually set up a proper scene or anything. But with what I have derped around with, using C# (or Net.Core since it is one of the few languages to have all the features I need without needing to use anyone else's code and naturally has cross-platform compatibility) is to make a custom zip file, that lets the custom made file browser know it is a compatible file (ie like a .rar or .7zip file type). Inside could be other files, json's for example or other text documents that provide the file browsers the information it needs to know. these files can then be hidden from view. The browser would need to be able to add and remove files, the ability to add and customize tags or labels, make sub label or child labels for hierarchical organization, and of course a filter option.
While a filtering option would be nice, it is the first key step to making not just a file browser, but a pipeline tool that could plug into a game engine. Depending on how flexible you want the system to be (not something I experimented with too much to know any major tripping points) labels and tag types would be the perfect way identify key particular patterns in how the game may handle data. For example music or characters could have particular moods or states. ie a character could be talking or listening, but both could be in a sad or happy mood, or the character is not made up from images, but parts of images ie a mouth layer asset, keeping track of certain parameters would be needed in many games assuming most are not just hard coding in behavior (ie renpy scripting). While it certainly wouldn't be practical for the pipeline tool to know what code to have for different assets or to allow users to attach code to tags in the file browser, it would be more up to the game engine and programming to determine how to assets are handled during gameplay, there is a middle ground that the file browser /pipeline tool hybrid monstrosity could fill. And that is packaging.
More and more I am getting sick of the file management with most game engines, be it renpy, unity, monogamy, etc. It can sometimes be a black box, and you just use it because it works, but then you limit yourself to the workflow of that engine or game. if you want to make changes, you have to directly alter the game files, and often re run your pipeline tool to overwrite the binaries. With some basic tests, I could keep a living version of the data as a folder, or a zip, that you can edit at will, on the fly, I could have code that 1. converts into binaries for fast loading once the game is published/running, and 2. create a .dll that contains not only information about the organization of the binaries, but code specific for accessing such data. This .dll could be loaded at run time, assuming that 3. there was another bit of code or compile-time .dll that provided the functions needed for the game engine to properly handle the run time .dll. The idea being that the run time .dll could be a general purpose .dll, maybe even include code that you want your game to run, ie a layer management system, while the compile time code or library is like a plug in made for any engine you want to support, you just have to make a new plug in for each engine you want to support, or for a custom engine such as what I prefer to work with, I could make my own plug in to sync up with how my system work and calls draws.
The main advantage to this as a pipeline tool is that, assets and things I want to modify are outside the game as a separate file, that I can modify as i wish, each time the system starts up (starting the game or recompiling) the pipeline tool recompiles the binaries automatically so I never forget (so many dumb bug hunting quests that turn out to me not re-running the pipeline tool). that means a simple update or mod for a game would be to swap out this separate and special made file since it is not wrapped up inside the game's .exe, and maybe most important to me, rather than hard coding everything into my game for managing assets (ie specifying the file tree names) i could soft code it with the easier to read (in code) labels or tags. Basically an abstraction layer would already be in place, specified by the compile time .dll/plugin for a targeted the game engine.
Thats a dump, so I'll add a tldr. most of the time the work flow is, make art, put art in folder, organize stuff constantly, change how I organize things as the project becomes more complex. insert art into game 'somehow', and lot and lots of coding and scraping art, but this is as a solo dev who just messes around, not doing work or scheduling or meeting deadlines which could be major part of one's workflow and perhaps more of what you were thinking about, but not my workflow. Sleeping and time are but an illusion.
