Převod hry do Unity

[abuki]

Ahoj,

koukám, že Unity tu nemá sekci (nebo jsem ji nenašel) tak to dávám sem.

Z několika důvodů bych potřeboval svojí hru Ahoooj (která je paradoxně už téměř před dokončením a kterou jste tady na fóru i jinde asi už viděli) zkusit převést do Unity. Dělám to v Game Makeru a všechno je v pohodě až na to, že optimalizace pro iPhone 4 nebo některé androidy je prostě peklo (ale to možná Unity nevyřeší) a protože potřebuju kvůli komiksu co tam máme použít nějaké animační timeliny, bez kterých tam nedostanu ten komiks v takové kvalitě jak bych chtěl. Navíc, když už teda tam dali i ty tooly pro 2D tak bych si je rád vyzkoušel (to prosím berte kdyžtak v patrnost při diskuzi, že bych rád použil co nejvíc přímo 2D nástroje Unity než nějaké 3D workaroundy, které asi byly potřeba dříve).

Unity jsem otevřel, mám zhruba představu jak se to používá, ale než se do toho ponořím naplno, rád bych od někoho zkušenějšího věděl pár věcí, které jsem řešil i v GM projektu.

1) Nechtěl by mi s tím někdo pomoct? Levely si tam stvořim sám a předloha je víceméně hotová, ale s tím jádrem hry - jak řešit některé specifické věci, bych potřeboval pomoct, jinak to bude hroznej bastl. Rád zašlu podrobnější info zájemcům. Můžu nabídnout podíly z prodeje a mám rozjednané i další projekty, které by se případně v Unity dělaly. Toť OT a teď k tomu Unity.

2) Jak se řeší skejlování na různý zařízení? V GM jsem to řešil tak, že jsem si sprity a pozadí nahrával ve dvou velikostech, pozadí byly tily 1024x1024 resp. 2048x2048 a tomu proporčně spritové animace též ve dvou rozlišeních. V editoru jsem pracoval s vyšším rozlišením a při exportu jsem nastavil, že pro desktop se to nechá a pro iOS a Android se použijí sprity a pozadí s nižším rozlišením, pozice objektů se při startu vydělí dvěma, sníží se rychlosti apod. čímž jsem dosáhl dvou výsledných rozlišení. Trochu opruz byl nahrávat assety dvakrát, ale i to by se dalo bejvalo zautomatizovat. Kamera a zobrazení se následně přizpůsobilo velikosti displeje - vždy se roztáhlo view na šířku a výška byla dle poměru stran. Pixel perfect abych to měl pixel na pixel myslim fakt nepotřebuju, takže tohle zjednodušení mi naprosto vyhovovalo. Jak by se podobná věc řešila v Unity? Chtěl bych, aby mi hra běžela na PC v HD (1920x1080), ale mobily to většinou neutáhnou, takže co s tim tam?

3) Další problém byla fyzika. Loď je fyzikální objekt a když narazí do břehů musí se nějak odrazit, otočit, nějak ji unáší proud, takže bez fyziky to myslím v tomto případě nejde, nebo by to bylo příliš komplikované. Na druhou stranu břeh a loď jsou jediné fyzikální objekty (krom občasných pohybujících se překážek). V GM se používá box2d, který má limit jedné fizikální fixture 8 vrcholů a navíc musí být polygon konvexní, takže jsem použil jakýsi Physics Editor, břehy jsem si v tom naklikal, vyexportoval data jako jednoduché pole konvexních polygonů a naimportoval do GM, kde jsem to při startu vytvořil jako neviditelný fixures přes pozadí. Bál jsem se, že to bude problematické na výkon, ale zdá se, že i když mají levely okolo 2048x48000px a loaduju všechny fixtures hned na začátku tak to není moc problém. Opět tedy dotaz - jak by se řešila tato věc v Unity? Byl by tam problém s výkonem?

4) Podotázka k fyzice - loď musí být unášena proudem. V GM jsem to řešil tak, že v každém framu jsem lodi dával impulz (jeden na střed, že by loď mohla mít různé síly na špičku nebo záď jsem ignoroval, i když by to bylo asi pěkné, ale zároveň by to vyžadovalo i čitelnější směr proudu v grafice). Do zatáček dávám triggery, který má každý svůj nastavený úhel. Sečtu a zprůměruju úhel všech kolidujících triggerů. Případně ještě můžu triggeru nastavit, že přidává navíc sílu. Jak byste tento konstantní proud (sílu), který má ale v zatáčkách měnit směr řešili v Unity?

