Autor Wątek: UE4 vs CryEngine3 vs Unity4(5)  (Przeczytany 11096 razy)

Offline yarpen

  • Użytkownik

# Marzec 21, 2014, 15:41:32
Nie za szybko placisz te podatki od niezarobionych pieniedzy? :)
Podatek bylby od 950k, te 50k to twoj koszt.

Offline Mr. Spam

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

Offline Ivian

  • Użytkownik
    • Ivian's Cave

  • +1
# Marzec 21, 2014, 16:10:17
Dodatkowo w UE4 programujemy 'naprawde' (chodzi mi tu o to ze mamy dostep do calego projektu w visualu) a nie skryptujemy oraz dostajemy kod zrodlowy a w przypadku naprzyklad kodu nie dostajemy.

Ja wręcz uwielbiam sobie "na prawdę" napisać sobie smart pointery. Codziennie piszę kilka. Lubię też patrzeć co tam się dzieje na stosie, wtedy dopiero czuję się "prawdziwym" programistą.

Nie sądzę, że taki ficzer jest potrzebny jeśli nie chcesz robić AAA. Jeśli kumasz jak biega silnik, to deep dive w jego bebechy jest zbędny. A wygodny język, w którym piszesz, jakim jest C# tylko ułatwia Ci sprawę.

<offtopic> Irytuje mnie podejście do programowania w Unity nazywając to "skryptowaniem" (jako opozycja do "prawdziwego programowania" np. w HTML'u). Nakład pracy jest identyczny, kod który piszesz jest tak samo skomplikowany, a tylko asset w edytorze nazywa się "skrypt" (bo jak go mieli nazwać? Assets->new->CodeFile(C#) ?). Ale o to można się kłócić tak samo jak o to, czy Blizzard jest Indie czy nie.  </offtopic>

Offline deadeye

  • Użytkownik

# Marzec 21, 2014, 16:39:57
Unity osobiscie nigdy nie ogarniałem. Ludzie sobie chwala ten komponentowy system, jakie to proste i wogole jak latwo zaczac. Dla mnie to jest anty-pattern tego jak nalezy pisać i nie byłem i nie jestem w stanie zrozumieć jak sie tym mozna zachwycać.
Tego typu wypowiedzi pokazują właśnie tyle, że ktoś nie ogarnał workflow unity. Unity daje wolność - albo robisz gre skryptująć (podpinając małe fragmenty kodu pod odpowiednie obiekty), albo klasycznie programując - mając jeden entry point który odpala główną pętle, gdzie trzyma się referencje na wszystkie obiekty i wywołuje na nich kod ręcznie.

Przy czym unity nie wymusza żadnego podejścia, zazwyczaj następuje to dość naturalnie - najpierw prototypując skryptuje się zachowania żeby szybko i łatwo sprawdzić co się sprawdza, i nie trzeba bawić się w tworzenie w kodzie struktur danych aby sprawdzic czy dany feature fajnie się sprwdzi, a gdy koncept się stabilizuje i chcemy więcej mocy żeby implementować bardziej skomplikowaną logikę, kod naturalnie układa się w klasycznym stylu (jeden entry point).



Zalozmy, ze moja pierwsza gra (?), jakims cudem przyniesie 1mln $ przychodu. W takim przypadku Epicowi musze zaplacic 50k $. Czy to dużo ? Napewno nie jest to mało. Ale w kontekscie 1mln to jest kropla w morzu.
Trzeba tez wziasc pod uwage, ze koszt wejscia w UE4 jest bardzo niski. Place raz 20$ i moge pracować. Potem dalej nic nie place i moge gre wydać na 4 platformach. Jak mi nie wyjdzie, to strace tylko te początkowe 20$ (nie liczac innych inwestycji).
W przypadku Unity podpisujesz cyrograf odrazu na rok z góry, a kazda kolejna platforme musisz oplacac osobno. Ryzyko inwestycji w Unity jest duzo wieksze.
Zapomniałeś fakt, że Unity jest darmowe na wszystkich platformach i nie bierze żadnego udziały w zyskach. Możesz spokojnie zrobić grę indie bez licencji pro, nawet gry z dopasioną grafiką z drobnymi ograniczeniami można odpalić bez pro. Jedyny zauważalny koszt to wtedy splash unity na początku gry, ale nie płacisz NIC. Żeby dojść do potrzeby używania pro to trzeba robić naprawdę duże projekty lub mieć potrzebę wykorzystania feature wersji pro.

Cytuj
Niemniej pod wzgledem cena/oferowane mozliwosci UE4 wygrywa z kazdym innym rozwiazaniem na rynku.
Z darmowym sie nie wygra :] Natomast jeśli brać pod uwagę płatne wersje, to tak.

Cytuj
Bardziej mnie ciekawi skarbówka, niż to co musze placic Epicowi. Czy US bedzie chciał podatek od 1mln czy od 950k ? To mi juz robi różnice. 
Patrzac na to najprosciej to ja zarobiłem 950k, wiec wydaje mi sie, ze podatek powinien byc od tej kwoty.
To zależy czy założysz działalność gospodarczą. Jeśli tego nie zrobisz, to nie dość że zapłacisz podatek od 1 mln, to jeszcze od około 920k ten podatek będzie wynosił 30%. Jeśli w dodatku będziesz chciał zapłacić część tego znajomemu z którym robiłeś grę, to zapłacisz kolejny podatek ~20%.

Co więcej większość store'ów nie umożliwia zmiany konta prywatnego na firmowe, więc lepiej myśleć przed zarobieniem pierwszego miliona :)
« Ostatnia zmiana: Marzec 21, 2014, 16:57:41 wysłana przez deadeye »

Offline laggyluk

  • Użytkownik
    • twitter

# Marzec 21, 2014, 16:51:21
ktoś ogarnia czy w ue4 na windzie da się zrobić builda na ios? w udk3 się dało co też jest niezłym ficzerem obniżającym koszta

Offline ArekBal

  • Użytkownik

# Marzec 21, 2014, 18:05:25
Nie za szybko placisz te podatki od niezarobionych pieniedzy? :)
Podatek bylby od 950k, te 50k to twoj koszt.
A nie przypadkiem milion przychodu vs 50k kosztów uzyskania przychodu.
Tak samo jak opłata platformy np. steam. Liczysz "chyba raczej" podatek od przychodów zredukowany o poziom kosztów. W innym przypadku przy opłacie na poziomie 50% mielibyśmy 500k przychodu i 500k kosztów. 

Offline iniside

  • Użytkownik

  • +1
# Marzec 21, 2014, 18:19:48
Nie za szybko placisz te podatki od niezarobionych pieniedzy? :)
Podatek bylby od 950k, te 50k to twoj koszt.

Podatki w naszym pięknym kraju to rzecz którą nalezy sie martwić nawet jeśli sie jeszcze nie ma od czego ich płacić :D
Tego typu wypowiedzi pokazują właśnie tyle, że ktoś nie ogarnał workflow unity. Unity daje wolność - albo robisz gre skryptująć (podpinając małe fragmenty kodu pod odpowiednie obiekty), albo klasycznie programując - mając jeden entry point który odpala główną pętle, gdzie trzyma się referencje na wszystkie obiekty i wywołuje na nich kod ręcznie.

Przy czym unity nie wymusza żadnego podejścia, zazwyczaj następuje to dość naturalnie - najpierw prototypując skryptuje się zachowania żeby szybko i łatwo sprawdzić co się sprawdza, i nie trzeba bawić się w tworzenie w kodzie struktur danych aby sprawdzic czy dany feature fajnie się sprwdzi, a gdy koncept się stabilizuje i chcemy więcej mocy żeby implementować bardziej skomplikowaną logikę, kod naturalnie układa się w klasycznym stylu (jeden entry point).
Zgadzam sie. Ale majac wybór nie będe sie zmuszał do poznawania czegoś, co juz przy pierwszym podejsciu odrzuca mnie brakiem jakiejś konkretnej struktury ;).
« Ostatnia zmiana: Marzec 21, 2014, 18:24:44 wysłana przez iniside »

Offline Oti

  • Użytkownik

# Marzec 22, 2014, 15:07:32
Długo nie mogłem się dokopać do info o programowaniu w UE4, ale tu jest:

https://www.youtube.com/watch?v=Q3AvZmZEPyc

Co sądzicie? :) Wydaje się bardzo wygodne przy dwóch monitorach, przy jednym ciągłe przeskakiwanie między okienkami może być uciążliwe. Martwi mnie też czas rekompilacji-na 100% ten gościu ma mega silny komputer, a i tak po małych zmianach w kodzie podczas kompilacji musiał robić 'cięcie'.

Offline iniside

  • Użytkownik

# Marzec 22, 2014, 15:33:41
Z czasami kompilacji to jest troche zabawnie. U mnie cały kod skompilował sie w około 20 minut.

Sredni czas kompilacji samego kodu gry wynosi około 40s. Mozna go zmniejszysc zmienajac ustawienia projektu do jakies 5s,  ale mnie sie niechciało w to bawić, compilator pluł tyloma błędami, ze uznałem, ze to nie jest warte zachodu ;p.

