ugrás a tartalomhoz

Magyar, nyílt forrású MMO

Cucu · 2012. Dec. 20. (Cs), 02.33

Pár éve írtam egy cikket a játékfejlesztésben szerzett tapasztalataimról egy Zandagort nevű játék kapcsán. Akkor a kommentekben tettem egy óvatlan ígéretet, hogy összedobok egy MMO „sablont”, ami nyílt forráskódú és viszonylag jól dokumentált lenne, hogy bárki tudjon belőle saját játékot fejleszteni.

Az élet máshogy alakult, így egy év csúszással egy picit módosult formában tartom meg az ígéretem. A rossz hír az, hogy a dokumentáció szinte teljesen hiányzik. A jó hír viszont, hogy nem egy sablon, hanem egy teljes, működőképes és meglehetősen összetett MMO játék forráskódját adom közre. Méghozzá MIT licensszel, ami a GPL-nél is engedékenyebb, vagyis akár eredeti, akár módosított formában, akár nyílt, akár zárt kóddal, akár non-profit, akár kereskedelmi céllal fel lehet használni.

A forráskód a GitHubon érhető el. Mellékeltem hozzá egy telepítési útmutatót, így akinek minimális lövése van a LAMP-üzemeltetésről, az változatlan formában biztosan el tud indítani egy saját Zandagort szervert. A kód megértése és átírása már nehezebb falat. Dokumentáció nincs, viszont a nevek elég beszédesek (és gyarló módon magyar nyelvűek), így egy FireBuggal felszerelkezve bárki nekiállhat a megfejtésnek. ■

1

Köszi

zzrek · 2012. Dec. 21. (P), 12.12
Köszi Cucu, igazán rendes embernek látszol. Remélem, hogy további nagyszerű dolgokat fogsz összerakni, sokat, sokat. Sok sikert kívánok!
2

Gratula.

szabo.b.gabor · 2012. Dec. 21. (P), 21.29
Tényleg szép teljesítmény.

Ha adhatok tanácsot, keress valami csapatot, akik ilyesmivel foglalkoznak, akár opensource mód, és próbáld ki magad csapatban is.

Ha jól sejtem ez egy egyszemélyes történet volt.
3

Csapat

Cucu · 2012. Dec. 23. (V), 19.02
Jelenleg a célom olyan csapat/cég megtalálása, ahol meg is fizetnek, mert biztos jó dolog másokkal együtt részt venni open source projektekben, de azért az éhenhalást sem lehet túl sok éven át folytatni. :-)
4

Értékelem a szándékodat, és

virág · 2012. Dec. 24. (H), 13.22
Értékelem a szándékodat, és biztosan sok, nagyon hasznos tudás van ebben a kódban, de én az ujkuki.php fájlnál feladtam :) eszem ágában sincs fikázni a munkádat, ne érts félre, csak egy kicsit úgy éreztem magam a kód nézegetése közben, mintha visszarepültem volna a boldog PHP-s békeidőkbe :) Azt, hogy miért nem OOP, már meg sem merném kérdezni :)
5

+1. Én is értékelem a

inf · 2012. Dec. 25. (K), 22.00
+1. Én is értékelem a szándékot, de a legszörnyűbb rémálmaim tértek vissza, volt egy webshop ugyanilyen kóddal, amit refaktorálni próbáltam. Hát szinte lehetetlen, legalábbis több a munka vele, mint nulláról újraírni.

Csak egy kérdés. Nem baszogatásból, tényleg érdekel, mert annál az oldalnál is előfordult ugyanez a jelenség, és nem tudtam rájönni, hogy miért. Minden php fájl elején van cache control meg content type header. Miért írtad ki ezeket minden fájl elejére, miért nem tetted külön fájlba, vagy függvénybe. A csatlak.php-ben van egy csomó függvényed, miért nem került ez a nyilvánvalóan ismétlődő dolog egy vagy több ilyen függvénybe?

function header_no_cache(){
	header('Cache-Control: no-cache');
	header('Expires: -1');
}

function header_text_content(){
	header('Content-type: text/plain; charset=utf-8');
}

