Dev Blog #2: Learning Through Iteration

One important lesson to learn about game design: it is difficult to judge if an idea is fun before trying it. A mechanic can look elegant in a document and still be boring once implemented. StormTome is now on its third major version, and each one has answered a different question. The project has not progressed by steadily adding more features. In each cases, progress meant throwing work away and starting again with a better understanding of the problem.

V1: BladeQuest

The first version of this game was called BladeQuest. It was a story-driven game built around the idea of bringing modern tools to a choose-your-own-adventure format. I liked the concept enough to build it, but once I could actually play it, I found it boring. There is still a trailer on YouTube, although I have little interest in watching it again.

The important part was that the prototype answered the question of fun. I did not need to spend another year expanding the story or adding more branches to discover whether the basic idea was good. Once it existed, I knew it was not the game I wanted to make or play.

V2: A Better Game on a Weak Foundation

The second version moved much closer to a traditional RPG, adding combat to the traditional chose-your-adventure experience. Players could create an account, create characters, level up and collect items. In addition, and much of the world that would become Draven was developed during this period.

Having both combat and story-telling side-by-side illustrated an important conceptual problem : on their own, those experience felt lacking. It was clear that both choices and combat need to be intermingled to create a satisfying experience.

This edition also had technical issues. The whole experience was built as a monolthic entity, encompassing server, client and admin. Development felt clunky and awkward. Starting again was more practical than continuing to build around those choices.

That said, not everything was discarded. Much of the worldbuilding survived, and technical lessons learned became the foundation for the next version.

V3: Testing Mechanics

Even though this is the current version of StormTome, its has gone through some dramatic iterations. One of the early ideas was to make the combat system simple enough that it could also work as a tabletop game. The goal was to simplify a combat turn to a single dice roll. Attack, defence, critical hits, dodge, damage, and all other outcomes would all come from the same result. This actually increased the complexity of combat, defeating the whole point.

Another experimentation was to turn the experience into a story-driven dungeon crawler. The dungeon mechanic was developed and play tested. The whole thing felt kinda meh, and ill suited to the short play experience most players expect these days.

Experimentations around combat were not going better. I tried a more traditional RPG combat system inspired by early Nintendo RPGs. The combat felt so familiar and predictable that I started wondering whether the game could almost play itself. That led to experiments with systems where the player had a more active role. One approach used slot-machine mechanics. The player could influence combat by modifying the reels, which created some interesting possibilities, but the design became complicated quickly. More importantly, it did not give me the sense of control I was looking for. Other experimentations included match-3, sliding puzzle, minesweeper, and many others.

The solution was simpler, building using a combination of mechanics and mini activity. Match-3 was chosen as the mechanic for combat, as it survived the current round of testing better than the alternatives. It gave the player something to do during each turn while still leaving room for equipment and character progression to matter. That said, I wouldn't call this a match-3 game, as the mechanic doesn't define the game. I would call the core mechanic, the "one-more-time", which I will explain in a future article.

Building, Testing, Replacing

Looking back at the three versions, the value of iteration is undeniable. At its core, a video game needs to be fun. This might seem obvious to design, but a fun idea rarely survives the prototype phase. It requires careful iteration and testing.