Development History

(don’t read this, it’s too long, but it was fun to write the whole history down—for posterity)

I’ve always liked strategy games even though I’m not that good playing the deep ones like Chess and Go. When I was very young my favorite game was Chinese Checkers because I liked hopping the marbles along the chains of other marbles. I liked multiple hops in Checkers too but the diagonal lines of movement on the Chinese Checkers board were more fun for me. Chess had an interesting collection of different shaped pieces (castles were my favorite) but I had trouble keeping track of how they all moved when I first learned to play, so I lost a lot of games.

My family would buy a new game each Christmas to play together and at some point I started reading GAMES magazine to get their recommendations. In the early 80s independent games began taking top awards. One that impressed me was Kensington, not because of the game itself, but because it was invented by a couple of guys who weren’t working for a big game company. It got me thinking that maybe I could create a game.

Piecing it Together

In 1983 I took all the parts I liked best about my favorite games and started to invent a new one. I used a hex board from wargames that had become popular in the late 70s. I preferred the hex spaces because I thought moving across the diagonals on a grid looked awkward. With a hex grid, a move from any space to another was an equal distance. I was able to buy a generic vinyl mat from the local games store. I had just learned how to play Go and I loved the Go Stones, so I used those as my initial pieces (again bought from the games store). In fact, I later incorporated the flattened-sphere shape of Go Stones into my piece designs for the manufactured version of my game because it made them easier to pick up.

I wanted to keep the rules and gameplay as simple as possible to make the game easy to learn and play. My first idea was that the pieces were rabbits which would hop out of a hole and jump over each other trying to get to the other hole (which is really just a Chinese Checkers variation). I soon ended up with too many pieces on the board. That’s when I added a more powerful piece that could capture the enemy pieces. I used two plastic Chess pawns I bought from the game store to represent the more powerful pieces.

Adopting a Siege Mentality

Many of the classic abstract battle strategy games like Chess and Go are about capturing pieces to win the game, but I’ve always preferred territory-capturing games. The outdoor game, Capture the Flag, was my idea of a perfect battle game. Capturing players was incidental to the goal of getting to the opposing team’s Base.

I liked games where all the pieces moved the same, but I also liked the Chess queen’s power of being able to move all the way across the board in any direction—especially when contrasted with the king’s limitation of only moving one space. When I started thinking of the pieces as rulers and subjects it made sense that the ruling piece would have more individual power and that the subject pieces’ strength would come from working as groups. So I made all the pieces able to move the same way, then added the extra abilities of sliding and capturing for the ruler piece.

I imagined each home space as the throne of a castle. I put each pawn on its throne and surrounded it with six Stones so they formed a wall around it. Because those pieces couldn’t fight, they were really more like the Stones of a castle, so I molded a set of black and white blocky hexagonal pieces out of modeling clay. I made the more powerful pieces hexagonal Columns the height of the six stacked Stones to represent the balance of power between the ruler and subjects. (Those Columns tended to tip over, so I later widened the base in my design of the plastic pieces for the manufactured version of the game.)

When I was deciding how many spaces to have between the Bases I picked the shortest number that still allowed for some multiple hops. I set the distance so that it was possible for a Column to jump in a straight line over three of its Stones from its Base to the opposing Base—though I later discovered that was unlikely to occur in actual game play. When it came time to trim my vinyl mat to a final board size I used the center space to each side of the Bases—where a Column could diagonally either threaten the opponent’s Base or return to its own Base—to determine the outside boundaries of the board. Once that width was established I cut the rest of the edges of the board to form an even hexagon.

Creating a Balance of Power

Because reaching the Base was the goal, I had to find ways to protect each Base so the game wouldn’t just be a race across the board. Likewise I couldn’t just have the Columns capturing all the opposing pieces, or it would only be a battle. I wanted the game to be like a castle siege where each team would be attacking and defending at the same time.

By making the rule that a Base could be only be protected from capture when the Column was on it I made sure a choice would have to be made between attacking and defending with the Column. Since it would only be able to capture pieces by leaving the Base, the Column would need to protect its Stones so they could keep blocking the Base. Plus, it could only easily capture the opposing pieces when its Stones were threatening the opposing Base. That trade-off of powers for the Column forced all the pieces to work together as a cooperative team.

Designing and testing the game rules and strategy by myself was a challenge since I knew what each ‘player’ was planning to do. I had to avoid planning my moves too far ahead to play out a lot of the possible losing strategies. As I played through many games I learned the strategy of protecting pieces by threatening the opposing Base or pieces. I was happy to find that my original set of simple rules held up during all the test games. The only odd rule I added was the one that allowed pieces to hop over their Base, which made it easier for Stones to protect the Base.

Naming the Game

The game has had a number of names during its development. Originally I thought of it as having a lot of opposite qualities, so I called it Yin Yang. Years later I made the logo for my game company, Harmony Games, by reversing half of the board to black along an ‘S’ curve of the spaces, with the Bases forming the dots like on the Yin Yang symbol.

After I created the blocky hexagonal pieces I renamed the game Stones. That was the name I used when I sent it to a games agent in the hopes of being able to sell it to a company like Parker Brothers (the agent passed on it, since the best selling games at the time were party games like Pictionary® and Jenga®).

