Orkn's Pulp Prototypes

Now the SDK is public I'd like to delve into it more, but I find myself with too much freedom and no idea where to start! I'm finding Pulp fun for more quickly prototyping some ideas - even if they aren't exactly what Pulp was intended for!

So rather than make a new thread for every half-baked and soon-to-be-abandoned idea I have, I thought I could throw them all in here :smile:

First up is a game called "The Tether Zone". A typically sinister governmental organisation has discovered a supernatural anomaly and is sending down test subjects to explore it on the end of a tether. It'll be a side-scrolling roguelite, with each attempted exploration of the anomaly another run - think sci-fi horror Spelunky. Each run would be contextualised and wrapped by a detached, direct-to-the-player computer system recording the results of each subsequent experiment - but that's getting ahead of myself!

Here is my first pass at the basic movement mechanics in Pulp:


As you can hopefully see it's side-scrolling with the player progressing ever further downwards, but the crank can be used to wind the player back in on the end of the tether (or to slowly lower them down rather than them falling).


Zelda-like experimenting:


The pots and push block will reset on re-entry. The key and door are permanent when spawned/unlocked. The block has to be pushed upwards for the key to spawn. The pots have a 1/3 chance of dropping a heart.


Not much progress to share yet, but the above has grown into a full game idea called "Resonant Tale". Here's a demo of bombs and arrows on the A and B button respectively - the sword is now used automatically when moving into things that can be attacked:


Neither bombs or arrows are being swapped into the game as tiles. Instead they are player tiles being drawn in, which lets them make use of transparency and means I don't have to worry about remembering what tiles they are replacing. I have some logic in the game loop for how they both behave. Arrows move one tile every other frame - I found that to be the nicest integer speed.



HUD, a few different elements, some very-non-final screens.


Something completely different, a finding the hidden number in some static by "tuning" the crank to the right angular range:



Woooow. I was seriously thinking about that today! Cool that you created a prototype already. I was still thinking how I would create this.

1 Like

@orkn You have off the wall minimalistic game ideas that are relatively simple to implement, and that is awesome!

1 Like

This is looking really great @orkn!

1 Like

Thanks all!

I'm sure this idea will be familiar to you @Guv_Bubbs - I went back to The Tether Zone and added some proximity lighting:


I can't wait to get my actual playdate and discover how unperformant all of my code is :smile:

Fun thing with the orb items you can see being picked up - because of the way I am overriding the default pulp movement, I also can't rely on the default collect approach to items. I actually ended up declaring collect to do nothing and adding my own event called pickup which essentially does the same thing, just obeying my movement rules!


This looks so cool. Hope you release this game eventually!

1 Like

With a little fiddly bit of animation trickery, I have smooth looking movement in Resonant Tale:


It's still tile-based movement, you're still moving on the grid, it's just smoothly(ish) animated as you move from one tile to another.

With Pulp running at 20 fps I had to play around with how many pixels per frame to move to get something that was both smooth and gives a decent movement speed.


Wow, willing to share how you did this? Does this require a separate version of every tile you walk on with the player on it as an animation or did you find a clear solution?

Fortunately not, thanks to player tiles supporting transparency. I'll try my best to briefly explain my approach (and maybe I'm missing a trick to simplify the animation!).

First I have a few variables keeping track of the player's position and direction, which is useful for checking when the player's position has changed and for making sure the player tile matches the direction.

Originally I was updating these at the end of the player's update event like:

posx = event.px
posy = event.py
pdx = event.dx
pdy = event.dy

However that was causing a minor bug as it turns out update is called before the player is moved when stepping onto an exit - event.px, event.py and event.room will all report the player's position when stepping onto the exit, not after being moved by the exit. I moved the position tracking to the end of the player's draw event instead to fix this (the direction tracking stayed in update as it is more limited in which events it is available).

