Josef,
Try to keep the game simple. Something like the old
"PONG" ping pong game would be easy to implement.
"BREAKOUT" is another old game that lends itself to
fairly simple programming. Look at some of the really
EARLY video games for inspiration.

For those who may not know,
PONG was the very first video game. You have two
paddles on the screen that are just short vertical
bars that can be slid up and down. A ball consisting
of one or four pixels is launched by the program,
and the player tries to return it. You can handicap
the computer side by giving it different values of
delay. That allows the game to be played on different
levels. As you get better, the computer gets faster.
Paddle size also sets difficulty level.

Resources required are pretty low. An xy value defines the
current ball location. Only a y location is needed for each
paddle, as they are fixed in the x direction. If you keep
track of average paddle velocity you can use that info to give
"spin" or "english" to the ball. The ball has a direction
and a velocity as well as xy position, but these can be bit
encoded into a single byte. When the ball's xy matches the
x of the paddle, check the y value to see if it is within
the y range occupied by the paddle. If so, the ball gets
returned based on velocity/direction/spin, etc. And you
can keep track of number of user returns, if desired. Same
goes for computer paddle. Whenever ball's next calculated
position is off the screen or behind the paddle, then that is
scored against the paddle. There is really little difference
between the handling of the user paddle and the computer's paddle.
Thus the same code can do double duty. Scoring info can be
"on top" of the playing field, or relegated to an edge of
the screen. For the world's simplest scoring indicator, use
two rows of pixels that grow with increasing score. Simple,
and you can see at a glance who is winning.

Another simple game is the WORM. There are pixels on the screen
that you try to get without hitting the edges of the screen or
certain simple barriers. Everytime you "get" one of the pixels
your worm grows one pixel longer. You can only gather pixels
by hitting them head-on. As your worm gets longer it eventually
gets in the way and it ends up hitting itself. Speed sets
level of difficulty.

Hope this helps.
Fr. Tom McGahee

----------
> From: Josef Hanzal <euroclass@PHA.PVTNET.CZ>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: A game for graphical LCD [OT]
> Date: Sunday, May 31, 1998 3:50 AM
>
> I am designing an instrument which should provide the user with an option
> "to play game" (of course in the spare time). The instrument is equipped
> with graphical LCD 128 pixels wide, 64 pixels in height, several keys
> (probably membrane keypad in final version). The display ON and OFF time is
> about 250msec, so it does not allow any fast actions.
>
> The question is what game would fit the display size and speed and use small
> number of keys (say four). It should be game for one player. To stay
> slightly on topic, there are at least two PICs inside each instrument. TIA
> for any suggestions.
>
> Josef
>
> ======================================================================
> Electronical devices for chemical laboratory, custom electonics design
> ----------------------------------------------------------------------
> Snail Instruments                     Josef Hanzal
> Vojanova 615                          phone/fax: +420-311-24433
> 266 01 Beroun                         e-mail: euroclass@pha.pvtnet.cz
> Czech Republic                        URL: http://www.vitrum.cz/snail/
> ======================================================================