function header_html_content(){
	header('Content-type: text/html; charset=utf-8');
}
Amivel rohamosan lehetne javítani a kód biztonságán, hogy bejárod a REQUEST tömböt, és mindennek, aminek tudsz, adsz egy mysql escapet. Sokat ez sem fog segíteni, mert az alap mysql libet használod. Helyette át kellene térned PDO-ra... Ehhez viszont be kellene szórnod az egész projektet egy szövegszerkesztőbe, vagy IDE-be, és mindenhol átírni a mysql_query-t, meg az ahhoz kapcsolódó dolgokat PDO-sra, vagy PDO esetleg mysqli alapú saját libesre. Na hát ezzel el lehet tölteni 1-2 napot, mire mindenhol működőképesre megcsinálod. Ha gondolod ehhez tudok tippeket adni.

Másik hasznos dolog lenne, ha utánanéznél a tranzakció kezelésnek, mert kb 5 perc alatt kerül ezzel a kóddal inkonzisztens állapotba az adatbázisod.

Még adhatnék rengeteg tanácsot, de nem lenne sok értelme, struktúrált megoldásokról áttérni OO-ra nem egy napos dolog, és unit testek nélküli kódot hosszan refaktorálni egy olyan hiba, amit nem követ el kétszer az ember. ;-)
6

Egyetértek

Cucu · 2012. Dec. 27. (Cs), 13.24
A kódot sok szempontból én sem tartom vállalhatónak. :-) Hogy ennek ellenére publikussá tettem, annak az az oka, hogy a célom a játék fennmaradása (amire, szemben a kóddal, büszke vagyok). Abban elég biztos voltam, hogy úgyis azok viszik tovább az egészet, akik elsősorban a játékot szerették, nem pedig azok, akik programozni. Előbbieknek pedig kis túlzással mindegy a kód minősége (pontosabban őket nem riasztja el). Újraírni egészen biztos, hogy nem fogom a kódot, aki elolvassa a cikkből linkelt blogbejegyzést, annak nem kell magyaráznom, miért. :-)

A kritikákkal nagyrészt egyetértek. Éppen ezért csak két olyan dologra reagálok, amikkel nem teljesen. Pontosítok: két olyan dologra, amiknél szerintem elsősorban "webshopos" tapasztalatokból indultok ki.

Az egyik a tranzakciók. Szép dolog a konzisztencia, de ugye mindennek van ára, ennek pedig a sebesség. És van, hogy a sebesség fontosabb szempont. Nem véletlen, hogy MEMORY táblákban van az egész játék, annak minden hátrányával együtt. A gyakorlat ebben az esetben szerintem igazolta ezt a döntést, mert nem igazán volt ezzel probléma. Leszámítva egy-két jól körülhatárolható esetet és helyet, ahol végül LOCK-okkal lettek "szimulálva" a tranzakciók.

A másik az OOP. Szerintem elsősorban a strukturáltság hiányzik a kódból, nem az OOP, de ez részlet kérdés. Ami viszont nem az, hogy megint csak a konkrét rendszerből érdemes kiindulni, nem általában a webshopokból. A konkrét rendszer pedig tömve van olyan részekkel, ahol hatékonyan kell nagy tömegű egymással összefonódott objektumot kezelni. Igen, sokkal szebb lenne a kód, ha egy bolygó termelése, egy flotta mozgása, két bolygó közti kereskedelem egy-egy metódus lenne, amiket csak végighívunk az összes bolygóra, flottára, bolygó-bolygó párra, de ha mindez lecserélhető néhány jól indexelt sql-re, és a sebesség elsőrendű kérdés, akkor az ember lecseréli. Ezért mondom, hogy inkább a strukturáltság hiánya a probléma, nem pedig a "tiszta" OOP-é.

Még egyszer: ezeket nem védekezésképp írtam, és nem is azért, mert ne értenék egyet a kritikákkal. Csak ez a két dolog volt az, amihez a rendszer ismeretében hozzá tudtam tenni némi plusz szempontot.
7

Én is köszönöm, hogy

heal · 2012. Dec. 30. (V), 18.24
Én is köszönöm, hogy megosztottad a forrást, Cucu!