[Prizes inside!] Visual Entitas - two week jam in January 2th - January 16th

[KumoKairo]

There was a lot of talk about Visual Entitas. The first official mention was back in 2016th #160
And this topic pops up in chat from time to time.
This is why I decided to host a public jam in January (who works in January anyway?) as I'm sure you guys (as well as myself) are busy on fulltime job and personal projects.

-- UPDATE --
We now have prizes for the most active contributors!
Three most active contributors will get a free t-shirt with an Entitas logo (shipping costs are also covered. Will be shipped anywhere the postal companies go - Europe, America, Australia). T-shirts are of a great quality 100% cotton

We also have a free Entitas-Pro voucher for the active contributor that doesn't have it yet ($45 of value)
https://www.assetstore.unity3d.com/en/#!/content/87638

--- Back to business ---

The main point of the Jam is to create something that will ease the debugging process and overall architecture comprehension. This involves watching which components get used or changed by which systems in which order. This is what currently pretty hard using the code-only approach. Visual editor doesn't have to include actual coding itself. it may generate components and system wrappers which are then implemented in code like you would normally do (that's what uFrame did very effectively).

This is the perfect opportunity if you always wanted to try some advanced Unity Editor scripting but couldn't find the time. No prior node-based editor scripting is required.

(uFrame ECS screenshot)

More general agenda for the jam is as follows:

• Unity-based visual scripting like Playmaker, uScript, ShaderForge, uFrame etc.
• Visual-driven component creation / deletion, system generation and system ordering
• Visual debugging with stepwise execution (just like visual debugging works now) with visible data flow / state changing
• Doesn't have to look good, or represent any final quality of the package. Main point is functionality.

To make things simpler, it's easier to get some node-based editor framework and build on top of that. uFrame MVVM and uFrame ECS are open source and can be used as a reference
https://github.com/uFrame/uFrame.Complete
https://github.com/Siccity/xNode

https://assetstore.unity.com/packages/tools/visual-scripting/uframe-ecs-pro-47548
https://github.com/micahosborne/uFrame
https://github.com/Seneral/Node_Editor_Framework
https://bitbucket.org/antiherostudios/nodify/src/7f25c3817241?at=master
https://github.com/Scramasax/Artimech/tree/master/Assets

and I bet one can find even more open solutions.

If you want to participate - just drop a line in this issue.

What and how you create during this jam is up to you - personal repositories are great as well as contributing to someone else's repo. It has to be open-sourced, so community can actually benefit from it. But what you do with it after the jam is up to you - it can be sold or whatever. What you create will remain yours.

Prizes for the "most active contributors" will be distributed based on subjective feedback from active people in the current Entitas community. All people here are usually nice, so expect objective distribution ;)

Cheers and stay tuned.

[ghost]

I’m also interested in participating.

[mgmhunt]

Note that https://github.com/uFrame is the best code base to work from now.

[KumoKairo]

Yes, I will definitely start from uFrame ECS. It's linked in the original description. There's also a more fresh version of it that works in 2017, let me just go fetch a link

[mgmhunt]

The links in description are from micah's code (the creator) but haven't been looked at in ages. The link I've referred to is the organisation that has a couple of key people who seems to understand it and are keeping it going.

[KumoKairo]

I have just checked the uFrame chat again, your link is the latest "not utterly broken" uFrame version. Thanks for pointing that out, I have updated the link in the description

[ealeksandrov]

I don't have too much of Unity expertise but this sounds like a good time to get some.
Count me in!

[Siccity]

Sign me up as well :)

[Pelmog]

I'm in.

…

On 20 December 2017 at 11:36, Thor Brigsted ***@***.***> wrote: Sign me up as well :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnI2jbqVIxA-4jgWtN2WwKVY8X3CqSCks5tCPEhgaJpZM4QPmXX> .

[KumoKairo]

Now we have a xNode author here, this is where things get serious :)

[KumoKairo]

I have created a chat room on gitter (as gitter is what people use by default with Entitas)
https://gitter.im/Entitas-Visual-Jam/Lobby

As a keynote -
for the new people with Entitas:

