Very infrequently, I've not yet joined the server for playdate/pulp. Definitely more of a forum than chat person I'm afraid!
Introducing Tile Hill - a tile-based sort-of-side-scrolling proof-of-concept platformer in Pulp!
I adjusted the jump curve to feel more natural, and made the jump height with the A button depend on how long of a run up you take. The B button always does the smallest jump so you can still hop at speed. Also - semi-solid platforms!
I added slopes that can be run up-and-down. You can also press down to slide down a slope!
Spikes are, naturally, deadly to any platforming hero. I also made some circular saws which aren't in the demo but are in the editor - the difference is that spikes are only deadly on vertical collisions, but the saw is deadly from any direction.
Finally I added springs. They preserve vertical velocity, so you will bounce off them up to the same height you fell from.
Here's the JSON if you'd like to play with it and see how it is put together
Tile Hill.zip (7.4 KB)
You're doing fantastic work here!
A Doodle Sketch toy - draw with the d-pad and wipe clean with the crank (that is, for all my artistic ability, supposed to be a playdate )
A sneak peek of Pulpino - an even tinier in-game editor made in Pulp!
Moving the cursor "off-screen" makes the HUD show in the editor, but the B button also quickly cycles between tools and the crank will change selected tile. Docking the crank switches to game mode (and undocking it back to the editor).
Not sure how far I'd like to take this. Adding more tiles, certainly, and a HUD for changing rooms on the left. Maybe text input would be cool! I'm not sure how feasible actually saving creations will be - it'd mean a store variable for every tile I guess, which sounds painful!
Edit - and here is the move tool and switching rooms:
Pulpino is now close to something-like-v1...
The objective of any level is to collect all of the floppy disks and get to the computer. As well as solid walls you can place ice (the player slides in the direction of movement), conveyor belts (they move the player in their direction of travel), switch blocks (that are either solid or non-solid), and switches (that are triggered when the player stands on them).
The biggest downside at the moment is not being able to save any creations between play sessions. I'm not sure if there is a good approach to that other than recording every tile in every room...
Nice work on Pulpino so far! I really like the interactable objects and the slide-out menu design.
(Also, you may already know about this, but there is a tool called Pulp Mill that allows you to translate Pulp .json into Lua, so you can work in some saving/loading functions that way)
Using Pulp Mill so I can handle saving/loading in Lua is a very sensible suggestion, but I worry it would compromise the entire concept of making an even smaller game editor in Pulp if it isn't really all done in Pulp. I'm in a corner of my own making
I've got to the point with Pulpino where I really need to test out the performance on an actual Playdate - the only problem being I don't have one yet!
Would anyone lucky enough to have a console be willing to test out the pdx for me?
I'm specifically interested in:
- General in-editor performance (due to drawing the HUD)
- Using the bucket tool, especially when filling large areas of a room
- Using the move tool
- Saving and reloading, especially after making changes in all rooms (using the move tool in each room would be a quick way of making sure all of the tile values have been stored)
I suspect the bucket and move tools may have problems. I really hope saving doesn't!
Here is a zip of the pdx: Pulpino.pdx.zip (156.4 KB)
Edit: A couple of kind people over on discord have tried it out for me. As suspected the bucket and move tools noticeably struggle, reportedly taking 3-5 seconds to process, which is unfortunate but not world-ending, and otherwise the performance sounds ok! I'll see what I can do to improve performance, although it might have to wait until I have my console so I can test first hand.
You could try putting it through the Pulp Mill!
can i use this to make a game?
From that demo, go ahead!
Would love to see what you come up with
@orkn do you have a playdate yet? Do you still need someone to test this?
I love your solution for smoothing out the player movement, thanks for providing that demo!
How did you get the player to smoothly move behind tiles? I've been using hide for that, but when moving smoothly the player is drawn above the tile as they exit. It doesn't look great, especially when walking between two tiles hiding the player, since the player pops up briefly moving between the two. Any pointers would be appreciated if you have the time, thanks!
Bumping this with some Resonant Tale progress!
This is a sub-boss in the first dungeon. There are a few different mechanics going on:
- When you step into the room the door slams shut behind you, trapping you in.
- When you approach the key it disappears, triggering the sub-boss. I trigger both this and the door slam with an item tile that is identical to the floor in appearance but on collect calls an event to say it has been collected on the room. That makes the item tile reusable and keeps the room specific logic inside the room script.
- I made quite a bit of use of both
play ... thenand
wait ... thenfor timing events.
- The boss requires the player to attack the correct (non-jiggling) pot. The others explode which damages the player - I have a generic event for an explosion happening at some coordinates that will trigger an "explode" event on the adjacent tiles as well as damaging the player and I re-use it for the player's bomb item they get later in the game.
- Once the boss encounter starts it is on a timer to re-randomise the pot locations (I called each randomisation a "round" of the boss). I had to account for the round being ended by the player attacking the correct pot and make sure the timer didn't prematurely end a new round that had just been started manually by the player.
- The pot locations are randomised! This is the big one. I wanted the pots to appear randomly anywhere in the room each round, but never in the same location as each other or the player. This isn't as simple as it sounds given Pulp's limitations!
All pulpscript has is a
random function that returns a random integer between some min and max values (inclusive). After a bit of thinking what I realised is that, if you have a room where the possible x coordinates go between
x_max, and the player is somewhere in the room, you can use the
random function to randomly get an x coordinate that isn't the player's by getting a random number between
x_max - 1, then comparing it to the player's x coordinate and adding 1 if it is equal to or greater than the player's x coordinate.
min_x = 9 max_x = 15 tile_x = random 9,14 if tile_x>=event.px then tile_x++ end
Maybe this is obvious, but it was an "aha!" moment for me!
Unfortunately with three different pot locations to randomise it got a little more complicated. For each subsequent location I had to reduce the max in the random range (essentially you reduce it by however many values you already have occupied), but I also had to recursively check if my random value was equal to or greater than each of the already occupied coordinates. So the first pot has just the one conditional, the second pot has a top-level if/elseif with a nested if in each, and the third pot has a top level if/elseif/elseif each with a if/elseif in turn each with a nested if. I can just about accept that, but randomising the locations of more than 3 objects and some kind of refactor would be necessary - exactly how I don't know!
Anyway I hope some of that was interesting and I will endeavour to actually get the game finished!
First of all, this might be my favorite thread here. I love all your prototypes and also every bit I’ve seen from your ‘main’ game.
Regarding the scaling up of randomized tile placement, couldn’t you just check for the type of tile that is at the random coordinates.
I.e. if it’s a world tile (which means empty) place the pod, if it’s a sprite (there is already a pod at the coordinates) choose new randomized coordinates?
Yeah for sure, this would work. What I don't like about doing that is it has no upper bound on how long it might take - if you have quite a small/busy area so the chances of clashing locations are high, or just get unlucky, you could be looping several times each time getting a new random coordinate and then checking if it is free. This could - theoretically - go on forever! That's probably not a particularly big concern, in most situations including this one I think the chances are very good you will very quickly find a free location, but the uncertainty bothers me. What I like about my approach is that you are guaranteed to only have to call
random once for each object.
Yes, please endeavor to do so!
Forget the above - why write elegant code when you can just brute force things!
I quite like how this warp effect looks. The code on the other hand...
on collect do ignore wait 0.25 then pdx = 0 pdy = 1 wait 0.25 then pdx = -1 pdy = 0 wait 0.25 then pdx = 0 pdy = -1 wait 0.25 then pdx = 1 pdy = 0 wait 0.25 then pdx = 0 pdy = 1 wait 0.2 then tell event.room to call "warp" end pdx = -1 pdy = 0 wait 0.25 then pdx = 0 pdy = -1 wait 0.25 then pdx = 1 pdy = 0 wait 0.25 then pdx = 0 pdy = 1 listen end end end end end end end end end end
I think we should coin a term for this kind of common pulpscript pattern - I like "apocalyptic", because at the bottom of the event is the end of all things
A new game "camera pan" intro (excusing the placeholder title text):
This uses 3 rooms (title screen, full screen beach, beach with black HUD background) - the "pan" is done with
config.follow and changing the center Y position, with the water tile as the overflow. Much simpler than using
draw (which would probably have performance issues) or creating many rooms. I quite like the effect
(The pan in the gif looks slightly choppier because of how I captured it, but you get the idea)