N/A game objectives

Comments

This movie was created mostly using a computer program,
the development of which took several months and several iterations.

This movie plays using the default settings of the game. That is,
it starts from the first board and uses the default friction setting.
Given the arbitrary selection possibility for friction, the default value
gives a reasonable baseline for comparisons to other players' results.

The development of this movie began in late 2006, after Comicalflop
suggested the possibility of writing a computer program to calculate the
optimal shots. I started writing my bot as a sort of competition
between qFox and I.

As a programming challenge, it was very interesting,
because of the infinite possibilities for improvements.

The source code of my first version of the bot can be
seen here. It determined
the most optimal shot, then moved on, repeated ad-infinitum.
However, it was quickly seen that
such a naive bot has its shortcomings.
This game has a RATE mechanism that causes
the board clearing to take longer and longer time until it
is practically impractical. By board 27, the bot had already
consumed 29 minutes in the movie.

It was determined that any bot would
have to start shooting "dummy" shots in the between; shots that
would pocket no balls at all, but which would simply reset the
RATE value.

This was relatively easy to program, but not a trivial change
to make: Instead of 80*256 shots (20480) to determine, there
would be 80*256 + 80*256*80*256 shots (419450880) to determine,
per each round. It was obvious that something would have to be
done for the movie to be finished within a decade.

So I designed lots and lots of heuristics by which the attempts
could be cancelled as early as possible. Wrote code which attempts
to save frames (in testing) by reusing cursor positions and choosing
the velocity values in the order that they become available.
And I added multiprocessing, which analyzes four different
ways of shooting simultaneously using the quad-core CPU.

Even this was not enough, so I had to limit the search space
somewhat so that only some second-shots would be analyzed.
The second-shots to be analyzed would have a velocity and angle
range much smaller than for the first-shots. This would reduce
the search space from 419450880 shots into 80*256 + 41*256*29*112 (34111488).
This reduced number is only 8 % of the original number.
Even with this reduced number, it took about 3 days per average
for the bot to do a single round; about a week by average to
clear a single board.
This movie does not utilize the "suicide" option that
was used in the frictionless submission.

However, much to everyone's surprise, the bot managed to
find a bug in the game. You can see it in this movie in
a few boards, described below.

Score and RATE

In Lunar Ball, each successful shot increases the "RATE" value of the player;
each unsuccessful shot resets it.
The higher the "RATE" value, the more points the player is awarded for the
next successful shot. Points are awarded at a rate of 10 points per frame.

The RATE value maxes at 99, at which point completing a single board can
give about 12000 points IIRC. Tallying that amount takes about 20 seconds.
Because nobody wants to watch 15 minutes of score tallying, it is a good
idea to reset the RATE value every once in a while.

In this movie, the RATE value is reset by shooting shots that do not pocket
any balls. Such shots achieve to reset the RATE value, as well as to move
the balls into a more optimal position for the actual shot that pockets them.

Board by board comments

Stage 01, Standard board

Shot 1

RATE=01

Positioning only. Push balls 1, 3 and 5. The bot determined that it can do a much better shot after this shot.

After shooting the last shot, the input is terminated.
The triumphal ending is seen after the board is completed.

Other comments

Thanks to:

Comicalflop

qFox

Derakon

Xkeeper

Adelikat

Nach

Bisqwit

Jemini, Teramoto, Miyamoto, Yunoki and Niitani -- the Compile crew credited in the game

FractalFusion: Set to delayed while the author works out improvements.
Bisqwit: Framecount goes from 85834 to 85792 in this update. Submission is "new" again. And I think, unfortunately, it will probably still fail for some emulators. At least the stage 60 has now been exhaustively tested.