Object definitions

Mon, 10/04/2004 - 13:21

#1

Anonymous

Object definitions

So consideration on the subject has brought me to the conclusion that most game "bits" fall into some combination of very few boolean switches.

1. Public - These are things like the main board, banks, card stacks, and the like that all players are allowed to utilize.
2. Private - These are things like the cards in your hand, your personal playing pieces, and other things that are restricted to fewer than all players. (Note: It is very important to determine which player(s) are considered to be Owners of a Private object).

1. Open - Open information is that which is known to all players; things like how many cards are in a players hand, what pieces have been placed on the board, and the board itself.
2. Hidden - Hidden information is that which is known only to the object's Owner if the object is private and is known to no players if the object is Public (card stacks tend to be Public/Hidden); such as the specific values of the cards in one's hand.

1. Fixed - These are pieces in which the above to settings do not change; examples include chess boards and chess pieces (which are always Privately owned with ownership changing hands).
2. Dynamic - These are things that change their properties; examples include resource cards in Settlers which change from Public/Open to Private/Hidden when a player takes them. This is also used for revealing hidden information (some scenarios utilize this in Seafarers of Catan).

It is useful to consider dice in terms of the actual values rolled. These values are most often Open and can be either Public (Settlers) or Private (Risk).

One thing that the above does not cover is the idea of Limited Hidden objects. These would be things like tiles with partial information on one side that is expanded upon on the other side (if for example all non-soldier development cards in a Settlers game had different backs). I am not really sure how to handle this other than to consider it two seperate objects...

Does anyone else think that this is at all useful? Are there other categories that have not been considered, or other Object types that do not fit (similar to Limited Hidden information)?

Thomas

Mon, 10/04/2004 - 13:42

#2

phpbbadmin

Offline

Joined: 04/23/2013

Re: Object definitions

RookieDesign wrote:

Quickly (because I'm suppose to work :( )

I have some objects defined.
Boards
Cards
Tokens
CardPiles
Banks
Dice

Now boards are either the main board, or players board.

Cards are either cards or tile. You can flip them and orient them.

Tokens are any pieces. You can orient them (like road in Catan)

CardPiles are a stack of Cards.

Banks are either a money bank, or ressource bank (Barrel from Puerto Rico) and can be limited or unlimited. Can be auction title and such. A bank contain only the same king of object.

Dice well any size and combination you roll them.

I think with these basic object it is possible to make a good deal of board game. I know I could with mine.

It seems to me like most of the objects above could be almost identical, and then you could create 'templates' off of those to create game objects.

For example, a die could be an object with X # of states (where x is the number of sides for the die) where each of the states has a graphic dispaying the appropriate dotted #. Then you could associate an action with the object where it would choose a random state for the object and then display it. Make sense? (Note: this may be difficult with four sided dice in the traditional sense, but then you could just implement a 4 stated object).

For cards, they would be two states. Face Up and Face Down.

For game boards, probably just one state. Tokens might also be one state. Counters could be easily done this way as well (one state for each different value).

You would also need player objects obviously. I envision player objects would be used to take ownership of hidden areas of the screen where players could look at their resources without the other players seeing it.

As for the hidden areas, these areas would be where players would drag things to look at them secretly (obviously) and to store resources that are to be kept secret from the other players. If the other players should see the number of cards in your hand, then obviously you need to put the cards down onto the open play area when you aren't looking at them. We should leave this up to the players to take care of I think.

As for banks/decks, I think we should forgo that and just create a grouping action. Grouped items would allow for special actions (along with the 'normal' single object actions) such as shuffle, get random, get specific, etc. You could add to a group by dragging an object (or a group of objects) of the same type onto a group of objects (or even a single object) of the same type.

Some examples:

You right click on the pool of tiles (grouped objects all face down) and select Get Random, the engine then passes your player pointer a random tile.

-or-

You right click on a discard pile (grouped objects all face up) and then select the action Flip. You then drag the discard pile onto the draw deck and select Add to Group. You then right click on the draw deck and select Shuffle.

Make sense?

I'm thinking if we make this as DUMB (and in essence, more flexible) as possible, then it will be able to handle a wider array of game designs. It may seem a little complicated to setup for the end user, but I believe that if we, as the designers of the engine, create some useful templates (for dice, cards, tiles, tokens, counters, boards, etc.) then would be users of the program will have a much easier time of implementing their game with it.

Any thoughts?
-Darke

Mon, 10/04/2004 - 13:49

#3

Anonymous

Object definitions

Now, to move out of the realm of Jargon and Theory...

I can only identify two major types of game Objects.

Card
I define cards here as an Object which is included with other, physically similar Objects for the purpose of randomization. (Intention to randomize is the key for cards).

The card is one of the most flexible Objects in board gaming. It can be any combination of Public/Private-Open/Hidden-Static/Dynamic (i hereby change my previous Jargon "Fixed" to "Static"). There are a large number of specific actions you can take with a card:

Draw. Self explanitory.
Place. This involves placement of the card somewhere. This includes placing cards in front of you and tile placement for board construction.
Change State. This is tied up with "tapping" and other such mechanics that indicate a change in the value of the card without changing its... whatever you call the Private/Open/Dynamic stuff. This mechanic is often used instead of Expending (see below) a card such that it can be used multiple times.
Expend. This is "using" the card such that it can not be used again. Most often this is a case of discarding the card.

Pawn
I define Pawn here as any object used to indicate the current state of things. Pawns are not randomized.

The pawn is actually a mnemonic device. If everyone had eidetic memory then the pawn would be superfluous. It is used to remind all players of the current state of the game. You can take the following action with a pawn:

Move. This is an extremely broad action that includes moving pawns around a board, moving pawns from off-board to on-board, and removing pawns from the board. Changing the state of a pawn is actually just another form of moving it. In Settlers you do not change a Settlement into a City, you MOVE the Settlement pawn off-board and then MOVE a City pawn on-board.

It is important to note that Public boards of all types are simply a form of Pawn, they are only there to provide visualization of the game.

Again, it is useful to consider dice in regards to the value of the roll instead of as their own entity. In this case they can be considered a specialized type of Card.

Looking back over this i am not sure that these categories are specific enough for use. It is probably necessary to identify some specific types of these two objects, possibly in terms of some combination of intended function and Public/Open/Static terms...

EDIT: Crossposted.

Thomas

[/][/]

Mon, 10/04/2004 - 18:45

#4

Anonymous

Re: Object definitions

You asked for some specific commentary (at least as i read it) on the implementability of these suggestions. Some i like a lot...

Darkehorse wrote:

It seems to me like most of the objects above could be almost identical, and then you could create 'templates' off of those to create game objects.

For example, a die could be an object with X # of states (where x is the number of sides for the die) where each of the states has a graphic dispaying the appropriate dotted #. Then you could associate an action with the object where it would choose a random state for the object and then display it. Make sense? (Note: this may be difficult with four sided dice in the traditional sense, but then you could just implement a 4 stated object).

For cards, they would be two states. Face Up and Face Down.

For game boards, probably just one state. Tokens might also be one state. Counters could be easily done this way as well (one state for each different value).
Ok, it strikes me that this is a lot more unique object types than we really need. See my comments regarding all Objects being subsets of cards (that is randomizers) and pawns (that is, mnemonic devices used to represent the state of the game). I do not think that seperate implementations for all of this are necessarily a good idea.

Quote:

You would also need player objects obviously. I envision player objects would be used to take ownership of hidden areas of the screen where players could look at their resources without the other players seeing it.

As for the hidden areas, these areas would be where players would drag things to look at them secretly (obviously) and to store resources that are to be kept secret from the other players. If the other players should see the number of cards in your hand, then obviously you need to put the cards down onto the open play area when you aren't looking at them. We should leave this up to the players to take care of I think.
This idea has some serious potential. I like the idea of a seperate part of the "table" where you can leave stuff and only you will know what is in there. It would be even better if we could have it such that people can see what Objects are in your area but not their Values.

Quote:

As for banks/decks, I think we should forgo that and just create a grouping action. Grouped items would allow for special actions (along with the 'normal' single object actions) such as shuffle, get random, get specific, etc. You could add to a group by dragging an object (or a group of objects) of the same type onto a group of objects (or even a single object) of the same type.

Some examples:

You right click on the pool of tiles (grouped objects all face down) and select Get Random, the engine then passes your player pointer a random tile.

-or-

You right click on a discard pile (grouped objects all face up) and then select the action Flip. You then drag the discard pile onto the draw deck and select Add to Group. You then right click on the draw deck and select Shuffle.
I did not really assimilate this properly the first time through, but after re-reading it i believe that this is an incredibly elegant solution to a lot of different things. Using a modified form of this we can probably build the entire system around a sinlge type of Object and a single Grouping type for said objects. So basically you can take any type of object and put it in a "Group". Then you can choose to "Get random object from group" which draws one of whatever is in that pile. Once you have viewed the Object withdrawn you would be given the choices of "Keep out of group" for things you draw and keep, "Place in discard" for things that are not part of play (that is, still tied to the Group) but for the purposes of memory, not avaiable. And an option to "Replace, Randomize" for randomizers

This has the very interesting side effect of allowing you to randomize disparate things (the pile is half coins, half cards; you could get either one).

Does that make sense? I think it is a really powerful tool and i feel like i am not really explaining myself well...

Thomas

Mon, 10/04/2004 - 21:44

#5

phpbbadmin

Offline

Joined: 04/23/2013

Re: Object definitions

LordSmerf wrote:

You asked for some specific commentary (at least as i read it) on the implementability of these suggestions. Some i like a lot...

Darkehorse wrote:

It seems to me like most of the objects above could be almost identical, and then you could create 'templates' off of those to create game objects.

For example, a die could be an object with X # of states (where x is the number of sides for the die) where each of the states has a graphic dispaying the appropriate dotted #. Then you could associate an action with the object where it would choose a random state for the object and then display it. Make sense? (Note: this may be difficult with four sided dice in the traditional sense, but then you could just implement a 4 stated object).

For cards, they would be two states. Face Up and Face Down.

For game boards, probably just one state. Tokens might also be one state. Counters could be easily done this way as well (one state for each different value).
Ok, it strikes me that this is a lot more unique object types than we really need. See my comments regarding all Objects being subsets of cards (that is randomizers) and pawns (that is, mnemonic devices used to represent the state of the game). I do not think that seperate implementations for all of this are necessarily a good idea.

Ok, I think you either misread or didn't understand me. I was implying that tokens, boards, tiles, cards, dice, etc all be the same type of object.. But depending upon the implementation, it would be different. So a 6 sided die would be a six stated object. A coin could be a 2 stated object. A card would also be a two stated object. Each of the states would represent a different physical orientation of the object that the players can access. I.E. for the die, each face of the die. For the cards; the face up and face down sides of the card. Single state objects could be used for objects that only need to be accessed from one side (for example, a tile that never needs to be flipped face down). Each state would basically hold a different graphical view of the object for the players to look at.

Quote:

Quote:
You would also need player objects obviously. I envision player objects would be used to take ownership of hidden areas of the screen where players could look at their resources without the other players seeing it.

As for the hidden areas, these areas would be where players would drag things to look at them secretly (obviously) and to store resources that are to be kept secret from the other players. If the other players should see the number of cards in your hand, then obviously you need to put the cards down onto the open play area when you aren't looking at them. We should leave this up to the players to take care of I think.
This idea has some serious potential. I like the idea of a seperate part of the "table" where you can leave stuff and only you will know what is in there. It would be even better if we could have it such that people can see what Objects are in your area but not their Values.
This is easily accomplished, leave it up to the players to flip the objects face down.

Quote:

Quote:
As for banks/decks, I think we should forgo that and just create a grouping action. Grouped items would allow for special actions (along with the 'normal' single object actions) such as shuffle, get random, get specific, etc. You could add to a group by dragging an object (or a group of objects) of the same type onto a group of objects (or even a single object) of the same type.

Some examples:

You right click on the pool of tiles (grouped objects all face down) and select Get Random, the engine then passes your player pointer a random tile.

-or-

You right click on a discard pile (grouped objects all face up) and then select the action Flip. You then drag the discard pile onto the draw deck and select Add to Group. You then right click on the draw deck and select Shuffle.
I did not really assimilate this properly the first time through, but after re-reading it i believe that this is an incredibly elegant solution to a lot of different things. Using a modified form of this we can probably build the entire system around a sinlge type of Object and a single Grouping type for said objects. So basically you can take any type of object and put it in a "Group". Then you can choose to "Get random object from group" which draws one of whatever is in that pile. Once you have viewed the Object withdrawn you would be given the choices of "Keep out of group" for things you draw and keep, "Place in discard" for things that are not part of play (that is, still tied to the Group) but for the purposes of memory, not avaiable. And an option to "Replace, Randomize" for randomizers

I would say we would need to keep it more abstract than even that. Don't define the discard pile, just make it another group of cards (or tiles or whatever) and let the players manipulate it. I think we should keep the engine as dumb as possible (at least for right now), so that it will be able to do as many games as possible. I currently forsee four actions for groups; Shuffle (what you called randomize), Draw Random Object, Draw Specific Object (the player could look through all of the objects in a group and keep a single object), and Draw Top Object (this action could be. With these four actions, and the ability to group objects easily, you can handle many situations such as draw X and keep y, shuffling, refreshing a draw pile, drawing the top card, etc etc ad nauseum. For keeping deck order, you could simply say that the object or group of objects dragged onto another object would be on top. So if I dragged a single card onto a deck of cards and grouped it, the single card would be on top of the deck. Likewise if I dragged a deck of cards on top of a single card and grouped them, then the single card would be on the bottom. Also keep in mind that grouped objects would have the same actions available to them as a single object. So if you could rotate a single card 90 degrees, then you could do the same to a group (or deck) of cards. Likewise, if you had to look at a grouping of cards and keep only one; you would drag them over to your 'hidden area' flip all of them over, pick the one you want flip them all back over and then return them to the deck using the appropriate method (bottom of the deck, discard pile, into the deck and then shuffled, whatever).

Make sense?
-Darke

Mon, 10/04/2004 - 22:02

#6

sedjtroll

Offline

Joined: 07/21/2008

Re: Object definitions

Darkehorse wrote:

For keeping deck order, you could simply say that the object or group of objects dragged onto another object would be on top. So if I dragged a single card onto a deck of cards and grouped it, the single card would be on top of the deck. Likewise if I dragged a deck of cards on top of a single card and grouped them, then the single card would be on the bottom.

It would be nice if dragging and dropping like that would auto-group like objects, but I can see reasons why that could be bad as well. Maybe there could be an "auto-group" function which could be turned on for games that do a lot of grouping and no 'put this object on top of that object but don't group them'.

Putting a card on top of a deck by dragging it there is fine. Maybe putting it on the botom instead could be done with a shift-drop?

- Seth

Oh, and as for things in hidden areas, it'd probably be good to display things like the number of objects (number of cards in hand for example) for opponents to see while you can see what they are in your hidden area. This is another feature that could be turned on or turned off for really great usability.

And finally, I realize that the system should be dumb, but to avoid accidental (and dare I say purposeful) cheating I think it would be nice if the system were set up such that if you DO cheat or misplay, your oppoent can tell by looking. For example, in the Apprentice program I mentioned, you can draw extra cards to your hearts content, and each time you do it says "sedjtroll draws 1 card". However if you look at the top 5 cards of the deck and choose 1 to put in your hand and the rest go on the bottom... if you had to draw 5 then put 4 down you could easily mess that up as the cards go into your hand with your other cards- even if you didn't want to. For that reason, that program opens a different window displaying the top 5 cards. you can drag and drop them into your hand, onto the board, or right click and send them places like the bottom of the deck, etc. This way if you DO try anything funny your opponent can see it.
[edit] your opponent cannot see that extra window

I would feel uncomfortable if the system allowed people to do things without their opponent knowing about it. There's hidden information, and then there's hidden actions. The former is important to a lot of games, I can't think of a situation where anyone would ever need the latter.

Mon, 10/04/2004 - 23:46

#7

Anonymous

Object definitions

A quick comment regarding multiple stated objects. It turns out that to the computer an object with multiple states is really multiple objects combined into one object. So a d6 is actually six a SixSided object that is comprised of 6 individual DieFace objects. Conceptually just think of any possible value of any object as its very own object.

Quick note: it will actually take a lot more time implementing each object than applying new operatons for it. Thus once we make a "deck of cards" (or similar) object including a "Place card on bottom" and tracking a discard pile become easy. Though you do have a point that the less that is automated the more flexible the system becomes...

Thomas

Tue, 10/05/2004 - 00:04

#8

phpbbadmin

Offline

Joined: 04/23/2013

Object definitions

LordSmerf wrote:

A quick comment regarding multiple stated objects. It turns out that to the computer an object with multiple states is really multiple objects combined into one object. So a d6 is actually six a SixSided object that is comprised of 6 individual DieFace objects. Conceptually just think of any possible value of any object as its very own object.

Yes, I had already ascertained as much, but I guess it really depends on how the programming language and the programmer implements it really. Besides how it is implemented on the computer is not anything we need to know, unless it affects efficiency.

LordSmerf wrote:

Quick note: it will actually take a lot more time implementing each object than applying new operatons for it. Thus once we make a "deck of cards" (or similar) object including a "Place card on bottom" and tracking a discard pile become easy. Though you do have a point that the less that is automated the more flexible the system becomes...

Not sure what you are getting at with that comment. Yes you can duplicate existing objects and then modify them to make new ones. Is that what you mean?

-Darke

Tue, 10/05/2004 - 12:56

#9

Anonymous

Object definitions

You're making this way too complicated. A six-sided die is a random number generator that generates a number between 1 and 6 (inclusive). That's it. A deck of cards is a stack of card references. A token is simply an object. Each of these can have a location on a board or a general table (the board is simply a constraint on the table).

Trying to make everything some form of one base object will be huge, error-prone, slow and impossible to maintain.

If you don't believe me, fine, but I've got 8 years of professional game development under my belt, so I do know what I'm talking about.

Tue, 10/05/2004 - 13:37

#10

phpbbadmin

Offline

Joined: 04/23/2013

Object definitions

Chaplain wrote:

You're making this way too complicated. A six-sided die is a random number generator that generates a number between 1 and 6 (inclusive). That's it. A deck of cards is a stack of card references. A token is simply an object. Each of these can have a location on a board or a general table (the board is simply a constraint on the table).

Trying to make everything some form of one base object will be huge, error-prone, slow and impossible to maintain.

If you don't believe me, fine, but I've got 8 years of professional game development under my belt, so I do know what I'm talking about.

Really? Which companies have you worked for? What games have you produced? What areas are you proficient in? Instead of getting hostile, why not provide gentle advice? Jumping in and attacking what we proposed is probably not going to get a good reaction. From day one, I have emphasized that the engine needs to be as dumb as possible so it can handle as many games as possible. This will mean that it will be slower than an engine designed to run only one game or a similar group of games (like card games), but this is by design. Again, I can't emphasize enough how much it needs to be flexible. Otherwise we will be reinventing the wheel. Why not just use Vassal or Thoth?

-Darke

Tue, 10/05/2004 - 19:40

#11

Anonymous

Object definitions

Sorry, I didn't mean to sound hostile.

One thing I will suggest is that you don't think of this project in terms of what a computer can do or how a programmer would implement it. Programmers can do anything with a computer (even if they don't admit it). The design phase of any project starts with requirements analysis, which you are doing. But don't get too technical.

