Marc Majcher

Marc is just this guy, you know?

Jun 042006

Well, I said that I was going to talk about ways to overcome design blocks, but it looks like I’ve been distracted by the worst kind – something shiny. It’s always easier to let my attention drift away from something that I’ve got in some kind of decent shape to pour some energy into a new project (or a new phase of an ongoing project), instead of steaming ahead. But that’s okay – working in parallel allows me to apply things that I’ve learned in one area to another, so, let’s go with that.

The shiny thing in question here is, of course, “Hive”, the board game that I brought out for playtesting on Friday, which Dan was generous enough to give me a good amount of very useful feedback on. The game is in the late stages of prototyping and playtesting, and I feel like it’s pretty solid right now. The prototype that we played on Friday was the same one that I’d slapped together last year, just some glued-together construction paper for counters and a very poorly sketched and cut apart game board. Dan’s feedback impelled me to polish that part a bit, so that this next round of playtesting won’t be so painful – as much time was spent trying to hold the board together and keeping pieces from moving around as was playing, I think, and a better quality prototype will allow me to focus on making a few final tweaks to the gameplay, without having to spend all that time apologizing for the sorry state of things.

So, I sat myself down yesterday and fired up Inkscape and before too long, I had a spiffy looking new version of the board ready to go. A quick trip to Michael’s craft store in the afternoon got me all the bits and pieces that I needed to glue up and cut out the new board, plus a bunch of other goodies that I’m sure will come in handy one of these days. The counters are another issue altogether, though. They’re supposed to be 1″ hex shapes, with printing on both sides, and they need to be a bit thicker than the previous ones, as Dan mentioned, to make all the flipping a bit less odious. I brought home a few different kinds of materials to try out, with varying levels of success. I printed out the counter art on some full-size label paper, and went to town. My favorite ones so far are the 1/8″ balsa wood counters, with the stickers on either side, but each one takes a couple of minutes to cut and assemble and clean up, which is a bit prohibitive for the number of counters that I’m looking at producing. Fortunately, I also made a trip to a teacher supply store on the way, and picked up a few things, including a bag of 1″ two-color counters. A little sharpie magic, and I’ve got some eminently usable markers for the game – round, not hexagonal, and nowhere near as pretty as the ones I mocked up, but they’ll do the trick.

So, enough about the look and feel of the game – how does it play? Dan summarized the rules nicely in his post – one of my primary design goals with Hive was to make it as simple as possible, but it’s possible that I may have run too far in that direction. The full rules for the playtest version are literally short enough to be written on an index card, which I like a lot. While there are a couple of strategies and counter-strategies that emerged during the initial round of playtesting, it’s possible that casual players may find the game play a little “flat”. I added some optional rules in an attempt to address this – such as the corner cells scoring double – which will require some more play to work out the details. Hopefully, this will break up some of the clumping behavior that we observed, and lead to some new play angles – I’ve worked them out a bit in solo testing, but more brains will really bring out the wrinkles.

There are still some design issues that I haven’t been able to fully address. One that Dan mentioned, keeping track of the direction of the tiles when they are flipped, has vexed me since the very beginning. To be honest, I’m not sure that there really is a solution to this one – I’m just planning on making the counters as clear and easy to handle as possible, and hope that the players can work it out. The other issue that bugs me is during setup; the players must sort out their piles of counters without them being clearly marked as to which ones belong to which player. I do have a solution to this one, but I totally forgot about it in my eagerness to pump out the current batch of tiles, so it’ll have to wait one more go-around. Fortunately, it’s mostly a cosmetic hiccup, and shouldn’t be too big of an issue in testing.

Dan also mentions that he’d like to see some kind of numerical analysis of the optimal scores on each move. I have to admit, I’ve done very little number crunching on this one – the concept seemed simple enough, and tested well enough initially (after the usual fiddling and grumbling) that I didn’t really feel like it was necessary to break out the spreadsheets. Maybe I’m wrong – it’s definitely something to look into. Mischa also brings up a couple of ideas in his reply to Dan’s post, which intrigue me. I’m not sure I’d want to cut down on the range of numbers for the tiles – I like the amount of granularity versus complexity with 1-9, as opposed to, say 2-4-8, but I’m not against testing some alternate number spreads. I do really like the idea of allowing the players to rotate their pieces in some way, but I think I’d like to get what I have now solidified before throwing completely new stuff in.

All in all, Hive is feeling very close to done. I’m very much looking forward to busting through the next round or two of playtesting, and then moving on to the next phase – finalizing the visual design, and then trying to figure out how to manufacture, sell, and distribute the little guy. Fun, fun. As usual, any other input, comments or thoughts are greatly appreciated.