When I manufactured it myself eight years later I chose the word batalo (meaning battle) from the artificial language Esperanto, figuring it would sound familiar enough to be understood but unique enough to trademark. I modeled it on the popular game Pente® and silk-screened the board on vinyl which rolled up in a cardboard carrying-tube with a bag of plastic pieces I had custom-molded. My friend, Bob Rhett, inked beautiful illustrations for the corners of the board and for the rule book. The rest of the graphics and text I created with desktop software on my Mac.

Batalo® was listed by GAMES magazine in their list of top 100 games for the first two years I sold it, but my packaging design and my lack of marketing skill (and funds) didn’t move enough games off the shelves, so I only sold a few thousand of them. There are still a few being offered for sale by Kadon Enterprises.

For my iPad version of the game I’ve chosen a new name that is a combination of the original name and the published name, but is still unique. I’m happiest with the new name, BattleStones, since I think it evokes the original spirit of the game where the Stones act as both the soldiers and the walls of a castle.

Adding Intelligence

The biggest problem with getting people interested in my game was that no one knew how to play it. Unlike Chess or Checkers, people weren’t going to be able to learn it from someone else. I’m not a very social person, so unlike the inventor of Pente (who I consulted with when I was producing Batalo) I was not inclined to hang out in bars or cafes challenging complete strangers to teach them the game. That meant that the best way for people to learn to play would be against an artificial intelligence (AI)—one that was at least good enough to teach the rules and hopefully be able to win.

I’ve always been fascinated by AI because I read a lot of science fiction (and I loved the idea of a computer friend who would play games with me). I was lucky to learn coding when I was in high school, but that was in the early FORTRAN days of punch-cards when computers were challenged by the simplest tasks. I studied Computer Science briefly in college, only to quickly realized the math was way beyond me. Years later (shortly after I first designed Stones and had it rejected), I bought an Atari and programed a text-only game (like Zork®), but the logic for that game was really just routing choices. I couldn’t begin to imagine how I would create a player for a strategy game.

Indie Game Developer

It wasn’t until I bought my first iPhone in 2009 (I think that was the year the App Store opened and Apple started letting independent developers sell their apps) that I got “gold fever” and started thinking about creating a game that would become a big hit. First though I needed to learn how to program again. Fortunately I had worked on a number of websites that needed Javascript to process orders and I had reverse engineered the code enough to feel confident that I understood the syntax. All I needed was a great idea for a game and a game engine to help me build the graphics.

I read up on game design and realized that the best simple game to start with was the one I had already created—Batalo. I wouldn’t have to create levels to keep the game interesting since the variety would come from players choosing different strategies. I just needed to create the board and pieces and set up the interface for touch, which was a perfect fit for a board game. I could use a new and inexpensive game engine called Unity3D to create 3D pieces which I could program to move by themselves and it would look a lot like my physical game.

This was before the iPad, so I had to program in zoom since the board was too small for most people’s fingers, and I messed around with all the new touch controls like rotating the board with two fingers. When the iPad was released the next year I quite working on the iPhone version and just focused on the larger real estate available. I still knew that the AI was going to be hard but I had found a book on AI for games that had psuedo-code for Chess-like games that I hoped to adapt. I had a working version accepted by Apple that year to hold the name BattleStones but I pulled it from the App Store because I didn’t believe anyone would want to learn to play the game without having a computer opponent.

I created a rough demo AI that was not very bright and made obvious blunders. This was just to show off the game to my family. Then I dived into developing a MinMax algorithm. This turned out to be taxing beyond my expectations. Not only was my computer too slow for me to test it quickly, by the time I had something working a year later, it ran too slow on the iPad and still did not make very good decisions. I gave up, burnt out from spending too much time on the computer (my full-time day job was also computer intensive and my wrists were starting to bother me).

Part of what stalled me was the useful features I had incrementally added—like undo and redo, a test mode where I could place pieces to run the AI through specific scenarios, highlights that showed future possible moves of pieces, etc. While these were helpful as I kludged together a simpler AI that was based on prioritized choices and a shorter look-ahead, they ultimately created too many bugs. I realized I was going to have to start over to have clean code that I could maintain. But now that I knew how long it might take to do it, I could no longer justify the time. Only a few games were making money in the App Store and paid strategy games were not the most popular games.

Simplify

After ignoring it for another year or so I realized I simply needed to finish it so that I could have at least the sense of accomplishment (similar to having created the physical version and getting it out into the world). Since the extra features I had added were causing too many bugs, then I could just remove them. My AI really only needed to be good enough to teach people the rules, and maybe some strategy. People could play against other people just like with old-fashioned board games.

I stripped out everything except what was absolutely necessary to play. Now that my code was simpler, the game no longer crashed, except where the AI had logic errors (or more commonly, code typos). By this time I actually had developed three different code scripts for analyzing and making decisions. I figured that maybe by using parts from all of them the AI would be good enough to beat beginning players and then they could move on to challenging human players.

This turned out better than I had expected. Once I had rooted out some major logic errors and rebalanced the priorities based on how much control the AI had over the board, it turned out to be smart enough to even give me a hard time. It was even able to solve the puzzle of how to pin the opponent’s column and capture all the other pieces to force the column to move off the base.

To be Continued?

For now I’m happy to have the game out in the world again. If it does prove to be popular I will start over (probably hire a professional programmer to create some rock-solid code and get the MinMax working—now that iPads are fast enough), add back in all the cool features I removed, make it possible for people to play each other remotely, etc. At the least, I will be porting a version to the OUYA console—just altering the interface to work with a controller—so look for that to appear soon.