Du bist nicht angemeldet.

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

1

03.06.2020, 02:44

Unreal Engine vs. Unity

Ich habe heute völlig zufällig ein - meiner Meinung nach - sehr gutes Vergleichsvideo zwischen »Unreal Engine« und »Unity« gefunden. Das ist vor allem für angehende Spiele-Designer von Interesse. Ist allerdings auf englisch:



Ich habe sehr lachen müssen, als er ca. bei 14:30 über »Unreal Engine« und dem damit zwingend verbundenen KnowHow von C++ spricht. Wirklich herzlich gelacht, und zwar nicht aus Bosheit, sondern weil das meine Erfahrungen mit C++ widerspiegelt (»Unity« nutzt C#).
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

2

03.06.2020, 08:29

Klasse Video. Er hat sehr ausführlich die Unterschiede erklärt. Er hat dann aber trotz C++ die Unreal-Engine gewählt - allein schon wegen der Assets. Anfänger ist er ja nicht mehr.

Tja, wenn es nicht so eine Spieleschwemme gäbe, dann hätte ich definitiv ein Spiel programmiert. Aber selbst Nischen sind inzwischen recht gut ausgefüllt. Und wenn man alleine entwickelt, muss das Gameplay schon zünden (siehe Stardew Valley, Axiom Verge, beides mit XNA bzw. Monogame in C#).

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

3

03.06.2020, 12:51

Ich finde eher, dass es noch Milliarden von Spielkonzepten gibt, die erst noch das Licht der Welt erblicken müssen. Damit meine ich nicht originäre Spiel-Ideen (die gibt es vermutlich tatsächlich nicht mehr, wenn nicht noch eine ganz neue Technologie entsteht), aber mir reicht schon ein gut gemachtes Spiel einer vorhandenen Spielidee. Das im Video gezeigte Hollow Knight ist so ein Beispiel. Oder Hyperlight Drifter. Oder das von Dir erwähnte Axiom Verge.

Da ich ja im Moment ein Spiel für den Atari-8-Bit-Computer programmiere: Mir fällt auf, dass sich viele, sogar sehr viele, Programmierer mit dem System befassen. Und die bringen auch erstaunliches zustande. Aber das sind fast alles nur Grafik-Demos. Wenn dann tatsächlich mal ein Spiel heraus kommt, dann ist das eigentliche Spiel meistens langweilig. Das fängt schon damit an, dass zum Beispiel bei einem Jump-n-Run die simple Sprungmechanik der Spielfigur lächerlich primitiv ist. Vergleicht man das mit den Sprüngen von »Mario« in Super Mario Bros. [NES], (35 Jahre alt und das NES hat auch einen 6502-Prozessor) dann kann man auf die Idee kommen, dass die Programmierer der Atari-Spiele niemals über den Tellerrand schauen oder einfach keinen Bock haben. Ich finde das peinlich.

Ich habe spontan mindestens vier Spiele im Kopf, die ich sehr gerne auf dem Atari sehen würde. Bei einem kann ich mir sogar vorstellen, dieses für aktuelle Systeme umzusetzen; dann grafisch natürlich mit »Pixelart« aufgemotzt. Man muss sich doch nur sein Lieblings-Genre nehmen und dann weiter denken. Bei mir wäre es im Falle von 2D-Spielen ein Metroid/Castlevania-Klon. Mir fallen da zig Varianten ein. An 3D würde ich mich auch nicht unbedingt sofort heran trauen. Wenn ich mir allerdings Spiele wie Rime ansehe, oder jetzt The First Tree, mit dem ich bei YouTube überschütte werde, nachdem YouTube gemerkt hat, dass ich mich für Spiele-Entwicklung interessiere (das Spiel wird auch kurz in dem Video erwähnt) ... oder auch Amnesia: The Dark Descent ... die Spiele sind machbar.

Nee, an Ideen mangelt es mir nicht. Es scheitert eher daran ... dass ich meinen Popo nicht hoch bekomme. ;)

Aber immerhin: In den letzten beiden Tagen habe ich an einer Website gearbeitet, die live geschaltet wird, wenn das Atari-Spiel fertig ist. Das ist nix dolles ... aber die Website und die dahinter stehende Programmierung (eigenes Mini-CMS, natürlich alles in PHP und OHNE Datenbank) sind fertig. Ich muss es nur noch nutzen. 8o
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

4

03.06.2020, 18:41

Nee, an Ideen mangelt es mir nicht. Es scheitert eher daran ... dass ich meinen Popo nicht hoch bekomme.

Aus Zeitgründen würde ich jetzt auch keinen Sprint hinlegen. Daher: Vielleicht läuft's irgendwann auf ein Gemeinschaftsprojekt hinaus(?).

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

5

03.06.2020, 21:07

8o :thumbsup: 8o
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

6

03.06.2020, 23:55

Das im Video gezeigte Hollow Knight ist so ein Beispiel. Oder Hyperlight Drifter. Oder das von Dir erwähnte Axiom Verge.


Das Video habe ich jetzt noch nicht gesehen, nur mich irritieren die genannten Beispiele für einen Vergleich von Unity und Unreal Engine. Ich habe mich kürzlich mit einem Entwickler unterhalten, der seit über 30 Jahren Spiele, bzw zuletzt VR-Inhalte entwickelt und bezogen auf 2D-Spiele bezeichnete er beide Engines als etwa "gleich schlecht", weil man quasi mit einem 3D-Unterbau 2D simuliert. Er ging noch soweit und erwähnte die Patch-Politik von Epic, wo offensichtlich das für 2D vorgesehene Paper 2D seit gefühlt einer Ewigkeit nicht mehr geupdatet wurde.

Ich habe jetzt selbst kaum was mit den Engines gemacht, bzw in Unity mal eine Weile mit einem Adventure-Creator experimentiert. Auf der einen Seite ist es interessant, weil man prinzipiell Elemente und Perspektiven einsetzen kann, wie es gefällt und bei Bedarf nahtlos in eine 2.5D-Ansicht schwenken kann. Aber für ein reines 2D-Spiel kommt es mir wie ein ständiger Workaround vor, weil der technische Unterbau für andere Dinge konzipiert wurde.

Für 2D-Gamedev fällt gerade der Game Maker von Yoyo Games ein, mit dem zb Hyper Light Drifter entwickelt wurde. AFAIK basiert die integrierte Programmiersprache GML auf Java Script. Ich hatte irgendwann mal die aktuelle Version 2 über Humble Bundle bezogen. Das Tool wirkt auf mich soweit sogar recht einsteigerfreundlich, allerdings ist die Preispolitik von Yoyo nicht ganz ohne. Die Export-Funktion beschränkt sich standardmäßig auf Windows, Mac und Linux und kostet sonst je nach Plattform extra, bzw Mobile zb einmalig 199$, aber wenn man Richtung Konsolen schielt, ist pro System die vierfache Summe fällig - pro Jahr.
https://www.yoyogames.com/

Womit wir uns im Team zuletzt etwas beschäftigt haben, ist die Open-Source-Engine Godot - bzw das war auch der Aufhänger für das Gespräch mit eben genannten Coder, der die Engine seit einer Weile für 2D nutzt. Die Engine kann auch 3D-Spiele, ist dort allerdings nicht ganz State-of-the-Art, allerdings ist der 2D-Part ziemlich ausgereift. Für den Code wird standardmäßig GDScript verwendet, was an Python angelehnt ist, alternativ können auch andere Sprachen genutzt werden, wie C# oder C++.
https://godotengine.org/

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

7

04.06.2020, 08:15

Das Video habe ich jetzt noch nicht gesehen, nur mich irritieren die genannten Beispiele für einen Vergleich von Unity und Unreal Engine. [...]

Die genannten Spiele kommen aber nicht im Video vor, sondern waren lediglich von mir genannte Beispiele für Spiele mit einer bekannten Spielemechanik, die es trotzdem wert sind - sogar extrem - gespielt zu werden. ;)

