What's on your Kitchen Table?

Work on KitchenTable continues during my lunch breaks. It's an interesting project in terms of trying to create something that allows a user to have as much freedom as he wants, while still maintaining a nice, easily understood interface without letting the user break things because f his own whims. And by nice, easily understood interface, I really want none at all.

But I'm going to be needing some buttons, whether I like it or not. These are going to be more global in nature, than actual gameplay kind of stuff. Think "load game" and "save game" vesus, "move a token."

Actually, it appears that Thoth does this very well.

It's working out fairly well at this point. Left-clicking on an object lets you drag it around. Right-clicking pops up a menu of special actions that's specific for that component type. Well, I have to convert the right-clicking to double-clicking due to a new"feature" the latest version of Director/Shockwave added where right-clicking an executable Shockwave will randomly shut the program down on a PC, but I don't need to discuss the gory details of that.






Something I've never contemplated up to now is that on the outside, thinking about all the different type of components there are, and how they are used can be somewhat mind boggling to try and define. But ultimately since KT is dumb about the uses of objects, the organization of component types is fairly straight-forward, with just a few differences across types. Ultimately, every object has an image, or a list of images that it could be, it has a location and a rotation. And that's sort of it. For the most part, every object allows you to select an image from it's list. Dice have an additional "pick a random image" action. Cards can be rotated (you can set the rotation increments if you are using hexes as cards, or something that requires strange rotations), and only have 2 images: card face and card backs. Now that I've got a lot of the backbone of how the world works, it's been fairly easy to add new component types.

Initially, when I was thinking about the structure of how this would all work, I really looked at something like a DECK OF CARDS, and saw a nightmare. How does one define that? Is it really a list of CARD objects? How do I go about manipulating that if I want to shuffle only the cards in the discard pile or a subset of cards? Is the DISCARD PILE a different object, or somehow tied to a DECK? What if the game doesn't have a discard pile for some reason, and is using some card-like kind of thing, like cardboard tiles or hexes?

Along those same lines would be this question: how would I go about creating a simple version of Yahtzee? Rolling one die is simple enough with a special "roll" action, but how do I handle multiple dice? Do I somehow create a way to "hold" dice (ala video poker) that I don't want to roll again? Is there a ROLL DICE button that affects all dice that aren't "held?" Or do I leave it up to the user to simply roll each die individually?

It turns out that a lot of these questions got aswered when I finished up my parenting method for moving objects. I use the term "parenting" not in the OOP sense, but in the animation sense. What this means is this: for any given object, it can be "parented" to one other object. This creates a relationship between the "child" and the parent where the child can follow instructions from the parent.

The easiest way to imagine this would be a stack of two cards. While each card is a seperate object, the top card is parented to the card directly below it, and if you move the bottom card, the top card will follow maintaining it's relationship in regards it's placement on the second card. At any point you can remove the top card from the bottom card, breaking it's parenting relationship, or place it back on top, re-connecting that relationship. Or swap the cards, reversing the parenting relationship.

This is, in fact, what KitchenTable is doing now with all of it's objects. Pick up and move an object, and all of that object's children will follow. Once an object is "dropped," KT checks to see if it has landed on another object; if so, it creates a parental relationship with those objects. You want to stack chess pieces on top of each other, you can do that. Move the bottom piece, and all the others on top of it follow along, and you never have to worry about them dropping!

This took some time to work out all of the kinks, but it works pretty well. You can stack components to your hearts content, break apart those stacks, and re-stack things in any different order. They are all just generic objects to KT.

And it turns out that this naturally and elegantly solves my questions above. There is no "physical" DECK object; a deck after all is just a stack of cards. But what there is turns out to handle deck functions (mostly shuffling) is a DECK TRAY, and dragging selected stacks of cards into deck tray allows the deck tray, as a special action, shuffle all the cards that have been parented in the tray. Much like collecting cards to shuffle.










For the dice, there's a DICE CUP. Put all the dice you want to roll into the dice cup, and those are the only dice that will roll.

It all feels very natural and very similar to playing with components on a table. And for prototyping purposes, I imagine this works wonders as it's pretty darn flexible since things aren't "hard-coded" for lists of components. There is no defined list for a given deck, one can fine tune the deck components easily by just not placing those cards on the deck tray, and instead dragging them "off the board." Same thing with rolling the dice. Ever wonder what Risk would be like throwing 8-sided dice for defense, and 6-sided for offense, well, just put the dice you want to use in the cup and find out.

And so, the project continues. This has put some of the things I wanted to work on for PocketCiv in the back burner. Which is sort of sad, now that PocketCiv has had a bit of awakening on BoardGameGeek (9 new ratings in the past week and a half. WOO!), it would be nice to keep that train going. Heck, a guy even made a nice little tech tree graphic for the game!

Interfaces

Even though I don't think many people consider board games to have user interfaces, technically they do. It's the components themselves. The parts are the things that the connects the players to the rules. When games are considered to be "too fiddly," that's just another way of saying that there's too much stuff on the interface. However, whether that's because there's too much needless stuff, or too many rules, is another issue, one that's primarily left up to a player's taste, for the most part.

I'm pretty amazed at some of the awful interfaces people have designed for various uses. I've seen gas pumps with a START button nowhere near the rest of the button panel, for example. Not very intuitive. There's quite a few websites that deal with bad/good interfaces which are fairly interesting to read.

In boardgame design, however, I think that most interface issues seem to fall into place fairly quickly during playtesting. You see very few games with insanely stupid interface decisions. You are more likely to see some bad interface designs brought on buy cost considerations more than true design thinking (or non-thinking). Such as using non-language dependant symbology for cards. It might look cooler, but having readable text that you understand sure helps a lot; however, if you can bring your cost down by only having to do one print run for the whole world of components, so much the better.

Anyway, where all this is going, is this: Someone emailed me about PocketCiv (which is becoming a lot less pocket-ful as I go, due to the work I'm putting in on the deluxe version), and wondered about the counters I had made for the City Advances (the red and blule counters in here). Basically, the question amounted to why i decided that each counter is a +1 AV counter that needs to be stacked, as opposed to simply having counters that get swapped out that said 1AV, 2AV, 3AV and 4AV.

I had considered this at one point. But when playtesting, I found that I sort of enjoyed the stacking aspects when a city gets built up. Aside from being visually pleasing, I didn't need to have to go searching for a specific tile with the right number on it, just grab another AV chit and stick it on top. And if an AV got reduced, simply pull one off the top and throw it in the pile.

Swapping of chits os sort of messy, since you have to search for the right chit that you need, and then remove the old one, and place the new one i the right place. The old chit being removed would presumably have to be placed in an area that you would have to remember where it was in case you needed to swap them out again. Not that this is REALLY a brain-bursting or Operation! twitchy physical action or anything.

In addition, anytime a player changes the state of a board, you are always prone to the player somehow accidentally whacking something that was not meant to be moved. Swapping tiles seems to complicate these issues a fraction more, since you are moving things at the board level. Stacking and unstacking tiles are slightly above board level, and is only one action, reducing possible whacking time.

Of course, there's always the condition that you now have stacked stuff that can fall down while you are moving other pieces around. So it's not THAT foolproof. But, hey, you go with your gut.