💾 Archived View for moddedbear.xyz › logs › 2023-01-03-thumby-coding.gmi captured on 2023-05-24 at 18:06:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
I got my hands on a Thumby handheld around summer last year and have been enjoying it since.
If you haven't heard of it, the Thumby is a tiny Gameboy-looking handheld the size of a keychain. No matter how many photos of it you see online, you'll still catch yourself saying "Dang, that's small!" once you see it in person. But here's a photo anyway.
Photo of the Thumby sitting in the palm of my hand.
It comes preloaded with several games, most of which are decent fun. But the real fun I think comes from loading games made by other Thumby owners and creating your own. It takes the Thumby from being a neat novelty to something you'll really want to always carry around on your keychain.
I finally found an opportunity to dig into the Thumby's game creation process this past December when I made a little top-down tank game. It's called MicroTank and has recently been added to the Thumby arcade if you're interested in checking it out.
The Thumby code editor runs in a web browser -- and it has to be a Chromium browser because of the API it uses to talk to the Thumby over USB. That's not ideal but it works and it includes some nice features like an emulator and bitmap editor for sprites. Games are written in Micropython which makes it pretty approachable.
I've played around with making simple games for fantasy consoles like the TIC-80 before. Coding for the Thumby feels very similar but ultimately a lot more interesting because you're targeting a real, physical device. You have to get creative to make something fun that fits within the limitations of Thumby's power, size, and monochrome screen. I've found that coding under restraints does great things for boosting my creativity while also keeping things light and not too serious.
The most difficult restraint to work around is definitely the screen size. The pixel dimensions are only 72x40 and every aspect of the game from art to level design has to carefully consider that.
The second most difficult is the Thumby controls. They're just tiny. Usable, but tiny. Games that require fast and precise inputs usually don't play super well. Creating a tank game with full d-pad controls was a little risky, but I think it works well enough.
I experimented a bit by enlisting ChatGPT to help a little bit on the game. I didn't have it generate any code obviously; if you've ever tried that yourself you'll likely quickly realize it's more trouble than it's worth to make sure the generated code is both bug-free and does what you asked it to do.
What I found is that ChatGPT is a pretty decent idea generator. At one point in development I was needing to test line of sight between each enemy tank and the player. The most obvious solution is to do a raycast from each enemy tank to the player, checking along the way to see if you've hit any obstacles. But I was curious if there were any alternative solutions that I should also consider, so I had the following conversation with ChatGPT.
Me:
I'm making a 2D game and need a performant way of checking if enemies have line of sight to the player. I'm not working with an existing engine so I can't just rely on a Unity or Unreal engine feature. I'm thinking of doing raycasting but am worried that could be too slow so I'm open to other solutions
ChatGPT:
Raycasting can be a good option for determining line of sight in a 2D game, as long as it's implemented efficiently. However, there are a few other approaches you could consider as well.
One option is to use a grid-based approach, where you divide the game world into a grid of cells, and then use a pathfinding algorithm (such as A*) to find a path from the enemy to the player. You can then check if the path is blocked by any obstacles. This approach can be very fast, since the pathfinding algorithm only has to consider a small number of cells.
Another option is to use a visibility graph, which is a graph data structure that represents the visibility relationships between the different objects in the game world. You can use a visibility graph to quickly find the shortest path between two objects, and then check if the path is blocked by any obstacles. This approach can be faster than raycasting, especially in cases where there are a lot of obstacles that would require many raycasts to check.
Finally, you could also use a combination of these approaches. For example, you could use raycasting to quickly check for obstacles in the immediate area around the enemy, and then use a pathfinding algorithm to find a longer-range path around any obstacles that are found.
It's worth noting that the most performant solution will depend on the specific requirements of your game and the hardware it will be running on. You may want to consider profiling your game to determine which approach works best for your needs.
I'm not a game dev, but those all seem like decent solutions to me. Completely overkill for my game, but cool anyway. In the end I stuck with a slightly optimized raycast solution since I'm only ever dealing with a couple of enemies and a handful of obstacles at a time.
I had a lot of fun on this project and I'll definitely consider making more Thumby games if ideas come to me. There's something really neat about carrying around a keychain handheld with your own games on it.
- moddedBear / 2022-01-03
