Autor Wątek: Temat rzeka, UE4 a Unity5  (Przeczytany 4017 razy)

Offline proquest

  • Użytkownik

# Czerwiec 16, 2015, 13:38:04
Cześć, mam pytanie jest ktoś kto testował oba silniki i może coś więcej o nich powiedzieć? Na razie bawię się UE4 i trochę się jeszcze gubię. Może ktoś ma jakieś doświadczenie z obydwoma i mógłby powiedzieć coś więcej? Który bardziej do czego itp? Który bardziej przyjazny, wydajny, "prosty"?
Pozdrawiam.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline koirat

  • Użytkownik

# Czerwiec 16, 2015, 13:47:05
Teraz zaryzykował bym z UE4 za dużo nerwów mnie kosztowało to całe Unity.

Offline komorra

  • Użytkownik
    • Blog naszego teamu (o grze Voxelfield)

# Czerwiec 16, 2015, 14:12:23
Mnie też trochę nerwów kosztowało... koirat, mogłbyś rozwinąć swoją wypowiedź? Czy też Tobie chodzi o to, że przy dużym projekcie "Ciężko ogarnąć" już? Mi się wydaje, że pierdyliard skryptów, rozsianych po pierdyliardzie gameobjectów nie jest za dobry... z UE4 nie mam aż takiego doświadczenia.

Tu jest wątek podobny: http://forum.warsztat.gd/index.php?topic=28690.0

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Czerwiec 16, 2015, 15:58:47
zależy do czego. z pół roku temu zrobiłem prostą gierkę w ue4 i tnie się na fonie na którym podobny projekt zrobiony w unity hulałby aż miło. do tego spakowanie projektu do .apk z rozmiarem poniżej wymaganych przez google play 50MB to była niezła batalia

Offline Kitsune

  • Użytkownik

# Czerwiec 17, 2015, 11:56:57
W zależności jaką grę planujesz.
Unity5 do małych projektów, gier na urządzenia mobilne.
UE4 do "dużych" gier na PC. Wiem, na mobile też można ale pusta scena w UE4 zajmuje całkiem sporo, Unity jest bardziej "mobile friendly".

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +1
# Czerwiec 17, 2015, 12:07:55
Zapomnieliście dodać opcji "własny framework". ;) Próbowałem swego czasu zabawę z Unity 4, ale jakoś niewygodne to środowisko. O porozsiewanych skryptach już @komorra napisał. Możliwość poskładania sceny WYSIWYG jest całkiem fajna, ale co z tego jak z tego co widzę zaleca się, by robić własną serializację, własny edytor w edytorze i ładować content na scenę ze skryptów. Do tego w Unity 4 (nawet Pro) pół renderera z shaderami było jak dla mnie do przepisania, bo lepsze cienie i oświetlenie to już miałem ogarnięte na najsłabszym Radeonie z Shader Model 2.0, i to z wyższą wydajnością. :)

Podsumowując, Unity odwala sporo roboty z przenośnością, daje WYSIWYG do zabawy, ale przy okazji narzuca tyle design patternów, że momentami jest po prostu niewygodnie i nieefektywnie.

Offline jelcynek

  • Użytkownik

  • +2
# Czerwiec 17, 2015, 14:00:11
Oczywiście Krzyśku, jeśli sie umie tyle co ty. Ja jako nie'3dśmienny (czyt. nie popełniłem jeszcze nic w 3d poza paroma trójkątami w oglu i parę prostych projektów w unity) swój framework bym sklejał przez rok i potem by sie pewnie okazało, że jest nie do użytku. W Unity (którego póki co szczerze nie cierpię) mogę względnie "szybko" popełnić coś małego i ukończyć, posiadając tą podstawową wiedzę na temat 3d, którą mam. Po skończeniu PixelPerfekta, chyba właśnie na następny projekt padnie wybór niestety na unity. Być może następny projekt tez będzie 2d, wtedy pod uwagę dojdzie jeszcze kilka frameworków, ale i przy 2d unity oferuje sporo ułatwień.


Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Czerwiec 17, 2015, 18:12:25
A ile lat trwa napisanie własnego cross-platformowego frameworka? :P

