Hogyan vigyen át egy Unity 4-es projektet Unity 6-ra

Egy Unity 4-es projektet ne nyisson meg közvetlenül Unity 6-ban, és főleg ne mentsen benne semmit. A Unity 6 a régi bináris jeleneteket csak részben tölti be, a mentés pedig véglegessé teszi a veszteséget; a biztonságos út a Unity 2019.4-en át vezet, amely a régi formátumot olvasni és szövegként visszaírni is tudja, és csak utána jön a Unity 6.

Ez azokra a projektekre vonatkozik, amelyek jeleneteit és prefabjait bináris formátumban tárolták, szkriptjeit pedig UnityScriptben írták, abban a JavaScripthez hasonló nyelvben, amelyet a Unity egykor a C# mellett támogatott. Példaként az Onagert használjuk, egy katapultos fizikai játékot, amely Unity 4.1.2-ben, UnityScriptben készült. A projektben 126 szkript, 75 jelenet és 78 prefab volt. Az átvitel után Unity 6000.5-ön fut URP-vel (Universal Render Pipeline), és ingyen elérhető az App Store-ban és a Google Playen.

#Mi történik, ha Unity 6-ban nyitja meg a projektet

A legegyszerűbb megközelítés megnyitni a projektet Unity 6-ban, és a szerializációt Force Textre állítani, vagyis az asseteket olvasható YAML-ként menteni. Ez azonban nem a fájlok fordítása. A Unity minden assetet a saját importerén keresztül tölt be, és YAML-ként írja vissza, így minden átmegy a Unity 6 betöltőjén. Ez minden jelenetnél egy GameObjecthez nem rendelt Transformot jelez, és törli a „lógó” komponenst. A mentés ezt véglegessé teszi.

A veszteség a binary2text eszközzel mérhető, amely a szerkesztővel együtt érkezik, és importer nélkül olvassa a szerializált fájlt. Az Onagernél a kimenetét összevetettük a keletkezett YAML-lel, és csak azokat a komponenseket számoltuk, amelyek a megmaradt GameObjectekről tűntek el:

A 75 jelenetből egy sem úszta meg veszteség nélkül. Teljes HUD-kamerák tűntek el, a fő kamera helyére pedig egy új, alapértelmezett kamera került. A lényeg: a kár már betöltéskor keletkezik, nem mentéskor. Amíg a projekt nincs átalakítva, a Unity 6 nem mentheti el, egyetlen jelenetet és egyetlen prefabot sem.

#1. lépés: Rögzítse az eredeti állapotot

Mielőtt bármihez hozzányúlna, készítsen képernyőképet minden jelenetről, és minden eredeti jelenetfájlról mentsen egy kiírást a binary2text eszközzel. Ezekhez a kiírásokhoz hasonlítja a kamerákat a 3. lépésben, és ezekből állítja vissza a HUD-ot az 5. lépésben. Az eredeti bináris fájlokat hagyja a git előzményeiben, ne törölje őket.

#2. lépés: Szöveggé alakítás Unity 2019.4-gyel

A Unity 2019.4 az utolsó szerkesztő, amely a Unity 4.1 formátumát olvasni és írni is tudja. Az átalakítást zárt szerkesztővel, a repó külön másolatában végezze:

• Projektverzió. A projekt verzióját tároló fájlban állítsa be az eredeti verziót (az Onagernél 4.1.2), hogy a szerkesztő a régi projektekre szolgáló utat válassza. A Unity megnyitáskor felülírja, elég, ha az első importnál érvényes.
• Üres csomagok. Ürítse ki a csomagfüggőségek listáját. Egyetlen fordítási hiba azt jelenti, hogy a szerkesztőszkriptek egyik menüpontja sem működik, és ez úgy néz ki, mintha a menü meg sem jelent volna.
• Import a nulláról. Törölje a Library mappát, és hagyja a projektet importálni.
• Force Text és kényszerített újraírás. A Force Textre váltás után a Unity 2019.4 magától nem írja újra a meglévő fájlokat. Ezt az assetek újraszerializálására szolgáló függvénnyel kell kiváltani, mégpedig csak az assetekre, a meta fájljaikra nem. Az összes meta fájl újraírása után a Unity 6 újra és újra importál.

Egy csapda a gitben van. Ha a git attribútumai a jeleneteket LF sorvégű szövegként jelölik, a git a repóba való felvételkor kiveszi a bináris jelenetekből a sorvégnek látszó bájtokat. Az Onagernél ez nyolc jelenetet rongált meg. A Unity assetjeire ne tegyen sorvég-attribútumot, a Unity úgyis LF-et ír.

#3. lépés: Az eredményt a szerkesztőben ellenőrizze, ne a YAML olvasásával

Az átalakított fájlok olvasása magabiztos, de hibás következtetésekhez vezet. A prefabpéldányok rövidített bejegyzései veszteségnek látszanak, ahogy az a kamera is, amely csak átkerült egy prefabba. Az számít, amit a Unity a memóriában felépít. Minden átalakított jelenetet nyisson meg, és a kameráit vesse össze az eredeti 1. lépésben mentett kiírásával.

Az Onagernél az átalakítás után mind a 75 jelenetben ugyanazok a kamerák maradtak, ugyanabban a sorrendben. Csak az veszett el, amit ma már egyetlen szerkesztő sem ismer: 569 GUITexture, 179 GUIText és a régi részecskerendszerek, amelyeket a Unity 2018-ban eltávolított.

