Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Thore

Pages: [1] 2 3
Playmaker Help / Re: How can I change objects randomly with a button?
« on: September 19, 2017, 05:57:40 AM »
1) Make sure the hats have a consistent anchor or mounting point. I'm not versed in 3D, but that would be the objects pivot. If that fits, skip step 2.

2) If you have no good pivots: Add Game Object, name it "Actual Hat". Give it a dot icon (inspector, top), so you see where it is. Take one good example hat mesh, and place it as a child. Now move it so that the point icon is where the hat is supposed to sit on the head. That's your anchor point. Later you do this for all hats, hence rename the "Actual Hat" to whatever the hat is, say "Cowboy Hat".

3) Next we define the place where the hats are mounted. Make a new game object, again, add a dot icon of a different colour, and call it "Mount Head". Next, drop one good example hat, say "Cowboy Hat" as child, and zero it properly. Now move the whole Mount-With-Hat contraption where it fits nicely. The pivot of the hat, the mount point and the place on the character model should now align. Because of this, you can now make any number of hats and when they are child and zero of the mount, they should fit perfectly.

4) Now, the drawing hats trick. Drop all hats under the mount (as prefab or as they are). This is now also the pool. In a more sophisticated system, the pool might be a separate object outside view, and you draw, parent, and set zero to mount.

5) All you need to do now is get a random hat, for example with get Random Child. I think there's also a method based on tags. Then activate this hat. Since you store the randomly drawn game object in a variable, you can use this to deactivate the object again, and then repeat with getting a new random object.

Playmaker Tips & Tricks / Re: Improving The Workflow
« on: September 19, 2017, 04:40:23 AM »

 This could go on the wiki actually. Thore, w can add you to the wiki authors, would you like that?



Sure. :)

As we all know, complex graphs can become tricky to keep tidy at times. I use  empty states, named sequentially starting with Pin 1 and exclusively coloured black, to feed transitions into so that I can force links to move cleanly around states rather than cross over them. In the absence of a true 'pin' function in Playmaker this works really well! I don't know if I'm explaining that very well so I'll pop up a screenshot later.

Thanks for the reply. I'm curious about this one! Screenshot would be very nice.

Action Requests / Camera: Smooth Follow Action + Distance Damping?
« on: September 17, 2017, 08:50:21 AM »

I struggle somewhat to get a more advanced camera going, that needs to change how fast and loose it follows the player (I want this based on distance, but possibly also on other parameters). Smooth Follow Action works fine, but it always snaps into place.

I tried also the following: I created a game object, called Shadow which uses Position Smooth Damp. I get the distance to player, substract that from a value and feed this as the smooth time. In other words, the greater the distance, the faster it will follow. The shadow now follows the player in a rubberband-like manner. The further away you go, the faster it will try to catch up.

I set the camera to Smooth Follow Action, and another time also as a simple child (for the offset) of this Shadow object, rather than the player directly, which gets me somewhere near what I want. The problem is that this creates the typical Non-FixedUpdate jitter, in whatever variant I tried.

Maybe there are other ways to get what I want which is: divide the screen into three parts vertically, A|B|C. When the player is within B (the middle section), the camera is supposed to relax and move slowly. When the player moves towards either A or C (towards some threshold, A|B or B|C) the camera must speed up and basically lock onto the player as long as they run in this direction. Ideally, it's possible to "lock" into the player and release gradually by float.

If you have any idea how I can build this, or any pointer what I could try, I'd greatly appreciate it.

Playmaker Help / Re: Jumping character controller
« on: September 16, 2017, 08:50:33 PM »

You could try rigidbody setup plus set velocity (up)? I recall I'm using this, and it works well (cannot check at the moment).

Note, the setup below is a bit fancy. You technically only need a button press, set velocity (passing through the state, finish) and back. The gravity takes care of it. But you probably want to polish it up, and have falling and landing etc.

The setup I build works like this: The first state listens for button down. I also get velocity up/down every frame. Also, every frame compare this float whether it is below zero, give a bit of threshold. If so, it means the character is falling (goes into a falling state).

On the state after the button, set the velocity. It only passes through that one. Afterwards another velocity/compare state like at the start, to detect whether the character is still rising. If not (velocity is negative), move into a following falling state. I use a different one there. I think I again do the velocity/compare pair once more, this time, waiting for velocity to be zero or positive — because that means the character has landed on something.

This way, I also don't need collision detection or rays that detect the grounded state — but I don't know if this method is superior. I also have a few more details in there, like jump height based on button pressed, and I also add downwards velocity after falling, but that's choice (makes it snappier and better in my view).

