Hogyan kell játékot készíteni, írni?

#19

Te is csak képen láttál unity t. :) De egyébként fura a logikád, ha egy eszközzel gyorsan tudsz dolgozni az.. negatív dolog?

#21 Az attól függ, hogy a gyorsaság mennyire megy a minőség rovására! :)

(Játékok terén itt elsősorban az optimalizációra gondolok.)

Nem ismerem a unity-t, de tény, engem kicsit a kínai tömegtermelésre emlékeztet ez a gyorsaság és ha megnézzük a most megjelenő programokat vagy weboldalakat akkor lehet nem is alaptalanul. Úgy szaporodnak a kódok, mint a nyulak, de egyik rosszabb mint a másik. Nagyon furcsa irányba ment el ez az egész... (persze a gyártók ennek örülnek, hiszen minél optimalizálatlanabb egy kód, annál erősebb gépeket fogunk venni). Lassan a böngészéshez is 8GB RAM kell majd a gépbe...

Szóval: Jó munkához idő kell, a rosszhoz pedig egy erősebb gép.

Lehet a unity jó ilyen szempontból (nem tudom, nem próbáltam).

> Te is csak képen láttál unity t. :)

Másfél évig dolgoztam vele, épp elég volt. Engem már nem nyűgöznek le a Unity3D-s tech videók, hiába real time ha két jelenet között 10 perceket tölt. A webes része gyakorlatilag használhatatlan lett, a WebPlayer plugin működött a HTML éppen hogy megy, ráadásul a feature-ok nagy része hiányzik. Eddig 5 mega volt egy kis játék, most 200 MB letölt mert plugin híján az egész engine le kell tölteni.

A js fordítást meg sem említem. Gyakorlatilag js -> C# kód -> intermadiate byte kód -> C++ -> emscripten -> js egy szörnyszülöttet alkot és ez csak js-ről js re fordítás. A Unity3D egy agyon hypolt vacak mindig is az lesz. Van aki ért hozzá láttam szép dolgokat benne de ennyi.

> De egyébként fura a logikád, ha egy eszközzel gyorsan tudsz dolgozni az.. negatív dolog?

Ha 2 hónap után az egyszerűsége bekorlátoz akkor igen. Meg az sem túl jó dolog, ha minden 3. dolgot valami ostoba hack-el kell megoldani, mert amúgy nem támogat szinte semmit az alap dolgokon kívül.

És jah egy erőforrás-zabáló ugrálás játékot össze lehet dobni vele gyorsan. Tök jó.

#22 A kínai tömegtermelés tényleg jó szó a Unity-t illetően :))

Nagyon egyszerűen és gyorsan lehet benne dolgozni, ezért kerül fel a netre a sok selejt. Ez persze nem azt jelenti, hogy nem lehet benne szépen dolgozni, csak az Unity logó a játék elején kemény előítéletet hoz :(

#23

Nem tölt 10 perceket, ha igen, akkor valamit kimondottan rosszul csinálsz - mellesleg adatot olvasni a hdd ről lassú volt mindig is, de a lehetőség adott, töltögethetsz a háttérben is.

A js nem js, egy js re emlékeztető szintaxisú script nyelv, aminek a becsületes neve unity script, csak a közelnyelvben hívják javascriptnek.

A webes rész ugyanúgy működik ahogy eddig is, a google nál reklamálj amiért nem engedélyezik a webplayer t - egyébként megnézném, hogy miken dolgoztál az alatt a másfél év alatt, ha a webplayer a legnagyobb problémád..

Unity tech videók soha nem nyűgöztek le, technológiában mindig is a konkurencia mögött kullogott, általában jelentősen, viszont gyorsan lehet vele dolgozni(na meg egy sokkal inkább általános célú engine, mint egy CE\UE - ha neki akarsz állni pl egy rts t csinálni ezekben foghatod a fejed egy darabig, de tény, fps\tps re olyan tekintetben jobb választás, hogy sok eszközzel rendelkeznek amivel a Unity nem).

Az egyszerűsége miben korlátoz, egészen konkrétan? Egyáltalán hogy érted, hogy egyszerű? Akármit meg tudsz benne csinálni, a legnagyobb probléma az lehet, hogy lassú a kód - ami btw nem probléma, mert nem számításigényes dolgokat írsz benne(pl fizikát), játékmenetet, AI t rendszerint script nyelvekben írják, a c# meg ugyanolyan sebességgel fut minden engine alatt. Sőt, ami azt illeti kódolhatsz pl c++ ban is, csak épp egy dll be kell fordítanod - a c++ sebessége remélhetőleg már megfelel, nem tudom hallottál-e már róla, de néhányan használják.

#26

> egyébként megnézném, hogy miken dolgoztál az alatt a másfél év alatt, ha a webplayer a legnagyobb problémád..

Egy ügyfél akart ultrahang felvételeket megjeleníteni. Így került elő a Unity3D mert hogy az 3D meg elég ismert a hype-ja miatt. Előtte dolgoztam már benne, mobilos játékot írtunk, így volt tapasztalatom és én lettem a lead dev.

A megrendelőnek volt egy WinForm-os megoldása és a külsős "szakértőnk" kitalálta, hogy szeretnék újra felhasználni a kódot merthogy úgy olcsóbb lesz a fejlesztés. Próbáltuk mondani, hogy a Unity-ben C# script van és nem egyenértékű a .Net fw-el, főleg nem fog működni. Ennek ugye az lett a vége, hogy kb annyi idő ment el a migrálással, mintha újra írtuk volna az amúgy elég szerény kódbázisukat.

Ettől függetlenül egész jól ment a dolog, egészen addig amíg nem akarták web-re kitenni. A WebPlayer a desktophoz képest a felét sem tudja a engine grafikus feature-öknek. Nincs render to textue, 3D texture és sok shader függvény nem fordul le. A régi pluginos WebPlayer még tudott pár trükköt de a html5-össel ezek is elvesztek.

Az idő 90%-ban hackeltünk, próbáltuk megkerülni a motor limitációit.

Az egyszerűsége pedig szerintem valóban probléma, az UE-t sokan kritizálják, hogy C++-os meg hogy bonyoluolt a kódja, valóban nagyobb a learning curve-ja, de később ez visszahozza. Abban is dolgoztam fél évet és azt kell mondjam többre jutottam mint a Unity-ban másfél év alatt. A kezdeti gyors egyszerű fejlesztésnek később nagy böjtje lett. Ha már delegációkat, konkurrent szálkezelést, vagy komolyabb polimorfizmust akarsz a Unity megőrül tőle. Debuggolni nagyon körülményes VS-ben még nem is webplayer debuggolni. A monodevelop meg olyan mintha 10 évet visszamentem volna az időben.