Du bist nicht angemeldet.

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

drakon

Supermoderator

  • »drakon« ist der Autor dieses Themas

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

1

03.01.2019, 23:56

Game Engines vs. Frameworks mit Entwicklungserfahrung

Hallo zusammen

Ist lange her, seit dem ich hier aktiv etwas geschrieben habe, aber mir ist in den letzten Tagen mal wieder ein wenig die Spielentwicklung durch den Kopf. Selbst lange nichts mehr in dem Bereich gemacht. Nun hat sich ja einiges getan in den letzten paar Jahren.

Ich würde mich für Eure Erfahrungen als erfahrene Entwickler hören zu dem Thema Game Engine (wie z.B. Unity, GameMaker oder Godot) vs. Framework (SFML scheint ja immer noch aktuell zu sein) interessieren.

Der Punkt ist ja, dass die Engines, wie Unity oder Godot es einem ermöglichen recht einfach ohne viel Entwicklungserfahrung zu haben loszulegen. Ich frage mich da allerdings ob es als jemand, der Entwicklungserfahrung hat der ideale Weg ist.

Auf der einen Seite mag ich Code, baue auch gerne mal einen eigenen Quadtree, Partikelsystem o.ä., aber auf der anderen Seite muss man das Rad ja nicht neu erfinden und irgendwie scheint mir das falsch das auf Basis von SFML selbst zu bauen. Dann gibt es ja vielleicht eine Library (wie glaube ich Nexus hier mal basierend auf SFML gemacht hat), die gewisse solche Funktionalitäten anbieten. Dann möchte ich aber auch das Spiel möglichst einfach auf iOS/Android zum laufen kriegen. Das geht dann aber wieder in die Richtung einer Engine.

Bei der Engine wiederum scheint es mir auf den ersten Blick (ich habe nur sehr limitierte Erfahrung mit Unity und Godot) ein wenig komisch alles mit so einem Editor zu machen und viel rumzuklicken für alles mögliche. Auch Skripte in dem Editor anpassen scheint mir merkwürdig und nicht so befriedigend auf längere Zeit aus der Sicht eines Entwicklers. Oder wird das mit mehr Einarbeitung anders und es ist eigentlich üblich mit einem "normalen" Code Editor (z.B. VSCode) zu arbeiten und reduziert sich die Nutzung des Editors später sowieso?

Kann jemand diese Gedankengänge nachvollziehen und hat sie auch durchgemacht? Was sind deine Schlüsse?

Vielen Dank für die Inputs!

Sidenote:

Ich weiss, dass man mit allem alles bauen kann. Das ist hier aber nicht wirklich mein Punkt. Ich müsste mal mit all den Editoren ein echtes Projekt umsetzen und dann vergleichen. Ich interessiere mich aber für Leute, die den Prozess bereits durchgemacht haben und aus Erfahrung sprechen können.

Tobiking

1x Rätselkönig

  • Private Nachricht senden

2

04.01.2019, 05:39


Bei der Engine wiederum scheint es mir auf den ersten Blick (ich habe nur sehr limitierte Erfahrung mit Unity und Godot) ein wenig komisch alles mit so einem Editor zu machen und viel rumzuklicken für alles mögliche. Auch Skripte in dem Editor anpassen scheint mir merkwürdig und nicht so befriedigend auf längere Zeit aus der Sicht eines Entwicklers. Oder wird das mit mehr Einarbeitung anders und es ist eigentlich üblich mit einem "normalen" Code Editor (z.B. VSCode) zu arbeiten und reduziert sich die Nutzung des Editors später sowieso?

Kann jemand diese Gedankengänge nachvollziehen und hat sie auch durchgemacht? Was sind deine Schlüsse?

Die "Skripte" in Unity und Unreal (nicht Blueprint) sind normaler C# bzw. C++ Code. Der lässt sich außerhalb des Editors ändern und bauen. Beide Engines generieren auch Projekte für Visual Studio mit Unterstützung von IntelliSense, Debugging etc.