Playmaker Tips & Tricks / Re: Workflow: Documenting, Commenting, Naming etc.
« on: September 16, 2017, 04:48:18 AM »
Thanks djaydino!

Incorporated your remark above, good point! And I added a few more that came to mind: Colour Naming, On-the-Fly Variables and Events, Generic Events and the Shortcut Method.

Playmaker Tips & Tricks / Improving The Workflow
« on: September 15, 2017, 12:40:30 PM »
It can be hard to keep an overview, once there are dozens of FSMs buzzing and sending events and variables around. There are also ways to make it easier, or more fun, to work with it all.

Here are a couple of workflow tips that will help you, or inspire you to manage your project and will help you staying on top of the ever-growing list of FSMs.

Renaming Actions
On Windows, you can press F2 to rename items (folders in Explorer, Game Objects in Unity, also paths in the animations, …). Did you know that you can rename actions, too? Place the action you want to use, then press F2 (or double-click) and rename it to something that gives you an idea what it does in your context. You can make the action list more intelligible and less abstract this way, almost like pseudocode. However, this makes it more difficult to see what the original action name was. Don't despair. Just hover over the little book icon and the tooltip tells you.

As pointed out by djaydino below, be mindful when working in a team. You can of course keep the action name, and just add to it, e.g. "Get Game Object: Player 1" or if it's obvious from context "Get: Player 1" and you have the best of both worlds.

Floating Labels & Headlines
This is more of a hack. States are also simply boxes with a name on it and a (possible) comment box underneath. You can appropriate them as a headline and paragraph, or as a floating label.

Place an empty state not connected to anything, and colour it (right click on state) with a colour used only for that purpose. That way you can tell these non-functional bits apart more easily. Now name them, and place them anywhere you like. You can add a kind of headline to functional parts of the FSM, for example.

Incoming Event
Let's suppose you have a state where you GET variables from somewhere else, or you read from a script. In other words, the FSM relies on incoming information. This is hard to see in the graph overview. How about using this hack in a similar vain as the floating label.

Create an empty state floating in thin air. Add an event like "Send Variable" or "From Script" to it, and connect it to a state which actually gets the variable from somewhere else. Colour both the state and the link, perhaps use the circuit link style to make it stand out from functional bits. Now you have something similar looking as a global event "coming in", but you can name the state and the event anything you like, and see clearly where variables are injected.

Tagging Nomenclature
I use some simple keywords I'll add into the states "description" field (in the State tab), like #Anim, #Send, etc. I use these to tell me straight away where dependencies are. I then see where, for example, animation events are send off. Short tags do the trick, and are fast and better to comprehend than longer explanations.

Global Events ALL CAPS
Global events are typically named uppercase. That way you can quickly tell them apart, and there's no issue with uppercase spelling (e.g. was it "turn on" or "Turn On"? It's "TURN ON")

Comment Action
Did you know there's an actual comment action? It's very useful to add information inside the states without cluttering up your graph.

Comment Action Dividers
Since you can rename actions, see the tip above, you can rename the Comment action into _______________, +++++++++++, ###########, ..................., ————————, ––––––––––––, --------------- and so on. Now you can structure your action list that way. Neat, isn't it?

Comment Action as Headline
Especially when you want to keep your graphs clean, you'll cram a lot of actions into one state. To still keep an overview, you can place Comment Actions, switch them off (just to be sure) and name them like /// EVERY FRAME /// etc. this way, you can group a block of actions with a headline.

Documentation URL
I haven't used that feature yet. However, the FSM has an option to include documentation right on the FSM tab.

Colour Coding
You can set up additional colours in the playmaker preferences and colour states and even the links (also separately). I sometimes succumb briefly to colour, but refrain from doing it, unless to draw attention to something. If every FSM looks like a rainbow, you have no clarity. Other users (see comments below) use them to differentiate whole groups of states.

Color Naming
You can name your colours and add new ones in the preferences, and that way determine more precisely what they mean. If you call the colour "WIP" (work in progress), you will probably use it consistently, and you will also see in two years what Red was supposed to mean.

You can switch on grid snapping which makes structuring and arguably grouping better. Obviously, you can move the states around and group them. Use this for your advantage. Arrange the states of loops close to one another, then leave some nice distance to the next functional block, that way you can keep a good overview even in one FSM that does many things. Forget about symmetry and other such superficial criteria. Think of the FSM to flow top-down, for example; or from left-to-right -- whatever serves your purpose.

