Playmaker Forum

PlayMaker News => General Discussion => Topic started by: sP0CkEr on April 15, 2011, 11:44:19 PM

Title: FSM Naming Conventions
Post by: sP0CkEr on April 15, 2011, 11: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
Title: Re: FSM Naming Conventions
Post by: jeanfabre on April 16, 2011, 05: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
 

Title: Re: FSM Naming Conventions
Post by: MaDDoX on April 29, 2011, 01:45:37 PM
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.
Title: Re: FSM Naming Conventions
Post by: sP0CkEr on April 29, 2011, 11: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
Title: Re: FSM Naming Conventions
Post by: MaDDoX on May 03, 2011, 03: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 :)
Title: Re: FSM Naming Conventions
Post by: kentcheung2000 on June 29, 2018, 02:40:19 PM
Naming Global event can use the format like eeGlobalEvent
Title: Re: FSM Naming Conventions
Post by: verybinary on June 30, 2018, 11:04:37 AM
The first/primary FSM is always FSM as I know which FSM im typing in when I get an FSM variable
States get named in lowercases and without spaces, and attempted to be truncated to fit in the states default width. usually what its doing or checking for.  isvr loadmenu haskey
events are less standard, the important part is in the state, events might not even make sense until you look at the state, I do tend to use 00 and 01 a lot for binary choices like has key a lot, and that got started with using a lot of 00-09 as goto events for big fsms that I didn't want dozens of events on. How many coins - 1-9, then to a state for how many medicines - 1-9. instead of using a yes and a no as extra states, I can just use the same 00 and 01 that's set up. the events on interactables always start with a click event. if a state waits for non user input, the state is go.(globalgo is used when a state needs trigger from another FSM). But other than these and a few random other cases, events are pretty generic in the same form as the states, lowercase and spaceless. ishit, getcoin, openchest.
variables. globals are prefixed by global. globalplayerarray, globalparty1array. normal vars are lowercase descriptions. health, money, blah. I usually also have tempint and tempobj in there too for "get int, convert it to tempstr, set tempstr to guitext" type situations. npcs and standalone objects usually have myhealth, mystatus, some variables are postfixed with type like the temps when I have multiples that have different types, like playerobj and playerstr. that's all I can think of within the context of the post that makes me weird, but I technally have a completely unorthodox system for everything related to unity.