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 ... 10
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.

Playmaker Help / Re: Double-click detection?
« on: December 17, 2018, 03:07:43 PM »
Check Ecosystem first.

Probably not ideal, but working example. First state, listens to mousclick, goes to a new state, which has a wait action on top that goes to Finished event. Underneath the wait action, it also listens for a mouse click (which would be the double click). The wait timer must be extremely short, and when run out, it’ll go back to the first state. Thus, only if you click twice, fast, it’ll register.

What happens is that you reach the second state only on mouseclick, but it stays in that state only super-briefly, so only in that brief moment you can click again, i.e. double click to proceed.

General Discussion / Re: Playmaker or Bolt i've done the search already
« on: December 15, 2018, 10:13:56 PM »
Ease of use

I think Playmaker wins this one. It uses a state machine approach, which is intuitive to grasp, more than scripts. It still uses the same concepts and is made of mini scripts (called actions). This also allows you to write your own in C# and transition into coding. The tradeoff is with the last point.

Tutorial and General Help

A lot of walkthroughs and tutorials exist for plenty of game genres and mechanics, on YouTube. The forum is helpful, and you can also get extra actions and templates from the Ecosystem.

Possiblity to build a game completely in Bolt/Playmaker

Depends on the game and what you mean by “completely”. In spirit of the question, I’d say generally yes. You can make the game mechanics, i.e. what gameplay scripts would normally do. Most people use several assets, for all kinds of purposes, multiplayer, audio managers, AI etc. That’s stuff you would normally not code or are also advanced in code. Playermaker works in play mode, so the whole area of editor scripting and tools etc is outside of the scope as far as I know. It’s also less ideal when you want to realize a big RPG, where you want to derive classes and manage tons of data, though there are even Playmaker solutions for this, like DataMaker, which is an addon (PM has addons, too).

Speed of Prototyping

Good, and manageable learning curve, but again, it depends. The tradeoff is this: you can make relative advanced mechanics and whole games with Playmaker, that’s very nice. I remember that I figured out a grapple mechanic fairly quickly, where I would otherwise trip over syntax for days had I tried to code it on my own — you just don’t know what is wrong, your idea, or because you made a stupid syntax mistake. But that advantage is moot when you plan to play around with very common elements where you can as well copy paste scripts, and learn to code right away. There are tons of scripts for conventional genre mechanics, so in those cases I say, skip Playmaker and script right away.

General Discussion / Re: Is there a loop action?
« on: December 15, 2018, 12:08:24 PM »
What would this action do, exactly? You can create program loops (foreach type) easily by simply connecting events in a circular manner, and each time pick another item from an array for example (by adding +1 to index, as you’d do in code).

Pages: [1] 2 3 ... 10