Focus on WHAT, WHERE and WHEN. HOW comes later. Start at a high level and work your way down, filling in details as you go.

What do you want to do? Prototype games.
What kind? Board, card, tile and dice (any others?).
What do players do when playing these games? Roll dice, draw cards, play cards, hold cards, move pawns, place tiles, remove pawns.
What are these actions based on? Action points, resources (die rolls), card hands.

Once you have a list of these things, you have your requirements. When you start talking about state, random numbers, scripting or anything else, you're too technical. When the overall design is coming along, those of us with technical knowledge can contribute to a technical design (this is a separate document), detailing how these objects and actions are represented and implemented.

I would love to help, but I am currently in a position that constitutes a conflict of interest. I'm hoping that that will change soon, and I will certainly help out when it does.

Ben Taggart

P.S.: Engineering Animation: Trophy Hunting (User interface, 3D sound), Microsoft: Direct3D for Windows CE, Amped 2 for Xbox (Xbox Live & multiplayer), THQ: Unannounced action game (Xbox features, special effects).

Wed, 10/06/2004 - 14:52

#12

phpbbadmin

Offline

Joined: 04/23/2013

Good stuff!

Quote:

One thing I will suggest is that you don't think of this project in terms of what a computer can do or how a programmer would implement it. Programmers can do anything with a computer (even if they don't admit it). The design phase of any project starts with requirements analysis, which you are doing. But don't get too technical.

