Java Answers Forum - How Simple Is Simple?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Answers Forum
How Simple Is Simple?

12 replies on 1 page. Most recent reply: Oct 17, 2003 12:52 PM by Matt Gerrans

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 12 replies on 1 page

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

How Simple Is Simple?

Posted: Oct 13, 2003 7:19 AM

I've just been doing a bot of ad-hoc coding for a simple game. The game has a number of Tokens which are assigned to Players, using syntax along the lines of:

   Token  t = new Token();
   Player p = new Player();
   t.setPlayer(p);

A Token can only be assigned to a single player and attempting to assign a given token to a second player throws up an error.
My question is, how do I best check for an invalid assignment to a second player. I see three options:
Firsty: Ask the token explicitly, if it has been assigned already and have it return true of false:

if (!t.isAssigned()) t.setPlayer(p);

This has the advantage of being clear but adds a method to the Token's interface.
Secondly: test the Token to see if it has a Player assigned to it:

if(t.getPlayer() == null) t.setPlayer;

This simplifies the token's interface but (like the first example) validates the token state from the outside.
Thirdly: Don't test first, just catch an exception if we do attempt a second assignment:

try
{
   t.setPlayer();
}
catch(IllegalStateException e)
{
   throw new wobbly();
}

This encapsulates any rules about token assignment within the token and doesn't rely on other object's performing the right tests first.

Since calling the setPlayer method will always need to be wrapped in a try/catch clause, which of the methods above is the more generally acceptable?

Vince.

Senthoorkumaran Punniamoorthy

Posts: 335
Nickname: senthoor
Registered: Mar, 2002

Re: How Simple Is Simple?

Posted: Oct 13, 2003 11:59 PM

> I've just been doing a bot of ad-hoc coding for a simple
> game. The game has a number of Tokens which are assigned
> to Players, using syntax along the lines of:

   Token
> t = new Token();
> Player p = new Player();
> t.setPlayer(p);

A Token can only be assigned to a
> a single player and attempting to assign a given token to
> a second player throws up an error.
> My question is, how do I best check for an invalid
> assignment to a second player. I see three options:
> Firsty: Ask the token explicitly, if it has been assigned
> already and have it return true of false:

if
> (!t.isAssigned()) t.setPlayer(p);

This has the
> advantage of being clear but adds a method to the Token's
> interface.

I would vote for having an isAssigned method. Because in many places in Java API this particular technique is promoted I guess rather than throwing an exception. One example is the java.io.File class having a isFile() method.

Senthoor

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How Simple Is Simple?

Posted: Oct 14, 2003 4:34 AM

> >

if (!t.isAssigned()) t.setPlayer(p);

> >This has the advantage of being clear
> >but adds a method to the Token's interface.
>
> I would vote for having an isAssigned method. Because in
> many places in Java API this particular technique is
> promoted I guess rather than throwing an exception. One
> example is the java.io.File class having a isFile()
> method.
>
> Senthoor

Thanks. That was my initial reaction, too. Unfortunately I then got caught up in wondering if I was creating a method that - to some extent - duplicated a check that happened in another method.

Vince.

fatih karakurt

Posts: 3
Nickname: karakfa
Registered: Oct, 2003

Re: How Simple Is Simple?

Posted: Oct 14, 2003 6:49 AM

If Tokens can not be reassigned, the simplest design is passing the Player to the constructor of the Token. i.e.

Player p = new Player();
Token t = new Token(p);

and set the assignment in the constructor itself.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: How Simple Is Simple?

Posted: Oct 14, 2003 6:21 PM

I like Fatih's idea using the constructor. It would also be possible to have setPlayer() return a boolean, but that may be a bit more obscure.

So, a token can't have more than one player, but can a player have more than one token? Should it be player.addToken( t ) or token.setPlayer( p )?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How Simple Is Simple?

Posted: Oct 14, 2003 11:10 PM

> So, a token can't have more than one player, but can a
> player have more than one token? Should it be
> player.addToken( t ) or
> token.setPlayer( p )?

I started out with a player.setToken(t) and then had both the methods above but found that the Player class was mainly a data class that records the name of the player (and possibly, in future, the player's game stats across games). Within an individual game, it is the token that does the work. Across multiple games, it doesn't matter which token a player used.

Vince.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: How Simple Is Simple?

Posted: Oct 15, 2003 3:03 PM

a bit of ad-hoc coding for a simple game
Maybe a bit of ad-hoc specification would help?

What are the lifecycles for Player and Token?
Players continue to exist after a game ends, do Tokens?
Do tokens exist independent of Players?
When are they created?

Easier to think and then code.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How Simple Is Simple?

Posted: Oct 15, 2003 4:56 PM

Specifications are so passé.
Extreme Programming is the way to go:
1) Pair programming: Go to a colleague's cubilcle and start using his PC. Explain that it works out quicker if you do the coding and he watches.
2) Deliver the simplest thing that could (possibly) work.
3) Having written the code, refactor everything (ruthlessly).
4) Issue updates at the maximum frequency you can achieve.