You can also control on which side the link arrows come out, by selecting the transition, hold CTRL and then left/right arrows to lock them in place. While I am at it, CTRL+Click on a state creates a FINISHED transition. CTRL+dragging out the link creates a new state that's already connected to the transition.

Naming Conventions
You have a VampireEnemy, and a SlimeEnemy? It may be better to adopt a general-to-detail naming convention for your variables. EnemyVampire, EnemySlime, etc and they are listed next to each other. Using space seems to create no problem, like "Enemy Vampire"; no need for clunky_names. Commonly, variables are also typed like enemyVampire (first lowercase, then every new word attached, starting uppercase). This convention is interpreted in Unity Editor as separate words when used in scripts (enemyVampire makes "Enemy Vampire").

FSM Paths
Name your FSM for example "Gameplay/Jumping" and you'll see in the FSM navigation bar right above the graph view, how it is now tucked inside a menu point "Gameplay". You need to keep this in mind when referencing it.

Right click on the graph view and set a watermark. You can add your own graphics into the folder and use them. Depending on your game, it can give you another quick and visible bit of information. Differentiate game logic FSMs and those that are for UI or effects, maybe. You can mark critical FSM, or use it as a stamp to assign ownership of the FSM when you work in a team (alien-head means Alice is responsible for this FSM). Maybe your game has two opposing sides pitched against each other, with nearly identical FSMs: watermark the sides. Watermarks can also be coloured images. I use this to mark FSMs with player input (movement, jumping, controllers etc). 

Variable Categories
When you select a variable, you can also set a category in the variable tab. Categories you once typed in, appear behind the tiny arrows next to the input field in subsequent variables. That makes it easier to keep the categories consistent. The same tip as above: don't succumb to categorize just because you can. The most important categories you want to use is Runtime and Config. In Config, you put those variables that you need to adjust; variables that are given. Into Runtime, you group all the variables that are overwritten and used for computation when the game is running (where it is pointless, or even game breaking when you adjust them).

On-the-Fly Variables and Events
A small workflow tip. You probably noticed that you can define variables and events right in the action. You find the option in the small dropdown menu where you set them. Once you do define an events there, a red box is popping up, telling you that no transition exists with that event (since you haven't yet added it). If you click on this box, it will create the transition on the fly. This happens when you pick an event that has no transition yet, and it's the fast way to populate especially switches that call for great many events. If you ever want to define ten types of events to use later, stop right there, and mind this trick.

Generic Events
(Non-global) event names don't have to be unique. You can create new events for each state individually ("go to jump"), but you can save some time if you pick more generic names, like Do, Next, Done, Fail, True, False, etc. The state only cares about the events as set in it.

Global Event Tricks
When you send a global event to an FSM, it will find it, and induce the flow there, no matter where it is. For this reason never use global events for anything other than to specifically communicate "globally". But you can also use this inside one FSM. Suppose you anyway use a global event called "AWAKE". Instead of looping back with a link, you can also send AWAKE to this same FSM, going back. This might be useful when your FSM is large and you want to "jump" from one place to another. Watch out, though, it might be a sign that your design is too much spaghetti, and perhaps needs to be broken up.

Shortcut Method Do Once
That's more a design pattern. Many actions do their thing. Then they trigger an event when they are done, or when some condition was met. You can often times leave the events not filled in, say Float Compare, only care about whether the float is smaller, and ignore equal and greater. You can take advantage of this fact, because this is good shortcut. That means, when you place such actions further above in the list, and they get triggered, the rest of actions down below will be skipped.

For example, you want that the actions below are only triggered once. But the sends keep coming in, constantly retriggering the FSM. Place a bool test with a variable that stands for "did we do this already?" on top. If true, do event "Skip". At the very bottom or in a subsequent state you set the variable "Did we do this already?" to true. Hence, when the list was used once, it's set to true, and when the chain is triggered again, the bool on top will recognize this and skip the rest. Later you need to reset the bool to false again. Take advantage of this to create a short cool-off period of retriggering events.

Think Ahead
It can be useful to get a fresh beverage and open a simple txt editor and type out what you exactly want to achieve. What kind of elements do you probably need? Are there different ways to solve the problem? Can you make it simpler with less dependency? Also, think about what exactly your mechanic is trying to solve; what gameplay purpose it will have? It might seem silly, but you should think whether your platformer really needs jumping, for instance. Imagine seriously how a game would be like without that mechanic (this is also great to get innovative games). Consider also inverting the problem, if you cannot trigger something, can you untrigger it? You measure from player to obstacle, how about from obstacle to player? etc. Make this a habit, and you have some clarity when you approach the situation.

Do the Research
Unless you know exactly what you're going to do, check some resources to give you a good turbo start on the frequent problems; get a glimpse of what kind of variables you probably need; and perhaps even find detailed talks, papers or videos on such seemingly simple things like jumping or camera movement (here, here) in a platformer -- stuff that is going to put your game above the competition when implemented with some juice.

Perhaps this is useful to some people. :) Please add your own ideas, or comments below!

