Milyen játékot vagy projektet készítsek (pascal)?

Na jó, nem csócsálom tovább a kérdéskört, a legutóbbi módosítások:

[link]

[link]

Pá.

tabaki:

Már tényleg nem bántásból de a kirajzolás megvalósítása kifejezetten olyan, amit mindenkinek el kellene kerülni. Még ha nem is OOP-val dolgozik valaki, akkor is lehet a fejben OOP-s modellt adni egy programnak, noha sima nem OOP-s kód lesz belőle.

Gondolok itt arra, hogy a formák megrajzolását így szétszórni, ilyen értelmetlenül nem szabad. Eltárolni mindenféle koordinátát. Minek? Az egész mérhetetlenül túl van bonyolítva még így is.

Elmondom, kb. hogyan lehetne egyszerűsíteni és hogy kell nekiállni:

Tökmindegy, hogy mit hogy tárolsz és hogy rajzolsz, a lényeg az, hogy van egy 3x3-as tábla és az, hogy ki jön. Nagyjából ez a program állapottere (vagyis a tábla tartalma és a soron következő játékos mindenféle kombinációja az, amit a program fejben tart).

A táblával kapcsolatban az alábbit várjuk el:

- Meg lehessen mondani, hogy a tábla egy cellájában mi található (üres, játékos-1, játékos-2).

- A tábla tetszőleges celláját be lehessen állítani.

- Le lehessen kérdezni, hogy van-e a táblában 3 egyforma egyvonalban.

Legyen a tömb mondjuk T[0..8], vagyis 1 dimenziós!

Ekkor, ha van két indexünk (x, y) a játéktáblára (mindkettő 0..2 tartományban), akkor a tömbbeli index (i) i = x + y * 3 lesz.

Ha van egy tömmbeli indexünk (i), akkor a két index: x = i mod 3, y = i div 3 lesz.

Lekérdezésnél kiolvassuk a megfelelő indexű elemet, beállításnál meg beállítjuk. Ennyi.

A kigyűlés vizsgálata úgy történhet, hogy mindig 3-mat kell megtalálni, pl. az alábbi indexek vannak "egy vonalban":

Függőlegesek: (0, 3, 6), (1, 4, 7), (2, 5, 8)

Vízszintesek: (0, 1, 2), (3, 4, 5), (6, 7, 8)

Átlósak: (0, 4, 8), (2, 4, 6)

Na, mit látunk? Mindegyik egy 3 elemű számtani sorozat. Az ilyenek pedig leírhatók a kezdőelemmel és a növekménnyel. Tehát lesz egy segédfüggvény:

KIGYULT-E(A, D)

var egyformae T[A] == T[A + D] ÉS T[A + D] == T[A + D + D];

if egyformae == true ÉS T[A] != Üres return T[A];

return Üres

Ez a függvény a fenti kombinációk egyikének tesztelésére jó: ha kigyűlt három, akkor visszaadja, hogy kinek gyűlt ki, ha nem, akkor simán az Üres értékkel tér vissza (vagyis azzal az értékkel, ami a tömbben az üres cellát jelzi - én itt "Üres"-sel jelöltem, ez lehet 0, 1, akármi).

Az egész táblában megnézhető, hogy kigyűlt-e valami, az alábbi kifejezés mondja meg:

KIGYULT-E(0, 3) VAGY KIGYULT-E(1, 3) VAGY KIGYULT-E(2, 3) VAGY

KIGYULT-E(0, 1) VAGY KIGYULT-E(3, 1) VAGY KIGYULT-E(6, 1) VAGY

KIGYULT-E(0, 4) VAGY KIGYULT-E(2, 2)

Már csak két dolog maradt: rajzolni és kattintást érezni.

A rajzolást megint elképzelhetjük úgy, mint egy erre szakosodott objektum feladata, vagyis egy olyan programrészé, aminek csak a tömböt adjuk át, ő meg kirajzolja az egész táblát. Mi kell ehhez? Végig kell menni a táblán és a rajzolandó cellához tartozó képernyődarabon.

Most vagy a tömbön megy végig egy ciklus és a képernyőkoordinátákat számoljuk, vagy a táblakoordunátákon megyünk végig egy dupla ciklussal és a képernyőkoordináták számolása egyszerűsödik.

De induljunk el egy darab cella megrajzolásából. Lesz egy függvény, aminek átadunk egy téglalapnyi terület adatait, pl. bal felső sarok és szélesség, magasság, meg azt, hogy melyik játékos jelét kell, vagy üreset rajzolni. Megrajzolja, tök mindegy, hogy részletkérdés: az átadott adatokból kiszámolható a terület középpontja és húzható kör valamekkora sugárral. Rajzolható x is, mindegy.