• be sure to check the FAQ and Getting Started section at the main repo: https://github.com/sschmid/Entitas-CSharp
• to get the general idea about visual ECS editor be sure to check out the uFrame ECS videos:
  https://github.com/InvertGames/uFrame.Documentation/blob/master/uFrameECS/Overview.md

The main purpose of this jam is to see what people can come up with regarding the Entitas visual programming / architecture creation / visual code generator. And also to increase one's editor scripting skills.

Good luck and see you in the chat.
Cheers!

[Psythyst]

(@T2RKUS Account) Example repo (Contains tutorial):
https://github.com/Psythyst/Entitas-Match-One

Psythyst Unity Edition (Unitypackage):
https://github.com/Psythyst/Entitas-Match-One/raw/develop/Assets/PsythystUnity-Entitas.unitypackage

[Psythyst]

Will update the other repos soon as well as begin to fully document Psythyst (even if no one but me uses it).

[KumoKairo]

This is my kinda-postmortem on a Jam. And we will wrap up during the next couple of days.

Initial ideas

So first, to be honest - for me this jam was an excuse to get my hands on uFrame and editor scripting.
I really like the idea of visually representing active data that we are working on. uFrame itself was a pretty popular package back in the day, feedback of software developers on it is quite positive, so I decided to give it a go.

My goal was to create a visual system that allows creating components, contexts, groups and systems.
First, we create components and groups.
Then we hook up groups to systems and generate some boilerplate systems code that only allows using entities from supplied groups.
We should also be able to specify output component types that a system should create so we know not only Input components, but Output too.

This will allow to easily query for systems that handle certain component types so we know which components can be changed by which systems. It makes the overall comprehension and debugging process easier as we can always check for all of the systems that have something to do with certain component types.

Jumpstart

So I've started with uFrame and it was a "straight to business" experience - I had Entitas Data Providers hooked up to uFrame graph data in no time (as uFrame ECS already has Component nodes).

