Én is megpróbálkoztam néhánnyal , de nagyot buktam a képeken. Ha nincsenek grafikai ötleteid, rosszul rajzolsz, vagy jól rajzóló ismerősöd van, akkor fújhatod az egészet.
Én azt mondom, hogy majd szólnak.
Ez nem a te dolgod, nem a saját szervered, ha "sokat fogyasztasz", akkor majd szólnak és 1. elküldenek, 2. többlet pénzért biztosítanak jobb megoldást (vps mondjuk).
Természetesen neked mindent meg kell tenni, hogy a lehető legkevesebb erőforrást használjad, hisz csak így maradhatsz az olcsó kategóriában.
Körülbelül hány oldalmegjelenítés vagy mekkora adatforgalom a határ, amit már nem szívlelnek meg az ilyen tárhelyeken?
Szolgáltatója válogatja.
Pl. úgy is tehet a szolgáltatód, hogy kevés az ügyfele, és monitorozza az oldal terhelést, ha látja, hogy az egyik valamelyest vagy akár kirívóan valamiből (Adatbázis, vagy kérések száma, kérések száma/load) többet igényel, fel is szólíthat, hogy vegyél nagyobb csomagot (tehát fizess többet), h neki is megérje.
Vagy ha sok az ügyfele szimplán elküld.
Ha meg jó indulatú, akkor némi pénzért külön rak (ritka)...
Körülbelül hány oldalmegjelenítés vagy mekkora adatforgalom a határ
...de ezt körülbelülire sem tudom megmondani, a szolgáltatót kell erről megkérdezni. Ugye persze a fent leírtak mind függenek attól, hogy van-e szerződés, mi áll benne, mekkora a szolgáltató cég (már ha cég ) és atöbbi.
Azt te is fogod érzékelni, hogyha lassul az oldal.
De arra figyelni kell ám, hogy az oldal adatbázisa azért optimális legyen, ugyan így a kódolás is. Mert ez is befolyásolhatja a szolgáltató hozzáállását (persze ez nem a multikra jellemzők, ők nagy terheléskor inkább új gépet állítanak be, mint valamit állítsanak a meglévőeken, hogy gyorsabb legyen. A kevesebb munkaóra miatt gonoldolom... :) )
Ha meg egy bérelt tárhelyen futtatod (osztott hoszting), akkor az 1000-2000 felhasználónál már el is küldhetnek.
Körülbelül hány oldalmegjelenítés vagy mekkora adatforgalom a határ, amit már nem szívlelnek meg az ilyen tárhelyeken? Ez az online játék jelenleg ilyen körülmények közt működik, igaz, nekünk a célpiacunk kisebb, mint egy átlagos játéknak (a különleges téma és az egyszerűbb felépítés, kivitelezés miatt kevesebben regisztrálnak be, mint egy átlagos háborús stratégiai játékba.)
ha van pár masszív bullshit akkor kérlek jelezd, mert abból is lehet leszűrni dolgokat (persze azért ne egyél meg mindenkit :D). Nah meg mint mondtam semmi extra flash megoldás nincs nálam ... csak a gombok, az nem csilli-villi megoldás csak sima gomb. Szóval ez lehet js is csak flashban készítettem el így egyelőre ebben van. nálam firefox van fenn és ott nincs gond.
Viszont cserébe lehet, hogy egy új böngészőt telepíthetsz, ha játszani akarsz vele :D
ez nem igaz.
Van egy jópár js lib ami megoldja ezeket a gondokat.
a js nem minden böngészőre az igazi, viszont shockwawe általában kiegészítésként megjelenik szinte minden böngészőben...
Érdekes meglátás.
JS alapból van, és mind ez bekapcsolva a böngészőkben. Flash nem, telepíteni kell.
Gyengébb gépeken a flashtől akár ki is fagyhat a böngésző. JS-től nem fagy, persze ha nincs csilibili effekttel össze pakolva.
Sajnos fejlesztettem már olyan oldalt, ahol addig kiszedtem a flash fejlécet, mert egyszerűen nem bírta a gépem.
Még egy érv:
Firefox plugin: flash blocker
"Javascript blocker" miért is nincs?
köszönöm a választ. Mellesleg a flash alatt a buttonokat gondoltam egyelőre. szóval azért nem viszem túlzásba, ráadásul a js nem minden böngészőre az igazi, viszont shockwawe általában kiegészítésként megjelenik szinte minden böngészőben... Nem tartom olyan rossz megoldásnak a flash dolgot.
Ha már flash-t is raksz bele, akkor egy játékossal kevesebb fog játszani vele. (gondolok itt magamra )
Mivel a flash nem megoldás, hanem "probléma" így nem szerencsés.
csak szeretném konkrétabban látni a php terhelhetőségét.
Nem a php terhelhetőségével van a baj, hanem a szerverével
Ha jól megvan írva nem lehet baj.
Esetleg érdekes lehet a statikus és a dinamikus tartalom külön helyezése. (egyszerű webszervert a statikus tartalomnak, míg a dinamikusnak egy nehézsúlyú szerver -és nem apache )
Adatbázisról nem beszélve, nagy terhelésnél célszerűbb egy másik szervergépre rakni az adatbázist (aminek nem feltétlenül szerencsés a mysql, vagy nagyon kibelezve -lighweight). És persze ezek a szerver gépeket úgy érdemes telepíteni, hogy ezekre legyen optimalizálva.
Meg akkor még esetleg valamilyen gyorsítótárazás memóriába, hogy az adatbázis szerver tényleg csak akkor legyen használva, ha menteni kell. (pl memcached)
Ha meg egy bérelt tárhelyen futtatod (osztott hoszting), akkor az 1000-2000 felhasználónál már el is küldhetnek.
Rengeteg témát olvasgattam már, de csak az a jó ha rákérdezz az ember olyanoktól akik esetleg jobban tudják a választ mint jómagam :D
Szóval (új témát nem akartam nyitni hiszen hasonló a dolog mint itt) kérdésem ez lenne:
Kivitelezhető-e egy olyan játék mely kb 1000-4000 usert (hirtelen tipp a kézzelfoghatóság miatt) kezel (mysql) és rpg alapú. Azaz van benne karakterépítés, céh (klán) rendszer, kalandozás, stb... Mindezt php / flash / as felépítésben szeretném. Nem a programozásban kérnék segítséget, csak szeretném konkrétabban látni a php terhelhetőségét. A játék készítés alatt van, de remélem hogy nem a php fogja elnémítani a projektet. Érdekelne hogy mire vigyázzak, azaz mit kerüljek el, hogy ne amortizáljam le a mysql-t.
Kiszámolja, hogy az adott körülmények közt milyen gyakran kapsz nyersanyagot, és eszerint javascripttel frissíti. Akkor van szükség lekérni a nyersanyag-adatokat, ha támadnak; tehát nem kell tizedmásodpercenként frissíteni az adatbázist.
Pedig de, hisz ha valaki nem is játszik, akkor minek számolgassuk?
Világos. Minek? Közeben felépül egy nyersi mező + 1 szintre már megváltozik a termelés/óra ezurán mondjuk 6 an megtámadják a 6. online akkor kiszámolgatod, hogy hogy a felépülésig mennyi nyersi termelődött aztán az öt támadás közt mennyit vittek el a támadások közt mennyi nyersanyag termelődött de közben kettőben volt katapult is ami levitt az adott nyersanyag termelő mezőkből pár szintet.....
Azért ennél komplexebb a dolog, például tegyük fel, hogy van egy toplista, ami a játékos tulajdonságai, vagy azok egy része alapján számolt pontok alapján rendeződik. Ez esetben, ha a toplistát legalább X időnként frissíteni akarod, kénytelen vagy az adatok (legalább egy részét) periodikusan kiszámolni.
Arról nem is beszélve, hogy ha esetleg ez a lista, vagy valami hasonló elven működő dolog funkcionálisan is része a játéknak, és számolni is kell vele. (mint mondjuk több kategóriában a legjobbhoz viszonyítva / az eloszlás szerint kapják a játékosook az egységeket)
szerk: Max. úgy tudnám elképzelni, hogy az adott játékost érintő bármilyen változás bekövetkeztekor kiszámolják az eltelt idő alatti nyersanyag növekedést vagy csökkenést.
Ezt nem így szokás megoldani. Rengeteg dolog van, amit ráér akkor kiszámolni a szerver, amikor egy játékos olyan oldalt tölt be, amelynek szüksége van az adat aktuális értékére.
Tapasztalatból beszélsz vagy csak úgy Te így képzeled el?
A gondolatmeneted szerintem itt hibádzik:
"a szerver valós időben pörgeti az összes játékos módosuló értékeit."
Ezt nem így szokás megoldani. Rengeteg dolog van, amit ráér akkor kiszámolni a szerver, amikor egy játékos olyan oldalt tölt be, amelynek szüksége van az adat aktuális értékére.
Vegyük például a nyersanyagokat. Ha pl. másodpercenként 3 fát termelsz, akkor sem kell a szervernek növelni a fa értékedet 3-mal minden egyes másodpercben. Timestamp-ek használatával nagyon sokat lehet spórolni.
Amikor lekéred pl. a főoldalt, ahol látszik az összes nyersanyagod aktuális értéke, akkor a szerver megnézi hogy mikor kérted le legutóbb, akkor mennyi volt az értéke, és hogy másodpercenként mennyivel növekszik. Ez a három adat van az adatbázisban, és ezekből ki lehet számolni egy egyszerű szorzással és egy összeadással az aktuális értéket.
Persze vannak esetek, amikor ténylegesen futtatni kell időzített szkripteket (vagy akár egy C++-ban készült segédprogramot a háttérben). De az általában felejtős, hogy egyszerre módosítunk értékeket az összes játékosnál.