Focus on WHAT, WHERE and WHEN. HOW comes later. Start at a high level and work your way down, filling in details as you go.

What do you want to do? Prototype games.
What kind? Board, card, tile and dice (any others?).
What do players do when playing these games? Roll dice, draw cards, play cards, hold cards, move pawns, place tiles, remove pawns.
What are these actions based on? Action points, resources (die rolls), card hands.

Once you have a list of these things, you have your requirements. When you start talking about state, random numbers, scripting or anything else, you're too technical. When the overall design is coming along, those of us with technical knowledge can contribute to a technical design (this is a separate document), detailing how these objects and actions are represented and implemented.

I would love to help, but I am currently in a position that constitutes a conflict of interest. I'm hoping that that will change soon, and I will certainly help out when it does.

Ben Taggart

P.S.: Engineering Animation: Trophy Hunting (User interface, 3D sound), Microsoft: Direct3D for Windows CE, Amped 2 for Xbox (Xbox Live & multiplayer), THQ: Unannounced action game (Xbox features, special effects).

Ya know, you're absolutely right. We are trying to define the implementation when we should still be working on the requirements. I think a lot of the problem is centered around a lot of us being in the IT background to start with. I appreciate your credentials, and your offer to help and I understand about your conflict of interest problem. Perhaps you can still provide 'advice' until you are free from your COI?