Bei Unity hab ich vor 1-2 Jahren (damals noch Unity 5) im Detail geschaut was alles möglich ist. Theoretisch kann man mit einer Szene und einem Objekt als Einstiegspunkt arbeiten und dann alles im Code erzeugen. Mir ist zumindest nichts aufgefallen was ich im Editor hätte erzeugen können, was im Code nicht geht. In der Praxis wird man aber schon Daten aus dem Code raushalten wollen und sie im Editor setzen wollen. Da ist es Geschmacksache wie viel das ist. Ich fand es sehr angenehm Anbhängigkeiten per DI Framework (Zenject) im Code zu definieren statt im Editor. Der Code wird damit auch etwas mehr von Unity unabhängig und hat die (zumindest damals) langsamen find und Event Methoden umgangen.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

3

04.01.2019, 06:35

Viele Änderungen brauchten wir für SFML nicht, damit es auf Android und iOS lief. Der meiste Code steckt allerdings in der Game-Logik, in der Verarbeitung der Level-Files und der UI. Soweit ich mich erinnere, sind alle diese Themen (selbst "coole" 2D UI) in Unity auch dem Entwickler überlassen oder müssen durch Bibliotheken/AddOns übernommen werden. Im Fall von SFML gäbe es z.B. SFGui, auch wenn wir was eigenes benutzen, was ich für mächtiger halte. Mit SFML würde ich allerdings kein 3D machen wollen und es ist ganz klar auch bei 2D ein Kampf zwischen "ich muss gewisse Dinge selbst erfinden" (was ich jetzt nicht mehr müsste, auch bei einem neuen Spiel nicht) und "fuck, wieso geht das nicht?" (was bei bestehenden Engines sicher härter zu umgehen ist als bei [Open-Source-] Frameworks). Letzteres ist bei SFML allerdings Shader auf Mobile. Kannste aktuell knicken und das ist aus meiner Sicht ein riesiger Verlust.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Mirlix

Supermoderator

Beiträge: 451

Beruf: Developer Advocate

  • Private Nachricht senden

4

04.01.2019, 20:06

Sobald man ein größeres Unityprojekt hat, sollte man eh auf den normalen Unityworkflow verzichten und sehr viel über Code machen. Der Editor wird dann nur noch als ContentEditor genutzt. Das heißt alle Logik etc. ist in Code und als Programmierer verbringt man die meiste Zeit in einer IDE. Designer, Artists und Leveldesigner nutzen dann die Bausteine die man als Entwickler erstellt hat um Content zu erzeugen.

Und das funktioniert auch sehr gut und führt zu einer netten Trennen von Logik und Content. Der Hauptvorteil den ich in Unity sehe ist das man keinen Content Editor schreiben muss sondern einfach den UnityEditor dafür nutzen kann. Hier ist ein schöner Artikel dazu: https://unity3d.com/how-to/architect-with-scriptable-objects

Damit werde ich mich dieses Jahr beschäftigen und schauen wie gut ich damit TestDriven entwickeln kann.

drakon

Supermoderator

  • »drakon« ist der Autor dieses Themas

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

5

04.01.2019, 23:25

Die "Skripte" in Unity und Unreal (nicht Blueprint) sind normaler C# bzw. C++ Code. Der lässt sich außerhalb des Editors ändern und bauen. Beide Engines generieren auch Projekte für Visual Studio mit Unterstützung von IntelliSense, Debugging etc.

Genau. Das ist das was mich bei Godot ein wenig stört. Da es eine Python ähnliche Sprache ist. Könnte mir aber vorstellen, dass es für VSCode mittlerweile auch gute Plugins gibt. Kommt wahrscheinlich nach einem Weilchen eh nicht drum herum das für sich selbst zu konfigurieren. Aber praktisch mit dem eingebauten Code Editor ist, dass man am Anfang gleich loslegen kann. Source Code Verwaltung ist auch einer der Punkte, der mir durch den Kopf ging.

@BlueCobold
Danke für den Hinweis mit iOS! War mir nicht so bewusst, dass das gut geht. Bei SFML gibts dann halt schon so Sachen, wie Tilemaps (respektive der Editor dazu) oder 9-slicing, Sprite Atlas die dann doch irgendwie Fehlen (je nach Spiel natürlich, aber die Chance, dass man etwas davon braucht ist ja schon da).

