Writing some Lua

I’m working on a playdate game. It’s sort of a mishmash of tile-matching mechanics, and attempts to get the crank working with various ideas I’ve had for square-grid manipulation. I’ve sort of thrown a bunch of ideas together and what I need to do now is decide how I’m going to focus it into an actual game. Currently there are both realtime “action puzzle” levels and also some more discreet puzzle levels that are not really designed so much as some tutorial and proof that puzzles could be designed pretty easily. I’m tempted to write a generator so I don’t have to do any level design, but I’ve gone down that road before, and once I’ve got the generator, I still have to pick levels that seem fun, and that’s usually where I crap out. I’ve mostly been focused on the action puzzle mode, which is what I really want to be the game, but if I’m being honest, I think the other mode seems maybe slightly more fun right now. I think I might try and think of ways to make the levels not be realtime, but still have recursive puzzles.

As I touched on in my last post, toward the end of last year and into the beginning of this one, I spent a bunch of time building some framework stuff for iOS grid-based games. I only mention this because now I’ve re-built a lot of that stuff in Lua for Playdate dev, which has me thinking lately about how I could re-use it in Pico-8, and maybe also in Love2D. The Love2D aspect is interesting because I could then target/publish back on iOS (in addition to desktops), bringing my development path pretty much full-circle. (I still definitely prefer Swift to Lua though, and have been daydreaming a bit about writing a Swift package that generates my Lua for me… that’s probably silly though.)

But no Unity

After publishing Thrive Digital last fall, I have yet to even install Unity on my new MacBook Pro. I think I may be “done” with Unity as a platform. (At least until I have another VR or AR project, but possibly not even then.) Unfortunately, this means a whole lot of my “in progress” projects are kind of abandoned at this point. That includes remakes of Action Chess and Go Tetris (which I’d been planning on calling Action Go when I do finally finish it), as well as a handful of prototypes and game jam games.

One of the jam games I thought was particularly promising and that I always meant to finish up was called Tetro-Buddies, and it had excellent art by August Brown.

Also in my Unity “in-progress” folder is Puzzle Prison, a game made for and targeting Google cardboard (no relation to Tetro-Buddies). I more or less abandoned Puzzle Prison around the time the first Oculus Quest came out. It was very near completion for a while, and I should probably have just released it. I actually showed Puzzle Prison at a number of events, and for a while it was my go-to demo whenever I wanted to show off VR on my phone. (It was a 3DoF Chain-Shot clone where the “puzzle was all around you”.)

I have been meaning to blog about Puzzle Prison for years. I even had an amazing OST made by musician Paths (who was calling himself DR00 at the time). The gameplay was… fine, but nothing special. I had all these ideas for making it more of a unique take, (mostly I just implemented a few additional block types, but I entertained plenty of other ideas) but none of the ideas really improved the gameplay much, and I think that had a lot to do with my never releasing it beyond TestFlight.

Now this article has become more about what I’m not doing than what I am, so let’s get back to that.

And some Action Puzzle game cataloging

The other thing I’ve been spending a lot of time on lately has been action puzzle game curation and Taxonomy. I have a relatively long blog post I’ve been working on, so I won’t go into it here, but of course action puzzle game taxonomy is a topic I’ve written about, and even felt compelled to present about, in the past. One piece of this is that I put together a relatively long list of action puzzle games on IGDB, mostly to make it easier to get feedback from fans of the genre about any that I may have missed or just don’t know about while putting the list together. I think there are a ton missing from the last 10-20 years, and I’d love for this to be as close to comprehensive as possible, but I’m not including any sequels or games that just don’t add anything to the design-space (although of course sometimes that judgement is subjective, so I’m erring on the side of inclusion).

One thing that’s decidedly missing from the IGDB list are smaller indie and hobbyist games. The list started not on IGDB, and the original is more comprehensive, and includes a bunch of iOS games not found on IGDB, a well as Pico-8 games. Of course it is possible to add games to IGDB, but I’m not sure that’s the best use of my time. The Pico-8 curation has been especially fun, because I recently bought an Anbernic RG351V, and have set it up to play all my favorite Pico-8 games, including some excellent Action Puzzle games like Pushamo, PullFrog, Bondstones, Drop Blop, TetraChess, and Sirtet. I definitely feel like I’ve barely scratched the surface on finding them.

Anyway, look for that blog post… sometime soon-ish.

I don’t know that I have ever written a blog post about a game I’ve prototyped before. I mean, of course I prototype every game, but I don’t often talk about games that are in the early phase of development. In this case, I spent a non-trivial amount of time working on a game with the WIP title “Snake Shapes” in December 2021. I don’t think I’m going to spend any more time on it unless I have some big epiphany or something. I don’t know how many games I’ve worked on where I abandon them like this, but there have been a few over the years, I just don’t think I’ve done very much, if anything, to document one of them before.

First, what is Snake Shapes?

The original idea came from an entry in my game design journal on October 15th. Around the end of November, I knew I was going to have most of December to spend on some new game idea, and “Snake Shapes” was just one of many ideas that were competing for my attention. It wasn’t actually what I considered “the best idea”, but it was one that I thought would be “quick and easy” to prototype using a new written-in-swift version of my Generic Game Model (GGM) library.

Anyway, the idea for the game was a turn-based version of Snake, where you try and form shapes (initially just squares) with your tail. This evolved during development a bit to have less emphasis on the actual shapes created. I was going to have a pop-up every time you created a shape, saying how many of that shape you’d created, and giving extra points for shapes that hadn’t been created before. I did not implement that aspect. Every time the snake moves there is something new that gets added to the gameboard. The first 8 are fixed pickups of only two colors, but they are randomized after that, and every 4th thing added is a “wall” square that you cannot move into or through. The game as it is currently is just to get the highest score by eating things and making shapes with your tail until you run out of room to move.

