itch.io

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.

Hmm, well that raises yet more concerns - it really seems like if that's how the editor registers behaviors then it would be impossible to package common behaviors into a plugin at ALL, let alone safely in a namespace.

Oh I forgot the most important part: the behaviors still WORK, as long as I don't touch the ones it thinks are "missing" they'll continue to function if you build and run the game, they just don't appear in the behavior list. I'm looking through the scene editor and behavior component code seeing if I can figure this out but I don't see anything yet...

As part of the work towards turning my game code into a reusable plug-in, I went through and stuck all of the relevant code into a namespace, but now even though I still register them to Superpowers none of the behaviors from the namespaced code appear in editors, even if I move the registration out of the namespace. For example:

class SimplePhraseBehavior extends Sup.Behavior {
...
}
Sup.registerBehavior(SimplePhraseBehavior);

Works just fine but:

namespace TomE {
export class SimplePhraseBehavior extends Sup.Behavior {
...
}
Sup.registerBehavior(SimplePhraseBehavior); //with either this....
}
Sup.registerBehavior(TomE.SimplePhraseBehavior); // OR this

Compiles but causes the behavior to be unavailable/marked "missing" in the editor

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

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.

Hmm well the 2D exploration is out of scope of my Tome project right now but although TECHNICALLY it's a point-and-click engine one of its main features is a scripting language for visual novel style dialogs. As I mentioned in another thread it is currently between very difficult and impossible to distribute a project like this and provide updates so I'm hesitant to hand it out in such an early state but if you have a good idea what you're going to need out of it maybe we can hammer out the features you need from it and I can provide a starting point :0

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

Hey, I'm An, I was a UI programmer for Star Citizen for two years (known there as "CIGHuntokar" or Brandon Evans", but I prefer An w/ friends now :v) before I quit the games industry and went to Dreamworks Animation, where I write lighting tools now. My usual M.O. these days seems to be really intensely into some open source project and contribute helpful tools until I run out of ideas and burn out then move on, but with Superpowers I'm helping my best friends create a game they've wanted to make forever so hopefully I'll be around longer.

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