playMaker

Author Topic: wiseguy thread (random tips and tricks whenever you stumple upon them :D)  (Read 19128 times)

kiriri

  • Hero Member
  • *****
  • Posts: 506
[I'll start detailled explanations on the last few quotes soon]

So, I really missed this kind of thread. In here you can post useful, but quite simplistic tricks you use to make stuff work or work easier. It's best if it'd remain very short like:

Quote
"To get the mouse wheel as an up/down event, use "Get Axis" on the "Mouse ScrollWheel" axis and then simply add a compare float action right behind it. If the float is bigger than 0, you scrolled up, if it's smaller you scrolled down."

I stumble upon these small gems all the time but since they are sooo simplistic, I never thought of sharing them. I'm sure you have some of them too :) Either way , I'll be adding more soon !

Cheers
,kiriri

List of them all so far:

Quote
"A complete input manager can be very cumbersome with its' various transitions. Use global transitions to be able to see the corresponding states better."
However:
Quote
"If the user right click AND scroll at the same time, your Fsm could not complete one of the two action."
by JeanFabre
Therefore as a conclusion the key up or mouse button up actions should never be placed in the input manager, to avoid them being overwritten by another key. However, it should be noted that , unless you do more thant just send an event to another FSM, it is very unlikely that a key will be pressed in the milisecond needed to process the first key, and therefore it may be ignored. In a final game one might consider separating the INput manager though.

Quote
"Using colored states and transitions can drastically improve your work efficiency since the additional visual input helps your brain not to shut down. Mindlessly sitting in front of the PC without doing a thing is a major enemy of any programmer."

Quote
"A wise man uses / to define categories in the everchanging ways of the variable and event. A wise man would just create a random variable named "a/b" to see what this one means. A wise man would notice it when using the variable in any action."

Quote
"A lazy person may consider saving time when copying states from one FSM to another. A lazy person would first copy the actions to the background of that same fsm, creating a new state with just those actions while doing so, and then copying that state to the other fsm. A lazy person would then be able to just paste his actions directly into one of the states there and all the variables, values and preferences concerning the variables which are used in the actions he just copy pasted would be automatically transferred to the other FSM. This saves the lazy person much time he would have otherwise used to recreate the variables."

Quote
"A sagely Game Maker would make sure that all his GUI elements look the same on any resolution, since he knows that normalized screen size depends on the screen aspect. Therefore said Game Maker would first calculate the screen X aspect by dividing the screen X resolution by the screen y resolution. The Game Maker would then use this X aspect variable to multiply it with the values he would normally use for the screen height (not width, for width you need to divide Y by X) of GUI actions. By doing so, his GUI elements will always stay square, no matter the aspect or resolution."

Quote
"A profound professional knows to ignore conditions. A profound pro would often create a state with a XXX compare action, which only did profound profoundness if true. If untrue, the state continues and FSMstates under the XXX compare state will be processed. If true, those states would not be processed. This means if the condition is either FALSE or TRUE, you only need to add one new state for one of the results, and have the other continue in the current state. "

Quote
If you ever have a prefab that uses itself (the project gameObject/ the real prefab) in any way, you will notice that once created, the new version of the prefab in the scene will now not reference the original prefab, but itself instead. So if a prefab creates itself, the scene version is duplicated, not the prefab version. To avoid this, you can create a global variable. To avoid messy dropdowns, I use the category "prefab" for all prefab variables.

Quote
"An over-eager playmaker user may search for an action and mistype the name of the action at the end. At that point the search result is empty. If he or she knows that he typed the first part right, and that the first or only result in the search before he made the error must've been the right action, and he just continued typing out of habit, then he can just press enter in that search and even though there's nothing to select, the previous selection will be used, which means the needed action will appear."

Quote
You can quickly deselect a variable by pressing Esc. It's very useful if you're having a lot of different Variables in one FSM and can't find an empty space to click to deselect the variable.
Source: http://hutonggames.com/playmakerforum/index.php?topic=2283.0


Quote
If you directly change a prefab, those changes will remain even if you stop playing the game. So if you need to change a certain parameter on a lot of gameObjects at once, you could create a (nested) prefab and add every gameObject that needs changing as a child of that prefab. Then you could create an FSM and go through all of the childs of that prefab and do certain actions. Like you may have a naming convention and you could string compare and then have a lot of different changes tailored to that type of GameObject. Then you can stop running the game and all the changes remain. You can then drag the different prefabs back onto their real prefab (if they have one) and voilá, you've then changed an indefinite amount of different objects permanently and all at once.

Quote
Playmaker offers default global events of the type "system event". These include mouse down, mouse up, etc, which work just like the mouse event action.
Now, that was probably nothign new to you. The real thing that is just so awesome is that the system events and the action are actually complementary and not redundant. The thing is, if you work with multiple cameras at once (split screen), the mouse event action will always use your active camera to check whether your mouse is over an object. That is nice and stuff, but what if we have the left part of the screen displayed by another camera? The actions will still use the main camera and say you are over something which you can't even see!
And here's where the system events kick in. They don't care what your main camera is. If something is visible on the screen and if it contains a collider, it will be triggered if the mouse is over/on/off. If you use them you will get the actual gameObject you see on your secondary camera and not something from the main camera which you can't even see.
« Last Edit: December 24, 2012, 09:57:33 AM by kiriri »
Best,
Sven

kiriri

  • Hero Member
  • *****
  • Posts: 506
new one:

Quote
"a complete input manager can be very cumbersome with its' various transitions. Use global transitions to be able to see the corresponding states better."

I learned that the hard way, I just replaced 30 or 40 transitions with global ones, and now it looks very ordered. Previously it looked like an atomic gooseberry :D.

If you've got such tips, I'd be eager to hear them. I believe it's small things like these that finally make a good FSM coder :)
« Last Edit: October 06, 2012, 08:46:07 AM by kiriri »
Best,
Sven

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Hi,

 can you share a screenshot of the fsm so that we can get an idea of what it looks like? I generally never put global events as stats transitions, so interested to see what you've done.

bye,

 Jean

kiriri

  • Hero Member
  • *****
  • Posts: 506
quite simple, normally an Input controller has lots of transitions and each new state does it stuff, then triggers FINISHED, then returns to the start input state. That means the new states are bound to be larger than the transition on the start state. And that in turn means one has to arrange the different FSMs weirdly.

I attached first the new version (I wasn't able to get it all on in one screenshot without defeating the purpose of order) and then how I had originally done these things (entirely different project since I didn't save but it's the concept that counts)

Each state is in essence 1rst a send event to another FSM, then a send event to the same FSM to trigger "active" (and go back to the original state). Since it's within the same FSM I don't need tto use global events, just global transitions, but using global events adds the ability to trigger stuff from other FSMs easily.

So all in all quite simple and quite an improvement on larger projects.

Looking at that reminded me of another sagely thing to say:

Quote
"Using colored states and transitions can drastically improve your work efficiency since the additional visual input helps your brain not to shut down. Mindlessly sitting in front of the PC without doing a thing is a major enemy of any programmer."
« Last Edit: October 06, 2012, 08:45:49 AM by kiriri »
Best,
Sven

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Hi,

 Very good. Tho your Fsm is likely to give trouble down the road because there is too many different possible entry point.

 If the user right and click AND scroll at the same time, your Fsm could not complete one of the two action. so I suggest you split this Fsm into smaller Fsm each responsible for one distinct User Input, this way you will never have weird bugs or behavior. Remember that a fsm can be in only one state at a time, so if this fsm is processing something and is taken away from its task by another action, then you hit trouble.

bye,

 Jean

kiriri

  • Hero Member
  • *****
  • Posts: 506
If the user right and click AND scroll at the same time, your Fsm could not complete one of the two action.

I kindly disagree. The time needed for the FSM to process through the different states is virtually non existing. Despite some of it looking like it actually processes stuff, it only does very low cost stuff (mostly comparing). So you'd have to be quite perfect in hitting 2 buttons at exactly the right milisecond to make it not work . Personally, I haven't managed that yet :P. And if for some reason one person actually manages this, he'll probably blame his keyboard and not the game :D
I do agree on the concept though, and most of my key up actions are in the individual FSMs to really ensure stuff stops when it's supposed to .
Best,
Sven

kiriri

  • Hero Member
  • *****
  • Posts: 506
I'll try to make my stuff sound more wisely from now on... maybe then more people will start adding their opinions.
Quote
"A wise man uses / to define categories in the everchanging ways of the variable. A wise man would just create a random variable named "a/b" to see what this one means. A wise man would notice it when using the variable in any action."

Quote
"A lazy person may consider saving time when copying states from one FSM to another. A lazy person would first copy the actions to the background of that same fsm, creating a new state with just those actions while doing so, and then copying that state to the other fsm. A lazy person would then be able to just paste his actions directly into one of the states there and all the variables, values and preferences concerning the variables which are used in the actions he just copy pasted would be automatically transferred to the other FSM. This saves the lazy person much time he would have otherwise used to recreate the variables."
« Last Edit: October 08, 2012, 07:06:56 AM by kiriri »
Best,
Sven

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
hi,

 Yep, I agree that the cases would be hard to repro, hence why this is very important to be fully aware of this. I see a lot of Fsm that are mixing different processes, so it's important to not leave users think that it is a fine design pattern, because they will hit problems if unaware of this situation. My comment aims at beginners, more advanced users already passed that concept and know when features can be condensed into one fsm and when not.

bye,

 Jean

kiriri

  • Hero Member
  • *****
  • Posts: 506
Yeah, merci Jean. I hope you don't mind my adding your post as a quote too (in the top post).

Here's another piece of mind. It's a bit complex but I think it's still too simple to deserve a thread on its' own:

Quote
A sagely Game Maker would make sure that all his GUI elements look the same on any resolution, since he knows that normalized screen size depends on the screen aspect. Therefore said Game Maker would first calculate the screen X aspect by dividing the screen X resolution by the screen y resolution. The Game Maker would then use this X aspect variable to multiply it with the values he would normally use for the screen height (not width, for width you need to divide Y by X) of GUI actions. By doing so, his GUI elements will always stay square, no matter the aspect or resolution.
« Last Edit: October 11, 2012, 12:34:23 PM by kiriri »
Best,
Sven

clandestine

  • Sr. Member
  • ****
  • Posts: 255
    • ЯKD.ZONE
I very much enjoy your thread!
Please continue!

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: wiseguy thread (random tips and tricks whenever you stumple upon them :D)
« Reply #10 on: October 11, 2012, 03:14:55 PM »
Hi,

 Adding to the "/" use in variable names, I also use "/" in my global events, because if you create an event called say "ROBOT / MOVE" and another event "ROBOT /RUN" then when you want to add them as transition, they appears under sub menus, so MOVE and RUN would be categorized under ROBOT. This prevents long and painful drop downs,

bye,

 Jean

kiriri

  • Hero Member
  • *****
  • Posts: 506
Re: wiseguy thread (random tips and tricks whenever you stumple upon them :D)
« Reply #11 on: October 22, 2012, 12:50:01 PM »
thanks clandestine, sorry I couldn't update, I just didn't have any ideas, since I worked a lot on the graphics side of my game lately.

And désolé jean, I must've overlooked your post. I couldn't quite find a thing to quote from your post, so I just added it to the original quote. I hope that's alright with you. I will probably reference each quote to some posts in here soon, if we manage to collect more wisely wisdoms :D Then you'll get the due credits ;)

A new one, which is very obvious for anyone who used playMaker for some time, but may be interesting to the new guys :
Quote
"A profound professional knows to ignore conditions. A profound pro would often create a state with a XXX compare action, which only did profound profoundness if true. If untrue, the state continues and FSMstates under the XXX compare state will be processed. If true, those states would not be processed. This means if the condition is either FALSE or TRUE, you only need to add one new state for one of the results, and have the other continue in the current state. "

I snapped out of the sagely tone at the end to drive home the point of the quote. I think this is a very important thing everyone should be aware of. It can save a lot of states, especially if used in nested conditions.
« Last Edit: October 22, 2012, 12:54:25 PM by kiriri »
Best,
Sven

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: wiseguy thread (random tips and tricks whenever you stumple upon them :D)
« Reply #12 on: October 24, 2012, 04:09:16 AM »
Hi,

 Maybe you could make a screenshot or a package of the correct way against a less efficient or alternative ways?

bye,

 Jean

kiriri

  • Hero Member
  • *****
  • Posts: 506
Re: wiseguy thread (random tips and tricks whenever you stumple upon them :D)
« Reply #13 on: October 25, 2012, 11:44:22 AM »
right, I'll do that this weekend. Turns out to be a bit difficult in just one image, so I'll have to see how to illustrate it.

Until then, I've got another wisdom, which I would just love to replace with a more elegant one (in terms of solution), but beggers can't be choosers :D

Quote
If you ever have a prefab that uses itself (the project gameObject/ the real prefab) in any way, you will notice that once created, the new version of the prefab in the scene will now not reference the original prefab, but itself instead. So if a prefab creates itself, the scene version is duplicated, not the prefab version. To avoid this, you can create a global variable. To avoid messy dropdowns, I use the category "prefab" for all prefab variables.
Best,
Sven

kiriri

  • Hero Member
  • *****
  • Posts: 506
Re: wiseguy thread (random tips and tricks whenever you stumple upon them :D)
« Reply #14 on: November 04, 2012, 08:07:58 AM »
I know I said I'd go into detail about the last quotes soon, but recently I've had a lot of work so I couldn't do it yet. I haven't forgotten it though, and so I won't forget this tip I just came up with I'll post it immediatly :)
This time it's again a small tip for advanced PlayMaker users:

Quote
"An over-eager playmaker user may search for an action and mistype the name of the action at the end. At that point the search result is empty. If he or she knows that he typed the first part right, and that the first or only result in the search before he made the error must've been the right action, and he just continued typing out of habit, then he can just press enter in that search and even though there's nothing to select, the previous selection will be used, which means the needed action will appear."
This can save up to half a second per search, but I still find it relaxing to sometimes just mistype an action and still have it work :D
Best,
Sven