5) Velká rastrová pozadí. Tady to bude asi největší boj. Hádám, že mě budete přesvědčovat ať z toho udělám vektory. To je možná spíš jako podotázka, mě by zajímalo, zda by to šlo udělat těma rastrama, protože to máme celý v rastrech hotový a předělávat to, by byl děs - z mnoha důvodů. Jde tedy o to že klasický level má 20 až 24 dílků pozadí buď 1024x1024 nebo 2048x2048 (viz výše). Teoreticky musí být nahrána v paměti jen 3 v jednu chvíli (ta kde je loď a před a po), ale nevím, zda se to dá nějak za běhu přepínat, jak se s tím pracuje apod. V GM jsem to ne/vyřešil tak, že jsem prostě celej level narval do paměti. Což mi fungovalo na iPadu 3 a na PC, ale na iPhonu 4 to nerozjedu a androidy taky padaj. Designové řešení je přidat do levelů šlajsny (krátké minihry), které budou na nové scéně a rozdělí tak level na menší díly, které se načtou zvlášť. To by mi pak vycházelo zhruba 8 dílků v jednom úseku, větší četnost šlajsen by už kazila hru.
Zkoušel jsem i různé triky jak zmenšit ty dílky - tedy vypustit tu alfu kterou mají všude uprostřed kde je řeka (která je modrá, protože je modré pozadí). Například rozsekat dílky ve čtvercové síti a vyhodit všechny čtverce co mají všechny pixely jen průhledné. To vedlo ke snížení počtu dílků, ale bohužel to zase bylo náročnější na vykreslování a tak to vyšlo zhruba nastejno.
Jak byste to řešili v Unity? Jak to co nejlíp optimalizovat?

6) Atlasy. V GM tomu říkají texture pages. Předpokládám, že jejich optimalizace je alfou a omegou úspěchu, jinak mi bude hra padat kvůli plné paměti (jak se to ostatně děje právě docela často i v GM). Proto mě překvapuje, že se na webu píše, že featura co dovede atlasy nějak inteligentně vytvářet podle štítků a objektů je až v PRO verzi. Je to skutečně tak a bez PRO si nevrznu?
V GM jsem to řešil tak, že jsem si prostě sdružoval sprity podle levelů a každému spritu jsem přiřadil atlas podle levelu. GM pak vzal všechny sprity se stejně nastaveným atlasem a naházel je k sobě. Když se nevešly, udělal atlasů víc. Ve většině levelů se mi vejdou sprity na jeden atlas, plus mám ještě jeden univerzální atlas na loď, vlnky a GUI. Pokud jsem potřeboval nějaké sprity použít ve více levelech ale ne ve všech, tak jsem je prostě duplikoval a přiřazoval jim různé atlasy a přizpůsoboval u objektů jejich sprity dle levelu.
Jakým způsobem se pracuje v Unity s atlasy, jak moc na tom záleží výkon a na co si dát pozor?

7) Komiks. Jednotlivé příběhy má oddělovat relativně jednoduchý komiks. Ale aby to vypadalo trochu cool tak je to potřeba trochu rozhejbat, což se bez nějaké animační timeline dělá blbě. Opět jsou to rastrové objekty, je jich docela dost a často jsou i velké. Měl jsem to řešeno spritama, které jsem se snažil nějak rozhýbat/ukazovat/skrývat, vypadalo to ale trochu prkenně a navíc to zabíralo docela dost atlasů, takže to i padalo. Na to je asi podobná odpověď jako na předchozí otázku.
Mě by ale ještě zajímala jedna věc. Mám kamaráda, co mi ten komiks může velmi snadno a velmi pěkně naanimovat v after effects. Napadá někoho způsob jak to tam dostat, aniž bych to musel ručně přeanimovávat? Z AE se dají exportovat údaje o key framech pomocí nějakých pluginů, také se dá vyexportovat swf video a koukal jsem, že na to je zase například tento plugin: https://www.assetstore.unity3d.com/#/content/3630 ale zajímalo by mě zda s tím čirou náhodou nemá někdo zkušenost? Nebo prostě cutscény animujete v Unity přímo a importovat cokoli je blbost?

Pak určitě existuje spousta drobnějších problémů, ale tohle jsou takové obecné základní věci. Nerad bych se ptal na věci co se najdou v manuálu, ale většinu tohohle nevím jak bych hledal, jde spíš o to jak Unity použít a co řiká zkušenost z praxe.

