Stratégiai játék JavaScript-tel

Internet: PHP, CGI, stb.

Üdv!

Napokban volt szerencsém egy térinformatika előadást végigülni, és ennek kapcsán van egy ötletem. Felmerült bennem a kérdés, hogy vajon lehetséges-e egy online stratégiai játék megvalósítása csupán javascript-el, mindenféle flash és java cuccok nélkül. Egy teljesen interaktív valamire gondoltam, mint annak idején pl a Warcraft volt. Nem is annyira az a kérdés, hogy megvalósítható-e, mert szerintem biztosan, hanem hogy mennyire érdemes... Maga a JS technológia sebessége szab határt vagy csak és kizárólag a sávszélesség? Az más kérdés, hogy milyen szerver kell mögé illetve hogy marha sok munka megírni egy ilyesmit... de mondjuk egy diplomamunkának nem utolsó :)

karika200

  • 2378 megtekintés

( tomaza | 2010. 04. 18., v – 16:37 )

szerintem ha érthetően fel tudod tenni a kérdést, meg is válaszoltad ;)

mit akarsz? a js a megjelenítésért feleljen, mert a stratégia játéknak látványosnak kell lennie? vagy lényegében egy letöltött fájl legyen offline játékkal js-mest.inttel? vagy multiplayer legyen és a szerver csak egyik játékostól küldi a lépést a másiknak?

de hogy egy beleképzelt kérdésre válaszoljak:
- a megjelenítés mindenféleképpen akár css-vel (is) tökéletes,
- kommunikáció szerverrel, többi játékossal: nagyon jó js frameworkok léteznek, most had ne soroljam fel
- a.i. része pedig, hát chromeban biztos értelmes munkával is megvalósítható, elméletben egy ie is képes ma már rá hisz anno a civ 486-on (386?) tökéletesen futott

Nos, a JS-t csak a megjelenítés részre értettem. A szerver közvetítene a kliensek között, hogy ki mit csinált és társai. AI-val annyira nem lesz baj, mert leginkább itt csak a játékosok játszanának egymással ;] Azért olvasgatok még a témában, aztán ha sok időm lesz, lehet neki ülök... Köszönöm a válaszokat!

( Yorirou | 2010. 04. 18., v – 16:40 )

Igen, főleg az új HTML 5-ös techológiákat felhasználva, nagyon elegánsan és könnyedén lehet ilyet csinálni.
Lásd a blogpostom a HTML 5 újdonságairól: http://hup.hu/node/85933

( Aadaam v | 2010. 04. 18., v – 22:35 )

A JS technologia sebessege nem veszes, attol fugg, mit ertesz alatta. Maguk a JIT runtime-ok 2-2.5 sebessegkulonbseggel rendelkeznek a nativ / statikus JIT (java, .net) kodokhoz kepest, egy Quake 2 siman elfut egy mai gepen nightly build bongeszoben, ahogy azt a google demonstralta:

http://code.google.com/p/quake2-gwt-port/

Ami a JS-ben para, az a fejlecek utazasa minden keresnel, bar ezt megoldja neked a websockets, igy ezzel is rendben vagyunk.

Grafikailag a WebGL meg nem tart messze, a canvas azt tudja, amit a freeciv bemutat, nem tul gyors rajzolo, 1-2 sprite animalasahoz boven eleg, de 3d-t emulalni rajt lassu.

Egy korlatos technologiai platformon - WebSockets + WebGL tamogatas, mondjuk WebKit nightly bongeszok - mukodo jatek megiras azt gondolom, realis celkituzes; egy minden bongeszoben, hagyomanyos (HTTP, Canvas2D) mukodo jatekkal ma meg talan tul nagy szopasaid lennenek egy egyszemelyes diplomamunkahoz, bar egy turn-based izometrikus jatek megirasa mar lehetseges bennuk.

( asch v | 2010. 04. 19., h – 00:06 )

Szerintem lehetséges, de ezzel beállnál a mazochisták táborába, akik JavaScriptre programoznak.

Elterjedtebbet, vagy rosszabbat nehéz lenne mondani.

