PixelHero gémájdía 2017. október 30., hétfő - 21:21


Bátyámtól hallottam régen, és már felvetettem az EP csoportomban is az öltetet, nem sok támogatást kaptam. Elvileg régen a prog.hu-n volt róla szó (nem linkelem, mert nem létezik már, de legalábbis nem találom). Eredetileg is hasonló volt a játék (az alapján, amit hallottam), de én azért átalakítanám kicsit, tehát nem ez a hivatalos, nem a régi sztori:

  • webes MMO(RPG) 
  • pixelekről szólna a játék
  • a karaktert és a tárgyakat is mi rajzolnánk meg (mármint a játékos[ok])
  • kezdésként kapnánk pár pixelt, és ellenségeket legyőzve gyűjthetnénk továbbiakat
  • a színes pixeleket csak a saját színükként lehetne eladni és felhasználni
    • esetleg több pixel keverhető lenne az additív színkeverés szabályai szerint, így olyan színekhez is lehetne jutni, amihez máshogy nem, vagy ritkán
  • a fekete pixel (vagy fehér, csak a fekete gyakoribb, de mittudomén') bármilyen színre váltható (ezért többet is ér pl.)
    • de lehet, hogy inkább egy kitalált, "szivárvány pixel" kéne, ami minden színű lehetne (tudom, hogy 1 pixel 1 szín, de ez most játék - nem jó ötlet egyébként, de azé' leírtam)
  • lehetne kereskedni mindennel (tárgyak, pixelek, képességek)
  • nem tudom, mi lenne a fizetőeszköz. (maguk a pixelek szerintem, valamilyen módon.)
  • a fegyverek és tárgyak is átrajzolhatóak lennének
  • minden színű pixel jelentene valamit (zöld = méreg, piros = tűz, kék = fagy, sárga = elektromosság, stb)
    • minél több színű így egy tárgy pl, annál erősebb. minél többször szerepel egy szín, annál nagyobb a hatása (fenetudja, 2 piros pixel = +2 tűz sebzés pl., ha fegyver)

Röviden ennyi az alap. Bonyolítható mindenféle limittel és ötlettel.. pl: minden 3. piros pixel gyengít 1 kéket, de minden 3. kék is egy pirosat, vagy ilyesmi. Ellentétek, de úgy, hogy azért ne oltsák ki egymást..


Mivel a tartalmat nagyrészt a játékosok gyártanák, és a lényegi részt kéne csak lekódolni hozzá, ráadásul az egész mehet PHP-val, hiszen nem kell annyira látványosan dinamikusnak lennie, így nem lenne sok idő összerakni - feltételezem, hogy 1 nap is elég lenne hozzá, ha nekifeszül az ember.

Valamikor mindenképp elkezdem, ha lesz egy kis szabadidőm, mert már évek óta halogatom..  (És az egy új bejegyzés lesz..)

"Mi böki a csőrömet?" 2017. október 25., szerda - 20:20


( igen, a képet letöltöttem, mert az eredeti nem https. )
Rövid bejegyzéseket nem terveztem írni, ezért ha mégis ilyesmi van, és valami gyakoribb dologról, akkor azt "kifüggesztem", lehet ez is egy ilyen lesz, a bal oldali menüben.

Annyi, hogy sokszor elgondolkodok, milyen dolgok zavarnak. Egész apróságoktól nagy hülyeségekig. Egyszer le akartam írni őket (ahogy pl. egyszer az összes általam játszott játék címét leírtam, a(z) (körülbelül) összes látott anime címét összegyűjtöttem, az összes pénz- és börtön szinonimát leírtam, stb.), aztán most hátha tényleg leírom őket..

Szóval, amikor:
  • még az átlag sétatempónál is lassabban haladnak előtted az úton
    • ennek az a variációja, amikor az egész járdát (is) elfoglalják
    • és/vagy az a variációja, mikor annyira mennek gyorsan, hogy nálad lassabbak ugyan, de annyival nem, hogy könnyen meg tudd őket előzni, az meg neked hülye érzés, hogy mellettük sétálsz több másodpercig, mire végre bevágódhatsz eléjük
  •  az ember a Facebookon ->
    • éli az életét, minden részletet megosztogatva (a semmiségeket is beleértve)
    • mindent megoszt, amit lát - konkrétan a tetszik gomb helyett használja a megosztást
    • éli a "párkapcsolatát" (amit ilyen esetben én nem is tudok komolyan venni)
      • főleg úgy értem, hogy ha nem is napi, de heti szinten kirakja a közös fotót a valakijével, mellé egy örökkéSzeretniFoglak maszlagot biggyeszt, meg huszonkétféle szívecske szmájlit
    • mindent szarrá hashtagel. (egyébként a magyar, nem elterjedt megfelelője a címke. szegény kettőskereszt, a mai fiatalság már nem is ismeri, hogy valójában most arról beszélünk.. #poorcross )
    • az adott dolgokat nem rendeltetésszerűen használja
      • nemcsak úgy értve, hogy profilképnek BMW-t rak ki, engem az is zavar, ha tömeges fotót. arra van a borítókép, mondjuk.. (a profilkép célja az lenne, mint az igazolványképé. azonnali felismerhetőség, megkülönböztethetőség, és az ismerősök megtalálásának könnyebbé tétele. amiben nem segít, ha egy zongora a képed)
      • "az élet iskolája", meg hasonlók
      • még a pontatlan kitöltését sem szeretem az adatlapnak, hiszen annak is az információk továbbítása lenne a célja. én sajnos úgy vagyok vele, hogy a Facebookot sok ember használja, így fontos hely, akárki akármit is mond. tehát mindent sok ember lát, amit csinálsz, így az adatlapodat is -> az adataid megadási módját is. ha trehány az egész (meg van adva mindenhova minden, de hülyén), az megbélyegzi az embert. számomra biztosan. úgy vagyok vele, hogy minden mással is így viselkedik, ami fontos. (ha direkt hülyén adja meg, mert ez a stílusa, az persze más nudli.) 
  • a buszra feltolakodik az amúgy egyértelműen bérletesek közé/elé egy olyan, aki jegyet vesz, és emiatt áll a sor egy csomót, pedig értelemszerűen gyorsabb lenne, ha minden bérletes felrohanna
    • ennek egy vállfaja, mikor ráadásul -27 °C van a szabadban
( majd folytatom..  )

Haditechnikai kiállítás 2017. október 22., vasárnap - 10:02


Vagy ilyesmi néven volt meghirdetve a városom műv. központjánál ez az esemény. Hogy az 1956-os forradalomhoz köze van-e, vagy csak véletlenül sikerült 3 nappal előtte, azt nem tudom, de én kimentem, körbefotózgattam, már amennyire engedte a sok kisgyerek.


És volt egy koszorúzás, amivel nem vagyok képben, tehát inkább nem is írok róla.


Ja igen, ez meg ... elég vicces pillanat.. :D Valahogy erre emlékeztet.

Végtelen térkép generálás bármely irányba 2017. október 1., vasárnap - 23:03


Ahogy visszanéztem gyorsan, ez az első tényleg programozással kapcsolatos bejegyzésem. Amikor a blogot kezdtem, úgy voltam vele, hogy itt mindenféle elmélet és megoldás lesz ezen belül. És gondoltam, hogy azért előtte lesz pár bejegyzés, de hogy 51 bejegyzést írjak előtte (több, mint 1 éven át), amiből csak pár darab hajazott a programozásra.. :D (A node.js szenvedésem is csak hasonló volt, de ott a telepítésen volt a hangsúly, nem a használatán.)

Bevezető off.
Szóval:

Ahogy a cím is mutatja - a napokban elkezdtem a szabadidőmben (amikor épp nincs semmi fontos egyéb) egy Minecrafthoz hasonló, de 2D játékot csinálni. Mindezt természetesen multiplayer formába öntve, hiszen mit ér az alkotás, ha nem láthatja senki az eredményt? Mariocraft a kódneve, mert egyébként - jobb híján - Mario a főkarakter, egyelőre.
( Meg hát egy hálózaton játszható játék külön fényévekkel jobb, a legtöbb esetben. )


(Jobbra a kicsit újabb, árnyékos verzió látható.)

És ha már ilyen Minecraft-Terraria típusú játékba kezdtem, eszembe jutott egy olyan téma, amiről szívesen hallanám mások véleményét, megoldási módjait, hátha tanulhatok és/vagy van jobb, mint amit én ismerek. A Facebookos Amatőr játékfejlesztők csoportban feltettem a kérdésem, ami egy elég jó kis közösség - és pár aktív tagja között igazán nagy koponyák vannak, akik nagyon régóta űzik az ipart.


Kaptam is jó néhány választ, néhány még új információ is volt – tehát megérte a kérdést feltenni. Tanulhattam kicsit.

Összefoglalva: a kérdés, téma lényege az, hogy a legtöbb egyszerű játékban elég az, ha a játéktér térképe egy kétdimenziós tömb (főleg a csempéből felépülő játékoknál - erről van egy nagyon jó tutorial itt. Leír mindent, hogy miért jó ez, miért hasznos.).

Ez annyit tesz, hogy csak "egyirányúan" bővíthető a tér. A számítógépen a leggyakoribb módszer a 2D játékoknál (top-down view "felülnézetes", sidescroller "platform, mászkálós"), hogy a nullpont a bal felső sarok. Onnan indul ki a térkép összerakása, és tart egészen a jobb alsóig.
Ez pont kézenfekvő, hiszen a térképet tömbben szokás tárolni, a tömbök indexelése 0-tól indul, és tart N-ig. A tömb dinamikus is lehet, tehát nem lehetetlen, hogy akár játék közben IS nőhessen a pálya mérete. De csak (az előbbit alapul véve) jobbra, és lefelé.

És mi van, ha én egy Minecrafthoz hasonló játékot akarok, de oldalnézetből? Vagy valami katonás, akármilyen játékot felülnézetből? És mondjuk hasonló, generált térképpel, hogy az az érzésem legyen, hogy bármerre mehetek?

Erre több megoldás is van.

Volt, aki azt mondta pl. (Oli volt, csekkoljátok az oldalát, rengeteg jó játékot csinált már! Java és HTML5 főként. Az én kedvencem pl. a JAVA minigolf játéka.),
hogy ez megoldható azzal, ha a tömb elejére szúrunk be új elemeket (ha a mínusz irányokba haladunk), és/vagy csúsztatjuk a tömb elemeit (inkább ezt írta, csak nekem elsőre beszúrás ugrott be, de az sem butaság, amennyiben feljegyezzük, hogy mennyivel lett csúsztatva a pálya, és ezt minden koordinátájához hozzáadjuk. Akkor ránézésre nem mozdul semmi sehova, de mégis nő a pálya mérete.) Ha csak csúsztatunk az elemeken, és ami kicsúszik, az elvész, akkor nem jó az ötlet egy dinamikus pályával rendelkező játékhoz, de egyébként igen.

Volt, aki hasonló, indexeléses módszert írt, seed alapon generálással (így simán csak ugyanazt generálja a játék az adott helyen, ha visszatérünk oda). Ez akkor nem jó, ha változtatható a pálya. Mint jelen esetben.

Kaptam egy Circular buffer nevű módszert, amit még nem olvastam el részletesen, de ez is új infó nekem, ennek egy változatát már használtam, anélkül, hogy tudtam volna róla, meg arról, hogy mi ez.

Még páran írtak, egy elég jó kis beszélgetés lett belőle.

Az én módszerem annyi, hogy adott egy (Minecraft megnevezéssel) chunk, egy darabka, egy részlet a pálya egészéből. Ez magába foglal N*N további kis játékelemet, "csempét" (tile-t). A Minecraftban ez 16x16x16 méretet jelent (mert 3D), de a mérete mindegy. Lényegében ezen chunkoknak is van egy koordinátája, ami ugyanúgy 0, 1, 2, stb., de egy ilyen koordinátán N*N elem található. Úgy is mondhatjuk, hogy az 1/N-ed része a pályának egy chunk.
Bár a pályát, a chunkok tartalmát tömbökben tárolom én is, de magukat a tömböket objektumok értékeként. A tulajdonság pedig egy string, egy szöveg, ami tartalmazza a chunk koordinátákat is.
Mivel ez egy szöveg, ez mehet negatív egész számba is, hiszen az is szöveg. Hivatkozásképp van használva, kicsit úgy, mint egy asszociatív tömb. Így nem is lassít semmit (érzékelhetően), annak ellenére, hogy string.

Ez kicsit zagyva lehet, de épp ezért gyorsan megírtam működőben is, hogy tesztelhető, látható legyen, mire gondolok. Így nem elég, hogy "negatív indexbe", mármint koordinátára is mehetünk a játékon belül, de ez generálható a végtelenségig, mert ugyanúgy dinamikus, és még a tömböket sem kell birizgálni, ha újabb tér tárul fel, így nincs plusz processzorhasználat sem.

Ide kattintva megnézhető a kis tesztem.
Az irányítás is egyszerű: a kurzorbillentyűk a vörös téglalapot mozgatják. A WASD pedig az egész nézetet, amit csak látunk.

A vörös téglalap mutatja a játékos képernyőjét; ha ez egy játék lenne, azt a területet látná be a játékos. Ahogy látható, mindig előre betöltődik annyi, amennyi szükséges, a chunkokból. A kirajzolás persze nem így történne, hiszen ez nem túl takarékos, de a bemutató célja nem is az volt.
A két kék vonal szimbolizálja a nullpontot, az X és Y tengelyt, amitől "jobbra" és "lefelé" szokás a pályát építeni alapesetben - de itt ugye átléphető minden irányba, bármekkora távolságra.



Egyébként a barátommal beszélgettem, miközben beugrott egy sokkal egyszerűbb módszer is, ami ugyanezt eredményezi.


Ez pedig annyi, hogy négy térkép tömb van, ami tárolja a pályát. Általában egy van, de ha vesszük a két tengelyt, akkor az 4 részre osztja a pályát, és pont az a gond a tömbbel, hogy nincs negatív index.
De ha van egy topright, bottomright, bottomleft és topleft tömböm, amik a négy teret szimbolizálják, akkor már más a helyzet. A bottomright-ot használjuk ugyanúgy, mint alapból szokás. Az összes többi pedig a tükörkép. Mielőtt dolgoznánk a tömbünkben, előtte egy vizsgálat eldönti, hogy melyik tömbben dolgozunk a 4 közül. Ha negatív az X, akkor értelemszerűen left lesz, különben right. Ha az Y negatív, akkor pedig top lesz, különben bottom. És már csak annyi az extra, hogy a tömbhöz használt index-számot, ami egyébként koordináta (valószínűleg), annak az abszolút értékét használjuk, bármelyik tömbben is dolgozunk. Így a mínuszból plusz lesz, és egy sokkal egyszerűbb módszert kapunk a 4 irányba való generáláshoz, szintén végtelenségig (hiszen dinamikus ugyanúgy lehet mind).

De ezt most nem valósítom meg, el lehet képzelni. :)

Ezért szép a programozás, végtelen megoldás van ugyanarra a "problémára", még ha némelyik nem is a legjobb.