I did spend a bit of time trying to brainstorm different names for the game. I might use the terms “Snake Shapes” and “Square Snake” interchangeably, because I’ve called the project both things, and frequently mix them up. I did also try to entice my 11 year old (who is getting quite good at making art in Procreate) to make artwork for the game, but without any luck.

At some point I had and latched onto an idea that each shape created would boost a counter for “number of power-ups” for a given type of collectible on the gameboard. I thought these would be fixed, one per type, but then I couldn’t decide what all the power-ups should do, so I decided to ask the player which one they’d like after each new square color. I implemented 6 power-ups in total, (which only took 3 days or so, including the popup, which took almost a whole day itself). They are:

• sort your tail by color
• remove half the walls on the board
• convert half the pickups on the board to a random color
• remove half the pickups on the board
• clear out a 5×5 grid around your snake head
• push every wall 1 square away from your current position

Unfortunately, one of the power-ups breaks the game by allowing the player to continue to play indefinitely. Can you guess which one?

Updates to Generic Game Model

I have written a bit a few times about Generic Game Model, but I’m especially proud of a talk I gave about the library to the MN Cocoaheads in 2014. That original version of the library was written in Objective-C, and for at least a year or so, I’ve been working periodically on a new version written in Swift.

Because I haven’t really had a specific project to use it on, I’ve mostly been trying out different things as the mood/whim strikes. For instance, at one point I really wanted it to be a swift package, and you can find a version of it on GitHub that kind of works, but I ran into so many problems using it that way (specifically for Square Snakes development, and while the package is “in flux” so to speak) that I just copied all the files in the project. (I still need to copy the files back out of the project into my package again, as there have been a ton of changes and improvements.)

Another thing I spent extensive time working on was deciding how much to embrace SwiftUI for this iteration of GGM. There’s another repository on Github where I decided to ONLY use SwiftUI, and I abandoned that idea too, after numerous headaches. I think I might know enough now to give that version another go, but I have some concerns (possibly unfounded) about performance, particularly in regards to animation. (SwiftUI does have animatable properties, including offsets and frames, but it was unclear how complex animations would be possible, and animations weren’t the only place I was seeing performance issues, but they may have been my fault entirely.)

What did I really accomplish here?

What am I proud of about working on this game? It’s not really the game idea, frankly. I proved it out, but sadly, I think it’s more fun to play without the power-ups. That said, there are a lot of different directions I could take it, and it could be that it just needs some tweaking in one direction or another to be fun. At this time, I just don’t think I’m going to spend the time necessary to figure that out.

Mostly, the tech was fun to build, and I’ll list some aspects of that here:

• SwiftUI – It was surprisingly quick to build out new screens with SwiftUI. I used it to build essentially everything outside of the game grid itself, including a bunch of tutorial screens, and a popup that asks you to choose which power-up you want to associate with the color of square you just made. I’m not sure it would work in a “real” app, but I was pretty happy with the structure of the State object that controls all of what is displayed in the Application.
• Xcode Cloud Build – This was one of the last things I did on the project, but it’s a fun one. It was only a day or so of work to set up the project so that when I push to the GitHub repository, Xcode Cloud will create a new TestFlight build for me using the new changes. It’s kind of amazing that, as a solo-indie developer, I can get continuous integration working on a project in an afternoon.
• A-star pathfinding – This was actually something that came out of doing Advent of Code (adventofcode.com) in December as opposed to the Square Snake project, but if I hadn’t been working on the project, I am certain I wouldn’t have been as excited about the pathfinding problem. I essentially followed the A-Star tutorial over at Red Blob Games, and had it working in only a few hours. I didn’t really have a use for it in Snake Shapes, but did the work to integrate it with my library anyway, and that work paid off a few days later when I implemented the “push every wall 1 square away” power-up. I didn’t use the A-star itself, but used the PriorityQueue struct that was part of the code written for it.

What could I have done better or differently

This wouldn’t be a good retrospective if I didn’t think about what I could have done differently on this project. To be honest, even though I’m abandoning development, I’m fairly happy with how it turned out. Not happy enough with the game itself that I want to spend any more time on it, but happy with the things I learned and my progress toward making my GGM-swift library a usable tool for native iOS game development. I felt pretty “focused”, and even though what I was building meandered around a bit, I’m pretty happy with how on-task I stayed and the personal growth as a result of the project.

Here’s a few (minor) regrets:

• I would like to have spent more time on the Tetronimo aspect of the game. As previously mentioned, at some point I decided it would be “too easy” to make shapes other than squares in your tail, and abandoned that aspect of the game idea. That meant I could be exceedingly lazy with the code to detect “shapes” in your tail, and allowed me to abandon one of the aspects of the game I was looking forward to developing. (I have several Unity prototypes that do Tetronimo shape detection, and I was kind of looking forward to porting that code to GGM.)
• Also previously mentioned, I abandoned SwiftUI for drawing the game squares themselves. Because the library relies on UIKit for this aspect, it means it’s limited to iOS. If I really embraced SwiftUI, it would support iOS, MacOS, tvOS, and possibly watchOS. This is an area I’d still like to spend more time experimenting.
• I had a TODO in the project to flush out the tutorial views in the app with examples. I didn’t do it because it felt like “work” (in a way that working on the game itself didn’t), but also because I wasn’t sure if I was going to change to using images for the game states themselves at some point, and that might have necessitated re-work. Anyway, the tutorial as it exists now is pretty much the worst kind of tutorial in that it’s just a bunch of text you have to read.

Demo

Demo time. Here’s a video of a couple of play-throughs of the last version of the game, so you can get a sense of it.