Decoupling/Framework agnostic approach

[Dinozor]

Is your feature request related to a problem? Please describe. Active code requires user to code his way for each and every required feature. Hard to adopt and reuse coded features later. Every new feature requires reload.

Describe the solution you'd like More decoupled agnostic approach allowing to have reusable "drag&dropable" element. Best scenario to have API/Framework loosely coupled with unity and twitch. Main core will be basic models and set of prebuild commands, validators and builders.

Describe alternatives you've considered To rewrite active for more dynamic approach or start new independent repository/org.

Additional context Below is approximate design. Not the greatest, but should help to illustrate the idea and easier navigate it.

Model act like database. With exposed interface they can be mapped to any storage. Regardless of platform (Twitch, Youtube, Discord etc.) users have common variables and can be stored , linked and monitored cross platform. Act as somewhat aggregator. Provide set of adapters. Current one is for unity using TwitchAPI.Unity. Basically adapter/proxy class.

Adapter or adapters are injected to Managers (bad naming :( ) Managers provide active basic functionality of monitoring chat and platform events. Should be controlled by something Kernel like. Kernel will also sync and populate models using adapters.

Each manager accepts list of specific Interfaces. In unity should be ScriptableObjects. Every Object should have list of strategies knowing how to react on managers call when specific requirements are matched.

Example: class CommandController (Manager). Has list of Commands that have Execute(data) method.

[CreateAssetMenu(fileName = "New Chat Command", menuName = "Twitchmata/Chat Command")]
public class ChatCommand : ScriptableObject
{
    [SerializeField]
    private string _command;
    [SerializeField]
    private string _description;

    [SerializeField]
    private Permissions _permissions; 
    [SerializeField]
    private CommandStrategy[] _strategies; 

    public string Command => _command;
    public string Description => _description;

    // can be moved out and replaced by list of Validators 
    // following same principal as CommandStrategy
    public Permissions Permissions => _permissions;
}
public abstract class CommandStrategy : ScriptableObject
{
    public abstract void Execute(User user, Message message, Callable finished);
}
[CreateAssetMenu(fileName = "CommandStrategy", menuName = "Mata/Command")]
public class SendResponceStrategy : CommandStrategy
{
    [SerializedField]
    private string _template;
    public override void Execute(User user, Message message, Callable finished)
    {
            Mata.SendMessage(_template);
    }
}

This code allows to precreate all basic commands to be created and configured by clicking UI and drag&drop. Same strategies later can easily be reused or be more specific like "Call my character ability".

Below are screenshots of same for Channel Point rewards.

Having code this way would also allow later to constantly increate amount of possible options and even exchange them between users (even runtime, between streamer interaction). Or have a portal, git with just a list of them as snippets. In addition more users would be able to contribute to projects. Even regardless of the platform as having those components would allow easy adaptation via adapters. And as extra benefit can allow cross platform user interaction (games, channel points etc.).

Hope this provides some perspective of what and how I see "endgame" of this tool.

[pilky]

So I see this as two separate issues:

1. Making it easier to use Twitchmata (configuring more in the UI, more flexibility on where you place code, re-usable common components)
2. Making Twitchmata more abstracted from Unity and Twitch to support other game engines/platforms

1 is definitely the end goal for Twitchmata, and the sort of stuff you're showing with the Throw Bomb reward is definitely where I'd like to get to. This may not be something for 1.0, but would definitely be a focus for 1.1

2 is outside of the scope for Twitchmata. Twitchmata's primary goal is to be a wrapper around the Twitch API to make building a VIPO in Unity easier. There are large differences between game engines and streaming platforms, which would add large amounts of complexity to the codebase (making it harder to develop) and complexity for users (making it harder to use).

One of the most important goals of Twitchmata is to make things approachable for people new to programming. This means that some things may not be done in the "optimal" way an experience programmer may do, but are designed to be simpler to adopt for someone just getting started with coding. It does mean that some of the architecture may be simpler than it could be

[Dinozor]

It can be split to even more issues. :) First issue is not that hard. I have it somewhat already. I can make a PR if you wish. You could merge/copy/refactor parts that you need. Just tell from which commit to make it. Also I'm still not convinced that active approach is easy. Especially extending and enabling every command manually. Just looking on Doigs class of list bring me pain :) It does not mean that it should not be an option. Right now I have both.

