Unreal vs Unity: Cila është më e mira për zhvillimin e lojërave celulare? Rezultatet e krahasimit. Shpejtësia e kornizës

Në mësimet e mëparshme, ne modeluam dhe teksturuam terrenin, ndërtesat dhe pamjet e jashtme. Si t'i kombinoni tani të gjitha këto objekte në një skenë dhe t'i rregulloni në vendet e duhura? Ku t'i gjeni objektet që mungojnë - makina, pemë, shkurre, lule? Ne do të mësojmë për këtë në këtë mësim.

Në këtë tutorial, ne do të fusim objekte në skenë duke përdorur komandën Shkrihet(Kombinoni) dhe rregulloni këto objekte me kontrollues Lista e pozicioneve(Pozicioni kontrolluesin në listë), Kufizimi i rrugës(Kufizim gjatë rrugës), mjet Foto e çastit(Lloji i objektit) sipas shtojcës MultiScatter dhe modulin e tij Multipainter, dhe gjithashtu mësoni se si t'i përktheni objektet në Objektet proxy.

1. Futja e objekteve nga skedarët e tjerë.

1. Le të hapim skedarin me peizazhin. Pikërisht në këtë skedar do të fusim të gjitha objektet e tjera dhe do t'i rregullojmë mbi peizazhin e pikturuar.

2. Le të fusim ndërtesa. Për ta bërë këtë, shkoni te menyja Skedari(File)> klikoni në shigjetën pranë butonit Importi(Import)> Shkrihet(Kombinoj) (Fig. 1).

Oriz. 1. Përdorimi i komandës Merge

3. Në dritaren që hapet, zgjidhni skedarin e dëshiruar dhe klikoni Hapur(Hapur) (Fig. 2).

Oriz. 2. Përzgjedhja e skedarit të dëshiruar

4. U shfaq një dritare Shkrihet(Combine), i cili liston emrat e të gjitha objekteve nga skedari i bashkangjitur. Na duhen vetëm ndërtesa. Për të zgjedhur vetëm objektet që na duhen, klikoni mbi to duke mbajtur të shtypur tastin Ctrl... Shtyni Ne rregull(Fig. 3).

Oriz. 3. Përzgjedhja e objekteve të kërkuara

Objektet e përzgjedhura futen në skenën e peizazhit (Fig. 4).

Oriz. 4. Futja e objekteve

Ushtrimi 1

Futni vetë të gjithë artikujt e jashtëm në të njëjtën skedar (Fig. 5).

Oriz. 5. Futja e sendeve të jashtme

Shënim: nëse i keni vendosur të gjitha objektet në shtresat tuaja, atëherë kur i ngjitni këto objekte në një skedar tjetër, shtresat gjithashtu do të kopjohen. Prandaj, nëse keni krijuar me ndërgjegje shtresa siç përshkruhet në mësime, atëherë tani keni Menaxho shtresat(Menaxheri i shtresave) duhet të ketë shtresa si në Fig. 6.

Oriz. 6. Pamja e menaxherit të shtresave

2. Futja e objekteve nga bibliotekat e modeleve të gatshme

Në mësimet e mëparshme, mësuam se si të modelojmë shumë nga objektet që na duhen. Por ka objekte të tilla, modelimi i të cilave do të marrë një kohë shumë të gjatë, ose për t'i krijuar ato ju duhet njohuri shumë e thellë e programit, ose thjesht nuk ka kuptim t'i modeloni ato, sepse ato tashmë ekzistojnë dhe thjesht mund t'i shkarkoni . Këto objekte përfshijnë makina, pemë, shkurre, lule, etj.

Ka shumë faqe nga ku mund të shkarkoni modele të ngjashme, për shembull:

• http://www.3dklad.com/ etj.

Gjithashtu, disa modele të gatshme mund të shkarkohen nga seksioni "Biblioteka" e kësaj faqeje.

Biblioteka të tilla modelesh të gatshme tundojnë vizualizuesit fillestarë që të mbledhin një skenë shpejt dhe me lehtësi, duke futur në të modele pak a shumë të përshtatshme nga koleksioni. Por kini shumë kujdes, sepse mund të ketë një problem të burimeve të pamjaftueshme harduerike në fazën përfundimtare të punës. Kjo për faktin se modelet e shkarkuara mund të kenë një numër të madh poligonesh.

Së pari, kur kërkoni për modele, sigurohuni që materialet e modelit të përputhen me interpretuesin në të cilin po punoni (VRay).

Së dyti, pas shkarkimit, mos e futni modelin menjëherë në skenën tuaj, por hapeni në një skenë të veçantë dhe ruajeni modelin nga të gjitha gjërat e panevojshme që nuk do të duken qartë. Ka kuptim të hiqni ose rimodeloni disa elementë krejtësisht, sepse modeluesit rrallë kujdesen për minimizimin e produktit të tyre.

Vetëm pas kësaj ju mund ta fusni me siguri modelin në skenën tuaj pa frikë se mos e mbingarkoni atë.

Detyra 2

Shkarkoni, kontrolloni dhe ngjitni ( Import> Bashko) në skenën tonë modelet e pemëve, shkurreve, luleve, gurëve, makinave dhe më tej sipas gjykimit tuaj (Fig. 7).

Oriz. 7. Futja e modeleve të përfunduara

Sigurohuni që të krijoni shtresa për këto objekte dhe t'i vendosni secila në shtresën e vet (Fig. 8).

Oriz. 8. Pamja e menaxherit të shtresave

3. Radhitje “manuale” e objekteve

Për akordim më të saktë dhe të imët të skenës, është shumë i përshtatshëm të përdoret metoda manuale e vendosjes së objekteve. Prandaj, ne do të rregullojmë ndërtesa, stola, kosha plehrash, shenja rrugore, lule dhe gurë për shtretër lulesh, makina në mënyrën më të zakonshme - "me dorë", thjesht duke i tërhequr zvarrë me miun duke përdorur mjetin Zgjidhni dhe Lëvizni(Zgjidhni dhe Lëvizni). Ne marrim objektet që mungojnë duke kopjuar me tastin e shtypur. Zhvendosja... Zgjidhni llojin e kopjes shembull(Shembull) (Fig. 9).

Oriz. 9. Kopjoni objektet që mungojnë

Si rezultat, ne duhet të marrim skenën si në Fig. 10, Fig. njëmbëdhjetë.

Oriz. 10. Pamje e vendit të ngjarjes pas vendosjes “manuale” të objekteve

Oriz. 11. Objekte të renditura

4. Vendosja "automatike" e objekteve duke përdorur kontrollorët, përkthimi në Proxy dhe mjeti Snapshot

Ka objekte që duhen rregulluar me njëfarë rregullsie, për shembull, fenerë, kafaz, shkurre në modele "të prera" bukur. Prandaj, ne do të shqyrtojmë një mënyrë për të automatizuar procesin e vendosjes së objekteve.

1. Zgjidhni një objekt, për shembull një fener.

2. Le ta përkthejmë elektrik dore në Objekt proxy... Objekti i përfaqësuesit bëhet, si të thuash, një referencë për një objekt që vetë ndodhet diku tjetër. Kjo do të ndihmojë në zvogëlimin e ngarkesës së rëndë në program dhe kartën video dhe do të zvogëlojë kërkesën për ndarjen e RAM-it. Kjo do të bëjë të mundur përdorimin e miliona dhe madje miliarda poligoneve në skenë në kompjuterë të zakonshëm, gjë që është përshtatja më e mirë për të zgjidhur detyrën tonë për të krijuar një qytet.

Ne do të formulojmë parakushtet për transferimin e një objekti në Objekt proxy.

Nëse një objekt përbëhet nga disa pjesë përbërëse, atëherë ato duhet të kombinohen duke përdorur komandën Bashkangjit në një objekt.

Të gjitha teksturat duhet të aplikohen tashmë në objekt.

