Scapia - dev log


We are working on a puzzle adventure game called Scapia. It takes place in a magical-medieval world with many areas for the player to explore. What started as a text-based choose-your-own-adventure game for my girlfriend is now a few months into production as a fully graphical Playdate game. I'm coding, she's doing the art. It's been a fun project with a huge learning curve for both of us.

We're excited to share our work so far! This is the first game we've made, so we're looking for feedback! Whether you have some advice or just a quick opinion to offer, we are grateful for your thoughts in the replies.

I'd like to highlight a few of my favorite features to start, and plan to go into more details on how these work in future posts. Progress will also be posted, as we are working on the game daily.


In this game, conversation is key. You can talk to people to learn about the world and progress the story.

This gif (below) where the player is talking to their brother shows how conversations are tracked independently. You can have many 'active' conversations with an NPC, and freely choose between them.

It also demonstrates side-scrolling text for longer player dialogue options. The scrolling here and in the next gif were not built-in Playdate functions, and were fun to write.


In this gif (below) is shown more dialogue, but with Dad this time, and showing the vertical scrolling associated with longer NPC phrases. I truncate with "..." indicating to the player it's a longer text than shown, and give the player a couple seconds to start reading the dialogue before scrolling.



In addition to dialogue, another key component of the game is the puzzling. I have an invisible tile system which tracks where things are in 20x20 pixel "tiles." These are used for puzzle logic, as well as for placing the pieces that make up the various puzzles.

"a chicken? huh?"

This gif (below) shows how the player can walk up to a statue, press B to toggle grabbing the statue, and move it around.

  • The player can only push or pull in the direction they're facing.
  • Moving orthogonally disengages the hold on the piece.



Thematically and literally this game has a lot to do with reflection.

  • Mirrors reflect the player at a 90 degree angle across the map.
  • Your reflection can do certain things you cannot, such as pass over small terrain that can't be walked over normally.

This gif (below) shows the most basic properties of reflection.



This gif (below) shows how:

  • the player can aim and toss a "coin" on the ground.
  • If the player's reflection ends up on top of that coin, the player can then teleport to the reflection.

This can be used to get the player over the aforementioned un-walkable terrain, and has other uses.


Thank you for reading my first post about this game! I'm looking forward to posting more, and hearing your feedback. I'm excited to get back into the code after a short break, during which I graduated school.

testing... testing... 1, 2, 3...

I also do not have a Playdate yet, though I expect to get one in this latest rollout (group 4). If anyone is interested in testing this for us, we'd be happy to send playable versions to you! I will include a pdx in a post soon so anyone on here can try it out and let me know what they think. Again thank you so much for reading, and thanks Panic for making the Playdate.


Neat conversation system! The font immediately made me think of Diamond on Amiga. Nice and big and readable!

FWIW, single-pixel lines cam often get lost on hardware, especially when the light isn't really bright. The Playdate screen is tiny! So the Simulator can be misleading in that regard. Sometimes just repeating the same art 4x to double the lines is a help.

(For example, that bird-statue is probably a lot more visible on hardware than the player character is.)

1 Like

really glad to hear that about the text, was wondering if the size was right. and with the conversation system I want to make a poor-man's Ink

thank you for the info about the single-pixel lines. I think we're going to make the main character art more salient, and this helps guide that. everything i've learned abt the playdate says "make it big" lol

1 Like

This looks cool, especially that mirror/reflection mechanic!

With the vertical scrolling text, it'd be more accessible to have that auto-advance as an option but also allow the player to advance the text manually at their own reading speed. It'd be equally annoying to miss the start of a conversation because it started scrolling too fast as it would to be reading ahead and constantly waiting for the scroll to catch up.

You might also consider not scrolling beyond the end of the text (both vertically and horizontally). There's no need to keep scrolling as nothing more is coming in to view, only moving out of it, and it delays the text scroll restarting. Especially on the horizontal text options I wouldn't want to be waiting for the entire line of text to disappear before it resets just so I can read the first word I missed, for example!

1 Like

While I'm pretty happy with how dialogue is starting to look, there are some obvious improvements to the dialogue that can be made.

  • Scrolling should be as player-controlled as possible.
    People read all kinds of ways, I was likely overthinking it by trying to average it out.

  • single-button scroll reset

  • considering pagination vs scrolling, which is kinder to the player?

I want to make dialogue as user-friendly as possible,
I really appreciate the thoughts and suggestions @orkn :pray:


