spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Renegade«

- mono.NET 2.6 & c# 3.0 (von 2009!)
- kein offizieller linux support für den editor
- kein eigenes reference linking in der solution möglich
- kein einzigartiger main-Einstiegspunkt vordefiniert
- Grundgerüst lädt dazu ein Logik und Daten zu vermischen (imo falsche Interpretation von CBSE)
- der Input-Manager ist katastrophal und seit Version 2 kaum verändert wurden
- native Plugins zu schreiben gestaltet sich schwieriger als es sein sollte (z.B. bei Android noch kein vollständiger gradle support)
- kein integrierter git support
- kein integrierter YAML support, obwohl intern verwendet
- Reflection anstatt Interfaces für MonoBehaviour Methoden (imo eine äußerst schlimme Design-Entscheidung)
- immernoch kein exklusives pathfinding für 2D, sowie frei wählbare Suchalgorithmen (wie wär's mal mit 'nem JPSA, wenn man Navigation Costs/Areas gar nicht benötigt)

Was haltet ihr davon, wenn wir meine Liste einmal konstruktiv fortführen? Dabei lasse ich aber einfaches: 'Weil sie bei mir abstürzt' nicht gelten! Konkreter sollte es schon sein. Der Editor ist im Vergleich zur Konkurrenz äußerst stable, imo. Hier also weitere mögliche Kritikpunkte:
- der Terrain-Editor (oder eher Component?) ist veraltet und bieter kaum wirkliche Funktionalität (Unreal und Cry haben da deutlich die Nase vorne)
- Der Editor bietet keine integrierte Möglichkiet für Tile Mapping (2D Games) oder eine Asset Pipleine für Tiled Daten (soll aber bald folgen?!)

Zitat von »PaRaLLaX«

Wie sieht das eigentlich mit C# und .NET aus? Ein Kollege hat als negativen Kritikpunkt immer angegeben, dass man einfach den Code auslesen kann. Außerdem lese ich viel darüber, dass man Unity Games mit einem "DotNetResolver" relativ einfach manipulieren/hacken kann. Da allerdings Hearthstone mit Unity gebastelt wurde... bezweifel ich einfach mal, dass man sich problemlos unendlich Mana 'hacken' kann...?! Ich sehe da zwar nicht so genau durch, aber das mit dem Auslesen des Codes müsste doch eigentlich stimmen, da C# anders funktioniert bezüglich des Interpreters und Compilers?! C++ hingegen ist ja viel hardwarenäher und somit kann man den Code nicht (oder nicht so einfach...) auslesen?!