Schau Dir das Video mal an. Zum Thema 2D sagt er so ziemlich das gleiche wie Du; wobei »Unity« durchaus nicht schlecht weg kommt.

[Nachtrag]
OK, Hollow Knight kommt im Video vor. Die anderen beiden nicht. Ich bin noch nicht ganz wach.

[...] Für 2D-Gamedev fällt gerade der Game Maker von Yoyo Games ein, mit dem zb Hyper Light Drifter entwickelt wurde. AFAIK basiert die integrierte Programmiersprache GML auf Java Script. [...]

Ich bin der Meinung, dass gerade diese Programmiersprache der große Knackpunkt vom »GameMaker« ist. Als Programmierer, der evtl. auch noch einmal etwas anderes in seinem Leben machen will, ist das quasie totes Kapital. Denn die Sprache kommt halt eben nur im GameMaker zum Einsatz. Das haben wohl auch die Leute von Unity gemerkt und deswegen C# bevorzugt (vorher war es auch irgend etwas Propritäres).

[...] Womit wir uns im Team zuletzt etwas beschäftigt haben, ist die Open-Source-Engine Godot [...]

Spannend, dass Du das erwähnst. Gerade gestern bin ich auf YouTube ebenfalls über die »Godot«-Engine gestolpert. Von der habe ich vorher noch nie etwas gehört. Nachdem, was ich gestern auf deren Website gelesen habe, würde ich die für 2D-Spiele sogar bevorzugen. :)
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

8

04.06.2020, 16:43