And on that note, I think I will start a new thread for the requirements analysis. Heh, might be time to bust out my college book on the SDLC.

-Darke

Wed, 10/06/2004 - 17:39

#13

Anonymous

Object definitions

I'll happily advise where it is appropriate for me to do so (and when I have time). I'm trying to go freelance right now, and if that succeeds, you'll hear more from me.

Mon, 10/11/2004 - 19:41

#14

Anonymous

Textbook for the Game Project

Hello All,

The "Object definition" thread caught my eye. Zimmerman's Rules of Play: Game Design Fundamentals (Amazon Link) is a great book that describes games in general and the different mechanics used in playing games. Although it is written for software game design many of the ideas, especially in section 1, are transferable directly to board games. Since it has been developed as a textbook it is both comprehensive and dense. However, that is exactly what you need when you are analyzing a subject for a software project.

Jonathan

Wed, 10/13/2004 - 06:52

#15

Anonymous

Object definitions

Darkehorse said

Quote:

I think I will start a new thread for the requirements analysis.

Darkehorse, did you create that thread yet? Thanks,
splunge

User login

Navigation

Dec 26 2024

Dec 25 2024

Dec 24 2024

Dec 17 2024

Dec 16 2024

Dec 14 2024

Dec 13 2024

Dec 11 2024

Dec 5 2024

Dec 3 2024

Dec 2 2024

Nov 28 2024

Nov 27 2024

Nov 24 2024

Nov 21 2024

Nov 20 2024

Nov 18 2024

Nov 17 2024

Nov 15 2024

	Build your own [insert game genre here] (12) by lewpuls
	DuelBotz: Sample New Card (16) by questccg

	Madison Game Design Cabal (0) by The Game Crafter
	PoA — Major shift back closer to FCE (13) by questccg

	New Product: Large Quad-Fold Game Boards (0) by The Game Crafter
	2025 New Year Sale at The Game Crafter (0) by The Game Crafter