Hi all,

We've finished our next game, Crypt Sweeper, after ~2 months of development.

Links:

• Digital Release (Pay What You Want)
• Physical Release (cart only)
• Source Code

I thought this community might be interested in some of the development and history as well.

We have been working on a platformer for a while, but started to feel stuck. I'm always on the look out for interesting games, and stumbled on this article from ArsTechnica, where they clued me into DragonSweeper.

It took me a while to figure out the game, but once I did, it was really addicting! I kept discovering new mechanics and ideas, and fell in love with it. I thought it would be a great idea to port the game to the GBA, and reached out to the developer (@danielben). He didn't want me to use his assets, but suggested I clone the game instead.

This seemed like a project I could tackle in a reasonable amount of time so I got to work. I made a basic clone of how I understood the game, and then dove into the original DragonSweeper code to look at the level generation.

DragonSweeper's level generation is really interesting -- the basic idea is to place monsters on the board, then score how "happy" the monsters are, and wiggle them around until their "happiness" is maxed out.

I attempted to port this same basic logic to C, but when I ran it on the GBA, it took 40+ seconds to generate a level! This was not acceptable.

I ripped out the level generator, and rewrote it from scratch, based on my new understanding of how the game worked. There are a lot of constraints that need to be maintained, but in principle, it's still very easy. For example, the walls are always placed in pairs (horizontal or vertical). Most monsters have placement logic as well. Instead of encoding the preferred placement as "happiness", I just placed them directly in the structure I wanted, and gave up and started from scratch if I failed after 100 attempts.

The level generation still took a while though, 15-20 seconds (iirc).

My solution was to do all level generation at compile-time. This actually turned out to be a really good decision.

A side effect of doing level generation at compile-time meant that I could do additional analysis on the levels. In particular, I wanted to have 5 levels of difficulty, with harder monsters spawning on more advanced levels, but also the boards themselves needed to be analyzed for their difficulty in reasoning.

So I created an AI that could play the game, based on different amounts of understanding of the game. For example, the base level understanding is just math. But I could also add knowledge of how the monsters behaved into the AI. That meant I could run the AI against a board with different levels of understanding of the game.

At compile-time, I generate 1024 levels per difficulty, and in order to validate that a board conforms to a difficulty level, I let the AI play the board with a certain level of understanding. If it can beat the board at that level of understanding -- and not at a lower level of understanding -- then I can be certain that the board has a certain level of difficulty.

This does increase compile-time quite a lot, but it's a fixed cost.

This is a similar technique I've done for Sudoku boards, for example. It's hard to generate an easy board from scratch, but you can generate lots of boards, validate they have one unique solution, and categorize them after the fact. This is roughly what I do for Crypt Sweeper as well.

One last step, since the player only has 1024 unique levels per difficulty, that felt a little small. In order to increase variability, I also shuffle the two lowest level monsters randomly on the board, at run-time. These monsters are always placed randomly, so shuffling them around after the fact shouldn't alter the difficulty that much, and hopefully provides a tiny bit of variety at run-time.

Lastly, now that I had everything working, I got a little creative with the monsters. I did copy a lot of the monster behavior from DragonSweeper, but I added new monsters, variations of monsters, dropped some of the mechanics I didn't understand (gnome?), and reworked some mechanics specific to the GBA (Dracula's Ire).

After all that, I gave it to my wife, who did all the graphics and came up with the story. I wrote an 8-bit rendition of Moonlight Sonata for the soundtrack, and added final touches, like sound effects, and an in-game tutorial.

Anyways, we hope you enjoy the game! We decided to release it as Pay What You Want because we took so much from DragonSweeper, which is also a free game, so it didn't feel right to charge for the game. At the same time, if people want to give us money, that would be great, because it helps us make more games!

Thanks for reading!

Sean

EDIT: Our Kickstarter funded and Inky is now available for purchase digitally on Itch!

Hi everyone,

I thought it might be interesting to see what me and my partner Casey have been up to this past year. Our game isn't done yet, but it's getting very close. Our goal is to have it shippable by January 2023, but we will probably spend more time polishing it.

Inspiration

The inspiration for the game can be traced back to Baba Is You, which we both loved. After the game came out, I made some prototypes of block pushing games, just for fun. These prototypes never became games, and I put them down for a while.

April 2019

Re-ignition

Fast forward a couple years, and in the fall of 2021, I wanted to get back into programming for the Game Boy Advance (more info here).

I wanted to start with a simple project that I thought I could finish quickly (lol). So I took inspiration from what I made years ago, but wanted to simplify it. For example, in my original prototypes, objects could move diagonally, and you could push multiple objects. I removed those ideas, and started making a prototype with much more simple rules.

You can see how I kept the logs, rocks, and holes.

You'll also notice that I don't worry about graphics at first :-). I aimed for simple readable JavaScript code that I could easily hack at, try new ideas, and edit levels using a text editor.

October 2021

Quitting our Jobs

In January of this year, we had saved up enough money to take a year off of work, so decided to have a go at making a game company. We launched Pocket Pulp.

We originally thought we could finish the game by April, and we wanted to have products out before April, so we spent time making other puzzle games.

We made a card game, Monster Dedux, and successfully funded it on Kickstarter. We made a daily wooden puzzle game dotris, inspired a little bit by Wordle. And most recently we made a brainteaser wooden puzzle called The Pig Pen Puzzle.

These were a lot of fun to make, and they also bought us some time to keep working on the video game. They also bought us time to level up our skills.

Second Prototype

Since I wanted to make the game in assembly language, I started on a second prototype written in JavaScript that would be very close to the implementation on the GBA.

This prototype allowed me to plan ahead on the different functions I would need, and eventually break them down and translate them to assembly. This was really important for me because I wasn't used to writing assembly language at the time.

January 2021

Work on the Game

Using the second prototype, we slowly started working on the actual game! Imagine that! Here is a version where we just got the walls drawn:

July 2022

September 2022

October 2022

Work Continues

It is about to be December, and we are still hard at work! Here's roughly where we are today:

• Puzzles: 100%
• Game engine: 100%
• Story: 100%
• World Map: 95%
• Title screen, pause screen, save, loading: 90%
• Music: 75%
• Cut scenes: 75%
• Sound effects: 0%
• Credits: 0%

We need to get over the finish line so that everything is done enough. Then we can move on to the polishing phase of making everything better. When we hit that phase, we will be able to stop working on it at any moment and launch if we think it's ready.

Challenges So Far

1. I wanted to write the game in assembly language, so I made my own assembler. I did this both to help learn assembly, and because I enjoy making my own tools.
2. I spent a lot of time researching sound on the GBA because I know it's notorious for having crappy sound. I created my own sound engine in order to output the highest quality sound I possibly could.
3. Casey is a creative person, but never made pixel art before this project, so she has been leveling up her skill this entire time. One benefit of making physical puzzles is that gave Casey more time to practice her art. She's come a long way, if you compare her skill now compared to a game we made when she first started a year ago.
4. One last big challenge is shipping on a physical cart and saving on those carts. I spent a lot of time researching how flash carts work, and wrote up a tutorial based on my findings. I still have some work to do to make sure the carts correctly save progress, but I've got it mostly working.

Thanks for reading, let me know if you have any questions!

If you're interested in our game, please follow our Kickstarter pre-launch page to be notified when we launch!