Womit wir uns im Team zuletzt etwas beschäftigt haben, ist die Open-Source-Engine Godot
Die Godot Engine ist seit der ersten 3er-Verison auf meiner Platte. Allerdings habe ich bisher nicht viel mehr gemacht, als die Showcases zu kompilieren. Denn, um wirklich einsteigen zu können, muss ich erst das Scene-Node-Konzept verstanden haben, was sicherlich nicht schwierig ist. Aber dafür muss man sich halt ein bisschen Zeit nehmen... :-)

Eigentlich gar keine schlechte Idee, sich kurzfristig damit zu befassen. Dann habe ich mal wieder was für meinen Blog.

9

04.06.2020, 21:55

EDIT: Unnötiger Rant entfernt.

Wenn man eine Programmiersprache gut beherrscht, kann man auch alle anderen relativ schnell lernen. Das sollte eigentlich nicht das Problem sein. Die Frage ob C# oder C++ finde ich daher nebensächlich. Ich mach mir allerdings Sorgen darüber, ob die Engines beide ähnlich flexibel, performant, und fähig sind. Zum Beispiel: Kann ich pixelgenaue Kollisionsabfragen hinbekommen? Geht das nur mit Unreal, oder auch mit Unity? Kann ich Objekte pixelgenau bewegen, ohne Pixelflimmern und ähnliche Artefakte? Ich sehe es häufig bei modernen Unity Produktionen im 2D Bereich, dass die Pixel sich beim Scrolling minimal, aber sehr hässlich verformen. Etwas anderes, was ich beobachte, ist, dass oft Objekte sich je nach Bildschirmauflösung gar nicht im klassischen groben pixel-look Raster bewegen, sonder in einem viel höher aufgelösten Raster der nativen Auflösung. Damit geht für mich die Illusion der retro-artigen Pixelgrafik komplett flöten. Da ich das so oft sehe, frage ich mich, ob das evtl. eine Beschränkung der Engine sein könnte.

Dieser Beitrag wurde bereits 20 mal editiert, zuletzt von »rsn8887« (04.06.2020, 22:36)


henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

10

04.06.2020, 22:56

Wenn man eine Programmiersprache gut beherrscht, kann man auch alle anderen relativ schnell lernen. Das sollte eigentlich nicht das Problem sein. Die Frage ob C# oder C++ finde ich daher nebensächlich. [...]

Das habe ich auch erst gedacht, und prinzipiell ist das ja auch richtig. Und dann habe ich mich ein wenig - wirklich nur ein klein wenig - mit C++ 13 befasst ... da schlackerst Du mit den Ohren, wie kompliziert da einiges funktioniert. Gut, bei C++ ist man einigermaßen zukunftssicher, nicht nur für Spiele-Entwicklung, sondern generell als Software-Entwickler. Aber wenn das nicht sein muss ... nee ... das tut man selbst seinen Feinden nicht an.

Bei C# gebe ich Dir Recht: Wer schon mal in ANSI-C programmiert hat, oder Java oder PHP, der kommt auch mit C# schnell zurecht, und freut sich sogar über den durchdachten Sprachaufbau (und das schreibt jemand, der Microsoft eigentlich nicht mag).

[...] Kann ich Objekte pixelgenau bewegen, ohne Pixelflimmern und ähnliche Artefakte? Ich sehe es häufig bei modernen Unity Produktionen im 2D Bereich, dass die Pixel sich beim Scrolling minimal, aber sehr hässlich verformen. [...]

Ich fürchte, das wird man ausprobieren müssen. Der beschriebene Effekt kann ja nur durch eine interne Skalierung der Engine geschehen. Nun gibt es genug Spiele, die eine Art »Zoom«-Effekt besitzen, dass also das Spielfeld je nach Geschehen mal ran oder weggezoomt wird. Und da müssen natürlich Skalierungen zum Einsatz kommen. Die Frage ist allerdings, ob es nicht alleine durch die Engine nicht zu kleinen Ungenauigkeiten kommt, selbst wenn man gar nicht zoomen will.

Ich bin auch ein wenig auf dem Tripp, dass ich für ein 2D-Spiel gar keine fertige Engine nehmen, sondern mir stattdessen eine Grafik-Bibliothek schnappen würde. SDL2 ist so ein Beispiel, dass mich sehr interessiert. Natürlich muss man dann die Spiele-Physik, Kollisionsabfragen und so weiter alles selber machen - wobei es für SDL2 bestimmt auch dafür Bibliotheken gibt - aber dafür hat man die volle Kontrolle darüber, was auf dem Bildschirm zu sehen ist. Ein anderes Beispiel wäre libGDX, das aber mehr im Java-Bereich zu Hause ist, damit aber auch Perfekt für Android passt.
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

11

04.06.2020, 23:32

Und wenn Du SDL2 benutzt, funktioniert es als Homebrew auch auf gehackten Switch und Vita Konsolen, denn ein Homebrew Port von SDL2 existiert dort schon ;)