Anecdotally I'd say pagination is much more common than scrolling, but it's maybe as much an aesthetic choice as it is practical and the look you have is pretty cool. This being a playdate game my mind immediately jumps to scrolling text (optionally) using the crank, which sounds kind of fun!

Anyway I don't mean to get you unduly hung up on dialogue, I look forward to seeing more of the game in general :slight_smile:

It's been a while since my last post, but I'm back with some exciting updates on my game for the Playdate! I finally got my hands on the device, and I must say, it's absolutely amazing. I've been glued to the screen, playing Bomber Panda endlessly.


As much as I want to bask in the joy of having the Playdate, I've encountered a critical error that's been causing some headaches. When I side load my game onto the device, it crashes after just a minute or two of gameplay. Even with sim settings (throttled and 16mb) I'm not crashing on my laptop.

My immediate goal is to tackle this memory problem head-on. To do that, I'm planning to reduce the number of sprites and active elements in memory. Additionally, I'm considering offloading some of the assets to storage, which can be retrieved as needed. This approach should help avoid overloading the memory and hopefully make the game run smoothly on the Playdate.

I've come up with an idea that involves loading the current room's elements as well as adjacent rooms' elements. By doing this, I aim to enable seamless movement of the player between rooms without maxing out the device's memory.

However, debugging device-only crashes has proven to be quite challenging. I could use some help from those who have experience in this area. If any of you have faced similar issues or have insights on how to effectively debug Playdate-specific crashes, I would greatly appreciate any pointers or advice.


Currently, I have some debug code in place, which I know I should remove before shipping. This code allows me to open a text file using"debug.txt", pd.file.kFileWrite), where I write debug output. The best part is that this information persists in storage through crashes, unlike console logs, which are not available on the device or after a hard crash in the simulator. If this is not a memory issue and could potentially be a segmentation fault or something similar, I'm hoping that tracking it down using this method might be the key.

Thank you all for your support and insights. Developing for the Playdate has been an exciting journey, and I can't wait to share more progress and updates with you all soon.


1 Like

Major Audio Issues

So while I am in the process of rewriting the game from the ground-up, I am running the game on-device much more often. I have found that the SDK audio library is much more capable in the simulator vs on the playdate.

I want to design really dreamy, fantasy-inducing synths. But the device crashes when even just a small handful of effects are used on a single audio channel. I played with this for hours yesterday and could not get a (imo, lightly) effected channel to play on the playdate without insta-crashing.

Remedies I'm considering

  • using recorded audio (as much as i'd rather use synths)
  • somehow utilizing coroutines to reduce CPU time for audio functions
  • shaving my head and becoming a monk with no technology
  • drinking more coffee, and just trying different things out

Post Desperately Seeking Answers

Here is a post about it I made to try to get some feedback on my process and other people's experiences.

Audio Bug Resolved

Bug fix implemented on Panic's side, (more info in the SDK Get Help post linked above) so I'm just waiting for that to see how far I can really push the effects. I love the synth tones, and the effects really bring them to life. Stoked to work more on the soundscape of my game. I've experimented with making nature sounds (much of my game takes place outside in a forest), and found myself listening closely to my surroundings for this project.

Songs and Playlists

I'm working on the structure of the music and music playing functionality in my game. Music is so important to a player experience. For my game, everything will be "playlists." This seems to be the most intuitive way for me to deal with music. Playlists will allow me to regionalize music in my game. IE: when you're in the country, you'll hear the country music.

Edge cases such as interrupts for special event-triggered music will be interesting but ultimately trivial I think. They will also be playlists, just of one song.

This allows me to loop, shuffle, or otherwise curate the music a player hears based on various world events. Songs can be discovered, or unlocked, and added to playlists to make the soundscape more rich as the game progresses.

Just a reminder that you don't need to wait for the bug fix to be pushed out by Panic. dave mentioned a workaround you can use:

A workaround for now is to drop the local when you create an effect that gets added to a channel.

So if I understand dave correctly that means you just need to ensure any effect is available globally in some form. So you could also just add them to some global table to keep them referenced. Example change to your music_player.lua file:

local song_library = {}
local playlist_library = {}
effects_library = {} -- no "local" to make sure the workaround works

-- then when creating your effects
local bitcrush =
table.insert(effects_library, bitcrush) -- this makes sure there always is a global reference to the effect
1 Like

an effect library might be a good idea regardless. hadn't thought of that, I've just been making them as needed for each song.

@NPException thanks! :pray: