Pushblox Devlog

Hey there! This is my first time writing a devlog. Hope you enjoy!

About the game

The game I'm working on is a puzzle game with a built-in level editor. I'm mostly done with the game itself and currently just working on making puzzles for it.

Here's one of the puzzles I made in it:

gif1

And here's what the level editor looks like:

gif2

It's a block-pushing puzzle game with a variety of blocks and some floor tiles too. The goal is to get all the star blocks onto all the star tiles.

My goal for the game, once it's released, is to have a form available for people to send in levels they create and make those available in official 'Community Pack' updates. (I have the form made already so I'll link it on the store page once that's up)

Development

(Note: all references to performance are based on how it runs on device not simulator)

I have a bad habit of putting off menus and UI longer than I should so for this project that's where I started. Using Lua made menus easy because of the gridview library and the only thing that took more time was setting up all the file I/O since I'm allowing players to create, delete, rename, etc. the level files.

With all the menus done, I moved on to the editor. I set up a simple table format for storing level data and leveraged the gridview again so this also went by pretty quick.

The first real challenge with this game's development came when I started working on the actual logic. At this point, I had a list of all the blocks and tile types that I wanted to include. The logic actually would have been a lot simpler if it wasn't for three things... Push Tiles, Slide Blocks, and Mimic Blocks...

All of these allow for blocks to move without direct player influence:

gif3

See how they can move into currently occupied tiles as long as that tile is 'planning' to be empty? That took me a bit to figure out. The first thing that came to mind was doing multiple sweeps but with potentially a lot of sprites on screen already I looked for something more performant. I ended up using recursion to achieve this effect.

Here's a bit of pseudo code:

AttemptToMoveBlock(block)
{
if ( not block.planningToMove ) then return false;

if ( block.alreadyChecked ) then return block.planningToMove;

block.alreadyChecked = true;

...
return false if block collides with tile or out of bounds
...

var targetBlock = getBlockAtPosition(block.targetPosition);

if ( not targetBlock ) then return true;

if ( not targetBlock.planningToMove ) then return false;

var targetIsAbleToMove = AttemptToMoveBlock( targetBlock );

if ( not targetIsAbleToMove ) then return false;
else return true;
}

And here's what that might look like in game:

gif4

The game was now playable and since I did the level editor first I could start making and testing stuff... I could make anything... Even this...

gif5
(On device this ran at about 15-20fps)

And if I could make this so could anyone! Great...

Some context before I go further. I have also been working on a couple of other games/prototypes in C. In almost every way I prefer using C and only used Lua to hopefully speed up development. My new plan is to build up a sort of engine in C and get faster development times that way.

So I ported the whole thing to C! :grin:
I know there were probably a lot of ways to make it work well in Lua but I played to my strengths instead.

I used this as a chance to recreate the gridview from the Lua SDK and make my own keyboard interface. The whole process took about a week and I learned a lot about file I/O and string operations so not too bad.

The result was very nice. It now runs at a consistent 50fps in what I think is the worst case. And with some room to spare:

I also forgot to mention that I gave the player the ability to undo and the memory usage for that in Lua was a little frightening. Working with memory in C is really nice so this was solved too. The max number of stored turns that you can undo is 5,000+ comfortably (compared to only a couple hundred before porting to C).

Once the game was in C it was smooth sailing. Mostly just connecting all the menus and polishing up the controls. As of right now, I'm just working on filling the game with puzzles.

If anything else interesting happens between now and the game's release I'll be sure to talk more about it here. Thanks for reading!

6 Likes

You madman :joy: nice performance, too! Looks like a solid puzzler

1 Like

Kudos to you. I haven't really done much development for the PlayDate yet, but in general I tend to go the other way, from a more complicated language to a simpler one. Then again, nothing I do in the development world really benefits from the performance gains of a tighter language.

As for the game itself, looks great. The editor also looks pretty decent to use, especially given the small screen size.

1 Like