Systems, as far as the eye can see...

[Mnem der Maschinenwelt]

Hi,

I'm thoroughly enjoying using Ash at the moment, it has a wonderfully elegant structure. However as with any new model of coding, I can't help worry if I'm using it well. I've now grown old enough to give up trying to use something "perfectly" :)

Currently I create many systems to process very specific behaviours and states, rather than clustering broader amounts of functionality within one system. Often (and probably in the majority of my systems) the main update method has 6-12 lines of useful work to do.

For example, I may have an NPC who has a queue of tasks to get through before they do something else. This could be implemented with 3 systems - one to manage the queue, one to do whatever the task is, and one change the NPC state when all the tasks are done. Alternatively it could be encapsulated in one system.

To me, it feels neater to have a clear division of responsibilities. However, having such neatness comes at a cost - although it allows flexibility, a clear view of the overall purpose can be lost amongst a multitude of systems and nodes.

So, on to my question: how do y'all break up your functionality between systems? Few systems each with a lot of code? Many systems with tiny bits of code? Have you tried both and can list pros and cons to put might mind at ease? :)

mnem

[Michael Cann]

I know exactly what you mean and it was the same thoughts and feelings I had when working with RobotLegs alot. The price of increased Sepparation of Concerns is more classes. However, like RobotLegs, you have the option of putting more functionality in a particular system then separating it out later if you like.

Over the years I have noticed that there is a stage in a project where you can no longer "keep everything in your head" you cannot know every facet of your application and hence cannot know precisely the outcome of a particular change. This is where separation of concerns comes in, so long as you organize your code well and reduce dependencies you dont have to worry so much once you go past the critical mass point.

I think ash's rules about no inter-system communication and other rules really help with managing the complexity in your head which in turn makes making games more fun. 

As for your question; I have noticed that when using ash that if the Node that a particular system relies on starts having too many components then there is probably grounds for some code to be split off at that point. 

mnem

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

@mikeysee

[Billy Belfield]

I personally prefer many simpler systems over complex ones. I almost always end up going back to complex systems and breaking them up so they are more generalized and I can reuse them. That said, starting complex isn't a bad way to start to get something working quicker. Until you actually need to reuse some functionality it isn't always clear how a set of features should be divided.

[Neil Manuell]

I've also hit this conundrum.

As in RL I have opted for many simpler systems.

If you are going to place the complexity into to configuration, you might as well go the whole hog.

[Mnem der Maschinenwelt]

Reassuring to hear that other have gone down the same road :)

Mike, that's a good point about not being able to keep everything in your head. I hate that stage of a project though - it's scary stepping over that line and just trusting the code, Luke :)

Thanks all!