playMaker

Author Topic: FSM Naming Conventions  (Read 2320 times)

sP0CkEr

  • Playmaker Newbie
  • *
  • Posts: 25
    • View Profile
FSM Naming Conventions
« on: April 15, 2011, 08:44:19 PM »
Curious as to what kind of naming conventions people are starting to adopt for PlayMaker FSM, Events and Variables. I find myself unable to decide on one that i like. So hoping that others will share what they do today.

Here are mine:

FSM - leave as default, have not figured out why i would need to rename unless i split into view/controller pattern
Events - preceding with _ and and using _ between nouns/verbs, soume using camel notation, examples:

    _add_score (using the underscore is nice because it sorts custom actions first)
    _player_die

    AddScore
    PlayerDie

Variables - preceeding with "." (dont ask), preceding with var type (i, s, v, etc), examples:

    .score
    iScore

- sP0CkEr

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 12342
  • Official Playmaker Support
    • View Profile
Re: FSM Naming Conventions
« Reply #1 on: April 16, 2011, 02:11:27 PM »
Hi sPoCkEr,

 Very interesting.

I go for verbal and plain english for events, state and variable

isAlive, doorEnabled, hasWeapon,  obviously a boolean
PlayerName, obviously a string
then yes, it becomes not so obvious for int, float, gameobject, etc etc

For States, I use plain English sentences when they fit in the limit.

For Events, no matter what we write, It feels wrong that events get listed all equally. For example, I create a  YES, NO, DONE set of events on most of my fsm, and they obviously only means something when used as State transitions. Yet they get listed with input Events, Application Events, etc etc.

Also, for Events, I keep them all uppercase cause it looks better ( and will look even better when the event casing will adjust properly and not crop the event string when too long :) ).

 Bye,

 Jean
 


MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • View Profile
    • FluidPlay Studios
Re: FSM Naming Conventions
« Reply #2 on: April 29, 2011, 10:45:37 AM »
That's what I've used so far:

FSM (More than one FSM in a single object): fsmController, fsmWeapon, etc.
State: Regular camel case with spaces. Eg.: Was Damaged, Move Right
Events: Generally the same as the State name with an "e" in the front and no spaces (eg.: eWasDamaged). I'm considering using upper caps "E" for global events for added clarity.
Variables: Prefix added to denote the type. Eg.: bIsReady, iScore, fPlayerSpeed. As such:
b = Boolean
i = Integer
f = Float
s = String
o = Game Object
v = Vector3
c = Color

I'm finding this a very good convention to work with, no problems so far. Having the transition/event named just like its destination state (in most cases) also takes less time than thinking about new names :) I'll probably start changing the global events prefix to upper caps right now, it's something that's slightly confusing when the global event is simply an event awaited while on a state instead of the regular "Add Global Event" box.
--
Breno "MaDDoX" Azevedo
@brenoazevedo

sP0CkEr

  • Playmaker Newbie
  • *
  • Posts: 25
    • View Profile
Re: FSM Naming Conventions
« Reply #3 on: April 29, 2011, 08:24:23 PM »
- MaDDoX - curious how prefixing vaiable (ala Hungarian notation) helps with your Actions as actions only show you allowable vars? Does it help when using vars in custom script? I think your state naming makes sense, and I have adopted.

- jeanfabre - i like your bool vars, i have adopted this as well.

I'm still on the fence for Events, for whatever reason. Like jeanfabre, I have adopted all uppercase naming, but I am sticking with preceding underscore so that they are listed first.

I know...wierd...

- spocker

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • View Profile
    • FluidPlay Studios
Re: FSM Naming Conventions
« Reply #4 on: May 03, 2011, 12:37:32 PM »
- MaDDoX - curious how prefixing vaiable (ala Hungarian notation) helps with your Actions as actions only show you allowable vars? Does it help when using vars in custom script?
More than anything hungarian notation makes me extremely comfortable when dealing with and recognizing variables. Sure you can only select a variable from the allowed type in the dropdown box, but that's only helpful when you're setting up the state the first time, after that you only have the field label as reference. For instance, if you're checking a "Set Vector3 XYZ" action it's not instantly obvious if X, Y and Z are floats or ints. Also when you're reading the variables list I don't have to go past the first column of characters to know which variable is of each type, and they stay all nice and organized on the list. It's a minor boost I know, but I love it ^_^

Quote
I'm still on the fence for Events, for whatever reason. Like jeanfabre, I have adopted all uppercase naming, but I am sticking with preceding underscore so that they are listed first.
Preceding underscore to list them first sound practical, but won't all uppercase confuse them with the standard Unity/Playmaker ones? Since I use low caps for custom events I can really find them at a glance amidst the all-caps one, and it's still in a single alphabetical order. I generally try to avoid starting underscores for Playmaker since they look a bit "programmer-like" to me (just like a coder mate who insists in adding "on" in front of all event names heh) but you guys got me curious so I'll test it sometime and see if I like it :)
--
Breno "MaDDoX" Azevedo
@brenoazevedo