#4. lépés: UnityScriptről C#-ra ugyanazzal a GUID-dal

A Unity a 2017.2-es verziótól fokozatosan vezette ki a UnityScriptet, így a kézi port C#-ra az egyetlen út. A jelenetek a szkriptekre a GUID-dal hivatkoznak, ez egy egyedi azonosító, amelyet a Unity minden asset meta fájljában tárol, a mezők értékét pedig a mező neve szerint tárolják. Ha a port során mindkettőt megtartja, minden hivatkozás magától visszakapcsolódik:

minden X UnityScript-szkripthez:
  hozz létre egy C#-szkriptet pontosan X nevű osztállyal
  másold át a GUID-ot a régi szkript meta fájljából az újéba
  publikus mezők: ugyanaz a név, ugyanaz a típus, elírásokkal együtt
  semmit ne nevezz át, amíg a projekt nem fut

Az Onagernél így mind a 126 szkript portja után 12 935 komponens kapcsolódott vissza 73 jelenetben, és az Inspectorban beállított összes érték megmaradt.

Szöveges kereséssel nem deríthető ki, mely szkriptek vannak használatban. A bináris prefab a GUID-ot bájtokként tárolja, nem szövegként. Az Onagernél így huszonegy szkript tűnt használatlannak, és mindegyik élt. Figyeljen a korábbi portkísérletek maradványaira is: egy fakocka prefabja egy ilyen kísérlet két szkriptjére mutatott, és egyedül miatta hiányzott 1140 komponens. Ha egy bináris fájlban GUID-ot kell cserélnie, cserélje közvetlenül a bájtokban, tizenhatot tizenhatra, hogy a fájl ne csússzon el.

#5. lépés: Állítsa vissza a HUD-ot az eredeti bináris jelenetekből

A GUITexture és a GUIText nincs meg a Unity 6-ban, és velük együtt eltűnik a rájuk épülő teljes HUD. Újrarajzolni nem kell. A binary2text a git előzményeiből származó eredeti bináris jeleneteket akkor is beolvassa, ha az osztályok már nem léteznek. Nyerjen ki belőlük minden HUD-képet és -szöveget textúrával, színnel, pozícióval és igazítással, és szkripttel tegye vissza őket a jelenetek ugyanazon objektumaira. Az Onagernél ez 577 kép és 180 szöveg volt.

Így azok a szövegek is megmenekülnek, amelyek sehol máshol nincsenek meg. Az Onagernél ez 111 szöveg volt: minden tutorialfelirat és a teljes stáblista. Ha a HUD-ot a nulláról írná meg, ki kellene találnia őket. A színek átvitelénél számoljon valamivel, amiről a dokumentáció hallgat: a régi GUITexture rajzoláskor megduplázta a színt. Mind az 577 kép színe pontosan 0,5 volt, vagyis a szürke fehéret jelentett.

#Az átalakítás után: cserélje le a régi kerülőmegoldásokat

A régi projektek gyakran megkerülték az akkori Unity korlátait, és ezeket a kerülőmegoldásokat az átalakítás után érdemes újraépíteni:

• Tükröződés a padlón. Az Onagerben fényes padló volt valódi tükröződés nélkül. A padló alatt egy második, tükrözött világ állt: minden objektum másolata, amelynek pozícióját egy szkript minden harmadik képkockában átmásolta az eredetiről, egy pályán 50-70 klón. Ez helyettesíthető egyetlen további kamerával, amely a tükröződést fél felbontásban rajzolja. Ekkor a részecskék és a törmelék is tükröződnek, amire a klónozott világ nem volt képes.
• Célzás. Ha a röppálya előnézete azt próbálja megjósolni, hová küldi a lövést az első fizikai lépésben hozzáadott erő, a lövés máshová esik, mint a jelölő. Megbízhatóbb egyszer kiszámolni a sebességet, az előnézetet pontosan abból rajzolni, és közvetlenül a lövéshez rendelni.
• Teljesítmény. Gyenge telefonon mérjen. Egy Motorola G52-n az Onager csak a falak shadere miatt 20-ról 6 fps-re esett, ez több volt, mint a felbontás, az árnyékok és a tükröződés együtt. Ezért alacsony és közepes részletességnél a falak egyszerűbb anyagot kapnak.

Ha a mai Unityben több ezer objektum fizikáját kell megoldania, nézze meg a több ezer ellenségre szabott hamis ragdollt a Unity DOTS-ban is. Hogy átállás után hogyan kaphat egy régi 2D játék glow-t és 2D fényeket URP-ben, azt egy külön útmutató írja le.

#Amit ez a módszer nem old meg

Azok a komponensek, amelyeket a mai Unity nem ismer, nem kapcsolódnak vissza. A GUITexture-t és a GUIText-et az 5. lépés szerint kell visszaállítani, a régi részecskerendszerek elvesznek. Az osztályok és mezők neve pontosan olyan marad, mint az eredeti projektben, elírásokkal együtt és azon a nyelven, amelyen valaki egykor megírta őket. A jelenetek név szerint kötődnek hozzájuk, ezért átnevezni csak a szerkesztőn keresztül érdemes, amely maga írja át a hivatkozásokat.

Ha van egy régi Unity-projektje, amelyet egy mai verzióra kell átvinni, írjon nekünk.