Kdyby mi s tím někdo chtěl pomoct, budu rád, jak jsem již psal v úvodu.
A pokud jste dočetli až sem, tak už jen za to vám patří díky!
_________________
Twitter @abukac
www.amanita-design.net
www.circusatos.com

[Ladis]

Nižší rozlišení obrázků a k nim podělení hodnot pozic, animací a fyziky nemusíš dělat ručně, můžeš si na to udělat utilitu, která ti to z plné velikosti vygeneruje. Dokonce to můžeš mít v rámci načtení scény a žádná předpočítaná data tak na disku nemusí být (ušetříš 1/4 velikosti, když na disku nebudeš potřebovat ty menší obrázky). Takto by šel řešit iPhone a Android - když to spadne na nedostatek paměti (můžeš to i pro iPhone a Android rovnou předpokládat), tak načteš scénu znovu s parametrem "1/4 rozlišení" (a poznamenáš si to, abys příště nezdržoval loading pokusem o plnou kvalitu). Downsample obrázků je dávno rychlostně zadarmo přes renderování do textury (GPU-akcelerovaný downsampling) - žádný pomalý procházení bajtů v CPU.
_________________
Award-winning game developer

[Mem]

V Playito děláme v Unity hlavně 2D včetně spritových animací, všechno je to ale ruční práce, tj. do textur si děláme ty atlasy (typicky 1024x1024) ručně a potom jen na materiálu nebo v kódu nastavujeme správné offsety a tiling (pro animované sprity máme samozřejmě skripty, které ten tiling a časování řeší automaticky, ale vesměs jsou to jen loopy). S Mecanimem a jinými pokročilými nástroji jsem tam zatím nedělal, stejně tak nevím, co umí ty 2D nástroje v novém Unity (kromě uzamčení viewportu a podobných detailů, ale reálně to samozřejmě pořád zůstává 3D), např. to kombinování více spritů v animaci by pro tebe mohlo být zajímavé.

O tu vlastnost pro generování Atlasů ve verzi Pro jsem se nezajímal, protože máme starší verze případně nové Free, takže to budeš muset omrknout sám, pokud jsi ochotný investovat za licenci (případně kdybys chtěl vyvíjet (jen) pro Xbox One, tak v příštím roce má být pro registrované vývojáře k dispozici Unity Pro s Xbox One pluginem zdarma).

Co se týče použití více velkých textur najednou a omezené paměti, jak jsi sám správně napsal, jedním z řešení by mohlo být rozsekání her do jednotlivých levelů a jejich nahrávání (Application.LoadLevel). Nevýhodou je, že hra je chvíli zaseklá, obraz se neaktualizuje, maximálně hraje hudba na pozadí.

Jestli a jak umí Unity řešit nedostatek paměti, když má všechny textury natažené, nevím. Setkali jsme se ale na Androidu s tím, že při velkých texturách se ztratil za běhu jejich obsah (byly černé), případně framebuffer problikával. Ale možná na to bude existovat nějaké 3rd party řešení, zkus prohledat Assets Store.

Jednou z dalších možností je řešit si dohrávání assetů ručně. Používá se to třeba pro inapp obsah, který tvůrci stahují z vlastních serverů. Tímhle způsobem se dají stahovat textury i celé scény (levely).

Tohle téma mě taky zajímá, tak se určitě pochlub s tím, co objevíš

[]semo[]

Ad 3)
2D fyzika se v Unity dělá tak, že prostě zamkneš jednu osu. Takže je sice 3D, ale toho se z hlediska výkonu neboj. Ten břeh bych asi seskládal klasicky z boxů, nebo spíš s z plejnů. Jinak, v Unity je i mesh collider. Použil jsem ho a na PC s rychlostí taky nejsou problémy (ale většinou mám jen raycasty od kol aut, což nejsou uplně plnohodnotné kolize). No já bych hlasoval pro ty boxy a plejny :-).

Ad 4)
Triggery se mi nelíbí. Co třeba použít "zóny"? Daly by se udělat třeba na základě colliderů + raycastů v jiné vrstvě. Loď by mohla mít nějaké body, třeba právě na přídi a zádi, které by se dotazovaly raycastem na rychlost proudu a podle toho by aplikovaly sílu na loď (klasický odpor prostředí).
Jinak, teď mě napadá, že těma triggerama si myslel možná právě tohle :-)

Jo..a to stejné by samozřejmě šlo udělat jako velocity (flow) mapu.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Rampage]