Ich bin mehr im Design Bereich unterwegs, daher kann ich Unity durchaus empfehlen (außer man will ein Portfolio aufbauen und hat den Anspruch, dass die Leute das möglichst unkompliziert spielen können... weil da sieht's mit Unity und Google Chrome doch eher mau aus ...). Mich erschreckt bei sowas eher die Vielfalt... ich kann nämlich nicht wirklich einschätzen, was nun wirklich "gut" und was dann doch eher "schlecht" bzw. für meine Zwecke ungeeignet ist. Aber das ist denke ich auch nur eine Sache der Gewohnheit bzw. wie sehr man sich in der Engine auskennt?!

C# und VB wird zu IL compiliert. Dieser IL Code ist lesbar und wird von der CLR ausgeführt. Quasi wie der Java bytecode für die JVM.
Dadurch das der Code im IL vorliegt, kann natürlich der ursprüngliche C# Code generiert werden. (Nicht 1 zu 1, aber schon ziemlich gut) Entgegenwirken kann man hier mit einem Dotfuscator.
Es gibt jedoch bereits .net native toolchain, was den C# Code in C++ übersetzt. Oder AOT compilation... Man weiß sich auf jeden Fall zu helfen. Selbst ohne Maßnahmen muss das Spiel eben so geschrieben werden, dass selbst wenn der Client modifiziert wird, der Server das erkennen kann und dementsprechende Maßnahmen einleitet. Denn alle (nicht nur C# Applikationen) Spiele können prinzipiell am Client modifiziert werden.

Zitat von »CodingChris«

Zitat von »Renegade«

Zitat von »BlueCobold«

[...]

Gebe ich dir recht - das richtige Tool für die richtige Aufgabe. Verstehe mich bitte nicht falsch, ich verteidige die Engine nicht. Ich beurteile lediglich aufgrund des aktuellen Marktes und der Features. Und in Bezug auf Spiele-Entwicklung ist (umso bedeutender im Mobile-Markt), aufgrund der Vielfalt von Geräten und Plattformen, kaum eine andere Engine dazu fähig so viel zu bieten. Das ist keine Frage des persönlichen Geschmacks, sondern Tatsache. Wie dem auch sei, ich frage mich indes immer noch ob du konkrete Gründe kennst.

Hier mal ein paar negative Aspekte die mir persönlich schon häufig auf den Senkel gingen:
- mono.NET 2.6 & c# 3.0 (von 2009!)
- kein offizieller linux support für den editor
- kein eigenes reference linking in der solution möglich
- kein einzigartiger main-Einstiegspunkt vordefiniert
- Grundgerüst lädt dazu ein Logik und Daten zu vermischen (imo falsche Interpretation von CBSE)
- der Input-Manager ist katastrophal und seit Version 2 kaum verändert wurden
- native Plugins zu schreiben gestaltet sich schwieriger als es sein sollte (z.B. bei Android noch kein vollständiger gradle support)
- kein integrierter git-support
- kein integrierter YAML support obwohl intern verwendet
- Reflection anstatt Interfaces für MonoBehaviour Methoden (eine äußerst schlimme Design-Entscheidung die laut Unity kaum mehr rückgängig zu machen ist)
- immernoch kein exklusives pathfinding für 2D sowie verschiedene wählbare Algorithmen (wie wär's mal mit 'nem JPSA @Unity?!)

Dinge die momentan verbessert werden, die Du angesprochen hast:

- .NET 4.6
- Linux Editor als experimentelle Version
- neuer Input-Manager als experimentelle Version
- MonoBehaviour wird durch ScriptBehaviour ersetzt (statt "Magic-Methods" werden dort virtuelle Methoden und Interfaces benutzt)

Ich persönlich denke, dass die Leute bei Unity da einiges verbessern werden und sich der Probleme bewusst sind.

Wie kommt ihr auf 4.6? Quelle bitte.
Ich dachte Unity läuft auf Mono (Linux, Mac) und ist somit auf 3.5 beschränkt?

Zitat von »Renegade«

Was haltet ihr davon, wenn wir meine Liste einmal konstruktiv fortführen?

Ja, das ist mal ein guter Einwurf. Ich wollte auch gerne ein paar Punkte beitragen, allerdings hast du meine kritischen Schmerzpunkte bereits erfasst, besonders der Punkt fehlender "main". Eine vernünftige DI-technik ohne Singletons/ DontDestroyOnLoad würde mich deutlich motivieren, mehr mit Unity zu machen.

Zitat von »Toemsel«

Wie kommt ihr auf 4.6? Quelle bitte.
Ich dachte Unity läuft auf Mono (Linux, Mac) und ist somit auf 3.5 beschränkt?

Weil es bei der Unite'16 in der Roadmap Session steht:

Unite'16 Roadmap Scripting

MfG Chris

Wobei sich das mit dem IL bald erledigt hat, wenn alle Platformen IL2CPP unterstützen. Bei iOS und Android wird die IL in C++ convertiert und erst dann kompiliert. Damit lässt sich dann der Code nicht mehr so leicht analysieren. Sobald also IL2CPP auf jeder Platform existiert ist dieses Problem gelöst.

Das größter Problem bei Unity für mich ist, die Installsize und Speicherverbrauch. Bei mobilen Spielen muss man einiges an Aufwand investieren um eine gute Lösung mit AssetBundles zu bauen damit man unter dem 100 OverTheAir Install Limit bleibt.

Mich persönlich stört an Unity der Scene-Editor. Im Prinzip muss das ganze Level in Blender erstellt und dann exportiert werden.
Verglichen mit älteren 3D Engines wie 3D Game Studio empfinde ich das als unnötig aufwändig. Vor allem, weil immer mal wieder beim Exportieren
irgendein kleinerer Fehler auftritt, so dass ne Textur fehlt (bzw. erneut zugewiesen werden muss), oder ein kleineres 3D Objekt falsch in der
Szene orientiert/positioniert ist.

Wieso muss das ganze Level in Blender erstellt werden? Das finde ich ja bei Unity so genial, das man sich durch EditorScripts extreme leicht schöne Tools bauen kann um seinen Level aus Bausteinen, die aus Blender kommen, zusammen bauen kann.

Zitat von »Mirlix«

Wieso muss das ganze Level in Blender erstellt werden? Das finde ich ja bei Unity so genial, das man sich durch EditorScripts extreme leicht schöne Tools bauen kann um seinen Level aus Bausteinen, die aus Blender kommen, zusammen bauen kann.

Wie gesagt verglichen mit älteren Engines in denen es bereits Presets für für Räume (Hollow Cubes) gab und man selbst Durchgänge in die Geometrie schneiden konnte. Alles ohne Blender. Und ja vllt. kann man sich das iwie über Scripts zusammencoden, besser fänd ich aber, wenn es entsprechende Grundfunktionen gäbe. Zumal man dann nicht extra eine 3D Modellierungssoftware erlernen muss, um einen einfachen Levelprototypen zu bauen. Wobei ich mit "einfach" Levelprototypen mit unterschiedlichen Räumen und Geheimgängen, mehreren Stockwerken, Treppen/Aufzügen, Lüftungsschächte, Fenster und ähnlichen Durchgängen, meine.

Es gibt gefühlt viel zu viele Leute die mit Unity "programmieren", aber eigentlich keine Ahnung haben was sie tun und eigentlich nur so lange herumcopypasten bis es irgendwie tut was es soll. Sowas wird dann im Forum usw weiter verbreitet und so weiter und so kommt es dann zu vielen echt häßlichen Snippets die überall herumfliegen und fast jeder nutzt. Das kommt sicherlich dadurch, dass Unity sehr viele User hat und auch dadurch, dass viele davon eben eigentlich keine Programmierer sondern irgendwas anderes sind aber meistens allein an etwas entwickeln. So erfolgreich ist Unity unter anderem weil genau das funktioniert. Es gibt aber bestimmt auch viele Gegenbeispiele.
Mich stört vor allem, dass in Unity gefühlt sehr viel legacy Code steckt, den eigentlich keiner mehr anfassen will und stattdessen werden immer mehr neue Features rausgehauen die die Engine attraktiv halten sollen. Das ist inzwischen aber vielleicht auch besser geworden, keine Ahnung.
Ich habe Unity seit einigen Jahren nicht mehr benutzt, damals gab es aber so Dinge wie Mauspositionen die ein anderes Koordinatensystem genutzt haben als die UI. Die UI fand ich auch ganz schrecklich. Die Matheklassen fand ich nicht besonders Gebrauchstauglich, einfach weil die Methodennamen oft unpassend gewählt waren, oder viel mehr gemacht haben als ich eigentlich wollte.
Das Shadersystem fand ich auch nicht schön weil man ziemlich eingeschränkt war und Unity dann noch sehr viel im Hintergrund gemacht hat.

Wenn das Ziel ist ein mittelmäßiges kleines Spiel zu entwickeln ist Unity sicher super, aber wenn man dabei auch ernsthaft programmieren lernen und verstehen will was da intern noch so alles passiert, gibt es andere Engines die besser geeignet sind.