Invert World - Devlog/some help needed

Hi all,

I think I'm almost finish with my first game demo but I have no device to test on and I still have a few outstanding bugs. I came up with the idea for this game while reading through the Playdate SDK documentation, the drawmode made me think I can easily create a game where the main mechanic would be inverting the world. Hence the name of my game.

Firstly, if anyone could test this on an actual device and let me know what kind of fps they are getting that would be great. I’m inverting the whole map which I know is not great but my invert with a certain area function had a few small bugs so I reverted.

When I first came up with the idea, I thought I’d develop it for pico-8 first. I was a bit scared of the Playdate SDK so starting in something I’ve dabbled around in before felt the safest. Also, the fact that pico-8 is so limited, I thought if it ran on that system, it would definitely run on a device. I thought porting it over from pico-8 would be quite simple but this was not the case. Here is the pico-8 version if anybody wants to check it out or compare it to the Playdate build:

For porting it across I used the tiled example from the Playdate SDK as my starting point. This helped me get something that looked like the game up and running relatively easily. The issue was that I didn’t really understand the code and this slowed me down quite a bit. My character jump and movement speeds never seemed right; the scroll speed would speed up when the character jumped. It felt like the collision detection with the ground was slowing down the game. Finally, when it came to inverting the world. I felt like redrawing the tiles and re-creating the collision was too intensive (although it didn’t actually run that badly in the simulator) I’ve now just thought storing both versions of the maps and collisions would have been a much better approach. Doh!

Anyhow not liking my tiled version and not really understanding the code. I went with the nuclear option of starting over and trying to port my code line by line. The code has ended up looking very similar to the pico-8 version and I even went as far as converting the pico-8 specific code like mget, mset, fget, btn, etc. I might even start a repo for pico-8 to Playdate if I have the time.

I feel like I’ve waffled on a bit too much there so I’ll go onto remaining issues. I have slightly bouncy collision detection as I was having issues with the back of the character sprite firing a false death collision. This one I can live with.

Then I have an issue where the character block doesn’t fall through gaps that are one block wide.

Finally, my biggest issue at the moment is that the character is hiding under tiles that I consider see through. I’ve tried setting the zIndex of the character. I also tried drawing the see-through tiles as sprites and this worked until you inverted the scene and then went back to hiding the main sprite. I’ve seen the setBackgroundDrawingCallback in the documentation. Does anyone know how to use these with a tilemap? I’m using tilemap:draw to draw the tiles then getTileAtPosition and setTileAtPosition to invert them.

Here is the zipped pdx folder. I’m not totally sure how to do a release. I’m just using the playdate-vscode-template from github. (11.1 MB)

This zip is now the version where I switch between two maps instead of using setTileAtPosition.

I do have a particle system but I’ll add that back in once I see how it performs on device. I’ll also add more to this post as I go along.

update 25/10/2022
I've added a new build to the comments in this page with particles. Also the project will live on at this link.

1 Like

Framerate on the device looked good (30) at first, but I'm not sure how to play. What are the controls/goals? (A) seems to jump, and when I pressed (B) it bricked my device. (Temporarily. I'm sure I can reset it with a paperclip once I get back home, but I don't know a way to resurrect it using the buttons alone.)

A or Up is to jump and B would invert the world. So when you press B the dashed bricks will change to solid ones and spikes will flip their direction. The point of the game is to get as far as possible.

There are no errors in the simulator when I press B. Maybe I'll have to wait until my device arrives to fix this.

Thanks for testing. I hope your device is ok.

1 Like

Sounds like a cool idea! Maybe the invert function is too much for the hardware, or has a memory leak. I bet there are ways to make it work though! Your limited-area method might do the trick. (And you can't hurt a Playdate by running a game... not to worry.)

Re the character being behind things... is the character a sprite? You should be able to set that in front of other sprites (and of course the background) pretty easily.

You might need to mark it as sprite:markDirty() and/or do a sprite.update() in the update() loop if you're not already? Usually sprites mark themselves dirty in my experience, but maybe if the player hasn't moved on the screen that could be an issue?

The malloc log is saying 1.09mb used so I don't think I have a memory leak.

It could be that the hardware can't handle it. I might reduce the level size to one screen and upload that onto here.

The character is a sprite. I've set the zIndex for it to be right at the front but that doesn't work. The documentation kind of goes through this. I'll try the markDirty idea as I already have sprite:update() in the code.

Thanks again for your help.

1 Like

Reset my Playdate and tested again--B button always crashes. No error message, but a steady white light comes on. Maybe someone else knows what that means!

I ran it in the debugger--the B button crash is because it's taking longer than ten seconds to invert the level, plus there's a new bug where it's crashing instead of showing the error message on the screen. :confused: I'm looking into that now!

It's a fun game, though! Frustrating, but the frequent checkpoints keep it from being too mean. :slight_smile:

Here's the error on SDK 1.10 fwiw. I'm going back and figuring out where we broke that screen..

That looks like it is the invert loop that's failing it. I think I'll created an inverted version of the map and just switch between them which should be much faster.

Thanks a lot for looking into this.

1 Like

I've uploaded a version where the invert loop has been removed and I now switch between two maps instead. Could anybody test this versions performance please?

Where's the new download link?

I've changed the link above to the latest file. It should be a bit bigger than the previous file.

1 Like

Cool, that did it! Steady 30 fps, both buttons work fine now. (It's fun coming up with the optimized way to use the Playdate's limited power!)

I die immediately, but that's me—my reaction time is too slow. I see how the concept works now I think: jump when you can—but invert to save yourself from a bad jump?

One thing that might be worth trying: double the size of everything? (This might help that experiment.) The Playdate screen is quite a bit smaller (and usually dimmer) than the Simulator. Single-pixel lines and small fonts tend to get lost if you're not holding very still in bright light. For Invert World, the player and platforms aren't much more than a millimeter in size. (My own Playdate game mockups had to get bigger several times before I was happy.)

A quick way to judge the size of things: save a screenshot, resize it to be about 5.9 cm across (2-1/3 inches), turn your brightness down, and sit at "handheld distance." Works best with a high-DPI display.

Or you may be able to adjust your computer's resolution to make the Simulator's active area (sans black margin) be that width.

Thanks for trying it. It's great that it is working properly.

I'll see if I can make the simulator the size of a real device. I'll try to double the size as I could see it being quite small.

1 Like

@AdamsImmersive I've created a build with 2x the scale. If you could let me know how it looks and runs on the device that would be great.

Then I'll add the particle system back in. Then add distance traveled to the game hud. (11.1 MB)

1 Like

Here is a version with a particle system during movement. Can anybody tell me how it runs on a device and do you like the look of it? As I'm not too sure. (11.1 MB)