Vetëm pasi të plotësohen këto kushte, objekti mund të transferohet në Përfaqësues... Për ta bërë këtë, klikoni me të djathtën mbi objektin dhe zgjidhni komandën Eksportimi i rrjetës V-Ray(Eksport në sipërfaqen V-Ray) (Fig. 12).

Oriz. 12. Transferimi i një objekti në Proxy

Në dritaren e hapur në fushë Dosja(Dosje) specifikoni shtegun për të ruajtur objektin Proxy (është e këshillueshme që të krijoni një dosje për objektet Proxy në dosjen e projektit në mënyrë që objektet Proxy të mos humbasin kur punoni në projektin tuaj në një kompjuter tjetër). Në fushë Skedari(Skedari) vendosni një emër për objektin e përfaqësuesit ose lëreni atë si parazgjedhje. Sigurohuni që të kontrolloni kutinë Krijo automatikisht proxies(Krijo Proxy Automatikisht) dhe kliko Ne rregull(Fig. 13).

Oriz. 13. Parametrat për transferimin e një objekti në një përfaqësues

Objekti do të ndryshojë pamjen e tij. Kjo është një veçori tjetër e objekteve Proxy për të lehtësuar ngarkesën. Objekti mund të duket si një kuti, si një rrjetë e errët, ose në përgjithësi si një pikë, etj. - në varësi të parametrave të zgjedhur të shikimit në parametrat e objektit Proxy - por pas paraqitjes ai do të marrë formën e tij reale (Fig. 14).

Oriz. 14. Shfaqja dhe vizualizimi i thjeshtuar i objektit

3. Kontrolloni nëse keni Pika e rrotullimit(Pika e ankorimit, rrotullimi i objektit dhe pika e shkallëzimit) në bazën e objektit. Tani, si parazgjedhje, pika është në mes të fenerit. Ajo duhet të zhvendoset në bazën e saj. Për ta bërë këtë, shkoni te skeda Hierarhia(Hierarki) dhe zgjidhni Prekni vetëm Pivot(Ndikimi në pikën e ankorimit). Tani duke përdorur Zgjidhni dhe Lëvizni(Zgjidh dhe Lëviz) dhe Snaps 3 mund të lëvizim pikën e ankorimit (Fig. 15). Pas kësaj, le të mos harrojmë të dalim nga modaliteti i redaktimit.

Oriz. 15. Lëvizja e Pivot Pivot

4. Le të krijojmë paraprakisht një shteg përgjatë së cilës fenerët do të vendosen në mënyrë të barabartë. Në rastin tonë, thjesht krijoni Rretho rreth parkut, si në Fig. gjashtëmbëdhjetë.

Oriz. 16. Krijimi i një rruge

5. Caktoni një fanar kontrollorët... Ky koncept i referohet animacionit në 3Ds Max. Me ndihmën e kontrollorëve, zhvilluesi i grafikës tredimensionale mund të kontrollojë në mënyrë fleksibël ndryshimin e parametrit të animuar të objekteve. Kontrollorët e animacionit janë kufizime të paracaktuara, sipas të cilave parametrat mund të ndryshohen. Në këtë tutorial, ne nuk do të përdorim kontrollues për animacion, por për pozicionimin e objekteve.

Zgjidhni fenerin dhe shkoni te skeda Lëvizja(Lëvizje). Le të hapim rrotullën Cakto kontrolluesin(Caktoni një kontrollues), zgjidhni një rresht Pozicioni: Pozicioni XYZ(Pozicioni: pozicioni XYZ) dhe klikoni në butonin e caktimit të kontrolluesit. Nga lista që hapet, zgjidhni Lista e pozicioneve(Listo kontrolluesin e pozicionit). Ky kontrollues ju lejon të kombinoni disa kontrollues të pavarur menjëherë për të krijuar një animacion të përgjithshëm, dhe kjo do të jetë e dobishme për ne në të ardhmen.

Oriz. 17. Qëllimi i kontrolluesit të listës së pozicioneve

Pas aplikimit të këtij kontrolluesi në lista Pozicioni: Lista e pozicioneve> Pozicioni XYZ: Pozicioni XYZ do të shfaqet një rresht Në dispozicion(E disponueshme), duke ju lejuar të shtoni kontrollues të rinj në listë. Zgjidhni këtë rresht dhe shtypni përsëri butonin Cakto kontrolluesin... Në kutinë e dialogut që hapet, këtë herë zgjidhni Kufizimi i rrugës(Kufizim gjatë rrugës). Ky kontrollues kufizon lëvizjen e objektit përgjatë shtegut, i cili është spline i specifikuar. Ky kontrollues përdoret për të animuar objekte përgjatë shtigjeve komplekse (për shembull, lëvizja e një makine në rrugë). Shtypni Ne rregull(Fig. 18).

Oriz. 18. Qëllimi i kontrolluesit të kufizimit të rrugës

Tani më poshtë, në një rrotull Lista e pozicioneve nxjerr në pah Kufizimi i rrugës dhe klikoni në butonin Vendos aktiv(Bëhu aktiv). Në një rrotull Parametrat e Rrugës(Parametrat e rrugës) klikoni në butonin Shto shtegun(Cakto shtegun) dhe zgjidhni shtegun e krijuar më parë. Sigurohuni që të kontrolloni kutinë pranë Ndiqni(Ndiq), zgjidhni boshtin e dëshiruar, nëse është e nevojshme, ne do të reflektojmë duke përdorur Rrokullisje(Rrokullisje). Feneri do të lëvizë në fillim të shtegut (Fig. 19).

Oriz. 19. Caktimi i rrugës

6. Nëse filloni animacionin tani, fanar do të lëvizë pikërisht përgjatë shtegut. Por të gjitha këto veprime me caktimin e kontrollorëve tani nuk ishin për hir të animacionit, por në mënyrë që objekti të ndjekë qartë rrugën që na nevojitet. Tani do të kuptoni pse na duhej.

Nga menyja kryesore Mjetet(Mjetet) zgjidhni një mjet Foto e çastit(Lloji i objektit) (Fig. 20). Është krijuar për të krijuar një sërë objektesh përgjatë rrugës së animimit të objektit origjinal (në rastin tonë, animimi i fenerit gjatë rrugës).

Oriz. 20. Vendndodhja e mjetit Snapshot

Në dritaren që hapet, kontrolloni kutinë përballë Gama(Përgjatë trajektores), ne lëmë vlerat nga 0 deri në 100, Kopje(Numri i kopjeve) të vendosur sipas gjykimit tonë. Zgjidhni metodën e kopjimit shembull(Shembull) dhe klikoni Ne rregull... Do të shohim menjëherë se si fenerët vendosen automatikisht përgjatë trajektores që kemi vizatuar (Fig. 21).

Oriz. 21. Përdorimi i mjetit Snapshot

Ka mbetur një pikë e rëndësishme. Është e nevojshme të hiqni atë fanar origjinal me animacion, përndryshe ai do të lëvizë në një rreth në videon tonë të prezantimit. Është shumë e thjeshtë për ta bërë këtë: aktualisht është zgjedhur, prandaj, pa hequr përzgjedhjen, shtypni butonin Fshije në tastierë.

Nëse ndonjë fener është në vendin e gabuar, gjithmonë mund ta lëvizni atë "me dorë". Si rezultat, do të kemi një skenë të ngjashme me Fig. 22.

Oriz. 22. Pamja perfundimtare pas vendosjes se dritave

7. Vendosni fenerë në të gjithë pjesën tjetër të qytetit. Aty ku nuk është shumë i përshtatshëm përdorimi i vendosjes "automatike" të dritave - bëjeni me dorë (Fig. 23).

Oriz. 23. Dritat e rregulluara

Detyra 3

Vendosni vetë kapakë të vegjël rreth parkut në të njëjtën mënyrë (Fig.).

1. Zgjidhni rrjetën e vogël dhe përktheni atë në Objekt proxy.

2. Lëviz Pika e rrotullimit në bazën e objektit (Fig. 24).

Oriz. 24. Pivot Pivot në bazën e objektit

3. Vizatoni një shteg për rregullimin e grilës - Rretho pak më shumë se më parë.

