Dit Dit Dit

When you’re playing a game, particularly a game with quite a bit of text, is there something that makes the experience worse for you? For me, it is the default use of text being dripped out in front of you, letter by letter. This didn’t always bother me, it was just always how it has been done as long as I can remember. I am sure there is a very interesting historical deep dive on this topic, how it perhaps started with Teletype games, or some other similar origin. Regardless of how it began, it has been nearly ubiquitous in the games I’ve been playing since the early ‘80s, but that definitely doesn’t mean it’s the best way to put game text into my eyes.

This method started getting to me sometime around Super Paper Mario on the Wii, when a whole cast of quirky characters had to type out their comedic lines so slowly that any humor was not just lost, but morphed into a tedious experience. Yes, you can normally speed things up with button presses, or maybe a menu setting, but that just adds a frustration point and unneeded interaction when all the developer wanted me to do was read some text. This is not how anyone reads, comprehends, and enjoys text.

Super Paper Mario RPG text in progress. Taken from full game walkthrough video here.

Thankfully, Tom Francis has given us one way to move away from this with the somewhat obvious and also genius way of showing the text one word at a time in Tactical Breach Wizards. Much like speed-reading apps and courses do, getting one word in your face at a time is much easier for many readers like me who like to just read when reading instead of pushing a button while reading.

There are other ways to move away from this too, though! For instance, Yako Taro’s Voice of Cards games, where an entire sentence or paragraph is revealed at a time. Yes, there are button presses between, but it feels interactive in a way that paces the story, and lets you actually read the text in a way that the writer intended.

Voice of Cards Text Example from Square-Enix marketing

None of this makes or breaks a game for me, as I am used to sidelining this gripe and enjoying a game regardless. I just want developers to think about it before implementing the de facto standard implementation.

Seven Day Roguelike Jam 2025

Recently, I took part in the Seven Day Roguelike jam, or the “7DRL.” I’ve been a watcher of this jam after seeing Terry Cavanagh talk about his entry a few years back, but I’ve never had the time to really give it a go. Lucky for me, I have no job right now, so I have more time than I normally would to work on something like this.

Before the jam started, I did a little brainstorming here and there about ideas, but a few old concepts I’ve had in mind for years kept insisting I give them some attention. The one I settled on wasn’t originally a roguelike in my mind, but after thinking about it a bit, I realized it was probably perfect for some classic rogue elements.

The Concept

At some point, while staring at some dice years ago and trying to come up with a simple game idea, I inadvertently came up with one that was much more complicated. The basic concept was that you play as a six-sided die, and the layout of the pips determines which spaces around your die are impacted by actions you take. Movement would involve rotating your die across to a neighboring grid square and the new set of pips on top would be what you’re stuck using for better or worse.

Early look at the die moving from one space to the next

Throw on top of this foundational idea a huge pile of elemental effects, character progression, and equipment shuffling and the prototype in my head became very complex. For a jam game, though, all of that extra cool stuff was tossed out quickly in the hopes of having a reasonable scope.

Back in a Jam

Turns out the basic scope was still quite a lot to get done for this. First of all, even though I am unemployed, I still have a family, and the sense that I should be working through some home project backlogs as well as, you know, finding a job. So, even with all of those things, I suspect I was able to get in more than forty hours of pretty solid work on this project, which is pretty good for something I was mainly doing “for fun.”

In addition to real-life time constraints, I was also a bit held back by my lack of existing frameworks, tools, and even code snippets to pull from. When I’ve previously done game jams, I had worked on similar projects in close proximity, so I at least felt comfortable pulling things like state machines and audio controllers in from those. It’s been so long since I’ve jammed, though, that it felt like digging through any of my old stuff would take a long time, and I also know anything I created more than three years ago is going to seem just terrible to me now. That means I started with a blank slate, for better or worse.