wadą unity jest to że dużo ficzerów trzeba albo zaimplemetnować samemu albo nabyć w assetstorze. Powoli się to poprawia ale UE4 wydaje się być bardziej kompletnym rozwiązaniem
« Ostatnia zmiana: Czerwiec 17, 2015, 23:22:04 wysłana przez laggyluk »

Offline koirat

  • Użytkownik

  • +1
# Czerwiec 17, 2015, 21:50:26
Ogólnie Unity3d można zaliczyć do klasy produktów FEFE => fajny edytor,  fatalny engine.

Największą wadą unity jest to że engine jest, jak ja to nazywam "YAGNI" ;) projektanci założyli że skoro oni nie potrzebowali pewnych funkcjonalności to ty też nie będziesz potrzebował. Dodatkowo stwierdzili że pewne bardzo użyteczne funkcje będą dostępne jedynie w namespace UnityEditor i nie będzie się dało z nich skorzystać w grze.

Pod iluzją łatwości w tworzeniu oprogramowania za pomocą tego produktu czai się wiele pułapek. I nie chodzi o to że łatwo sobie strzelić nim w stopę, bo właściwie to on sam strzela ci w głowę.

Żeby nie być gołosłownym przywołam jedynie kilka przykładów, bo i tak już mi ciśnienie podskoczyło na samo wspomnienie.

AnimationClip:
jest AddEvent ale nie ma ani Remove ani Get [edit]co prawda jest "events" ale to ciągle za mało[/edit]
jest SetCurve a nie ma GetCurve

Nawet nie da się w normalny sposób pobrać top most obiektów w scenie.

Nie da się pobrać wszystkich tekstur materiałów itp, bez wrzucania ich do Resources, nawet prefabów się nie da pobrać.

W ogóle nawet nie da się powiedzieć czy dany obiekt jest prefabem.

Nie da się zmienić Meshom ani teksturom z non-readable/non-writable na readable. Najgorsze jest to że na niektóre obiekty nie mamy wpływu i są defaultowo non-readable na zawsze.

Bardzo wielu rzeczy się nie da zrobić bez wcześniejszego przygotowania do tych operacji w edytorze.

Serializacja w Unity to jakiś żart.

W wielu miejscach wywołania Awake Start Enable Disable poprostu potrafią maksymalnie zaskoczyć, wręcz bym powiedział że zaszokować, doprowadzić do race-condition itp.

Nie da się utworzyć obiektu nie aktywnego za pomocą Instantiate , pomimo iż da się w edytorze go utowrzyć disablować i aktywować dopiero w czasie działania aplikacji.

Dziiiiiiiiiiiiiiiiiiwne rozwiązania urągające zdrowemu rozsądkowi takie jak overloading == dla Componentów.

Nie wiadomo z jakiego powodu jest niszczony obiekt kiedy jest niszczony. (OnDestroy)

I wiele wiele innych...
« Ostatnia zmiana: Czerwiec 17, 2015, 22:05:36 wysłana przez koirat »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 18, 2015, 01:56:51
Cytuj
A ile lat trwa napisanie własnego cross-platformowego frameworka? :P
Z tymi latami to nie przesadzajmy. Ja sobie powoli dziobię swojego i choć roboty jest trochę, to nie jest to robota liczona w latach.

Offline Kos

  • Użytkownik
    • kos.gd

  • +4
# Czerwiec 18, 2015, 10:49:40
Z tymi latami to nie przesadzajmy. Ja sobie powoli dziobię swojego i choć roboty jest trochę, to nie jest to robota liczona w latach.
"Całe życie i 6 miesięcy" :-)

Offline iniside

  • Użytkownik

  • +1
# Czerwiec 20, 2015, 21:47:37
Z tymi latami to nie przesadzajmy. Ja sobie powoli dziobię swojego i choć roboty jest trochę, to nie jest to robota liczona w latach.

No ale ty zaliczasz sie do osob ktore wiedza co robia w tym przypadku.

