Bouncing Babies-like
It's been a while!
One of my hobbies is to tool around with various programming languages/engines. I'm not a developer by trade, but it's something I've done for 40 years now, ever since I copied BASIC games from David Ahl's BASIC Computer Games book. It's a great book that you should check out if you have any interest in vintage computer programming.
This summer I'm going to play with Pulp, the web-based game editor for the Playdate. It's a very light language, but there's a surprising amount of flexibility built in. One of the things I like to do when I start a new language is to port an old DOS game over to it. Usually I stick with text-based games, like a simple adventure game or hangman, because I'm not a graphic designer and it allows me to focus more on basic logic. However, with the monochrome nature of the Playdate and sprite editor in Pulp, making animated graphics is simple and straightforward. Below is a screenshot of my Bouncing Babies-like game Fire Rescue.
The gameplay is simple. The babies fall from the building and you have to use the trampoline to bounce them to the ambulance. It's a one-screen game with a clear win and lose condition so it's approachable to a hobbyist like me.
The first thing I had to do was create the player sprite. Tiles in Pulp are 8x8 and the player can only be one sprite (more on that in a future post), so it's tiny. For this sprite, I made a small "trampoline" with legs, just as a placeholder until I could make a bigger and better sprite. If you look at the screenshot below you'll see a few interesting things about the editor. It's pretty full featured, with paint and fill options, as well as mirror, flip, and rotate. At the bottom you'll see how simple it is to animate sprites. Simply add another frame, draw it, and it will flip through them at the FPS rate you determine. My Player has a simple two frame animation loop that makes it look like legs are opening and closing.
The next thing I needed to do was lock the player movement to specific locations, like in the original game. All game movement is set on a grid, as you can see below. The player is at (5,14), so deciding where I want to keep the player is pretty simple.
This is where Pulp is a bit different from what I've used before. All scripts have to be associated with the Game or a Sprite. Everything is global in nature, so organization is pretty loose (I've seen games put all of the code on the Player object), but I think I'll develop some best practices that work for me because I can see it getting confusing. The first thing I had to do was familiarize myself with PulpScript, the language Pulp uses. It's pretty straightforward and simple, which I like. Below is the code I use, attached to Game, that loads when the game starts. It sets the only positions the Player tile can go to, locking movement on a single line like the original game. There is also the intro splash screen instructions that explain how to play the game. As you can see, printing to the screen is as easy as typing "say" and putting in your text. The game automatically formats it and places it inside a textbox that players can advance through.
on load do // When the game starts
// set player positions
xPos1 = 3
yPos = 14
xPos2 = 8
xPos3 = 13
xPos4 = 18
// intro text
say "Get the babies to the ambulance" then
say "B moves left A moves right"
end
end
Then I need to implement this code, which is done below. I decided to lock movement to the A and B button because they're the only two needed to play the game (adding crank controls would be a fun next-step, but it's more complex than I want to tackle now). The code below moves the player right when the A button is pressed. There's similar code that moves the player left when B is pressed. All in all, it works pretty well.
on confirm do // when the A button is pressed
if event.px==3 then // if the player (px) is at 3 on the coordinate plane
goto xPos2,yPos // move to the next player position
elseif event.px==8 then
goto xPos3,yPos
elseif event.px==13 then
goto xPos4,yPos
end
end
The next step is handling the baby loading and falling. I also tied this to the Player sprite but may move it later. I created a new event handler called "babyFall" for this that generates a baby and just moves it down the screen. It's not optimized at all (a loop will be much better), but it works as proof of concept.
on babyFall do
tell 3,4 to
swap "Baby"
end
wait 1.5 then
tell 3,4 to
swap "white"
end
tell 3,7 to
swap "Baby"
end
end
wait 3 then
tell 3,7 to
swap "white"
end
tell 3,9 to
swap "Baby"
end
// code continues for a while after
So after a few afternoons of tinkering, here I am. It's not far, but Howard Scott Warshaw once said it took over 1000 hours to get an Atari VCS game from concept to the store shelves, so my 5 hours looks pretty good so far.
Next steps include rewriting the babyFall code and implementing collision physics with the Player sprite. I'll also add in a life counter and some beeps and boops for sound effects.