4. Caktoni kontrollorët në sekuencë Lista e pozicioneve dhe Kufizimi i rrugës... Bëni kontrolluesin aktiv Kufizimi i rrugës duke shtypur butonin Vendos aktiv... Caktoni rrugën e krijuar më parë duke klikuar në butonin Shto shtegun... Grilë lëvizi në fillim të shtegut dhe qëndronte pingul me të (Fig. 25).

Oriz. 25. Grilë e vendosur pingul me shtegun

Kjo duhet të rregullohet duke kontrolluar kutinë pranë Ndiqni(Ta ndjek). Mund të zgjidhni boshtin e dëshiruar nëse dëshironi të pasqyroni me të Rrokullisje(Flip) (Fig. 26).

Oriz. 26. Grilë e vendosur përgjatë shtegut të mëposhtëm

5. Nga menyja kryesore Mjetet zgjidhni një mjet Foto e çastit... Në dritaren që hapet, kontrolloni kutinë përballë Gama(Përgjatë trajektores), lini vlerat 0 deri në 100, Kopje(Numri i kopjeve) ne vendosëm sipas gjykimit tonë, gjëja kryesore është që grilat të përshtaten në mënyrë të përkryer me njëra-tjetrën. Zgjidhni metodën e kopjimit shembull, shtypni Ne rregull(Fig. 27). Rrjetat u rregulluan automatikisht përgjatë shtegut që ne vizatuam.

Oriz. 27. Përdorimi i mjetit Snapshot

Hiqni grilën origjinale të animuar duke shtypur tastin Fshije në tastierë.

Nëse një grilë është në vendin e gabuar, për shembull, pikërisht në pistë, gjithmonë mund ta lëvizni "me dorë" ose ta hiqni plotësisht. Si rezultat, do të kemi një skenë të ngjashme me Fig. 28.

Oriz. 28. Pamja përfundimtare pas vendosjes së grilave të vogla

Detyra 4

Vendosni kafaze të mëdha rreth shtëpive tuaja dhe shkollës vetë. Diku do t'ju duhet t'i vendosni ato me dorë (për shembull, ku ka porta), diku ky proces mund të automatizohet. Si rezultat, duhet të duket diçka si Fig. 29, Fig. tridhjetë.

Oriz. 29. Pamja përfundimtare pas vendosjes së grilave të mëdha

Oriz. 30. Pamja përfundimtare pas vendosjes së grilave të mëdha

Detyra 5

Rregulloni shkurret me metodën automatike përgjatë shtigjeve të tërhequra (Fig. 31, Fig. 32).

Oriz. 31. Shkurre të rregulluara

Oriz. 32. Shkurre të rregulluara

5. Vendosja "Automatike" e objekteve duke përdorur shtojcën MultiScatter - MultiPainter

Ne kemi shqyrtuar tashmë disa mënyra për vendosjen e objekteve në skenë: "manualisht" dhe "automatikisht" përgjatë trajektores. Po sikur të na duhet të organizojmë fjalë për fjalë miliona kopje të një objekti, si bari apo pylli? Metodat tashmë të njohura për ne nuk do të ndihmojnë këtu.

Ju ndoshta keni dëgjuar tashmë për MultiScatter... Ky është një plugin për 3Ds max, me të cilin mund të krijoni me lehtësi dhe lehtësi skena me miliona objekte. Versioni i ri i MultiScatter përfshin një modul të ri dhe shumë të dobishëm Multipainter... Kjo ju lejon të "pikturoni" objekte në të gjithë një sipërfaqe duke përdorur një furçë virtuale. Vizatimi mund të bëhet si në një sipërfaqe, ashtu edhe në disa në të njëjtën kohë. Mund të vizatoni me disa objekte të ndryshme në të njëjtën kohë. Prandaj, MultiPainter është i përshtatshëm në mënyrë ideale për detyrat tona.

1. Shkarkoni dhe instaloni shtojcën MultiScatter.2. Theksoni tufat e barit dhe përktheni ato Objektet e përfaqësuesit (klikoni me të djathtën> Eksportimi i rrjetës VRay)... Në kutinë e dialogut që hapet, vendosni emrin dhe dosjen, vendosni një shenjë kontrolli Krijo automatikisht proxies... Shtyni Ne rregull.

3. Kontrollojeni atë Pika e rrotullimit ishte në bazën e tufave të barit.

4. Tani mund t'i rregullojmë këto objekte duke përdorur MultiScatter - MultiPainter... Për ta bërë këtë, në skedën Krijo zgjidhni Gjeometria dhe nga lista rënëse zgjidhni MultiScatter, Shtyp butonin Multipainter.

Pas kësaj, sigurohuni që ta vendosni përcaktimin e tij drejtpërdrejt në skenë - për ta bërë këtë, mbani të shtypur butonin e majtë të miut dhe tërhiqni kursorin në çdo drejtim (Fig. 33).

Oriz. 33. Shënim MultiPainter

5. Pas kësaj, shkoni te skeda Modifiko... Këtu shohim parametrat e instaluar rishtas Multipainter.

Në një rrotull Pikturoj Objektet(Vizatimi i objekteve) nën Shpërndani objektet(Objektet për vendosje) është e nevojshme të tregohen objektet me të cilat do të vizatojmë. Klikoni në butonin + kazan dhe zgjidhni objektet tona në skenë. Butoni + lista ju lejon të zgjidhni objekte nga një listë dhe jo nga një skenë. Zgjidhni objektet në mënyrën që ju përshtatet më së miri. Butoni - kazan përgjegjës për heqjen e objekteve për vizatim.

Pasi të specifikoni objektet për të vizatuar, dy parametra do të bëhen të disponueshëm - Probabiliteti(Probabiliteti, dendësia) dhe Shkalla e përplasjes(Kuptimi i përplasjes). Janë ata që do të duhet të konfigurohen. Tani për tani, le të vendosim vlerën për rrezen e gjelbër Probabiliteti 200, Shkalla e Përplasjes 5, dhe për një pako të zverdhur Probabiliteti 10, Shkalla e Përplasjes 5.

Në kapitullin Opsionet e furçave(Opsionet e furçës) mund të rregullohen Rrezja(Rrezja), Butësi(Zbutësia e skajit) dhe Intensiteti(Intensiteti, presioni) i furçës. Le të vendosim Rrezja 100, Butësia 1, Intensiteti 80... Butonat më të rëndësishëm janë gjithashtu të vendosur këtu. Bojë(Vizatoni) dhe Fshije(Fshi).

Në një rrotull Sipërfaqet(Sipërfaqet) duhet të specifikoni sipërfaqen (s) në të cilën do të vizatoni. Butonat janë tashmë të njohur për ju, veprimi i tyre është i ngjashëm me ato të mëparshme. Ne tregojmë këtu sipërfaqen e lëndinës sonë.

Në një rrotull Rrotulloje(Rrotullimi) mund të specifikoni se sa gradë mund të rrotullohen objektet gjatë vizatimit. Ne vendosëm në bosht Z vlera e rrotullimit 360 gradë për t'i bërë tufat e barit të duken të ndryshme dhe jo të përsëritura.

Në një rrotull Shkalla(Shkallëzimi) mund të specifikoni se sa do të ndryshojnë objektet në shkallë nga njëri-tjetri. Le të vendosim vlerën Nga(Nga) 90 , për të(Para) 100 .

Në një rrotull Parapamje(Paraafishimi) mund të zgjidhni mënyrën e shfaqjes së objekteve në portën e shikimit. Kutia - çdo objekt do të jetë në formën e një paralelepipedi, Kryqi - në formën e një kryqi, Pikat, Numërimi - në formën e një grupi pikash, Asnjë - nuk do të shfaqet në asnjë mënyrë në portin e shikimit, i cili mund të të jetë shumë i dobishëm në një skenë të rëndë.

Të gjitha cilësimet e nevojshme janë paraqitur në Fig. 34.

Oriz. 34. Cilësimet e MultiPainter

6. Pra, ne kemi instaluar të gjithë parametrat dhe cilësimet që na duhen. Tani le të zgjedhim të dy trarët në seksion Shpërndani objektet dhe shtypni butonin Bojë(Vizatoni). Ne lyejmë me një furçë direkt në lëndinë tonë (Fig. 35).

Oriz. 35. Vizatim me furçë

Se sa të suksesshëm janë parametrat e vendosur për skenën mund të shihet vetëm pas paraqitjes paraprake. Le të shohim rezultatin duke dhënë një fotografi (Fig. 36). Nëse kërkohet, ndryshoni parametrat e kërkuar.

Oriz. 36. Tufa bari të vendosura në skenë

Detyra 6

Vendosni tufa bari në të gjithë qytetin, duke përdorur të njëjtën metodë për të rregulluar pemët në qytet (Fig. 37) dhe jashtë (Fig. 38).

Oriz. 37. Bari dhe pemët në qytet

Oriz. 38. Bari dhe pemët e shpërndara jashtë qytetit

Shënim: për të kursyer burimet e kompjuterit, mund të vendosni objekte vetëm aty ku do të fluturojë kamera.

Eshte interesante!

Jo shumë kohë më parë, hasëm në një artikull interesant rreth zhvillimit të lojërave celulare duke përdorur Unity (datë 12 gusht 2015); megjithatë, avantazhi kryesor i artikullit është se ai e krahason këtë mjet me konkurrentin e tij kryesor: Unreal Engine.

Është me këtë studim të jashtëzakonshëm që ju ftojmë të takoheni të premten mbrëma. Në komente, do të jemi të lumtur të shohim rekomandime për botimin e librave rreth UE, dhe gjithashtu shpresojmë për një diskutim të frytshëm.

Artikulli është përkthyer me shkurtesa të vogla.

Ne (OnlineFussballManager GmbH) po fillojmë aktualisht zhvillimin e një projekti të ri për pajisjet mobile. Ne do të krijojmë një kombinim të varur dhe unik të strategjisë së bazuar në kthesa dhe lojës së menaxherit të futbollit.

Lojtarët do të jenë në gjendje të planifikojnë dhe krijojnë terrenet e tyre të klubit dhe objektet sportive, të stërvitin ekipin dhe të punojnë në taktikat e tij. Lojtarët e ekipit nuk do të jenë vetëm njësi në fanella me numra, por personalitete realiste me tiparet e tyre dhe madje edhe shprehjet e fytyrës. Gjithçka do të zhvillohet në një pamje izometrike të dhomave dhe zonave të ndryshme të klubit, ku ndërtesat e animuara do të vendosen në një rrjet të përcaktuar posaçërisht.

Pra, erdhi momenti i së vërtetës kur filluam të zhvillonim prezantimin vizual.
Duke marrë parasysh kërkesat e vendosura para nesh dhe faktin që duhet ta zhvillojmë këtë lojë si për iOS ashtu edhe për Android - si ta zbatojmë teknikisht këtë projekt?

Një nga pyetjet e para që duhej vendosur ishte nëse do të krijoni motorin tuaj apo do të përdorni një ekzistues. Sigurisht, opsioni i parë është optimal nëse doni të kontrolloni plotësisht gjithçka që ndodh në kodin tuaj burimor, zinxhirin e mjeteve dhe gjithashtu të keni një ide të mirë se cilat do të jenë të ardhurat tuaja nga kjo lojë. Disavantazhi i kësaj qasjeje është se një zhvillim i tillë do të kërkojë shumë përpjekje - për shkak të së cilës do të rriten kushtet e të gjithë projektit dhe do të rritet ndjeshëm në çmim. Ne e braktisëm shpejt këtë ide, pasi donim të mbanim koston dhe kohën e projektit brenda kufijve të arsyeshëm.

Sigurisht, mund të bëni shumë argumente se cili motor është më i mirë dhe për çfarë qëllimesh. Sa njerëz - kaq shumë mendime. Duhet të pranoj që në një moment kemi ndjerë edhe ne një subjektivitet të tillë. Ekipi ka mbështetur në mënyrë aktive Unreal Engine. Sidoqoftë, sado që e shikonim nga afër UE-në, askush nuk mund ta karakterizonte atë në mënyrë objektive, pa iu drejtuar mendimit personal.

Kështu, vendosëm të mos shpërqendroheshim nga faktet dhe filluam të eksploronim mjete të tjera, më të famshme.
GameMaker u refuzua shpejt pasi është më i orientuar drejt të ardhurve që sapo kanë filluar të zhvillojnë lojëra. Pra, është shumë e lehtë për t'u mësuar, por aftësitë e GameMaker nuk ishin qartësisht në nivelin e duhur.

Më pas erdhi radha e Cocos2D, e cila në pamje të parë dukej premtuese. Siç sugjeron emri, Cocos2D është optimizuar për zhvillimin e lojërave 2D. Pra, pyetja ishte nëse donim të krijonim rrjetin tonë izometrik të ndërtesave në 2D të vërtetë apo në 3D aktuale me një këndvështrim fiks. Pas disa kërkimeve shtesë, ne zgjodhëm një zbatim 3D. Në këtë rast, Cocos2D padyshim nuk na përshtatej.

Ne iu drejtuam Marmelatës. Në fund të fundit, me ndihmën e Marmalade lojëra të tilla të famshme si Plants vs. Zombies dhe Godus. Por, megjithëse gjetëm shumë avantazhe në këtë motor, mbetën probleme që na detyruan t'i drejtohemi opsioneve të tjera. Një nga të metat më të rëndësishme ishte se komuniteti i marmelatës është mjaft i vogël.

Pra, nga alternativat kryesore mbetën vetëm Unreal dhe Unity. Por edhe në këtë pikë, ne nuk mund të zgjidhnim me siguri një nga të dy pa ndihmë.

Për fat të mirë, konferenca e lojërave të GDC San Francisco po afrohej, kështu që ne shfrytëzuam rastin të fluturojmë atje dhe të konsultohemi me kolegët.

Ne u takuam me djemtë nga Epic, u njohëm nga afër me Unreal Engine, provuam Paper 2D, mjetin e tyre për të parë pamjet paraprake të aplikacioneve celulare dhe pyetëm se çfarë mund të përdornim: motorin e tyre apo Unity?

Djemtë na bënë të lumtur, duke thënë diçka si më poshtë: “Irreale është e lezetshme, por Uniteti nuk është as i keq. Provoni të dyja."

Më pas shkuam te zhvilluesit e Unity dhe hodhëm një vështrim më të afërt të Unity 5 - si përmirëson performancën në iOS. Në fund, ata i bënë të njëjtën pyetje dhe morën një përgjigje të ngjashme.

Në këtë fazë, ne vendosëm për një studim të plotë teknik. Ne projektuam një prototip që i ngjan shumë projektit tonë për të testuar në pajisje të ndryshme celulare se si do të shkojë procesi i ndërtimit dhe cila do të jetë performanca. Në të njëjtën kohë, ne gjithashtu donim të zbulonim se cilat gracka dhe probleme mund të na presin kur zhvillojmë motorët e parë dhe të dytë.

Meqenëse të gjithë programuesit tanë ishin të zënë me projektet aktuale, ne ia besuam punën për prototipin specialistëve të kompanisë Bit Baron.

Hulumtimi i motorit nga Bit Baron

Menaxheri Online Fußball (OFM) po planifikonte të krijonte një lojë celulare. Na është kërkuar ndihmë për të përcaktuar më mirë se cili motor është më i miri për projektin e tyre. Deri atëherë, ne ishim të angazhuar ekskluzivisht në zhvillimin e lojërave të shfletuesit, por vendosëm që të përballonim detyrën. U sugjerua të krahasohen dy opsione: Uniteti dhe Unreal. Aktualisht, këto janë dy "lokomotiva" në botën e programimit të lojërave. Ka shumë raporte që detajojnë ndryshimet delikate midis të dyve. Por e veçanta e punës sonë ishte se ne shkruam për krahasim dy aplikacione testimi pothuajse identike dhe karakterizuam performancën e tyre në përputhje me sistemin e pikave të kontrollit (benchmarking).

