playMaker

Author Topic: How do you organize your work?  (Read 2544 times)

Krillan87

  • Beta Group
  • Full Member
  • *
  • Posts: 185
How do you organize your work?
« on: February 15, 2017, 03:03:34 AM »
Hi!

So my main character in my game is starting to have A LOT of FSMs on him. So I started to think about how I could organize my FSMs and my work in a better way.

My first idea was to create empty game objects as children with different categories of FSMs (Like one with only FSMs that controls Health/Mana/Potions and one that only controls Skills/Experience/Level up and so on).

The problem with this was that some FSM needs to on a certain game object to work. My main problem here is animation events (https://hutonggames.fogbugz.com/?W181) that needs to be on the same objects as the animator component.

I have also read that you can name your FSMs with a / to create sub-categories but I do not know if i like that workflow.

So... How do you organize your work? Maybe someone here with a little more experience with bigger projects and such. Thanks!

elusiven

  • Full Member
  • ***
  • Posts: 233
  • Debt we all must pay...
Re: How do you organize your work?
« Reply #1 on: February 15, 2017, 05:17:35 AM »
My project tries to follow some MVCC (Model-View-Controller-Component) design pattern. Although this might not work well with full-size games this fits well with my educational 2d app.

I have one canvas that controls all the Views (different pages of my app).
I have an empty game object with Models, so this store information on how each model should look like, all its properties, functions etc.
Then under Controllers I have my controllers, and I pass data to model from xml, and display it on a view. I also have an empty game object like Helpers, which include some random/generic functions.

The app itself is pretty small, only one scene. The images/sounds load from a server and all the levels are stored in an xml file.

I actually come from php background and all my previous work was done in Laravel framework, which is an MVC. I wish I knew about Xamarin earlier, because I would probably switch to that instead of developing a 2d app in Unity, but I was like hey.. Niantic developed Pokemon Go in Unity so it can't be that bad :P

I would recommend on having as little fsms as possible, as each time you add an fsm your performance will decrease. Organize everything or most of the stuff with empty game objects because it can get messy with larger projects. Also, use templates for things that will share functionality. For example I have a template to check internet connection, and because I re-use this a lot of times in different places I made it into a template.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: How do you organize your work?
« Reply #2 on: February 15, 2017, 06:08:32 AM »
Hi,

Just shiming in. Niice advices here, thanks for sharing your experience.

 But, I am not sure I agree that adding fsm equates to performance diminution. It's like saying adding a script decreases performances. It's how Unity component based system was designed from the ground up. I got the same assumption when I first jumped into Unity and PlayMaker, I wanted to have a conventional scripted approach to my development, but Unity and PlayMaker have very specific paradigms in the way they work, Unity is component based, PlayMaker is Fsm Based, so embrace this, and when you hit some performances issues along the development, you must bring on the table hard evidence that it's because you have too many Fsms.

you have to realize that it's not because it's visual development environment that it's heavy on the execution side, the two are separated. The Fsm core execution is deceptively simple, you can find some open source Fsm scripted in c# around, it's really not a big deal at all in terms of code foot print.

 I think you should have a very different approach with this. First make the feature work, then optimize, if you start by worrying about your number of fsms, this is going to be problematic and you may actually end up doing very bad design pattern just because of this.

I am speaking of experience here, you'll find that 99% of projects will have problems with graphic performances and content management, not scripting. Use the wrong shaders and you loose 10FPS instantly... put some nice camera effect and you are doomed on mobile, too much meshes and content and your VR project is simply not fluid enough. I don't think you can then compare this to the impact of adding too many Fsms or components on a GameObject on the overall frame rate.

 I have ported several projects from fully scripted to fully done in PlayMaker and I was always very positively surprised by the constance of PlayMaker in its footPrint. The latest is the Space Shooter UnityLearn Project for example (https://github.com/jeanfabre/PlayMaker--UnityLearn--SpaceShooter_U5.5) and I published on webgl which is known to be the less performant platform, and the fps difference is 1 FPS with my test, pretty cool!

The usual mistake in blaming PlayMaker is for example using an action that in turns use a Unity api call that is known to have bad performances, for example FindGameObject. This is known to be a bad call, and you should really never use this in your game loop or abuse it, it's preferable to find gameobject by tag or to have a direct reference to it via sending an event to the interested fsm willing to work with that GameObject, etc etc. The same execution of finding a GameObject by its name without PlayMaker would lead to the same performance issue.

Bye,

 Jean


Krillan87

  • Beta Group
  • Full Member
  • *
  • Posts: 185
Re: How do you organize your work?
« Reply #3 on: February 15, 2017, 08:08:47 AM »
Hi,

Just shiming in. Niice advices here, thanks for sharing your experience.

 But, I am not sure I agree that adding fsm equates to performance diminution. It's like saying adding a script decreases performances. It's how Unity component based system was designed from the ground up. I got the same assumption when I first jumped into Unity and PlayMaker, I wanted to have a conventional scripted approach to my development, but Unity and PlayMaker have very specific paradigms in the way they work, Unity is component based, PlayMaker is Fsm Based, so embrace this, and when you hit some performances issues along the development, you must bring on the table hard evidence that it's because you have too many Fsms.

you have to realize that it's not because it's visual development environment that it's heavy on the execution side, the two are separated. The Fsm core execution is deceptively simple, you can find some open source Fsm scripted in c# around, it's really not a big deal at all in terms of code foot print.

 I think you should have a very different approach with this. First make the feature work, then optimize, if you start by worrying about your number of fsms, this is going to be problematic and you may actually end up doing very bad design pattern just because of this.

I am speaking of experience here, you'll find that 99% of projects will have problems with graphic performances and content management, not scripting. Use the wrong shaders and you loose 10FPS instantly... put some nice camera effect and you are doomed on mobile, too much meshes and content and your VR project is simply not fluid enough. I don't think you can then compare this to the impact of adding too many Fsms or components on a GameObject on the overall frame rate.

 I have ported several projects from fully scripted to fully done in PlayMaker and I was always very positively surprised by the constance of PlayMaker in its footPrint. The latest is the Space Shooter UnityLearn Project for example (https://github.com/jeanfabre/PlayMaker--UnityLearn--SpaceShooter_U5.5) and I published on webgl which is known to be the less performant platform, and the fps difference is 1 FPS with my test, pretty cool!

The usual mistake in blaming PlayMaker is for example using an action that in turns use a Unity api call that is known to have bad performances, for example FindGameObject. This is known to be a bad call, and you should really never use this in your game loop or abuse it, it's preferable to find gameobject by tag or to have a direct reference to it via sending an event to the interested fsm willing to work with that GameObject, etc etc. The same execution of finding a GameObject by its name without PlayMaker would lead to the same performance issue.

Bye,

 Jean

Hi Jean,

Thanks for sharing you thoughts on the FSMs. This is my first project in Playmaker and I have always been a bit worried that i over-use FSMs but it feels really nice knowing that I can relax. My game is also to a desktop computer so there a lot more power than using a mobile phone.

Do you have any inputs on the organization part? Right now, I have one game object that I call "MyBrain" on each character with all the FSMs that does calculations of some sort, and then I put all the other FSMs on the main game object.

I have not used a single template yet (I do not even know what they do), is it important to use templates?

Any other inputs on how to organize the work?

Thanks a bunch for all the help (and an amazing product!)

bye,
Christian

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: How do you organize your work?
« Reply #4 on: February 16, 2017, 12:46:05 AM »
Hi,

 don't worry about template right now, indeed it's something to be using with caution and be well aware of the shortcomings that could possibly make debugging more difficult.

few posts that you should read carefully ( they are typically tltr but it's important to go throught them...)

http://hutonggames.com/playmakerforum/index.php?topic=13603.msg63269#msg63269

http://hutonggames.com/playmakerforum/index.php?topic=14313.msg66459#msg66459

Bye,

 Jean