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 ... 11
Playmaker Help / Re: Clamp Inverted
« on: February 12, 2019, 09:27:34 AM »
You need to specify what exactly happens with the -0.5—0.5 range in the middle. If you assume that anything between -0.5 to 0 counts as -0.5, you need to handle that case extra, and do the same thing for 0 to 0.5 (which might count as 0.5). If that’s the case. If you want a deadzone, then you don‘t need to clamp at all, but set the output variable to 0 if the value is between -0.5 to 0.5.

Playmaker Help / Re: Access to Input Manager?
« on: January 22, 2019, 10:21:35 AM »
whenever this question comes up, somebody points to the Rewire asset.

Playmaker Help / Re: Efficient Way to Handle Data In and Out of FSM?
« on: January 21, 2019, 03:55:15 PM »
With Set Event Data, Get Event Info, check the many posts and the example posted in this forum.

How you do this:

1) when pressing the pickup button (get button down), raycast in front to detect whether a box (the object to carry) is close enough. If so, store the box as variable. Later, this is used to move or teleport the box to the mount point.

2) Next, place an empty game object into your character’s hierarchy, where the box is being attached to, i.e. the mount point. Make it visible using the gizmo, put the box as zero transform under it as child, and move the mount around until it looks right. Now, you will run into a problem with the box’s rigidbody. Set the body type to simulated for now. You see, always try to achieve the effect “dry”, then you know what you need to automate later on.

3) Next, put the box back to the scene, change body type back. We now want to move the box from the scene to the bind point. This is simple in theory: after button press, and after the box is detected by the ray, in step 1, go to a next state. Here simply set parent the mount point to the box (as we did dry in step 2). Also use my action to set the body type to simulated. Also, reset the position, or set it with an action. You should now be able to pick up the box. For dropping it, you need to do the same principle, unparent it from mount, for example.

4) Next, you can do the cosmetics. You want to make the ray short, or make the character walk close, and before attaching the box, play an animation (you do this with mechanim, where you can also make a “carry” state with extra animations, transitions etc). This will conceal the teleporting/set position/mounting of the box.

5) Good luck. The full system, with some decent polish can get quite intricate. You also have to watch dependencies: what happens when you jump while carrying, die while carrying etc. Hope that helps.

Playmaker Help / Re: Sprite Actions
« on: January 06, 2019, 07:02:41 PM »
I made set order in layer, making a get should be easy.

Double jump, the simple version: in the jump state of mid air, add another get button down. With a more robust grounded system, see above, you check for isGrounded, and when jumping, you can set a isJumping to true. Then, in the airborne state, get button down, check if isJumping is true, to allow double jump. Reset the bools when returning to start state. No need to count jumps or anything like that, unless you plan for quadruple jumps eventually.

This system is fiendish, because you’ll find out soon, that it needs to do much more than you think at first.

The basic (but eventually too simple) double jump part or basic ground check is easy to do. In the jump state where you apply force (or set velocity), simple add another button down, and you can jump mid-air. To get back to start, add a system global event ON COLLISION. But that’s not enough, and maybe not the best way to do this.

What if your character runs off a platform. Then you’re not grounded, either. What if, you bump with the head into a platform above? The collision would think you’re grounded, even when you’re not. What is on slopes or bumping into a wall?

This is what makes it fiendish. You likely need a more robust system. You have a few options. The basic principle is that a separate FSM checks all the time, sets the animator and isGrounded bool. Other FSM read that when necessary.

(1) You can make a child game object with a collider that sticks out underneath (only) of your character. It could be a circle that is slightly smaller than the base circle collider, and slightly offset downwards, resulting in crescent at the base that can handle most cases. You can use on collison, enter and stay to be quite precise whether there is ground under the feet.

(2) You can also constantly cast a overlap sphere (see method below), to check for ground underneath.