I was able to get a rough architecture idea together with some basic game and turn management without much trouble. It all had to be adaptable though, because I wasn’t even sure of some important design elements from the start like turn resolution order, enemy movement, etc. I was moderately successful at this, and by the end felt pretty good about how I would do it all so much better if I could start all over—game jam enlightenment.

Since this was a roguelike, I also had to create some level generation logic, trying to take into consideration the way your die would have to move around, especially if trying to “line up” attacks against surrounding enemies. This logic is definitely in need of a revision. It seemed to work out just fine in all of my tests, but the level layouts were generally less interesting than they could be. I thought I could come back to this at the end after some playtesting and refine the level output, but playtesting was barely even possible in the time limit so I was just glad this level generation worked reliably at the end.

Gif showing debug tests of level generation — not quite the “final” version

Other than that, my main challenges were setting up different enemy pathing routines and making sure your attacks worked correctly based on your current pip pattern. 

Results

So, did it all work out? Well, of course not! It’s a game jam! I think it was somewhat successful, though, and I came away pleased with what I got done. Getting a working game posted within the time limit and having it use a new level generation system and a pip-based battle mechanic were pretty huge. The art is passable, and the free assets and color palette I used definitely give it a look I am pleased with—except for the player’s shadow disappearing sometime during the last fifteen minutes of the jam for unknown reasons.

Screenshot of the gameplay

It had been quite a few years since I’d really committed to a game jam, and a lot of lessons learned came back to me. I definitely need to have some generic frameworks ready for use next time, and ideally would work with at least a couple other people to get something that feels more polished at the end. I’ll probably also need a good reason to do another one soon, because honestly, it wasn’t a lot of fun to have this kind of time pressure applied voluntarily. It feels completely different when you’re crunching on finishing a game for a job and trying to help a team than when you are just doing it for your own satisfaction. Still, I’m glad I did this one, and I’m not ruling out another one sometime soon.

Thanks to anyone who gave the game a try, and let me know if you like the core mechanic or not. I might revisit it later with more of the many ideas that got quickly chopped from this version due to the tight schedule.

World on a Game Board

I have never played a PC-98 game, and definitely never played the PC-98 game GAGE. It is firmly caught in my brain wrinkles, though, after I watched a gameplay video of the game. It looks fun based on what I can tell of this original Japanese version*, but I could be completely wrong! The actual mechanics of the game are a bit of a mystery to me, but I think I get the gist. In some ways, I like leaving the particulars a mystery, because perhaps that makes the level display even more enchanting. 

GAGE for the PC-98 in action

Shown as an isometrically displayed “game board,” your characters move about the limited amount of level displayed, as the board appears and vanishes off the edges as needed. No “fog of war” or “obscured angles” are used here, because there seems to be enough mystery just one space over on the playfield. This whole layout is reminiscent of Populous, but just feels different when you’re not an omnipotent overseer, but instead controlling a small character inside the game board directly.

After watching some of the video, instead of deciding the play the game, I felt like I had to hammer together a similar set of level and game board mechanics in a quick and dirty prototype. I just wanted to think through getting this made, and then most likely send the whole project away to a corner of my hard drive and GitHub to never be seen again.

First, I bashed together an architecture of sorts, trying my hardest not to expand beyond the very small scope of “working game board representation of a level.” That meant no enemies, no combat, no decorations even. That doesn’t really make managing user input, handling the input, state management, and other basics tasks simple, but I tried to keep them to a minimum.

For this, I just set things up to work with two two-dimensional arrays, one for the level layout and one for what was displayed on the board. Then set up the math to just be a simple coordinate shift from the bottom corner of the level to the bottom corner of the board. When the player shifts close to an edge, the level has to slide over one space, populate the next row and send a batch of now unneeded level pieces to an object pool. Moving around in this way was fairly trivial, with the trickiest bits being the handling of when the player gets close to the level edge and maintaining a “dead zone” in the middle of the board where the board doesn’t move along with the player.

Working prototype of the game board