Anyway, the reason that is useful is because during the update event I check if the player's position has changed by comparing my tracked variables and what is reported by event.px and event.py. If they are different I set a variable called player_moving_frame to 1 and call ignore. The variable flags that the game should animate movement (and I also use it to know what animation frame to use each game frame - more on that later) while the ignore is just to prevent any more input until the movement animation is complete.

I want my player to be animated at 2 fps, but because I'm going to be drawing some player tiles directly to the screen as frames I can't just rely on Pulp's fps config - I need to manually sync the animation myself. So in the game's loop event I have a generic counter that restarts every 20 frames (1 second):

if counter20==20 then
  counter20 = 0

Then at the start of my player draw event I have:

if counter20<10 then
  player_frame = 0
  player_frame = 1

Then I have my animation handling inside a conditional on player_moving_frame>=0.

Here comes the fiddly bit - the player tiles.

To smoothly animate I need to have 2 tiles animating together, one for the player "entering" at their new position and one for "exiting" their old position.

"Enter" is the easier half. As it's the actual player tile, I can swap it and then set the frame like this:

swap "player enter {pdx}{pdy} {player_frame}"
frame player_moving_frame

I have animated tiles set to 0 fps for all four directions and for both animation states. Those tiles have 7 frames each moving the player 1 pixel at a time further into the tile, the rest is transparency.

"Exiting" is more difficult, because rather than swapping the player tile I have to draw the exiting animation to the player's previous position. As far as I can tell, you can't specify a frame when drawing a tile. This means that instead of 8 tiles with 7 frames of animation each, I have 56 player tiles each with a single frame. I then choose exactly which tile to draw like so:

draw "player exit {pdx}{pdy} {player_frame} {player_moving_frame}" at x,y

Fear not - I don't actually end up using most of those tiles! Having them all lets you smoothly animate movement 1 pixel at a time. At 20 fps this felt too slow, so I ended up incrementing player_moving_frame by 2 every frame. Like this:

player_moving_frame += 2
if player_moving_frame>6 then
  player_moving_frame = -1

So for my animation I only actually go through frames 1, 3 and 5.

There were a few other fixes I had to do but that's the crux of it. I'll see if I can just cut out that code specifically and share the json so you can take a look, if you're interested!


Oh wow, so draw can actually draw transparent tiles too. I didn't know that. Too bad that the player exiting still has to be single tiles instead of frames. Still makes it a little hacky unfortunately. Let's ask if we can get frame settings support for draw! That will probably cleanup your code too.

1 Like

Here's a demo project you can import:

Smooth Movement Demo.zip (5.3 KB)

I made it so you can press A to toggle smooth movement on/off, and press B to cycle between different movement/animation speeds.


Thank you so much. Great example project! For now this is probably one of the cleanest workarounds possible!

1 Like

A little update:


I'm pretty happy with how the transitions through the tunnels look and with how smoothed movement looks with the player being hidden behind scenery.


love the little up / down the ladder animations !!

What do you mean Pulp wasn't made for side-scrolling platformers?


Scrolling Platformer Demo.zip (2.9 KB)

This was fun to work out! I tried to keep the code to a minimum and really lean on what Pulp already offers. It's certainly no Mario (shamelessly stolen level layout for this demo aside) but it's not unplayable!

The trick to "screen-scrolling" is in Pulp's follow config and using edge exits set several tiles into the screen to sew together multiple rooms with overlapping layouts. Then I simply used crop to add the black bars on either side of the screen to hide that room switching from sight! If you load up the json and comment out the crop command in the game script it makes the whole thing very obvious (and is actually a kind of cool looking effect).

The platforming is very rough-and-ready as the jump curve is less of a curve and more of a triangle, but hey the player goes up-and-down and it's not awful (ymmv!).

Unfortunately it seems the player confirm and cancel events for pressing the A and B buttons don't fire repeatedly when held no matter the Pulp config, so my idea for varying jump height by how long the button was held was scrapped. Instead I made both A and B do a jump, but the B jump is shorter!


Mind blown🤯

This feels like dangerous information for me to know....

Are you on discord @orkn?

1 Like