Unreal vs Unity

Zitat von Sleepy

Im Klartext: Du zahlst Steuern von 1,1 Millionen und dann möchte Epic Games die 5% ebenfalls von 1,1 Millionen. Das heißt die 5% von 1,1 Millionen werden zwar aus deinem Brutto berechnet gehen aber von deinem Netto weg.

Das ist ja aber eben nicht der Fall. Epic möchte die 5% von (1.1 Mio - 1Mio), was dann 5k entspricht. Das die dann von deinem Netto weg gehen ist klar.

Zitat von Sleepy

Nein eben nicht da sowohl das Finanzamt also auch das Geld von deinem Bruttoumsatz haben möchte.

Du bezahlst nicht erst Epic Games und das Finanzamt holt sich dann das Geld aus dem was übrig bleibt.

Habe nie was anders behauptet, trotzdem will Epic nicht 5% von deinem Brutto Umsatz sondern 5% von deinem Brutto Umsatz - 1Mio.

Quelle: https://www.unrealengine.com/en-US/faq

Da habe ich aber was losgetreten... xD

Ich sehe das so wie Sleepy (vor allem der Vergleich mit dem Linux-Forum ). Beide Engines haben auf jeden Fall ihre daseinsberechtigung.

Wir können natürlich einzelne Features raussuchen und sie 1:1 vergleichen, aber manchmal spielen noch andere Faktoren eine sehr große Rolle.

Es kommt auch immer drauf an wie viel Erfahrung die Person mit der Engine hat.

Als ich zum ersten Mal Unreal gesehen habe dachte ich nur, ooof wie will Unity denn da mithalten??

Dann habe ich mehrere Unreal Tutorials geguckt und war mir sicher, dass diese auch von der Handhabung einfach die beste Engine sein muss. Das hat sich mir auch bestätigt als ich mir mal Unity runtergeladen hatte, um bisschen auszuprobieren.

Und da war auch schon das Problem: Ich habe Unity nur ausprobiert.

Ohne viel Zeit und Arbeit reinzustecken und Unity als eigenständige Engine zu verstehen habe ich ständig Vergleiche zu Unreal gezogen und dementsprechend fiel mein Urteil dann auch aus.

Ähnliches kann man auch bei Blender und Maya, 3ds Max etc. beobachten.

Der auf der Hand liegende Vorteil von Blender: OPEN SOURCE und völlig kostenlos. Trotzdem hört man von vielen Seiten, dass Maya besser zu benutzen sei und die Steuerung viel besser wäre. Frag das mal einen, der mit Blender angefangen hat. Allein die ganzen "Tutorials" von Leuten, die Blender anscheinend Speedrunnen und super effizient arbeiten können genau wegen dieser komischen Steuerung xD

Jetzt wo ich eine sehr lange Pause von Unreal hatte sah ich auch sehr viele Unity Tutorials und war tatsächlich begeistert davon wie Unity funktioniert.

Also gab ich Unity nochmal eine Chance und muss sagen, dass ich jetzt sehr zufrieden bin und damit auch meinen Usecase besser mit Unity erfüllen kann als mit Unreal, denke ich.

Und natürlich hängt es auch vom Usecase ab. Ich kann nicht sagen, dass ich aber unbedingt mit Unity eine Architektur Viz zaubern möchte, obwohl Unity gar nicht die Grundstruktur dafür bietet und mich dann über Unity beschweren. Das sehe ich so wie Veelos

Zitat von Veelos

5. Multiplayer

Soweit ich weiss sind derzeit alle Multiplayertools von Unity deprecated und funktionieren mehr schlecht als recht. Man kann hier aber Unity verstehen, dass sie keinen grossen Fokus auf dieses Feature legen, da Multiplayer Spiele ja mehr eine Randerscheinung in der Spielebranche sind, hust ja genau... . Wenn man also MP in Unity will, darf man den schön brav selber implementieren.

Unreal im Gegensatz bietet mit den OnlineSubsystem ein Interface für Replikation und bietet darüber hinaus ein Plugin für das Steam Matchmaking.

Klar, das eine Engine möglicherweise den Multiplayer einfacher zur Verfügung stellt möchte ich gar nicht beurteilen (dafür wüsste ich auch zu wenig darüber). Was ich weiß ist, dass es trotzdem sehr viele Leute gibt, die auch mit Unity einen wunderbaren Multiplayer zaubern. Die benutzen nur halt ihre Mittel, die ihnen von Unity zu verfügung gestellt werden am Besten. Wenn ich natürlich frisch von Unreal komme mit der Einstellung, dass da schon ein MultiplayerSystem-Template oder ähnliches auf mich wartet, dann werde ich enttäuscht.

Was ich damit nur sagen möchte ist, dass erfahrene Unity-Nutzer auch den Multiplayer letzendlich implementieren können, weil sie die Engine spezifischen Features besser kennen als Unreal-Nutzer. Möglicherweise findet der Unity-Nutzer das Multiplayer-System von Unreal besser, aber weiß, dass seine Erfahrung in Unity einfach gold wert ist und eine Umgewöhnung auf einen anderen Workflow dafür einfach zu viel Zeit frisst.