Ich stelle mir das jetzt ein wenig vor wie es Mirlix beschreibt. Das klingt irgendwie vernünftigt. Ich habe damals nicht nur selbst ein Tilemap System gebaut, sondern brauchte ja schliesslich auch einen Editor dazu. Das ist ja dann irgendwann schon nicht ganz so praktisch.

Irgendwie habe ich das Gefühl, dass der Sweetspot für mich irgendwo wäre bei: Level SFML (aber mit Python oder so), dazu aber Spielentwicklungsrelevante Erweiterungen (Tilemaps, Partikelsysteme, Sprites, Shader, etc.) und "freie" Editoren für Maps, Sprites, etc., die man benutzen kann, aber prinzipiell am Anfang gar nicht mal braucht. Der Unterschied zu Unity oder Godot ist dann da allerdings auch nicht mehr so wahnsinning gross. Löve2Dscheint da in diese Richtung zu gehen. Oder kennt jemand noch anderes, dass +/- dem entspricht was ich beschrieben habe?

Auf jeden Fall Danke für die ganzen Inputs!

@Mirlix
Packt ihr da Content, respektive Maps, etc. auch in euer Source Control System?

6

05.01.2019, 14:03

@drakon

Der Unterschied zwische Godot und deinem SFML basierenden Lösung würe nur noch GDScript da Godot auf SFML basiert. Außerdem kannst du, wenn du unbedingt willst auch mit C# für Godot scripten.
Hilfreiche Information: Übersicht über Authorensyteme

Garzec

Alter Hase

Beiträge: 693

Wohnort: Gießen

  • Private Nachricht senden

7

05.01.2019, 18:11

Meines Wissens nach ist der C# Support zwar vorhanden, allerdings noch nicht vollständig. Auf dem Godot Discord hieß es, ca. Sommer 2019 wäre C# mit GDScript gleichauf.

Mirlix

Supermoderator

Beiträge: 451

Beruf: Developer Advocate

  • Private Nachricht senden

8

05.01.2019, 18:15

@Mirlix
Packt ihr da Content, respektive Maps, etc. auch in euer Source Control System?


Das kommt darauf an, bei manchen Projekten ja, wenn es größer wird teilt man es oft auf. Also ein VCS für Code und ein anderes für Content. Aber für kleiner Spiele ist alles in VCS am einfachsten.

9

05.01.2019, 22:11

Bezüglich Unity gibt's übrigens einige interessante Entwicklungen in Richtung "mehr selbst machen" bzw. moderne daten-orientierte Programmierung:
https://github.com/Unity-Technologies/En…tation/index.md
http://lucasmeijer.com/posts/cpp_unity/

Wirago

Alter Hase

Beiträge: 1 193

Wohnort: Stockerau

Beruf: CRM Application Manager

  • Private Nachricht senden

10

06.01.2019, 13:14

Ich mach zwar hauptberuflich keine Spiele, aber mir persönlich geht es so, dass ich ungern mit solchen Engines (Unreal, Unity) arbeite. Für mich fühlt sich so eine Engine an, wie VBA oder Python Skripterei, nicht wie Softwareentwicklung. Ich habe gern die volle Kontrolle und daher bin ich eher der Fan von Frameworks, die man beliebig anpassen und abändern kann. Man muss aber auch dazu sagen, dass mich weniger das Entwickeln des eigentlichen Gameplays interessiert, als viel mehr Dinge wie Architektur, Algorithmen, Physik und Computergrafik.


Geht mir ähnlich. Habe auch mal überlegt auf Unity um zu steigen, aber irgendwie hatte ich immer das Gefühl mir ein Spiel "zusammen zu klicken" und bin deshalb bei MonoGame geblieben. Da habe ich eher das Gefühl alles unter Kontrolle zu haben. Ja, es ist mehr Arbeit, aber durch das schreiben von einem eigenen UI- und Inventar-System habe ich so einiges gelernt und das möchte ich nicht missen.

Werbeanzeige