In response....

I've been away from the wired world for a while, waterparking with the kids at Grizzly Jacks. So, instead of responding to the comments of the last post in the comments, I figured I'll use the power of the RSS feeder to answer the questions.

The hook for PocketCiv would simply be "solitaire Civ game."

The hook for One Against the Dead would be "Solitaire Zombie game with household components." Of course, I've decided to blow away that hook, and am slowly working on a more story-driven basis for that game, while keeping the slightly strategic elements of city building/zombie creation. But that's sort of slow going at this point...creating all of the story points and arcs is turning out to be a larger time-consuming project than I have imagined.

The other project I'm working on is the resusitation of KitchenTable. The more observant may have noted that it has magically appeared in the 'Places to Play" link off in the sidebar. This is my attempt at a game prototype engine that can support multiple players, that I had given up last fall with the introduction of Gabob and Zun Tzu. However, these don't seem to appeal to a few members of BGDF, so I've gone back and started working on it again. The multiple player is currently turned off to chase down gamebox creation bugs, there's no documentation, and it's being debugged by a few BGDF chat people, but it's there for people to play with.


And, of course, there's no promise that I'll ever finish it, and give it up further along the line.



And yes, "The Hook" image was created on the DS Colors program.

PocketCiv ranks!

PocketCiv finally hit the 30 ratings mark on BGG to finally be given a rank. While it has a true rating of 7.6, it's biased rating is 5.86 (biased due to the fact it has so few ratings), ranking in currently as the 1583rd best game ever invented.

For the record, the worst ranked games with at least 30 ratings (again biased), are:

#3701 Snakes and Ladders
#3702 Bingo
#3703 Tic Tac Toe

And in other news, PocketCiv was subjected to an audio podcast review, which is a strange experience. It's one thing reading someone's comments about your game on a website; it's another thing to hear a voice talk about it. It all sounds so...official. Maybe it's the accent.

Anyway, comments and rules clarifications keep tricklling in on PocketCiv, and I've been meaning to get back and clean that game up a bit. Unfortunately, KitchenTable has been keeping me quite busy of late, and I've hit the "man, I'm so tired of working on this" part of the project.

The other side of KitchenTable is that I think I'm pretty close to having a releasable beta (after a complete re-write of some elements). Aside from a few issues I need to pick up, I'm currently dealing some higher conceptual issues in regards to how the multi-user aspects work.

Unlike a typical online game server where all the objects and graphics are known, KitchenTable relies completely on user-created content. And for a true multi-user game session to take place over the internet, each user must "point" KT to the correct file structure on their local hard-drive, and make sure that they are both pointing to the same image folder and files. This is all trickier than it should be; but since KT knows nothing about the content it is going to use, it just can't simply go to the folder structure "games/carcassonne/images."

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!

Introducing KitchenTable

Most likely because we've finally hit warm weather here in my hemisphere and Cicada Watch 2007 is in full swing, my desire to work on designs has slowed down. So I'm taking a break for awhile.

However, I've got a new project keeping my lunchtime busy.

Everyone on at BGDF seems to want a prototyping engine, something to easily playtest boardgames on. But, as one can expect, noone has really done anything about it, except to talk about what kind of features they want.

Sure, there are some amount of game playing engies out there; notably Vassal, Thoth, and Cyberboard. They all have their strengths, but for quick prototyping, based on my quick looks into their packages, they don't work very well. Since you actually have to "program in" the rules somewhat, it requires some amount of programming logic, and you really need to have a good sense of how the game operates before you even start getting into the meat of making a game for these systems. And so, making changes to rules as you go is VERBOTEN!

So, I've embarked on trying to come up with this application. And first passes at it have been promising. It works with a very simple mindset. Imagine a kitchen table where there are a bunch of game pieces strewn about. You can manipulate these in any way you wish, making up rules on how they are manipulated, or changing the rules, as you go.

This is pretty much what the software does. It's a "dumb" graphics engine, where users (through a network, local or online) can manipulate graphic objects in real-time on a shared visual table. And since it's simulating the above mentioned kitchen table, I'm eschewing all the fancy suggested names, and going with "KitchenTable" as it's name.

As a real-time example, imagine you want to play a game of chess. You simply load up all of the chess graphic objects, and your friend in another part of the world does the same. KitchenTable doesn't understand the rules of chess, but it allows you and your friend to play chess, in real-time, or whatever rules you want to use with those chess pieces.

You define want you want in your game by editing a simple .txt file (at this point, future plans would call for a drag-and-drop design module that creates the .txt file), which defines objects, and what type of object they are, and the graphics that you want associated with them.

You want to add some dice to your game? Go ahead, and create a die object in the game file. Your die object is simply a list of images that you want on each face of the die, so you can easily define how many sides you want on a die.

This is all being done in the almost-obsolete world of Shockwave. Actually, KitchenTable is a standalone executable program that is stored locally, and is not used in a browser. Why Shockwave? This is what we prototype games in at work, and I have become very fluent in it. Also, there is this thing called the Shockwave Multiuser Server (near the bottom of this link), also pretty much obsolete-d by Flash stuff, that handles a ton of the multi-user stuff. So it's fairly qucik and easy to send messages back and forth between multiple users.

As I've said before, initial tests have proven promising. So I'm now in the stage of cleaning things up from those tests and moving forward.

We'll have to see how long this diversion lasts, since this will most likely keep me busy at lunchtime for a while.