EDIT: expanded a bit, made some improvements to the text.

I have no idea what was wrong and am none the smarter. I now changed the setup around.

I wanted to use the trigger because I didn't want to constantly update velocity floats for the mechanim. It occured to me that I don't need to do that anyway. Instead of triggering, I set the float at desired times to (somewhat arbitrary) values and use that to move the animations to the desired state. In other words, the value might change constantly in the FSM, but the Mechanim can have it simpler and only needs to know once that velocity is, say above 5, to move into the correct animation.

In case someone wants to know how: when your character is jumping, set the animator float to, say "5" and then in mechanim the condition so that if value is greater than 4 to move into the desired animation. Simply space out the values to make jumping (trigger), rising (velocity is above 0.3), falling (below 0) and landing (above 0, but following the falling state).

Feature Requests / Re: Interface/Usability: State/Action Hashtags
« on: September 13, 2017, 04:27:35 AM »
That sounds like a cool feature. Though, it would also be cool to see certain things at a glance, in Playmaker spirit, rather than running search queries.

Playmaker Help / Re: Suggestions for good Speech Bubble plugin?
« on: September 13, 2017, 04:23:02 AM »
I think you could build something like that in Playmaker and with Unity's GUI system. If you don't have lots of variables, the standard Build String action will suffice. With lots of variables, it's probably getting unwieldy and if you can code, I'd suggest to invent a better Build String action where you can drop a block of text, and which can read and use variable text elements, i.e. use a string like this "$Character goes to $Place where $it $buys $item"  (resulting in "Alice goes to the shop where she buys icecream"). Look up Twine, for a general idea.

Once you have the string you want displayed, you have to get it on screen. For this, create a text element (Game Object > UI > Text). Place it where you can see it. Select it, and find the component where you can enter the text to display in the inspector. Now, drag and drop that thing to your FSM state, select set. This will generate an action to set a parameter. Pick out text > string, and then set your string value. There's probably a custom action to do this in the Ecosystem, or you can write one that finds the component and writes the string to it. That's preferable.

Sizing of the speech bubble etc can be done with 9-sliced sprites. Look that up, it's fairly straightforward and build into Unity. The placement of the GUI is a bit finicky, especially with different resolutions, but manageable.

Finally, you need some way to change the string around to say different things, which is straightforward Playmaker stuff. Finally, you need a bit of logic, perhaps in a different FSM to appear and disappear the speech bubble contraption. You do this by having it go to an empty state. Set up two global events, like "SHOW BUBBLE" and "HIDE BUBBLE" (all caps naming convention for global events), and when needed, Send Event action from somewhere else to show them and hide them. If this is literally periodical, you can build the timer right into this FSM.

Playmaker Help / FSM ↔ Mechanim (Set Animation Trigger behaves like bool)
« on: September 12, 2017, 01:26:34 PM »

TL;DR: I send a Set Animation Trigger to mechanim, but instead of sending only an impulse, the triggers appear to be on or off, behaving like bools. I ruled out that I accidentally set them every frame.   

Q1: You see the triggers are filled or "on". They were triggered once (correctly) after spawning, because the character drops down shortly. The states that send the anim trigger are passed through only, and marked with the exclamation marks. There are none on Ground.

Q2: Why keeps velocity fluctuating as you see in the screenshot despite that the character is completely at rest? (it seems to have no effect on gameplay, though)

EDIT: I found out that triggers work like bools, but are supposed to be reset when the animation clip transitioned. Someone over at Unity wrote this:

Quote from: User
... Use triggers only if you are sure the animation will play full, from begginig to end, before issuing another trigger...

Feature Requests / Interface/Usability: State/Action Hashtags
« on: September 11, 2017, 10:26:35 AM »
What does it try to solve?
Where did I trigger the animation? Where do I wait for input? Where did I use this variable again? Where was the FSM state that I wanted to improve? You know these problems. You have to click through FSMs which can be quite laborious, and you cannot see at a glance what's relevant for you.