Also at any stage, you may "Discover Python". This allows you to start again.

;)

> a bit of ad-hoc coding for a simple game
> Maybe a bit of ad-hoc specification would help?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: How Simple Is Simple?

Posted: Oct 16, 2003 2:03 PM

> Specifications are so passé.
> Extreme Programming is the way to go:

Au contraire XP is passé.
Moderate Programming is the way to go!

- some understanding (aka specification)
- some coding
- some testing
repeat

> Also at any stage, you may "Discover Python"

"Discovered" Smalltalk 15 years ago...

Kishori Sharan

Posts: 211
Nickname: kishori
Registered: Feb, 2002

Re: How Simple Is Simple?

Posted: Oct 16, 2003 6:03 PM

I don't much about your requirements. However, just to avoid reassignment of a token object to another player, the simplest way is to let play handle its token, rather than supplying token to a player from outside.
1. If player can have only one token then create the token inside player's constructor and keep the reference in private instance variable of player as:

class Player {
  private Token t ;
  public Player () {  
   //...
  t = new Token();
 }
}

2. If token can/cannot be assigned to a player at the time of its creation then adda method to player's class. when that method is called let player add a token to itself. If different types of tokens can be assigned to a player then pass token class type as argument to a method as:

class Player {
 private Token t ;
  public assignToken() {
    t = new Token();
  }
 pubic assignToken(your type goes here){
  t = ...
 }
}

This way you don't have to fear/check about reassigning token again to another player.

I don't know what you do with token after you assign to player. I would prefer to let handle player its token. YOu should be able to send message to player what to do with its token, but you don't be able to get hands on its token directly.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: How Simple Is Simple?

Posted: Oct 16, 2003 7:11 PM

I guess another question here is "can tokens exist apart from players?" If not, then Kishori's suggestion should be right on the mark.

If so, then it is a different story, but even so, let's imagine the tokens are cards. In this case, each token should exist only in one place; it starts out in the deck and then is given to a player. That player might give it to another, or put it in a trick, or wherever, but the token needn't be in more than one collection at once. Now, continuing with the card analogy, if the game is something like "go fish," then for each token, it has three "equivalent" tokens, but they are not the same token. In other words, it seems you might have a multiton (say 52) of tokens, each being unique. So, while a player may say "do you have a duece" what they are really asking is whether you have any one of the four cards that has that value. If you have several collections, like the deck, the discard pile, players' hands and so on, you just make sure that you are always moving the token from one to another, not just copying its reference.

This would be modelling it like it is actually played. Of course, if you wanted to find a particular token, you might have a somewhat less efficient route (ask the dealer, ask each player, look on the table, under the table, in the window sill...), then if you kept them all in a collection, but you could add that optimization later, if it was really a problem.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How Simple Is Simple?

Posted: Oct 17, 2003 5:26 AM

Kishori's suggestion is a good one and I'll look into it. Within the confines of a single game (which is all I'm modelling to start with), players and tokens are pretty much synonymous. Players only take on an independent form if statistics and other data are to be carried between games.

The stuff about card's was interesting. One of the first things I did when I learnt java, was to buy an encyclopaedia of Patience (card) games. What I found, after modelling the first couple of games, was that all the games were pretty much identical. They started with an unsorted deck (collection) of cards (multiplethons) and, via intermediate decks, you ended with a sorted deck of cards. All that changed were the rules for moving the cards from one deck to another.

The hardest part was laying out the game-play patterns on the screen in a professional sort of way and the general UI. I never did manage to code dragging-and-dropping cards from one pile to another. I started out with high hopes of coding most of the games. Unfortunately, after less than a dozen games, the intellectual challenge wore off (and I saw that free card games were ten-a-penny on the internet). The first game took about two weeks to write. The last one, no more than a couple of hours. Maybe I ought to dig the code out and dust it off (and sort out the drag-and-drop).

Vince.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: How Simple Is Simple?

Posted: Oct 17, 2003 12:52 PM

I was imagining a design for games where the are Participants who may have different roles (dealer, player, observer, referee), behaviors (playing, stalling, bluffing, cheating, quitting), styles (cautious, bold) and talents (smarts, memory) and which may be human players, or software. These characteristics would change throughout the game and even moreso over a series of games (which may not all be the same game). The game has rules and objectives. Stratgies fit into the player's characteristics somehow. Seems like the participants may communicate and operate with messages which need both sender and a receiver (in other words the methods for each class need to always have a sender parameter, or a separate messaging system needs to be used. There would be a table, with different regions for tricks, discards, etc. This would be a fun system to set up. It is amazing how complex it is for us even to roughly model in software something as simple as a Saturday night round of poker with friends.

Flat View: This topic has 12 replies on 1 page

Previous Topic

Next Topic