Mivel diplomamunka, nyugodtan fejleszthetne QT-re, OpenGL-re, WPF-re, Androidra vagy IPhone-ra is. Szeritnem ezek didaktikailag sokkal megfelelőbbek egy tanuló számára. Egy gondolatot megér, ennyit próbáltam a hozzászólásommal mondani.

Mondok en neked rosszabbat: intercal.

A javascript a vilag legfelreertettebb programnyelve, ahogy Crockford mondta. Gyakorlatilag konyv helyett az o videojat osztogatjuk: http://video.yahoo.com/watch/111593/1710507 (a 4 resz osszesen 1 ora).

(Ha konyvet kell adni, tole a Good Parts, vagy Resig-tol a Pro Javascript Techniques)

Mivel az egyetem a valo eletre keszit fel, a Qt-t kevesbe javaslom.

Mint emlitettem fent, az MIT-n egy ennel sokkal nehezebben olvashato valtozataval kezeltek tavalyig - az elsoeveseket. Diplomamunkanak tokeletesen jo nyelv, szerintem.

Nem tudom ki ez a fickó aki emlegetsz, de nem kellene minden narkósnak elhinni amit mond, főleg akkor ha más a valóság.
Majd ha minden böngésző ugyanúgy és ugyanazt a javascript verziót fogja támogatni vagy cserélhetem a javascript értelmezőt egy adott bőngésző alatt, akkor van értelme programozási nyelvnek nevezni a javascriptet, addig egy nagy rakás szar, amit azért kell használni, mert nincs más.
Amúgy meg az egész javascript egy közröhej..
.. 2010-ben még nem tud több szálat használni..
.. állítólag objektumorientált, gyakorlatilag meg vért pisál az ember ha használni akarja ezt benne..
.. stb. tudnék ezer példát mondani..
Az, hogy a legtöbb javascript-es program egy bug és memory leak halom elég jól mutatja mennyire jó nyelv.

Ja, te is egy ignorans ember vagy latom :)

2010: Szalakat workereknek (worker thread, web worker) hivjak
gyakorlatilag is objektumorientalt, viszont prototipusos oroklodesu (de jol lehet vele emulalni klasszikust is)
Az IE6 (DOM!) memory leakjere mar evek ota van workaround, ill. sokezer unittest reven a frameworkok nem bugzanak sokat.
Kivetel nelkul minden bongeszo az ES3 verziot implementalja, btw eleg fullosan, ideertve az IE6-ot is.

Amirol Te beszelsz, az a DOM, ami a bongeszo API. Ez egyfelol egy total mas teszta (ehhez a jatekhoz nagyon pici resze kell, a Canvas API egy kulon jatekszer), masfelol a bongeszok termeszetuknel fogva kulonboznek a DOM implementaciojukban (Gecko/Trident/WebKit). De kuzdunk, kuzdunk, az IE9 mar allitolag jo lesz, a Gecko meg a WebKit eddig se voltak annyira szarok.

Az a narkos akit emlegettem, pedig a Yahoo vezeto JS agytrosztje (yahoo mail, remlik?), aki konkretan az uj verzio (ECMAScript 5, 2009 decembereben jelent meg, igy meg nem mindenki implementalta) szellemi atyja. Tudom, A Yahoo nem google, de a YUI-ra jobb ranezni mint a closure-re.

Raadasul ezekrol a temakrol mind beszel a fenti videoban, ha megertened oket, talan nem anyaznad..

If you please...

Öcsisajt, minden támogatja a workereket?
Hol van az elfogadott szabvány? Miről beszélsz?

A memory leak javascript beépített "haszon állata", ami a "this" futás közbeni kiértékeléséből adódik
és egy esemény hosszá rendelésekor követnek el sokan.. néha nincs is más mód.. ha példát akarsz, akkor
nézd meg a jQeury-s pluginokat.. szinte mind egy bug és memory leak halom, akárcsak a jQuery.

Rémlik ki az a Yahoo.. rémlik ki az a w3c, hasonló köcsög banda, akinek köszönhetjük a "csodálatos" html-t,
css-et és még pár dolgot, amikben 2010-ben olyan dolok nincs benne, amit sok program már a 90-esek években alap szinten tudott.

