Sunday, February 12, 2012
Tuesday, July 5, 2011
Design version 7/05/11
design statement for RockPaperScissors game 7/05/11
goals
Game is person versus computer. Select either to play first. Offer levels of difficulty. Mid-level is random. Easy level plays to lose to computer's prediction for person's move. Pseudo-code for most rudimentary strategy:
If count(rock) >count(paper) and count(rock) > count(scissors)
play paper // beat rock
else
If count(paper) > count(rock) and count(paper) > count(scissors)
play scissors // beat paper
else
play rock;
play paper // beat rock
else
If count(paper) > count(rock) and count(paper) > count(scissors)
play scissors // beat paper
else
play rock;
Log person/phone/result history. Show who won and why. Keep score for a session of games. Keep record of session scores. Help should be unnecessary. Undo.
user interface
Main screen - portrait only. Choose instructions / play-level / philosophy. Press go button to get to intended screen.
Game screen - portrait only
Rub finger down-up-down-up-down, resembling pumping your arm. Stick figure's arms move up and down with rub. Error message for incomplete rub? Display a graphic showing winner and score. Display phone's next turn. Use menu to turn it off. (1)
implementation
Develop graphics (2)
Modify tic tac toe, progressively morphing to RPS
Modify web pictures to fit on screen.
Substitute web picture for play-field.
Play, see arm movement per pointer position.
See different graphic for win/lose/draw 3 pics.
See different graphic for win/lose/draw 9 pics.
Cosmetic changes.
Develop input handler
track movement by drawing free-form line.
require up-down threshholds for movement?
Score round on pointer-up instead of I'm ready button.
Develop strategies
Create random prediction for move.
Predict person favoring rock, paper, or scissors.
Paths Beyond.
Play two person game, same device.
Play two person game, different devices.
More elaborate strategies.
Keep a community record of scores.
Allow user to create their own strategies.
.
Discussion
- Someone complained that a computer backgammon game demonstrated at Radio Shack cheated. Whenever it needed a good dice roll, it got one. The Desktop version of RPS had the computer's next move at the bottom of the screen. Criticism was that the package was incomplete. People didn't want to cover the next move on the screen with a card. The web version allowed you to scroll down to see the next move. Early versions of Javascript didn't allow the computer to know if you peeked. The illusion of trustworthiness persists. This version allows you to make the next move invisible with a menu. Most people don't care, find this discussion tedious.
Thursday, June 30, 2011
Design Discussion
_____________________________________________
Keith Re: Design for moves and strategies Wed,
June 29, 2011 2:35:43 PM
>Rub your finger up
> and down the screen. Take your finger off when
> it is on the left side of the screen to choose
> rock, middle=paper, right = scissors.
OK, so the rubbing doesn't really perform any
useful function. You effectively have three
buttons which are not displayed on the screen
so you're being vague about the boundaries
and you're looking for the unpress rather than
the press. I guess you just like the cuteness
of this.
_____________________________________________
Jarvis Re: Design for moves and strategies
Wed, June 29, 2011 2:57:34 PM
Well, there is an analogy between rubbing up and down
and the traditional up and down arm motion.
The traditional up and down motion has appeal for some,
but we don't want them to flatten their palm
to choose paper at the end of a downward thrust.
The web version activates upon clicking a radio button.
I'm hoping that rubbing makes you feel better than clicking.
What do I know?
__________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 2:46:56 PM
For the computer move strategy, the design should
specify exactly what each of the algorithms is, and
then there's the issue of whether you're going to
explain the algorithms to the user or not. Any
explanation belongs in a help file. You don't
need a help file if you don't explain, as you
can simply have several difficulty levels which
the user can choose. Then they have to guess
about the algorithms if they wish.
In any case. the design should specify exactly
what should be done in the implementation.
_____________________________________________________
Jarvis: Design for moves and strategies
Wed, June 29, 2011 3:11:56 PM
If count(rock) >count(paper) and count(rock) > count(scissors)
play paper // beat rock
else
If count(paper) > count(rock) and count(rock) > count(scissors)
play scissors // beat paper
else
play rock;
For the low level of difficulty turn the > to <
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 3:51:56 PM
> There are 9 positions vertically. y axis: 0=top, 8=bottom
> ...
I'm trying to imagine how to explain all this
to the user. Whatever the algorithm, I think
the explanation is not easy.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:10:04 PM
That is for the programmer. You have to explain rubbing to the player in terms of simulating an arm shaking motion by rubbing up and down on the screen. The book, Rock, Paper, Scissors, explains the three-prime shoot thusly, Players pump their arms three (two) times in unison.
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:20:21 PM
> That is for the programmer.
You have a definite tendency to let the programmer
decide various things that I think the design should
specify. I prefer to debug the design before getting
into the coding.
It's fine for the programmer to decide how to explain
things, but the design should specify what is to be
explained, and where, like in help or just onscreen.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:32:54 PM
I meant the programming spec is in terms of nine vertical areas of the screen, not that it is up to the programmer to come up with an explanation. We can probably improve on the explanation of the rubbing. It currently resides in a single XML tag that fills the instructions screen, and I am hoping that changes in the explanation do not impact much work elsewhere.
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:47:17 PM
I'm still unclear about how the user gets started
the very first time. I have noticed several apps
that bring up an "explanation" screen after you
first install it. This could go over the rubbing
concept or anything else that the user needs to
know before starting to play.
You should not bury the explanation somewhere
that the user could miss, like in menu/help.
Most phone experts know to try that, but not
everyone will think of it.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 5:07:42 PM
I am a minimalist about instructions. If I say too much, they just think it is too complicated.
Some things, if you don't say enough, they just sit there, stuck. So far, I don't think this is one of them. Maybe the instructions should pop up if there is a long delay with the scores all zero.
83 Games answer to Rock, Paper, Scissors
I looked for a longer explanation. None of these games have very lengthly explanations. Here is one that needs some explanation.
Keith Re: Design for moves and strategies Wed,
June 29, 2011 2:35:43 PM
>
> and down the screen. Take your finger off when
> it is on the left side of the screen to choose
> rock, middle=paper, right = scissors.
OK, so the rubbing doesn't really perform any
useful function. You effectively have three
buttons which are not displayed on the screen
so you're being vague about the boundaries
and you're looking for the unpress rather than
the press. I guess you just like the cuteness
of this.
_____________________________________________
Jarvis Re: Design for moves and strategies
Wed, June 29, 2011 2:57:34 PM
Well, there is an analogy between rubbing up and down
and the traditional up and down arm motion.
The traditional up and down motion has appeal for some,
but we don't want them to flatten their palm
to choose paper at the end of a downward thrust.
The web version activates upon clicking a radio button.
I'm hoping that rubbing makes you feel better than clicking.
What do I know?
__________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 2:46:56 PM
For the computer move strategy, the design should
specify exactly what each of the algorithms is, and
then there's the issue of whether you're going to
explain the algorithms to the user or not. Any
explanation belongs in a help file. You don't
need a help file if you don't explain, as you
can simply have several difficulty levels which
the user can choose. Then they have to guess
about the algorithms if they wish.
In any case. the design should specify exactly
what should be done in the implementation.
_____________________________________________________
Jarvis: Design for moves and strategies
Wed, June 29, 2011 3:11:56 PM
If count(rock) >count(paper) and count(rock) > count(scissors)
play paper // beat rock
else
If count(paper) > count(rock) and count(rock) > count(scissors)
play scissors // beat paper
else
play rock;
For the low level of difficulty turn the > to <
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 3:51:56 PM
> There are 9 positions vertically. y axis: 0=top, 8=bottom
> ...
I'm trying to imagine how to explain all this
to the user. Whatever the algorithm, I think
the explanation is not easy.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:10:04 PM
That is for the programmer. You have to explain rubbing to the player in terms of simulating an arm shaking motion by rubbing up and down on the screen. The book, Rock, Paper, Scissors, explains the three-prime shoot thusly, Players pump their arms three (two) times in unison.
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:20:21 PM
> That is for the programmer.
You have a definite tendency to let the programmer
decide various things that I think the design should
specify. I prefer to debug the design before getting
into the coding.
It's fine for the programmer to decide how to explain
things, but the design should specify what is to be
explained, and where, like in help or just onscreen.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:32:54 PM
I meant the programming spec is in terms of nine vertical areas of the screen, not that it is up to the programmer to come up with an explanation. We can probably improve on the explanation of the rubbing. It currently resides in a single XML tag that fills the instructions screen, and I am hoping that changes in the explanation do not impact much work elsewhere.
_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:47:17 PM
I'm still unclear about how the user gets started
the very first time. I have noticed several apps
that bring up an "explanation" screen after you
first install it. This could go over the rubbing
concept or anything else that the user needs to
know before starting to play.
You should not bury the explanation somewhere
that the user could miss, like in menu/help.
Most phone experts know to try that, but not
everyone will think of it.
_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 5:07:42 PM
I am a minimalist about instructions. If I say too much, they just think it is too complicated.
Some things, if you don't say enough, they just sit there, stuck. So far, I don't think this is one of them. Maybe the instructions should pop up if there is a long delay with the scores all zero.
83 Games answer to Rock, Paper, Scissors
I looked for a longer explanation. None of these games have very lengthly explanations. Here is one that needs some explanation.
Wednesday, June 29, 2011
Jarvis: Design for moves and strategies
Design for moves and strategies
From:
Jarvis Rich
View Contact
To: Keith Rich; Edith
With some work, I could put an image of rock, paper, and scissors under the feet of the stick-figure contestants.
These are rudimentary instructions and philosophy.
Rub your finger up and down the screen. Take your finger off when it is on the left side of the screen to choose rock, middle=paper, right = scissors.
If the phone plays a random strategy, you can gain no advantage by using a strategy. If it tries to win, it can be beaten. If you can beat it when it tries to win, you may find it harder if it tries to let you win.
Pictures from web version
Design for startegy.
The simplest algorithm is to see whether the the person is favoring one of the three choices, and we program the phone to win over that. Aging the history, by weighting the next previous choice less by 5 percent, may help. A small abount of randomization may make the phone less predictable.
The next most simple algorithm is to see whether they favor one choice given their last choice or the computer's last choice.
From:
Jarvis Rich
View Contact
To: Keith Rich
With some work, I could put an image of rock, paper, and scissors under the feet of the stick-figure contestants.
These are rudimentary instructions and philosophy.
Pictures from web version
Design for startegy.
The simplest algorithm is to see whether the the person is favoring one of the three choices, and we program the phone to win over that. Aging the history, by weighting the next previous choice less by 5 percent, may help. A small abount of randomization may make the phone less predictable.
The next most simple algorithm is to see whether they favor one choice given their last choice or the computer's last choice.
Subscribe to:
Posts (Atom)