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;

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

    click on rock/paper/scissors radio button

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)

    Press go button :

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

1. 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.

2. For images see http://phoneappprojectman.blogspot.com/2011/06/pictures-from-web-version.html

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

https://market.android.com/search?q=rock+paper+scissors&so=1&c=apps

I looked for a longer explanation. None of these games have very lengthly explanations. Here is one that needs some explanation.

https://market.android.com/details?id=net.badpixel.android.victoryv&feature=search_result

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

http://phoneappprojectman.blogspot.com/2011/06/pictures-from-web-version.html

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.

Pictures from web version

person chooses rock
person chooses paper
person chooses scissors

Keith comments on alternate design

Re: Alternate Design Statement
From:
"kxr@netzero.com"
View Contact
To: ishtar@pacbell.net
Cc: edithrasm@yahoo.com; kxr@netzero.net
Jarv,

Yes, I think this is helpful.

Now, for specifics:

1) rub finger down-up-down-up-down
I don't understand this; how do you choose
what your move is?
2) consider multitouch input with 1, 2 or 3
fingers to make choice. Yes I know this
won't really work with the emulator. You
can have multiple input methods active.
3) display images of Rock, Paper and Scissors
and make the choices bigger or a different
color after choice. Show computer's choice
as well. In any case, the design should
really say what the screens will look like.
4) a bunch of your implementation belongs up
in the design section, like the strategies.
You really want to "design" everything that
you're going to implement rather than just
leaving important issues undesigned. This
goes back to the idea that the principle
that it is cheaper to debug the design
than to change things during implementation.

In summary, it should be possible to create and
debug the design enough so that you effectively
have a spec that someone else could implement
without any important ambiguities left to the
implementation stage. Of course, this does not
guarantee that implementation won't disclose
bugs in the design which can't or shouldn't be
implemented.

Keith

Jarvis alternative design

Alternate Design Statement
From:
Jarvis Rich
View Contact
To: Keith Rich ; Edith
Alternate Design Statement
Looks better on the blog
http://phoneappprojectman.blogspot.com

design of RockPaperScissors game goals     person versus computer     select either to play first     offer levels of difficulty     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 game screen - portrait only     click on rock/paper/scissors radio button     rub finger down-up-down-up-down     stick figure's arms move up and down with rub.     balloon error message for incomplete rub.     display graphic showing winner and score.     press go button implementation Develop graphics     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 button. Develop strategies     predict favoring rock, paper, or scissors.     predict given previous win or loss.

design of TicTacToe game goals     person versus computer originally 4 dimensional tic tac toe changed to 2D showing 8 previous results     select either to play first     offer levels of difficulty     log player/cell occupied     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 play-level     choose person/phone to go first game screen - portrait only Develop graphics     differ from tic tac toe sample, show 9 playing fields.     show accumulated score, chosen difficulty.     button to continue play or start over. Suggestion to play on full sized field is good. while showing 9 fields with score now seems within reach. Actions     press one of the nine squares to make a move. Originally, press square on 1 of 9 play-fields for 3rd, 4th dimention. Now, press square on 1 of 9 play-fields current game.     blinks until I'm Finished button is pressed.     Until then, your move can be changed. implementation Main screen     add radio buttons for level of difficulty.     Learn to pass level of difficulty intent to activity. Game screen Develop graphics     modify tic tac toe progressively morphing from sample.     miniturize playing field, with 9 copies on screen. build actions logic     create data structures for score.     Achieve persistence for score, with phone movement     Achieve persistence for score, back to foreground

Keith presents two design files

Re: Project Management discussion, Phone apps

From:	"kxr@netzero.com" <kxr@netzero.com> View Contact
To:	ishtar@pacbell.net
Cc:	edithrasm@yahoo.com
	2 Files  Download All tttdesign.txt (1KB); rpsdesign.txt (1KB)

---

Jarv,

I've attached two design files, one for
TicTacToe and the other for RPS.  They
are not very different, but that's only
because I didn't think very hard about
how the RPS game ought to work.

The real design for RPS should build on
this by writing down several possible
ways to define the RPS user interface.

The paper prototype stage is where you
imagine how to play the game while
looking at imagined screens.

Anyway, I can see from my design files
that the actual input controls are a
rather minor part of the whole app.

design of RockPaperScissors game goals person versus computer   select either to play first   select computer smartness log order of moves taken allow undo allow multiple games   scroll through list of games keep track of scores user interface main screen portrait         RoPaSc    score         rock         paper         scissors       <=    <  >  => landscape         RoPaSc    score         rock <=    <    paper    >    =>         scissors actions press one of the RPS buttons to make a move press and hold buttons to unmove it < button - undo "person" last move     grayed out button if no undo available > button - redo "person" next move     grayed out button if no redo available <= button - scroll back to previous game board     grayed out button if no previous available => button - scroll forward to next game board     grayed out button if no next available press and hold any of the four buttons to act   repetitively as far as possible options menu select computer smartness select game count   before roll off of history help   explain actions implementation build user interface   main screen     portrait     landscape   options menu     help text build input handler   main screen     press actions     press and hold actions   options menu build actions logic   create data structures     as needed for actions

design of TicTacToe game goals person versus computer   select either to play first   select computer smartness log order of moves taken allow undo allow multiple games   scroll through list of games keep track of scores user interface main screen portrait         TicTacToe    score         nine         square         board       <=    <  >  => landscape         TicTacToe    score         nine <=    <    square    >    =>         board actions press one of the nine squares to make a move press and hold square to unmove it < button - undo "person" last move     grayed out button if no undo available > button - redo "person" next move     grayed out button if no redo available <= button - scroll back to previous game board     grayed out button if no previous available => button - scroll forward to next game board     grayed out button if no next available press and hold any of the four buttons to act   repetitively as far as possible options menu select computer smartness select game count   before roll off of history help   explain actions implementation build user interface   main screen     portrait     landscape   options menu     help text build input handler   main screen     press actions     press and hold actions   options menu build actions logic   create data structures     as needed for actions