Even though I didn’t go nuts getting this set up, it should be pretty malleable to different board sizes, level sizes, dead zone sizes, etc. If this were to be used for a real game, I would definitely work up an easier way to create a level. I just did the bare minimum with some brute force integer editing in code to get something to test the features. For a real game, there would also be a need for actual things of interest and different versions of walls, floors, doors, and so on of course. Again, I just wanted the movement to work.

Squint at this brute force layout array and you can see an overhead view of the level

It populates the board quickly and reacts well to all movements so far on my pretty sub-par PC. Elements are all moving in and out of object pools, and traversal of the different arrays with each move are minimal. If this concept does ever escape that hard-drive back corner, I think this is a good starting point, or at least a good set of lessons to use when making something with a full design in this vein.

Player piece at its spawn point and showing off some low saturation colors for some reason

It’s also fun to consider the options possible while working in a 3D engine (Unity) as opposed to the 2D isometric sprite work the GAGE developers had to wrangle. If the board angle looks funky to me, or the lighting off, I can make some easy adjustments without throwing out most—or any—art. For one thing, using WASD controls on an isometric board is pretty weird, so shifting to QEZC might be nice, or even rotating the board to be straight on–a concept that would lose the fun isometric idea, but maintain the game board movement that drew me in.

Rotate the camera, and we’re safely out of the isometric

For now, my need to get this concept into an engine and running has been satisfied. I’m still considering playing the actual game, but also still trying to resist one more RPG in my life. Regardless of what’s next, making this small and rough prototype was an enjoyable exercise, so I’m kind of hoping to use an expanded version of this idea someday.



*There is an English fan translation available if you feel so inclined to try that out. I would like to, but I’m already buried under officially translated RPGs to play and so I am resisting the urge.

Useful Unity UI: Beasts of Balance Bestiary

This is possibly the first entry in a possible series of entries where I will take a quick stab at recreating a cool UI effect in Unity. Sometimes it’s the simplest effects that can have a big impact, and make your interface jump from workmanlike to downright appealing. For this entry, I wanted to highlight a neat concept within the collection display of the game, Beasts of Balance.

The Inspiration

Beasts of Balance is a really clever game that coordinates physical pieces with an app. Most concepts like this just feel gimmicky, but this one is very well done and we have played it often in my house. 

The Beasts of Balance game

Part of the game is creating various beast combinations in each successive game that you play. Each new creature you uncover is recorded in the app’s Bestiary, and that’s the piece I want to focus on.

Watch the video below to see the bestiary open up and reveal each discovered critter. Please note that we use a very old iPad to play this game, so any frame rate hiccups in this video are most likely all the fault of this old device. I am sure it is smooth as silk on something that is less than five years old.

Quick clip showing the Beasts of Balance Bestiary opening within the app

Looks pretty slick, right? Each beast is unveiled smoothly inside of a hexagon. The cool part is, this is pretty easy to do, and it’s a technique that is easy to apply to any group of UI elements you might want to animate into place. I think this is a particularly strong technique for a collection manager like this, and even stronger with this flat-shaded 2D art style Beasts of Balance is rocking.

The meat of the collection reveal effect comes in the animation of each creature’s hexagon display. Having each item scale up from zero--perhaps with a little jiggle to make it cute--isn’t too uncommon of a practice when revealing a grouping of UI elements. In Beasts of Balance, however, what is happening inside the hexagon makes it look a little cooler than usual.

As each item scales up from nothingness, the creature inside is scaling smaller to fit. It’s as if a small camera is zooming out to capture the full size of whatever dwells inside the hexagon. To me, this simple effect grabs the eye and makes me want to study what is in each item a bit more closely; a nice attention grabbing technique that is easy to pull off.

The Recreation

First of all, I decided to create my own little critters for this, and I regret it. I should have just snagged some Kenney assets and moved on, but here we are. Everything in this example is intended to just quickly show some techniques, but doesn’t show the usual polish I would apply to an interface like this (with help from actual artists). Also, since my intention was to highlight elements of the bestiary’s methods, I kept the opening screen as bare bones as possible.