Aber dann musst Du Dich leider mit C++ herumschlagen.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »rsn8887« (05.06.2020, 21:50)


henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

12

05.06.2020, 01:01

Ähm, nein ... SDL2 ist C, nicht C++. Man kann es aber auch nativ mit C++ benutzen. Für andere Sprachen gibt es jede Menge Bindings. Ob man für Konsolen-Programmierung C++ benutzen muss, weiß ich allerdings nicht.

Persönlich interessieren mich Homebrew-Hacks nicht sonderlich. Wer damit Spaß hat, dem will ich seinen Spaß auch nicht nehmen. Aber für mich stünde eine wie auch immer geartete Gewinnerzielungsabsicht durchaus neben der eigentlichen Spiele-Entwicklung im Vordergrund. Bedeutet, dass ich mich eher für offizielle Wege interessieren würde.

Aber bevor man von so etwas träumt, sollte man erst einmal überhaupt ein Spiel auf den Weg bekommen. Ich halte es da mit den Worten des Entwicklers von The First Tree, der meint, dass man als erstes Spiel erst einmal etwas Kleines machen und das dann aber VOR ALLEM fertig bekommen soll (einfach mal auf YouTube suchen). Nur so sammelt man Erfahrungen in der Spiele-Entwicklung. Das bedeutet auch, dass man sich am besten auf das stützt, was man schon kann. ANSI-C ist bei mir kein/kaum ein Thema. C# würde ich mir aus dem Stand zutrauen (30 Jahre Erfahrung in ANSI-C, rund 20 Jahre in PHP).

Wie gesagt: Eine Lösung in SDL2 ist mir im Moment am sympathischsten, dicht gefolgt von Unity und/oder der Godot Engine.

Das gilt aber nur für mich persönlich, weil ich bereits programmieren kann (eine der ganz wenigen Sachen in meinem Leben von denen ich behaupte, dass ich sie wirklich kann). Wer eben nicht programmieren kann, dem empfehle ich, sich auf jeden Fall eine Game-Engine anzusehen. :)
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

13

05.06.2020, 21:47

Stimmt, klar, C nicht C++. In meinem Kopf sage ich immer C++, egal ob C oder C++. Ich unterscheide da nicht gross, weil C eine Untermenge von C++ ist. Aber es ist natürlich ein enormer Unterschied an Komplexität.

Wenn Du C eh schon kannst, kannst Du, wenn Du willst, auch ein praktisches Wissen in C++ ruck zuck dazu lernen. Ich empfehle Stroussup's Buch. Das ist aber, wie Du sagst, gar nicht notwendig. Die meisten Projekte benutzen, wenn überhaupt, nur eine ganz kleine Menge der C++ Funktionalität. Benutzen musst Du C++ in der Tat überhaupt gar nicht, weder für SDL2, noch für Konsolenentwicklung. Fast alle Homebrew Devs sind zum Beispiel C++ Hasser, aber haben kein Problem mit C. Die Konsolen SDKs auf Switch und Vita benutzen, soweit ich weiss, C und nicht C++.

Fuer SDL hat mir dies Tutorial geholfen:
http://www.lazyfoo.net/tutorials/SDL/index.php

Und natürlich die offizielle Doku:
https://wiki.libsdl.org

Aber am Besten war für mich, mit einem existierenden Open Source Projekt auf Github anzufangen, welches SDL benutzt, und dort den Source zu lesen und zu verstehen. Bei mir war es der Amiga Emulator UAE4All2 auf Vita, bei dem die Pixel übelst verzerrt waren. Das wollte ich beheben und damit ging auch die SDL Faszination los. UAE4ALl2 benutzte aber SDL1.2. Das war sehr von Vorteil, denn SDL1.2 ist viel leichter zu lernen als SDL2. Der Schritt von SDL1.2 zu SDL2 war dann auch sehr leicht.

Ich habe also mit UAE4All2 Vita Source code angefangen, dann hier SDL1.2 studiert:
https://www.libsdl.org/release/SDL-1.2.1…html/index.html

Danach bin ich erst auf SDL2 umgestiegen. Das war ein guter Lernpfad, denn die SDL1.2 Doku ist, meiner Meinung nach, wesentlich leichter zu lesen und logischer strukturiert als die Dokumentation zu SDL2.

Später habe ich dann aktiv an den SDL1.2 und SDL2 Portierungen auf Vita und Switch mitgearbeitet und zum Beispiel Touchfunktionalität und physische Maus und Keyboardunterstützung (via Bluetooth auf Vita, via USB auf Switch) zu den Ports hinzugefügt.

Dieser Beitrag wurde bereits 15 mal editiert, zuletzt von »rsn8887« (05.06.2020, 22:09)