For second I see a problem with accessing parts of possibly useful data and building extra layers/integrations now conflicts. Idea here, maybe, to chip away some parts of twitchmata and make dependency on it (or interfaces) or to have it abstract enough to be extendable by other software as current one limits it use. I mean if it's going to be used as package. If whole idea it to be more like boilerplate/bootstrap part around twitch api and be rewritten as needed, than other part can be changed and be simpler (more unity like style with less nesting).

My active concern is mostly that Twitchmata in current state is more like example of what's possible. So like after if you really wish to have something extra for your Animata - you need to completely scrap it and have your own (or most of it). And it's going to be harder the longer you build on top of it. Of course, not everyone would need it, but why to limit? So just to summarize my current goal about 2.nd issue. start a discussion what parts and how can be more generic and adaptable. So later you could replace them or extend or even migrate.

Also just had a thought that maybe my confusion about Twitchmata is that it makes multiple things at once and I don't know where it belongs more. Like should it be just an adapter of TwitchAPI.Unity that has some extra insides, Or vice versa - Unity's packet that has API for creating reactions to some chats and happens to have integration with twitch.

Example things that can be added along twitchmata (not part of twitchmata, but still somewhat dependent):

• discord integration (posting images, messages). Reaction to messages in specific channel
• loading/showing twitch chat, bttv, 7tv etc. emojies
• have databases: users, their messages, bits, gifts etc. To have analytics of users, chat behavior.
• automated chat reactions (we kinda spoke about them already). Just parcing messages and executing them as commands.
• command/message chaining: to allow multiple commands in one message and preventing spamming them.
• external chat commands: ability to send chat commands and controls NOT using twitch. like from discord or standalone custom website, server etc. Like mods could move on scene without flooding chat having their own control tools.

And more important ones:

• Testing: can have tests and extra stuff along with it. Won't need to start and connect to twitch to test as Twitchmata always work and I would need to test my own command without the need to write/click twitch.
• Side help: more people using same tools - more people can help you with problem you experience with it.

This are main thing I already though about implementing along with twitchmata :) so let's discuss?

[pilky]

It can be split to even more issues. :) First issue is not that hard. I have it somewhat already. I can make a PR if you wish. You could merge/copy/refactor parts that you need. Just tell from which commit to make it. Also I'm still not convinced that active approach is easy. Especially extending and enabling every command manually. Just looking on Doigs class of list bring me pain :) It does not mean that it should not be an option. Right now I have both.

I'd be happy to take a look at a PR if you have one

For second I see a problem with accessing parts of possibly useful data and building extra layers/integrations now conflicts. Idea here, maybe, to chip away some parts of twitchmata and make dependency on it (or interfaces) or to have it abstract enough to be extendable by other software as current one limits it use. I mean if it's going to be used as package. If whole idea it to be more like boilerplate/bootstrap part around twitch api and be rewritten as needed, than other part can be changed and be simpler (more unity like style with less nesting).

My active concern is mostly that Twitchmata in current state is more like example of what's possible. So like after if you really wish to have something extra for your Animata - you need to completely scrap it and have your own (or most of it). And it's going to be harder the longer you build on top of it. Of course, not everyone would need it, but why to limit? So just to summarize my current goal about 2.nd issue. start a discussion what parts and how can be more generic and adaptable. So later you could replace them or extend or even migrate.

What limitations are you finding with it? I've not found anything in the architecture that would preclude anything one would want to do with Twitch in a VIPO. There are missing features, but that's more requiring you to drop down to TwitchLib directly than a limitation

Also just had a thought that maybe my confusion about Twitchmata is that it makes multiple things at once and I don't know where it belongs more. Like should it be just an adapter of TwitchAPI.Unity that has some extra insides, Or vice versa - Unity's packet that has API for creating reactions to some chats and happens to have integration with twitch.

Example things that can be added along twitchmata (not part of twitchmata, but still somewhat dependent):

• discord integration (posting images, messages). Reaction to messages in specific channel

That would be a separate library to Twitchmata. However, I can foresee a third library being a collection of small, common actions to happen in response to something and having Twitchmata, a Discord library, etc all supporting this third library as an option.