Wiem, ze jak jabym mial pisac wszystko od podstaw to najprawdopodbniej nigdy bym tego nieskonczyl :D.
« Ostatnia zmiana: Czerwiec 21, 2015, 15:58:43 wysłana przez iniside »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +1
# Czerwiec 21, 2015, 02:40:46
Cytuj
No ale ty zaliczasz sie do osob ktore wiedza co robia w tym przypadku.

Wiem, ze jak jabym mial pisac wszystko od podstaw to najprawdopodbniej nigdy bym tego nieskonczyl :D.
A bo to ja skończyłem? Ostatnie dwa dni roboty przy tym minęły mi na nieskutecznych próbach podłączenia się do Maca przez Windowsowe udostępnianie folderów. A to dopiero początek zabawy w dodawanie supportu OS X/iOS. :)

Offline matheavyk

  • Użytkownik
    • rabagames.com

  • +1
# Czerwiec 22, 2015, 01:41:49
Nie ma chyba sensu przekonywać do Unity kogoś, kto go nie lubi. Ale też nie wolno pisać nieprawdy w miejscach, gdzie zaglądają osoby, które nie wiedzą jeszcze na co się zdecydować.

Na pewno Unity wymaga przestrzegania konkretnej filozofii wytwarzania gier. To może komuś nie pasować. Mój styl akurat i tak przez lata doszedł do tego samego, co w jest w Unitym, więc dla mnie jest super.

Ktoś napisał, że mało jest już gotowych rozwiązań, a niektóre "trzeba" pobierać z asset store. Więc odpowiem moją opinią: w Unity jest dużo gotowych rozwiązań, a do tego można ściągnąć masę darmowych (lub płatnych, jeśli ktoś chce) z asset store, który jest swoją drogą bardzo dobrze zintegrowany z edytorem, jeden klik i mamy pliki u siebie.

A @Koirat napisałeś kilka rzeczy, które są zwykłą nieprawdą:

Cytuj
W ogóle nawet nie da się powiedzieć czy dany obiekt jest prefabem.
Ciężko powiedzieć, co masz na myśli, bo żaden obiekt nie jest prefabem.

Cytuj
Nie da się zmienić Meshom ani teksturom z non-readable/non-writable na readable.
Napisałem w zeszłym tygodniu aplikację, w której piszę do tekstury, której wcześniej zmieniłem z non-readable na read/write enabled.

Cytuj
W wielu miejscach wywołania Awake Start Enable Disable poprostu potrafią maksymalnie zaskoczyć, wręcz bym powiedział że zaszokować, doprowadzić do race-condition itp.
U mnie wszystkie Awake wywoływały się przed wszystkimi Start. Miałeś inny przypadek?

Cytuj
Nie da się utworzyć obiektu nie aktywnego za pomocą Instantiate , pomimo iż da się w edytorze go utowrzyć disablować i aktywować dopiero w czasie działania aplikacji.
Przecież robisz Instantiate, a potem zmieniasz enabled na false. No to jednak się da.

Cytuj
Dziiiiiiiiiiiiiiiiiiwne rozwiązania urągające zdrowemu rozsądkowi takie jak overloading == dla Componentów.
Porównywanie komponentów to raczej nie jest dobry pomysł, ale to już zależy od tego, co kto i jak pisze.

Cytuj
Nie wiadomo z jakiego powodu jest niszczony obiekt kiedy jest niszczony. (OnDestroy)
To jest cecha wielu silników, w których pisze się w Javie i C#. One są dodawane na listę do zniszczenia i są niszczone, kiedy silnik zdecyduje, że nadszedł ten moment. Może nie jest to oczywiste rozwiązanie i potrafi wielokrotnie wprowadzić w błąd, ale jak już się w to zagłębić, to jest sensowne. Po prostu trzeba dodawać flagę o nazwie np. "isDestroyed" do obiektów, jeśli zależy nam na dokładnym wykryciu, kiedy były zniszczone.
edit: dokumentacja Unity mówi "Destroy is always delayed (but executed within the same frame)".
« Ostatnia zmiana: Czerwiec 22, 2015, 02:53:19 wysłana przez matheavyk »

Offline koirat

  • Użytkownik

  • +1