Niemniej, trzeba wziasc pod uwage, ze im wiecej kodu, tym proporcjonalnie czas komplilacji jest krotszy.  Zreszta jesli masz zamiar pisać w gre w Unrealu i piszesz całe elabortay w C++ to znaczy, ze cos robisz zle (;.

Aha kompilowałem na i5 4670K@4.4Ghz.

https://docs.unrealengine.com/latest/INT/Programming/index.html

Offline Oti

  • Użytkownik

  • +1
# Marzec 22, 2014, 16:05:06
Niemniej, trzeba wziasc pod uwage, ze im wiecej kodu, tym proporcjonalnie czas komplilacji jest krotszy.  Zreszta jesli masz zamiar pisać w gre w Unrealu i piszesz całe elabortay w C++ to znaczy, ze cos robisz zle (;.
Nie mam w tym doświadczenia, ale intuicyjnie zakładam, że napisanie logiki w c++ będzie znacznie wydajniejsze niż oparcie jej na blueprintach. No i dla mnie kod jest wiele czytelniejszy niż te klocki. Ktoś gdzieś w necie napisał, że dobrze jest cały gameplay zrobić i dopracować na blueprintach, a dopiero potem, w ostatnim kroku, przenieść go do c++ w celach optymalizacyjnych.

Dzięki za linka. :)

Offline ArekBal

  • Użytkownik

# Marzec 22, 2014, 16:14:47
Mnie to załamuje o tyle... że to znak złej architektury...

Offline iniside

  • Użytkownik

# Marzec 22, 2014, 16:22:49
Nie mam w tym doświadczenia, ale intuicyjnie zakładam, że napisanie logiki w c++ będzie znacznie wydajniejsze niż oparcie jej na blueprintach. No i dla mnie kod jest wiele czytelniejszy niż te klocki. Ktoś gdzieś w necie napisał, że dobrze jest cały gameplay zrobić i dopracować na blueprintach, a dopiero potem, w ostatnim kroku, przenieść go do c++ w celach optymalizacyjnych.

Dzięki za linka. :)

Zalezy kto robi. Np. Przy nowym Fable w Lionhead, wyglada to tak, ze całą mechanike gry robi sie w blueprintach.
Jeśli blueprint jest zbyt skomplikowany, albo zwyczajnie robi to samo co inny blueprint tylko troche inaczej to sie w C++ pisze normalne funkcje ktora pokrywa dana funkcjonlanosc i eksportuje ja do BP.

Straty wydajnosci zwiazane z uzywanie BP, sa pomijalne.

Najlepiej to potraktowac tak:
1. W C++ robimy sobie klocki.
2. W Blueprintach je składamy.

To jest chyba najoptymalniejszy sposob robienia gry w UE4. Chyba, ze ktos wpadnie na lepszy pomysl.

Jesli ktos bardzo niechce sie bawić klockami to inny rekomendowany workflow i tak zakłada, zeby ostatni uzyty obiekt był blueprintem i miał chociaz wyeksponowane jakies wlasciwosci do łatwego tweakowania w edytorze.

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Marzec 22, 2014, 20:43:40
Pytanie: Jak wygląda sytuacja z tą licencją w przypadku gdy to co stworzę na tym silniku nie jest sprzedawane jako oprogramowanie a używane przez firmę do świadczenia usług? (Wiem dziwne pytanko) :)

Offline albinoski1989

  • Użytkownik

  • +1
# Marzec 22, 2014, 20:46:43
ich kodu możesz użyć nawet do swojego silnika, pod warunkiem, że będziesz im oddawał te 5%. Też piszą o jakiś projektach architektonicznych.

a swoją drogą, Unity spadł na 3 miejsce z 1.
http://www.indiedb.com/engines/top
« Ostatnia zmiana: Marzec 23, 2014, 13:50:59 wysłana przez albinoski1989 »

Offline Qbi-Wan

  • Użytkownik

# Marzec 24, 2014, 09:00:11
A ja mam inne kryterium:
- prostota tworzenia funkcji SAVE/LOAD Game
- Level of detail
Jestem w trakcie przenoszenia się z Game Maker na jakiś 3D engine (sory, ale 3. wymiar musi być :P). Tam bardzo pomocna była magiczna funkcja save/load skracająca czas główkowania. Czy któreś z porównywanych narzędzi to wspiera (z tego co zdążyłem wywęszyć to w Unity nie bardzo, pozostaje tam wymyślić własny, bo tutoriale tłumaczą jak zapisać pojedyncze dane).
Druga sprawa - LoD - Domyślam się że dzisiejsze narzędzia nie mają prawa tej funkcji nie mieć, aczkolwiek wypróbowany przeze mnie 3d RAD (teraz nazywa się troczę inaczej) bardzo dziwnie podchodził do tego zagadnienia.

Offline laggyluk

  • Użytkownik
    • twitter

# Marzec 24, 2014, 09:41:04
wiem tyle że LOD jest ficzerem unity pro

a swoją drogą, Unity spadł na 3 miejsce z 1.
http://www.indiedb.com/engines/top
a co to mierzy? bo na pewno nie liczbę wypuszczonych tytułów :P