Sim High (aka Class of ‘96)

In the early days of my career I had uncapped energy for making games. So, although I was programming a game professionally for 8-12 hours per day, I somehow still had enough energy to spend my available weekends and evenings also programming games. And so it was that while I was making what would eventually becomes Mercenaries at Pandemic, I was also making a little indie game on the side with a then-colleague of mine (Katy, also with an insane amount of energy to make games).

There were two things about this game I’d say were notable. First was the theme itself. We were making a high-school themed strategy RPG. Since Bully was not out yet, and Japanese high-school games such as from the Shin Megami franchise were not really known in the west, I think our idea was fairly unique.

Second, it was for the Game Boy Advance. I didn’t have an official GBA dev kit, so I had to work with an enthusiast tool chain that included a C++ compiler and which generated ROMs that could be run in a GBA emulator. At one point, I even got a physical ROM burner, and was able to run the game on actual hardware. It was really neat!

As a result of this project, my first on sprite-based hardware, and my first working so directly with the integrated circuits, I did many things I’d never done before. For example I programmed an omni-directional scrolling title engine (not at all trivial on sprite hardware), as well as a custom memory manager to handle large and small allocations and stave off fragmentation, and I implemented DMA (Direct Memory Access) transfers to keep things at framerate. I’d never worked so close to the metal before, and so making this game was as enlightening as it was fun.

Unfortunately, in the end it became yet another game on the pile of shame of unfinished projects. But nevertheless, it was a worthwhile endeavor for the educational value alone.

At Sea

The exact time line is rather muddy now, but I believe this was my next project after Sim High. At the time I was blown away by flash game called “Grow”, in which the user would click on various things on screen, with each click causing the scene and story to change in wholly unpredictable ways, all related to the things the user had clicked on already. Because of the order-dependent nature of the results, the seemingly combinatoric number of outcomes, and the sheer quality of how each was portrayed, Grow was beyond merely entertaining - it was astounding.

So I wanted to make a game like that, with all it’s surreal insanity, but with a bit of a survival-game edge, and perhaps some board-game like systems to add a hint of predicable player control. As well, I wanted the game to have a decidedly indie vibe to it (Though at the time I don’t think I could have articulated it that way - “indie” as an aesthetic was not well established then). And I wanted the game to be animated with a subtly magnetic appeal, from the waves, to the sun, to even the player pointer and menus.

Though I didn’t complete this project (what a surprise!), I think I was achieving some of those goals. The prototype game DID have a certain appeal to it, and while simple, I always got really positive feedback whenever I showed it to people, even other industry professionals.

Why did I stop working on it? Probably because I got distracted by the next shiny object in my ADD brain - a project I called:

Ninjas!

In my early career I was always amazed by Sid Meier games. I loved the way they made your brain feel, fostering something like an addiction (just one more turn!) but not unpleasant. As a game creator, I wanted to understand how a person even went about designing a game like Civilization, with all it’s deep and interrelated complexities, let alone also finding some kind of stickiness within that. And for a while it was a complete mystery to me. That is until I played Digital Eel’s Strange Adventures in Infinite Space, and realized this: Sid Meier’s games, and games like them, were computerized board games, and that if I wanted to understand their design, I needed to understand boardgame design.

So I studied boardgames (and ended up permanently in love with the hobby), and after a while I was able to at least meaningfully analyze Sid’s games. In fact, once I had the right lens through which to view games design, I saw boardgame-like thinking in almost every videogame. Being able to think like a boardgame designer, I feel, became something of a game design super power that allowed me to more easily understand other games, and importantly, to better design my own - a super power that I still rely on today.

Anyway, I digress a bit. Ultimately what lead to Ninjas! was an analysis and love of “Sid Meier’s Pirates!” and a real itch to make a game like it. Also at the time ninjas were seen as the flip-side of Pirates - I don’t know why. So altogether, it seemed obvious that I should make “Ninjas!”

Probably the most interesting technical feature of Ninjas! is that it’s an isometric tile game. I actually used a version of the Sim High tiling engine here, modified as needed to support the isometric view. Also neat is that the map data was built from a real map of Japan, and you can see the accurate terrain in the mini-map in the screenshots above.

Chess Quest

The last project from this era worth mentioning is Chess Quest. This came about from my interest in two things. First, most obviously, was my lifelong interest in chess. Second, was a little game called Puzzle Quest.

Puzzle Quest is a genius game, that even now, as I type this, I’m thinking, “I should play it again!” What amazes me most though is that I like it at all. At it’s core it’s a match-3 style puzzle game (the most famous game of this format being Candy Crush), and I hate match-3 puzzle games! Their core gameplay is banal and mindless. So why do I love Puzzle Quest so much? I realized it’s because it uses what I consider a magic game design formula.

I first encountered this formula in another classic game, X-Com UFO Defense. The idea is this: take a reasonably interesting core game (aka, tactical game, aka second-to-second game), and pair it with a equally compelling outer game (aka strategy game, aka minute-to-minute game), and make those two inter-dependent such that good results in the strategy game help your tactical game, and vice versa, and you have design gold - or rather, some form of crack-cocaine.

So many great games have a version of this design pattern at their core (for example, The Walking Dead, Saints and Sinners), because the forumla really is magic. It can even make a crappy core game (ie match-3) compelling! And if that’s the case, then what could it do for a good core game, such as chess?

So was born Chess Quest - basically a Puzzle Quest like game, but with the core gameplay being a more interesting chess-like game mode. I say “chess-like” because the idea was to lean on chess ideas, such as basic move and capture rules, but do creative things such as use new maps (boards) and have different win conditions.

Though again I did not complete this project, its creation came with a nice technical centerpiece. I speak of the chess AI engine of course. For Chess Quest to be any good, it had to be able to play reasonable chess. So, I learned about the mini-max algorithm, board state representation, tree-pruning methods and other optimization techniques. It was all very educational, and despite not finishing the game, the understanding I gained added value to my development repertoire and forever enriched my own enjoyment of chess.