cs349 - Developing User Interfaces - Spring 2005
Assignment 1 - Game interfaces. 2D graphics - Draft.
To be handed in before: 23h59 June 3, 2005.
Overview
Assignment 1 asks you to develop a simple game based on an event loop
written in C, with Xlib as the base window system. Emphasis in the assignment
is
- an attractive functional game interface,
- a well-tuned implementation that is both challenging and playable,
and
- effective use of the events and graphics provided by Xlib.
Resources
Course Account
In the course account, in the directory
/u/cs349/assignments/a1
, you will find three resources to help
you with the assignment.
- A PDF description of the game, which might be called
`Whack-a-jinnee'.
- Source code of a simple event loop program with a blocking event loop
to help you see how XLib and C work together. It shows you:
- how to get events,
- how to use data from event structures, and
- how to use a display list for repainting the screen.
- The binary, executable but not readable, for a prototype model
solution, made by Erin Lester, which you can execute to answer questions
about how the game is supposed to work.
Note that this prototype solution assumes that the player has enough
imagination to see bottles and corks in simple geometric objects. In judging
the success of your implementation we assume that players are typical
graduate students, and most highly reward assignments that make neat looking
solutions using the simplest of means. For example, don't use colour; you
will lose marks for doing so.
The prototype solution is intentionally a mediocre and incomplete version
of the game. Submitting an exact replica of it will not achieve a high mark
on the assignment.
Web
In addition there are resources on the web that will help you with
programming Xlib using C/C++. Here are a few, far from the only ones.
You are assumed to be capable of using documentation and examples to find
out how to use a novel programming environment.
Hints
The final source is a set of `helpful hints'.
- You will need two OS services to make an accurately timed event loop:
finding out the current time, and suspending execution for a specific
length of time. When you start to poke around the man pages you find that
there are lots of ways to do timing on Unix, most of them not that great:
too complex, insufficient resolution, etc. Here are my thoughts.
- To find out the current time I can't find anything better than
int gettimeofday( struct timeval *tp, void * )
, for
which you need #include <sys/time.h>
.
- The easiest way to sleep seems to be
int usleep( useconds_t
time )
, for which you need #include
<unistd.h>
.
- It's recommended in the man pages that you sleep with
getitimer(...)
, but you then have to program with
signals.
nanosleep(...)
, and napms(...)
, which
requires the curses headers and library, also give adequate sleep
capability.
- If you want to position text
XStringWidth
will tell you
how long a string is in pixels.
- I use a rough, and easy to program, algorithm for determining if the
mouse is clicked inside a bottle. Users don't notice its
deficiencies.
- I only put corks and bottles into my display list explicitly, leaving
the crate and other stuff in the `display list' that is implicit in the
repaint function.
Hand In
- The source code for your game, which may be in one or more files, plus
a
Makefile
that compiles it. We will compile your code using
your makefile.
- A Readme file. The Readme file should contain the environment (machine
and terminal in the undergraduate environment) on which you compiled and
tuned you game, and pointers to TAs so that they don't miss something
important. It should also contain answers to the following questions.
- What is the most significant improvement in the interface of your
implementation? Why?
- What is the most significant improvement in the appearance of your
implementation? Why?
- Did your hot keys adjust the values arithmetically (by adding and
subtracting) or geometrically (by multiplying and dividing)? Why?
Marking
The marking procedure used by the TAs is the following.
- Execute your program using the following sequence of steps.
cd
to the directory in which your handed in files are
located.
- Execute make as defined in the undergraduate environment.
rees% which make
/usr/ccs/bin/make
- Run the resulting executable
- Inspect the source code you created.
- Read the answers you submitted.
The assignment will be marked as follows.
- Successful implementation of the game as given in the prototype
solution - 25%.
- Quality of tuning, Readme file - 20%. The default tuning of your game
should be hard enough to be challenging, and easy enough to be winnable
for a user who has practiced the game only a little. The Readme file
should contain answers to the three questions given above.
- The improvements you made compared to the prototype solution - 45%.
Some suggestions are given in the game description but you should go
beyond them. Your goal is to produce a game that is attractive, playable
and complete.
- Quality of code - 10%. When considering `quality of code' we will look
at two factors
- use of X functions, overall organization, algorithms, data
structures, and
- variable names, comments, white space, etc.
Return to: