Pelimoottoreista keskustelua (Unreal Engine, Unity, Source, jne)

[Jean_Sipulius]

Täällä keskustelua nykyisistä pelimoottoreista ja niihin liittyvistä ongelmista sekä tulevista päivityksistä. Millaisia pelimoottoreita porukka käyttää? Onko isoja projekteja työn alla? Mitä pelimoottoria käytätte? Aloituspostaajalla käytössä Unreal Engine ja yksi isompi VR-projekti on työn alla. Projektin aikana on oppinut todella paljon erilaisia kikkoja joilla suorittaa toimenpiteitä.

Viime aikoina opettelussa on ollut animaatiot sekä tekoälyohjelmointi. Täytyy sanoa, että olen suorastaan häkeltynyt Unreal Enginen Persona-animaatioeditoriin. Ohjelmoijalla on käytännössä 100% hallinta mihin tahansa rigattuun 3D-malliin. Vaikka jotain animaatiota ei olisi tehty valmiiksi, sen voi helposti pakottaa/feikata animaatioeditorin avulla. Luiden välinen kinematiikka on täysin hallittavissa.

Olen mielelläni yhteydessä muihin peliohjelmoijiin tai 3D-mallintajiin pelin tiimoilta.

 

[MagGyver69]

Olen tehnyt Unitylla 2 pientä peliä (matopeli sekä breakout -klooni) ja kolmas peli etenee hitaasti. Nämä olen kaikki tehnyt Unityn Linux editorilla, joka on vielä beta -vaiheessa. Linux versio oli vielä puolisen vuotta sitten täynnä pahoja bugeja, mutta nykyään toimii jo mukavasti.

 

[Gorilla]

Koska tämä lienee tagien perusteella henkistä jatkoa "Peliohjelmointi"-threadille, niin:

Oma moottori sen olla pitää.
Itsellä työn alla hilpeä oldschool rävellys, josta varmaan tulen mesoamaan tännekin, jahka valmista.

Netistä dyykatut assetit, purkkaviritelty asset conditioning pipeline, mahdollisimman alusta laadittu, old-school hengessä.

Edit: Ja tosiaan. 100% freeware värkki kyseessä. Ei minkäänlaista rahallista tavoitetta.

 

[JoksuPoksu]

Olen tehnyt Unitylla 2 pientä peliä (matopeli sekä breakout -klooni) ja kolmas peli etenee hitaasti. Nämä olen kaikki tehnyt Unityn Linux editorilla, joka on vielä beta -vaiheessa. Linux versio oli vielä puolisen vuotta sitten täynnä pahoja bugeja, mutta nykyään toimii jo mukavasti.

Mielenkiintoista... Omasta kokemuksestani Unityn Linux-editori on vieläkin täynnä pahoja bugeja, jotka tekevät siitä epämielyttävän käyttää. Vaikkakaan tilanne ei ole todellakaan enää niin paha, kuin puoli vuotta sitten.

 

[muzzy]

Unityllä pääsee ainakin hemmetisti nopeammin alkuun kuin itse väkertämällä engineä, ja tämä voi olla merkittävä ero siinä että tuleeko projektista ikinä yhtään mitään vai ei. Vaikka projektin loppuvaiheilla miten kiroaisi Unityä ja niitä kapuloita mitä se heittelee rattaisiin siinävaiheessa kaikilla ongelmillaan, on se projekti ainakin päässyt sinne asti toisin kuin se oma engine joka kaatuu GUI-subsysteemin kirjoitteluun ennenkuin se itse peliosuus edes toimii.

 

[JoksuPoksu]

Unityllä pääsee ainakin hemmetisti nopeammin alkuun kuin itse väkertämällä engineä, ja tämä voi olla merkittävä ero siinä että tuleeko projektista ikinä yhtään mitään vai ei. Vaikka projektin loppuvaiheilla miten kiroaisi Unityä ja niitä kapuloita mitä se heittelee rattaisiin siinävaiheessa kaikilla ongelmillaan, on se projekti ainakin päässyt sinne asti toisin kuin se oma engine joka kaatuu GUI-subsysteemin kirjoitteluun ennenkuin se itse peliosuus edes toimii.

No siis se, että käyttääkö valmista pelimoottoria vai ei, on hyvin tapauskohtaista. Joskus yksinkertaista peliä tehtäessä, on mukava päästä eroon valmiiden pelimoottorien turhista ominaisuuksista, jotka vievät tehoa ja tilaa.

 

[Gorilla]

Unityllä pääsee ainakin hemmetisti nopeammin alkuun kuin itse väkertämällä engineä, ja tämä voi olla merkittävä ero siinä että tuleeko projektista ikinä yhtään mitään vai ei. Vaikka projektin loppuvaiheilla miten kiroaisi Unityä ja niitä kapuloita mitä se heittelee rattaisiin siinävaiheessa kaikilla ongelmillaan, on se projekti ainakin päässyt sinne asti toisin kuin se oma engine joka kaatuu GUI-subsysteemin kirjoitteluun ennenkuin se itse peliosuus edes toimii.

Yleisesti ottaen totta.
Mutta helvetin hieno kokemus se on väkertää jotain alkeista, vaikkei se tietenkään ole kilpailukykyinen oikein minkään kanssa.

 

[muzzy]

Joskus yksinkertaista peliä tehtäessä, on mukava päästä eroon valmiiden pelimoottorien turhista ominaisuuksista, jotka vievät tehoa ja tilaa.

Ja sitten sitä kiroaa kun haluaisi jonkun jutun joka kaupallisella pelimoottorilla veisi 5min mutta itse kun tekee niin siihen menee pari päivää. Vielä pahempi jos sen valmiiksi saamisen jälkeen se ei tunnukaan niin hyvältä kun sen näkee sitten toiminnassa. Nopea prototyypitys on valmiiden engineiden vahvuuksia, mutta onhan sillä toki hintansa. Olenpa myös kuullut että jotkut tekevät Unityllä prototyypin ja sitten heittävät sen Unityn syrjään ja koodaavat pelin kasaan jollain ihan muulla...

Yleisesti ottaen totta.
Mutta helvetin hieno kokemus se on väkertää jotain alkeista, vaikkei se tietenkään ole kilpailukykyinen oikein minkään kanssa.

Oppiihan siinä paljon kun tekee asiat itse ja voi tuntua palkitsevammalta, mutta huonona puolena on se että asiat todellakin pitää sitten tehdä itse.

Ja voihan sitä omaa engineäkin tehdä monella tasolla. Ihan täysin tyhjästä kun aloittaa niin palaa hermot jo siinävaiheessa kun haluaisi sen "Hello World":n ruudulle ja tajuaa että olisi ehkä sittenkin pitänyt ottaa frameworkki jossa olisi valmiiksi edes bitmapfonteille ja kuvien lataamiselle tuki. Harvempi masokisti kuitenkaan tekee sitä omaa pelimoottoriaan ihan kokonaan itse kuvaformaattien lukemisesta lähtien, siinä voi sitten ottaa juuri sen verran kompromisseja valmiiden kirjastojen käytön suhteen kuin vain itse haluaa.

 

[Gorilla]

Ja voihan sitä omaa engineäkin tehdä monella tasolla. Ihan täysin tyhjästä kun aloittaa niin palaa hermot jo siinävaiheessa kun haluaisi sen "Hello World":n ruudulle ja tajuaa että olisi ehkä sittenkin pitänyt ottaa frameworkki jossa olisi valmiiksi edes bitmapfonteille ja kuvien lataamiselle tuki. Harvempi masokisti kuitenkaan tekee sitä omaa pelimoottoriaan ihan kokonaan itse kuvaformaattien lukemisesta lähtien, siinä voi sitten ottaa juuri sen verran kompromisseja valmiiden kirjastojen käytön suhteen kuin vain itse haluaa.

Joo.
Ihan "alusta" tekeminen alkaa tänä päivänä olemaan jo käytännöllisyyden tuolla puolen, jos puhutaan yhtään suuremmasta takeleestä.

Alla uteliaimmille hieman omasta värkistäni.

Spoileri

Itse päädyin lähinnä ulkoistamaan:

Online:

- Grafiikka-Api.
Tämä ladataan ajon aikana .dll:nä, ( Oikeastaan mikä vain dynaamisesti ladattava .dll kaltainen kelpaa eri alustoilla ) jonka sisältö käytännössä toteuttaa oman iGraphicsDevice rajapinnan. Ensimmäisenä toteutuksena DirectX11.

- Fysiikkakirjasto.
Toimii jokseenkin samoin kuin grafiikka-apikin. Toteuttaa iPhysicsDevice rajapinnan. Lähdin aluksi Bulletilla liikkelle.

- Äänikirjasto.
Sama tarina. iAudioDevice. XAudio2 alkutoteutuksena.

Offline:
Raaka-assetit ( lähinnä animoidut mallit ja niiden tekstuurit ) tulevat sisään, missä formaatissa haluavat ja assimp ja tinyimage toimivat oikotienä niiden avaamiseksi.

Tämän jälkeen ne muutetaan moottorin arvostamaan homogeeniseen binäärimuotoon, joka tarjoaa nopean ja helpon lataamisen itse ajon aikana.