However, I think we're a way off from such a component library being built and adopted as we'd want to see a lot more mature VIPOs out there to extract common components from. It's always far better to ship a product (or ideally multiple products) before abstracting stuff out into a library, as the library then better reflects how it's actually used rather than how people think it would be used

• loading/showing twitch chat, bttv, 7tv etc. emojies

Emotes would definitely be supported. Things like BTTV may be outside of the scope, at least early on.

• have databases: users, their messages, bits, gifts etc. To have analytics of users, chat behavior.

That is already planned for Twitchmata. The properties are there, I'm just not populating them. At this point they may be a 1.1 feature as I'd want to add persistence (probably to JSON)

• automated chat reactions (we kinda spoke about them already). Just parcing messages and executing them as commands.

That is also planned for Twitchmata, possibly for 1.0

• command/message chaining: to allow multiple commands in one message and preventing spamming them.

I'd be hesitant to make this built in to Twitchmata as it opens up far too many cans of worms but it's something that one could try to build on top of Twitchmata

• external chat commands: ability to send chat commands and controls NOT using twitch. like from discord or standalone custom website, server etc. Like mods could move on scene without flooding chat having their own control tools.

Again, that would be outside of Twitchmata's scope

And more important ones:

• Testing: can have tests and extra stuff along with it. Won't need to start and connect to twitch to test as Twitchmata always work and I would need to test my own command without the need to write/click twitch.

Twitchmata 1.0b3 added a bunch of additional debugging tools to make it easy to test things you can't easily test in the TwitchUI. Eventually a full debug UI in Unity would be a goal

• Side help: more people using same tools - more people can help you with problem you experience with it.

This is part of why I'm taking things relatively slowly. We need a LOT more people with released VIPOs that have matured enough to know what wants to be built. Twitchmata 1.0 is basically just "extract what I have and mix with a few things others need". I want to get a good base out there and then get more feedback before taking it to the next level. it does mean early adopters will need to build more stuff, but it also means it the future can be focused on what people actually need.

[Dinozor]

Most parts that I described MUST be outside of twitchmata. And not even know about it :) They are just an thought experiment of how you would implement this feature alongside twitchmata. Or how would you implement twitchmata to active one. About stuff that are limited: I could not find "good" way of extracting and having user list without changing twitchmata. But making it separately kinda duplicated same functionality.

For persistence I though about Sqlite. Still can use adapter.

Anyway I will try to refactor some parts along with SOs and attachable commands. Hope we will be able to get some modularity.

[pilky]

About stuff that are limited: I could not find "good" way of extracting and having user list without changing twitchmata. But making it separately kinda duplicated same functionality.

The ChatParticipantManager should contain a list of everyone currently chatting, plus mods and VIPs.

For persistence I though about Sqlite. Still can use adapter.

SQLite is a bit overkill and adds some additional complexity. For the scale streams will work at JSON is more platform agnostic and has no dependencies

[Dinozor]

I think it was not linked list in ChatParticipant. Like I could not map it properly as I wanted to. I will re-check it later than.

SQLite is a bit overkill and adds some additional complexity. For the scale streams will work at JSON is more platform agnostic and has no dependencies

Why you trying to limit it's flexibility? Like it should not care if it is JSON, SQlite, redis. It just should be just some IRepository with find(string chatterId), update(Chatter chatter) etc.

And then we just add adapters: JsonAdapter : IRepository .. or something like that. It just additional interface. Basically done by few shorcuts. Takes no extra development time, almost 0 performance impact (or can be faster in some cases), and you get infinite flexability. More importantly, I can reuse your database in my Overlay, or have my already existing database synced or connected. And if later you decide to update your code, like storage format - I still can easily migrate to new version without breaking anything. Also you WILL need to provide extra standalone tools for working with JSON. As it's useless to have this format without ability to build reports over them.

[pilky]

I mean, chatters isn't really something that would be planned to be persisted by Twitchmata, at least not in the near future. The current plan for what will be kept track of (and eventually persisted in case an overlay needs restarting or crashes) are:

• Who subscribed this stream (possibly also who gifted subs)
• Who followed this stream
• Who raided this stream
• Who redeemed each channel reward
• Who redeemed bits

We can certainly add an interface for those who might want to use something other than JSON for storing info, but the intent would be that out of the box it would just store JSON in the persistence path so people don't need to even need to care about persistence 🙂