Duke shkruar dy aplikacione të ngjashme, ne ishim në gjendje t'i testonim të dyja në një fushë loje të sheshtë, t'i tregonim OFM-së se cili version funksiononte më mirë dhe të nxjerrim në pah çështje të tjera.

Rast testimi

Ne donim të krijonim një pikë referimi që do t'i siguronte OFM informacionin që lidhet drejtpërdrejt me llojin e lojës që ata po krijojnë. Klientët treguan se prototipi duhet të ketë disa ndërtesa dhe pemë të animuara. Prandaj, ne krijuam një skenë 3D ku përdoruesit iu kërkua të rregullonte në mënyrë të pavarur këto objekte në hartë. Rrjeti ishte 11x16 dhe strehonte deri në 176 ndërtesa. Çdo katror rrjetë mbështeti deri në 6 pemë, kështu që mund të kishte mbi 1000 pemë në një skenë. Ne shtuam një ndërfaqe të thjeshtë përdoruesi ku mund të shtoni një numër të caktuar pemësh dhe ndërtesash në skenë. Ne gjithashtu shtuam funksionin e shtimit të ndërtesave në vende specifike - për këtë ju duhej të klikoni në hartë në pikën e dëshiruar. Sa i përket organizimit të programit, ne ndërtuam një rrjet në një avion, dhe e pamë skenën përmes një kamere të vendosur "mbi kokën e përdoruesit". Ne kemi shtuar gjithashtu funksionalitetin e dedikuar të kamerës për t'i lejuar përdoruesit të zmadhojë dhe të zhvendosë skenën. Meqenëse ky prototip u krijua për të përcaktuar motorin për zhvillim, ne bëmë çmos që skena të dukej pothuajse e njëjtë në të dy versionet. Përndryshe, do të ishte e pamundur të krahasohej cilësia vizuale e opsionit të parë dhe të dytë. Më duhej të ndërhyja me të, pasi disa gjëra trajtohen ndryshe në Unreal dhe Unity. Ne përfunduam me dy skena shumë të ngjashme.

Për të unifikuar testimin e performancës, ne donim të aplikonim modele identike të pemëve dhe ndërtesave në të dy sistemet. Për pemët, u përdor një model i lëvizshëm SpeedTree, i cili përfshinte vetëm rreth 1000 poligone dhe bëri të mundur që të vlerësohej mirë se si rritjet e vogla në trekëndëshat e shfaqur ndikojnë në shpejtësinë e kuadrove. Për ndërtesat e animuara, ne nuk mund të gjenim një model për to që të funksiononte me të dy motorët, kështu që përdorëm dy modele të ndryshme. Të dy ishin të përmasave për pak më shumë se 16,000 poligone secili dhe kishin cilësime materiale pothuajse identike. Ne i çaktivizuam plotësisht nivelet e detajeve (LOD) në mënyrë që në të dy opsionet të shfaqet i njëjti numër trekëndëshash në çdo distancë nga kamera. Standardi u krijua jo vetëm për të pasqyruar ndryshimet e performancës midis dy motorëve, por edhe për të treguar ndryshimin në cilësinë e paraqitjes. Më duhej gjithashtu të mbaja një sy të ngushtë në shaders standarde të Unreal Engine. Duke vënë re se Unreal po dukej qartësisht më mirë, zbuluam se kishte një numër shaderash në kamerë që ishin të shtrenjta për sa i përket performancës. Pas fikjes së tyre, skena vizualisht mbeti pothuajse e pandryshuar. Ndriçimi ishte një problem shumë i ndryshëm, kështu që na u desh pak kohë për ta rregulluar atë siç duhet.

Klientët ishin të interesuar jo vetëm për kryerjen e testeve, por edhe se si do të ishin përshtypjet e zhvillimit në motorët e parë dhe të dytë. Në fund të fundit, cili është kuptimi i performancës nëse nuk keni kohë ta shkruani lojën në kohë. Për të kapur këto përshtypje, ne krahasuam faktorë të tillë si koha e ndërtimit, dokumentacioni i disponueshëm, kompleksiteti i vendosjes në një mjedis celular dhe kompleksiteti i përsëritjes mbi kodin. Ne besuam se ishte pikërisht në këto tregues që Unity do të ishte më i fortë (si një flamurtar në fushën e zhvillimit të lojërave celulare).

Projekti i Unitetit

Prototipi në unitet. Ka 200 pemë në hartë

Mirë

• Elementet thelbësore të Unitetit janë Objektet ("Objekti i lojës") dhe Komponentët ("MonoSjellja"). Pasi të keni zotëruar këtë koncept, tashmë mund të punoni me Unity. Nëse përdoret si duhet, ky sistem mund të përmirësojë ndjeshëm organizimin e një projekti.
• Unity përfshin shumë komponentë që ju ofrojnë gjithçka që ju nevojitet për të krijuar një lojë - përveç vetë logjikës së lojës. Siç u tha më lart, një komponent mund të jetë aq i vogël sa Plani (i padisponueshëm në Unreal), të cilin e përdorëm për të gjeneruar rrjetë. Shtesat më të fundit në motor janë komponentët "UI" dhe "Layout", të cilët ofrojnë ndërfaqe grafike të fuqishme dhe të shkallëzueshme të përdoruesit.
• Redaktori mund të zgjerohet me skriptet tuaja, përveç kësaj, Dyqani i Aseteve ka mijëra burime për të gjitha rastet. Dyqani i Aseteve përmban gjithashtu shumë skripta të dobishëm, modele materiale dhe më shumë. Këto do të jenë veçanërisht të dobishme për krijimin e prototipit - thjesht mund të ngarkoni gjithçka që ju nevojitet si burime të përkohshme dhe ta përdorni si një model simulimi të dobishëm.
• Unity ishte një nga motorët e parë me burim të hapur për të mbështetur zhvillimin e celularëve. Prandaj, është shumë i përshtatshëm kur vendoset në një mjedis celular, duket dhe vepron atje në të njëjtën mënyrë si në redaktues. Sistemi po përmirësohet vazhdimisht dhe vendosja po ecën shumë mirë. Ky ishte një faktor domethënës në të cilin vendosëm të bënim një prototip celular.
• Unity është padyshim komuniteti më i madh i çdo motori të lojës, kështu që nëse keni një pyetje, shanset janë që të ketë një përgjigje. Ndërsa Unity mbështet shumë gjuhë skriptimi, dokumentacioni për secilën është shumë solid. Për më tepër, edhe nëse gjeni një përgjigje në lidhje me një gjuhë tjetër, logjika e kësaj përgjigje do të jetë gjithsesi e qartë për ju dhe ju mund ta përshtatni atë për të zgjidhur problemin tuaj.
• Unity ka bërë një punë të jashtëzakonshme për të optimizuar paraqitjen për shumë objekte të të njëjtit lloj. Për të arritur performancë të krahasueshme në Unreal, do të duhet të përdorni Rendering Instanced, dhe ky mekanizëm është zakonisht më pak fleksibël sesa interpretimi në Unity.

E keqe

• Motori është me burim të mbyllur. Nëse po flisni me Unity për çmimin e kodit burimor, atëherë duhet të jetoni me të. Prandaj, problemet janë të mundshme nëse një ose një veçori tjetër në të cilën mbështeteni dështon - do t'ju duhet të prisni për përditësimin.
• Sistemi i ri UI është mjaft i mirë. I mungon një redaktues special, të gjitha ndryshimet bëhen direkt në skenë - dhe skena është shumë e madhe. Kur hapni një skenë dhe dëshironi të redaktoni ndërfaqen e përdoruesit, së pari duhet të rritni shumë zonën e interesit.

Kjo është një foto nga redaktori i Unity. Jemi shumë me fat që mundëm ta plotësojmë me skenarët tanë.

E tmerrshme

• Ka dy probleme me sistemin e ri UI në Unity. Kur shtypni gishtin në ekranin me prekje, nuk do të jeni në gjendje të përcaktoni nëse është shtypur një grafik i caktuar. Le të themi se përdoruesi dëshiron të lëvizë ekranin duke përdorur një rrëshqitës. Por nëse trashëgojmë nga klasa GraphicsRaycaster, atëherë mund të hapim çdo të dhënë të dëshiruar që mund të bëhet publike. Nëse zëvendësoni GraphicsRaycaster në objektin e kanavacës, mund të kontrolloni nëse është klikuar elementi UI.
• Problemi i dytë me ndërfaqen e përdoruesit të Unity ka të bëjë me shkallëzimin në madhësi të ndryshme të ekranit. Në thelb një objekt kanavacë ka opsione shkallëzimi me disa parametra. Por organizimi i pamjes paraprake të tyre ishte shumë i vështirë, na u desh ta vendosnim aplikacionin në pajisje disa herë derisa të gjenim një konfigurim normal.
• Gjithashtu, ne ishim shumë të hutuar nga paneli i statistikave të Unity. Pasi kemi zbatuar një numërues të shpejtësisë së kornizës në lojë, ne krahasuam vlerën e tij me atë që u shfaq në panelin e statistikave të redaktorit të Unity. Këto vlera ishin të ndryshme. Pasi kërkuam në internet për opsione të tjera zbatimi, gjetëm përgjigjen: paneli statistikor jep një vlerësim se sa korniza do të kalonte loja nëse do të funksiononte në mënyrë autonome, dhe jo në redaktues. Prandaj, logjika e numëruesit tonë të kornizës ishte krejtësisht e saktë.

Vlerat e shpejtësisë së kornizës janë 37 kundrejt 32. Në panelin e statistikave të Unity, shohim vlerësime për aplikacionin e pavarur, të cilat nuk përputhen me ato reale.

Projekt joreal

Kështu duket projekti në redaktorin Unreal. Këtu ka shumë redaktorë të specializuar të ndërthurur, disa prej të cilëve janë të krahasueshëm në funksionalitet me programe të tëra.

Në UE, e njëjta pamje e ekranit u mor si në Unity (shih më lart), me cilësimet e celularit të mbetura si parazgjedhje, pa ndezur pemët

Kur cilësimet u rregulluan, pemët dolën më mirë, por ende jo aq të mira sa në Unity.

Mirë

• Prova Unreal është plotësisht falas. Këtu ju merrni një redaktues plotësisht funksional. Unity ka gjithashtu një version falas, por shkuarja në Pro do t'ju kushtojë një qindarkë të bukur.
• Unreal ka një redaktues të fuqishëm që përmban disa redaktorë shumë të specializuar. Nëse jeni të njohur me këta redaktorë "të mbivendosur", atëherë ata do t'ju ndihmojnë shumë me zhvillimin dhe shpesh ofrojnë informacione që nuk do t'i shihni në Unity. Ka redaktorë që mund të shërbejnë edhe si zëvendësim i plotë për disa programe. Ndërveprimi i të gjitha këtyre nënsistemeve është një kryevepër.
• Motori vjen me të gjithë kodin burimor. Prandaj, mund të gërmoni në të dhe të kuptoni se si funksionojnë pjesët individuale. Për më tepër, madje mund të rregulloni gabimet në motor ose të plotësoni vetë funksionalitetin e tij.
• Vizualizimi në redaktues është i shkëlqyeshëm. Thjesht, sytë shkojnë nga bollëku i opsioneve të interpretimit (të lidhura, për shembull, me ndriçimin ose me kompleksitetin e shaderëve). Këtu do të gjeni shumë shadera të fundit që vijnë edhe me motorin. Në thelb, Unreal ofron motorin më të mirë të riprodhimit në treg. Ju mund të krijoni skena jashtëzakonisht të bukura.
• Planet janë të dobishme për krijimin e shpejtë të diçkaje të thjeshtë dhe zbatimin e logjikës bazë të lojës. Ata integrohen në mënyrë të përsosur me C ++, dhe ky vendim u mor për një arsye: jo vetëm që hap mundësi të jashtëzakonshme si për fillestarët ashtu edhe për zhvilluesit me përvojë, por gjithashtu i lejon ata të ndërveprojnë me njëri-tjetrin.
• Integrimi i përgjithshëm me C ++ është i shkëlqyeshëm. Si dhe një rindezje e nxehtë.

Vizatimet janë të shkëlqyera për detyra të thjeshta dhe integrimi i tyre me C ++ është fantastik. Por nëse përfshihet një logjikë më komplekse, ato shpejt bëhen të rrëmujshme dhe të vështira për t'u përballuar.

E keqe

• Është e vështirë të rritet ritmi kur zhvillohet me Unreal Engine. Edhe nëse e njihni mirë C ++, do të duhet shumë kohë për të mësuar makrot dhe funksionet e ndryshme të UE4. Kjo mund të jetë shumë e vështirë për dikë që po mëson C ++ në të njëjtën kohë.
• Vizatimet mund të ngatërrohen shumë shpejt. Kur logjika përfshin dhjetëra nyje, secila prej të cilave përmban një plan, ndonjëherë mund të thjeshtohet në disa rreshta kodi të shkruar në C ++ të thjeshtë. Zakonisht ky nuk është problem, pasi është mjaft e mundur të punohet me C ++, por me disa gjëra, për shembull, "UMG" (sistemi UI), është e nevojshme të përdoren vizatime, kështu që mund të jetë konfuze.
• Simulatori celular doli të ishte shumë i paqëndrueshëm. Ai dha paralajmërime kur ne u përpoqëm të përdornim funksione shader që nuk përdoren në mjedisin celular, por edhe nëse shader kalon verifikimin, mund të mos funksionojë. Në thelb, ky imitues është një gjë e mirë, por cilësitë e tij vizuale lënë shumë për të dëshiruar.
• Megjithëse Unreal ka një komunitet të madh zhvilluesish, ne rrallë kemi marrë përgjigje për pyetjet atje. Përveç kësaj, pothuajse e gjithë mbështetja që morëm ishte në projekte. Unreal Engine 4 po zgjeron në mënyrë aktive komunitetin, tashmë po ecën mirë, duket se specialistët janë të etur për të zhvilluar dhe ndihmuar. Por komuniteti Unity është akoma më i mirë.

E tmerrshme

• Dokumentacioni C ++ mungon seriozisht. Materiali i referencës në internet për klasat C ++ është i vështirë. Për më tepër, për shkak të përditësimeve të vazhdueshme, shumë veçori bëhen shpejt të vjetëruara. Kini kujdes kur shikoni videot e ndihmës, pasi ato mund të përshkruajnë një version të vjetëruar të motorit dhe funksione që nuk përdoren më.
• Duke punuar me GUI, ne përdorëm sistemin inovativ "UMG". Ai bazohet në projekte dhe mund të jetë shumë i dobishëm. Me pak punë, arritëm të trashëgojmë klasën C ++ dhe të pastrojmë pak renditje me vizatimet. Megjithatë, sistemi është ende i papërpunuar, i mungojnë disa kontrolle si butonat e ndërrimit. Për më tepër, praktikisht nuk ka dokumentacion përkatës C ++. Redaktori ra disa herë ndërsa ne po zhvillonim UI. Dështimet e papritura mund të kushtojnë orë të tëra pune dhe janë mjaft shqetësuese. Zhvillimi i këtij sistemi vazhdon, por deri më tani ai është larg të qenit i përsosur.
• Zhvillimi i celularit me Unreal është i ngadaltë. Programi kërkon shumë kohë për t'u vendosur në pajisje. Android kishte disa probleme vizuale si skica të paqarta dhe pemë të pandritura. Në iOS, problemet ishin shumë më serioze. UE4 mbështet ndërtimin për një pajisje iOS vetëm nëse aplikacioni juaj përbëhet vetëm nga projekte. Ky është faji i Apple, por ne kaluam deri në fund importimin e çelësave të zhvillimit (mund ta imagjinoni) përpara se të hasim këtë problem. Në iOS, teksturat e pemëve të ndërtuara në bazë të SpeedTree nuk shfaqeshin, pemët ishin gri dhe të zhveshura, pa gjethe. Pra, mbështetja e Unity për zhvillimin e celularëve është një përmirësim i madh në krahasim me Unreal.