(Historical note: Hive was originally intended to be a chronic mini-game in a larger online science fiction massive-ish multiplayer game, in the vein of Pazaak, Triple Triad, or Tetra Master. The over-game, Parallax, was shelved indefinitely, but Hive took on a life of its own, in the non-virtual world. This is one of the joys of designing in multiple game media – things like this, or like Wu Xing, going in the opposite direction are bound to happen.)

Next: Zombies!!!

May 302006

I’ve had a design rolling around in the back of my head for a while, involving the Chinese five elements – wood, fire, earth, metal, and water. I’ve always been intrigued by the cyclic interactions of the five elements, and how they could be used as elements in a game. In the generative cycle, wood burns and becomes fire, fire turns into earth (ash), earth generates metal, metal melts and becomes liquid (water), and water creates wood again; in the complementary destructive cycle, metal destroys (chops down) wood, wood consumes earth as it grows, the earth can be used to block the flow of water, water quenches fire, and fire melts metal. The connections can seem a bit strained if you think about them too much, but for the most part, they’re intuitive, and have some nice effects when applied to gameplay – they represent two sets of pre-existing rock-paper-scissors relationships, and each element has a number of correspondences that can be used to add flavor.
Cycles of the Five Chinese Elements
My design was originally intended to be a board game – perhaps using an Icehouse set and a chess board – but after some fiddling around and pondering, I decided that it was more suited to implementation as a puzzle-type game on the computer. I had a free day over the long weekend, so I scribbled out a page or two of notes, and started throwing together something that I could knock out in pyGame or Flash in a few days. I taught an introductory game programming class or two at ACC over the last year, so I have a simple object-oriented framework to build on. After a day or so of refactoring and rejiggering (and a little bit of programmer art), I have a basic prototype that I can start really working with. There’s a splash screen and a startup menu, data and image loading, the game loop, screen rendering, a simple game controller that manages user input and updates the world, all the things that make life grand.

Obviously, this initial version is far from playable, much less fun to play. There’s no real game logic or collision detection or anything implemented yet. However, it is a useful start. From here, I can start dropping in gameplay elements one at a time, to see what works and what doesn’t. The game that I have sketched out has four different states for each element – as an item that can be carried and used by the player, existing passively in the world, active in the game world and affecting the other elements, or “harvested” by the player. Active elements grow and change over time, interacting with other elements in the playing area; the player must use the “item” incarnations of the elements to control and manipulate them. The player also has a certain amount of “Qi” that they may use to activate or alter elements in play, and may be able to be replenished at a shrine somewhere in the level. There will be a few other components to play with, to add a little more complexity as the game progresses, but I’d like to keep things as simple as possible for the first go around.

Wu Xing initial prototpye screenshot

As you can see from the screenshot above, each element has a radius or field of effect – I was originally going to just make this yet another simple tile-based puzzle game, but we’ve already got plenty of those, and I wanted to try something a little different. So, instead of pushing rocks and picking up keys and hitting switches and whatnot, the player has to work with these mushier, more volatile elements. In addition to the cyclical interactions between the elements, each element that exists on the playing field will have additional effects – the player may not be able to cross an area filled with water, for example. These are still in the process of being defined, and I should have a better idea of how they’ll work as the prototype evolves. The goals for each level will be something along the lines of harvesting a certain number of “dead” items from the elements in play, or creating and maintaining a specific balance or ratio of the element for a certain amount of time, among others.

Obviously, there are many directions this design could go. This is the danger of jumping right into an interactive prototype – you can spend a lot of time tweaking and adding shiny bits and making a fun toy to fiddle with, but it’s also easy to lose sight of your design goals for the game, and get lost in the process of building and adjusting things that aren’t central to what you hope to accomplish. I know that this is one of my major weaknesses – I’ll blaze ahead when a design is fresh and exciting, throwing a bunch of things together until I have something that’s just barely amusing, and then lose interest, because I’ve lost focus, and the game is never completed. Fortunately, I’ve developed a few techniques to overcome these blocks… but that’s for next time.

May 212006

Hello, and welcome to our little experiment in open-air game design. We’ve got a few games on the burner, and we figure that by thinking out loud and posting our progress to a public forum, we’ll both be encouraged to keep plugging away at things, and be albe to elicit feedback from each other, and the design community at large.

We’ll have a few people joining us here, so let me introduce myself first. I’m Marc, and I pay the bills by making computers go. I’m primarily a programmer, with a good dose of game designer. I have a handful of mostly-done board and card games in the queue, a couple of smallish role-playing games in dire need of playtesting, and a large stack of interactive waiting to be built – that is, video games, both single-player and web-based multiplayer. I’ll be dribbling those out here as they come up.

But first, I’ll wait for the others to pipe up, and then we’ll get rolling.