So nach dem Motto richtige Balance zwischen Exploit und Explore

Hier ein interessantes Video dazu für die, die es interessiert haha

Ich möchte hier auch gar nicht argumentieren was die beste Engine ist oder so, ich wollte euch einfach nur meine Erfahrung teilen, wie ich das damals und heute empfunden habe

Zitat von BlueSwap

Klar, das eine Engine möglicherweise den Multiplayer einfacher zur Verfügung stellt möchte ich gar nicht beurteilen (dafür wüsste ich auch zu wenig darüber). Was ich weiß ist, dass es trotzdem sehr viele Leute gibt, die auch mit Unity einen wunderbaren Multiplayer zaubern. Die benutzen nur halt ihre Mittel, die ihnen von Unity zu verfügung gestellt werden am Besten. Wenn ich natürlich frisch von Unreal komme mit der Einstellung, dass da schon ein MultiplayerSystem-Template oder ähnliches auf mich wartet, dann werde ich enttäuscht.

Was ich damit nur sagen möchte ist, dass erfahrene Unity-Nutzer auch den Multiplayer letzendlich implementieren können, weil sie die Engine spezifischen Features besser kennen als Unreal-Nutzer. Möglicherweise findet der Unity-Nutzer das Multiplayer-System von Unreal besser, aber weiß, dass seine Erfahrung in Unity einfach gold wert ist und eine Umgewöhnung auf einen anderen Workflow dafür einfach zu viel Zeit frisst.

Versteh mich bitte nicht falsch. Ich habe nie Behauptet, dass Multiplayer in Unity nicht möglich sei. Soweit ich es beurteilen kann sind die MP Ansätze in Unity aktuell aber zu einem Grossteil Custom.

Das muss per se auch nichts schlechtes sein. Je nach Use Case könnte es zum Beispiel sein, dass du extrem auf deine Bandbreite achten musst und deshalb auf eine eigene Umsetzung der Replikation setzen musst. In so einem Fall würde ich Unity sogar bevorzugen, da es für mich einfacher iwelche Custom Replication in Unity einzubauen als mich in das Subsystem Interface von Unreal einzuarbeiten.
Möchte ich aber das Standard Steam Coop Erlebnis setze ich auf Unreal und das drag & drop klicki bunti.

Tatsächlich habe ich bis auf wenige Dinge (Wie zb, dass es Unity scheinbar nicht hin bekommt halbwegs stabile Builds raus zu hauen) nichts gegen Unity einzuwenden. Ich habe mit beidem gearbeitet und je nach Use Case wechsle ich zwischen Unity, Unreal oder auch anderen Engines wie Godot hin und her. Im Grundsatz funktionieren die nämlich alle gleich .

Der Rest ist persönliche Präferenz.

Gäbe es einen Unreal Bashing Thread könnte ich da auch das eine oder andere dazu erzählen .

Also bei Unity und Unrealengine gibt es schon einige Unterschiede. Ich habe es (ausser zum Asset Export) schon lange nicht mehr genutzt, also wenn ein Punkt veraltet ist korrigiert mich. Ich versuch mal rauszustellen was ich persönlich an beiden Positiv und negativ finde:

Unity:

Pro:

- Sehr kleine Built size

- Großes Angebot an Assets im Marketplace

- Große Community und großes ANgebot an Tutorials/Hilfe/etc

- Moderne C# Sprache

- Support von Browserbasierenden Appz

Contra:

- Viele qualitativ bescheidene Assets im Store

- Plattformunabhängig (WebGL) nur mit IL2CPP, JIT nur Windows nativ

- Shader System ein Alptraum, das einzige was ich damit hinbekam war von Shadertoy klauen

- Materialeditor eher altbacken

- Sehr große C# Files können schnell unübersichtlich werden. Da fang ich wieder an zu dokumentieren

- Performance Profiler altbacken und zu oberflächlich

Unreal Engine 4:

Pro:

- Debugging. Mit Blueprints ein Traum.

- Sehr starker Materialeditor

- Blueprint Code praktisch zumindest zum Teil "Selbstdokumentierend" und Übersichtlich (Wenn ich ihn anordne)

- Shader sehr einfach zu erstellen

- Particle System, AI System, Animationssystem sehr ausgereift

- Analysesystem (Profiler) sehr ausgereift

- Raytracing/DLSS auf NVidia Karten überzeugend

- Viele nützliche Technologien kostenlos (Quixel, Live Link Face, etc)

Contra:

- Dependancies etwas umständlich (Plugins/build.cs)

- C++ etwas altbacken

- Riesige Buildsize (Leeres Project mit default/dependancies 300 MB!)

- Light Baking cool aber Shader kompilieren nervt und lahm - 6000 Shader bei "leerem" Projekt

- Kein offizielles WebGL mehr (Sehr schade!)

In vielen Punkten gebe ich dir ja recht, aber du kannst aber nicht C++ und C# vergleichen. Schon alleine C# als modern zu bezeichnen und C++ als altbacken ist ein sehr großer Fehler.