Tekstuurien mipmapit luodaan offlinessä.

Tietenkin myös maailmadatan olisi syytä joskus tulla sisään ( kolmannen osapuolen editorista uskomattoman pöljästi uunotettuna ) , ja siitä sitten parsitaan triggerit, valonlähteet, colliderit, spawnit, sekä kaikki maailman staattinen geometria nodeissaan.

Geometria murskataan ja partitioidaan halutun laiseksi ( Tällä hetkellä nelikantapuu ) ja sortataan materiaalien ja tekstuurien perusteella paremmin piirrettävään muotoon.

Miltei kaikki muu on itse tehtyä.
Muistinhallinta ( segmentoitu stack-allokaattori ).
Kontainerit + stringit.
Matematiikka.
...

Käytännössä ajonaikainen homma on jaettu neljään eri "kerrokseen".

- Riippumaton kerros: Ei linkitä tai includeta mitään.

- Alustakerros: Määrittää rajapinnat alustakohtaisten modulien toteutettaviksi ja tarjoaa pienen pätkän alustakohtaista koodia moduulin lataamiseksi.

- Moottorikerros: Käyttäen kahta alempaa kerrosta, toteuttaa itse moottorin.

- Sovelluskerros: Käyttäjän toteuttama aplikaatio ladataan moduulina.

Kielenä C++.
Edit: Tai, noh... Ei oikeastaan.
Niin paljon omaa kivaa ja kommervenkkejä eksynyt mukaan, ettei se ole puhdasta C++ kieltä nähnytkään.

 

[peksi]

Aika iso osa moottorin palikoista on lopulta aika tylsää koodattavaa (vaikka matikkakirjasto esim) mutta voihan tylsiksi kokemiaan juttuja aina korvata valmiilla kirjastoilla. Onneksi myös saa UE4:n kaltasia helposti käyttöön, ihan tajuton kehitystahti. Unitykin kevyempiin juttuihin ihan käyttökelponen.

 

[Lazzu]

Minä olen nyt kohta kolme vuotta tehnyt Unityllä isompia ja pienempiä projekteja. Kokemusteni perusteella seuraava projekti joka alkaa, ei varmasti tule toteutumaan Unityllä. Se alkaa jäämään jalkoihin kankeudessaan, ja "Unity way" tuntuu olevan lähinnä rajoitusten kiertäminen typerillä ja hirveillä purkkavirityksillä. Pari (ei julkista) engineä itse tehneenä Unityn kanssa päivittäinen tappelu alkaa syömään miestä, etenkin kun tietää miten helppo jotkin asiat olisi tehdä matalammalla tasolla.

Seuraavaan projektiin pitää tehdä valinta Unreal Enginen ja oman enginen välillä. Vaakakuppi tällä hetkellä on kallellaan omaan engineen, varsinkin kun on kuunnellut Unreal devaajien elämää sivukorvalla.

 

[Xiyng]

Unitystä on kertynyt hitunen kokemusta, ja on vaikuttanut oikein näppärältä ja moneen taipuvalta pelimoottorilta. Muutama asia siinäkin tympii toki. Lähinnä ärsyttää, miten kömpelöä Unityssä on hoitaa objektien luomiseen ja arvojen alustamiseen liittyviä asioita sekä pitää asioita muistissa scenejen välillä. Aivan erityisesti toivoisin, että moottorissa olisi mahdollisuus jonkinlaiseen startup-skriptiin, joka suoritetaan joka kerta ensimmäiseksi riippumatta ladattavasta scenestä tai oikein mistään muustakaan. Kyllähän nuo ongelmat pystyy kiertämään, mutta kiertäminen ei yleensä ole kovin mukavaa. Lisäksi editori on aika köykäinen kenttien osalta lähinnä ikävästi toimivan snap-to-gridin takia. Jos snäppäämistä ei erityisemmin tarvitse, editori toimii kyllä silloin ihan mallikkaasti.

Unreal Engineä on tullut myös kokeiltua hieman ja tuli todettua, että sen opettelu saa jäädä toiseen kertaan. Siinä vaikutti olevan paljon samaa kuin Unityssäkin, mutta siinä törmäsi jostain syystä koko ajan joihinkin ihmeellisyyksiin, jotka saivat kaiken rikkoutumaan. Työkaluna Unreal Engine on varmasti valtavan tehokas ja hyvä pidemmän päälle, mutta alkuun pääseminen vaikutti Unityn jälkeen kohtalaisen tuskaiselta. Lisäksi UE:n muistinhallinta kuulosti muistaakseni vähän jännältä (ja C/C++ ovat kyllä sen verran tuttuja, ettei jännyys tullut siitä).

 

[muzzy]

Unityssä ideana on käyttää prefabeja jossa olet käsin säätänyt ne arvot sellaisiksi kuin haluat, ja sitten alustaa prefabilla läjä objekteja jossa asiat on valmiiksi alustettu.

Scenejen välillä asiat pysyvät tallessa jos kutsut DontDestroyOnLoad jossainvaiheessa.

Startup-scriptin saa aikaiseksi kun pistät johonkin gameobjektiin scriptin jolla on Awake-metodi.

Uusista sceneistä saa tiedon nykyään SceneManagerin eventtien kautta.

 

[Radium]

Unitystä on kertynyt hitunen kokemusta, ja on vaikuttanut oikein näppärältä ja moneen taipuvalta pelimoottorilta. Muutama asia siinäkin tympii toki. Lähinnä ärsyttää, miten kömpelöä Unityssä on hoitaa objektien luomiseen ja arvojen alustamiseen liittyviä asioita sekä pitää asioita muistissa scenejen välillä. Aivan erityisesti toivoisin, että moottorissa olisi mahdollisuus jonkinlaiseen startup-skriptiin, joka suoritetaan joka kerta ensimmäiseksi riippumatta ladattavasta scenestä tai oikein mistään muustakaan. Kyllähän nuo ongelmat pystyy kiertämään, mutta kiertäminen ei yleensä ole kovin mukavaa. Lisäksi editori on aika köykäinen kenttien osalta lähinnä ikävästi toimivan snap-to-gridin takia. Jos snäppäämistä ei erityisemmin tarvitse, editori toimii kyllä silloin ihan mallikkaasti.

Kuten jo tuossa muzzy jo sanoikin, niin nuo kaikki onnistuu aika helpolla ja kikkailematta ainakin, kun ohjelma tulee tutummaksi. Tuon gridin osaltakaan ei pitäisi olla suurta ongelmaa tai et ainakaan kuvannut tarkemmin mikä on ongelma? yleisimmin käytetyt tavat ovat kai ctrl pohjassa raahaus ja kääntely, shift+ctrl surfacelle sekä vertex snapping eli V pohjassa raahailu.

 

[SnakeCase]

Unitystä on kertynyt hitunen kokemusta, ja on vaikuttanut oikein näppärältä ja moneen taipuvalta pelimoottorilta. Muutama asia siinäkin tympii toki. Lähinnä ärsyttää, miten kömpelöä Unityssä on hoitaa objektien luomiseen ja arvojen alustamiseen liittyviä asioita sekä pitää asioita muistissa scenejen välillä. Aivan erityisesti toivoisin, että moottorissa olisi mahdollisuus jonkinlaiseen startup-skriptiin, joka suoritetaan joka kerta ensimmäiseksi riippumatta ladattavasta scenestä tai oikein mistään muustakaan. Kyllähän nuo ongelmat pystyy kiertämään, mutta kiertäminen ei yleensä ole kovin mukavaa. Lisäksi editori on aika köykäinen kenttien osalta lähinnä ikävästi toimivan snap-to-gridin takia. Jos snäppäämistä ei erityisemmin tarvitse, editori toimii kyllä silloin ihan mallikkaasti.

Unreal Engineä on tullut myös kokeiltua hieman ja tuli todettua, että sen opettelu saa jäädä toiseen kertaan. Siinä vaikutti olevan paljon samaa kuin Unityssäkin, mutta siinä törmäsi jostain syystä koko ajan joihinkin ihmeellisyyksiin, jotka saivat kaiken rikkoutumaan. Työkaluna Unreal Engine on varmasti valtavan tehokas ja hyvä pidemmän päälle, mutta alkuun pääseminen vaikutti Unityn jälkeen kohtalaisen tuskaiselta. Lisäksi UE:n muistinhallinta kuulosti muistaakseni vähän jännältä (ja C/C++ ovat kyllä sen verran tuttuja, ettei jännyys tullut siitä).

Kannattaa tutustua Script Execution Order ominaisuuteen. Sillä voi määrittää haluttujen skriptien MonoBehaviour kutsuja (Awake, Update yms.) hallitussa järjestyksessä. En kuitenkaan suosittele tuon Script Execution Orderin käyttämistä joka asiaan ja kannattaakin harkita tarkkaan muita vaihtoehtoja ennen kuin tuohon koskee.

Unityä tullut käytettyä jo monta vuotta monessa eri projektissa ja vähän harmittaa kyllä, että siihen on tullut jumahdettua. Nyt pitäisi tässä alkaa taas haistelemaan muita vaihtoehtoja. Unreal Enginen käpistely kiinnostaa ja näköjään hyvät dokumentaatiot (Unreal Engine for Unity Developers) siitä näyttäisi löytyvän jos Unitystä siihen haluaa vaihtaa tai muuten vain vertailla niitä.

 

[Xiyng]

Unityssä ideana on käyttää prefabeja jossa olet käsin säätänyt ne arvot sellaisiksi kuin haluat, ja sitten alustaa prefabilla läjä objekteja jossa asiat on valmiiksi alustettu.

Tiedän kyllä tämän toiminnan. Skriptistä käsin objektien luominen on joissain tilanteissa se vähän epämiellyttävämpi homma. Muistaakseni skriptin kautta luodessa joissain tilanteissa joutuisi muuttamaan itse aika montaakin arvoa, että se vastaa editorin kautta luomista. En valitettavasti saa päähäni millään, missä tilanteessa tätä esiintyy. Ongelma ei ole kovin yleinen mutta pariin otteeseen olen siihen törmännyt. Samoin skriptien kanssa työskennellessä ärsyttää, kun joutuu herkästi editorissa valkkaamaan drag-and-drop -periaatteella prefabeja sun muita objekteja aika paljonkin.

Scenejen välillä asiat pysyvät tallessa jos kutsut DontDestroyOnLoad jossainvaiheessa.

Tiedän kyllä. Jossain pitää vain käydä luomassa se objekti, jolla tuota metodia kutsutaan, ja seuraavan scenen pitää sitten käydä vielä etsimässä tuo objekti. Ratkaisu toimii kyllä mainiosti muttei ole kovin elegantti.

Startup-scriptin saa aikaiseksi kun pistät johonkin gameobjektiin scriptin jolla on Awake-metodi.

Jotta kyseinen skripti suoritettaisiin heti pelin käynnistyessä scenestä riippumatta, skriptin sisältävä objekti pitäisi muistaa käsin laittaa jokaiseen sceneen. Eihän sekään ongelma ole, mutta minusta tuollaisten asioiden kuuluisi olla automatisoitavissa. Awake on joka tapauksessa tuttu asia, ja käytän sitä tällä hetkellä reilusti enemmän kuin Startia.

Uusista sceneistä saa tiedon nykyään SceneManagerin eventtien kautta.

Niinhän niistä saa, mutta en nyt tähän hätään näe, miten se minua auttaa näissä ongelmissa.

Kuten jo tuossa muzzy jo sanoikin, niin nuo kaikki onnistuu aika helpolla ja kikkailematta ainakin, kun ohjelma tulee tutummaksi. Tuon gridin osaltakaan ei pitäisi olla suurta ongelmaa tai et ainakaan kuvannut tarkemmin mikä on ongelma? yleisimmin käytetyt tavat ovat kai ctrl pohjassa raahaus ja kääntely, shift+ctrl surfacelle sekä vertex snapping eli V pohjassa raahailu.

Jos haluaa lähes kaiken pysyvän gridissä, nappi pohjassa tekeminen ei ole miellyttävää. Lisäksi asioilla tuntuu olevan pientä taipumusta karata gridistä aika helposti, jos ei ole hyvin tarkkana. Erityisesti ärsyttää, miten objektit, jotka eivät ole jo valmiiksi gridissä, jäävät Ctrl pohjassa raahatessa edelleen gridin ulkopuolelle. Ylipäänsä tuntuu, ettei Unityssä ole gridin kanssa työskentelyyn hirveästi panostettu vaan tehty ihan minimimäärä sen eteen. Luulen että tuon saisi jollain editoriskriptillä korjattua ainakin enimmäkseen, mutta ainakaan vielä ei ole tullut niin suurta tarvetta puuttua tuohon, että olisin sellaista kaivellut tai väsännyt.

Kannattaa tutustua Script Execution Order ominaisuuteen. Sillä voi määrittää haluttujen skriptien MonoBehaviour kutsuja (Awake, Update yms.) hallitussa järjestyksessä. En kuitenkaan suosittele tuon Script Execution Orderin käyttämistä joka asiaan ja kannattaakin harkita tarkkaan muita vaihtoehtoja ennen kuin tuohon koskee.

Tuokin ominaisuus on tiedossa, ja itsekin välttelen sen käyttöä muuten kuin viimeisenä vaihtoehtona. Kiitos vinkistä kuitenkin!

Unityä tullut käytettyä jo monta vuotta monessa eri projektissa ja vähän harmittaa kyllä, että siihen on tullut jumahdettua. Nyt pitäisi tässä alkaa taas haistelemaan muita vaihtoehtoja. Unreal Enginen käpistely kiinnostaa ja näköjään hyvät dokumentaatiot (Unreal Engine for Unity Developers) siitä näyttäisi löytyvän jos Unitystä siihen haluaa vaihtaa tai muuten vain vertailla niitä.

Itse kirosin juurikin noita dokumentaatioita, kun yritin perehtyä Unreal Engineen. Siellä on kyllä hyvin kattavasti dokumentaatiota, mutta jokin siinä aina silti mätti. Pidemmän päälle dokumentaatio vaikutti kyllä hyvälle, mutta UE-aloittelijana minun oli vaikea saada selkeää kuvaa siitä, mitä yksinkertaiseen perustoimintaan vaaditaan eri asioissa. Muistaakseni aika moni juttu toimi melkein suoraan, mutta aina oli joku asetus tms. joka aiheutti valtavasti päänvaivaa. Konkreettisimpana esimerkkinä muistan fysiikanmallinnuksen, joka taisi kyseisessä projektissa toimia muuten suoraan, mutta piti osata muuttaa yksi tietty asetus. Aika montaa asetusta tuli kokeiltua ja mielestäni kokeilin myös sitä oikeaa jossain vaiheessa, mutta nähtävästi jotain meni silti pieleen. Jossain vaiheessa palaset sitten lopulta loksahtivat paikoilleen. Pitää vielä joskus palata UE:n pariin uudestaan (onhan se hyödyllinen osata), mutta tuo kerta vei kyllä isoimmat innot UE:n suhteen toviksi.

 

[muzzy]

Jossain pitää vain käydä luomassa se objekti, jolla tuota metodia kutsutaan, ja seuraavan scenen pitää sitten käydä vielä etsimässä tuo objekti.

Siihen objektiin voi iskeä kiinni scriptin joka kutsuu ihan itselleen sitä. Samalla tavalla objektissa kiinni oleva scripti voi asettaa listenerin SceneManagerille että pystyy hoitamaan tarpeelliset jutut seuraavaa sceneä ladatessa, sitä ei tarvitse jättää minkään ulkopuolisen gameobjektin tai luokan vastuulle jos ei välttämättä halua.

Ja aina voit tehdä myös singletonin joka käy etsimässä ensimmäisen scenen aikana läjän gameobjekteja ja sitten tarjoaa rajapinnan myöhempien scenejen käyttöön, tai hallinnoi suoraan niitä.

Esimerkiksi jos tarkoitus on siirtää jokin gameobjekti tiettyyn pisteeseen myöhemmässä scenessä, voit hyvin tehdä uuteen sceneen tyhjän gameobjektin joka toimii vain markkerina sisältäen scriptin jossa pelkästään stringi että mikä asia siihen pitäisi siirtää. Ytimenä toimivassa gameobjektissasi olisi sitten kiinni komponentti joka uuden scenen lataudutta käy etsimässä kaikki markkerit ja siirtää ne gameobjektit kohteisiinsa. Liikuteltaviin gameobjekteihin vielä lopuksi scripti johon syötetään vastaava tunnistestringi ja joka käy rekisteröimässä itsensä tuonne ytimessä olevaan dictionaryyn niin ydin tietää mitä pitää siirrellä sitten kun aika tulee. Näiden kolmen yksinkertaisen scriptin jälkeen ei tarvitse enää ikinä kirjoittaa lisää koodia objektien siirtelemiseksi uusissa sceneissä vaikka scenejä tai liikuteltavia asioita tulisi lisää. Samaa tekniikkaa voi laajentaa sitten vielä pidemmälle muihinkin ominaisuuksiin kuin sijaintiin.

 

[Radium]

Jos haluaa lähes kaiken pysyvän gridissä, nappi pohjassa tekeminen ei ole miellyttävää. Lisäksi asioilla tuntuu olevan pientä taipumusta karata gridistä aika helposti, jos ei ole hyvin tarkkana. Erityisesti ärsyttää, miten objektit, jotka eivät ole jo valmiiksi gridissä, jäävät Ctrl pohjassa raahatessa edelleen gridin ulkopuolelle. Ylipäänsä tuntuu, ettei Unityssä ole gridin kanssa työskentelyyn hirveästi panostettu vaan tehty ihan minimimäärä sen eteen. Luulen että tuon saisi jollain editoriskriptillä korjattua ainakin enimmäkseen, mutta ainakaan vielä ei ole tullut niin suurta tarvetta puuttua tuohon, että olisin sellaista kaivellut tai väsännyt.

