Użytkownik "jacem" <j...@1...pl> napisał w wiadomości grup
dyskusyjnych:hmgm9b$e7b$...@a...news.neostrada.pl
...
> Jak myśli człowiek w trakcie takiej gry?
> Sławku, grając w tetris, jaką obierasz strategię?
> To pierwsze, podstawowe założenie.

Ja tam "nie myślę" - tzn. nie stosuję jakiegoś formalnego algorytmu. Więc
raczej blado od tej strony. :)

> Chyba bajbardziej optymalne byłoby dążenie do zapewnienia jak najbardziej
> płaskiej powierzchni.
> I od tego należałoby zacząć.
> Mnie się prędzej nasuwa analogia do gry w kółko i krzyżyk niż szachy.

Kiedyś napisałem program grający w kółko i krzyżyk - algorytm był
jednolinijkowy, do dziś pamiętam:

n = (n + 1) mod 9

Sprawdza się na planszy 3x3, AI zawsze jako druga, numeracja pól jakoś tam
sobie szła. Nie wygra i nie przegra. Czysty minimax.

> Ludzie, którzy na codzień zajmują się tworzeniem gier, na pewno dadzą
> wyczerpującą odpowiedź. Przypuszczam, że tego typu problemy mają już dawno
> rozpracowane.

Zgoda, ale NIE chodzi o to aby ZROBIĆ TO - ale aby zastanowić się JAK DUŻE
TO BYŁOBY WYZWANIE.

I odpowiedź niekoniecznie nieomylna - może algorytm da się streścić w paru
linijkach? A może porządny algorytm to jakieś 10 tysięcy linii kodu? Mnie
nie interesuje, by taki napisać (bo i po co?) - ale aby zorientować się, jak
bardzo ufacie swoim ulubionym językom programowania. Jeżeli ktoś np. pisze,
że PHP jest cool - a potem nie potrafi ocenić, ile musiałby naklepać tego
PHP aby mieć "program rozwiązujący łamigłówkę Tetris" - to czy PHP jest taki
cool? Zamiast PHP podstawcie sobie inne języki, przeiterujcie.

Jeszcze jedno - zakładam że program nie musi być the best - takim "terisowym
mistrzem" - patrz Głęboko Niebieski i gra w szachy. Chodzi tylko o to, by
grał sportowo, uczciwie. Dlatego odpadają programy upuszczające klocki tak
jak są, albo upuszczające je z losowym obrotem i przemieszczeniem. Pewnym
utrudnieniem mogłoby być przesuwanie klocków tak, aby wlazły pod inne
(pozwalamy opaść w pewnym położeniu... i myk w lewo lub prawo gdy będą już
na dole) - więc załóżmy że tego robić nie wolno.

Ja bym próbował np. tak jak poniżej. Nie twierdzę, że to dobre rozwiązanie.

Przesunięć jest może 10, obroty mnożą to przez 4, symetria może zredukować.
Czyli jakieś do 40 pozycji do rozpatrzenia, powiedzmy 2^5. Typów klocków
jest może z 2^4. Stąd przewidywanie jakie przyjdą kolejne dwa (mając już
jeden) i spasowanie ich daje łącznie (2^5)^3 * (2^4)^2 = 2^23 = 8 milionów
kombinacji. To niedużo - jeżeli jeszcze uda nam się ograniczyć trochę
(usunąć te, które są ewidentnie złe, odfiltrować symetryczne). Czyli
wstawiamy klocek tak, aby optymalnie pasował - biorąc pod uwagę kolejne dwa,
których jeszcze nie ma. I od nowa.

Musimy jeszcze jakąś reprezentację mieć planszy, klocków, definicję
"optymalności" - nie mówię że to łatwe i nie jest pracochłonne.

Ale zakładam, że program ma prawo się mylić - tzn. nie musi sprawdzać
wszystkich możliwości, może używać funkcji random (jeżeli to uzasadnione).

Trzebaby pogooglać - może są jacyś entuzjaści tego typu programów. Ale nie
chodzi o sam program - lecz o zagadnienie, które: a. można zaprogramować; b.
nie jest to "typowe" programowanie
kadry-płace-excel-webmastering-cholera-wie-co; c. fajne jakieś takie wyszło.

Moim zdaniem ciekawiej jest porównywać "jak duży ma być program układający
Tetris" - niż programy "Hello, I am Jan... Jan B."

slawek