Das Konzept von C# ist ein absolut anderes, schon alleine weil C# keine echte Compilersprache im eigentlichen Sinne ist, auch wenn von Microsoft und im Web diese öfter als solche bezeichnet wird. Da kommen wir dann auch zu einem großen Nachteil von C#. C# Binarys kannst du ganz leicht recompilen und hast als außenstehender den kompletten Sourcecode zur Verfügung. Nur um hier mal nicht das Argument von Geschwindigkeit, sondern auch Sicherheit zu nennen.

Aber genau das macht C# auch langsamer, denn die Binarys sind nur precompiliert. Dadurch wird auch die plattformübergreifende Funktionalität hergestellt. Denn es benötigt ein .NET kompatibles Framework, wie zum Beispiel .NEt oder Mono, damit die Binarys zur Laufzeit dann endgültig interpretiert werden können.

Das ist zwar jetzt nur eine Kurzfassung und vielleicht auch etwas holprig erklärt, aber es zeigt halt den großen Unterschied auf. Es ist zwar nicht so schlimm wie bei Interpretersprachen wie Basic oder ähnliche, aber es ist halt auch nur eine Zwischenlösung.

IM Gegenzug musst du dich in C++ natürlich um vieles, bzw. alles, selber kümmern, was Speichermanagement usw. angeht. Dadurch neigen Programme, wenn man da etwas unsauber arbeitet, leichter zu Fehlern. Aber, wenn du die absolute Kontrolle über dein Programm haben willst, kommst du bei C# nicht unbedingt weiter.

Das Konzept an Sich ist einfach komplett anders. Wenn ich ein Programm schreiben würde, wo der User ein paar eingaben machen muss, ein paar Ausgaben bereitgestellt werden, irgendeine Datenverwaltung mit Windowsoberfläche und es reicht wenn ich das Programm mal eben so zusammenschuster und natürlich auch wenn ich eine Sprache brauche, die ich relativ schnell erlernen kann, dann ist C# durchaus meine erste Wahl.

Wenn ich jedoch Anspruch auf Optimierung lege, dann kommt nur C++ in Frage.

Und ich weiß selber wie schwierig es ist C++ zu lernen, zumal, siehe meinen letzten Hilfegesuchenbeitrag, es auch Situationen gibt in der C++ sich anders verhält als erwartet. Von daher kann ich schon verstehen, wenn jemand meint C# wäre moderner weil einfacher und nicht ganz so fehleranfällig. Aber eigentlich ist das Ziel beider Sprachen einfach nur unterschiedlich. Und C++ wird auch nicht so schnell unmodern werden, weil es wird ständig weiterentwickelt. Also es ist nicht so, dass das heutige C++ noch genau dasselbe ist wie vor 30 Jahren oder so.

Doch natürlich - man kann jede Programmiersprache vergleichen.

"Altbacken" - sorry für den begriff - aber ist meine persönliche Meinung. Natürlich wird C++ immer weiterentwickelt - und C++ 20 mit allen Boost libraries ist schon sehr mächtig - mein "Altbacken" bezieht sich eher auf die Syntax und die ganzen Eigenarten.

Die Performance Diskussion ist schon so uralt wie praktisch jede Kritik - grundsätzlich ist die Garbage Collection bei C# .net natürlich "lahm" - bei C++ ist der Charme und der Fluch aber auch daß du selber deine Objekte im Speicher managen musst. Glaube ich muß jetzt nicht breittreten woher viele bugs in C++ herrühren...

Wer die absolute Kontrolle will der schreibt in Maschinensprache - aber da hatte ich ja schon mal ne lange Abhandlung geschrieben zum Thema "blueprints vs C++ - nur C++ ist eine "richtige" Programmiersprache (Jaja wers glaubt)".

Precompiled, JIT, usw - da hast du meinen Post wohl nicht komplett gelesen weil ich ja gerade auf IL2CPP und JIT herumgehackt habe. Du kannst dich ja bei Unity "bedingt" entscheiden wie du kompilierst. Ich sage mal "bedingt" - weil klar kannst du unter WebGL kein JIT verwenden - da geht offensichtlich nur IL2CPP. Aber auch ansonsten ist es oft eine Glaubensfrage ob man nun unter Android besser gegen Mono oder IL2CPP komiliert. Wenn du Mono nicht magst oder die Performance nicht passt dann verwende es doch nicht, das ist ja dir selbst überlassen - aber ansonsten spricht doch nix dagegen.

Ich weiß dank Boost gibts inzwischen auch in C++ fast "jeden Scheiss", aber die ganzen dependancies und Deklarationen finde ich doch (man verzeihe mir den Begriff abermals) - altbacken. Ich finde es in .net/mono einfach schön die ganzen Klassen so übersichtlich und griffbereit zu haben ohne jetzt lange wühlen zu müssen in welcher boost jetzt was drin ist und die dann erst wieder runterzuladen (Ja ich nutz vcpkg!) und einzubinden. Klar ist alles ansichtssache - ich will ja keinem C++ madig machen und ich nutz es ja auch täglich - aber "modern" ist was anderes. Und Danksagung daß es beides gibt - die Welt wäre blöd und langweilig wenn jedem das gleiche gefallen würde.