Itselläni oli tuollainen editorin auto snap -skripti tehtynä ja käytössä yhdessä projektissa, jossa muistaakseni automaattisesti napsautin raahatessa koko ajan vaihtelevan gridin mukaan, joka oli sidottu objektin tagiin tai layeriin. Pohjatileilllä oli esim. oma gridi ja koristeilla oma 1/4 pohjatilejen koosta oleva gridi. Muutaman kerran myös asset storen ilmaisia ja käteviä lajennuksia.

Aika monessa projektissa itselleni on kuitenkin nuo perusjutut riittäneet hyvin

 

[Xiyng]

Siihen objektiin voi iskeä kiinni scriptin joka kutsuu ihan itselleen sitä. Samalla tavalla objektissa kiinni oleva scripti voi asettaa listenerin SceneManagerille että pystyy hoitamaan tarpeelliset jutut seuraavaa sceneä ladatessa, sitä ei tarvitse jättää minkään ulkopuolisen gameobjektin tai luokan vastuulle jos ei välttämättä halua.

Ja aina voit tehdä myös singletonin joka käy etsimässä ensimmäisen scenen aikana läjän gameobjekteja ja sitten tarjoaa rajapinnan myöhempien scenejen käyttöön, tai hallinnoi suoraan niitä.

Esimerkiksi jos tarkoitus on siirtää jokin gameobjekti tiettyyn pisteeseen myöhemmässä scenessä, voit hyvin tehdä uuteen sceneen tyhjän gameobjektin joka toimii vain markkerina sisältäen scriptin jossa pelkästään stringi että mikä asia siihen pitäisi siirtää. Ytimenä toimivassa gameobjektissasi olisi sitten kiinni komponentti joka uuden scenen lataudutta käy etsimässä kaikki markkerit ja siirtää ne gameobjektit kohteisiinsa. Liikuteltaviin gameobjekteihin vielä lopuksi scripti johon syötetään vastaava tunnistestringi ja joka käy rekisteröimässä itsensä tuonne ytimessä olevaan dictionaryyn niin ydin tietää mitä pitää siirrellä sitten kun aika tulee. Näiden kolmen yksinkertaisen scriptin jälkeen ei tarvitse enää ikinä kirjoittaa lisää koodia objektien siirtelemiseksi uusissa sceneissä vaikka scenejä tai liikuteltavia asioita tulisi lisää. Samaa tekniikkaa voi laajentaa sitten vielä pidemmälle muihinkin ominaisuuksiin kuin sijaintiin.

Tiedän kyllä, että tähän löytyy ihan näppäriäkin tekniikoita. Ehkä kaipaisin käytännössä jotain funktiokutsun tapaista, jossa välitetään eräänlaisena parametrina tietoa, jota sitten voidaan käyttää miten huvittaa. Meinaan siis, että vanha scene antaisi uudelle scenelle parametriksi mitä antaa, ja uusi scene sitten käyttää parametrina välitettyä dataa miten haluaa. Luultavasti jotain tuontapaista pystyisi itsekin tekemään kohtalaiselle vaivalla, mutta olisi kiva, jos Unityssä olisi jonkinlainen luontaisempi tuki. Datan välitys sceneltä toiselle ei kuitenkaan ole asia, jonka kuvittelisi vaativan kovin ihmeellisiä asioita, mutta Unityssä sekin vaatii jo hieman säätämistä.

Itselläni oli tuollainen editorin auto snap -skripti tehtynä ja käytössä yhdessä projektissa, jossa muistaakseni automaattisesti napsautin raahatessa koko ajan vaihtelevan gridin mukaan, joka oli sidottu objektin tagiin tai layeriin. Pohjatileilllä oli esim. oma gridi ja koristeilla oma 1/4 pohjatilejen koosta oleva gridi. Muutaman kerran myös asset storen ilmaisia ja käteviä lajennuksia.

Aika monessa projektissa itselleni on kuitenkin nuo perusjutut riittäneet hyvin

Kiva tietää, että tuo tosiaan onnistuu. Kiitos varmistuksesta!

 

[Kura]

. Skriptistä käsin objektien luominen on joissain tilanteissa se vähän epämiellyttävämpi homma.

Worst case tämän kanssa on että teet prefabin ja instantioit niitä miten huvittaa. Vie yhden rivin koodia.

Tiedän kyllä. Jossain pitää vain käydä luomassa se objekti, jolla tuota metodia kutsutaan, ja seuraavan scenen pitää sitten käydä vielä etsimässä tuo objekti. Ratkaisu toimii kyllä mainiosti muttei ole kovin elegantti. Jotta kyseinen skripti suoritettaisiin heti pelin käynnistyessä scenestä riippumatta, skriptin sisältävä objekti pitäisi muistaa käsin laittaa jokaiseen sceneen. Eihän sekään ongelma ole, mutta minusta tuollaisten asioiden kuuluisi olla automatisoitavissa. Awake on joka tapauksessa tuttu asia, ja käytän sitä tällä hetkellä reilusti enemmän kuin Startia.

Äärettömän yleistä isommissa peliprojekteissa olla jonkin sortin GameManager objekti joka hoitaa tämän tyyppisiä funktionaalisuuksia. Voit laittaa tämän yhteen skeneen, tallentaa staattisena arvona, kutsua DontDestroyOnLoadia ja rekisteröidä SceneManagementin eventteihin jotain kutsuja kun skene vaihtuu.

Skenejä ja niiden käyttötapoja on niin monia erilaisia ettei tämän tekemisestä enginen puolesta olisi kovin järkevää.

Toisin kuin Start, Awake kutsutaan myös disabloiduille objekteille ja sitä pitäisi käyttää vain asioiden initialisointiin.

Jos haluaa lähes kaiken pysyvän gridissä, nappi pohjassa tekeminen ei ole miellyttävää. Lisäksi asioilla tuntuu olevan pientä taipumusta karata gridistä aika helposti, jos ei ole hyvin tarkkana. Erityisesti ärsyttää, miten objektit, jotka eivät ole jo valmiiksi gridissä, jäävät Ctrl pohjassa raahatessa edelleen gridin ulkopuolelle. Ylipäänsä tuntuu, ettei Unityssä ole gridin kanssa työskentelyyn hirveästi panostettu vaan tehty ihan minimimäärä sen eteen. Luulen että tuon saisi jollain editoriskriptillä korjattua ainakin enimmäkseen, mutta ainakaan vielä ei ole tullut niin suurta tarvetta puuttua tuohon, että olisin sellaista kaivellut tai väsännyt.

Unity on 3D moottori ja monet 3D pelit eivät ole gridipohjaisia. Unityn mentaliteetti on myös hyödyntää Asset Storea tämmöisiin spesifisiin use-caseihin. Grideihin voi käyttää vaikka https://www.assetstore.unity3d.com/en/#!/content/4466

Tuokin ominaisuus on tiedossa, ja itsekin välttelen sen käyttöä muuten kuin viimeisenä vaihtoehtona. Kiitos vinkistä kuitenkin!

Ei script exec orderia kannata "välttää", vaan käyttää ainoastaan silloin kuin on tarve. Esim omassa pelissäni on Controller, PlayerMovement ja CameraController komponentit. Camera controller täytyy kutsua ennen PlayerMovementia, jotta liikkuminen on kameran nykyisen framen mukaista, ja Controller on kutsuttava ennen PlayerMovementia ja CameraControlleria, jotta kummallakin on käytössä nykyisen framen state-data. Movement on kutsuttava ennen muita pelaajan skriptejä, jotta niillä on nykyisen framen positiodata.

Kutsut voisi kirjoittaa käsin skripteihin, mutta tällöin Controllerin pitäisi tietää jotain CameraControllerista, CameraControllerin jotain Controllerista tai sisältää jotain rumia null checkejä ja/tai frame flageja ettei niitä kutsuta useampaan otteeseen.

Unityn suurimmat rajoitukset tulee kun projektit kasvaa ja/tai mennään vähän syvemmälle koodauksen kanssa.
- Haluat rendata natiivit shadowmapit itse vaikka stencilien kanssa? Ei onnistu
- Tarviit gigan kokoisen arrayn dataa? Pakko käyttää unsafe dll:ää ja unmanaged arraytä jos ei halua että monon GC menee hulluksi
- Haluat useamman fysiikkakontekstin tai deterministiset fysiikat vaikka nettipeliä varten? Pakko käyttää P/Invoken kautta ulkoista kirjastoa kauhean overheadin kanssa
- Haluat piirtää GPU instansoinnilla vaikka 100000 asteroidia tai ruohonkortta kuten monet AAA pelit Crysiksestä lähtien? Pakko käyttää unityn lagista APIa joka vie kaiken CPU tehon
- Haluat ketjuttaa image effektejä useamman kameran välillä? Voi vittu mikä sotku tästä tulee
- Haluat työskennellä 10+ ihmisen kanssa projektissa? Scenejen ja prefabien hallinnasta tulee käsittämättömän hankalaa. (Koita opettaa artistille UnityYAMLMerge etc prefabien hallinta)

jne lista jatkuu pitkälle..

Monet näistä paranee todennäköisesti kun Unity saa uumoillun Scriptable Rendering Pipelinen, nested prefabit jne muita featureja tehtyä, mutta siltikin ollaan vielä kaukana siitä että Unityllä tehtäisiin useita AAA pelejä.

