Warsztat.GD

Programowanie => Silniki => Wątek zaczęty przez: proquest w Czerwiec 16, 2015, 13:38:04

Tytuł: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: proquest w 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.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: koirat w Czerwiec 16, 2015, 13:47:05
Teraz zaryzykował bym z UE4 za dużo nerwów mnie kosztowało to całe Unity.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: komorra w 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
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: laggyluk w 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
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Kitsune w 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".
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Krzysiek K. w 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.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: jelcynek w 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ń.

Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: laggyluk w 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
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: koirat w 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...
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Krzysiek K. w 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.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Kos w 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" :-)
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: iniside w 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.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Krzysiek K. w 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. :)
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: matheavyk w 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)".
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: koirat w 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.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: laggyluk w Czerwiec 22, 2015, 13:17:46
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.
to ja. nie że mało ale braki są a kiedy szukam odpowiedzi na jakiś problem to często kończy się na poradach typu 'kup moją wtyczkę'
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: koirat w Czerwiec 22, 2015, 13:30:42
Często też rozwiązania na storze są bardzo słabej jakości. Raczej bym go używał do zakupu assetów typu media.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: matheavyk w Czerwiec 22, 2015, 15:36:42
@laggyluk
No tak, z tym się muszę zgodzić. Ale też faktycznie jest tak, że się poprawia. Np. nowe GUI w Unity 5, jest już ok. Tutaj akurat bardzo mądrze zrobili, bo zatrudnili do pracy gościa od NGUI (najpopularniejszej wtyczki do GUI na asset store). Bardzo mi się to spodobało. No i teraz wprowadzają jakieś rozwiązanie do łatwego robienia multiplayera, zobaczymy jak to wyjdzie.

@koirat
Przekonałeś mnie teraz :). Poprzednia Twoja wypowiedź nie była dla mnie jasna. Jednak jedno, co powiedziałem muszę podtrzymać - wszystko zależy od stylu programowania. U mnie sytuacje, które opisałeś nie występują w ogóle. Może to moja "wina", a może chodzi o to, że piszę nieduże gry na smartfony.

Co do tekstury: tak zmieniłem opcję w edytorze. Z tym, że ja nie widzę problemu w tym, że większość rzeczy zmieniam w edytorze. Przecież w sumie on od tego właśnie jest. No, ale mam też w swoim podejściu sprzeczność, bo praktycznie nie wrzucam żadnych obiektów na scenę w edytorze, wszystkie tworzę w kodzie. I chyba takie połączenie powoduje, że nie napotykam na nieprzyjemne sytuacje.

Ale co do prefabów, to albo się nie rozumiemy, albo chcesz robić rzecz, która moim zdaniem nie ma sensu, chociażby ze względu na, nazwijmy to, semantykę. Prefab to taki zdefiniowany w edytorze opis właściwości jakiegoś obiektu. To jest taki szkic. Na podstawie tego szkicu można w runtime tworzyć nowe obiekty, ale gdyby się nie miało szkicu, to też można je tworzyć, tylko każdą właściwość trzeba by ustawiać w kodzie. Jeśli chce się koniecznie wiedzieć, które były zrobione przy użyciu szkicu (tylko po co?), to można sobie to gdzieś zapisywać.
Tytuł: Odp: Temat rzeka, UE4 a Unity5
Wiadomość wysłana przez: Jerzykk w Czerwiec 19, 2016, 12:51:21
Do tej pory korzystałem tylko z Unity. Z UE4 nie mam żadnych doświadczeń.

Chciałbym stworzyć grę 3D (strzelanka, widok TPP najpewniej) multiplayer z bardzo dobrą grafiką na PC (i może na konsole w przyszłości) i coś mi podskórnie mówi, że lepszym rozwiązaniem będzie tutaj UE4. Na podstawie tego czytałem tutaj i na innych forach miałbym kilka pytań:

1. Czy Unity ogólnie rzecz biorąc jest lepszy do "małych" gier na smartphony, a UE4 do większych gier na PC i konsole?

2. Czy w Unity piszę się gry szybciej, ale tylko te "mniejsze" na smartphony, natomiast w przypadku większych gier na PC i konsole szybciej można napisać grę w UE4?

3. Jeżeli to o co pytam pkt 2. jest prawdą, to z czego to wynika? Czy może z tego, że jak się chce mięć bardzo dobrą grafikę w grze napisanej w Unity, to trzeba wiele rzeczy napisać samemu (lub dokupić w Asset Store), bo to co jest w Unity nie wystarczy, bo jest na średnim poziomie (no i wiadomo, że wtedy napisanie gry się wydłuży)? Zacytuję w tym momencie jeden z poprzednich postó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ą. :)

A jak wygląda kwestia "renderera z shaderami" w UE4 w porównaniu z Unity? Co jeszcze w Unity jest do poprawienia? Co pozostawia wiele do życzenia w UE4?

Jakość grafiki w silniku to jedno, ale pozostaje jeszcze kwestia dostępnych narzędzi (gdzieś słyszałem, że np. w CryEngine jest świetny edytor terenu, dużo lepszy niż w Unity)?

Więc jak ogólnie rzecz biorąc UE4 wypada w porównaniu z Unity jeżeli chodzi o jakość grafiki i dostępność narzędzi?

Bo jeżeli UE4 bierze tu zdecydowanie górę, to jaki sens pozostawania przy Unity, skoro nawet jeżeli nauka UE4 będzie trwała dłużej niż Unity (o to pytam w pkt 4), to później dzięki temu, że UE4 jest dużo lepszym silnikiem do gier z bardzo dobrą grafiką zaoszczędzę mnóstwo czasu i pracy nie musząc udoskonalać samemu tego co jest domyślnie w Unity na średnim poziomie?

4. Niektórzy piszą, że nauka UE4 trwa dłużej niż Unity. Jeżeli to prawda, to z czego to wynika?