Ktorá metóda je rýchlejšia pre testovanie možných ťahov na šachovnici?

Postav to na OOP a dedicnosti. Pak kazda figurka bude vedet, kam a jestli muze tahnout.
Jen provedes:
if Figurka.TahniNa('B6') then ...

Bude ti jdno, jestli to bude kral nebo strelec. Figurka si osetri, jestli tam muze jit a pokud dojde k sebrani souperovy figurky, muze vyvolat nejakou udalost.

Dobre, tak sa o tom rozpíšem viac.

Ak napíšem toto, tak za každú figúrku budem musieť prejsť celú šachovnicu a teda ak na šachovnici bude povedzme 35 ťahov pre danú stranu, tak prejdem šachovnicu toľkokrát, koľko mám figúrok a dostanem 35 ťahov. Ak by som to postavil na testovaní podľa figúrok a priamo ich možné ťahy, tak prejdem vybrané miesta na šachovnici toľkokrát, koľko je figúrok. Zdanlivo je to rýchlejšie, ale pri tomto musím testovať priamo vhodné polia a niekde vyexportovať možné ťahy. To by nebol problém, akurát, že musím vedieť koľko ťahov je maximum, čiže nevýhoda. Nespomalí mi teda prebehnutie celej šachovnice toľkokrát koľko je figúrok program?

Ted jsem trochu na rozpacich...
Chces zkontrolovat tah figurky nebo hledat optimalni tah pocitace ?

Hľadať optimálny ťah počítača metódou Minimax, Alfa Beta a podobne, aby to zabralo čo najmenej strojového času. Dokonca myslím, v tom prípade môžem na OOP kompletne zabudnúť, pretože OOP je ďalší slimáks káblovou televíziou a širokopásmovým Internetom v ulite.

Pak bude asi nerychlejsi, kdyz si po kazdem tahu figurky vybudujes seznam poli, na ktera muze tahnout. Pak budes prochazet pouze seznam poli, ktera pripadaji v uvahu. Rychleji to asi nepujde...

Dobre a teraz ohľadne jazdca (v prípade veže to nie je až tak nutné) mám dať mantinel a nekontrolovať, či je rozmer mimo šachovnice alebo otestovať rozmer a potom, či je ťah možný? Osobne si myslím, že test s kontrolou je rýchlejší. Toto je vlastne otázka, ktorú som položil na začiatku.

OMG ved pise ze najrychlejsie je ak si pred testovanim tahov vytvoris nejake pole v ktorom budu mozne cielove policka danej figurky. Tie sa daju urobit jednoducho pre kazdu figurku (pre kazdu osobitny algoritmus).
Zavisi co presne potrebujes mat rychle.

Dilemovat ze ci urobit if(x>8) alebo if(dx==dy) je uplne nepodstatne, su casovo rovnocenne.

P.S. "mantinel" z figurok je nezmysel, kon by ti to mohol preskocit. Celkovo na to ides nejako moc divne.

P.S.2. nemusi to byt ani pole moznych tahov v RAM, staci ak to budes robit v cykle pre kazdu figurku tahy. Napr.
testuj_tahy()
{
for(x=0; x<8; x++)
for(y=0; y<8; y++)
switch(sachovnica[x,y])
{
case VEZA:
tu si v cykle vytvoris mozne tahy veze z x,y
a zavolas OhodnotTah(novex, novey)
apod.
}
}

No a na toto potrebujem vedieť, ktorá metóda je rýchlejšia. Už rozumieš?

Ja te nechapu. Kdyz tahnu fugirkou, tak si po dokonceni tahu vytvorim novy seznam poli, kam muze figurka tahnout. Zrovna tak si vytvorim novy seznam pol pro figurky, ktere svym tahem ovlivnila.
Pri vyhodnocovani projdes pole moznych tahu bez jakehokoliv testovani.

Pokud chces hledat opravdu tah za pocitac, potrebujes si nastudovat teorii her a budes muset kazde pole ohodnotit z pohledu vsech figur - to znamena nekolikere prochazeni.

On ma dilemu prave pri tom vytvarani "pola moznych tahov", ze ci ma pri teste (ci je tah mozny) testovat okraje sachovnice, alebo len mantinel z figurok (tah na vlastnu figurku nie je mozny) a netestovat okraje sachovnice.

Už dilemu nemám. Mantinel prehral, zdal sa mi pomalší, takže to vyhráva if. Tiež som uvažoval o tom, že pri mantinely je zbytočné počítanie adresy pola, kontrola obsahu a podobne a if to urýchli. Pre Jazdca bude teda if a ostatné figúrky nepotrebujú mantinel.

ostatne figurky nepotrebuju mantinel ?

Nie, lebo testovať budem postupne po koniec šachovnice, ale pri jazdcovi sa testujú priamo polia, kam môže ísť, keďže on figúrky preskakuje. Tak to bolo myslené.

A myslis ze ak testujes "po koniec sachovnice", ze tam nie je test (if) na hranice sachovnice? Co robi "for" pri kazdom prechode cyklom?

Naštudovanú teóriu ťahu počítača v šachu už mám približne natoľko, že sa do toho môžem pustiť. Možno nejaké úpravy algoritmu nechám okomentovať poradňou. Ide o hlavne o rýchlosť a tiež aj jednoduchosť (aby som nemusel určité veci písať 2x, keď to netreba.

Abys urcite veci nemusel pocitat 2 a vicekrat a abys to mohl jednoduse pouzivat, tak presne k tomu slouzi tebou odsuzovane OOP.

Ja by som ho použil, ale sa bojím, že pri použití OOP bude počítač rozmýšľať 10 sekúnd a bez neho 3 sekundy. Je to tak alebo sa mýlim?

Nechapu, jaky by k tomu mel duvod.
Rychlost zalezi na tom, jak kvalitne napises kod, ne jestli pouzijes nebo nepouzijes OOP.

Pokud OOP nepouzijes, budes mit program plny podminek, kde se budes rozbocovat podle druhu figurky.

Predstav si ze to udelas nejak takto:
Udelas tridu figura, nadefinujes ji vlastnosti a metody, jako mozne tahy, barva, jmeno, ...
Od ni odvodis jednotlive figurky, prepises jim metodu pro tah. Jmeno nastavis v jejim konstruktoru.

Pak si vzpomenes, ze potrebujes ke vsem figurkam pridat jejich vahu. V OOP to pridas predkovi a v constructoru nastavis.
V proceduralnim programovani to znamena upravy parametru funkci a zmeny na spouste mist.

To znie je zlé. O OOP uvažujem, ale z hľadiska zjednodušenia. Pohyb by som vedel jednoducho riešiť aj bez OOP a to tak, že každý pohyb bude mať bitovú váhu:

Bity:
0-pešiak
1-jazdec
2-strelec
3-veža
4- kráľ
5-biely
6-čierny (dá sa aj zrušiť v prípade, že nemám (a ja nedám) mantinel)
7-pre vlastnú potrebu (možno využijem, možno nie)

Dáma nie je potrebná, tá bude mať nastavené bity 2 a 3, čiže figúrky budú:
1-pešiak
2-jazdec
4-strelec
8-veža
12-dáma

Pohyb figúrok je takto nezávislý od metódy, pretože metóda ani nespozná, či má vežu alebo dámu. Akurát sa pohyb rozvetví pri dáme aj pri podmienke na strelca.

No, doufam, ze ten sachovy program pak uvolnis jako Freeware. Bez OOP se v tomhle moc nechytnes, propripade se zachvili ztratis ve svem vlastnim zdrojaku.

No vlastne aj OOP sa dá s týmto skombinovať. Urobím vlastne objekt figúrka a priradím im "hodnosť" a ťahy sa budú hľadať podľa hodnosti. Osobne sa mi moc nevidí robiť povedzme dámu ako potomka strelca a čo potom v vežou. Multidedičnosť v Delphi nie je? Myslím, že nie, ale aj tak neviem ako by som dokázal multidedičnosť skombinovať. Okrem toho Pešiak sa môže zmeniť na dámu a tým by som musel zrušiť objekt a vytvoriť nový, takto univerzálnemu objektu zmením vlastnosť. No a poprosím konštruktívnu kritiku, ako by to bolo ešte lepšie.

Proc bys delal takove silenosti typu Dama potomek Strelce?
Dama je jako ostatni potomek tridy Figura

To bolo len tak akože. Mne sa skôr najlepšie vidí varianta, kde figúrke nastavím vlastnosť, ktorá bude znamenať jej hodnosť. Čiže objekt figúrky a vlastnosť hodnosti. Je to jednoduchšie naprogramovateľné a pešiak sa pri dosiahnutí poslednej pozície len zmení a nemusí sa vytvárať nový objekt. Alebo tento nápad je nevhodný?

Pridani property do objektu ti neovlivni zbytek programu.
Pridani property do predka = property je dostupna ve vsech potomcich.
Pridani parametru do procedury znamena opravovani na hodne mistech.

Objekt figúrky by mal danú vlastnosť. Figúrka by bol univerzálny objekt. Niečo ako TBitBtn s vlastnosťou Kind.

Videl bych to tak (laicky):

Trida Figura - ta by obsahovala mimojine atribut zda je dana figura cerna nebo bila.
Tridy Pesec, Vez, Jezdec, Dama, Kral, Strelec - potomci tridy figura, navic atributy ohodnote figury.

Pokud jde o promenu pesce, tak tam bych to resil asi tak, ze kdyz by dany objekt presec zanikl (dorazil na posledni radu), tak by se vytvorila nova instance tridy nektere figurky na miste pesce.

No pak by asi byly jeste treba tridy Sachovinice a Policko, pak nejaka trida Engine, kde by byla ulozena sachova logika.

Triedu policko by som radsej vynechal, nech to nerata jeden tah pol minuty.. Sachovnica by mala mat IMHO nejako optimalne ulozene udaje, pole tried a podobne orangutany nepovazujem za optimalne.

Aniž bych pozorně četl tuto diskuzi, házím sem odkaz

chess

který by se možná msx. hodil.

Zdrojáky KC Chess ve čtivém Pascalu, dobře okomentované...

Vyzerá to dobre, ďakujem za link. Ale prekvapilo ma, že keď som začal hrať, dostal som sa k možnosti brania mimochodom. Hra mi to umožnila, ale čierny pešiak ostal (či len opticky alebo fyzicky, to netuším).