AA pelit ja siitä alaspäin Unity on tosin loistava.

 

[Ctzn_no7]

Seuraavaan projektiin pitää tehdä valinta Unreal Enginen ja oman enginen välillä. Vaakakuppi tällä hetkellä on kallellaan omaan engineen, varsinkin kun on kuunnellut Unreal devaajien elämää sivukorvalla.

Just kerkeää UE:n change logit lukee kannesta kanteen ni on jo uutta preview-versiota tulossa ulos.

Monesti olen kuullut tuosta "valmiissa moottorissa on liikaa ylimääräistä", vaan viime Unreal MegaJamin Discord keskusteluissa todettiin että senkin enginen kun karsiin aivan runkoa myöten turhasta ennen projektin pakkausta, jää 40megaa+projektitiedostot jäljelle kirjotettavaa dataa vs. ~400Mb default asetuksilla
(yksi kisaluokka oli siis alle 100Mb pelit)

 

[Xiyng]

Worst case tämän kanssa on että teet prefabin ja instantioit niitä miten huvittaa. Vie yhden rivin koodia.

Tiedän kyllä, mutta prefabin luonti on tympeää puuhaa, jos oikeasti tarvitsee vain saada nopeasti tietynlainen objekti ja on tottunut siihen, että "normaalissa" ohjelmistokehityksessä se onnistuu koodin kautta helposti. Enimmäkseen käytänkin prefabeja koska monissa tilanteissa se on kätevin ratkaisu, mutta välillä se tuntuu järeämmältä työkalulta kuin mitä tilanne vaatii.

Äärettömän yleistä isommissa peliprojekteissa olla jonkin sortin GameManager objekti joka hoitaa tämän tyyppisiä funktionaalisuuksia. Voit laittaa tämän yhteen skeneen, tallentaa staattisena arvona, kutsua DontDestroyOnLoadia ja rekisteröidä SceneManagementin eventteihin jotain kutsuja kun skene vaihtuu.

Skenejä ja niiden käyttötapoja on niin monia erilaisia ettei tämän tekemisestä enginen puolesta olisi kovin järkevää.

Tiedossa on, ja se on ihan näppärä ratkaisu sinänsä. Testausta vain helpottaisi, jos voisi editorissa helposti testata joka sceneä suoraan play-napilla. Tuon GameManagerin kohdalla se vain tarkoittaa sitä, että joka sceneen pitää pistää se GameManager tai jotain, joka kaivaa sen jostain. Juuri siinä kaipaisin sitä koko pelin startup-skriptiä, ettei noita GameManagereita tarvitsisi käydä käsipelillä lisäämässä joka sceneen. Toistaiseksi kun omalla virittelytasolla on kuitenkin pystynyt muuten testaamaan scenet suoraan play-napin avulla, niin ei huvittaisi melkein ensimmäisenä olla tekemässä jotain startup-sceneä, joka hoitaa tuollaisia asioita (eikä sen puoleen sen avulla testaaminenkaan ole mukavaa, kun joutuu joka kerta vaihtamaan kyseiseen sceneen, jotta GameManager on olemassa).

Toisin kuin Start, Awake kutsutaan myös disabloiduille objekteille ja sitä pitäisi käyttää vain asioiden initialisointiin.

Tämäkin on tiedossa, ja juuri tuohon olenkin sitä käyttänyt. Startin tarve on ainakin toistaiseksi ollut vaatimattomampaa, joten siksi Awake on ollut yleisempi. Oletan, että projektien koon kasvaessa Startin tarvekin kasvaa suuremmaksi.

Unity on 3D moottori ja monet 3D pelit eivät ole gridipohjaisia. Unityn mentaliteetti on myös hyödyntää Asset Storea tämmöisiin spesifisiin use-caseihin. Grideihin voi käyttää vaikka https://www.assetstore.unity3d.com/en/#!/content/4466

Kiitos vinkistä! Asset Store on toki tiedossa, ja perehdyn näihin varmaan enemmän sitten kun se on ajankohtaisempaa; tähän hätään ainakin vierastan vähän maksullisia paketteja olosuhteiden, kohtalaisen vähäisen tarpeen ja testausmahdollisuuden puutteen vuoksi.

Ei script exec orderia kannata "välttää", vaan käyttää ainoastaan silloin kuin on tarve. Esim omassa pelissäni on Controller, PlayerMovement ja CameraController komponentit. Camera controller täytyy kutsua ennen PlayerMovementia, jotta liikkuminen on kameran nykyisen framen mukaista, ja Controller on kutsuttava ennen PlayerMovementia ja CameraControlleria, jotta kummallakin on käytössä nykyisen framen state-data. Movement on kutsuttava ennen muita pelaajan skriptejä, jotta niillä on nykyisen framen positiodata.

Välttää oli ehkä vähän väärä sana. Ennemminkin en ole toistaiseksi onnistunut törmäämään tilanteeseen, jossa suoritusjärjestys olisi ollut selkeästi paras ratkaisu. Suoritusjärjestyksen käpälöiminen käsin vaikuttaa asialta, joka on melko virhealtista varsinkin muutosten suhteen, joten sen vuoksi en yleensä pidä sitä kovin ihanteellisena ratkaisuna.

Kutsut voisi kirjoittaa käsin skripteihin, mutta tällöin Controllerin pitäisi tietää jotain CameraControllerista, CameraControllerin jotain Controllerista tai sisältää jotain rumia null checkejä ja/tai frame flageja ettei niitä kutsuta useampaan otteeseen.

Tähän ongelmaan olen itse asiassa törmännyt jo jonkin verran, ja se pakottaa aina miettimään tehtyjä ja harkinnassa olevia ratkaisuja aika tarkkaan. Pidän mielessä, että suoritusjärjestyksen käpälöinti saattaisi sopia ongelman ratkaisuun. Kiitos vinkistä!

Unityn suurimmat rajoitukset tulee kun projektit kasvaa ja/tai mennään vähän syvemmälle koodauksen kanssa.
- Haluat rendata natiivit shadowmapit itse vaikka stencilien kanssa? Ei onnistu
- Tarviit gigan kokoisen arrayn dataa? Pakko käyttää unsafe dll:ää ja unmanaged arraytä jos ei halua että monon GC menee hulluksi
- Haluat useamman fysiikkakontekstin tai deterministiset fysiikat vaikka nettipeliä varten? Pakko käyttää P/Invoken kautta ulkoista kirjastoa kauhean overheadin kanssa
- Haluat piirtää GPU instansoinnilla vaikka 100000 asteroidia tai ruohonkortta kuten monet AAA pelit Crysiksestä lähtien? Pakko käyttää unityn lagista APIa joka vie kaiken CPU tehon
- Haluat ketjuttaa image effektejä useamman kameran välillä? Voi vittu mikä sotku tästä tulee
- Haluat työskennellä 10+ ihmisen kanssa projektissa? Scenejen ja prefabien hallinnasta tulee käsittämättömän hankalaa. (Koita opettaa artistille UnityYAMLMerge etc prefabien hallinta)

jne lista jatkuu pitkälle..

Monet näistä paranee todennäköisesti kun Unity saa uumoillun Scriptable Rendering Pipelinen, nested prefabit jne muita featureja tehtyä, mutta siltikin ollaan vielä kaukana siitä että Unityllä tehtäisiin useita AAA pelejä.

Noista lähinnä scenejen hallinta kuulostaa tutulta ongelmalta. Tosin isommat projektit ovat minulla luultavasti vielä kaukana tulevaisuudessa jos sielläkään, joten en voi väittää tietäväni näistä hirveästi. Hyvä kuitenkin tietää, että Unityllä on näiden asioiden suhteen jonkinlaisia hankaluuksia. Olen kyllä arvellutkin, että jokin syy siihen on oltava, miksei Unity ole kovin suosittu valinta AAA-peleille.

AA pelit ja siitä alaspäin Unity on tosin loistava.

Jep, kaikista ongelmistaankin huolimatta Unityllä vaikuttaa saavan helposti aikaan ja tarvittaessa kohtalaisen paljonkin eikä suunta luultavasti ole ainakaan huonompaan päin.

 

[Radium]

Tiedossa on, ja se on ihan näppärä ratkaisu sinänsä. Testausta vain helpottaisi, jos voisi editorissa helposti testata joka sceneä suoraan play-napilla. Tuon GameManagerin kohdalla se vain tarkoittaa sitä, että joka sceneen pitää pistää se GameManager tai jotain, joka kaivaa sen jostain. Juuri siinä kaipaisin sitä koko pelin startup-skriptiä, ettei noita GameManagereita tarvitsisi käydä käsipelillä lisäämässä joka sceneen. Toistaiseksi kun omalla virittelytasolla on kuitenkin pystynyt muuten testaamaan scenet suoraan play-napin avulla, niin ei huvittaisi melkein ensimmäisenä olla tekemässä jotain startup-sceneä, joka hoitaa tuollaisia asioita (eikä sen puoleen sen avulla testaaminenkaan ole mukavaa, kun joutuu joka kerta vaihtamaan kyseiseen sceneen, jotta GameManager on olemassa).

Singletoninahan tuo esim. onnistuu helposti ja toimii kaikissa sceneissä ja kokeiluissa automaattisesti. Toinen vaihtoehto esim. on tehdä oma GameManager scene, jossa kaikki yleiset rimpulat ja jutut on ja ladata se olemassa olevan rinnalle.

 

[Xiyng]

Singletoninahan tuo esim. onnistuu helposti ja toimii kaikissa sceneissä ja kokeiluissa automaattisesti. Toinen vaihtoehto esim. on tehdä oma GameManager scene, jossa kaikki yleiset rimpulat ja jutut on ja ladata se olemassa olevan rinnalle.

Tiedossa ovat nuokin kikat, joskin singleton haiskahtaa vähän ikävälle enkä siksi tykkää sitäkään käyttää. Se saattaisi tosin silti olla vähiten huono vaihtoehto... Tuo toinen ratkaisu taas ei oikein toimi halutulla tavalla, koska siinäkin pitää muistaa ladata joka scenessä se toinen scene, jolloin on aika yhdentekevää, lisääkö GameManagerin ~suoraan vai lisääkö komponentin tms., joka lataa GameManagerin yms. lataavan scenen. Eihän tuolla ongelmalla siis edelleenkään suurempaa vaikutusta mihinkään ole, koska sen pystyy kohtalaisen helposti kiertämään, mutta se on yksi niistä ärsyttävistä asioista, jotka joutuu Unityssä tekemään tarpeettoman hankalasti kun helpompikin tapa olisi olemassa ja todennäköisesti myös helposti Unityyn lisättävissä (eli se pelin käynnistyksen yhteydessä suoritettava startup-skripti).

 

[Radium]

Tiedossa ovat nuokin kikat, joskin singleton haiskahtaa vähän ikävälle enkä siksi tykkää sitäkään käyttää. Se saattaisi tosin silti olla vähiten huono vaihtoehto... Tuo toinen ratkaisu taas ei oikein toimi halutulla tavalla, koska siinäkin pitää muistaa ladata joka scenessä se toinen scene, jolloin on aika yhdentekevää, lisääkö GameManagerin ~suoraan vai lisääkö komponentin tms., joka lataa GameManagerin yms. lataavan scenen. Eihän tuolla ongelmalla siis edelleenkään suurempaa vaikutusta mihinkään ole, koska sen pystyy kohtalaisen helposti kiertämään, mutta se on yksi niistä ärsyttävistä asioista, jotka joutuu Unityssä tekemään tarpeettoman hankalasti kun helpompikin tapa olisi olemassa ja todennäköisesti myös helposti Unityyn lisättävissä (eli se pelin käynnistyksen yhteydessä suoritettava startup-skripti).

Uuden scenemanegerin tulon yhteydessä mainittiin tuo erillinen scene suositeltuna tapana tehdä gamemanagerin tyyppisiä juttuja. Sen voi merkitä buildin ekaksi sceneksi tai ladata halutussa kohtaa ja editorissa voi raahata parissa sekunnissa työskenneltävän scenen rinnalle. DontDestroyOnLoadin osalta muistaakseni sanottiin, että jatkossa kannattaa välttää sen käyttöä projekteissa, jotka voisivat käyttää tuota erillistä Sceneä

Startupin osalta en näe hyötyä erillisessä skriptissä verrattuna startup sceneen skriptillä. Scene on joustavampi resurssien määritysten suhteen ja eri platformien käytön kanssa. Mitä koodia käytännössä pitäisit tuollaisessa pelin startupissa? vai oliko tarve pelkästään tuo editorin käyttöön liittyvä scenen lataus?

 

[Xiyng]

Uuden scenemanegerin tulon yhteydessä mainittiin tuo erillinen scene suositeltuna tapana tehdä gamemanagerin tyyppisiä juttuja. Sen voi merkitä buildin ekaksi sceneksi tai ladata halutussa kohtaa ja editorissa voi raahata parissa sekunnissa työskenneltävän scenen rinnalle. DontDestroyOnLoadin osalta muistaakseni sanottiin, että jatkossa kannattaa välttää sen käyttöä projekteissa, jotka voisivat käyttää tuota erillistä Sceneä

Kiitos vinkistä tuon DontDestroyOnLoadin suhteen! Kuulostaa ihan fiksulle ajatukselle. Oliko tosiaan näin, että scenejä voi myös editorissa ladata jotenkin rinnakkain?

Startupin osalta en näe hyötyä erillisessä skriptissä verrattuna startup sceneen skriptillä. Scene on joustavampi resurssien määritysten suhteen ja eri platformien käytön kanssa. Mitä koodia käytännössä pitäisit tuollaisessa pelin startupissa? vai oliko tarve pelkästään tuo editorin käyttöön liittyvä scenen lataus?

Lähinnä kai kaipaisin tuota startup-skriptiä juurikin GameManagerin yms. lataamiseen... Silloin kaikki scenejen tarvitsema olisi automaattisesti olemassa aina riippumatta siitä, mitä scenejä lataa, ja ilman että sceneihin tarvitsee itse lisätä mitään, mikä huolehtii tällaisten scenestä toiseen säilyvien juttujen lataamisesta. Startup-scenessä (jos siis meinataan sceneä, joka ei Unityn puolesta lataa automaattisesti muita scenejä) tosiaan on epämukavuutena se, että peli pitää testatessa käynnistää aina sen kautta, jotta kaikki tarvittava olisi aina olemassa muiden scenejen käytettävissä. Tosin jos ajattelee startup-scenen scenenä, joka ladataan aina ennen muita scenejä ja sen päälle ladataan sitten myös valittu scene, niin sellainen kelpaisi myös. Selitys taitaa mennä nyt vähän sekavaksi, mutta selvennetään sitten, jos se osoittautuu ongelmaksi...

 

[Radium]

Kiitos vinkistä tuon DontDestroyOnLoadin suhteen! Kuulostaa ihan fiksulle ajatukselle. Oliko tosiaan näin, että scenejä voi myös editorissa ladata jotenkin rinnakkain?

Joo siitä saakka, kun se multi scene editing tuli. Riittää, kun raahaat toiset scenet hierarchyyn. Täältä löytyy ohjeita ja näköjään noita samoja joista edellisessä viestissä mainitsin.

https://docs.unity3d.com/Manual/MultiSceneEditing.html

Lähinnä kai kaipaisin tuota startup-skriptiä juurikin GameManagerin yms. lataamiseen... Silloin kaikki scenejen tarvitsema olisi automaattisesti olemassa aina riippumatta siitä, mitä scenejä lataa, ja ilman että sceneihin tarvitsee itse lisätä mitään, mikä huolehtii tällaisten scenestä toiseen säilyvien juttujen lataamisesta. Startup-scenessä (jos siis meinataan sceneä, joka ei Unityn puolesta lataa automaattisesti muita scenejä) tosiaan on epämukavuutena se, että peli pitää testatessa käynnistää aina sen kautta, jotta kaikki tarvittava olisi aina olemassa muiden scenejen käytettävissä. Tosin jos ajattelee startup-scenen scenenä, joka ladataan aina ennen muita scenejä ja sen päälle ladataan sitten myös valittu scene, niin sellainen kelpaisi myös. Selitys taitaa mennä nyt vähän sekavaksi, mutta selvennetään sitten, jos se osoittautuu ongelmaksi...

Buildiin käy hyvin vain tuo ekaksi sceneksi määritys ja sen koodin seuraavien scenejen lataus additivena. Näin aika moni tekee muutenkin animoidut latausruudut yms.

Editoinnissa voi joko raahata tai varmaan tehdä muutaman rivin editor skriptin, joka lataa saman gamemanagerin aina playn yhteydessä.

 

[Xiyng]

Joo siitä saakka, kun se multi scene editing tuli. Riittää, kun raahaat toiset scenet hierarchyyn. Täältä löytyy ohjeita ja näköjään noita samoja joista edellisessä viestissä mainitsin.

https://docs.unity3d.com/Manual/MultiSceneEditing.html

Kiitos tiedosta! Eiköhän tällekin jossain vaiheessa löydy jotain käyttöä (itse asiassa potentiaalisia käyttökohteita tulee jo hieman mieleen).

Buildiin käy hyvin vain tuo ekaksi sceneksi määritys ja sen koodin seuraavien scenejen lataus additivena. Näin aika moni tekee muutenkin animoidut latausruudut yms.

Buildin kanssa ei tosiaan ole ollut mitään ongelmia, joten tässä ei sinänsä ole mitään uutta.

Editoinnissa voi joko raahata tai varmaan tehdä muutaman rivin editor skriptin, joka lataa saman gamemanagerin aina playn yhteydessä.

Sen sijaan editoriskripti on aivan loistava ehdotus, joka saattaa hyvinkin ratkaista tämän puutteen! Jos latausjärjestyksestä ei koidu ongelmia, tämän pitäisi sopia täydellisesti. Suurkiitos suorastaan! Edelleen tykkäisin kyllä, jos Unityssä olisi startup-skripti tms. ettei tarvitsisi itse väsätä editoriskriptiä, mutta tämä saattaa hyvinkin korjata ongelman tyydyttävästi.

 

