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 4
Playmaker Tutorials / Re: how to make a timer and a basic turn system
« on: December 06, 2017, 04:35:47 PM »
Glad it's useful. Go ahead, and use this as you see fit. :)

Action Requests / Re: Camera: Smooth Follow Action + Distance Damping?
« on: October 17, 2017, 12:02:16 PM »
Didn’t know about it, looks fantastic (also that it is free now). I‘ll check it out. Thanks!

Hi and Welcome!

1) Large projects are always messy to some degree, in any engine or format. How messy depends on how well you structure, engineer and document it. You can over-engineer and it gets unwieldy, or you can throw it together and face spaghetti of dependencies all over the place. The trick is to find a right balance, which is however always different from project to project. Also see some tips how to manage.  Provided your Metroidvania is generally within the usual features, it's fairly straight-straightforward: a few FSMs for the player, one to move around; one to jump; a few for firing in different directions, projectiles, health etc. or two for each unique power mechanic. And maybe one or two for each monster, interactible item (doors etc) etc.

2) Storing variables should all work with various Playmaker techniques, such as global variables. Maybe you’ll need some light coding, like a data holder script (easy to do, for non-coders, too). It‘s just a list of variables, in your case mostly bools called flags, i.e. you have it, or you don‘t have that power. Enum flags might be one specific way to do this. I don‘t know exactly what’s the best way to store persistent data, but I know it’s a comparably trivial problem to solve. Also, Playmaker is fully compatible with anything else. You can simply grab some script that does it, and hook it up. The process in Playmaker itself is easy as well, with dozens of ways to it. You could conceive of the powers as game objects each, that are added or removed by one PowersManager FSM. Or they are all sitting dormant on the player until de/activated, or by using send events (waking them from their idle state).

I suggest for big endeavors to frontload some of the unkowns and risks. Like, build a craptastic version you will throw away, with a basic player, one power (a type of weapon); which you copy and paste a few times with e.g. different laser colours that open matching doors, and the basic unlock/pickup mechanic, plus two scenes to test. This gives you some insights how it might work.

Playmaker Help / Re: Exposing FSM Variables In A Custom EditorWindow
« on: October 10, 2017, 06:34:27 PM »
What you’re trying to do can be done with a simple data holder script, keeping the variables, and a custom action for getting and setting the variables into Playmaker. Though I agree, it would be more elegant if it was possible to customize how they are exposed in inspector, see here:

Peek into this, but don’t watch the whole thing yet, just know it exists :)

Here are actual tutorials:


General Discussion / Re: Tutorial: Custom Scripting 101
« on: October 10, 2017, 06:18:19 AM »
Hi Djaydino,

I am quite sure this is all second nature for you. I should add this is C# basics and Unity, not Playmaker related directly. It's good for people who are not entirely newbies with Playmaker, yet code newbies. Because when you use Playmaker for a while and slightly more seriously, you eventually want to know how to access scripts, and object properties, and things like that, hence it's good for beginners of Custom Scripting (I think).

Playmaker Tutorials / Re: how to make a timer and a basic turn system
« on: October 09, 2017, 02:47:50 AM »
Hi, good start with the tutorials. :)

The turn mechanic could be improved a little, and work without the every frame check. You can do this using global events, and send event.

Think of this as a chess clock which gives control to one player. The player does their thing, then hits the Clock to say "I'm done" and the Clock then "knows" what to do next. That is: give control to the next player. Using a Clock or Manager as a third party is a bit more robust, because then you can separate the taking turns rules from whatever is supposed to happen within a given turn. In a more complicated game, it can count up the int which stand for any number of players, for example. It can skip turns, or change the order etc. Thus, it's better to keep this mechanic separate in more advanced games.

If you really only have two players in a simpler game, you don't strictly need the Clock, because you then can start both players and let them run into an Idle / Awake state. One of the two continues to whatever they do in their turn, while the other is stuck in the Idle, going to Sleep. When the active player is done, it goes to it's Sleep state, but before it Send Event over to the other player to wake them up , to start chain of events. Now the other player's FSM runs becomes active player and does whatever it does, until done, go sleep but before Send Event over again to wake up the other player, and so on.

I built an example on the quick. Player Blue's job is to press the space bar, and Player Red's job is to press the tab, taking turns. You're correct that using Input Manager is always a good idea, but for debugging and testing I use the keys.

Playmaker Help / Re: Convert Float 0.00 to 000
« on: October 08, 2017, 06:28:12 AM »
For example,  ×100 Mulitplication. There might be a Convert Float to Int action somewhere.

