Użytkownik "slawek" <s...@h...pl> napisał w wiadomości
> Ja tam "nie myślę" - tzn. nie stosuję jakiegoś formalnego algorytmu. Więc
> raczej blado od tej strony. :)

Mózg przetwarza, i to intensywnie.
Zagraj w tetris.
A potem przyłóż dłoń do czoła.
Przekonasz się jakie gorące. ;-)

Podejmujesz decyzje "odruchowo", to jasne. Ale nie są przypadkowe.
Czymś się kierujesz.

> 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.

A na planszy 5x5?

>> 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.


Nie mam swojego ulubionego języka.
To tylko narzędzie.
Może być C++, Java, C#...

> 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ę

Skoro klocki pojawiają się przypadkowo, to jaki sens przewidywania?
A ty przewidujesz, który klocek następny podczas układania bieżącego?

> 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

Wszystko zależy od poczynionych założeń początkowych i uproszczeń.
Im prościej, tym bardziej elegancko. :-)

Przypuszczam, że najkrótszy (ale najmniej czytelny) kod byłby w Ruby'm.
(pomijam Perla)




j.