[Jean_Sipulius]

Tervetuloa seuraamaan ohjelmoinnin videosarjaa. Ohjelmointi tapahtuu Visual Studiolla ja kielenä on C++. Tämän sarjan rinnalla kulkee Unreal Engine -ohjelmointivideot. Näissä videoissa käytämme visuaalista blueprint-ohjelmointia sekä C++ ohjelmointia. Nämä kaksi täydentävät toisiaan. Aikaisempaa ohjelmointikokemusta ei tarvita C++ videoissa, mutta tiedot ainakin olio-ohjelmoinnista on hyvä olla hanskassa Unrealin videosarjassa. Mikäli videot kiinnostavat niin pistäkäähän kanavaa tilaukseen. Huomenna tulee video IF-lauseista.

https://www.youtube.com/channel/UCfbRKG0qnF9sQuQVXedFDAQ

 

[Kelju_K]

Itse olen käytellyt XNA:ta joskus vuonna nakki, siitä siirryin LibGDX:ään ja sen rinnalla on pyörinyt Unity ja uusimpana tuttavuutena Godot engine. Varsinkin tuo Libgdx on ihan täydellinen 2d-pelejä tehdessä.

Itselle on tärkeää pelimoottoria valittaessa, että se on vapaa ja ilmainen. Se että joutuu vaikka splash-screenin muokkauksesta maksamaan on mielestäni väärin. Tai että menestyvän pelin tuotoista lähtee x% pelimoottorille on myös väärin. Enemmän ehkä periaatekysymyksiä nämä. Oma peli pitäisi olla juuri sellainen kuin itse haluaa, itse määräten kaikki sen piirteet. Silti tuo unity on tuolla omassa listassa, kun kaikenlaiset yhteistyönä tehtävät projektit tehdään unityllä koska muut eivät muulla osaa eivätkä halua opetella uutta.

 

[Xiyng]

Itselle on tärkeää pelimoottoria valittaessa, että se on vapaa ja ilmainen. Se että joutuu vaikka splash-screenin muokkauksesta maksamaan on mielestäni väärin. Tai että menestyvän pelin tuotoista lähtee x% pelimoottorille on myös väärin. Enemmän ehkä periaatekysymyksiä nämä. Oma peli pitäisi olla juuri sellainen kuin itse haluaa, itse määräten kaikki sen piirteet. Silti tuo unity on tuolla omassa listassa, kun kaikenlaiset yhteistyönä tehtävät projektit tehdään unityllä koska muut eivät muulla osaa eivätkä halua opetella uutta.

Ei kaupallisen tason pelimoottoria oikein voi ilmaiseksikaan jakaa, jotain siitä on saatava takaisin. Kehitystyö maksaa, ja mielellään yrityksen on tehtävä voittoakin. Jos ei hyväksy tuota, voi käyttää ilmaisia vaihtoehtoja, jotka tässä tapauksessa ovat yleensä joko huonompia tai vaativat enemmän työtä. Jos tilanne ärsyttää, voit toki itse lähteä kehittämään ilmaista kaupallisen tason pelimoottoria ja katsoa, miten käy. Jos pääset lähellekään Unityn tasoa, siirryn itsekin mielihyvin moottorisi käyttäjäksi.

Ihmiset käyttävät valmiita pelimoottoreita, koska pelimoottorin kehittäminen on työlästä, aikaavievää ja usein kallista, ja kaikki se on pois itse pelin tekemiseltä. Ihmiset eivät yleensä käytä valmiita pelimoottoreita siksi, etteivät he halua opetella uutta, vaan siksi, että se on heille yksinkertaisesti järkevin vaihtoehto. He eivät välttämättä ole periaatteistasi samaa mieltä (ainakaan kaikissa tapauksissa), joten heillä on ihan erilainen lähtökohta asian tarkasteluun.

 

[Jean_Sipulius]

Omasta mielestä täysin hullu ajatus, että esim Unreal olisi ilmainen. Epicillä on hurja määrä ihmisiä vakituisessa työsuhteessa ja kokonaispalkka lasketaan kymmenissä tuhansissa. 5% tuloista on naurettavan pieni, kun joka ikinen viikko tulee livestriimiä ja uutta asiaa opetetaan ja selitetään. Kaikki Unrealin assetit on täysin ilmaisia käyttää omissa projekteissa ja niitä on Paljon. Tämän lisäksi uusia ominaisuuksia lisätään jokaiseen versioon. PS4, xbox One, Android, IOS,VR ohjelmointi onnistuu opettelemalla vain yhden ohjelmointikielen.

Jos haluaa omaa niin voi tehdä vaikka pluginin joka tekee minkä tahansa asian mitä ikinä keksiikään.. käyttää sitten plugaa omassa projussa. Unityssä tietysti samantyyliset setit.

Ennen UE maksoi 15e/kk, mutta se lähti pari vuotta sitten pois. Nyt on se 5% tuloista enää

 

[Ctzn_no7]

Ennen UE maksoi 15e/kk, mutta se lähti pari vuotta sitten pois. Nyt on se 5% tuloista enää

5% myyntihinnasta, steam raapaisee kolmanneksen ja verottaja loput.
ottaavahan ne tietysti oman osan asset storen myynneistä, olikohan 10 vai 20%

Muistaakseni Facebook on tarjoutunut kattamaan tuon 5% Oculus-exclusive peleille, ja taisi olla vielä ilman määräaikaista sopimusta

 

[Radium]

Oculus maksaa 5% rojaltit 5 miljoonaan asti myynneistä heidän kaupassaan ja ei ole yksinoikeusvaatimusta. Käytännössä tuo on 250k säästö.

Tuo 5% koskee yleisesti per product, per platform ja per quarter eli harrastelijoille ei mitään merkitystä. Unityssä vastaava raja yksityisenä on 100k/vuosi Unityllä tehtyjen tuotoista. Käytännössä siis omien moottoreiden teon pitää tapahtua opettelu-/kokeiluhalusta tai muiden moottoreiden ylitsepääsemättömistä esteistä, jonka pitäisi olla hyvin harvinaista.

 

[peksi]

Kaupallisia "tuotantomoottoreita" alkaa kyllä arvostamaan kun pitää saada koko pipeline toimivaksi - artisti haluaa lopputuloksen olevan työkalussaan mahdollisimman lähellä pelirendaajaa ja sitten pääsee parhaimmillaan tulkitsemaan jotain fbx:n kaltaista kuraformaattia eri tavoin tai jopa vääntämään itse jonkun + exportterin. Aikaa vastaavaan tunkkaamiseen kotikutoisilla engineillä uppoaa yllättävän paljon. Puhumattakaan jos pitää tukea vielä useampaa alustaa tehokkaammin, etenkin mobiilipuolella.

 

[Ctzn_no7]

Omasta mielestä täysin hullu ajatus, että esim Unreal olisi ilmainen. Epicillä on hurja määrä ihmisiä vakituisessa työsuhteessa ja kokonaispalkka lasketaan kymmenissä tuhansissa. 5% tuloista on naurettavan pieni, kun joka ikinen viikko tulee livestriimiä ja uutta asiaa opetetaan ja selitetään.

Tämmöiseen törmäsin:
http://steamcommunity.com/groups/UE4Games
Sieltä ne 5%:set kilisee

 

[iunknown]

LibGDX on ihan toimiva ratkaisu 2d-peleihin, tosin työkalujen kanssa saa varautua hieman kikkailemaan. Muuten tiedossa on leppoisaa Java-koodailua ja sama koodi toimii desktopin ja selaimen lisäksi vielä android ja iOS -vehkeissäkin.

 

[Professori Kaaos]

Mitä mieltä porukka on tuosta CryEngine:stä
Olen vähän aikaa suunnitellut sellaista openworld seikkailu peliä ja pitäisi moottori valita.
Unity on toki hyvä vaihtoehto, mutta haluaisin kuulla mielipiteitä tuosta CryEngine.
Ja tosiaan olen ihan uusi/aloitteleva pelintekijä, c++ ja javaa olen kirjoittanut

 

[Ctzn_no7]

Mitä mieltä porukka on tuosta CryEngine:stä
Olen vähän aikaa suunnitellut sellaista openworld seikkailu peliä ja pitäisi moottori valita.
Unity on toki hyvä vaihtoehto, mutta haluaisin kuulla mielipiteitä tuosta CryEngine.
Ja tosiaan olen ihan uusi/aloitteleva pelintekijä, c++ ja javaa olen kirjoittanut

Sen verran olen kuullut että kehittäjien palkkojen maksussa ollut viiveitä, tiedä sitten kannattaako alkaa investoimaan aikaa moottorin opetteluun jonka tuki voi kipata aika lyhyelläkin aikavälillä

 

[Xiyng]

Mitä mieltä porukka on tuosta CryEngine:stä
Olen vähän aikaa suunnitellut sellaista openworld seikkailu peliä ja pitäisi moottori valita.
Unity on toki hyvä vaihtoehto, mutta haluaisin kuulla mielipiteitä tuosta CryEngine.
Ja tosiaan olen ihan uusi/aloitteleva pelintekijä, c++ ja javaa olen kirjoittanut

