spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

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?

Läuft auch auf Mono. Aber bald nicht mehr, dank Kooperation mit Microsoft. (Danke @Chris für den Link).

Zitat von »Mirlix«

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.

Ich muss @Mirlix recht geben: auf gewissen mobilen Plattformen ist die Größe ein echtes K.O. Kriterium. Ein leeres Projekt unter Android ist bis zu 20MB groß. Btw wird gerade an einem neuen AssetBundle System gearbeitet, dass mit grafischer Oberfläche einiges erleichtern soll. Link: https://blogs.unity3d.com/2016/10/25/new…tool-prototype/. Gibt's konstelos zum Testen auf BitBucket: https://bitbucket.org/Unity-Technologies…undlegraphtool/

Was die alte Mono Version angeht, kann man zumindest einen aktuellen C# Compiler nutzen, da die auch alte .Net Versionen als Target unterstützen. Das lässt sich sogar recht leicht direkt in Unity einbinden: https://bitbucket.org/alexzzzz/unity-c-5…ration/overview

Jein. Das gilt natürlich nur für die Features, die auch in alten .Net Versionen unterstützt werden. Async/Await dürfte damit rausfallen. Oder?

Zitat von »BlueCobold«

Jein. Das gilt natürlich nur für die Features, die auch in alten .Net Versionen unterstützt werden. Async/Await dürfte damit rausfallen. Oder?

Es benötigen halt die wenigsten Features wirklich ein aktuelles .Net Framework. Laut Beschreibung betrifft das nur Late Binding mit dynamic.

Async/Await lässt sich über AsyncBridge nutzen. Es bleibt aber die Limitierung das Mono System.Threading nicht kompetibel mit .Net System.Threading ist und somit in UWP nicht verwendet werden kann. Das ginge dann wirklich erst wenn Unity direkt auf das .Net Framework setzt.

Zitat

AsyncBridge/TPL stuff is also not compatible with Windows Store Application platform (and probably all the platforms that use .Net runtime instead of Mono runtime) due to API differences between the recent versions of .Net Framework and the ancient version of TPL (System.Threading.dll) that comes with AsyncBridge. Namely, you can't use async/await, Caller Info attributes and everything from System.Threading.dll (concurrent collections for example).

Daraus würde ich schließen, dass async/await bei den vorher genannten kompatiblen Plattformen (Windows, Mac, Android, iOS) funktioniert. Habe es aber selbst nicht ausprobiert.

Ich selbst würde Unity immer empfehlen. Aber nur für nicht-mehr-ganz-Anfänger.

Unity soll laut Propaganda sehr Einsteiger/Anfänger-freundlich sein. Meiner Meinung nach trübt der Schein. Wieso denke ich das?

Alle dinge die ich jetzt aufzähle betreffen nur Anfänger. Ich finde Unity hat eine gefährliche Mischung aus Klick-Editor und leerem Rahmen für ein Spiel. Damit meine ich, dass es zu einfach ist schnell etwas vorzeigbares zu erstellen, dabei aber die vorhandene Infrastruktur so dermaßen schlecht zu benutzen. Daran sind auch, wie in Vorposts erwähnt, die programmiertechnisch extrem schlechten Tutorials schuld.

Die meisten kopieren mal schnell ein Javascripts mit ein bissl "WASD-Steuerung" ohne sich Gedanken zu machen was sie da treiben. Ist ja im Prinzip noch gar nicht so schlimm. Aber da fängt der Spaß eben schon an. Spätestens wenn es dann darum geht Objekte miteinander interagieren und kommunizieren lassen, wirds extrem dreckig. Da werden Sachen gebaut und benutzt... da habe ich mir teilweise wirklich meinen Teil gedacht. In keinem der mir bekannten Tutorials wird auch nur erwähnt dass man neben der Engine auch seine eigene Logik anbinden kann, die nicht Zwangsläufig im Gameloop mitläuft.

