playMaker

Author Topic: Sub Fsm: no problemo :) working prototype available  (Read 14388 times)

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Sub Fsm: no problemo :) working prototype available
« on: April 09, 2012, 11:51:33 AM »
Hello,

 It's been a while since I wanted to make a quick proof of concept of what I'd like to have built in, Sub Fsms.

 Basically, being able to run a fsm process within a state opens wild perspective, better reusability, better maintenance, more flexibility, etc etc.

 the thing is, playmaker is already that powerful, that it is actually possible to do that already ! :)

 I have attached a package showing one way of doing this, using a custom action "SubFsm". I had this in mind, had to get it done to make sure it was feasible.

basically, the idea is to create an empty gameObject, attached ONE fsm to it and save it as a prefab.

This prefab is then used with the action "subFsm" and is created and managed by this subFsm custom action. It currently can do the following:

-- Bind an Fsm float FROM the Fsm TO the SubFsm.
-- Watch for the GameObject destruction and in that case call an event ( one way to trigger an event when the SubFsm is finished).


Obviously the only limitation is the SubFsm custom action interface. For example, a built in integration of such subFsm system by playmaker would required a more advanced UI, to bind any variable and display a list of variables the way we are used to, via a dropdown. The rest would be only convention really. For example, I expect a SubFsm to declare a "__MASTER__" FsmGameObject, I inject in that the Fsm.Owner so that within a SubFsm, we can control the actual GameObject that runs this fsm ( as opposed the gameObject the subFsm is running from, which is of no use, only to support instantiation of this SubFsm).


I'd like to take this one step further, because even as is, I could create a compound set of variable to give total flexibility with bindings ( choosing any variables, from Fsm to SubFsm, AND back, from SubFsm to Fsm).

So, I think, supporting SubFsm, is totally feasible with actually, minimal impact on playmaker current state and features ( it only needs a more flexible or dedicate ui component for this subFsm variable binding).


I'd really like to hear what you have to say about this, and where you'd see this going, that would help me improve the SubFsm custom action.

 Playmaker rocks :)

 Bye,

 Jean

kru

  • Playmaker Newbie
  • *
  • Posts: 3
Re: Sub Fsm: no problemo :) working prototype available
« Reply #1 on: April 10, 2012, 02:52:16 AM »
What is the purpose of a sub-fsm?  What might one use this functionality for?

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Sub Fsm: no problemo :) working prototype available
« Reply #2 on: April 10, 2012, 03:50:41 AM »
Hi,

 Sub fsm is a one way to do the following:

-- reuse a process:
A given Fsm might be responsible for a high level task, and to prevent mixing high level task and details, small implementation and features, it can go into a sub fsm. This is huge.

-- encapsulation ( black box):
Sometimes it is good and very effective to hide features from a fsm. A fsm dealing with receiving input, does not and should not know or deal with how this input is processed and used by a feature of your game. Sub Fsm would allow you to keep things clearly organized that way. It's not really the same as the "reuse" point above, as it is more about the semantic approach of what you are trying to achieve, aside the effectiveness of the implementation approach


-- unclutter a Fsm:
The two points above lead to another great positive net result: you have simpler Fsm, more readable, more maintainable.

-- Flexibility:
Now, on medium/large scale project, this becomes anyway the only way to work and provide a stable and flexible project ( read when the client is asking for that unforeseen change the day before the deadline...). How fast and reliable you can be when doing that change is very much dependant on how you organized and layed out your features and various Fsm. If all the points above where in your mind when you design a feature, you'll end up with a very positive problem: changes will take no time, and you'll have to raise your hourly rate cause you are bloody quick now :)

Say in that example I provided. The clients comes back and say: now I want to offer various animations when the user click on that mighty cube, and oh yes I forget to tell, we need this on other models as well. If you have hardwired everything... you can just start again, start duplicating code, ect etc. Here,  you create new sub fsm each representing a different animation, and you load the appropriate sub fsm. So the only change is to offer a list of possible Sub fsm instead, no big deal! AND you can reuse them sub fsm on other Fsm for the new model you need to animate. If everything was wired in one fsm, you'd have to wired some more, and you'd end up with too many states, spaghetti links,  rendering your fsm unreadable, rigid and one step further instability and not-anymore-fun development.


Bye,

 Jean

yezzer

  • Playmaker Newbie
  • *
  • Posts: 24
    • Follow me on Twitter
Re: Sub Fsm: no problemo :) working prototype available
« Reply #3 on: June 27, 2012, 05:21:36 PM »
jeanfabre: This looks great. Any chance of getting a tutorial or sample project for this? I'm making AI in PlayMaker for a 3rd person shooter, and this looks like it would be extremely useful.
Freelance games & App developer using Unity3D, Flash & Adobe AIR for web, iOS, & Android. Interested in AR & other emerging tech.
@yezzer

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Sub Fsm: no problemo :) working prototype available
« Reply #4 on: June 28, 2012, 01:18:28 AM »
Hi,

 The package does have a sample attached, have you checked it?

 also, this is quite an advanced concept and you will need to script custom actions to match your sub fsm needs, for example I did only one action that can pass a float variable, obviously in any other scenario you'll need to pass other variables types and most likely several as well.

