How to hook up alternative Player inputs?

Pulp
1

I’m interested in using the device’s change in orientation as an input for player movement. I see that there’s an event parameter for orientation; I imagine something like the player going from “standing up” to “on back” and back to “standing up” as the same thing as pressing the d-pad’s up button and releasing it to move the player one tile up.

I don’t see anything about player directional inputs in the PulpScript documentation, where can I look to get started on this?

2

Dpad input can't be triggered in pulpscript, but it is possible to replicate what it does.

  • Determine the target tile's coordinates (+/- to event.px or event.py depending on intended direction of movement)
  • Get the type of the target tile using type x,y

If sprite tile:

  • Call interact on the target tile

If item tile:

  • goto the target tile
  • Call collect on the target tile

If world tile:

  • Check if the target tile is solid using solid x,y
  • If not solid, goto the target tile
  • If solid, call bump on the player

The other half of the problem is getting orientation changes to trigger the above pseudo-movement. There isn't a player event that gets triggered by accelerometer/orientation changes, instead you can look up the accelerometer and orientation members in any event.

Triggering your pseudo-movement only when the orientation member changes seems pretty simple and workable. The loop event is called on the game script every frame. You could get the current orientation, compare it to the previous orientation (that you assign to a variable each loop), then if they are different convert that into your intended movement.

Hope that helps! Sounds like it could be an interesting way to play :slight_smile:

1 Like
3

It's a shame there isn't a command to simulate a DPad button press - that would make alternative inputs a bit easier to code.
But here's a version of the default pulp game with added crank movement - crank fast to move horizontally and slow to move vertically.
Unfortunately I had to hard code the exit, which makes it less useful for bigger games.
Pulp Crank Move.json.zip (3.3 KB)

4

Yeah unfortunately while making something for folks who wanted a simple way to make a game, Pulp still gets complicated if you want to do anything other than very narrow vision of what the game could be.

If you search the forums, what you find is a lot of us using programming knowledge (which I assumed was something that Pulp was trying work around requiring) to try and cheat things into Pulp.

Best idea I had to simulate this was trap the actual player in a box where them attempting to move in different directions via the d pad causes a separate sprite in animate.
You can use the dx and dy coordinates in the update event to get the info on what's going on.

I have no idea if this will actually help you though, and trying to do this turned out to create more work for me so I gave up.

the d pad will always try to move the player, and other than handling all movement, they dont let you single out specific d pad directions.

Pulp seemed to be a quick game creation tool for folks who aren't great programmers, and just wanted to make something quickly, but it's so limited that unless you only want to do the bare minimum (have a character move around and text pop up), then you're going to have to do some programming.
I felt like Game Maker ran into this very same problem as well, where its GUI based creation was still complicated enough that you might as well just code everything.
My own main project is full of lines of loops and conditionals and hardcoding all just to get stuff working that doesn't seem like the intended behavior from Panic's Pulp team.

I hope they update it in the future to be easier to use (not just simple, but also easy to implement slightly complicated stuff).