User Interface Software
05-830 Spring 2000
Benchmark Program – BeatMania type
DJ simulator
By Chun-Kwok Lee
Introduction
BeatMania is an arcade game produced by Konami that become
extremely popular in Asia. Since its original release in 1997, the machine
itself has gone through five generations. This unique game has also created
a gene in itself, with over 30 similar games produced over the course of 3
years.
BeatMania is sometimes referred to as a “DJ simulation”
game. The arcade machine has 5 buttons and one turntable, and each control
corresponds to a different position on the screen. Different types of music are
played during the game, and once the music starts, the screen shows color bars
in different positions start falling down. The goal of the game is to hit the
correct control at the right time when the color bar drops to the bottom. When
the control is hit, certain notes or special effects are played to complement
the background music. The combined music will play beautifully if the notes are
all hit at the correct moment, and vice versa. The final scores are determined
by how well each notes are “played” by the DJ. Two players mode are supported.
In this case, the two players play different parts of the music at the same
time.
The goal of this project is to use reproduce a
BeatMania-like game under different platforms to serve as a benchmark test for
user interface development. It represents user interface systems with real-time
animation, sound outputs, and quick response time of control.
Specification
An input file will be supplied to the game describing a list
of events that happens during the gameplay. Events include the time and
sequence of the notes, sound files to be played associated with each note, the
tempo of the music, and the graphics files to be shown at specific times.
Upon reading the input file, the game starts by placing the
first notes to the top of the screen in the form of horizontal bars at
different positions. Then, the bars drop one slot downward and a new row of
notes is drawn on the top, as specified by the input. While the note start
falling to the bottom, the system watches for user input. As specified keyboard
is not available on the PC platform, the standard keyboard is used. Different
keys are assigned to the various notes on the screen. Upon pressing a key, the
system immediately plays the corresponding sound file. Next, the system
calculates the difference between the time the user hit the note and the time
the note intended to be hit. The difference is used to determine how well the
user plays this note. There are 4 levels of performances for each individual
note: “Great”, “Good”, “Bad”, and “Poor”. The words are shown on the screen
whenever the user tries to hit a note.
The final score is calculated by accumulating the scores
from individual notes. The system starts with a non-zero score. It will
increase a certain amount when the player performs “Great” or “Good”, or
decrease otherwise. The score is bounded by 0 and a certain upper score, which
means that there is no way to score below zero or above the maximum score.
However, if the score reaches maximum, the score will lower again if the player
does “Bad” or “Poor” in the future.
Additionally, graphics will change from time to time as
specified in the input file. Also, sound files containing music will play
unconditionally without the user pressing any keys at times that are denoted in
the input.
After all the notes are played, the final score is
calculated and displayed to the player. The system determines whether the
player succeeded in this game by scoring over a threshold value or failed
because the score is lower than the threshold.
Platform Comparisons
Development Time
The following is a comparison of the different toolkits
used so far:
| |
Director 7.0 |
Win 32 |
MacOS |
Amulet |
| Time to learn (hours) |
4 |
5 |
10 |
5 |
| Implementation time (hours) |
16 |
25 |
20 |
18 |
| - design |
1 |
1 |
1 |
3 |
| - layout |
6 |
1 |
0 |
0 |
| - referencing documentation |
2 |
2 |
3 |
1 |
| - coding |
1.5 |
16 |
12 |
11 |
| - debugging |
5.5 |
5 |
4 |
3 |
| Total |
20 |
30 |
30 |
23 |
Macromedia Director
In Macromedia Director, most of the time was spent on
either the layout or the debugging phase of the development cycle. Since this
tool is highly interactive, most of the task in building a prototype are not
directly concerned with code, so the coding time is comparatively small. Debugging
is very difficult in Director. At times the tool reports no error at all,
and seems to allow all kinds of syntax, but later the user finds out that
what it did is not what he/she wants. Worse, users frequently get no output
while they expect them to appear, and finds no way to find out the bug.
Win32
A lot of time has been spent on actual coding in implementing
Win32. However, this may be due to the fact that this is the first real running
implementation, so a lot of application code not related to UI has to be written.
During the implementation of the other toolkits, a lot of code can be reused,
which reduced development time significantly.
MacOS
I spent a lot of time learning the MacOS programming
environment. It is actually very similar to the Win32 API, but the documentation
of MacOS is not as convenient as Windows, and finding a good reference is
not easy.
Amulet toolkit
For Amulet, I spent more time on design than on the
other toolkits. This is probably due to the fact that Amulet contains many
not so common techniques like prototype instance and constraints, a lot of
code has to be redesigned to take advantage of those features.
The Amulet was most suitable for development of programs
with direct manipulative user interfaces. However, it also fits particular
well with this benchmark, which stress on animation, graphics, key press events
and synchronization. The Amulet toolkit has support for most of the features.
This implementation covers most of the details in the
specification, except multiple channels of sound playing simultaneously, which
is not available in Win32. It has double buffering by default, so the screen
flicker of the Win32 implementation was eliminated. It performs quite effectively.
In this implementation, each note is represented by a graphical object attaching
to the main window. There are usually at least 160 notes, and each note contains
constraints that calculate its position and visibility. The performance is
almost the same as theWin32 implementation.
File Size
The following chart summarize the size of the difference
implementations:
| |
Director |
Win32 |
MacOS |
Amulet |
| Lines of code |
60 |
1134 |
1255 |
967 |
| Source file size |
8.5Mb (.dir file) |
29.9kb |
56kb |
24.5kb |
| Object code size |
1.4Mb |
208kb |
732kb |
1.76Mb |
The Director implementation almost contains
no code. All the interactions are laid out in the Score window graphically.
However, it has a severe limitation in that it is very difficult to program
in Lingo code that dynamically change the scene according to an input file,
which this implementation requires.
The Amulet toolkit generates the largest object code.
This is probably due to the inclusion of the whole Amulet library.
General Discussions
There are a lot of advantages in using Amulet. For example,
the use of constraints really simplifies a lot of code. Previously, the programmers
have to keep track of the variables themselves, and have to remember to update
values whenever necessary. However, one constraint set at initialization time
can take care of all these. Plus, constraints reduce error also because of
the above reason.
Separating the interactor from the object itself provides
much flexibility. However, sometimes it is difficult to determine which and
how interactors are used. The prototype instance model provides a very convenient
way of rapidly embedding in-context information in the graphical object. This
kind of integration leverage the programmers having to remember the different
locations data are situated in.
However, the disadvantages of using Amulet include no
sound support. I have to use the Win32 interface again. There is also no key-up
event generated, but sometimes it is useful to have this event, for example,
to provide visual feedback while a key is held down.
Director, on the other hand, is an excellent prototyping tool. It is ideal
for developing multimedia programs with simple interaction effects. Another
requirement is that what is shown on the screen shown largely determined in
design time. Otherwise, it is very hard to program in Lingo to set things
up at runtime.
Win32 is probably ideal for developing small Windows
utilities that must consume little space and run fast. However, its complexity
and primitive API calls may be difficult to learn at first.
MacOS is very similar to Windows in terms of the programming
model. However, it lacks preemptive multi-tasking, so the programmer has to
write code give up CPU time for other programs. It also requires the programmer
to determine the expected amount of RAM the program uses, which is not sometimes
determinable in design time.
MacOS and Win32 programs have giant switch/case loops that do all the decision
making for different input. This can make the code less easy to maintain.
In contrast, Amulet eliminates this by having command objects and constraints.
The organization of the code is better done in Amulet
As a conclusion, Amulet is a easy-to-use, easy-to-learn,
cross-platform toolkit that implements a lot of good programming models to
help the programmer in coding the user interface software. It can also reduce
development time and source code size.
Screenshots
Win 32 screenshot
MacOS screenshot
Amulet screenshot