Ash framework inside of Unity3d

[Vladimir Beletsky]

Hey guys,

I am developing a game on Unity3d and for some time I was using this engine's native architechture with some minor improvements. But after a bit of code and retrospection of Ash usage in the past I am starting to consider wether it will be beneficial to implement the Ash inside of Unity. 

I already see problem with FixedUpdate being a separate update cycle in Unity and don't know yet how to work around this problem besides implementing some kind of nodeFixedUpdate.

I am interested if anyone has made this kind of work before (Ash in Unity) and what kind of difficulties one could have encountered.

[Michael Cann]

Haha, this topic gets brought up every 3 months or so. I brought it up not so long ago.

I too had a thought about it recently and even started to bash out some code. 

The core difficulty I found was that Unity's Entities have no events that tell you when a component is added or removed so there is no way to build node lists. 

You could perhaps create a base component class that listens for OnEnable or some other hook to know when the component is added, then tell some central repository that it was added but it seems pretty hacky. Also it wouldn't work with the many other custom components that are out there that dont extent your base component such as RigidBody, SpriteRenderer, MeshFilter etc etc etc

So I think Unity in Ash is a no-go unless you want to totally ignore Unity's entity / component architecture altogether.

Mike

--
You received this message because you are subscribed to the Google Groups "Ash Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ash-framewor...@googlegroups.com.
Visit this group at http://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

--
Mike Cann
http://www.mikecann.co.uk/

@mikeysee

[Vladimir Beletsky]

You are quite right, I am currently using OnEnable in a base class to translate the component addition into Ash engine. As for the base components I now use builder systems which are expecting to find a unity's component and then these builders add a special provider component. The code is an informed one, you may say. For example if there is a RendererProviderComponent on a unity's gameobject, the nodeAdded will extract the renderer from the GO and add to the correspondent field. And of course no dynamic addition/removal of this base components is supported. Not perfect, but one may live with this.

Fixed update on the other hand is a pain. Separate nodeUpdate action or even a separate engine for physics maybe?..

[Michael Cann]

An alternative is to have Ash scan the hierarchy each update to see if any GameObject's  have been added or removed. 

If a GameObject has been added then you add an "AshEntity" component. The AshEntity's job is to keep track of what components are on the GameObject. Each frame it checks to see if any components have been added or removed, if that is the case then it lets Ash know which then updates the node lists. 

That could actually work... 

As for your fixed update. That could just be another type of System? FixedUpdateSystem?

Mike

[Vladimir Beletsky]

Great idea, scanner might work. Maybe the overhead is not worth it though, I think I'll go with builders for now, and will start using scanners if necessary.

As for the FixedUpdateSystem, that would be cool if one could call Update on PhysX in Unity manually, so I'd say something like "while physics time is less than real time do fixed update", but that's impossible in Unity.

[Richard]

I thought about this briefly, admittedly not for very long.

I was thinking of implementing systems as MonoBehavours, and having a game object that contains all the systems. Then you don't have to worry about the update loop - systems can implement Update or FixedUpdate as they wish and Unity will call them accordingly. They can use Start, OnEnabled, etc.

I would then implement Ash components as ScriptableObjects and create a Unity component (i.e. a MonoBehaviour), lets call it AshEntity, that contains an array of ScriptableObjects, which is the Ash components for that game object.

That was my initial thoughts, but I abandoned them pretty quickly. For me, implementing Ash in Unity is an interesting thought experiment but is of little practical value.

Richard

[Michael Cann]

Well it turns out this is actually easier to do than I at first thought..

Using David Arno's .Net port of Ash (https://github.com/DavidArno/Ash.NET) you are most of the way there. 

It only takes two more "Ash" classes to do the work, an AshEntity which keeps track of components being added and removed and AshGame which serves as the root of the tree.

Then all you do is add an "AshEntity" to each game object in your world, make sure they are children of your "AshGame" and thats it.

The performance wont be the best but this is just a proof of concept ATM.

Its getting late here in Australia so im off to bed soon but I plan on porting the whole of Richards Asteroids over tomorrow. For now you can clone: https://github.com/mikecann/UnityAshteroids

Let me know what you think!

[Vladimir Beletsky]

Well, I am on the same route as you are, but I don't think that the complete iteration over the components each frame is necessary. I use OnEnable and OnDisable like this, and this covers my needs regarding bounds of unity-ash:

 private void OnEnable()
 {
    var entity = GetComponent<EntityProviderComponent>().Entity;
    entity.Add(this);
 }


 private void OnDisable()
 {
    var entity = GetComponent<EntityProviderComponent>().Entity;
    entity.Remove(GetType());
 }

Non-unity components are just added straight away to the entity.

Despite Richards suggestions I still want to use more separated Ash-way where the systems are separate objects (not ScriptableObjects), because it is more convinient for testing for example, and more strict. 

What I am concerned is the physics. I am thinking about a provider component for each object with rigidbody which creates a component in it's OnCollisionEnter, OnTriggerExit etc. and fires it down into Ash. As for the fixedUpdate, I am now thinking about custom action nodeFixedUpdate for each system, and a separate fixedUpdate cycle for Engine which calls these fixed updates.

[James Wrightson]

As someone who has worked professionally on a team with Unity AND fairly competent with Ash I can tell you
it really is not worth going outside the "Unity" way.

If you use Unity how it is meant to be used you can make maintainable code, there really is not much point in using
Ash in Unity as the trouble to get it working AND scalable is a pain :P

Try and wrap extensions from Unity and other things into the Ash style, it is just simply too hard to work with.

I prefer the decoupled methodology that Ash uses but this is based on custom in-house code, so using my own workflow
around Ash where the rest of my framework works well is essential. 

Unity's "GameObject" can work very well if used correctly and as its so entangled with the Unity engine it is not worth stepping outside.

[Michael Cann]

Okay well I spent most of the day scratching this itch but I have now completed a working Unity port of Richard's Asteroids. 

It was surprisingly not that bad. It all works much better than I was expecting. 

I wrote a blog post on it here: http://www.mikecann.co.uk/myprojects/unityasteroids/unity-ashteroids-ash-framework-in-unity/

The source is on GitHub: https://github.com/mikecann/UnityAshteroids

​

Probably performance isn't the best because of the per-frame component checks but there are improvements that can be made there.

--

You received this message because you are subscribed to the Google Groups "Ash Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ash-framewor...@googlegroups.com.
Visit this group at http://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

[James Wrightson]

Nice post, no one said it was impossible to do, more like it is pointless as you will now have slow bloated code that does not integrate well
with the Unity eco-system. :/

Good job for getting it working though, it is nice to have a port for Unity even out of curiosity.

Looking at your code I can see you had no choice but to keep the Unity bloat with it, (entities have transforms etc), but
it is cool anyway :D

[James Wrightson]

I wish I could edit posts but sadly groups does not allow...

Have you looked at : https://github.com/jacobdufault/forge ?

That would be much better suited if you had to work around Unity and is similar to Ash
in design, but much different under the hood.

[Michael Cann]

Hi James,

No I haven't heard of Forge before, it looks really interesting, ill have to give it a closer look.

I only did that work yesterday to see if it could be done, I had previously assumed it couldn't due to various Unity issues. I am happy with the result, it integrates with Unity nicely and I think it synergises well with the "check if it changed on each loop" way that Unity does things.

I personally dont think there is that much "Unity Bloat" in there. Most of the time you need a Transform component in one of your nodes so it just becomes another component on your entity. 

Mike

[Damion Murray]

Interesting discussion. It would be awesome if one could swap out Unity's native ECS(Entity/Component System) for Ash (or any 3rd party ECS for that matter). Sadly Unity is closed source so we can't go in and tinker with the code to create custom bindings.

However there is an open source project to create a unity-like game editor in haxe/openfl (spiritual successor to as3 and the flash platform as a whole). Its called blendHX, check out the project on github:  https://github.com/mehdadoo/blendHX.

I've thinking it would be cool if someone were to fork this project and make ash its core entity system. Or better yet make it capable of supporting multiple entity systems. Any takers?

[Guido Zuidhof]

I've been working on something similar, it does not have a visual part yet though. I am currently working on the build process of projects.

I decided to build it upon Kha, as OpenFL emulates the Flash API, which feels unnatural to add anything ECS to as it's OOP (inheritance) and scene graph based (although it has been done).

You can read about Mash on the github page.

Trivia: It was once called Dash, so the editor could be Rapidash (rapid ash). But then Dash engine popped up for the D language :c

Op zondag 17 augustus 2014 04:01:14 UTC+2 schreef Damion Murray: