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!
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!
Labels: Interfaces, KitchenTable, parenting, PocketCiv, Thoth
0 Comments:
Post a Comment
<< Home