General Discussion / Tutorial: Custom Scripting 101
« on: October 07, 2017, 11:01:53 AM »

I came across this small video series and found it super useful. It goes over stuff that is probably second nature to coders, but for us Playmaker people often quite obscure, especially when you transition to some light coding and custom actions yourself. Enjoy.

Playmaker Help / Re: How to: FSM to FSM Communication
« on: October 02, 2017, 03:41:21 PM »
Depends how do you want it to work and how scalable it needs to be. I have projectiles that deal normal/double/half damage depending on the type of enemy they hit, so i put all the logic in the projectile and pass the stuff to the object. It stores the collider in a variable and then manipulates the variable of the object hit (reduce hp/destroy) before despawning itself. Of course, it all occurs over two frames so it's basically at the same time to the human eye.

I have modular system, with is a game object with a FSM "Health", which waits for a global event. A projectile, on hit, will look for the Health FSM game object, then send over the damage, and right afterwards set off the global event in the Health FSM, which starts it.

Within that, it copies over the damage from the incoming variable, and empties the incoming bin. The damage (or energy, because I also use it for healing, damage is minus, heal is plus) is then computed in the fsm, substrat from current HP, and if below zero triggers the Death. It works neatly, so far, but I still look for something more than "it works".

Even more detail, see here.

I wonder if there are objectively some best practices on the general problem of FSM/FSM communication.

Playmaker Help / How to: FSM to FSM Communication
« on: October 02, 2017, 02:23:37 PM »

Despite that I have built quite a lot of mechanics with Playmaker already, I still feel unsure about the FSM to FSM commuication, which is an increasingly common challenge.

For example, creating a new object and passing variables to it. What's the best way to go about it? Are Send Events always fast enough to ensure the variables are set in Start state? Or should you create the object, have Start run empty (or only do configuration that are self-contained), set variables, and then trigger a global event to really set it into motion?

Another example: When a projectile hits a target: what's the best way to do this? Is it better for the Health FSM to be hit, then get projectile information, or is it better that the projectile hits an object, and passes its variables onto the object? Or some combination thereof?

Are there any good tricks that make communication between FSMs less complicated? A rule of thumb or something of the sort?

I also ask because I've seen many different tutorials and even more ways how this can be done, but none stick out as clearly superior. Any pointers, and reasons?

Playmaker Help / Re: Show Variable in Inspector on Play Mode
« on: September 28, 2017, 07:38:13 PM »
Not sure I understand this. Why would you want to expose variables dependent of state?

1) You can tick a tiny checkbox called Inspector at the variables tab, then these variables are exposed to the inspector in the respective FSM component.

2) there is also a debug variables mode in the FSM editor, which shows you the variables as they currently are at runtime (in play made) per each action.

Playmaker Help / Re: Simple Get Key Down/Up fsm?
« on: September 28, 2017, 07:30:27 PM »

Try this. Make two events called pressed and released.
State 1, Press A: get key down, A key, goes to pressed event.

State 2, Release A: get key up, goes back to state 1. Not sure, but check also key pressed, if false then also go back to state 1.

1) First watch the FSM. Does it go to the proper state when you press A and release?

2) Now, you can animate the key with a usual animation clip. The is also the new timeline feature. You can move it by smooth transform, with actions like move towards, itween move etc. As a tip, use two empty invisible GameObjects, give them a gizmo icon (inspector top left when selected) to mark the two positions, then your thing can move towards one and back to the other, advantage you can easily tweak the positions by moving your start/end points around. You can also note down the vector (start/end position) and set this in variables. And finally, you can move stuff with physics, add velocity, add force, change gravity etc.

3) Once more, be aware of Input Manager. Same principle, but you use Get Button etc instead of key, and you assign the keys/inputs to your buttons in the manager. Depends on what you try to do, as always. If you have only keyboard, and it is straight forward, go ahead with keys. If you have other inputs, alternative layouts etc, use Buttons.

Playmaker Help / Re: Looking for feedback on setup
« on: September 28, 2017, 07:06:12 PM »
Not sure, depends on what you are trying to achieve, and the actions. A few FSMs for player control alone are typical.

The Input One seems wonky.

What you should check is whether you use get key down or get axis & get button down. This is often wrong in tutorials. And the get key down action probably should warn new users to strongly consider  get axis & get button down in combination with input manager.

Quick Help: in Input Manager (read), you can bind keys (also several) to a button name or axis name. In the FSM you simply use get axis or get button (down), with the exact name of one button as defined in Input Manager.

The principle is the same as key down, almost. The main difference is that you have all inputs in one place, and you can setup multiple inputs rather easily (you can duplicate button entries with CTRL+D too, just like GameObjects).

