Egy játék létrehozása egy kis csapat technikai jellemzőivel
Fejlesztő gyermekek mobil puzzle Fold Adventure Alex Galkin írta CPU oszlop, amit meg kell figyelni, hogy a fejlődés a mobil játékok a Unity platform: hogyan kell kiválasztani a megfelelő eszköznek a Asset Store, ahol szolgáltatás tárolására haladás adatokat a felhasználók és hol kap hangok játékokat.
Jó játékhoz jó ötletre van szükséged. De még egy ötlet, nem könnyű létrehozni egy tisztességes játék alapján. A banális szerencse mellett sok dolog van, amivel foglalkozni kell. Végtelen számú döntést kell tenni nagyon szerény időben. Végül is az idő pénz, és a projekt költségvetése eltűnik, mielőtt valami méltó demonstrációra kerülne sor (különben is szabadulni).
Ez a történet arról szól, hogy a kis indie csapatunk létrehozta a "Fold the Adventure" kalandot ("Tedd le a kalandot") az eredeti ötlet alapján. Mivel a játék szabadul fel, lélegzetet vehetünk, és megnézzük a fejlődésre fordított három hónapot. Annak ellenére, hogy sok éves tapasztalattal rendelkezett a szerencsejáték-iparban, a Hajtás a Kaland megteremtése meglehetősen nehézkessé tette az izzadást az előre nem látható események és nagyon korlátozott források miatt. Üdvözöljük a kalandunkban!
A motor kiválasztása: Egység
Az igazat megvallva nem kellett választanunk a motort. Rögtön elvettük az Egységet, és nem sajnáltam. Elsődleges feladatunk egy viszonylag kis játék létrehozása és a platformok maximális számának elindítása volt. Ugyanakkor nem akartam elkerülni a C program és a Java programozás programozását. Az Egységgel sikerült. És bár minden nem volt olyan egyszerű és sima, ahogy azt feltételeztük, elégedettek voltunk a motorral.
Íme néhány olyan ajánlás, amelyet az Egység meglehetősen hosszú használata után fejlesztettünk ki (nemcsak a hajtás kalandjának létrehozására):
Eszköz: létrehoz vagy vásárol
Ha van egy kis csapatunk nagyon korlátozott idővel és költségvetéssel, akkor szinte lehetetlen nagy számban létrehozni minőségi játékelemeket a semmiből. Szükséges a nagyszabású törekvések megbékítése és a szükséges létszám minimalizálása. De még a minimalizálás feltétele mellett is el kell hagynia valamit, amit a játékos örömmel látna.
Ha a támadó játékot a csapat végezheti el - egy probléma kevesebb (valószínűleg). De még mindig van egy prototípus-fázis, és olyan eszközökre is szükség van, amelyek nagy valószínűséggel ki lesznek dobva. Ezért szinte minden csapatnak szüksége van eszközökre, amelyeket nem tud vagy nem akar. A kérdés az, hogy mikor szerezzük őket.
Az első és legnyilvánvalóbb válasz, mint az Unity fejlesztők, az Unity Assets Store volt. Bármennyire is csábító ez a lehetőség, számtalan nehézséggel jár:
- Az Unity Assets Store elemei mindenki számára kivétel nélkül állnak rendelkezésre. Azonban senki nem akarja, hogy a játék olyan legyen, mint a többiek. Legalábbis ezt nem akarjuk.
- Szinte lehetetlen egy szamárcsomagot vásárolni, amely kielégítené a projekt összes igényét, és fennáll a stíluskompatibilitás problémája. A Hajtás kalandozásához néhány csomagot vásároltunk, amelyből kevesebb mint felét használtuk.
- Annak ellenére, hogy az Unity Assets Store birtokában lévő eszközök összlétszáma meglehetősen nagy, nagyon nehéz megtalálni közülük valami különleges igényt. Ugyanakkor a minőség gyakran sok kívánnivalót hagy maga után. Órákban töltöttük a keresést, miközben nem mindig tudtuk értékelni a csomag minőségét anélkül, hogy megvásárolnánk.
A második lehetőség az eszközök kiszervezése volt. Természetesen így több időt és pénzt vesz igénybe, mint vásárolni valamit az Unity Assets Store-ból. Azonban sikeres forgatókönyv esetén a kapott eszközök egyediek és minőségiek.
Lehetőség nyílt arra is, hogy eszközöket vásároljon az Unity Assets Storetól eltérő forrásból. Azonban kompatibilitási probléma volt az Egységgel, és úgy döntöttünk, hogy tartózkodunk az ilyen kísérletektől.
Íme néhány egyszerű szabály, melyeket az Eszközök az Unity Assets Store-ban keresünk és vásárolunk
A zene és a hangok különös figyelmet érdemelnek. Ők ritkán hozták létre az indie csapat maguk (ha van egy zeneszerző, akkor vagy nagyon szerencsés, vagy már nem indie). Szerencsére számos olyan szolgáltatás létezik, amely jogdíjmentesen zenét és hangokat szolgáltat, beleértve a Unity Assets Store-ot is. És ez eléggé olcsó.
Nem elég csak zenét és hangokat vásárolni. Biztosítani kell, hogy a játékban helyesen halljanak, és ne irritálják a hallást. Ha magabiztos a képességeidben, akkor megpróbálod megtenni magad. Mi segítséget fordítottunk egy olyan stúdióhoz, amely a hangviselésre specializálódott. Az eredmény sokkal jobb volt, mint amit magunknak tehetünk, és megérte a pénzünket.
Hol tárolja az adatokat: Parse
Még akkor is, ha Ön, mint nekünk, egy egyjátékos játékot hoz létre, még mindig szükségünk van egy olyan helyre, ahol adatokat tárolhatunk a játékos aktuális eredményéről, tevékenységének statisztikáiról, vásárlásairól és egyéb információkról. A legegyszerűbb megoldás az Unity PlayerPrefs osztály használata. Azonban helyben tartja az adatokat, és nyilvánvalóan nem alkalmas olyan finom dolgokra, mint a játékon belüli vásárlások.
Az egyik oka annak, hogy Parsé-t választottuk, az integráció volt a Facebook-val (az elsõ változat a Fold the Adventure kifejezetten a Facebook-ra készült). És annak ellenére, hogy később a fejlesztés fókuszát mobilplatformokra helyeztük át, továbbra is a Parse-t használtuk.
A Parse egy másik szép tulajdonsága az árpolitikája. Először kissé furcsának tűnik, de a tükröződés és számítás után bizonyul több, mint sikeres. Lényegében korlátozza a kérések száma másodpercenként. A jó hír az, hogy másodpercenként 30 kérést adunk ingyen. Úgy tűnhet, hogy ez elég egy kicsit, de valójában ez elég ahhoz, hogy több ezer felhasználót támogasson. Feltéve, hogy ezeket a kéréseket ésszerűen használja.
A Parse-ban mindent megtesz a lekérdezések segítségével. Az adatmezők megszerzéséhez és módosításához hozzon létre egy kapcsolatot az asztalok között, hozzon létre egy mintát - mindössze egy lekérdezésre van szüksége. Első pillantásra a kérések száma meglehetősen nagy, de valójában az elemi műveletek nagy része egyetlen lekérdezésre kombinálható a ParseObject.SaveAllAsync módszer használatával. Ezenkívül a Parse kivételt is ad, ha a másodpercenkénti kérelmek határát túllépik. De semmi sem akadályozza meg, hogy várjon egy kicsit, és ismét végrehajtsa a kérelmet. És bár a játék ebben az esetben úgy tűnhet, hogy a felhasználó "lógott", ez a probléma egyszerűen kezelhető kis módosításokkal a felhasználói felületen és az adatok mentésének és olvasásának logikáján.
Az egyetlen dolog, amit a Parse nem szabad használni, egy játékszerver létrehozása. Még akkor is, ha lépésről-lépcsős játékot fejlesztesz, a Parse célja alapvetően más. Vannak más megoldások, amelyek sokkal jobban megfelelnek ezeknek a céloknak.
A Parse egységen belüli használata nem különösebben nehéz és jól dokumentált. Valójában le kell töltened a Parse SDK-t, fel kell állítanod a játékodat a Parse szerveren és az Unity projektben, és programozhatsz egy kicsit. Az egyik nyilvánvaló árnyalat: a Parse nem használható, ha az eszköz, amelyen a játék telepítve van, nem fér hozzá az internethez.
Ha szükség van az offline mód fenntartására és az adatok frissítésére a Parse-ben egy hálózati kapcsolattal, akkor ehhez külön különálló rendszert kell írni. Ehhez a PlayerPrefs osztályt használtuk. A rendszer helyben tárolja az adatokat, és feltölti azt a Parse-re, amint felismeri az internetkapcsolatot.
Helyhez kötött platformok mobil ellen: kompromisszumok
Az elmúlt évek fokozatos konvergenciája ellenére az álló és mobil platformok még mindig nagyon különböznek egymástól. Ez nyilvánvalóvá válik, amikor a "gyönyörű" árnyékolók készen állnak arra, hogy elfogadhatóak legyenek (nem is beszélve arról, hogy gyorsan működjenek) minden olyan eszközön, amelyen a játéknak futnia kell. Az egység nagymértékben megkönnyíti ezt a folyamatot, de sajnos nem oldja meg az összes problémát.
Hatalmas cikk van az Unity-játékok mobilplatformokra történő optimalizálásával kapcsolatban, így a témáról itt egy kicsit elmondható.
Íme néhány ajánlás:
- Ha mobil platformokon kívánja elindítani és árnyékokat használni, akkor korlátozza a módot a világítás továbbítására. A világítás sütése és az árnyékoló tárgyak számának csökkenése ellenére nem sikerült elfogadható teljesítményt biztosítani a halasztott világítási módban. Talán nem keményen próbálkoztunk, de a Unity fórumai nagyrészt szolidárisak velünk ebben a kérdésben.
- Csökkentse a hívások számát. Számos sokszög a modellekben nem befolyásolja annyira a teljesítményt, mint a további hívások. Számos optimalizálást tervezünk, melynek célja a felhívások számának csökkentése, annak érdekében, hogy jobban támogassuk a mobil eszközök régi modelljeit, de sajnos nem tudtuk rögzíteni a határidőket.
- Ne árulja el a textúrákat árnyékban. Ez a teljesítmény jelentős csökkenéséhez vezethet. A mi játékunkban kénytelenek voltak több speciális árnyékolót használni egy univerzális helyett - ezért.
A teljesítmény- és hardverkorlátozások különbségein kívül más fontos különbség van a fix és a mobil platformok között. És ez a különbség a bemeneti mód. A billentyűzet és az egér segítségével történő vezérléshez létrehozott játékot a multitouch és a gyorsulásmérő nem fogadja jól. Ezt a keserű tapasztalatunkon keresztül láttuk. Először is, az Unity-ban az egér és a multitouch feldolgozás el van osztva. Ezért olyan rendszert kellett létrehozni, amely egységesíti ezt a szempontot. Ebből a célból egy NGUI bemeneti rendszert használtunk. amely kisebb fejlesztések után nagyon jól mutatta magát. Azt is lehetővé tette számunkra, hogy megoldjuk a bemeneti felosztás problémáját a felhasználói felület és a játékvezérlés között, ami akkoriban problémát okozott nekem.
A felhasználói felületek egészében számos módosítást igényeltek a mobileszközök helyes támogatásához. Például az egér görgőjének görgetése és a gombok lenyomása helyett többszöri gesztusokat kellett beírni. Néhány módosítást potenciálisan egyszerűsíthetünk az Unity Assets Store által készített kész megoldásokkal. De a mi esetünkben ez egy egyszerű csipetnyi volt, úgyhogy úgy döntöttünk, hogy a karcolásból egy órát írunk le, ahelyett, hogy napi napokat kötnénk össze és debugoznunk egy olyan rendszert, amely "mindent csinál és még többet tesz".
A legtöbb problémát a játékmenedzsment okozta. Elkezdtünk egy hagyományos ASWD + egér készletet a karakter és a kamera vezérléséhez, és terveztük, hogy mobil eszközön használjuk a képernyő joystickot. De minden nem kiderült, nem úgy, ahogy vártuk: a játék szinte ellenőrizhetetlen volt. Sürgősen változtatnunk kell a játékmenedzsmenten, miközben változtatnánk a játék mechanikán. A próba és a hiba révén pont-n-click kezelést rendezünk, amelyet intuitív módon érzékelünk a mobileszközökön.
Lokalizáció: minél egyszerűbb, annál jobb
Ha globális szinten szeretné elérni a játék sikerét, akkor kétségtelenül lokalizálni kell. És a lokalizáció egy másik része a fejlesztésnek, amelyet egy indie csapat szinte soha nem tehet egyedül. Ez csak egyet jelent: a helymeghatározáshoz fizetni kell.
Minden, ami köze van az emberi nyelvhez, lokalizálni kell. Vagyis szövegek, beszéd, textúrák - mindezt lokalizálni kell. Egy ilyen folyamat nagyon gyorsan nagyon időigényes és drága lesz. Ezért rendkívül fontos, hogy a helyi tartalom minimálisra csökkenjen.
Kerülni kell a textúrákat, és például NGUI szövegmezőket kell használni. Ha a játéknak beszédre van szüksége, akkor valószínűleg feliratokra lesz szükség, mivel a beszéd lokalizációja nem csak drága öröm, hanem a játék által elfoglalt hely szempontjából is igényes.
A helyi tartalom minimalizálása azonban csak a kezdet. A következő lépés maga a játék előkészítése a lokalizációhoz. A rossz hír az, hogy az Unity (ezen írás idején) nem rendelkezik beépített mechanizmusokkal e célokra. Bár az Unity Assets Store-ban számos speciális megoldás létezik (például l2 lokalizáció), úgy döntöttünk, hogy az NGUI részét képező lokalizációs rendszert használjuk.
Az NGUI lokalizációs rendszer egyszerű és egyszerűen használható. Egyetlen CSV fájl alapján épül fel, amely minden nyelvre oszlopot tartalmaz. Az ilyen fájlok jelenléte nagyon kényelmes a vonalak fordításhoz való továbbításával (ebből a célból számos speciális szolgáltatás létezik), majd a lefordított verzió későbbi beillesztése.
A Google Dokumentumlapokat a lokalizációs fájl tárolására használtuk. Ebben a verzióban könnyen elérhető minden csapat tag, gyorsan frissíthető és letölthető CSV formátumban. Ezenkívül ezt a fájlt számos olyan ismerős számára elérhetővé tettük, akik más nyelveket beszélnek. Tehát a transzferek egy részét ingyen kaptuk.
Sajnálatos módon az NGUI lokalizációs rendszere nagyon korlátozott a képességeiben, és nem használható olyan játékokban, amelyek sokféle helyi tartalmat tartalmaznak. Például nem engedélyezi a szövegmező betűtípusának megváltoztatását, és ez a lehetőség akkor szükséges, ha a nyelvek, például a japán nyelvek lokalizálása szükséges. E tekintetben bővítettük az NGUI UILocalize osztály funkcionalitását, hozzáadva a betűtípus megváltoztatását és a szövegmezők pozíciójának megváltoztatását.
következtetés
Miután minden megtörtént, a játékot alaposan meg kell vizsgálni (érdemes megtenni, és többször is a fejlesztési folyamatban). Ez a maximális számú készülékkel foglalkozik. Semmi sem veszít egy jó játékot, mint egy hiányzott hiba. Szükséges hallgatni a játékosok panaszait. Mivel ezek a panaszok a piacon való megjelenés után azonnal elégedetlen fogyasztókká válnak. És pontosan ezt senki sem akarja.
A fejlesztés során folyamatosan teszteltük játékunkat, több mint száz különböző hibát azonosítottak és korrigáltunk. Ugyanakkor a játékunk nem volt olyan bonyolult és nagyszerű, de a szoftver nem hibák nélkül zajlik le. Ezenkívül a tesztelők javaslatai és panasza alapján számos módosítást hajtottunk végre a játékban, beleértve az alapvető játékmódszerek változásait, a szintek egy részének struktúráját, a felhasználói felület elemeinek méretét és helyzetét, a játékkezelést.
Ez a történet a szabadon bocsátott játékkal együtt három hónap kemény és gondos munkát végez. És annak ellenére, hogy sok nehézséggel szembesültünk, nagyon izgalmas volt a Fold the Adventure fejlesztése. Reméljük, hogy az általunk létrehozott játék, valamint a megszerzett tapasztalat kicsit jobbá teheti a világot. Sok szerencsét a játékok létrehozásában!