Körökre osztott stratégiai játék, http kapcsolat
2018-08-24T08:37:43+02:00
2018-08-27T08:13:18+02:00
2022-07-21T03:45:22+02:00
  • Köszönöm az észrevételeket, de asszem kezdetben maradok a php/sql kombónál. Legrosszabb esetben lesz egy valós példám arra, hogy miért nem csinálunk ilyet. :)
    Mutasd a teljes hozzászólást!
  • Azért érdemes emlékezni rá, hogy a készletnyilvántartó meg a játék eléggé mást csinálnak.
    Mutasd a teljes hozzászólást!
  • Kérdéses, hogy hány file-t hajítanál rá egyszerre a szerverre "napi folyamat" címén. Ha túl sokat ráhajigálsz egyszerre egy kávédarálóra, le tud éppen halni. Jobb lenne valami időben elosztottabb terhelés. Az a nagyobbik baj, nem az átlagos terhelés. Az átlagos terhelésed egyébként is annyira pocsék scriptes szerver esetén, hogy nyugodtan elfelejtheted a hatékonysági szorzókat - talán előzőleg már említettem, hogy mennyire. Ami a nagyobbik problémád lesz, hogy sose kapjon egyszerre akkora rúgást a szerver, amitől csak hebeg-habog percekig, és addig a kliensek felé se kép se hang.

    Anno csináltam egy mérést egy ingyenes kategóriájú webszerveren. Sql query-ket futtattam, több ezret. Valami átlagosan 15-öt tudott megcsinálni másodpercenként (memória táblákba kb 300-at). Scriptes környezetet mellé pakoltam, ami még a processzort is fogta, kb 9-et tudott úgy megcsinálni másodpercenként (memóriatáblákba valami 40-et). Nem tudom, hány sql query tartozna a batch file-ok darabjához, de gondolom cpu-t is ennél, meg db query-ket is futtatnál. Csinálj egy tesztet csak egy batch file feldolgozáshoz, és úgy írd meg az alapokat, hogy számolni tudd a végrehajtott sql query-ket is. Akkor lesz arról valami képed, mi történik majd, ha az összes állományt ráhajigálod. Minden kötegelt folyamat, ami 5 másodpercnél tovább fogja a szervert, már kényelmetlenség a gyakorlatban. Pláne, hogy elővigyázatlan tervezésnél nem csak 5 másodpercig fogod majd lekötni a szervert, hanem akár 5 percnél is tovább. Figyelj oda, mit tervezel.
    Mutasd a teljes hozzászólást!
  • Matematikailag/algoritmikusan nyilván kb. egyenértékű a két megoldás, viszont én élek a feltételezéssel, hogy a gyakorlatban gyorsabb/hatékonyabb, ha egyben dolgozzuk fel az összes lépést (a szkriptfeldolgozó elindítása, objektumok példányosítása, adatbázishoz való kapcsolódás, stb.). Persze ez csak egy megérzés, simán lehet, hogy tévedek.
    Mutasd a teljes hozzászólást!
  • Kulcsszavaik valának: Stateful vagy stateless!
    Mutasd a teljes hozzászólást!
  • Tehát te kliensen végig játszod a játékot, majd elküldöd a szervernek a lépéseket, aki újra végig játssza azt, hogy validálja és kiértékelje?
    Ennyi erővel logikusabb lenne már akkor kapásból a szerven játszani, nem látom hol spórolnál meg bármilyen terhelést is, max némi adatforgalmat spórolnál meg.
    Mutasd a teljes hozzászólást!
  • Ezekben mondjuk igazad van, lehet kezdeni az egyszerűbb/kézenfekvőbb megoldással, aztán menet közben váltani - persze, csak ha van rá igény.
    Másrészt egy jól megcsinált algoritmus elég átlátható, egy már elkészült kódot át lehet írni más nyelvre, mondjuk PHP-ról C++-ra.
    Lényeg a lényeg, akkor nem olyan elvetemült ötlet szkripteket használni, később esetleg még lehet változtatni rajta.
    Mutasd a teljes hozzászólást!
  • egy körökre osztott játék esetén van-e érdemi különbség a natív és a szkriptes megoldás teljesítménye között?

    Nincs. Azt írod, hogy a szerver csupán validál egy beküldött lépéssorozatot, szóval nem játszik, csak lejátszik. Ehhez minimális számítási teljesítmény szükséges csupán, nem érheti meg "szenvedős" nyelvvel kezdeni.
    Mutasd a teljes hozzászólást!
  • Hogy ne lenne? Kb 50x-es. Mármint minimum.

    Amíg csak te játszol, meg a haverok, addig egy 10k huf-os tesco budget szerver (valami régi 32 bites máshonnét ingyen elvihető cucc, aminek a postai szállítása volt az a 10k huf) is elbírja scriptes alapon. Az elején írd php-ban. Ha másra nem, gyakorlásra biztosan jó lesz, és hamarabb szembesülsz a koncepcionális buktatókkal a játékélményt illetően.

    Majd amikor már közhírré tétetett a nagy mű, meg az üzleti elgondolás is működik, és elkezd emelkedni a szerver üzemeltetési költséged, mert millióan döngetik, majd akkor jön az, hogy nekiállni az első verzió helyére egy második verziót írni, és ott szerver meg kliens oldal is átgondoltabb lehet. Addig teljesen mindegy.

    A szuper ötletek egy ezrelékénél is kevesebb arány éli meg azt a kort, hogy olyan problémája legyen, amin éppen agyalsz. Amelyik meg is éli, jellemzően nem az alkotó első ötlete, hanem valahol a 40-edik. Nagyjából az a statisztika. És akkor még hozzáértő népekről beszélünk. Azt mindenki alábecsüli az elején, hogy mennyire nehéz ténylegesen betörni valami új cuccal a piacra.

    Szóval kár görcsölni. Csak lazán.
    Mutasd a teljes hozzászólást!
  • Természetesen a kliens és szerver oldalt is én írnám meg. A kérdés leginkább arra vonatkozott (amit asszem meg is válaszoltál), hogy egy körökre osztott játék esetén van-e érdemi különbség a natív és a szkriptes megoldás teljesítménye között.
    Mutasd a teljes hozzászólást!
  • Batch fájl alatt azt értem, hogy a játék menet közben eltárolja a lépéseket, majd a végén egyben küldi el a szervernek, így csökkentve a terhelést.
    Vagy ha arra gondolsz, hogy miért nem csak a pontozást küldi el: egyrészt a csalásokat megelőzendő, másrészt másnap vissza lehetne nézni az előző napi legjobb megoldást.
    Mutasd a teljes hozzászólást!
  • Nem elég az infó ahhoz, hogy ezt eldöntsük.
    Hány emberre kell tervezni? Ha max a haverokkal számolunk akkor kb. mind1 hogyan oldod meg.
    Mondjuk ha naponta csak egyszer küld akkor ígyis-úgyis mind1, annyi embert nem tudnál összeszedni ahol már gondot okozna.

    Nem is értem amúgy mit akarsz? Valami böngészős játékot? Vagy saját klienseset? Utóbbi esetben hülyeség lenne php-t írni csak erre.
    Meg miért a batch fájl? :D
    Mutasd a teljes hozzászólást!
  • A szolgáltatók szerver hostingot adnak "mind egyforma" szolgáltatásként. A többi már egyedi megállapodás, és az is lehet, hogy nem létezik, amit keresnél - magadnak kell nullából felépítened. Használhatsz bináris szerver oldalt vagy scripteset is. Ha nem kell nagy teljesítményre, igazán nem oszt nem szoroz.

    Vannak framework-ök különféle játékokra, temérdek sok alap szolgáltatással, de azok akkor is csak picike mozaikok, amikből külön programozói munka az appot összerakni. Hogy azt bárki másnak akár csak esélye legyen helyetted megcsinálni, ahhoz nagyon pontosan kellene dokumentálnod a felhasználói élményt. Annyira részletesen, hogy igazából előzetes gyakorlás gyanánt neked is kellene egy kicsike programozási gyakorlat. Legalább hogy egészen eltévedve ne legyél a lehetőségekről.
    Mutasd a teljes hozzászólást!
  • Hali!

    Próbáld meg felismerni, hogy mi a különbség a Tudástár (konkrét kérdések, megoldandó problémák színtere – ahol tévesen nyitottad ezt a témát) és a Társalgó (kötetlen beszélgetések, ötletelések, eszmecserék, viták, vélemény-, javaslat- és ajánlat-kérések helyszíne – ahol nyitnod kellett volna ezt a témát és ahova most áthelyeztem) között, és a jövőben új téma nyitásánál alkalmazd is ezt az ismeretet. Köszönöm.

    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Egy körökre osztott stratégiai játékon gondolkodom, ami egy http szerveren keresztül ad "napi kihívásokat"(daily challenge). Az eredményeket egy batch fájlban küldené vissza, amit PHP-ben dolgoznék fel. Szerintetek életképes ez a megoldás, vagy inkább natív kódban kéne szerveroldalon feldolgozni a bejövő adatokat? Ha igen, tudtok szolgáltatót, ahol ez megvalósítható?
    Mutasd a teljes hozzászólást!
abcd