I didn't want to write lots of code generator logic from scratch and have decided to use most of what Entitas already provides. Unfortunately, its current default Data Provider layout doesn't allow to inject some custom code into the data providing pipeline (https://github.com/sschmid/Entitas-CSharp/blob/develop/Addons/Entitas.CodeGeneration.Plugins/Entitas.CodeGeneration.Plugins/DataProviders/Components/ComponentDataProvider.cs#L38).

Milestone 01 - Sourced Entitas

Default Data Providers pipeline is hardcoded and we can't change that using a .dll version of Entitas easily, so first I had to tailor Entitas for the source release. Turned out that Entitas doesn't really depend much on .dllness on its own, it just needs to know which assemblies to check for types. I started with Unity 5.2 (it's the latest version that is supported by uFrame out of the box) and it didn't have a notion of Assembly Definitions back then (turned out to be around two years ago - sic!). So I have returned to retrieving assemblies by type instead of loading dlls.
Entitas also needs an assembly version so it knows whether or not it should advise you to upgrade.
Assembly Definitions get us back to the need of searching for assemblies. But I think the whole process of manual addition of the assemblies thought the text preferences is cumbersome, and it can be easily replaced with automatic assembly search in the output Unity's Library folder.

Back to uFrame

Data Providers hook up to uFrame graph data and generate all the needed code correctly. What I didn't yet have is a Context node and context attributes generation. It required a custom uFrame node and I dived in the Plugins system (after all - adding a custom node type should be easy, right?). Turned out to be not a simple task. Although uFrame has a notion of Plugins (it even has some code does a search and even calls some initialize functions), it was required to write actual code in the core of uFrame to add another item to a right click custom menu.
After I was able to make a custom node and make it appear in the graph, I've faced another issue - it didn't allow me to rename my custom node. The text was in editable form, but it didn't receive any input. Turned out the focus is hard-reset every OnGUI event to some nonexistent text field. So I spend around 5 days digging around uFrame, fixing this thing and trying to understand the whole underlying uFrame structure.

Milestone 02 - Lazy developer

Now as I have started feeling that custom node types don't really work out as expected, I started thinking about reducing the workload. I have thought of the notion of contexts themselves, as they are kind of a workaround the fact that we need to store preallocated array of components for each entity. So we can reduce amount of wasted RAM, by splitting component types into groups. So entity can have 50 preallocated array elements instead of 300.
The idea is OK, but it leads to another workaround - Multi Reactive Systems, which need to handle entities from different contexts at the same time. It also puts a pressure on a developer by making think about which components really do belong together, and it kinda breaks the ECS thinking as these "contexted" components start to look like fields of a class (I've seen a lot of examples where people treat contexts like that, in OOP way)
Then it has struck me - all this time we are trying to fix the code generation issues while the main problem lies deeper - component storage model. This has led me to a lot of conversation in the Entitas chat and a lot of component access tests. We were also lucky to have @Leopotam in that chat, as he provided a few different alternative ways of accessing components that can even be faster than what Entitas has right now, but with less RAM consumption. This whole Make Entitas Generic Again topic took me another 4 days or so.

Back to uFrame (again)

So in the end I've managed to kinda fix the node renaming issue, but it has really shown that uFrame has a lot of "tech-debt" as one of the community members noted, so it was not really feasible to rewriting some stuff in uFrame itself.
I've had 4 days left of the jam (took me too much time digging in uFrame and chatting about component storage model) so I finally decided to acually JAM!, writing my custom node editor from scratch

Milestone 03 - Actual JAM!

Besides uFrame, I've also wanted to try PureMVC for Unity and Editor Scripting looked like a good place to apply it. I have checked a few articles and a "handbook" again and started working. There's a .NET Standard version of PureMVC https://github.com/PureMVC/puremvc-csharp-standard-framework, but it doesn't work in Unity (it's multithreaded and uses some modern language features),
so I had to port it to Unity it first. https://github.com/KumoKairo/puremvc-csharp-multicore-framework this is a fork that has a "converted" version that works in Unity.
I have also decided to quickly "Generitize" Entitas so I won't need complex code generators that Entitas currently has. I have changed component storage to naive Dictionary lookup and removed the notion of different Contexts as they were not needed anymore. This process of refactoring got me understanding the "backend" of Entitas much better.
But in the end I didn't even had a chance to actually try it, so I guess it was work just for the sake of learning.
So last 3 days I have spend JAMMING with Node editor scripting with PureMVC and it turned out to be an exciting experience. I knew that I had to move on to next tasks without refactoring the previous ones, but couldn't help returning back and polishing all the stuff (both visual and technical).

Results.

As a result of excessive polishing, by the end of the Jam I only had working solution for:

1. Component addition / removal
2. Component renaming (intuitive double clicking instead of RMB - Rename)
3. Fields - addition / removal / renaming / changing types
4. Interactive fields are really interactive - when moving a mouse everything reacts - text dims, buttons show that they can be clicked etc., feels really nice to me
5. Trivial component generation.

Other than actual node editor:

1. I'm really determined to continue digging into component storage implementation in Entitas so we can really say goodbye to Contexts, MultiReactiveSystems and other workarounds of a current component storage strategy.
2. Got my hands on uFrame (finally) and won't get back to that
3. Finally tried PureMVC and it turned out to be good
4. Got back to Editor Scripting (haven't touched that for 3-4 years because the first custom Node-based editor scripting experience was very daunting) and it turned out to be cool and exciting.

https://github.com/KumoKairo/Entitas-Visual-Jam
this thing is opensource, it has PureMVC, Naively generitized sourced Entitas version and actual Node-based editor. I'm not sure what I will do with it now, but in general I'm still motivated to continue working on my initial idea of visual static analysis thingy that I have in my mind.

[KumoKairo]

Thanks everyone for being interested and special thanks to @T2RKUS for actually participating and making something cool and usable.

Stay tuned for later updates!

[masterkenny23]

Hi Kumo, apologies for resurrecting this thread.
In your research into a visual node system on top of , did you ever look at Bolt?
In particular, Bolt 2 looks very interesting with its realtime C# generation. Perhaps there's something here to compile down to the ECS in Entitas?
I have not dug into Bolt in detail, but on the surface level, "flow machine" macros in Bolt can act in a visual way of building "systems" in Entitas' ECS.