My friends and I are working on a point and click game (called "TOM"), and since I'm the only programmer and also a born-and-bred tools programmer, I'm doing my best to build a flexible engine with user-friendly debugging menus and its own easy-to-use scripting language that allows artists and writers to script "cutscenes" with branching dialog, inventory and game state manipulation, etc. which I'm calling "TomE" (short for TomEngine - not esp clever but good enough).

Now here's the problem: while Superpowers' UID system for files certainly simplifies renaming things and moving them around in the interface, it makes it essentially impossible (afaik) to work on TomE independently of TOM because it will pick up conflicting IDs if I add anything to it.

So what I propose is this: Superpowers could support a marginally more complex UID system that allows for additional entries.json files in subdirectories by prefixing the id with a project name or number, which would allow developing reusable packages that can be included and modified by users who don't necessarily have the access or know-how to rewrite a system/plugin if it doesn't suit their needs adequately. As it stands I'm considering simply adding a very large number to every file id in TomE and including a python script to patch the entries file of the parent

I feel like what you really need is the ability to export and import a bunch of scripts at once easily from one project to another, right? If that's the case, this will be covered by implementing https://github.com/superpowers/superpowers/issues/78

There is one thing that doesn't cover though - allowing SEPARATE entries files would allow for ongoing development of a block of assets (like my very WIP framework) if you say included it into your game's git repo as a submodule. If you don't ever want to update the engine I could just distribute the code and sample game stuff and you could just build off of it without even drag and drop. The bigger problem honestly is that maintaining the engine separately from the game I'm using it in already isn't even possible because I can't have an additional git repo included that would work if imported by someone else - even though I have the engine and game code in separate subdirectories right now I can't change either outside of the client for that project

OK so the fact that one can't include manage a subtree as its own git repository is indeed not very convenient. But I'm not very enticed by the idea of complexifying project structure with nested entries.json. What do others think?

We haven't really given much thought to reusable engines built *within Superpowers*. I mean, there are project templates (which you can put in systems/game/public/templates) which are one approach, but it's not quite the same. Maybe your engine would be best built as a plugin for Superpowers Game? It could expose its API like the sound play exposes its API for instance: https://github.com/superpowers/superpowers-game/tr...? I feel like that's a good match.

It would be a very simple plugin that only have a typescriptAPI bundle and no editors or data folder.

Yeah I think that might be the right idea... I'm gonna have to be a lot more thorough making sure you never need to touch the engine code then, and probably still need a project template for all the required data you DO need to be able to edit, but I guess that's fine.

Actually there may be a minor but work-around-able issue with the plugin concept - an important part of Tome, at least in my mind, is that it provides a bunch of helpful in-game debug menus for pretty much any data you might be using, which means providing Scene assets. Now I COULD just put those in the project template it's already probably going to require, or as a standalone folder to be added as per Issue #78, but is there a way to provide those assets directly within the plugin? And just for perfect clarity: that's actual created assets, not an asset TYPE, which I know you can add via plugin

Well now it turns out even behaviors can't really be placed into a plugin, so a plugin wouldn't even contain just the scripts it could only contain a SUBSET of them. Honestly I think I could more easily sort out the asset management dealing with subprojects than all the issues keeping this from being distributed as a plugin, and that method would make it easier for less advanced end users to make changes to their local versions of it as well.