Could you explain what kind of AI you want to implement, and we'll take it from there to see what solution would best fit your needs. If it turns out subFsm is the way, I'll help you out building the actions for it.


Bye,

 Jean

yezzer

  • Playmaker Newbie
  • *
  • Posts: 24
    • Follow me on Twitter
Re: Sub Fsm: no problemo :) working prototype available
« Reply #5 on: June 28, 2012, 04:04:14 AM »
Damn, somehow missed that! Downloaded, will check it out later :)

I'm on my way to building a horizontal layered AI using FSMs, along these lines:
http://aigamedev.com/open/editorial/fsmgate-scandal/

After reading about the early Quake and Unreal AI, I think using PlayMaker would fit it pretty well. I don't want to create anything as complex as that - yet - but this looks like a good model to follow to build a more advanced AI than I have before. Previously, I've just had patrol/idle/hunt/attack - again using 2 or 3 FSMs in PlayMaker. Ideally I'll use what I've learned making this, and use it to create more complex AI in future.

After brainstorming for some time, reading everything I could find (AIGameDev is a fantastic resource), and mapping out a bunch of functionality and describing the FSMs in Omnigraffle, I've started building the FSMs in PlayMaker. I don't have to use sub-fsms, but they might be useful.

So far I have The following FSMs:
Senses (vision, hearing)
Behaviour (Idle, Wandering, Acquisition, Patrol, Fleeing,Searching, Dying)
Combat (Hunting, RangedAttack, CloseAttack)
Movement (MoveToPoint, TurnToFacePoint. Will be using NavMesh and NavMeshAgents for this iteration of the AI)
Animation (various states)

I'm thinking I could probably use sub-fsms for the different states in Behaviour and Combat. There may be a better way of doing it, and I'm open to suggestion.

I'll take a look at your example and see how it works. Thanks!
Freelance games & App developer using Unity3D, Flash & Adobe AIR for web, iOS, & Android. Interested in AR & other emerging tech.
@yezzer

amaranth

  • Full Member
  • ***
  • Posts: 172
Re: Sub Fsm: no problemo :) working prototype available
« Reply #6 on: August 09, 2012, 05:55:02 PM »
I 1000% agree with this idea and thank you for providing this sample and action. Even for small projects, I think this is a good thing to have. I was getting ready to code my own system until I saw this.

In my RPGs that I've made in the past years, I relied heavily on this type of system. This is what I felt PlayMaker was missing and I'm excited to see you implemented a solution. I'll write down notes as I use the sub FSMs and let you know if there are any features that might be neat to add.

Jean, you are seriously awesome! Everytime I think I need to create something from scratch, you've already done it and posted it for all of us newbies.  ;D

[Update]
Jean, there is something that I see that might cause problems. From previous tests on iPad and Web, creating and destroying objects caused my frame rate to drop. Is this not a problem with SubFSM creation?

[Update]
I wonder... would adding/removing FSM scripts to one game object be a faster alternative for performance? I've only tested adding/removing game objects. Maybe a pool manager on one game object for FSM scripts? I'm going to hunt around and learn what I can about performance and script objects.
« Last Edit: August 09, 2012, 07:18:46 PM by amaranth »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Sub Fsm: no problemo :) working prototype available
« Reply #7 on: August 10, 2012, 02:49:11 AM »
Hi,

 yes, creating gameObjects is resource intensive, that's the main draw back of my solution, but I merely provided this as a mean to spark discussions about this in hope that playmaker will officially provide a solution for this ( a performant one I mean).

You could use pools framework, that would increase perfs dramatically.

I think adding component has the same impact on perfs than gameObject ( maybe slightly less)

Bye,

 Jean

dasbin

  • Junior Playmaker
  • **
  • Posts: 92
Re: Sub Fsm: no problemo :) working prototype available
« Reply #8 on: August 23, 2012, 02:01:30 AM »
Jean,

Thanks so much for your work on this.

Right now this is the biggest problem on our game, which is a fairly large-scale project. We can have 100's of objects in a scene all with the same FSM's doing the same (or nearly the same) things. The objects would be based off about a dozen prefabs or so. It is really annoying and time-consuming to have to go through all dozen of those prefabs FSM's just to tweak one or two things in the core mechanic all to be the same.
A far better solution would be to instantiate a task-specific FSM at runtime when needed and destroy it when done. Then the master FSM can be shared between prefabs.

Amaranth has a good point about the performance problems of actual instantiation and destruction though - any real solution would need to point to the FSM master as being in a self-replicated "Pool" at runtime.

I hope Alex takes notice of this and starts thinking of an official Playmaker implementation :) If it were able to function as though the FSM were on the object all along, instead of passing variables through custom actions, that would be ideal.