(3) Generally recommended by many is the use of several rays. Like, three (downwards, and diagonal to detect slopes). Switch on the debug line to see where the rays are cast and fiddle around how far, angles etc. You can dial that in before anything else. Put them all in one state, fire them only once, and when any hits, go to new state to flip the isGrounded bool to true. If none hits, on finish, go to a state where the isGrounded is flicked to false. Then wire each through a wait state with a tiny wait time (like 0.1 real time), to return to start. It will tick away super fast, but rays are effecient, and should tell you exactly what’s going on. Use a variable on the wait time, which you can dial in later.

Playmaker Help / Re: Position ++1
« on: December 31, 2018, 10:36:33 AM »
If nothing else is affecting x, you don’t need n. Just x + 1, and set position.

Playmaker Help / Re: How to find Who killed who ?
« on: December 31, 2018, 10:33:42 AM »

1. When bullet spawns, get owner of bullet (the player).
2. When bullet hits, store player it hit.
3. Send both info over to a score keeper, e.g. using the event info, set event data pair.  Depending on mechanics, only when kill, every time etc.

Compute that data in the score keeper. Make yet another FSM that gets that data from score keeper, and updates the UIs.

Playmaker Help / Re: Make a 2d top-down Zelda game
« on: December 31, 2018, 04:24:56 AM »
You can have a 3D look, derived from 3D models, but bake them into 2D sprites. You can use 3D models, but 2D mechanics (colliders, triggers etc). You can use sprites (2D) and arrange them in 3D space.

You need to keep the graphical representation, 2D or 3D, apart from the mechanics. Then ask yourself these questions:

— where’s your talent or interest: 2D or 3D. Can you model, animate in 3D or better in 2D? There are also hybrids, like skeletal 2D.
— what are you trying to do exactly? Do you need 3D? (generally, a dimension fewer is a dimension you don’t need to worry about). If you want to use the third dimension in top down, you’ll have to worry a lot about camera movement. Keep in mind that Unity is never truly 2D. Even in 2D projects you can use height, i.e. distance from the ground plane in top-down.

Generally, YouTube is filled with Zelda 2D tutorials, and most (all?) I’ve seen are 2D like the original. Check the usual suspects, Brackeys, and Blackthornprod (he generally does 2D).

Playmaker Help / Re: How to Specify a Variable from another state
« on: December 24, 2018, 07:23:56 PM »
Usually, setting a variable means basically copying it over from another identical variable type. You just make the new variable, put it in the upper field (red), and then you set the source variable in the lower field. In code, it’s basically this:

Code: [Select]
int x = 1;
int y;

y = x;

Read, y “is equal” x, since equal was 1, y is now 1, too.

Playmaker Help / Re: Playmaker Timer
« on: December 24, 2018, 05:06:23 PM »
No idea how you do it, but simply reduce the variable(s), or multiply by a fraction (e.g. 0.2 = 20% the speed) before you scale.

Playmaker Help / Re: Blocking/ignoring events, rendering a FSM deaf[SOLVED]
« on: December 23, 2018, 12:55:33 PM »
Perhaps, global events should be visually distinct in some way, since Playmaker strives to be a visual scripting solution, but nobody’s stopping you from following the convention used by Playmaker, namely writing global events in ALLCAPS—then you see at glance what is global and local. The other rule is perfectly clear, events underneath are only triggerable during that state, and the events coming in from the top (global or start) always listen.

Playmaker Help / Re: Help with my Movement FSM
« on: December 22, 2018, 04:50:15 AM »
Hi, consider dedicated 8-way input actions like this one:

You can also toy around with my movement action (when you use both axis, you can try switching on has neutral on both):

Finally, my usual comment: unless it’s really a small game just for the internet, or to debug quickly, do not use key down actions. Use the input manager, button down and the two axis (“horizontal” and “vertical”) as proper inputs. They are mapped to wasd by default, but also the arrow keys, controllers and gamepads.

Try the 8 directional one above. If you want something more atomic, try my axis-down-to-button, here:

Playmaker Help / Re: Adding text Prefix and suffix
« on: December 18, 2018, 03:49:04 PM »
Use the build string action.

When you open the action browser, check “preview” at the bottom and look through related actions for what you’re trying to do, e.g. the String section.

Pages: [1] 2 3 ... 11