|
When we first started developing the title, our aspiration was to build a game which casual strategy fans could easily pick up, but with enough strategic depth to satisfy the more hardcore strategist. Over the past few weeks, it became clear that we had built a satisfyingly deep strategic experience, but interacting with the game felt tedious
Panic.
Once the butterflies in my stomach had settled, it was time to look deeper into the issue.
On the surface, the biggest hurdle was the cumbersome user interface. The UI featured plenty of strategic command options but the most common tasks required at least 3 clicks to complete. However, the UI's complexity was just the outward manifestation of the over complicated game design - there were too many commands available to a user at any one point in time, but most of the commands were infrequently used ones, or just badly thought out interactions.
I had inadvertently designed a complicated game and I had not discovered my mistake until 4 months down the road - all because I had convinced myself early on that it was faster to build the tech prototype rather than 'waste time' building a pen-and-paper version.
The game design was in need of some major work (for the third time).
This time, I was determined not to repeat my earlier mistake. After spending a week coming up with a core activity re-design, I started building a low fidelity prototype using game pieces from my board games collection, and some additional counters and tokens from the corner dollar store.
 - I used components from the 'Halo' boardgame along with some dice and counters from the dollar store
The results were extremely positive.
I translated the core activity into a board game equivalent in less than a day. My partner and I then spend a total of 4 days play testing and refining the core activity. At the end of the play tests, my business partner had a clear idea what it was that we were building, I had a clear data suggesting that the game complexity problem had been resolved without compromising strategic depth (much), and we both had renewed confidence that the game had strong potential.
 - The first low-fidelity game prototype I built
 - My second low-fidelity game prototype (2 days later)
In conclusion, I've learnt that most turn-based game designs are faster prototyped as a board game rather than as a tech prototype. If it's arduous building the board game prototype, building the tech prototype is bound to be worse. In addition, the difficulty in building a board game prototype may indicate a significant risk that that the design is too complex or that the design details may not have been fully thought out. In either case, it's a clear signal that the game design needs to be scrutinized deeper.
 - One of our playtests in progress. We used coloured counters to represent different terrain types
 - I used a modified MS Word 2010 card game template to build all the cards including these terrain stats 'cards'
|
Were you trying to make a turned based game or an action game? The reason I ask is if it was an action game what kind of problems did you run in to translating it in to a board game? Board game are turned based, so I'd assume that translating a turned based game in to a board game wouldn't be too complex.
Also how did you deal with stat tracking? I have to assume a strategy game may have a lot of statistics for units and the like to track, or did you have to scale some of the stats down?
My student game project was an "action" game and we prototyped it as a board game. The main tweak is to have turns taken simultaneously by both player and "AI", essentially undertaken by a human following a set of predetermined rules. If you want to simulate decision-making under pressure (like an fps), set a time limit between turns - but that can quickly become messy.
For a board game prototype you really want to boil your experience down to its core parts. That means your basic peon enemies, the fewest permutations of terrain and as simple a resource counter as possible. You can see in the pictures above that terrain only had 4 attributes: (movement) cost, attack bonus, defense bonus and special attributes. If your game is not fun with the basic rules, it probably won't be fun even with added stuff. Simple is elegant after all.
"For a board game prototype you really want to boil your experience down to its core parts."
This is true I think. But I think even a very complex game with good artistic delivery and meaning can delivery a great experience.
So while simple ideas of relational function are more advantageous in capturing immersion, the key isn't just "the grasp" but excellent sequencial meaning.
http://www.gamasutra.com/blogs/AltugIsigan/20120524/170894/Narrati ve_Articulatio
n_Through_Gameplay.php
Abstract boards can help to demonstrate things spacially, but also timing and help demonstrate interest/connectedness in something that is spacially abstract and has timing of the nature demonstrated.
So I pretty much 100% agree with you with some fidelity inclusions.
We prototyped a real-time ironsides battleship game using board game mechanics about 3 years ago. It was reasonably successful mostly because the game pace was slow enough to translate into a turn-based approach.
Regarding stats tracking, unit stats were dumped on to stock card templates (we had lots of those) and session stat changes were recorded on scrap pieces of paper. Because we wanted a system that was easily approachable by the masses, the mechanics and statistics were kept to the simplest possible. We opted to increase depth through map layout and creature variety.
I appreciated your comments about user interface. While we don't think of board games as having a real UI, the vast majority of complexity in such a game comes from what's going on in our heads. If a game is meant to simulate the act of moving pieces on a board, then players should be able to enjoy the game "at the speed of thought." Adding too many stages between idea and action makes the game feel very slow, even when it really isn't. Contextual commands (i.e. attack when clicking on an enemy, move when clicking on the ground) and quick buttons for frequently used actions, skills and so on all work to alleviate that problem. Once players are familiar with the mechanics, they don't need to thumb through pages of text or icons - they just want to get things done and see what happens.
A couple weeks ago I made a Lego prototype of a game and actually used it as my level editor.