Siitä ei ainakaan ole kovin kauan, kun CryEnginen dokumentaatiota moitittiin ja moottoria yleisesti pidettiin kilpailijoita hankalampana ottaa haltuun. Kyvykäs pelimoottorihan se kuitenkin on, joten siinä mielessä varmasti hyvä vaihtoehto. Voisin kuitenkin kuvitella, että jos meinaat tehdä pelin yksin, CryEngine ampuu aika pahasti yli. Todennäköisesti et koskaan pysty hyödyntämään sen potentiaalia tehokkaasti, vaan esim. Unity voisi olla ihan riittävä vaihtoehto. Varsinkin tuo kokemattomuus pelupuolella vihjaa vähän siihen suuntaan, että helpompi vaihtoehto voisi olla parempi aluksi, ja sen jälkeen voi olla helpompi hypätä vaikeamman moottorin kimppuun jos kiinnostaa. Toki jos CryEngine ehdottomasti kiinnostaa etkä pelkää korkeampaa oppimiskynnystä, niin kaikin mokomin kimppuun vaan.

 

[Professori Kaaos]

Taidan kallistua enemmän tuon Unityn puolelle. Onko mitään vinkkejä antaa?

 

[Xiyng]

Taidan kallistua enemmän tuon Unityn puolelle. Onko mitään vinkkejä antaa?

Aika laaja kysymys, mutta heitetään nyt vaikka jotain perusteita:

• Unityn sivuilla on hyvä dokumentaatio lähes kaikesta. Samoin löytyy runsaasti virallisia oppaita, joista suurin osa on videomuodossa.
• Unityn kanssa voi käyttää useampaa ohjelmointikieltä, mutta C# lienee käytännöllisin valinta. Samoin kehitysympäristön voi valita vapaasti, ja ainakin itse olen käyttänyt Visual Studiota. Mukana tuleva MonoDevelop on vähän tönkkö.
• Scene on jokseenkin kenttää vastaava juttu mutta taipuu myös muihin asioihin (esim. valikoihin ja HUD:iin). Sceneen ripotellaan objekteja, joilla on erilaisia komponentteja, jotka käytännössä määrittävät, millaista toiminnallisuutta objektilla on. Skripteillä taas tehdään juurikin omia komponentteja (joissa voi toki hyödyntää normaaleja luokkia yms.). Skriptien olennaisimpia erityismerkityksen omaavia metodeja taas ovat Awake/Start ja Update/FixedUpdate. Unity kutsuu noita metodeita oman mielensä mukaan tietyllä logiikalla, ja muitakin vastaavia löytyy (selviää tutkimalla dokumentaatiota). Awake vastaa jokseenkin normaalia konstruktoria, ja muuten komponenteilla ei sitten käytännössä olekaan konstruktoreja (Unity hoitaa).
• Instantiate-metodin käyttö kovin tiheään tahtiin on nähtävästi myrkkyä suorituskyvylle. (Ei varmaan tule ihan heti vastaan, mutta mainitaan nyt kuitenkin tässä.)
  
• Valmiista komponenteista kiinnostavia ovat ainakin Collider (törmäykset) ja Rigidbody (fysiikanmallinnus muuten). Näistä löytyy melko hyvin myös 2D-versiot, jos haluaa tehdä 2D-pelin.
• Ainakin alussa aika moni ongelma voi johtua siitä, että on tökkinyt väärät rastit päälle komponenttien asetuksista. Esim. komponentin saa otettua pois päältä tällä tavalla hyvin helposti, jolloin se ei myöskään tee käytännössä mitään.
  
• Drag and drop toimii melkein kaikessa (esim. grafiikka- ja äänitiedostot voi vetää Unityyn suoraan).

Onhan noita juttuja muutenkin vaikka kuinka, mutta jos tuo vaikka auttaisi hahmottamaan vähän perusteita. Yksi ensimmäisistä asioista, joita kannattaa kokeilla, on varmaankin ihan yksinkertaisten kontrollien toteutus (nappi pohjaan -> liikkuminen yhteen suuntaan). Jos sitten lisäät fysiikanmallinnuksen ja teet liikkumisen sen avulla, se voi myös opettaa vähän lisää. Esim. triggerien toimintaan tutustuminen voi myös olla ainakin aluksi opettavaista. Pistä vaikka liikkumaton taso sceneen, tason päälle pallo fysiikanmallinnuksella ja törmäyksillä varustettuna, tee tasosta trigger (colliderin avulla), ja koita saada jotain tapahtumaan, kun pallo putoaa tason läpi (vaikka viesti konsoliin noin esimerkkinä). Varmaan voi olla jotain yksinkertaisempaakin, millä pääsee asiaan käsiksi, mutta tuossa kuitenkin pari ideaa joita voi kokeilla aluksi. Kuulostaa yksinkertaiselta mutta on yllättävän opettavaista!

 

[Crom]

Unitystä sen verran vielä näin aloittelijan näkökulmasta että dokumentointi on vähän niin ja näin. Periaatteessa materiaalia on paljon mutta kaikki ei ole välttämättä ajan tasalla ja ohjeet voi viitata luokaan tai funktioon joka on joko poistettu tai nimetty uudelleen.

 

[Xiyng]

Unitystä sen verran vielä näin aloittelijan näkökulmasta että dokumentointi on vähän niin ja näin. Periaatteessa materiaalia on paljon mutta kaikki ei ole välttämättä ajan tasalla ja ohjeet voi viitata luokaan tai funktioon joka on joko poistettu tai nimetty uudelleen.

Onko muuten mielestäsi jossain pelimoottorissa asia selvästi paremmin? Ainakin itse kirosin Unreal Enginen kanssa aloittelijalle vaikeaa dokumentaatiota ja CryEngineä ainakin on joskus parjattu huonosta dokumentaatiosta, ja Unity on ainakin omasta mielestäni ollut silti kohtalaisen hyvä dokumentaation puolesta. Ehkä jossain jonkin verran vähemmän tunnetussa moottorissa on sitten parempi dokumentaatio?

 

[Temezi]

Onko muuten mielestäsi jossain pelimoottorissa asia selvästi paremmin? Ainakin itse kirosin Unreal Enginen kanssa aloittelijalle vaikeaa dokumentaatiota ja CryEngineä ainakin on joskus parjattu huonosta dokumentaatiosta, ja Unity on ainakin omasta mielestäni ollut silti kohtalaisen hyvä dokumentaation puolesta. Ehkä jossain jonkin verran vähemmän tunnetussa moottorissa on sitten parempi dokumentaatio?

Cryengine on aivan surkea documentoinnin kanssa. En tiedä onko nyt parantunut.. Unreal ehkä parhain suurin käyttäjäkunnan takia

 

[demonax]

Itse kun Unitylla joskus aloittelin niin kävin tämän Space Shooter -tutoriaalin läpi. Siinä oppi perusasiat hyvin.

https://unity3d.com/learn/tutorials/projects/space-shooter-tutorial

 

[Bl-Papu]

Itse en saanut CryEnginellä mitään aikaiseksi kun vuosi sitten aloin sitä opiskelemaan. Godot engine on nyt päällimäisenä pinossa ja vaikuttaa hyvältä. Toivon mukaan se yltää 3Dssa pian samaan kuin edellä mainittu.

 

[Lazzu]

Olin positiivisesti yllättynyt miten hyvin Unity (5.4) ja Visual Studio Code toimivat yhteen. Huomattavasti mutkattomampi debuggausprosessi kuin Monodevelopin kanssa. Suosittelen tätä komboa. Vielä kun muutamat bugit saataisiin Codesta pois, niin tämähän olisi täydellinen. Unity 5.5 vielä kuulemma tukee Codea out of the box, kun 5.4 vaati pluginin.

 

[SnakeCase]

Olin positiivisesti yllättynyt miten hyvin Unity (5.4) ja Visual Studio Code toimivat yhteen. Huomattavasti mutkattomampi debuggausprosessi kuin Monodevelopin kanssa. Suosittelen tätä komboa. Vielä kun muutamat bugit saataisiin Codesta pois, niin tämähän olisi täydellinen. Unity 5.5 vielä kuulemma tukee Codea out of the box, kun 5.4 vaati pluginin.

Tätä komboa olen ite käyttäny jo lähes vuoden ja VSCode on tässä ajassa parantunut huomattavasti ja tulee luultavasti edelleen parantumaan. Kerran kuukaudessa tulee uusia ominaisuuksia ja bugi korjauksia saattaa tulla useamminkin. Monodevelopiin päin ei tule kyllä edes katsottua kun siirtyi VSCodeen. Suosittelen varauksetta.

 

[fin_thunderstorm]

Onko kukaan heittäytynyt vielä niin hurjaksi, että osaisi vinkata parhaimmat tavat tehdä VirZoomille peli? Moottoriksi varmaankin järkevintä nakata Unity, kun valmiit paketit. Itsellä tarkoituksena tutustua, että onnistuisiko jonkin asteinen tasohyppelypeli kehittää sen pohjalle. Olisihan se aika hurjaa, kun pystyisi jotain "Mario-kopiota" polkupyörällä ja Vivellä hakkaamaan...