A terület adatait (x - bal felső sarok X, y - bal felső sarok Y, w - szélesség, h - magasság) pedig a táblaindexből (tx - 0..2, ty - 0..2) lehet számolni:

x = XMIN + tx * szélesség

y = YMIN + ty * magasság

Most innen már akárhogy lehet variálni, hogy az XMIN, az YMiN, a szélesség és a magasság honnan jön. Lehet számolni a képernyő méretéből is.

Az egérkoordinátából meg pont az előző fordítottjaként jön ki a táblakoordináta:

tx = (x - XMIN) / szélesség

ty = (y - YMIN) / magasság

Ennyi az egész. A többi már sallang és lényegtelen részletkérdés. De sem nagy táblázatok, sem case szerkezet nem kellett bele. A program kb. csak 50%-70% olyan hosszú lesz.

Drága Srapnel!

Hm.

Ezért nem volna szabad negatív példákat hoznom, pláne nem ilyenformán: "Hülyeség amit műveltetek, de ha már ezt csináltátok, legalább próbáltátok volna így..."

A legutóbbi gyöngyszemem hitem szerint megint hasonló ahhoz, mint amire te jutsz:

"De sem nagy táblázatok, sem case szerkezet nem kellett bele."

Az iromány első fele arról szól, hogy egy dimenziós tömb használata esetén is ugyanolyan szépen meg lehetett volna

szabadulni a fölösleges CASE-tömegtől és a redundanciáktól, mint az előzőleg közölt kétdimenziós tömbös programban. (Kétségtelen, hogy ezúttal meghagytam az indokolatlan koordinátatáblázatot, hogy Kérdező lássa, mennyivel szerencsésebb konstans alapértékeket egy konstanstömbben tárolni és indexelni, mint ugyanazt az eljárást kilencféle állandó paramétercsoporttal kilencszer meghívni.)

A második rész üzenete pedig ennyi: Ne használj CASE utasításokat, mert akkor a tömbösdinek semmi értelme. elvész az indexelés minden előnye, ezen az alapon akár különálló változókkal is végigcsinálhatod az egészet.

Más szóval: Miután előzőleg mutattam egy nyilván tökéletlen, de Kérdezőénél működőképesebb megoldást, két dolgot próbáltam kiemelni:

1. Ha valami részletkérdésben nem találja meg a megoldást (itt egy szám két indexxé alakítása), attól még más úton lehet használható programot írni.

2. Ha az adatokat értelmetlen módon kezeli a program (CASE-blokkok), akkor az adatok tömbbe való rendezése nem jelent semmiféle előnyt, a priori el van barmolva.

Melyik állítással nem értesz egyet?

Mindkét állítással egyetértek. A megközelítéssel nem értek egyet. Pont a lényeg nincs hangsúlyosan kezelve. Teljesen mindegy, hogy végül egy dimenziós, vagy két dimenziós tömböt használ. Mindkét esetet meg lehet csinálni elegánsan, működően. A lényeg pont a tervezési szakaszban van: a jó programhoz értelmes terven és nem egy rossz programon keresztül vezet az út. A másik probléma a meglehetősen terjengős tárgyalás, amiben megint csak az egyébként többé-kevésbé valóban hasznos megállapítások néha elvesznek.

A kérdező nagyjából egy dolgot nem használt: azt, hogy rengeteg dolog számítható másik dolgokból, ezért nem kell táblázat. Ti. mert az utóbbit ő maga is számolással kapja. Végeztesse el a géppel inkább.

Na, most én kaptam két állítást, amivel egyet kell értenem :)

1. Igen, hajlamos vagyok arra, hogy tekeregjek, mint az ökörpisilés... A szándékom olyasmi lett volna, hogy Kérdező lásson ilyet is, olyat is, az orra előtt egyenesedjenek ki a programgubancok, de lehet, hogy ennél jóval többet ért volna a lényegre szorítkoznom, és arra törekednem, hogy csak értelmes kód kerüljön a szeme elé.

2. Hát igen, a nagybeteg program kikuruzslására tett próbálkozásom homályban hagyta a bajok gyökerét, nevezetesen, hogy A PROGRAM NEM LETT KITALÁLVA (nem szenvedélyből üvöltök, hanem, hogy Kérdező lássa a lényeget, ha erre jár). Tehát azzal illett volna törődnöm, hogy a progi működjön, mielőtt egyetlen sor kódot is begépelne. No mindegy, ez a hajó már elment, de te addig is elég jó alapozást adtál erre, aztán előbb-utóbb lesz egy másik kérdező, annál majd úgy fogom meg a dolgot...