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.

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.