Rezultatet e krahasimit. Shpejtësia e kornizës

Çuditërisht, kur testuam shpejtësinë e kuadrove (FPS) në pajisje të ndryshme, morëm rezultate shumë të ndryshme. Në disa pajisje, Unity fiton me çdo konfigurim. Në raste të tjera, Unreal mundi Unity në teste ku kishte shumë ndërtesa. Në parim, Unreal fitoi, por me një kosto të lartë. Cilësia dhe qëndrueshmëria e imazhit ishin dukshëm më të mira në Unity. Teksturat joreale në disa pajisje dukeshin të paqarta, pemët dolën shumë më keq. Dallimi në cilësi ishte pjesërisht për shkak të asaj që shfaqet nga njëra anë në redaktorin Unreal dhe pamjen paraprake të celularit, dhe nga ana tjetër në një telefon celular të vërtetë. Ky problem ishte veçanërisht i dukshëm kur bëhet fjalë për ndriçimin e skenës. Ishte shumë e vështirë për të zgjedhur cilësimet në mënyrë që të rregulloje siç duhet dritën, i gjithë cilësimi në pajisjet celulare shpesh dukej i errët. Në këtë drejtim, Unity ishte shumë më i qëndrueshëm, imazhi në çdo telefon inteligjent ishte i njëjtë si në pamjen paraprake në redaktues.

Rezultatet për të dy motorët doli të ishin shumë më të mira nga sa prisnim (siç e mbani mend, në modelet tona të testimit kishte rreth 10 herë më shumë trekëndësha sesa në lojërat e zakonshme celulare).

Në iOS, të dy motorët dhanë modele të animuara me sukses afërsisht të barabartë. Megjithatë, testet me pemë në këtë pajisje ishin të pasuksesshme, pasi Unreal nuk shfaqi asnjë teksturë në modelet e pemëve. Ne u përpoqëm të gjenim shkakun e këtij modeli, por nuk mundëm ta zgjidhnim atë. Përveç kësaj, duhet të theksohet se kur vendosni duke përdorur këta motorë, duhet të keni në dorë një kompjuter Apple. Kjo është shumë e papërshtatshme, por vetë Apple është fajtori për këtë situatë. Klientët na kërkuan gjithashtu të bëjmë standarde në Windows Phone. Fatkeqësisht, Unreal nuk i mbështet ende vendosjet në telefonin Windows, kështu që Unity fitoi këtu sipas definicionit. Meqenëse Windows Phone ka ende një pjesë shumë të vogël të tregut, zhvillimi i Unreal në këtë drejtim nuk konsiderohet prioritet.

Në fund të fundit, testimi standard tregoi vetëm se të dy motorët ishin pothuajse të barabartë në forcë. Prandaj, është veçanërisht e rëndësishme t'i kushtohet vëmendje avantazheve dhe disavantazheve specifike të secilit prej tyre. Në fund, nëse performanca është kaq afër, atëherë komoditeti dhe shpejtësia e zhvillimit për secilin prej këtyre motorëve dalin në pah.

Parametra të tjerë të kontrollit

Këtu janë disa rezultate më interesante që kemi arritur t'i zbulojmë gjatë testeve tona:

• Të dy motorët vështirë se ndryshonin në konsumin e memories. Në pajisjet Android, Unity kishte performancë më të mirë, në pajisjet iOS, Unreal.
• Projekti Unity është dukshëm më i vogël (Android: 42 MB / iOS: 100 MB) se projekti Unreal (Android: 101 MB / iOS: 173 MB).
• Unity është rreth tre herë më i shpejtë për t'u vendosur në një pajisje. Për më tepër, Unity përpilon kodin shumë më shpejt.
• Unreal e shpenzoi baterinë dukshëm më ekonomikisht. Pas dy orësh punë me 150 modele të animuara në ekran, Unreal arriti të shkarkojë baterinë e Android me 42 për qind dhe iOS me 36 për qind. Unity konsumoi afërsisht 72 për qind në Android dhe 47 për qind në iOS me të njëjtin konfigurim dhe kohë pune.

konkluzionet

Bazuar në rezultatet e hulumtimit, na pëlqyen shumë për të dy motorët. Përveç kësaj, ne gjetëm shumë fusha ku këto mjete mund të përmirësohen për ta bërë programuesin më të rehatshëm për të punuar. Asnjë motor nuk kishte një avantazh të rëndësishëm mbi tjetrin duke pasur parasysh se sa shpejt ndryshuan aftësitë dhe mbështetja e tyre. Testet e paraqitjes kanë treguar se të dy produktet shtrydhin maksimumin nga pajisja dhe, në parim, janë mjaft të krahasueshëm. Përsëri, këtu dalin në pah përdorshmëria dhe intuita e dizajnit. Duke marrë parasysh gjithçka që mësuam për këta motorë, dhe çfarë problemesh u përballëm gjatë zhvillimit, u përballëm me një zgjedhje të vështirë, por në fund zgjodhëm Unity.

Përkundër faktit se fillimisht ishim bast për fitoren e Unreal Engine, aktualisht Unity është ende një opsion më fitues, të paktën kur bëhet fjalë për zhvillimin e lojërave celulare.

Këtu janë arsyet kryesore për vendimin tonë:

• Unity është vizualisht më i qëndrueshëm në të gjitha pajisjet dhe vendoset shpejt me një klikim në çdo platformë.
• Unity zë shumë më pak hapësirë ​​në pajisje dhe ka më pak ndikim në përvojën e përdoruesit fundor. Madhësia kompakte është veçanërisht e rëndësishme në Dyqanin e Google Play, ku APK duhet të ndahet nëse skedari është më i madh se 50 mb.
• Uniteti është shumë më i lehtë për t'u mësuar dhe kuptuar. Të armatosur me Unity, përdoruesit e papërvojë mund të funksionojnë më shpejt dhe të ndërtojnë produkte të mbështetur nga një komunitet i madh ekspertësh.
• Koha e përsëritjes në Unity është shumë më e shkurtër (vendosja dhe përpilimi i kodit burimor është më i shpejtë, shaderat përpilohen pothuajse menjëherë)

Ne dëshirojmë të theksojmë se rezultatet tona duhet të konsiderohen në kontekstin e prototipit të bërë. Ajo që funksionon për një kompani nuk funksionon për një tjetër. Përveç kësaj, ka shumë më tepër motorë lojërash, disa prej të cilëve mund të jenë më të përshtatshëm për detyrën tuaj specifike. Në disa kompani me kohë dhe burime të mjaftueshme, mund të jetë edhe më e përshtatshme për të shkruar motorin e tyre. Nuk ka asnjë zgjidhje të vetme për të gjithë në zhvillimin e lojës. Bëjini vetes një nder dhe eksperimentoni mirë. Për më tepër, shumë prej tyre bëhen më të lira apo edhe shareware si Unreal. Ne nuk do të habiteshim nëse Unity gjithashtu ndjek shembullin e Unreal dhe liberalizon modelin e tij të çmimeve.

konkluzioni

Është interesante të theksohet se djemtë nga Bit Barons na këshilluan të merrnim Unreal Engine për projektin tonë përpara se të bëni prototip. Duke marrë parasysh që edhe ne në OFM fillimisht preferuam Unreal Engine, ndoshta zgjidhja përfundimtare doli të ishte jooptimale.

Natyrisht, nuk është e lehtë të hartosh, të shkruash dhe të testosh një prototip, veçanërisht nëse thjesht duhet të vendosësh për motorin për projektin. Por çështja e një zgjedhjeje të tillë është jashtëzakonisht e rëndësishme.

Së fundi, morëm parasysh disa faktorë të tjerë që mund të ndryshonin opinionin tonë. Domethënë: sa e lehtë është të gjesh talent me përvojë për secilin motor në ditët e sotme, dhe cilat janë modelet e biznesit në dispozicionin tuaj?