Anyázok, és tölem ilyen köcsögökkel elmehetsz a búsba.. mikor 2010-ben még egy sima trim() függvény kézzel kell
a javascript String-jéhez hozzátoldanom, mert az ilyen és hasonló buzik és akik kitalálták a javascriptet csak "pár"
valóban fontos dologra nem gondoltam anno!

Miutan ez egy prototipusos nyelv, nem ugy viselkedik a this, mint a klasszikus nyelvekkel. A megoldas: closure.

Milyen alkalmazast irtal, hogy thread kellett egyebkent?

WebWorkerek vannak: Safari, Chrome, Firefox, IE-ben Gears pluginnel, bar igernek IE9-re sokmindent megint.

Az ECMAScript 5 szabvany megtalalhato a kovetkezo cimen: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.p…

Regebbi valtozat: http://www.mozilla.org/js/language/E262-3.pdf

A trim nincs az ES3-ban, de String.prototype.trim = function() { return this.replace(/^\s\s*/, '').replace(/\s\s*$/, '');} es maris van.

ES5-ben egyebkent van: https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_O…

Az meg, hogy a jQuery pluginek memory leakelnek... hat ... user generated content :) Maga a jQuery, Resig annyira nem hulye, nem leakel.

Ha leaket talalsz, itt jelenthetsz bugot a jQueryhez: http://dev.jquery.com/report
Itt a WebKitekhez: https://bugs.webkit.org/
Itt a Firefoxhoz: https://bugzilla.mozilla.org/

Bonusz! IE: https://connect.microsoft.com/site/sitehome.aspx?SiteID=136 (sajnos ok fokent az aktualis verzioval foglalkoznak)

A kozhiedelemmel ellentetben a jol bejelentett bugok ki szoktak javulni (bar IE-rol nincs tapasztalatom, a masik 3-ban igy van)

( arth2o | 2010. 04. 20., k – 06:10 )

Szerintem csak JavaScripttel nem igazán tudsz megvalósítani egy olyan játékot, ahol pl.: bejelentkezés van, meg adatbázisban kell tárolnod az állapotokat.

A megjelenítési részéhez illetve ahhoz, hogy a terhelés nagy részét klienes oldalra nyomd, arra tökéletes. És ne feledkezzünk el a 3D-s, SVG és egyéb hasznos dologról amit kezelni tudsz vele.

Határok: Hegyeshalom :)
Különböző böngészőkben, más-más teljesítmény (csináld meg Firefoxban és próbáld ki IE-ben)
A napokban egy térképes oldalhoz kellet megjelenítenem 3000 pontot.. Firefoxban vidáman ment, de IE-ben (7,8) csak ~150 pontig volt élvezhető (Több mint 3000 Pont megjelenítése Google Maps-on). Persze itt volt egyéb megjelenítési igény is (tooltip, adatok a buborékban stb..).

A klienes oldal mennyire combos géppel rendelkezik.
A szerver amiről az adatot várod (Ajax kérés), mennyire terhelt.
Milyen adatbázist használsz szerver oldalon.

Sok mindentől függ egy JS fejlesztés, és nagyon kell ismerni az optimalizációs kérdéseket.

arth2o: http://keszit.es

node.js, nitro js ? :)

Szerveroldali javascript mar a 90-es evekben is volt, ma ismet kezdi reneszanszat elni (a JIT-compilerek miatt)

Az IE tombkezelese valoban tragikus (konkretan a tomboket lancolt listakent abrazolja, ezert 3000 ponton vegigmenni negyzetes), de ezt igerik, hogy a 9-esben vegre kijavitjak.

Egyebkent ilyenkor inkabb clusterezz, esetleg KML eseten hasznalj zonakat - ha a wikipedia cikkeket / panoramio fotokat akarnad megjeleniteni, akkor is gyanus lenne, megis jol skalazodik.

Én nem a szerver oldalai javascript-re gondoltam. De hogy öszinte legyek a kérdésnél fel sem merült bennem a szerver oldali JS (úgy már más tészta :).

A térképes dolognak az lett a vége, amit írtál. Kisebb területekre lett bontva és úgy kb 200-300 pont esik egy-egy régióra.

arth2o: http://keszit.es