The name of the input should be short, and descriptive. Jump, Use, Attack, etc. Case sensitive. In the FSM you use those names, in the Get Button Down action. Then, you simply bind keys/buttons/joystick/controller whatever to the inputs. If you want to double them, no problem. You can have a Jump entry several times, one for keyboard, one for controller etc.

Try also YouTube, and normal tutorials. You can skip the code part, or get a sense of how the logic works, which can help to adapt it for Playmaker.


General Discussion / Re: Enum Creator wizard for non coders
« on: September 24, 2017, 05:40:58 PM »
Wanted to add a bit of what I found out, and which might be useful to other coding newbies.

The Path
The enums, like other definitions are stored away in a specific path, which is visible when you create the enum in the FSM, and when you set the Enum Type (which is "Days" in the example above). You can sort this neatly with a namespace. This is simply a bracket around everything, like this:

Code: [Select]
namespace Gameplay.Enum {
         >enum days stuff here<

Gameplay.Enum and then the Enum variable is pretty much like a path like Gameplay/Enum/Days. You can call these any way you want, and create the path the way you want. This example will produce Gameplay > Enum > Days (nested twice) in Playmaker. Try this somewhere to get an idea.

It makes sense to do this, when you have several enums, and to keep a bit of order. You can also group your other scripts that way. Just put the namespace bracket around everything and it's sorted into the menu entry. However, you then also need to reference the path correctly. So when do this to your own NPCdata script, you can access it with Gameplay.NPCdata (Gameplay can be any name you want). Or Gameplay.Enum.Days etc.

You can also put it into a class. Classes have the same path structure, but don't produce a nested menu entry. Say, you have namespace Gameplay, then a class Enum, and then your stuff, you get again the menu Gameplay (as before), but this time, the specific enum looks like this "Enum+Days". So if you see strange errors, try to figure out the path, and it might fix it.

Enum in Data Script
See MdotStrange's tutorial on simple data holder or interface scripts (there are a couple of good ones).

I found it confusing first and had lots of erros when I tried to add enums to my custom data holder scripts. But it is actually simple: Once, the enum is defined, you make use of it by treating it like a custom variable type. Let's say you use the namespace snipped as I shown above (and no class) then all you need to do is place this in your variable list.

Code: [Select]
public Gameplay.Enum.Days currentDay;
I know, it looks weird for non-coders at first. But this is really the same principle as public int myNumber. IN other words, Gameplay.Enum.Days is like your own variable type, and currentDay is the variable name in the current context. Once you place this in your script, you get a drop-down list with the enums in the editor. To get or set this to the Action, you simple refer to the variable like this public FsmEnum currentDay; i.e. like all the other variables.

In other words. Somewhere (same file or another), you define the enum type(s). And once they exist in the Unity context, you can use them like your own variable types.

Changing Enums
Behind the scenes enums are integers (int), where in Jean's example Sunday is 0, Monday = 1 and so on. The names are simply counted. When you delete Wednesday (which was at the 4th position, with zero), then Thursday slips down from 4 to 3 internally and all your references are screwed up.

Code: [Select]
0 = Sunday
1 = Monday
2 = Tuesday
3 = Wednesday
4 = Thursday
5 = Friday

when deleting Wednesday, becomes...

Code: [Select]
0 = Sunday
1 = Monday
2 = Tuesday
3 = Thursday
4 = Friday

Now 3 refers to Thursday and everything that referenced Wednesday now point at Thursday, everything that pointed at Thursday now points at Friday etc.

It's thus better to not remove or add within the list (only to the end), merely replace. You can also manually assign the ints to enums, by simply writing Sunday = 0, Monday = 1, etc. When you then delete or rearrange the list, the numbers stay the same, and are not reassigned.

Enums as Flags
Last thing. Enums can also be used as flags, which allows to assign multiple categories (instead of just one drop down list), say your character has multiple attack types, not just one. The keywords to search for is bitwise and enum flags. Here's an article for this. There's are cheap assets that provide basic scripts on the Unity Store for this.

Hope this is useful for someone ;)

Playmaker Help / Re: Two Player
« on: September 24, 2017, 06:53:59 AM »
Hey, i'm trying to make a two player split screen game that only works with controller but the problem is whenever i try to move them around they both move at the same time can anyone help me with that?

As Rabagast said, probably the same controls assigned twice. Also, be sure you use Unity's InputManager which can be easily overlooked. You assign the controls there, and then you refer to buttons by the name you gave them. You should probably do this each for both players.

Pages: [1] 2 3 4