# Czerwiec 22, 2015, 10:56:27
Na wstępie mówię iż moje doświadczenie jest związane z Unity3d 4.6 , ale znając politykę unity wątpię żeby wiele się zmieniło w wersji 5 w tej dziedzinie.

No to jedziemy :)

Cytat: matheavyk
Ciężko powiedzieć, co masz na myśli, bo żaden obiekt nie jest prefabem.
Raczej każdy obiekt może być prefabem ale prefab który tworzysz w edytorze zachowuje się inaczej niż twoje obiekty w grze. A nie jesteś w stanie po prostu pobrać wszystkich prefabów z gry bez uprzedniej zabawy w edytorze.

Cytat: matheavyk
Napisałem w zeszłym tygodniu aplikację, w której piszę do tekstury, której wcześniej zmieniłem z non-readable na read/write enabled.
Wrzuć sobie na scenę kilka cube-ów zaznacz im static, teraz spróbuj się dostać do ich wierzchołków w runtime.
Wrzuć sobie na scenę defaultowego particla w runtime dostań się do jego textury poprzez materiał, teraz spróbuj przeczytać wartości tej textury
.
Swoją drogą jak udało ci się zrobić to co piszesz (oczywiście mowa w run-time a nie edytorze) to może napiszesz jak to zrobiłeś, być może zwrócę honor :)

Cytat: matheavyk
U mnie wszystkie Awake wywoływały się przed wszystkimi Start. Miałeś inny przypadek?
Kolejność o której mówisz jest taka, ale są inne problemy niż kolejność.
Np:
Awake nie jest wywoływany dla obiektów nie aktywnych. (skoro ma być traktowany jak konstruktor to chyba by wypadało żeby jednak był)
Wyobraź sobie że dodajesz scene do sceny LoadlevelAdditive i w tym momencie kolejność wywołania Awake na różnych obiektach zdaje się być dość nieobliczlna.

Cytat: matheavyk
Przecież robisz Instantiate, a potem zmieniasz enabled na false. No to jednak się da.
Problem w tym że jak to zrobisz to twój Awake już się wykonał. A jak robisz instantiate na deaktywowanym prefabie to twój Awake się wykona dopiero jak aktywujesz obiekt.

Cytat: matheavyk
Porównywanie komponentów to raczej nie jest dobry pomysł, ale to już zależy od tego, co kto i jak pisze.
Nie do końca był bym takim optymistą. Problem w tym że zależnie od sytuacji zastosowanie == na tym samym obiekcie może dać różne rezultaty.
Nie wiem czy podaje dobry przykład, bo z sytuacją spotkałem się nieco inną:
object obj = comp;
Writeline(obj == null);
Writeline(comp == null);
comp może być np MonoBehaviour
W zależności czy comp jest (Destroyed) czy nie rezultat będzie różny.

Cytat: matheavyk
To jest cecha wielu silników, w których pisze się w Javie i C#. One są dodawane na listę do zniszczenia i są niszczone, kiedy silnik zdecyduje, że nadszedł ten moment. Może nie jest to oczywiste rozwiązanie i potrafi wielokrotnie wprowadzić w błąd, ale jak już się w to zagłębić, to jest sensowne. Po prostu trzeba dodawać flagę o nazwie np. "isDestroyed" do obiektów, jeśli zależy nam na dokładnym wykryciu, kiedy były zniszczone.
edit: dokumentacja Unity mówi "Destroy is always delayed (but executed within the same frame)".
Nie w tym problem. (chociaż to też problem)
Powiedzmy że na którymś z obiektów zostaje wywołany OnDestroy, teraz chce się dowiedzieć czy
a) Aplikacja się zamyka. ( od biedy można kombinowąć z OnApplicationQuit() )
b) Level się zmienia
c) Ktoś wykasował obiekt w edytorze podczas PlayMode
d) Po prostu GameObject.Destroy()

I jeszcze dało by się to przeboleć gdyby nie można było tworzyć obiektów podczas gdy Lewel się zmienia/applikacja się zamyka.

A tak to w momencie gdy chcesz utworzyć jakiś inny obiekt na OnDestroy innego, czekają cię niemiłe niespodzianki.