Shake Screen depending on variable
-
Let's say I want for screen to shake when some enemy boss lands on the ground after big jump, and as player's character is standing closer to boss the stronger is screen shake.
I know I can make several distance conditions, but it would've been really good if you (hyperPad devs) would change shake screen strength setting from slider to data input (like "if" behaviors), or let user choose between slider and input mode.
(screenshot showing current Shake Screen behavior) -
You can move the camera, very quickly, and move it back, also quickly, which has exactly this effect.
The other advantage of doing it this way, you can mirror the movement of the monster, rather than a random shake, it's relevant to the movement of the monster shaking a "ground".
Set the camera to focus on a proxy object representing your monster, and move it how you see fit to get the shake you want, when you want, with fades of movement (curves) to bring it back to where you want it to finish softly... like the camera is being progressively stabilised.
-
Hm, interesting technique. Gonna try this on. Thanks Deeeds.
Still, I think hyperPad needs more input-boxes, it adds new possibilities of coding and can also save time. -
@andrey-ghost hyperPad has a unique, unused advantage over other visual code editors... it goes top to bottom, left to right.
Most others go left to right, and push complexity into the y - axis.
With hyperPad's down-to-do approach, they could put visual inputs on the left of behaviour nodes, and outputs on the right (where appropriate) so data could be passed in and out visually.
Which would be amazing.
And they could add an Undo to the behaviour editor ;)
-
@deeeds Some people have swear jars. I need an undo in the behaviour editor jar 😂
-
@aidan-oxley 🤣🤣🤣🤣🤣🤣
-
@andrey-ghost Just to add muddle... here's another way of doing it, without a proxy object.
This has a huge benefit, the size of the camera shake is determined by the velocity/power of the impact. So it feels more "real" and has natural variance in accordance with what's going on in your game.
This has a bit of a flaw, in that there's often some drift in this, that I've never managed to track down the origin of, but it does work. It takes the collision impact, which is off the screen above the broadcast... and does the following:
-
@deeeds Thanks again, but don't you agree it would be convenient if there just would be an opportunity to input data in Shake Screen behavior? There are also some other behaviors that may need input data.
-
@andrey-ghost absolutely agree.
-
What I'd like to eventually introduce is to change all sliders to be input fields with a slider option.
Just having come up with a good UX to achieve this with out overloading the UI. -
This one is easy.
Get rid of the slider. The slider provides no benefit worthy of what its usage requires be removed.
Swap it out for a mechanism exactly the same as how Duration is chosen and set.
Done. Go have lunch. Take the rest of the day off. You've earned it.
-
@deeeds but I like sliding my finger on the screen. Its fun.
-
-
@aidan-oxley That's why there should be an option to choose between slider and input field! :)
Also, IMHO Aidan you're to cruel with your signature there. I wonder how much time in sum people have wasted on reading it. Maybe like.. 5 minutes :P -
I would personally use input fields, but for say a new user just trying to make a simple game, a slider might be more convenient....