Damit meine ich als sehr einfaches Beispiel simple C#-Klassen in ViStu die dann Beispielsweise Quest-Objekte in einer Liste lagert und dafür sorgt dass man sauber auf sie zugreifen kann. Nein da wird ein neues Javascript erstellt, die dann irgendwelche Strings speichert. Und dass man da auch dran kommt, wird noch ein leeres GameObject erstellt der dann das Scripts bekommt. Und alle Funktionen müssen dann natürlich pro Frame einmal durchlaufen werden. Und so wären wir wieder bei einem potenziellen Performance-Loch.

Ich hoffe es ist ersichtlich was ich damit meine. Die vermeintliche Freiheit wird eben oft zum Verhängnis. Deshalb sollten meiner Meinung nach Entwickler die mit Unity ein Spiel "Programmieren" wollen auch schon etwas Programmiererfahrung mitbringen.

Also ich finde schlecht an Unity: Die Community, die Anfängern ein falsches Bild von der Arbeit mit der Engine und dem Editor gibt.

Zitat von »Sneyke«

Ich selbst würde Unity immer empfehlen. Aber nur für nicht-mehr-ganz-Anfänger.

Unity soll laut Propaganda sehr Einsteiger/Anfänger-freundlich sein. Meiner Meinung nach trübt der Schein. Wieso denke ich das?

Alle dinge die ich jetzt aufzähle betreffen nur Anfänger. Ich finde Unity hat eine gefährliche Mischung aus Klick-Editor und leerem Rahmen für ein Spiel. Damit meine ich, dass es zu einfach ist schnell etwas vorzeigbares zu erstellen, dabei aber die vorhandene Infrastruktur so dermaßen schlecht zu benutzen. Daran sind auch, wie in Vorposts erwähnt, die programmiertechnisch extrem schlechten Tutorials schuld.

Die meisten kopieren mal schnell ein Javascripts mit ein bissl "WASD-Steuerung" ohne sich Gedanken zu machen was sie da treiben. Ist ja im Prinzip noch gar nicht so schlimm. Aber da fängt der Spaß eben schon an. Spätestens wenn es dann darum geht Objekte miteinander interagieren und kommunizieren lassen, wirds extrem dreckig. Da werden Sachen gebaut und benutzt... da habe ich mir teilweise wirklich meinen Teil gedacht. In keinem der mir bekannten Tutorials wird auch nur erwähnt dass man neben der Engine auch seine eigene Logik anbinden kann, die nicht Zwangsläufig im Gameloop mitläuft.

Damit meine ich als sehr einfaches Beispiel simple C#-Klassen in ViStu die dann Beispielsweise Quest-Objekte in einer Liste lagert und dafür sorgt dass man sauber auf sie zugreifen kann. Nein da wird ein neues Javascript erstellt, die dann irgendwelche Strings speichert. Und dass man da auch dran kommt, wird noch ein leeres GameObject erstellt der dann das Scripts bekommt. Und alle Funktionen müssen dann natürlich pro Frame einmal durchlaufen werden. Und so wären wir wieder bei einem potenziellen Performance-Loch.

Ich hoffe es ist ersichtlich was ich damit meine. Die vermeintliche Freiheit wird eben oft zum Verhängnis. Deshalb sollten meiner Meinung nach Entwickler die mit Unity ein Spiel "Programmieren" wollen auch schon etwas Programmiererfahrung mitbringen.

Also ich finde schlecht an Unity: Die Community, die Anfängern ein falsches Bild von der Arbeit mit der Engine und dem Editor gibt.

Könntest du denn ein paar Beispiele geben wie man es besser machen kann?
Ich selbst bin Programmieren, habe mich aber derzeit noch nicht wirklich viel mit Unity und der Programmierung beschäftigt.
Die von dir angesprochenen Zusammenklick-Mechanik hat bisher noch ausgereicht.

Vielleicht könntest du dafür einen neuen Thread aufmachen, der ein paar Beispiele zeigt wie man Objekte miteinander kommunizieren lassen kann und welche Dinge man auch noch beachten sollte.

Kann ich gerne machen. Ich suche mir mal die gröbsten Schnitzer zusammen und mach eventuell noch einen einfach Performancevergleich. Kann allerdings ein paar tage dauern, da ja jetzt die feiertage vor der Tür stehen

Dankeschön,
ich freue mich schon drauf