Programmer art creatures doing their thing

The key to getting this effect in place is using effective masking within each collection object. To make this easier, each collection item is created using a prefab with all elements in place. Some of these elements may not be necessary depending on the look you’re going for, but I was trying to hew pretty closely to what Beasts of Balance is doing.

The setup of the collection item prefab

Note that I have the drop shadow layer at the very back, and just above that is the “Mask” layer. This mask contains the masking shape I want to use (a hexagon), and its children will be masked out accordingly. Its children being the background and the “CharacterRect” object, which will have the character sprites appended at runtime. Then on top of the mask, lies the border that will hide the edges of the masking with a nice frame.

The mask image settings

This setup allows the character’s image to extend beyond whatever the current size of the hexagon is, but be masked so that just the portions inside the hexagon are visible. There are a few different masking options available in Unity now, and some are better for different situations. For this setup, the classic Mask component seemed to be most appropriate.

At the top level of this prefab, I have also applied an Animator component. This component will animate the sizing of the collection item. Note that using a separate animator for each of the items may become a performance bottleneck, especially when we’re also dealing with a scroller. If you actually use a technique like this in a project, refer to this excellent guide to clean up any of these slowdowns.

When the user enters the collection, a BeastsCollectionCanvas.cs script clears out any existing collection items and spawns in new ones to fill up the scroller. My simple script allows you to set the number of items from between 10 and 100, and it will just randomly use one of the three critters I created for each one. I also allow the time between each character’s reveal to be varied, and this just allows for a slow uncovering of the whole collection, similar to Beasts of Balance.

Despite my programmer art, I think the reveal effect comes across well and it illustrates how easy it is to pull off an effect like this in your own project.

Refinement

Maybe I’m being a little tough on my own art—the first thing to be overhauled—but there are other things to fix up as well. If I were to implement this into a real project, I would create a better transition from the main menu into the collection. For now, it just pops from one to the other, just like Beasts of Balance does. Does anyone notice this while playing that game? Probably not, but it’s something I would personally try to smooth out.

The text here is a bit washed out, and I would probably try swapping to TextMeshPro in place of the standard UI text elements. I must note that I am pretty sure I am using the exact font used in Beasts of Balance, which I just stumbled into while looking for something similar. It’s a really good font, and free to use!

There are also many optimization tactics I would put into this project, even before a slowdown was apparent. Again, this link is a great checklist to go down periodically when developing a user interface with Unity. It’s hard to get too into the weeds on a sample like this since there is no definitive architecture that this fits into at this point, so I treated it all as a simple standalone project.

Take a look through the project and its hierarchy to see how each piece fits together if you’re interested. Feel free to borrow any of the code or pieces that will make your life easier too! I have no plans to extend this into a part of any current projects.

Also, if you have any cool UI effects you’d like me to try and recreate, I am up for a challenge. Please leave a comment with your suggestions/requests!

Bonus Note

When prototyping, I often use a little trick to not add a bunch of cruft to a project early on. Sometimes, this trick even gets used in final versions of a project depending on the platform and style I am working with--it’s very mobile friendly!

If you need a nice looking background quickly, you can create a texture that is 2x2 pixels. Then use different colors to get a nice gradient effect when the bilinear filtering is applied. This is the tactic I used on the background for the characters in this sample project. You can also just make it a 1x2, but I like to go ahead and get rid of any Power of Two warnings in the inspector.

Space saving gradient background

I have fallen back to this little tactic while frantically finishing game jams, but also when prototyping. When used in the right situation, it can look good enough to stay in a production release.

When the Map Makes the Dungeon

After playing the classic dungeon crawler, Eye of the Beholder for a few hours, I had a wacky idea that I needed to throw together. Playing a classic like this normally requires mapping the catacombs by hand as you go. This is a big change from more modern games, like Etrian Odyssey, where the mapping is built right in. This somewhat tedious, somewhat meditational practice made me wonder if it would be fun to create the dungeon as you map it, instead of vice-versa. Then a whole flood of mechanics came to mind that could go along with this, but the first step was a must: have the dungeon build  itself from the map you make.

This is a prototype-prototype, so no definitive game was expected at the planned end of this exercise. I just wanted to rough out the concept and see if it felt like it had any legs. Everything is in Unity, and my rudimentary pixel art was done with Pyxel Edit.

Basic Layout

The biggest chunk of this project was building a mesh for the actual dungeon geometry as you lay out a map. To keep things simple (and classical, like Eye of the Beholder), I stuck with a nice grid of squares to represent each dungeon tile. Since I was trying to be speedy, I decided I would rely on raycasts to the dungeon grid plane to place the tiles. Each tile is one unit squared. 

My simple plane with grid atop

I placed an orthographic camera looking down on the grid to capture mouse clicks to place the tiles. This could be considered a secondary camera to the primary, first-person view. You can see how I use this mapping camera over in my somewhat sparse UI on the right.

Editor view showing the first-person view and the ersatz UI

From the first person view, you can see the empty grid spread out in front of you. I tied ray-casting to the orthographic camera in the UI so that when you hover over a grid space, a highlighting object appears over that grid square, visible in both the UI and the first-person view. Clicking on a tile will add that tile to the dungeon mesh. This is when the actual mesh making begins. 

Mesh Making

I split the dungeon into three mesh sections: floor, ceiling, and walls. The floor and ceiling are the most straight-forward. With each added dungeon tile, a four-vertex mesh is added to the existing floor and ceiling meshes, composed of two triangles (your typical square, folks). Each mesh has its own material, with its own tiled texture. For now, there is no variation among the tiles of each mesh, although this is something I’d like to implement.

A view looking up at the generated ceiling mesh with its texture applied

As stated earlier, I am just using one mesh each for the ceiling and floor, so new tiles are just added to the vertex, triangle, and uv arrays. The relative position of the different added tiles didn’t really matter at this stage, but I did keep track of each tile as it was incorporated into the mesh. This comes in handy when I started adding the walls.

To make the walls, I assumed that any floor tile with an adjacent floor tile would not have a wall between. Essentially, each space between walls would be an entire tile. So, as dungeon tiles are selected to be added to the mix, each tile’s custom class is updated to record which adjacent tiles are populated.

Cycling through each populated tile and placing walls on the sides that require them, and ensuring that the visible side is facing the side with the floor. In this quick mock up, I just clear the entire wall mesh and make a new one. This is what needs a major coding update, but wasn’t really required to prove out this concept. 

You can see how it all comes together in this short video I made placing the tiles and then doing a bit of exploring.

A quick look at the Dungeon Maker concept

Future Ideas

The first step would be cleaning up the mesh generation a little, primarily with the wall methods mentioned. This would just involve some optimization of array manipulation for the most part -- this I will probably do regardless of any other additions. Also, some texture variety is needed, and I’ll have to gin up a shader to help with this, in addition to deciding if the textures will be random or intentional based on certain factors.

Outside of basic code and art improvements, I have had several ideas to make this into an actual game. Perhaps it would be fun enough to build a dungeon to reach a known treasure location? Certain obstacles could be in the way making this a bit more of a puzzler than a dungeon crawler. Maybe it could be a timed dungeon escape as a one-hit-kill monster or hazard chases your character as you map and run out of the created dungeon. Both of these ideas have some merit, and shouldn’t be too difficult as an extension of this prototype to test out.

Almost all of my other ideas involve digging into a combat system of some sort, and the options there just kind of explode. This is my main hesitation from continuing this for now. Not that I don’t want to work on such a thing, I just don’t have the time to commit to doing it well at the moment.

If you want any more details about how this was done so you can start doing something similar, feel free to send me an email and ask. No deep trade secrets here, and I’d love to help get someone started on a dungeon diving game with a twist.