Mario


Welcome to this [December adventure](https://eli.li/december-adventure), where I write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

One of the few good programming classes I had at university was deceptively called C++. I say deceptively because we learned little about the language features, and instead the class focused heavily on the control flow of a program.

The teacher showed us how to use the Visual Studio debugger and go step by step through the code. Each class, he would teach us a new concept and walk us through it. We would go step by step in the program and showed us how to inspect the state of the program.

After that class, I practically stopped using a debugger even though I learned a lot using them. I eventually ended up doing `print` statements and got used to this way of working.

I used a debugger a couple of times but only for really specific issues and the majority of the time it seemed like too much hassle that wasn't worth the effort.

When I started learning C watching the [Hand Made Hero](https://www.youtube.com/watch?v=A2dxjOjWHxQ) video series, Casey always ran his program through the debugger. It didn't matter if he was searching for a bug or not. He dedicates a couple of hours at the beginning to setting everything up, but by the time he is actually working on his code, running the game through a debugger was as easy as running the game without it.

I also watched his [video talking about Remedy BG](https://www.youtube.com/watch?v=r9eQth4Q5jg). It certainly looked useful, and as I considered myself a novice in C I needed all the help I could get. This is how my search for a debugger that worked on Linux started.

## [GDB](https://en.wikipedia.org/wiki/GNU_Debugger)

![gdb](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger/gdb.png)
GDB Is the de facto debugger people use on Linux. Not only that, but by the end of this adventure, I realized almost all the other options were just GDB in disguise, or a GDB front end, as they would say in their description.

I’m not a person who shy away from the terminal and rely on tools like nvim, tmux, bat, ripgrep, lazygit, and others almost daily. However, for some reason, just like with the profiler…. Lo demás ok

I’m not a person who shy away from the terminal; I use [nvim](https://neovim.io/), [tmux](https://github.com/tmux/tmux), [bat](https://github.com/sharkdp/bat), [ripgrep](https://github.com/BurntSushi/ripgrep), [lazy git](https://github.com/jesseduffield/lazygit), etc. almost daily. However, for some reason, just like with the profiler, I was having a hard time making sense of the debugger on the CLI.

I saw a [couple](https://jvns.ca/blog/2021/05/17/how-to-look-at-the-stack-in-gdb/) of [tutorials](https://www.youtube.com/watch?v=PorfLSr3DDI), read the manual a little and learned enough to be able to use it. But by the end of the day, it never felt faster or easier than just printing stuff to the terminal.

It was really valuable though, in the future I already knew for example how to print a variable in hex or binary format, and that knowledge carried over to the other tools I tried.

So even if you don't like CLI, I would say it's valuable to learn how to use GDB. At the end of the day, a lot of tools are based on it, so you probably would end up learning how to use it even if you don't want to.

## [GDB TUI](https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19.html#SEC198)

![gdb-tui](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger/gdb-tui.png)

The GDB TUI seems to be recommended a lot when people complain about using the CLI. It does improve things a little bit but, but not by that much. The UI somehow would always end up somewhat broken after a couple of minutes poking around at a program, and still a lot of functionality was behind the CLI interface, so I needed to learn all the syntax and small tricks that the GDB CLI interface used.

And as with all the other GDB front ends, I eventually would find something I wanted to do that GDB supported, but the TUI didn't, GDB has an enormous set of features, and it seems really hard that a GUI has support for everything that GDB can do.

## [Seer](https://github.com/epasveer/seer)

![seer.png](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger/seer.png)
Seer was one of my first tries at a GUI debugger on Linux; it sounded promising, but after using it for a day, it lacked a bunch of features, and the workflow was just too slow for me. It didn't fulfil the requirement of being more convenient than a print statement.

## [GF](https://github.com/nakst/gf)

![GF](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger/gf.png)

This is one of the best if not the best GDB front end, it supports a bunch of features from GDB, it works well while launching from a terminal.

One problem is that it doesn't support Wayland natively, so my code looks all blurry. Also, it has a layout system that you have to define from a config file, and having to make a change, to restart GF and then wanted to change something else quickly became tedious.

When I started using it, there was a Memory Viewer module behind a Patreon, so I subscribed to the Patreon and compiled the app with the Memory Viewer enabled. This was nice, but I would have preferred to install it directly from my package manager. After a couple of weeks, the Patreon was closed and the memory viewer plugin realized. I haven't checked in a while, but it wasn't updated in Arch yet.

## [VS Code C/C++ Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools)

![vscode](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger/vscode.png)

This is the option that I'm currently using. Watching Casey video on Remedy BG made me realize that a debugger could be a lot nicer than what there is right now in the Linux ecosystem, but at least with VS Code it runs fast enough, I'm already familiar with the UI, and it does most of what I need.

I have a long list of things I would like in the VS Code debugger, like being able to launch from the CLI the project attached to the debugger or a way to show my custom strings as text in the watch window. But it doesn't seem like it's going to be possible any time soon.

So that's it! I'm really excited to try out the [Raddebugger](https://github.com/EpicGamesExt/raddebugger) once it's available on Linux. Who knows, maybe next year is actually going to be the year of the Linux desktop!

Any way, It was time to polish the physics of the game and after using this tools I had an idea.

See you in the next adventure: The physics debugger.


Making a pinball game for Playdate: Part 07, the debugger


Welcome to this [December adventure](https://eli.li/december-adventure), where I write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

One thing I was afraid of when I started working on this game was profiling code. By the end of [Pullfrog Deluxe](https://play.date/games/pullfrog/) development, I tried using the SDK profiler, but I had a really hard time.

![Sampler Playdate](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-06-the-profiler/pd-sampler.png)

The call stack in general was big, and it wasn't clear for me which things were the ones I had control over.

So when we started working on the pinball, I prioritized an easy way to measure performance.

Reading the [Playdate dev forum](https://devforum.play.date/), I learned that if you were doing things in C, you couldn't use the simulator profiler on desktop, just on device. Even the device profiling wasn't that great. But you could use any of the profilers for desktop apps.

I remembered there was a profiler project from the [Hand Made community](https://handmade.network/) that sounded interesting, so I started looking into it.

The project name is [Spall](https://gravitymoth.com/spall/) and to my delight, integrating the tracing library was super simple. The library is a single header file; you include it in your project and add a couple of macros to the functions you want to trace.

![Spall](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-06-the-profiler/spall-ss.png)

This was different from my previous approach in Pullfrog where I started with the full code being profiled and got lost quickly because it was hard to tell what was happening. You can profile specific functions [using the Lua SDK](https://sdk.play.date/2.6.2/Inside%20Playdate.html#M-profiling), but you would still get all the other functions in the data.

But the thing that made the biggest difference was the overall UI/UX of Spall. You can zoom in and out, and pan the graph smoothly, whereas in the Playdate SDK you have to first select a section of the timeline and then view that profiling info.

![spall.gif](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-06-the-profiler/spall.gif)

Another big benefit from Spall is that they have [a free web version](https://gravitymoth.com/spall/spall-web.html), so you can try it out and see if it works for you.

I even managed to generate the Spall profiling data on the device! It was not perfect; the device would stall after the ring buffer was full and needed to write to disk, but it was enough for me to test small code paths.

At the end, my setup wasn't perfect, but just learning how to interpret the data was enough for me. I learned that a good UI takes you a long way into understanding something complex and scary.

I'm thinking of dropping Spall, at least for device profiling. Now that I actually understand what's happening, I feel more confident to use any profiler.

I also wanted to try [Tracy](https://tracy.nereid.pl/), but after reading the documentation, it seemed that I needed to get a C++ build system, and my build system is super simple. So it didn't seem worth it for this project.

One thing that got me excited is that [Superluminal](https://mastodon.gamedev.place/@rovarma/113194259676032577) is coming to Linux. Sounds like the next year could be the year of the Linux desktop!

Well, it seems that all [the people](https://www.youtube.com/watch?v=WJVQLpGHB8g) who talked about profiling were right, it's really useful! And after years of using print statements to debug, I started to wonder... Is this the time to learn how to actually use a debugger?.

See you in the next adventure, [The Debugger](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-07-the-debugger).


Making a pinball game for Playdate: Part 06, the profiler


Welcome to this [December adventure](https://eli.li/december-adventure), where I will write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

If I could only choose one book to recommend from this adventure, that would be [Real-Time Collision Detection by Christer Ericson](https://realtimecollisiondetection.net/books/rtcd/). Collision detection is a subject that has come up a bunch of times in my career, and it's something that once you learn can apply to a bunch of things in game dev.

![Real-Time Collision Detection](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition/cover.png)

## Narrow collision detection

We already had all the primitive checks (minus one that I will cover in a later post) that we needed to make our game, the most complex one being the polygon collision test. The Pikuma 2D physics course covered the [Separating axis theorem](https://en.wikipedia.org/wiki/Hyperplane_separation_theorem), and I had already understood and implemented that. But I had heard about the [GJK algorithm](https://en.wikipedia.org/wiki/Gilbert%E2%80%93Johnson%E2%80%93Keerthi_distance_algorithm) for a while and wanted to try it out.

After [watching](https://www.youtube.com/watch?v=Qupqu1xe7Io) a [couple](https://www.youtube.com/watch?v=ajv46BSqcK4) of [videos](https://www.youtube.com/watch?v=MDusDn8oTSE) and reading some articles, I understood some of it, but wasn't that confident in being able to implement it in a language I wasn't comfortable with yet. Not only that, but this was a basic piece we needed for our game. I remembered reading about the [cute headers](https://github.com/RandyGaul/cute_headers) single header libraries and specifically knew there was a [header for collision detection](https://github.com/RandyGaul/cute_headers/blob/master/cute_c2.h).

After reading the documentation, I got excited; not only did it supported polygons using GJK, but it also had a way to do [swept collision detection](https://blog.hamaluik.ca/posts/swept-aabb-collision-using-minkowski-difference/), which at the time sounded useful.

Turns out we didn't need the swept functions, as running our physics step 4 times every frame and doing sequential impulses was enough to avoid any tunneling issues, at least with the speed the ball was moving in our game. But I'm getting out of topic.

I quickly added the header library to my project and started to testing it out. It worked great.

But as I mentioned before, after we added a bunch of polygons, the game started to slow down. I knew it was due to the lack of any spatial partitioning. I was checking every ball with every polygon every frame.

## Broad collision detection

There are various ways to solve this, and [Real-Time Collision Detection](https://realtimecollisiondetection.net/books/rtcd/) talks about a bunch of them, not only that but compares them and explains in which case you would use each one of the different techniques.

The main goal is to split the checks you have to do by some kind of spatial characteristic.

For example, [Quad trees](https://en.wikipedia.org/wiki/Quadtree) which I knew thanks to [The Coding Train](https://youtu.be/OJxEcs0w_kE?si=X3F3cgFOXt6HC0yh) (Jp & I are fans). Quad trees are a technique where you subdivide the space into 4 parts. You put each element inside of one of these 4 parts, and if any part has more than a certain number of elements, you split that part into smaller 4 parts and repeat.

![Point_quadtree.svg](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition/Point_quadtree.svg)
_By David Eppstein_

I always wanted to try to implement them; it didn't sound terrible complicated, and what better moment. But I decided to keep reading and see what the difference was with the other techniques.

> "A very effective space subdivision scheme is to overlay space with a regular grid. This grid divides spaces in to a number of regions, or grid cells of equal size. Each object is then associated with the cells it overlaps.
> Thanks to the uniformity of the grid, accessing a cell corresponding to a particular coordinate is both simple and fast."
> [Real-Time Collision Detection by Christer Ericson](https://realtimecollisiondetection.net/books/rtcd/)

Well, I know grids. It's one of the most basic things you start doing while programming, and they are everywhere. Quad trees may sound more interesting, but nothing beats simple.

Not only that, but reading more, I realized our pinball table was mostly static, so storing all the static bodies in the grid could be done in a cache-friendly way.

> "When a grid data is static, the need for a linked list can be removed all together. Rather than storing the data in a linked list, the idea is to store all cell data in a single contiguous array."
> [Real-Time Collision Detection by Christer Ericson](https://realtimecollisiondetection.net/books/rtcd/)

![diagram](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition/diagram.png)

So I load all the polygon data from our [Level Editor](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor), order them by their top left corner, calculate the bounding box of each polygon, and store them in a contiguous array. I know the number of polygons beforehand thanks to the _level editor_, so I only need to allocate memory once.

Then I calculate how many polygons each cell has, and store the polygons index on each cell they occupy, instead of storing them in a single cell and then having to check multiple ones when doing the broad face collision detection.

I have to run this logic twice, the first time to know how many elements each cell has, allocate the memory needed, and then run again to actually store the indices.

Not gonna lie, this process takes _some time_. I'm sure I'm doing it in the slowest way possible, but this only happens once when the game launches, I have it on my list of **TODO** to optimize it at some point, but if the game launches and the loading time is long, well you will know it was in exchange for really fast collision detection! (I mostly kid, I really want to fix it).

![bounding boxes](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition/01.gif)

We filled the bottom part of the level with all the polygons we planned for the game and smooth 50fps, not a single frame drop.

![All polygons](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition/02.gif)

Well, intuition and good practice can only take you so far. I wanted to be sure that if there were any performance issues, I had tools to diagnose them and fix them!

Will see you in the next adventure: [The Profiler](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-06-the-profiler).


Making a pinball game for Playdate: Part 05, the spatial partition


Welcome to today’s [December adventure](https://eli.li/december-adventure), where I will write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

One day, as we were scrolling through the Playdate Squad Discord server, [Lukas Wolski](https://bsky.app/profile/strupf.bsky.social) the dev behind the excellent game [Owlet’s Embrace](https://play.date/games/owlets-embrace/) posted the following picture.

![Interlaced](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/interlaced.png)

> Some time ago I wrote my own sprite and primitive blitting routines without using the SDK. I went for the same bitmap format like the SDK: First half of the bitmap buffer black/white pixel data, second half of the buffer transparent/opaque pixel data.
>
> I wondered what would happen if I rewrote my code and texture format to use an interlaced layout, where 32 bits of black/white and 32 bits of transparent/opaque are alternating. You need to read and write both of them for basically all graphics routines anyway. The performance difference depends probably on the size of the bitmaps used (-> distance between b/w and transparent regions in a bitmap).
>
> The very same game scene in my own game went from 35 FPS to 50 FPS. And it all came down to cache misses, stalling the CPU. I use some very big textures here and there btw.

This sounded promising! When we were working on [ Pullfrog ](https://play.date/games/pullfrog/) I didn't know a lot about how to measure performance bottlenecks, but even I knew that drawing things on the screen was expensive. If we could get a speed bump by doing our own custom drawing routines, that sounded like a big win!

I can't say I fully understood what Lukas was talking about or why it mattered, but I have heard before that cache misses were important for performance.

![Cache miss](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/cache-miss.jpg)
[From Game Engine Architecture by Jason Gregory](https://www.gameenginebook.com/)

Ok good. What is [interlacing](<https://en.wikipedia.org/wiki/Interlacing_(bitmaps)>) again? You probably have experienced this on the web.

Sometimes a website image will show row by row of pixels while loading. But other times it would wait until the whole image is loaded. When the image is not interlaced, the browser needs the whole image information to be able to render it. This is because the information about the colors of the pixels and, the transparency is separated. So to show a single pixel, the browser needs to load all the color information and then load all the transparency information.

When the image is interlaced, meaning all the information to render a row of pixels is close together, the browser can render the pixel as soon as it loads that single pixel information.

Ok now that I got that. First I needed to figure out how to convert our `.png` images to something interlaced that I could then read on the Playdate and blit it to the screen. My first attempt was to convert them to the [CHR format](https://wiki.xxiivv.com/site/chr_format.html) I knew my friend [Devine](https://wiki.xxiivv.com/site/home.html) was using it for his [Nasu](https://wiki.xxiivv.com/site/nasu.html) sprite sheet editor

I wrote a custom [Aseprite exporter for ICN and CHR](https://git.sr.ht/~afk/ase-scripts/tree/main/item/export-to-chr.lua) and BOOM; we have textures in the screen. This was my first time reading/writing a binary format, so it felt like a massive win.

![ICN/CHR](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/chr.gif)

Now this didn't assure me that it would be faster to draw than the Playdate's [PDI](https://github.com/cranksters/playdate-reverse-engineering/blob/main/formats/pdi.md) format; not only that, but the restriction of having everything in tiles was something that made sense for the Famicom but not for our game.

With this new knowledge, I started reading **Lukas’** code. He shared it on the **Playdate Squad** Discord server and had his game code on GitHub. I didn't understand the blipping code yet, but thanks to his previous messages in the Discord, I was able to replicate the image format. Once again, I wrote another [small Aseprite](https://git.sr.ht/~afk/ase-scripts/tree/main/item/export-to-tex-32.lua) script and tried it with this code; it worked!

![Glitched](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/glitch.png)

Kind of...

A couple of tries later, and it worked!

![Grid](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/grid.png)

We now had physics and a way to draw textures on the screen; we felt over the devil’s on the **moon** pinball.

At this point, Jp had plenty of time to plan the pinball table design and had a bunch of art ready to implement.

![final](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format/final.gif)

We added a bunch of polygons and tried the game, but when we started to see the frame rate drop, I knew what I needed to do.

See you in the next adventure, [Part 04: The spatial partitioning](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-05-the-spatial-partition).


Making a pinball game for Playdate: Part 04, the image format


Welcome back to this [December adventure](https://eli.li/december-adventure), where I will write about the process of making our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

When following the [Pikuma 2D Physics course](https://pikuma.com/courses/game-physics-engine-programming), one thing I did quite fast was making a simple polygon editor. I quickly got tired of inputting every vertex by hand.

![Draw polygons with the mouse](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/pikuma.gif)

This presented a problem: how are we going to author the pinball table for our game? Not only that, but good pinball games have a lot of curves. Am I going to need a way to create [Bézier curves](https://www.youtube.com/watch?v=aVwxzDHniEw)? How do I convert Bézier curves to something useful? In my case, to polygon colliders? Should I start working on a custom level editor?

I briefly tried writing an [Aseprite](https://www.aseprite.org/) extension to generate the collision masks but failed. It was fun though.

![Aseprite extension](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/aseprite.gif)

The main thing we wanted to know was if we could use the same approach from the physics engine for the Playdate game. First I had to translate from C++ to plain C and from [SDL](https://www.libsdl.org/) to the Playdate. Second, I wanted to put a lot of polygons on the screen, a couple of balls, and see how the frame rate behaved.

As you will see in future posts, I don’t need a lot of reasons to start making a new tool, but everything was still up in the air; if performance wasn’t good enough, I would need to go back to the drawing board and find a different way to define the level.

So I started searching for a UI to make polygons. I wanted something simple that would let me define some polygons and ideally set different stats on the polygons to test the physics.

In my search, I found the [Code & Web Physics Editor](https://www.codeandweb.com/physicseditor). It ran on macOS and Linux; it had a simple UI and allowed me to write a plugin to change the export file to something that fitted my needs. I didn’t have a good way of defining custom entities that weren’t physics-related, but it was good enough to start.

![Code & Web physics editor](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/codeandweb.gif)

One intermediately obvious benefit of the Code & Web editor was that it took care of subdividing the polygons to make them concave _automatically_.

I hacked around a custom exporter that would generate a .h file with an array of polygons and started working from there.

```c
// map.h

struct body TABLE_BODIES[43] = {
    {
        /* ID=poly0-0 */
        .p = {0.0, 0.0},
        .restitution = 0.60f,
        .friction = 1.00f,
        .mass = 0.0f,
        .inertia = 0.0f,
        .mass_inv = 0.0f,
        .inertia_inv = 0.0f,
        .shape.shape_type = COL_TYPE_POLY,
        .shape.poly = {
            .count=6,
            .verts={{44, 105},{39, 109},{39, 162},{45, 171},{50, 160},{50, 109}}
        }
},
...
```

Then came the porting process to the Playdate, we were super excited the first time we saw the ball moving around the screen and colliding with the polygons. We knew at that point that we were actually going to be able to make it. Suddenly making a janky pinball game similar to early game boy pinball games wasn’t enough; we knew we could do better.

![photo_2024-12-04_00-08-08.jpg](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/photo_2024-12-04_00-08-08.jpg)

While I was playing around with the physics system, Jp finally had some tools to start designing; he already had some ideas for the design of the table. The Code & Web editor got us really far. It allowed us to focus on the overall design of the table and making sure the physics were right before moving on to the next steps of the game.

![Polygon Editor](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/polygon-editor.png)

I wrote a really basic camera system, that followed the main ball, and as Jp added more and more polygons, the game kept running at steady 50FPS.

There were a lot of things left to do, but the scariest part was done, or at least done enough. In retrospect, I really like that we went with the Code & Web editor first; eventually we migrated to [Tiled](https://www.mapeditor.org/), but only after we took the Code & Web editor to its very limits.

![debug.gif](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor/debug.gif)

Now we just needed to find a way to draw textures on the screen, and there was a message on the Playdate Squad discord server that excited us a ton.

See you in the next adventure, Part 04: [The image format](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-04-the-image-format).


Making a pinball game for Playdate: Part 03, the first level editor


Welcome to this [December adventure](https://eli.li/december-adventure), where I will try to write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

When we decided to make a _pinball_ game, the main challenge I saw was the physics system. I don't consider myself to be someone good at math, and physics simulations sound like a scary big math mountain to climb.

But there was always a small sliver of hope; old _Game Boy pinball_ games didn't look like they had a really sophisticated physics simulation, so If we at least managed something like that, we would be fine.

![Hero Shuugou!! Pinball Party](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/Hero%20Shuugou!!%20Pinball%20Party.png)

I started looking more into how these games worked. I [found](https://www.raspberrypi.com/news/code-your-own-pinball-game-wireframe-53/) a [couple](https://news.ycombinator.com/item?id=28667945) of [good](https://talk.pokitto.com/t/wip-pinball-engine-for-the-pokitto/2206) [answers](https://www.reddit.com/r/howdidtheycodeit/comments/106uro7/how_did_they_code_physics_in_pinball/) [online](https://gamedev.stackexchange.com/questions/43705/2d-collision-detection-for-pinball-game).

The main gist of it seemed to be to generate a collision mask where every pixel had encoded the value of the angle the ball had to bounce off in a value between 0-255. You then read the value of each pixel around the radius of the ball, get the x and y components of the force vector from the average of the angle, and apply the force to the ball. This sounds... simple!

![Pinball collision mask](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/mask.png)

One thing that you need to understand is that here at **Amano**, after 10 years working together, **Jp** and I try to always work in parallel. Gone are the days were **JP** would send me the file through Dropbox, I would put them in the correct folder with the correct naming convention, show him my build of the game, tweak a couple of values and then recompile.

My main priority while making a system for a game we will do together is to give **JP** the tools to be able to work on design while I'm working on the next system.

So going back to the collision mask, I just didn't know a good way of generating these masks. Today, a year later, I have some ideas, but at the time I felt there was not enough information around on how this was supposed to work.

**JP** who has become steadily better at 3D over the years, saw it as an opportunity to use Blender and came up with a pipeline on how to generate a mask like that.

![Collision mask made in blender](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/mask-amano.png)

I tried it for a day but quickly became frustrated; for one, as I said, there was little information on how to do this. I didn't understand the math behind it, as simple as it was, and I depended on **JP** to generate a new image if I wanted to try a new mask.

I researched a little on the state of physics libraries for Playdate, but the results weren't encouraging. There were a couple of bindings for [Box2D](https://devforum.play.date/t/playbox2d-port-of-box2d-lite-physics-engine-to-c-and-playdate-sdk/1656) and [Chipmunk physics](https://devforum.play.date/t/chipmunk-physics-lua-binding-demo/13448), but the libraries seemed too complicated for what I needed they didn't seemed to have the results I wanted.

I was kind of lost; on one hand, I could try to figure out the collision mask method and have the simple janky physics of some early _Game Boy pinball_ games. And in the other, I could just try to do a rigid body simulation myself and see how that goes.

[My first rule when I started this project was](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-01-the-language), "I prefer something simpler and done by myself, rather than doing something more complicated and just grabing someone else's code." So going for the collision mask seemed like the best option if I was going for simplicity, but the lack of resources made it harder on the ‘me understanding it’ part of the rule.

For a long time I had been wanting to do one of the courses on [Pikuma.com](https://pikuma.com/). They seemed to share a similar spirit to Hand Made Hero, and they had a course on a [2D physics engine](https://pikuma.com/courses/game-physics-engine-programming), just what I needed, neat!

I skimmed the contents, and it seemed like just the thing I needed.

![Pikuma 01](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/pikuma-01.gif)

It took me around a week to finish the course and it was good! I don't understand all the underlying math and wouldn't be able to derivate the formulas by myself, but I understood enough to feel confident to reimplement the physics engine in _C_ for our _pinball_ game.

![Pikuma 02](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/pikuma-02.gif)

It was a _dangerous_ decision because while I took a full week learning new things, I left **JP** with the hype of a new project and not a lot of tools to work with, but after showing my progress, we were both excited.

The main benefit of doing things ourselves meant that we could cut corners where it made sense for our specific project.

Now I had to port my new physics engine to C and make it work on the Playdate so we could validate how many things we could have on the screen at the same time.

![Pikuma 03](https://media.amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics/pikuma-03.gif)

But first I started to worry. Remember how I said that my main priority was having tools ready so that **JP** could work in parallel while I worked on the next thing? Authoring the collisions for the game started to look like a task more difficult than what I was expecting.

See you in the next adventure, [Part 03: The first level editor.](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-03-the-first-level-editor)

## Resources

Before I go go. I want to share a couple of links to resources that helped me tremendously with this. And on that note, I also want to tell you that doing a basic rigid body simulator is not that hard! If you are even a bit interested, you should try it! I don't regret it one bit, and you can have something fun happen quite fast.

### [How to create a custom physics engine](https://code.tutsplus.com/series/how-to-create-a-custom-physics-engine--gamedev-12715) by [Randy Gaul](https://randygaul.github.io/)

By far the easiest of the bunch, you can follow along and have something working in a day, also Randy Gaul so if you haven't checked their libraries of CuteHeaders I highly recommend them.

### [Game physics series by Allen Chou](https://allenchou.net/game-physics-series/)

A little bit more in depth and touch on more intermediate subjects, whenever I got stuck with a specific concept, I would try to read this article series, a lot of times it went over my head! But the little knowledge that I was able to absorb was super valuable.

### [Rigid Body Dynamics by Chris Hecker](https://www.chrishecker.com/Rigid_Body_Dynamics#Physics_Articles)

Chris Hecker was mentioned quite a lot in the Hand Made Hero video series, so it was a nice surprise to find his name all over the place whenever I was searching for rigid body Dynamics.

### [Physac a 2D physics header-only library in C by Victor Fisac](https://www.victorfisac.com/physac)

Whenever I'm doing something new, I always feel more confident when I have the code of someone else I can read along with and digest. While doing anything in a new language and one that was so different from what I was used to, Physac helped me to double-check everything I was doing and make sure it made sense.

### [Everything by Erin Catto](https://box2d.org/)

I don't really know where to start when linking things from Erin Catto. If you have worked for a while in games, probably you already know about Box2D and even maybe heard about Erin. What you may not know is that Box 2D is not at all as complicated as I thought it was! By the end of my work with the physics engine, my main source of reference was the Box2D and the [Box2D Lite source code](https://github.com/erincatto/box2d-lite). I didn't even realize that the intention behind **Box2D Lite** was to teach people on how to do physics simulations. Anyway, all the GDC presentations and all the code that Erin has written is excellent, and you should check it out.

### [Solving Rigid Body Contacts](http://www.richardtonge.com/presentations/Tonge-2012-GDC-solvingRigidBodyContacts.pdf) by [Richard Tonge](http://www.richardtonge.com/)

At some point I got stuck with a weird behaviour we were having with multiple collisions in a single frame, I may talk a little more about it in a later post, but this presentation saved my ass. And now I'm forever a fan of [Antonio Signorini](<https://en.wikipedia.org/wiki/Antonio_Signorini_(physicist)>)


Making a pinball game for Playdate: Part 02, the physics


Welcome to this [December adventure](https://eli.li/december-adventure), where I will try to write about the process of our latest game, [Devils on the Moon pinball](https://play.date/games/devils-on-the-moon-pinball/).

If you want to see the game in action, you can watch the [Playdate Fall update](https://youtu.be/wSNBCK5gIcY?si=t_YoBfm6o5_JanjH&t=415) where we show a sneak peek of the game.

After we released [Pullfrog Deluxe](https://play.date/games/pullfrog/) I had mixed feelings. On one side, I was super happy with the game that we did, but on the other, I felt stuck. There are some parts of Pullfrog that I felt I could have done better. I have had this feeling before; the problem is that I didn't know how.

I'm not a person who cares a lot about which programming language he uses; I have some preferences, but mainly because of familiarity. I have used _JS_ for 10 years, almost daily, so whenever I have to make something fast, I tend to pick that. But the last time I programmed in a low-level language like _C_ or _C++_ was at university, more than 10 years ago.

When we were in the last stretch of **Pullfrog's** development, one thing that would happen often is that we didn't know if we could add something to the game without running in to performance issues, for example we had more ideas for special pieces but any time we added a little visual effects we would spend days trying to optimize the game and make it run at **30FPS**.

In the current version, at the end of 2024, the game still _struggles_ when you have a lot of pieces in the board all moving and falling. No one has ever complained about it. I think most people assume we slow down the game on purpose to make it more _dramatic_ or easier to read, similar to how [space invaders would speed up the fewer enemies were on-screen.](https://en.wikipedia.org/wiki/Space_Invaders#Hardware) But truth be told, I was annoyed by it, but it was good enough.

In the process of trying to optimize _Pullfrog_ I rewrote large chunks of the game and underlying systems, some obvious things had great results, but by the end I reached my capacity to improve the codebase. I realized that even with more time, I didn't know how to make the code better.

You always have constraints when doing a game; there are fun ones, like a limited color palette, but in this case I couldn't shake the feeling that we were missing on some good game design ideas by being afraid of performance.

I always have had a curiosity about low-level languages, game engines and, as the name of our studio says, doing things from scratch. So one year ago, I started my last [December adventure](https://merveilles.town/@mario_afk/111509153847171054); I started the [Hand Made Hero](https://www.youtube.com/watch?v=A2dxjOjWHxQ) video series and followed along. This was my second attempt at it. The first time I tried it was back when the project launched, but I quickly gave up after trying to set up a dev environment on Linux and translating the platform code from Windows to Linux.

This time I thought there were a [couple](https://hmh-notes.handmade.network/) of [good resources](https://davidgow.net/handmadepenguin/) that helped me get over the hump. I made it up to day 32; it was great!. I have tried a couple of times to make games in _C_, mainly following small tutorials, and it just felt like doing games in any other language/framework but worse. Watching Casey make something from nothing and understanding most of it felt empowering, and kind of scary.

I realized that there were a ton of things to learn while doing games this way, and maybe that would help me to become better at doing them. So by the start of the next year I made a decision; I was going to make a game in _C_ and tried to do everything myself.

The main rule I set for myself was that I prefer to make something simple and do it myself, rather than trying to do something complex that I don't understand and grabbing someone else's code.

**Spoiler alert:** I ended up doing the most complicated game mechanics I have done in the last 10 years. And I had a _great_ time doing it.

See you in the next adventure, [Part 02: The Physics.](https://amano.games/devlog/making-a-pinball-game-for-the-playdate-part-02-the-physics)


Making a pinball game for Playdate: Part 01, the language


It’s been a long time since we talked about **Pullfrog**. The main reason being that we paused the development to work on another game called **Don Salmon**, you can read more about it on the previous [devlog](https://amano.games/devlog/lets-talk-about-don-salmon).

But now we are back working on **Pullfrog**, with our main goal of **finishing it**, we haven’t yet, but we are close! It’s at the stage where we are comfortable with what the game is and what it isn’t.

So buckle up because this is going to be a long one.

![graph.svg](https://media.amano.games/devlog/lets-finish-this/1-graph.svg)

## What happened?

When we started working on **Pullfrog** for [Playdate](http://play.date/), the plan was to work on it for a month, three months tops. The plan was to port the [PICO-8 version](https://afk-mario.itch.io/pullfrog) and improve some things on the way. It took us a year to have the basic version of the game we wanted to do. By the end we were a little tired, so when we heard **Panic!** was looking for games to publish, we saw it as an opportunity to spend some time on a proper pitch and take a break from developing the game.

![s5.png](https://media.amano.games/devlog/lets-finish-this/2-slide.png)

While we waited to hear from **Panic!** we started working on Don Salmon. We wanted to apply everything we had learned making Pullfrog, on a game where the limitations were different. We wanted to experiment with new platforming mechanics, like wall-jumping, air jumping, dashing etc.

One day we got a tweet from [@Guv_Bubbs](https://linktr.ee/guv_bubbs) and [@TYMplaydateshow](https://tinyyellowmachine.com/) asking us on the status of the project. At that point we were deep on the development of **Don Salmon**, and we hadn’t heard anything from **Panic!** So we replied that the project was on indefinite hiatus while we finished **Don Salmon**. **Panic!** saw this and emailed us asking us if we were still interested in publishing the game but cutting the scope of it.

Who would have thought that lowering the scope saved the game.

![old-vs-new-clean.png](https://media.amano.games/devlog/lets-finish-this/3-old-vs-new-clean.png)

Before **Panic!** approached us, we looked at the amount of work we had yet to finish, and it was frankly _a lot!_ In trying to make a different enough game from the PICO-8 version, we put a lot of pressure on changes. So when **Panic!** contacted us after not working on the game for a year and asked us if we were interested in reducing the scope and finishing the game, we got excited, Ideas started coming through.

The first thing was to stop trying to make a different game. We scrapped all the ideas to make it more like a dungeon crawler with enemies and a final boss and focused on closing the loop of the game, to make it play more like the **PICO-8** version which we knew worked, but with the learnings from the past year applied towards making it better.

## Make everything bigger

![Screenshot 2023-08-11 at 15.29.51.png](https://media.amano.games/devlog/lets-finish-this/4-frog-evolution.png)

One of the first things [Jp](https://merveilles.town/@jp) did was to completely re-do all the game assets to make all the sprites larger. After playing other **Playdate** games, we came to the conclusion that the game would read better by changing the size of the character and the pieces, though at the slight cost of losing some vertical space for the game screen.

## The shop

![old-shop.gif](https://media.amano.games/devlog/lets-finish-this/5-old-shop.gif)

The second part was removing the shop logic of the game. The initial plan was to have a shop like the one in [Downwell](https://downwellgame.com/), and allow you to step out of the game and use the eyes as currency to get new power ups.

As you can see, we had everything working already, but we decided it was something that the game didn’t need and added a lot of complexity to the project. The way we did it in the **PICO-8** version was that every time you cleared 3 lines, the shop would pop-up in a little window and pause the gameplay while you browsed, and you could choose an item for free. So we decided to go with this as well.

![shop-export.png](https://media.amano.games/devlog/lets-finish-this/6-new-shop.png)

The thought of deleting all that code and focusing on the important parts of the game felt good. After that it took us about two weeks to get back up to speed, but once we did, we where closing tickets left to right.

## The eyes

One consequence of changing the shop was that we had all these systems based on getting eyes, but now they didn’t hold any value anymore.

![old-vs-new-bussy.png](https://media.amano.games/devlog/lets-finish-this/7-old-vs-new-bussy.png)

In the **PICO-8** version you could also collect eyes, by choosing five of them on the shop instead of a useful upgrade, a secret door would appear. Something we like from the new version, is that to collect an eye, it needs to be inside of a cleared line. If you use your tongue to destroy a block piece that contains an eye piece, you loose the eye. This makes the game a little more like a puzzle and forces you to think more about which pieces you destroy.

![eyes-2-export.gif](https://media.amano.games/devlog/lets-finish-this/8-eyes-collect-destroy.gif)

Now that you don’t collect the eyes in the shop, we had more space left for power-ups.

## 1UP

One thing we discovered while working on this new version is that having an extra life can be nice, but too many and the game is less fun. Getting squished by a piece but being able to get a second chance and go back to the game felt great.

So we came up with the power up of a **1UP**, there will only be one each run, so it is precious but gives you that second chance.

![1up-export.gif](https://media.amano.games/devlog/lets-finish-this/9-second-chance.gif)

So yeah! We are _almost_ done, we are excited to see what people think of the game, and happy with the progress we have made in the last couple of months. As of writing this we’ve finished the **first beta build,** there are still a couple of months left of work, but we are getting close!

![eyes.gif](https://media.amano.games/devlog/lets-finish-this/10-eyes.gif)


Let’s finish this


Some things have been happening that triggered me to write this blog post. One of them is that [a good friend of the studio](https://twitter.com/pepehxc) showed me a couple of neat muck-ups for a pixel art point-and-click adventure game, which took me down a rabbit hole of research, and I ended up reading 50 entries of the [Thimbleweed Park blog](https://blog.thimbleweedpark.com/index.html) in a day.

![01-pepe](https://media.amano.games/devlog/lets-talk-about-don-salmon/01-pepe.jpg)

I also went to GDC for the fifth time! The first time I went to GDC I didn't have a good time, mostly because I didn't know anyone, my English wasn't great, and the projects I was working on at the moment were hard to talk about with a bunch of cool people at the Yerbabuena park.

Last year, I had a great time, mainly because I had two big things going on for me. The first one was that [I gave a talk](https://gdcvault.com/play/1027710/Independent-Games-Summit-Game-Dev)!. This was the first time I went to GDC with a ticket, which was great! The second thing is that I was working on Pullfrog and had one of the few PlayDates, (maybe the only one?) in San Francisco at the time, so everyone I met wanted to try out the game!

![02-tutorial](https://media.amano.games/devlog/lets-talk-about-don-salmon/02-tutorial.png)

## What happened with Pullfrog?

A lot! But it was on hold for about a year. We just took a break from it, mainly because Panic announced that thanks to the big success of the Playdate pre-orders, they were looking for games to publish.

We sent an email and a pitch deck but didn't hear back, so we assumed Panic wasn't interested. At the time we were working on Pullfrog's unlockable abilities, we had a bunch of ideas we wanted to try but to finish the game we had to focus on performance for a bit. We had already optimized the game a lot, but the game would drop to 20FPS regularly on advanced levels, so after sending the pitch deck, we decided to take a little break while we waited to see the future of the project.

![03-ded](https://media.amano.games/devlog/lets-talk-about-don-salmon/03-ded.png)

> We planned to publish this post in April! And a lot has happened since then, mainly that Panic! Got in contact with us, and we have been working on Pullfrog since the end of May. That’s the main reason why this post is published now: so that we can start writing about Pullfrog.

As I said in the previous log, we have been dabbling with 3D, and personally, I was really deep in to learning the Godot Game engine, so I wanted to make a small game with it to get it out of my system. So after we send the email, I started working on a small prototype.

The main idea of the game was to make a 2D platforming game with all the platforming mechanics: corner correction, dashing, wall jumping, double jumping, triple jumping, QUADRUPLE JUMPING, you get the idea. And we needed a way to limit the abilities, and one thing we hadn't done in a game before, was combat.

![04-lego](https://media.amano.games/devlog/lets-talk-about-don-salmon/04-lego.gif)

After I saw this GIF on my timeline, I came up with the idea of a game with a waterfall where you can climb to the top while punching things that are coming down. Depending on your combo, you get more platform mechanics.

![05-prototype](https://media.amano.games/devlog/lets-talk-about-don-salmon/05-prototype.gif)

After a day of working on it, I showed it to Jp, and he got excited and started working on the art. We made a couple of level prototypes to nail down the resolution and general workflow, and we had a nice demo!

![06-concept](https://media.amano.games/devlog/lets-talk-about-don-salmon/06-concept.png)

Perfect, I said; in a month we will finish this little game and come back to work on Pullfrog.

![07-combat](https://media.amano.games/devlog/lets-talk-about-don-salmon/07-combat.gif)

It's been ~~10 months~~ 1 year, and we haven't finished, but here is how the game looks right now. We are pretty happy with it; we are still figuring out something on the main mechanics, but that's a topic for another log.

![08-preview](https://media.amano.games/devlog/lets-talk-about-don-salmon/08-preview.gif)


Let's talk about Don Salmon


Last year we made the decision to take a break and focus on a spooky game around the spooky season.

This year we wanted to try and do a 3D game. We already have a 3D spooky game, [Gossip Ghost](https://afk-mario.itch.io/ghossip-ghosts) but we never finished it, and it left us with an urge to try it again later.

![iLspod.png](https://media.amano.games/devlog/spooky-eyes-and-level-editors/gossip.png)

One thing that I wanted to try is [Godot](https://godotengine.org/), as a Linux with a bad internet user Unity tended to be a little hostile.

We spent around a month and a half on a small 3D demo of a game, with the idea to maybe make it something bigger. Turns out doing a 3D game can get tricky, more so when you are learning a new programming language, game engine and asset pipeline. In general, the experience was positive, and we are excited to try and do more 3D games next year, but our time was up, and we decided to go back and finish **Pullfrog**.

![Screen_Recording_2021-10-06_at_12.28.56_AM.gif](https://media.amano.games/devlog/spooky-eyes-and-level-editors/spoopy.gif)

Possibly in another post we will talk about our experience with Godot and 3D games in general, but I'm trying to finish an entry here.

## Eyes and levels

The last thing we were working on before taking a break was our _eye_ system. The idea is to have some sort of hard currency that you need, to advance to the next level. This is the mayor difference between this new version of the game, compared to the PICO-8 version. The concept of levels. We started the development with the idea to do something more similar to a dungeon crawler than an arcade game.

The idea is that every piece has a probability to spawn an _eye_ in one of their blocks, and if you clear a line of pieces containing an _eye_, you get it. After you fill the level quota, the door unlocks, and you can go and talk to a pondering frog merchant, who will eventually give you a nice perk before advancing to the next level.

![sss.gif](https://media.amano.games/devlog/spooky-eyes-and-level-editors/eyes.gif)

I loved implementing all these things, after months of tracking performance and trying to keep things under a CPU budget, being able to put as much polish as possible in little details was a joy to work on.

## Level editor

One of the things we love about PICO-8 is the integrated level editor. It may not be much, but just having something ready to use for any game adds a lot of possibility to your workflow. For a hard core use of the PICO-8 tile map editor check out [@calixjumio](https://twitter.com/calixjumio/) who always takes the level editor to an extreme in a interesting way.

For the original **Pullfrog** you may not know this, but we used the tile map editor extensively. The main reason was for testing. **Pullfrog** this is a complex arcade game with a custom physics engine and complicated rules. We had to test a lot of weird situations and the easiest way to do so was starting the game on a specific situation using the tile map editor.

![pullfrog_0.gif](https://media.amano.games/devlog/spooky-eyes-and-level-editors/pullfrog.gif)

From the start of the [PlayDate](https://play.date/) version, we made the decision to find a level editor for our internal testing, or in the worst case build one ourselves _by hand_. We don't need much, just paint some tiles and have at least a flag per tile telling what kind of tile it is.

The PlayDate SDK comes with an example on how to use [Tiled](https://www.mapeditor.org/). We have [used it in the past](https://hyperbeard.com/game/the-balloons/) and the experience wasn't great, granted, it was our first time doing a tile map game and we were using a hacky plugin to transform the map in to unity game objects, but in general Tiled seemed like a complicated solution for a really simple problem.

I have been following [Deep Night](https://deepnight.net/) from some time now, I'm a fan of the [game dev articles](https://deepnight.net/tutorial/a-simple-platformer-engine-part-1-basics/) and saw the release of [LDTK](https://ldtk.io/) which seemed promising. I tried using it while working on [The lost night](https://afk-mario.itch.io/the-lost-night) but we were already too deep into the game and would need to rewrite a lot of stuff to make it work, and probably more tokens, but it left a great impression on me. Making a parsing system for our PlayDate game sounded more fun than trying to use Tiled.

### Workflow

One of the things I love about LDTK is that the map file is a JSON file, so there is no need for an export → engine pipeline. We can just read the map JSON file which is the same that it's used by the editor. Another thing I like, is the file structure, it's well-thought-out to make the parsing job easier, [and the documentation is really good](https://ldtk.io/json/).

So I started writing our LDTK parsing module, currently it consists of 160 lines. We are not using the full list of features LDTK has, just a small subset of things that we require for the game, and every time we require something else I go in and add a couple of lines to the parse. If we start building a lot of levels, I may need to split the levels in files and load them depending on where the player is, but that's future Mario's problem.

![Screen Shot 2021-12-10 at 14.23.59.png](https://media.amano.games/devlog/spooky-eyes-and-level-editors/ldtk.png)

We have a couple of LDTK's entities to quickly iterate over the game, one that controls in which level the player is going to spawn and one that controls where in the level the player is going to spawn and with which properties.

![Screen Shot 2021-12-10 at 14.26.00.png](https://media.amano.games/devlog/spooky-eyes-and-level-editors/entity.png)

We also have one entity per shape of piece, this allows is to specify what kind of piece it is (more on this in the next post) and if the piece should spawn with an eye. So if we have a specific bug we want to try, we just need to set it up on the map and run the game.

### The world

We currently don't have a specific plan on how we are going to handle the level progression. Currently, when you open the door and fall to the next level, the level that it's directly below the one you were before gets loaded, and if there is no other level below we just restart the previous level. This works fine for prototyping, but we need to figure out a good way to present the different mechanics that we have planned, we have a couple of ideas, but I don't want to spoil them until we have a basic implementation.

![Screen Shot 2021-12-10 at 14.38.50.png](https://media.amano.games/devlog/spooky-eyes-and-level-editors/world.png)

## The future

The game will be out when it's finished, this means we have no idea when that would be, but we would like to at least have an early access version when the PlayDates start arriving to people, so we can have user feedback and add the finishing touches to the game.

Meanwhile I leave you with a Gif showing how we tend to debug UI elements.

![https://media.amano.games/devlog/spooky-eyes-and-level-editors/indicator.gif](https://media.amano.games/devlog/spooky-eyes-and-level-editors/indicator.gif)


Spooky eyes and level editors


Remember when I said that making a hole inside a big collider was a good idea? It was not. After rewriting the physics system for the third time, it was time to start working on more fun stuff. The frog death system™.

Something we wanted to improve from the PICO-8 version of the game, was to make it harder for the player to die. The game can be hard, as you need to mix platforming with puzzle solving abilities.

On top of that, dying while pulling the pieces towards you was no fun, so we came up with a system to try to save you, moving you out of danger.

First we figured we only are going to try to save the frog if you are getting squished by a piece that is moving vertically.

The most important part is to figure out which direction we should move you. Our first approach was to compare the piece center with the player center, and move the player to the closest side to freedom.

```lua
    -- Fake code
    local pieceCenter = piece:getCenter()
    local playerCenter = player:getCenter()

    if playerCenter < pieceCenter then
        player:moveLeft()
    else
        player:moveRight()
    end
```

This simple solution had a small problem, our pieces have different shapes and the center is not always, well, in the center.

![https://media.amano.games/devlog/this-kills-the-frog/hand-picked-center%281%29.png](https://media.amano.games/devlog/this-kills-the-frog/hand-picked-center%281%29.png)

So we created a small system to place the center of the pieces _by hand_

![https://media.amano.games/devlog/this-kills-the-frog/automatic-center%281%29.png](https://media.amano.games/devlog/this-kills-the-frog/automatic-center%281%29.png)

Now we have to figure out how many pixels we want the system to move the player each frame. If we move it too much, it would look like we are teleporting the player. If we move it too little, then it can get stuck for many frames and look like the game broke.

We decided we didn't want the player to die until the very last moment. When the piece is squishing it so much that there is no room to escape.

We can get this information based on the overlapping rect between the piece and the player. If the `height` of the rect is less than 10 pixels (the frog collider is 11 pixels tall), we keep trying to break you free.

We figured that 1 pixel at a time would look the best most of the time. There are some times when you are on top of a piece that's falling and if you pull it towards you, you get stuck sliding between a piece sandwich. So in that specific case, we move you 2 pixels at a time to get you out faster.

![https://media.amano.games/devlog/this-kills-the-frog/slide.gif](https://media.amano.games/devlog/this-kills-the-frog/slide.gif)

Another thing we realized was that it didn't feel good when you died while you were moving in one direction, and our system forced you to move in the opposite direction.

You would still be dead if we moved the direction you were trying to move. But it felt unfair because we were forcing you to move in to a direction you didn't intend.

So now if you press any of the D-PAD arrows while being squished, we force the direction you are pressing to try to get you out. You die more times than before, but it always feels like it's your fault, not the game's fault.

After implementing this, we found another issue. If you stopped pressing the D-PAD after we started moving you, then our system would try to move you in the opposite direction if you hadn't cleared the piece center.

This looked bad as the character was moving without you controlling it in random looking directions.

We decided to save the D-PAD direction if you were pressing it while being squished and try to save you on that direction even if you stopped pressing it.

Sometimes you would only get squished by a small amount on one of the player corners. If you were moving in to the piece and get caught, then our system would pull you in and kill you without anything you could do about it.

We added another rule. If the piece is crushing you by only a small amount, then we try to move you in the closest direction to freedom, regardless of what you are pressing.

Finally, if we fail to save you and the intersection rect between the piece and the frog is taller than 10pixels. This kills the frog.

![https://media.amano.games/devlog/this-kills-the-frog/ded.gif](https://media.amano.games/devlog/this-kills-the-frog/ded.gif)

Here is the code we ended up having, there is a lot of context missing, but helps to understand the system a little better.

---

```lua
function Player:SquishY(other, x, y, w, h, dy)
    local px = self.x
    local ox, oy = table.unpack(other.overrideCenter)
    ox, oy = other.x + ox, other.y + oy
    local dirX = self.flip and 1 or -1
    local correctingDir = self.correctingDir
    local velX = self.velocity.x

    local sideDist = 8
    local maxSquish = 10
    local speed = 1
    local cornerThreshold = 4
    local speedThreshold = 0.4

    if other.targetPosition then speed = 2 end
    -- When you get squish from a piece that it's moving upwards,
    -- check if there is a solid on top of you and if there is
    -- this kills the frog
    if dy < 0 then if self:checkSolid(0, -1) then return self:die() end end

    -- The player always overrides the direction where you are going
    -- to be tried to be saved.
    -- If the player stops pressing a button we use the last direction
    -- the user pressed.
    if (input.btn("left") or velX < -speedThreshold) and w >
        cornerThreshold then
        dirX = -1
        self.correctingDir = dirX
    elseif (input.btn("right") or velX > speedThreshold) and w >
        cornerThreshold then
        dirX = 1
        self.correctingDir = dirX
    else
        if correctingDir == nil then
            if (px < ox) then
                dirX = -1
            elseif (px > ox) then
                dirX = 1
            end
        else
            dirX = correctingDir
        end
    end

    if h <= maxSquish then
        actorCornerCorrect(self, dirX * speed, 0, sideDist, {0})
        self.squishedY = true
    else
        self:die()
    end
end
```


This kills the frog


This is a more polished version of a long message that I wrote in the official **Playdate** Discord server. A couple of things I would recommend when starting your first game on the **Playdate**.

## Lazy Devs

[Lazy Devs](https://www.youtube.com/playlist?list=PLea8cjCua_P0qjjiG8G5FBgqwpqMU7rBk) is one of the best teachers for game development out there. I love his tutorials because it shows you the process of doing a game from start to finish with a lot of polish and focus on gameplay. The tutorials are for PICO-8, but it also uses LUA, so a lot of things translate well to **Playdate**.

## a327ex

If you want a big LUA codebase to look at as a reference, [BYTEPATH](https://github.com/a327ex/BYTEPATH) and [SNKRX](https://github.com/a327ex/SNKRX) are good examples of finished games made in LOVE2D. They are open source so you can check how they handles everything in the games.

Basic example:

Coming from **PICO-8** I wasn't used to importing external files so I was importing _CoreLibs_ in every single file. At some point I started to wonder if that's how everyone was doing it. I looked at **[a327ex](https://twitter.com/a327ex)** code and ended up having an single `init.lua` file where I do all my imports and set up the game.

## Using a framework

The most valuable thing from a framework in my opinion is to look at their code. So you can check the general structure of the project and figure out if it works for you, or grab the things that do. In general, I would recommend against starting with a framework on top of the Playdate SDK for your first **Playdate** project. You will end up with another layer of things you have to learn.

## Scene Management

This is a common mistake, I know that I have fallen in to this trap a couple of times before. Scene management is not especially hard to do, but it's something that can impose a lot of friction between iterations of your game.

I like to start my games with the main interaction of the gameplay and make that feel as nice as possible.

In our game that would be movement and platforming. In other games it could be moving the cursor for a point and click adventure or grid movement for a puzzle game.

Making it feel good takes a lot of iteration. If you have to go through: _Title screen animation -> Main menu -> testing your small change_, it will end up as a painful process. You might even start working on tools to make that process faster. And end up spending more time doing the scene management and the tools around it than actually doing the main mechanic of your game.

In a more code-centric problem the first version of your scene system probably is not going to be the best. And you probably don't know all the things that you will need for it to work the best it can for your game. If you introduce it too early you may find yourself coding in a way to accommodate to your first attempt at your scene management system. So my advice would be start with movement first. Try to finish a game loop and if you need some scenes to make that happen do them in the simplest way possible.

## LUA and OOP

This is personal preference but a lot of the times it is better to start without OOP. It can make your LUA tables bloated in exchange for a small convenience that you may regret later on. I use the basic sprite for everything and do helper functions that accept a reference to the sprite. After a while it becomes clear if I need to abstract it in a class, but a lot of the times it doesn't.

```lua
function spriteGetMapCoords(sprite)
    local x,y = sprite.x, sprite.y
    x = math.floor(x/16)
    y = math.floor(y/16)
    return x,y
end

-- VS

local gfx <const> = playdate.graphics

class('MySprite').extends(gfx.sprite)
function MySprite:init(x,y,img)
    MySprite.super.init(self)
    assert(img)
    self:add()
    self:setImage(img)
end

function MySprite:getMapCoords()
    local x,y = self.x, self.y
    x = math.floor(x/16)
    y = math.floor(y/16)
    return x,y
end

```

**Playdate** has a lot of limitations on the amount of objects that you can update/have in every frame. So hiding them away on abstractions class can end up being a bad idea.

It's been a while since we post anything new about **Pullfrog 2Bit** and it's mainly because all the new stuff is hard to share as it is has been a lot of refactor to try to have the game running at a better frame rate in the **Playdate**. I leave you with a GIF on the latest bug.

![https://media.amano.games/devlog/starting-a-game/target-position-bug.gif](https://media.amano.games/devlog/starting-a-game/target-position-bug.gif)


On starting a game


There are many techniques that you can apply so that a platformer game _feels good_. One of those is corner correction.

![https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/corner-correct.gif](https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/corner-correct.gif)

As with most of these techniques, the goal is to assist the player in getting to the position where they want to be. Even if there is something in the way that wouldn't let them. In this case we are moving the player a few pixels to the sides so that they clear the platform above them.

In the [PICO-8 version of Pullfrog](https://afk-mario.itch.io/pullfrog), we solved this using multiple colliders. We would check which one of them triggered the collision, based on that, we would apply some logic to move them where we wanted. This worked fine but the problem is that we where checking **all the colliders** every frame. It was hard to maintain, and an expensive operation, dropping frames when there were a lot of pieces in the screen.

![https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/ezgif.com-gif-maker.gif](https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/ezgif.com-gif-maker.gif)

When starting the Playdate version I imposed myself a challenge, to have the same behavior using only one collider. The first thing we tried was to compare the position of the player with the object they collided with. Check if the distance between them is less than a certain amount, and if it is, move the player in the opposite direction.

![https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/03.png](https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/03.png)

This worked fine, but it was a little more complicated than what we needed, and caused a couple of undesired consequences. For example the jump distance would get altered and you would miss platforms that you would otherwise land on.

On top of that our physics logic for moving platforms was getting too complicated. Then someone on the Playdate Discord shared [an old post by Maddy Thorson](https://maddythorson.medium.com/celeste-and-towerfall-physics-d24bd2ae0fc5) about the physics system on Towerfall and Celeste. After reading it a lot of things _clicked_, and I got excited to change my broken physics mess for a more elegant solution.

For the corner correction Maddy doesn't go in to detail, but you can see and implementation on the [Celeste 2 PICO-8 game repo](https://github.com/ExOK/Celeste2). It took me a while to understand it, because PICO-8 code tends to be a little bit hard to read.

The main takeaway I got from Maddy's post and the Celeste 2 code, was to split the movement into two functions. One for X and one for Y. This made everything easier to think about and easier to resolve the collisions. In the case of corner correction, once we detect a collision, we try to move you out of it depending on the direction that you where moving. If while correcting you in one axis you collide again then we just don't move you, after that it's time for the other axis to try and correct you.

I'm thinking of doing a more in-depth explanation with some code. But haven't had the time to add code snippets support to the Devlog and this post is already getting big!.

A nice thing about doing this from scratch, is that now the code is less coupled with the player. This allow us to apply the same logic on different stages of the game an player movement. For example: If you are going to get squished by a moving piece, now we try to move you to safety.

![https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/squish-export.gif](https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/squish-export.gif)

Another example would be when you pull a piece and it collides with another one, we try to move the piece so that it ends up where you intended it to be.

![https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/piece-correct-export.gif](https://media.amano.games/devlog/how-to-correct-a-corner/how-to-correct-a-corner/piece-correct-export.gif)

Did you noticed how the piece pushed you? this was an added benefit form the new physics system and a big difference from the PICO-8 version of Pullfrog, but we will talk about this is a different post.


How to correct a corner


On some occasions people have commented on the character animations of the original Pullfrog. Saying how they look very bouncy, and asking how many frames we were using to get them to look so smooth. This used to throw me off-guard because the answer is one frame, or more like, as few as I can possibly draw.

![https://media.amano.games/devlog/bouncy-animations/01-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/01-bouncy.gif)

This is probably something that’s been talked about a million times, but here’s my take on the subject. To me, character animation is not about how smooth the movement is, or about trying to get in as many frames as possible to really make the character feel alive. It’s quite the opposite actually. I want to convey the action in the **least amount of frames possible** because I’m _lazy_, animation is a lot of work, and most people don’t really care or notice. Let the player’s mind fill-in the blanks. Well, those aren't the only reasons. See, I’ve worked in animation before, so while economizing is important to get work done, I like the challenge of getting an action to come across with very few frames. It feels elegant. It feels like I solved a problem.

So why DO these animations feel “Smooth” or “Bouncy”?

The most important thing to keep in mind are the **key poses** of an **action**.

A key pose is THE most essential frame of an action that the viewer needs to see. That single pose should be clear enough, that even without in-between frames the viewer knows exactly what action the character is performing.

![https://media.amano.games/devlog/bouncy-animations/02-bouncy.png](https://media.amano.games/devlog/bouncy-animations/02-bouncy.png)

Another Equally important decision, is choosing which poses you want to emphasize in order to get that reactive feeling when a character interacts with the world. So in the case of Pullfrog, I wanted to really emphasize the jumping part because, well… _frog_.

So I determined that each step pf the jump needed to have an impactful pose. These steps being:

1- Going UP  (Exaggerated stretch pose)

2- Coming Down (Frog curls into a ball)

3- Landing (Super Squash)

A simpler version of this goes into the walk an idle actions. Since I’m working with a n 8x8 grid there’s not a lot of room for detailed poses so the walking cycle is just a body squash and the legs opening and closing in alternation more like a “shimmy” than a walk, but it works!

So it’s not about how many frames I’m using rather, what actions I’m deciding to pose.

All this talk about economizing on frames does not mean that I don’t embellish my animations with extra frames for smoothness. I might if I can afford the sprites and have the extra time. Which is exactly what I chose to do in Pullfrog 2.

![https://media.amano.games/devlog/bouncy-animations/03-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/03-bouncy.gif)

Since the Playdate doesn’t really have any limitations to the amount of sprites, I decided to get a little fancy and add some extra frames to every action. These are just simple in-betweens where I’m using some animation principles like smears and anticipation to convey fluidity in movement. I also don’t want to over animate because this is still a game and reaction times are still more important than animations.

![https://media.amano.games/devlog/bouncy-animations/04-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/04-bouncy.gif)

![https://media.amano.games/devlog/bouncy-animations/09-bouncy.png](https://media.amano.games/devlog/bouncy-animations/09-bouncy.png)

Another advantage I now have is that I'm making the character on a 16x16 grind instead of 8x8 so that gives me a lot more room to really explore the strectchiness of the character.

![https://media.amano.games/devlog/bouncy-animations/05-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/05-bouncy.gif)

![https://media.amano.games/devlog/bouncy-animations/10-bouncy.png](https://media.amano.games/devlog/bouncy-animations/10-bouncy.png)

![https://media.amano.games/devlog/bouncy-animations/06-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/06-bouncy.gif)

![https://media.amano.games/devlog/bouncy-animations/11-bouncy.png](https://media.amano.games/devlog/bouncy-animations/11-bouncy.png)

![https://media.amano.games/devlog/bouncy-animations/07-bouncy.gif](https://media.amano.games/devlog/bouncy-animations/07-bouncy.gif)

![https://media.amano.games/devlog/bouncy-animations/08-bouncy.png](https://media.amano.games/devlog/bouncy-animations/08-bouncy.png)

Anyways. Once we start adding new mechanics and movements I’ll post about them too. And maybe talk about some cheating techniques to convey anticipation without hindering reaction times.

That’s all for now. Thanks For reading!


On "Bouncy" Animation


![https://media.amano.games/devlog/the-collision-stair-case/01-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/01-statircase.gif)

It all started with this little boy right here. A bug that had been annoying us for a couple of days, and this week was the time to fix it!

As stated on the previous post, updating all the pieces all the time was a bad idea. We needed to figure out a way to update only the ones that needed to be updated after another block got destroyed. The quick and dirty solution was to check all the pieces inside a bounding box on top of the piece that got destroyed.

![https://media.amano.games/devlog/the-collision-stair-case/04-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/04-statircase.gif)

We found an issue with the solution because If you have a structure like the one below, you could affect pieces in a column far away to the destroyed block and the algorithm would miss them.

![https://media.amano.games/devlog/the-collision-stair-case/06-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/06-statircase.gif)

The easiest solution was to check all the blocks above the one destroyed. We tried it, but came across a couple of issues. We updated way more pieces than the ones that were needed, not only that, but we some pieces kept freezing in the air.

![https://media.amano.games/devlog/the-collision-stair-case/03-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/03-statircase.gif)

At this point I realized that the basic idea was flawed. The pieces need to get updated not only if the block below them gets destroyed, but also when one piece below them starts moving.

So the new solution is: after we grab one piece, we search for all pieces that are in contact with it. Then we search for pieces in contact with those pieces, and then again and again. This is fast because we save the dry pieces inside a grid, so we only search nearby cells.

![https://media.amano.games/devlog/the-collision-stair-case/05-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/05-statircase.gif)

And it works!, we only update the pieces that need to be updated, and the code is way simpler to maintain.

A couple of tools helped us chase down this bug. We use [LDTK](https://ldtk.io/) to generate the game screen, it's very helpful, as we can generate any specific layout in seconds and start testing from there. Making the parser took us a couple of hours and has saved us a huge amount of time already.

![https://media.amano.games/devlog/the-collision-stair-case/07-statircase.png](https://media.amano.games/devlog/the-collision-stair-case/07-statircase.png)

We also added a grid overlay to the game through the Playdate men, to position things or figure out their coordinates.

![https://media.amano.games/devlog/the-collision-stair-case/02-statircase.gif](https://media.amano.games/devlog/the-collision-stair-case/02-statircase.gif)


The collision stair case


## About Amano

**[JP:](https://twitter.com/eljovenpaul)** So, a couple of months back, Mario and I were happily working away on The game, finding out the workflow and working out the kinks of developing for the [PlayDate](https://play.date/). We laid down the main mechanic, block were falling and colliding correctly the character was moving alright but we were doing everything on the simulator, NOT testing on the actual device. so when we decided to take it for a spin…  it crashed.

![https://media.amano.games/devlog/about-amano-collision-conundrum/10-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/10-about-amano.png)

Turns out, the way we were handling collisions wasn’t the best. So we got kinda bummed out and stopped working on the game for a bit.

During that off-time decided to address another issue. [Mario](https://merveilles.town/@mario_afk) wasn’t very thrilled about our games coming out under his personal [itch.io](https://afk-mario.itch.io/), [Newgrounds](https://afk-mario.newgrounds.com/), and [Lexaloffle](https://www.lexaloffle.com/bbs/?uid=21440) accounts because he’d constantly get solely credited for the games on social media and stuff. So in order to unify things in one place and give our games more of an identity, we designed a brand a website: **Amano**.

![https://media.amano.games/devlog/about-amano-collision-conundrum/09-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/09-about-amano.png)

![https://media.amano.games/devlog/about-amano-collision-conundrum/08-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/08-about-amano.png)

^This was gonna be the logo for a while. but IDK, one morning I kinda' hated it so I changed it on a whim.

![https://media.amano.games/devlog/about-amano-collision-conundrum/01-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/01-about-amano.png)

We went through a ton of iterations for the text; but the hand and the eye came out pretty much on the first sketch.

Hand-made tortillas are better than their machine-made cousins, and far superior to their ( born out of the necessity to cover demand and convenience) factory mass-produced alternatives. So sometimes I go on rants about how much I love hand-made tortillas. Especially to Mario. Hence his idea to name out little project Amano. “A mano”, which translates to “hand made” from Spanish.

![https://media.amano.games/devlog/about-amano-collision-conundrum/11-about-amano.gif](https://media.amano.games/devlog/about-amano-collision-conundrum/11-about-amano.gif)

## The Collision _conundrum_

[Mario:](https://merveilles.town/@mario_afk) The PlayDate SDK has pretty much everything we needed to start making Pullfrog, One of those things is a collision system. After spending the majority of the development time making a collision system for the original Pullfrog, this came as a welcome surprise. With a reassuring feeling that if everything went bad, we could always recreate the same system as the one in the PICO-8 version.

We started working on the main character and its behavior, we wanted to recreate the same feeling and polish we had on PICO-8 so the basic collision handling that we had on the PlayDate wasn't enough. Fortunately it wasn't to hard to customize and we ended up with even a better version of what we had in PICO-8. After a couple of days we already had the character moving in the screen! we already kind of had a game, so I built the game and send it to my device and started moving the little frog around.

After solving the collisions for the player, we though the next step would be as easy. Add falling pieces, and then we had the base game ready. We tried to keep things simple, so we had each the pieces with a list of blocks, and each one of blocks had their collider. We need this because when the player starts pulling and destroying the pieces with it's tongue we need to know which block was stroked.

![https://media.amano.games/devlog/about-amano-collision-conundrum/07-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/07-about-amano.png)

After a couple of weeks, I decided it was time to try the game again on the device, we where so excited that we added a hacky system for playing SFX's. I build the game, send it to the device, boot it up and then ... the game crashed.

Ok ok nothing serious, maybe I did something dumb with my hacky SFX manager and I could fix it later. I disabled the SFX's and tried again, after a few seconds of moving the little frog, the game crashed again!. After a couple of hours trying to figure out what was causing the issue, we realized it was the amount of blocks on the screen. Turns out that having one collider per block and checking collisions every frame was expensive and not a good idea, we needed a break.

Our previous game, The Lost Night, is a small spooky themed RPG made in PICO-8 where we hit all the platform limits at the very end of the development process and we had to scratch about 60% of the content we had planned for the game. By the end of the development we were bummed out. We didn't want the same thing to happen with Pullfrog2. Saddened, we started discussing our options, but nothing seemed to work better than what we had. We shifted our focus on something more exciting, Amano. We spent one month building the website, and it was a nice break, so by the end we were eager again go back and fix the game. [You can check out the source code of the website if you want.](https://github.com/amano-games/amano.games)

![https://media.amano.games/devlog/about-amano-collision-conundrum/12-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/12-about-amano.png)

After we knew the issue was having too many colliders in the game, I went back and started planing on how to reduce that number. The first thing that came to my mind was to have one collider for the bigger part of the piece and in some cases an extra one. This meant we would need to check twice each frame for half of the types of pieces. On top of that we still needed to know which block was struck by the tongue and would need an extra step.

![https://media.amano.games/devlog/about-amano-collision-conundrum/04-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/04-about-amano.png)

After a couple of hours I realized that if the pieces weren't moving, it didn't matter if we had all the colliders in the screen. Then we could keep a single collider per block and use them for the interaction with the frog's tongue. Now we needed to figure out how to handle when the pieces were falling as they only care about other pieces below them.

Next thing I tried was to query other sprites inside the bounds of the piece and check if there was something that should stop them. We made a quick test on the PlayDate and it Worked!. We could have the screen full of pieces falling and the game kept running. The frame rate drops a bit but that also happens on the PICO-8 version and no one has complained yet. I realized we didn't need to update the pieces when they are "dry", which is how we call them when they change their pattern to a state where they can be destroyed. We only needed to update the pieces that are above one that got destroyed the last frame. We can even have the screen full of dry pieces without any issue with the frame rate, which is how you play 99% of the time.

![https://media.amano.games/devlog/about-amano-collision-conundrum/06-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/06-about-amano.png)

There was only one thing else to fix. Some pieces have an empty block space in them, which makes them always a source of tricky bug. I figured to first check the big bounding box of the piece and then, if it collides, check if it overlaps with the empty space in the piece and ignore it. It's similar to the many colliders in the piece approach but with the advantage that we only check the empty space once, instead of twice for each piece.

![https://media.amano.games/devlog/about-amano-collision-conundrum/05-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/05-about-amano.png)

It worked!. But then I kept thinking there must be a better way of doing it. JP kept telling me that we could check the collisions based on a tile map like we do in PICO-8 version. It's tricky because the pieces can move around while you are pulling them, so when they are falling, we need more sophisticated collisions. And when they are in the floor we don't. We had a way of checking if the cell in the grid is occupied by a block for the line clearing, so we could use that while the piece where in the floor and use our new system when they are falling.

I'm sure there is still room for improvement but the game is playable in the device and we are happy with it for now. At the end it's similar to how we handle things in PICO-8, but it was hard to know how to translate that in the PlayDate without trying it first.

We where so happy about the game running in the PlayDate that JP did the launcher cards for the game, they look SO GOOD.

![https://media.amano.games/devlog/about-amano-collision-conundrum/03-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/03-about-amano.png)

![https://media.amano.games/devlog/about-amano-collision-conundrum/02-about-amano.png](https://media.amano.games/devlog/about-amano-collision-conundrum/02-about-amano.png)

Next up is dealing on how the pieces and the frog behave when you pull them and they collide with the frog. We have some ideas on how to improve this based on what we learned from the PICO-8 version.


About Amano & the collision conundrum


Back in **2020** during the month of may [Mario](https://merveilles.town/@mario_afk) and myself started working on a game for [PICO-8](https://www.lexaloffle.com/pico-8.php) as part of a monthly game development club. I've always loved playing Tetris and other falling block puzzle games, although Tetris is more of a skill game than a puzzle game such as [Panel De Pon](https://en.wikipedia.org/wiki/Puzzle_League). I've also always loved playing platformers. Moving around a character that has well-polished controls makes it feel like controlling an extension of your body. So I'd kinda wanted to mash-up these two things for a while.

![https://media.amano.games/devlog/pullfrog-postmortem/frogtris-cols-export.png](https://media.amano.games/devlog/pullfrog-postmortem/frogtris-cols-export.png)

I started by trying to lay down the feel of the character movement. I am not a programmer but attempting this really helped me understand how games and code really behave. and so after a while at work I managed to produce this janky-ass thing.

![https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-003.gif](https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-003.gif)

And then I tried again. Getting the basic movement allowed me to focus on important platforming details like "Coyote Jumping", collision corner corrections and input buffers. and so the second version was a little better.

![https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-004.gif](https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-004.gif)

This is where I hit my programming ability wall and [Mario](https://twitter.com/afk_mario) took over. He refactored the code, made pertinent changes, and continued to develop, what was initially just an exercise in learning good platforming _feel_, into a complete game. We came up with the look and core loop for the game, which is to move around and pull the falling blocks in to place with your tongue in order to clear lines and obtain power-ups, and keys in order to open a door at the end of the game. This Unlocks a new characters that play slightly different to the frog. Ideas were sketched, mechanics were polished, pixel art was pixeled. PICO-8's token limit was reached over and over again, but after 30 days we finished [Pullfrog](https://afk-mario.itch.io/pullfrog).

![https://media.amano.games/devlog/pullfrog-postmortem/concept.png](https://media.amano.games/devlog/pullfrog-postmortem/concept.png)

We learned a ton from the experience. Collisions, movement, performance, pacing, polish, math. Even though we were working remotely, most of the time we were talking on discord each doing our part. Finishing this game really made us feel that with enough time and resources we could make any kind of game we liked. So we put it out on [Itch.io](https://afk-mario.itch.io/pullfrog), [Lexaloffle](https://www.lexaloffle.com/bbs/?tid=38636), and [Newgrounds](https://www.newgrounds.com/portal/view/759921). People responded great to it, we were content and moved on to the next thing. We worked on a couple more pico ideas. But the itch remained. The "what if?". What kind of a game could we have made without the limitations of PICO-8?

![https://media.amano.games/devlog/pullfrog-postmortem/pullfrog.gif](https://media.amano.games/devlog/pullfrog-postmortem/pullfrog.gif)

So towards the end of the year, Mario managed to get his hands on a Development console for the handheld "[Playdate](https://play.date)" and we decided to attempt do make a second version of Pullfrog, this time featuring a playful little crank and seemingly less restrictions except for the apparent ones like the black and white color of the screen. Oh the naivety.

![https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-008.png](https://media.amano.games/devlog/pullfrog-postmortem/pullfrog-postmortem-008.png)

So this is the plan:

We want to make a version of Pullfrog that features more polish and variations in gameplay like:

- Different kinds of blocks.
- Some enemies and or bosses.
- Level progression.
- Replayability mechanics.
- Make use of the crank controller.
- Smoother animations and controls.

Slowly making progress as we get to know the [Playdate](https://play.date) console more and more. Developing tools and better ways to work. We're gonna try to keep this devlog going as we work and hope that whoever reads it can get something out of it. Thanks for reading.

You can follow us on [twitter](https://twitter.com/amanogames_) and stay updated on the development of our games.
