Tetris,
again. Results.
For the reminder, here is the
problem as stated originally.
Entries:
Here are the entries:
Additional non-ranked entry:
Score and comments about the entries:
- #1 -
Finds a good solution, make the squares fall (hence the size of the exe).
- #2 -
Directly outputs the grid without computing anything. It however
takes the 4-char input into account (which is a loss of points! :).
- #3 -
this entry is a little bit messy: there's a CHECK10.C source file
(that does not compile and is a modified version of the originally
supplied 'check.c') that comes with big exe. Should I take the
.EXE or the .C as valid entry? Well. I decide to remaster
the C-source into this (check11.c, 10000 bytes)
and take it as input.
- #4 - As usual, there is an Editor included!
Their search strategy is very good
(look at the C-version 'Tetris_ZeKiller.c').
But at the end, they realized, like entry #2 and #5, that
directly printing the starting grid was a better one. Hehe. That's
the fun :) So it directly prints the grid (internally packed) without
taking the input into account. Good move.
- #5 -
Directly outputs the grid without computing anything, nor
taking the input into account. But the grid is not packed,
so the .com is a little bigger than entry #4. This makes
the difference.
- #6 -
Dolmen sent me an enhanced version of its entry after the party.
This one is a very very small .com that prints the grid directly,
from a compressed form, with the input.
They were some output-formatting problem in some
entries (int 29h instead of int 21h, etc...) which
I won't take into account.
Input:
We need to choose a 4-color starting sequence.
Here are the 91 possibilities.
I used this C-program to search for
a "difficult" starting grid (> 8million grids tested in 1 day)
and to generate the 91 possible starting grids.
Let's pick a starting sequence at random:
"baba" (looks cool:).
The starting grid is then:
char *Grid[16] = {
"adbdcdbdddcbdbab",
"bccbddbccaadcdaa",
"dabdacdbbdacaccd",
"cdababcacbdcadca",
"baadabbabadbaddb",
"addbdaadcdaddcba",
"adcacdabcabcaadc",
"acadcbddbbcdcccd",
"bdbaadaaabdcaaba",
"adadbccbdacddcdb",
"dbaaddbcbdbbbcaa",
"dccbdcbaacaaacad",
"cbdacbcadcbdddcc",
"dbaadbacdcaaacab",
"dbcdcdbadbbbdaca",
"dcddccdcccacdcdb",
};
Results:
Run with "baba" as input, the programs return the following
texts:
- #1 - 01.txt -> Score: 574 + 4648 = 5222
- #2 - 02.txt -> Score: 1012 + 312 = 1324
- #3 - 03.txt -> Score: 582 + 10000 = 10582
- #4 - 04.txt -> Score: 1012 + 198 = 1210
- #5 - 05.txt -> Score: 1024 + 280 = 1304
- --------------------------------------------------------------
- #6 - 06.txt -> Score: 1012 + 123 = 1135
Too bad Dolmen/Experience didn't complete its .com during
the party, he would have won!!
Hence, the final ranking is:
- 1rst: #4 - ChoJin and Ze_Killer / Skytech group
- 2nd: #5 - Valdor / Paradise Studios
- 3rd: #2 - Dolmen / Experience
- 4th: #1 - Mandor & Sylex
- 5th: #3 - Ocean / Experience
According to these results, Chojin and Ze_Killer told me
they decided to give their price for this compo to Knos,
who's been stolen his laptop during the party.
Not only is it the third
time they win a LTP fast compo (with Houhoutigrou and the
other Skytechgroup dudes), but
one can see that their coding skill compares to their
human qualities.
Conclusion:
The funny thing about this problem is that the best
strategy was not the one you would have think of first:
directly printing the grid. However, packing it a little
(2bits/square at least) was worthwhile since it made
the difference.
You should have a look at the .asm source file included in some
entries. It worthwhile to compare to your code if you've sweat
on it ;)
Thanks evrybody for having played the game!
/Skal
And btw, while I'm here, here are some few features I find
important while finding a funny (?) fast-code problem:
- Non-determinism: the program's behaviour should be dependant of an
unknown input. Just to avoid having a too obvious, deterministic,
coding strategy.
However, this input should be of limited range so that people can
still try to precompute (and then, pack) every possibilities,
or attack it with a brute-force approach (refined later on...).
- Text output is preferable, and raisonably big if possible, so
that packing it is worthwhile. It should include penalties if
last stages of search is not complete, so that it's worthwhile
to try to push the search a little bit further.
- The compo should be at least 'triable' by non ASM-guru.
Hence the possibility of submitting a C-source only entry (at
the expense of small penalty compared to a full asm .com).
At least, there must be a 'first-try' obvious strategy
handy, so people can at least try a first draught, quickly.
- Choose the scoring mecanism carefully:
Size of final code should enter into account, but not
*that* much. You must left the door open to small ASM code
being beaten by a better strategy (even written in C).
- It's a plus if the problem is a 'visual' one, so people
can play with finding some solution 'by hand' (it's the second
time the Skytech dudes develop a visual 'Editor' for this
purpose, e.g.).
Souvenir:
Here is last year's LTP3 problem.
I tend to think it was better the year's one. Oh well... :)