Už jsem ti před několika měsícema psal do PM, kdy si hledal někoho na výpomoc s GM, aby si to dělal přes unity.

Jestli si tu praci chceš ulehčit, tak použí tenhle asset
http://u3d.as/content/tasharen-entertainment/ngui-next-gen-ui/2vh
Snižuje drawcally a všeobecně to ulehčuje práci.
Rozlišení si zjistíš přes Screen.height a Screen.width, podle toho by sis nascaloval co potřebuješ.
Ale nevím jestli ti to pomůže, protože android má hodně možných rozlišení. Takže na nějakým zařízení by to bylo ok a na jinym by to bylo rozmazaný buď v šířce nebo dělce textury.

Já bych to řešil tak, že pravý břech(texturu) bych si přichytil k pravý straně obrazovky a levý k levý straně obrazovky. Tohle umožňuje právě ngui přes "anchory". Takže by se zvětšovala akorát plocha řeky na různých zařízeních. Tedy že by na vyšších rozlišeních řeka zabírala větší plochu a na nižších menší.
3)nejpíš pomocí toho impulsu s nějakým uhlovým omezením, aby nedošlo k tomu, že by se ta kanoj obrátila o 180°
5)s velkejma textura myslim unity nemá problém, kdyžtak stačí vypnout renderer, aby se to tom ulohčilo u objektů, který nejsou na obrazovce.
6)atlasy umí dělat ngui automaticky.
7)Na sprite animace exitujou taky assety na storu, ale nový unity by to mělo už umět samo

[abuki]

Ahoj, díky moc všem, musím se tím pořádně probrat, zatím jen reakce na konkrétní věci co mě napadly.

[Rampage]

Tak to můžes udělat tak, aby si měl ten poměr výšky ku délce textury přesně daný. Kdyby to rozlišení bylo větší, tak by se zobrazila na pozadí nějaká větší textura(třeba jednobarevná).

Jestli si tam chceš udělat nějakou animaci se sprity, tak se můžes kouknout na nějakej tutorial na youtube jak se dělaj animace v unity. Ten tab pro animování otevřeš, když klikneš třeba na záložku game>add tab>animation

[Mem]

[]semo[]

abuki: Raycasty jsou prostě to, že vezmeš (polo)přímku a zjistíš její průsečík s nějakým kolizním objektem. Je to pojem z 3D, v tvým 2D případě to je přesně to, co si psal: testování bodu vůči (třeba) obdélníku.

Udělat to působení na kánoi ve více bodech je i s tím tvým systémem snadný. Jen bych definitivně doporučoval opustit impulzy a nahradit to stálým působením sil (přes ten vzorec odporu prostředí):

[abuki]

[Rampage]

[abuki]

Tak sem si řek, že místo dalších přiblblejch otázek to prostě v tom Unity zkusim udělat. Terén, pozadí a loď už tam mám a vypadá to moc dobře. Výkon jak fyziky tak vykreslování se zdá být lepší než v GM, což mě plní optimismem. Přesto je pořád GM fajn nástroj na jednoduché hry i třeba kvůli tomu, že umí HTML5.

Bojuju s nějakejma detailama, ale snad se to srovná. Na Unity fóru se mi ozvali nějaký programátoři, tak uvidíme i co z toho bude. Blbý je, že se prostě zas to vydání odsune, ale zas je to příležitost si to Unity pořádně osahat. Tak doufám, že až to doděláme, že to bude ještě někoho zajímat.

Všem díky za tipy!
_________________
Twitter @abukac
www.amanita-design.net
www.circusatos.com

[]semo[]

A já doufal, že to doklepneš v tom GM. Ale Unity je mocný nástroj. Nemám ho rád, nerad to zapínám, ale dělá se v něm rychle, takže tvá hra bude snad taky rychle hotová :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[abuki]

Proč si doufal?
Jak říkám - ono by to šlo, ale musel bych odstřihnout iPhone 4 a většinu androidů. Čistých a plynulých 60fps byl občas také problém a ten komiks by tam musel vypad dost stroze, protože pořádně zanimovat by bylo šílený.

Ale jak jsem psal, GM si stále nechávám na menší projekty a tam kde potřebuju html5, není to špatnej nástroj.
_________________
Twitter @abukac
www.amanita-design.net
www.circusatos.com

[]semo[]

Proč jsem doufal? No, že by snad někdo něco zase dodělal, místo věčnýho předělávání :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory