Hozzon létre egy játék, játék tervezők, játék motorok
Kezdők útmutató az alkotók MMORPG játék.
Szükséges ismeretek:
1. ismerete legalább egy programozási nyelv. Ki között a fejlesztők a legnépszerűbb nyelv C ++, mert annak előnyeit a hatékonyság és a gyorsaság. Visual Basic, Java, C # is használható ebben a minőségében.
2. Szükséges, hogy megismerjék a grafikus könyvtár. A népszerű választás SDL, OpenGL és a DirectX / Direct3D.
3. Döntés a hálózati könyvtár. Kiválaszthatja WinSock, SDL_net vagy DirectPlay.
4. Van tapasztalat játékprogramozásból. Például, hogy van elképzelése, hogy mi: az esemény sorban, többszálú, fejlesztése felhasználói felület (GUI), stb
Nagyon ajánlott, hogy tudja:
1. A kliens-szerver kommunikáció építészeti és építési az ilyen rendszerek.
2. létrehozása cross-platform alkalmazásokat. Elég talán szeretne létrehozni a játékot, és főleg az ügyfél úgy, hogy futhat a különböző operációs rendszereken. Mert ezt a funkciót, azt javasoljuk SDL, OpenGL és SDL_net.
3. kidolgozása Web (Internet). Erre azért van szükség, ha azt szeretné, hogy az érdekelt személyek, hogy megtekinthesse a statisztikát a játékosok, a szerver információt, vagy bármilyen más információ a weboldalon keresztül.
4. Protection és a menedzsment. Nem akarom, hogy valaki feltörte a szervert?
5. csapatmunka, team menedzsment. Be kell, hogy legyen egy csapat, amely képes lesz arra, hogy sikeresen kezelni.
2. lépés: Hozzon létre egy vázlattal
adatbázisok
előnyei:
• könnyen hozzá vagy módosítsa a mezőt.
• megváltoztatása statisztikát a játékos (nem a játék) sokkal könnyebb
• Lehet kapni különböző statisztikákat gyorsan és hatékonyan az SQL lekérdezések
• Nem kell létrehozni I / O művelet egy fájl, adatbázis, mindez érted
• Könnyen frissíteni és helyreállítani
hátrányai:
• A könnyű hibázni. Például lekérdezésével elfelejtett „hol” nyilatkozatot. Ez katasztrofális következményekkel járhat, különösen akkor, ha csak a régi (vagy egyáltalán nem) mentést
• Munkavégzés az adatbázis lassabb lehet, mint a munka a fájl lejátszó közvetlenül. Lehet veszíteni néhány milliszekundum, amikor megkapja az adatokat, különösen, ha nagy számú játékos ugyanabban az időben, belépés / kilépés a játékból
• Be kell írni kiegészítő kód konvertálni az adatokat / az adatbázisból
• Szükséges tapasztalat adatbázisok és az SQL nyelv lekérdezések. A könyvtárak is szükség van a szervezet interakció az alkalmazás és az adatbázis
• Ha valamilyen okból az adatbázis fájlok megsérültek, akkor így jártál. Akkor elveszíti a szereplők (főleg, ha nincs friss backup)
fájlok
előnyei:
• Nagyon gyors hozzáférés (írás / olvasás)
• Egyszerű végrehajtási
• Nincs szükség további könyvtárak
• Nincs kapcsolat az adatbázis szerver. Ezért nem kell aggódnia, frissítések és javítások az adatbázis
hátrányai:
• Meg lehet elég kihívást, hogy új mezőket, ha előzőleg nem gondol a méret és a fájl szerkezetét
• Nem lehet egy kérés egy nagy számú játékos (ez a probléma is megoldható egy programot, amely minden este hozzáteszi fontos adatokat az adatbázis szerver)
• Be kell írni speciális kódot, hogy frissítése / állapotának ellenőrzésére játékos
• Kissé nehéz elvégezni frissítési műveletek és helyreállítási
Most, hogy úgy döntött, hogyan kell tárolni információt a karakterek, el kell dönteni, hogy milyen hálózati protokoll fog használni a kliens-szerver kommunikáció: TCP vagy UDP? TCP ismert lassabb, de pontosabb, akkor nagyobb sávszélességet igényel. A gyakorlatban nem vettem észre semmilyen problémát, ha a TCP. Ha elegendő sávszélesség, TCP - ez egy jó választás, legalábbis a kezdet. UDP lehet nagyon kellemetlen, főleg kezdőknek. Ne feledje, hogy a kezdeti tesztek a motor és a játék lesz a helyi hálózaton, hogy minden csomag érkezik meg rendeltetési helyükre ugyanabban a sorrendben, mint hogy elment. De ez nem garantálható, ha az internet használata, azaz a egy valós környezetben. Abban az időben, a megszokott módon a csomagok érkeznek egy adott sorrendben, egy részük elveszhet, és ez egy állandó probléma az interneten. Persze, lehet fejleszteni a protokoll, hogy a kliens / szerver elvesztett csomagok. De ez egy nehéz folyamat, ami nem ajánlott kezdőknek.
3. lépés: Develop belső protokoll átvitelére a játék adatait
Ez a feladat egyszerűnek tűnik, de a lényeg, hogy nem. Nem lehet csak küldeni egy string, egy szimbólum a Terminal Zero '# 92; 0'. Szükséged lesz egy közös protokollt képes továbbítani mind húrok és bináris adatokat. Oktalan ebben az esetben használja a 0 (vagy bármely egyéb), mint terminátor elem, mert a terminátor része lehet az adatfolyamot küld. Továbbá, ha el szeretné küldeni 20 byte, majd további 20 bájt, valószínűleg a szerver nem kap egy csomag 20 byte, majd egy másik csomagot a többi 20 byte. Ehelyett kap 40 bájt egyszerre, mert ez csökkenti a terhelést a hálózat miatt a csomag fejléce (küldött egy, nem két cím). Hasonlóképpen, akkor küldjön egy csomag mérete 1 kb, de a szerver kap két kisebb csomagot. Így meg kell tudni, hogy hol a csomag kezdődik és hol végződik. A projekt Eternal Lands használhatja a következő módszert:
• Offset 0: 1 byte, amely meghatározza a parancsot továbbított.
• 1 Offset 2 bájt, a hossza a továbbított adatokat.
• Offset 3: változó hosszúságú üzenet testet.
Ennek a módszernek az az előnye, hogy az adatok továbbítása, illetve egy bizonyos szintet. Hátrány - néhány csapat már fix, előre ismert a méret, így a forgalom vész kárba. Végül is áttértek a hibrid megoldásokat.
A következő kérdés az, hogy dönteni - milyen modell használható a szerver, „nem-blokkoló foglalatok, egyszálú alkalmazás” vagy „blokkolt konnektorok, multi-threading”. Mindkét módszer (multi- és egyszálú) megvannak az előnyei és hátrányai.
többszálú:
1. A pontosabb választ a szerver, amikor a játékosok kell sok időt (például olvasás adatbázisból), hogy fog futni a saját téma, hogy ne érjen a többi játékos.
2. Nagyon nehéz a hibakeresés és megvalósítani: Meg kell, hogy hozzon létre egy csomó szinkronizálás, és a legkisebb félrelépés vezethet súlyos következményekkel (szerver összeomlik, átfedő objektumok, stb)
egyszeri beutazásra:
1. Sokkal könnyebb végrehajtani, majd hibakeresés
2. Egy nagyobb válaszidő
A cégem, ezért úgy döntöttünk, egy szálon alkalmazás, mert egyszerűen nem volt elég erőforrás, hogy megbirkózzanak a létrehozása többszálas megoldásokat.
4. lépés: Ügyfél
1. Nem lehet, hogy egy MMORPG, hogy vesz egy nagy cég.
Nem értek egyet ezzel. Míg a teremtés játékok World of Warcraft, Ever Quest 2, Asheron Call 2, Lineage 2, a másik pedig egy lehetetlen feladat, egy kis független fejlesztő csapatok, ami a szerény játék elég lehet, és attól csak a szintet a tapasztalat, a motiváció, és a szabad idő. Szükséged lesz legalább 1000 órányi műsort, hogy hozzon létre egy egyszerű technikai demo, és valószínűleg 10-15 ezer órát is igénybe vehet létre a szerver és a kliens. De ahogy a feje a csapatnak meg kell majd nem sokkal több, mint a programozás. Tartsa a csapat együtt, a konfliktusok megoldása érdekében, hogy nyilvános nyilatkozatokat (PR), műszaki támogatás, szerver konfiguráció, problémák blokkoló játékos, „brainstorming”, stb elkíséri egész idő alatt. Ezek gond zasosut meg teljesen. A legvalószínűbb, akkor is kell menni dolgozni / iskolába, ami tovább fog vágja az idő, hogy lehet fordítani a projekt. Nagyon szerencsések voltunk, hogy nem csapattag nem ment ki belőle, de ha ez megtörtént, akkor válhat egy nagy probléma. Képzeljük csak el, hogy az előadó bemegy a közepén egy projekt. És ami még rosszabb, hogy nem hagyja el a jogot, hogy az ő munkáját. Természetesen ez a probléma is megoldható figyelemmel a rendelkezésre álló, a szerződés, de a keresés az új előadó lesz unalmas. A használata két különböző művészeti stílusok egy projekt is lehet probléma.
2. Tart nagy mennyiségű (4-6 számjegy) a fenntartó a szerverek.
Ez nem igaz. Láttam egy csomó a dedikált szerverek egy határa 1000 GB / hó
3. létrehozása MMORPG nagyon izgalmas.
Ez szintén nem igaz. Talán úgy gondolja, hogy minden rendben lesz szimpatikus neked, a játékosok segít képes arra, hogy innovatív küldetések, és nem lesz sok játékos a játékban. A játékosok bosszantó lehet. Még ha ez egy teljesen ingyenes játék, még mindig talál okot panaszra. És a legkellemetlenebb - az emberek gyakran panaszkodnak a teljesen ellentétes dolgokat. Katonák nem tetszik, hogy hosszú ideig kell szerezni egy új szintre, míg a kereskedők fognak csalódni az a tény, hogy a katonák kapnak egy csomó pénzt a díjakat. Ha csökkenti a hiányt szörnyek trófeák, néhány ember, akkor veszélybe kerül az ő távozása a játékot. Ha a növekedés - ugyanazok az emberek lesz elégedetlen a tény, hogy most még a kezdők is könnyen pénzt. De ahhoz, hogy hagyja úgy, ahogy van - nem a legjobb ötlet. Itt kell használni az új ötleteket és fejlesztéseket. Ha úgy dönt, hogy valamit változtatni, például hozzáadott új kihívások azok számára, akik gyártanak tételeket, néhányan azt mondják, hogy túl nehéz. Ha ezt nem teszi meg - azt mondják, hogy ez nagyon könnyű, vagy unalmas. Meg kell emlékezni, hogy a legtöbb játékos általában nem mond semmit, és teljesen elégedett mindennel, míg egy része mindig panaszkodnak.
Gazdaság az MMORPG sokkal nehezebb az egyensúlyt, mint a játék egy játékos. Az egyetlen játékos akkor fokozatosan javítani a fegyvereket, hogy a játékos fokozatosan halad előre, akkor megkapja a legjobb felszerelést, a dobás (eladás) a régi. A multiplayer játék, ez a megközelítés nem sikerült, mivel mindenki próbál jobb fegyverek, figyelmen kívül hagyva a legrosszabb. Sok játékos nem szeretné használni a fegyvereket először, és folyamatosan pénzügyek vásárolható után azonnal a legjobb a lehető fegyver a játékban. Gazdaságfejlesztési megérdemel egy külön cikket írni.
Minden, ami már szerepel a pontig, valamint az extra munkát, és kihívásokat, hogy úgy gondolja, legalább kétszer, mielőtt inkább egy ilyen komoly projekt. Meg kell érteni minden következményét, amelyet választott.
Következtetés.