Për çështjen e personelit, ne u konsultuam me rekrutues me përvojë për të zbuluar pak a shumë numra realë. Aktualisht ka afërsisht katër Profesionistë të Unitetit për çdo Specialist Unreal. Për sa i përket modelit të biznesit, Unreal nuk parashikon një tarifë fillestare të sheshtë, por kërkon tarifa licencimi. Në Unity, e kundërta është e vërtetë. Të dy këta faktorë ishin të rëndësishëm për ne, dhe si rezultat ne përfunduam duke u vendosur te Uniteti.

Pra, duke ndërtuar një bazë në strategji. Parametrat që përfshihen në këtë proces mund të jenë shumë të ndryshëm. Ndoshta ari ose minerale, disponueshmëria e energjisë, e kështu me radhë. Çdo projekt mund të ketë diçka individuale, megjithatë, e përbashkët për të gjithë është vetë ndërtimi, domethënë rregullimi i objekteve në një zonë të caktuar. Çfarë duhet të bëjmë? Së pari, ne kemi një grup ikonash, secila përfaqëson një ndërtesë. Kur klikoni në ikonën, marrim një bosh objekti, i cili mund të zhvendoset përgjatë planit XZ. Së dyti, duhet të siguroheni që nuk mund të krijohen ndërtesa të reja aty ku tashmë ka një ndërtesë dhe ku është e ndaluar të ndërtohet ndonjë gjë.

Ky opsion është i përshtatshëm vetëm për 3D; për një projekt dydimensional, duhet të ribëni transmetimin e rrezeve dhe rrafshin e lëvizjes së objekteve.

Trajnimi. Krijimi i vetë ndërtesave, modele ndërtimi. Si do të animohen dhe kështu me radhë nuk është e rëndësishme, modeli kryesor duhet të jetë nën përplasës, kjo është e nevojshme jo vetëm për ndërtimin, por edhe për krijimin e një harte navigimi të robotëve. Për shembull:

Përplasësi duhet të mbulojë të gjithë objektin.

Pas krijimit të strukturës kryesore, ne bëjmë një kopje të saj dhe zëvendësojmë materialin. Kjo do të thotë, detyra është të krijoni një pamje paraprake të ndërtesës së ardhshme. Në çdo strategji, ne fillimisht zvarritim dhe lëshojmë planimetrinë e ndërtesave, zakonisht duke i bërë ato gjysmë transparente. Meqenëse ky është një plan urbanistik, atëherë mbi të ne heqim animacionin nëse ka dhe zgjedhim pamjen, për shembull:

Po kështu, objekti duhet të mbyllet nga përplasësi, por në modalitet Është shkas... Në këtë rast, përplasësi i paraqitjes mund të bëhet pak më i madh se origjinali, për shembull +0.1, kjo do të rrisë ndjeshmërinë dhe do të sigurojë që është e pamundur të krijohet një objekt mbi tjetrin. Të gjitha paraqitjet duhet të kenë të instaluar shtresën Injoro Raycast! Për më tepër, ne varemi në model Trup i ngurte dhe fik gravitetin. Plus, ne mbyllim një skenar të vogël MaskControl:

Përdorimi i UnityEngine; duke përdorur System.Collections; Klasa publike MaskControl: MonoSjellja (string publik respawnTag = "Respawn"; Fillimi i pavlefshëm () (DragAndDrop.isOn = i vërtetë;) i pavlefshëm OnTriggerStay (Collider coll) (if (coll.tag! = respawnTag) (DragAndDrop;O) falseis. ) void OnTriggerExit (Collider coll) (if (coll.tag! = respawnTag) (DragAndDrop.isOn = e vërtetë;)))
Qëllimi i këtij skripti është të përcaktojë se ku mund të instalohet objekti dhe ku jo. Në një variabël respawnTag ne specifikojmë një etiketë që lejon instalimin. Për shembull, nëse bëni një aeroplan me një etiketë, atëherë ndërtesa mund të ndërtohet vetëm në këtë zonë dhe nëse objekti pengohet në ndërtesa të tjera, ai do të bllokohet automatikisht. Në përgjithësi, gjithçka është e njëjtë si një strategji konvencionale.

Më pas, emrat e ndërtesave. Parafabrikat origjinale të ndërtesës janë emëruar kështu id_xxx, domethënë - numri, nënvizimi, emri. Parafabrikat e paraqitjes, të emërtuar saktësisht të njëjtë, numrat origjinalë dhe të paraqitjes - duhet të përputhen, dhe emrat mund të ndryshojnë.

Tani e varim skenarin në një objekt bosh Tërhiq dhe lësho:

Përdorimi i UnityEngine; duke përdorur System.Collections; duke përdorur Sistemin; klasa publike DragAndDrop: MonoSjellje (transformim publik origjinal; maskë e transformimit publik; zhvendosje publike float = 0.01f; varg publik respawnTag = "Respawn"; bool statike publike isOn; Transformim privat original_tmp; privat Transform mask_tmp; privat Vector3 curPos; Fillimi i pavlefshëm () (isOn = false;) publik void SetMask (int id) (foreach (Transformo obj në origjinal) (emri i vargut = obj.name.Split (karakter i ri ("_"), StringSplitOptions.RemoveEmptyEntries); nëse (id.ToString ( ) == emri) (origjinal_tmp = Instantoj (obj); original_tmp.gameObject.SetActive (false);)) foreach (Transformo obj në maskë) (emri i vargut = obj.name.Split (karakter i ri ("_"), StringSplitOptions .RemoveEmptyEntries); if (id.ToString () == emri) (mask_tmp = Instantiate (obj);))) Void Update () (RaycastHit goditi; Ray ray = Camera.main.ScreenPointToRay (Input.mousePosition); nëse ( Physics.Raycast (ray, out hit)) (curPos = hit.point + hit.normal * shift;) if (mask_tmp) (mask_tmp.position = curPos; if (Input.GetAxis ("Mouse ScrollWheel")> 0) (mask_tmp.localEulerAngles + = Vector3 i ri (0, 45, 0); ) if (Input.GetAxis ("Mouse ScrollWheel")< 0) { mask_tmp.localEulerAngles -= new Vector3(0, 45, 0); } if(Input.GetMouseButtonDown(0) && isOn) { original_tmp.gameObject.SetActive(true); original_tmp.position = mask_tmp.position; original_tmp.localEulerAngles = mask_tmp.localEulerAngles; original_tmp = null; isOn = false; Destroy(mask_tmp.gameObject); } else if(Input.GetMouseButtonDown(1)) { Destroy(original_tmp.gameObject); Destroy(mask_tmp.gameObject); } } } }
origjinale- një sërë të gjitha parafabrikat me modele ndërtimi origjinale.

maskë- një grup i të gjitha parafabrikave të paraqitjes.

zhvendosje- zhvendosje përgjatë boshtit Y për modelin.

respawnTag- etiketa e avionit në të cilin lejohet ndërtimi.

Ju duhet të shtoni disa në skenë. UI elementet, më saktë ikonat, GameObject> UI> Image. Ne krijojmë numrin e kërkuar të ikonave dhe i vendosim sipas nevojës. Pastaj, për secilën ikonë duhet të shtoni një komponent Shkaktësi i ngjarjes, zgjidhni funksionin Klikoni me tregues dhe më pas tërhiqni objektin e skriptit DragAndDrop në fushën aktive dhe zgjidhni funksionin e skriptit nga menyja - SetMask dhe tregoni numrin e paraqitjes. Për shembull:

Kjo do të thotë, çështja është që secila ikonë korrespondon me një model specifik, kështu që ne caktojmë numra. Në lojë, klikoni në ikonën - dërgoni numrin në skenar - gjen modelin përkatës. Kështu funksionon.

LMB në ikonën - merrni një plan urbanistik të ndërtesës. LMB e përsëritur - instaloni ndërtesën. RMB - anuloni. Rrota e miut - rrotullohet.