Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
- 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)
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Renegade« (17.12.2016, 13:14)
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?!
[...]
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.
Was haltet ihr davon, wenn wir meine Liste einmal konstruktiv fortführen?
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?
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.
Werbeanzeige