The solution comes in several stages. The basic one is a solution, the others make the feature even better.

Basic: Introducing State/Action Tags. The user can #hashtag words in the State Comment, which are then searchable. That way you can instantly see, and find, whatever is relevant for you.

Improved: In the improved version, the hashtags on a state are added automatically, when certain actions are added to a state (and removed accordingly). The user has to switch on an option, and then determine somewhere which actions should automatically add the hashtag to the state they're in. It's probably unwieldy to maintain a huge list, so how about an input field that is directly next to the manual and options button at the actions (but once set on an action, it obviously counts for all identical actions anywhere). It's first blank, but there you can set the tag's name and a label colour. See my quick mockups how it could function.

Use Case 1: You have a few places you aren't quite happy with. You simply add #WIP to the state's comment field. Weeks later, you have no idea where you wanted to make improvements. Luckily, you can use the tiny search bar, type in # and it shows you the hashtags you have used, or you when you remember that it was #WIP, you can type that in straight away. Click through the list in the hamburger menu next to it, and quickly go to the correct state.

Use Case 2: Suppose, you have some FSM and you are interested to know precisely where stuff is sent off to the animator. This can be quite hard to see, especially not at a glance, unless you use colour-coding which can be quite cryptic. Luckily, Playmaker now offers automatic hashtags! You go to the options and switch them on. Now a tiny label icon appears right next to the manual and options icon on the actions. You go find just one instance, say "Set Animator Bool", hit the label button, where you define the tag and a label colour. Et voila! Now everywhere where "Set Animator Bool" is used, you see the labels appended after the comment (if no comment, at the same place).

Use Case 3:   Oh noes! You just cannot find any instance where you used "Set Animator Bool". No problem, just make a state anywhere, add the action, and then set the label. If you used the action already, they're now all visible. If not, fine, all future instances will be automatically labelled.

Playmaker Help / Re: How to fix a GUI update problem?
« on: September 11, 2017, 07:43:51 AM »
Can you make a video showing the issue and the fsms/states/actions?

Not possible unfortunately, though there is not much to see. The logic itself works fine. I know this, because the inspector shows everything as expected. They're active when they should, and inactive when called for. But the "Game" view is wonky. As written above, the moment I move the object holder, using the scene view/transform scrubbing, it will suddenly display correctly. So it must be something with the GUI update, canvas/drawing, that does not refresh properly.

It's an annoying problem, but not a show stopper for this prototype, so if there is no hunch or idea what I could be trying, I'll have to live with it and build it differently next time. :)

Playmaker Help / Re: How to fix a GUI update problem?
« on: September 10, 2017, 10:35:48 AM »
Here's a schematic version of this, where you can see the basic setup.

The de/activation are in the Show and Hide states. The Update one is basically empty, but I put there the force GUI update action, though it does nothing.

The logic itself works fine. Also the objects are activated and deactivated properly, according to inspector. It is just not always reflected properly in the scene.

Thanks for the reply. :)

Playmaker Help / How to fix a GUI update problem?
« on: September 10, 2017, 08:14:02 AM »

I have a holder Game Object, and as a child, a GUI text Game Object. The whole thing sits in the canvas, and generally works just fine. An FSM on the holder is constantly (loop, not every frame) checking some condition, and when the condition is met, either activates, or (via another route) deactivate the GUI text child. It's thus very simple. The loop either goes one route, and has it active, or the other route, and keeps it inactive. This also works correctly.

This object is a prefab and a few of these populate the scene, and they all work just fine. Except one, or two, occasionally, that are not visible (as if inactive) despite that they are truly are active, and are supposed to be visible.

What happens: The Canvas does not show it, or update correctly. I tried the "U GUI Canvas Force Update Canvases" action to no avail. Also, when I move the object a bit by hand during runtime, it suddenly correctly displays the actual state.

I could do something hacky like move the thing by a few pixels and see if this forces the update, but that cannot be a good solution. Any ideas?

Playmaker Help / Re: 2d RPG GAME / Player movement
« on: August 11, 2017, 01:02:55 PM »
The ART155 series can you rate the difficulty and does it has sample files?
i don't have time to watch the series, but i want to add them to the User Tutorials wiki page

I found it easy to understand with little (or no) beforehand knowledge. Some of the things he does are perhaps not the best way, but I found it an excellent starting point. When I remember correctly, there are no provided sample files.

Pages: [1] 2 3