spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn die Vorgaben nicht zu sehr auf eine Engine bzw. ein Framework festgelegt und detailliert genug sind und außerdem alle Implementierungen diese Vorgaben richtig und vollständig umsetzen, dann dürfte es für den Spieler grundsätzlich keinen Unterschied geben. Mit einem reinen Betrachten der Ergebnisse könnte man nur feststellen, dass es vollkommen egal ist, welches Framework am Ende verwendet wird.

Der einzige Mehrwert, den entsprechende Spiele bringen würden, wäre das Beispiel/die Vorlage, welches sie mit ihrem Quellcode abliefern würden. Ob man nun eine Sprache und/oder den Umgang mit einem Framework/einer Engine lernen möchte, wenn man vorher bereits mit einer anderen Sprache oder einem anderen Framework gearbeitet hat, dann hat man zwar eine Vergleichsmöglichkeit, die entsprechende Doku und/oder Tutorials dürften aber dennoch mehr bringen und wenn man vorher noch nicht programmiert hat, dürfte man nur schwer Programmcode lesen können und erstmal auf andere Weise vorgehen müssen.
Abgesehen davon gibt es in wahrscheinlich jedem Framework unterschiedliche Wege, um an das gleiche Ziel zu kommen. Alleine in Unity kann man mit anderen Scripten per SendMessage, per direktem Methodenaufruf oder events kommunizieren, andere Objekte können in der Szene anhand des Namens oder Tags gesucht werden oder einem verwendenden Script angehangen werden, bzw. in manchen Fällen auch in der Hirarchie untergeordnet und so gefunden werden.

Und was die bisher angedeuteten Vorgaben angeht:
Eine Feste Auflösung halte ich für unsinnig. Die Unterschiede in der Auflösung machen sich zwischen verschiedenen Bildschirmauflösungen (und somit höchstens zwischen verschiedenen Geräten) bemerkbar. Wenn ein Spieler das Unity-Spiel mit dem XNA-Spiel, SFML-Spiel, SDL-Spiel, OpenGL-Spiel, ... bei 1920x1080 vergleicht, dann sollte es zwischen diesen keinen Unterschied geben. Ohnehin sollten die Spiele unabhängig von der Auflösung laufen und dennoch das Gleiche anzeigen.
Es ist vielleicht nur die Formulierung, allerdings sollte nicht "x Sekunden vom rechten zum linken Bildschirmrand" als Vorgabe gelten, sondern "x Einheiten/Sekunde", wobei mit "Einheit" die Spielintern verwendete Einheit gemeint ist. (Und das sind keine Pixel. )


Wenn du unbedingt etwas in der Richtung machen willst, dann müssen erst entsprechende Vorgaben, welche ausführlich genug das Verhalten des Spiels beschreiben, und alle notwendigen Ressourcen (Grafiken, Sounds, Schriftarten, ...) vorhanden sein.

Zitat

Wenn das reichen würde dann hätten wir ja nicht jedes mal x-neue Threads zu dem Thema, oder?

Naja ich sehe das so: Es reicht bei weitem, nur haben die Leute keine Lust (unterstelle ich einfach mal, denn so sieht es nun mal aus) sich diese an zu gucken und wollen sich mit den Fragen an die Community die Arbeit sparen.
Auch wenn ich die Idee für ganz gut halte, ändert das nichts am Problem der Einstellung der User. Denn auch wenn dies umgesetzt werden würde, würde es meiner Meinung nach nichts ändern, da die Leute sich trotzdem Arbeit sparen wollen und trotzdem Fragen.

Je nachdem wie die Vorgaben dann konkret aussehen würden, würde ich mich auch beteiligen wollen (und zwar mit libGDX).

Wie bereits geschrieben: um eine Sprache oder den Umgang mit einem Framework zu lernen, reichen in der Regel entsprechende Dokumentationen, Tutorials, Bücher etc. Die genannten Themen fragen dann entweder, welche Sprache/welches Framework verwendet bzw. welches Buch gekauft werden soll, oder nach Tutorials, Büchern oder anderen, ähnlichen Dingen. Bei letzterer Frage würden entsprechende Implementierungen verständlicherweise nicht helfen, ich würde aber auch bezweifeln, dass die Beispiele wirklich bei der Wahl des Frameworks oder der Engine helfen würden. Nur, weil man ein Beispiel vor der Nase hat, sieht man nicht unbedingt sofort, dass die Engine ein Komponentenbasiertes System verwendet oder dass bestimmte Teile bei jenem Framework händisch umgesetzt werden müssen, um ein paar Beispiele zu nennen.

Auflösung:
Wenn man bei einem Spiel sauber vorgeht, dann läuft das Spiel auch mit unterschiedlichen Auflösungen. (Ob dafür der Spielinhalt nach dem Zeichnen nur noch skaliert wird, ob höher aufgelöste Texturen verwendet werden oder ob ein Rahmen um den Spielinhalt gelegt wird ist an der Stelle egal.)
Was meinst du mit "Das zeigt gut den Unterschied, wie die letztendliche Shell des Spiels am Ende beeinflusst wird."?
Man muss sich in Unity zwar nicht darum kümmern, dass unterschiedliche Auflösungen unterstützt werden, das Standardverhalten Unitys ist dabei aber, dass immer eine feste Höhe verwendet wird, was aber nicht immer das gewünschte Verhalten ist.

Bewegungsgeschwindigkeit:
Wenn man sein Spiel entwickelt (und nicht mit Pixeln arbeitet), dann hat man eine Einheit, in der alle Berechnungen durchgeführt werden (ob Zoll, Meter oder was auch immer ist in dem Fall egal). Für alles im Spiel wird man also wissen, wie groß es ist. Man weiß also, dass der Bildschirm bspw. 20 Einheiten in der Breite darstellt, ein Spieler 1x2 groß ist, die maximale Sprunghöhe 5 Einheiten ist usw. In dem Fall sollte man dann auch Geschwindigkeiten in Einheiten pro Sekunde angeben, da man so auch direkt mit diesen Rechnen kann, ohne sie vorher von "Bildschirmbreiten pro Sekunde" umrechnen zu müssen.
Und wenn man keine Angabe in Einheiten pro Sekunde von seinem Game Designer erhält, dann wären es immernoch Aussagen, wie "doppelt so schnell wie ..." oder "halbier die Geschwindigkeit mal".

Wenn die Spiele gleich funktionieren sollen, dann sollten auch die gleichen Ressourcen verwendet werden. Mir, würde ich dafür mit einem Framework was entwickeln, wäre es am Ende vollkommen egal, ob du die Grafiken selbst gezeichnet hast, es kostenlose (CC, gemeinfrei, ...) Grafiken aus dem Internet sind oder ob du einen Grafiker beauftragt hast, solange alle zu verwendenden Ressourcen aufgelistet werden und idealerweise auch in einem Archiv bereits zum Download zur Verfügung gestellt werden.


Auch wenn hier einige Leute der Meinung sind, dass es nicht besonders viel bringen wird, wird dich/euch wohl niemand davon abhalten. Wenn du wirklich _willst_, dass sowas angegangen wird, musst du am Ende (auch wenn sich "genug" Leute, wie viele das auch sein mögen) ohnehin eine gewisse Eigenleistung erbringen. Dazu gehört auf jeden Fall zu beschreiben, wie dieses Spiel aussehen und wie es sich verhalten soll, idealerweise implementierst du es aber auch bereits.

Zitat von »KeksX«

Aber meinst du nicht, dass es helfen würde wenn wir in so einem Thread sagen könnten "Hier der Link zu den Beispielprojekten, wie du siehst funktionieren mehrere Ansätze - such dir einen raus, der dir gefällt!"?

Denke ich ehrlich gesagt nicht. Jemand, der so eine Frage stellt, will sich nicht lange mit verschiedenen Engines beschäftigen und selbst evaluieren. Er will einfach nur so schnell wie möglich eine Antwort und das so einfach wie möglich.

Wie wäre es, wenn wirs einfach mal ausprobieren!? Erstmal ist das ein ganz normaler Thread und hier kann gemacht werden was man will!

Ich hätte nur einzulenken, dass ich nicht "Asteroids" nehmen würde, sondern eher Pong. Ich finde bei Pong gibt es mehr Steuerungsmöglichkeiten (Maus || Tastaur) und man hat Kollisionen mit Auswirkungen. Außerdem klingt der Vorschlag eher nach einem 2D-Spiel und ich würde eher auf 3D setzen (2D geht immer), weil es meistens um 3D-Engines geht. Für die Objekte kann man dann ja Polygonvorgaben machen (vielleicht auch ein wenig übertireben, damit die Engines mal ins schwitzen kommen. Und dann soll man Effekte einbauen, je nach dem wie es möglich ist mit Shadern oder mir "normalem" Code. Dabei soll es immer drum gehen, dass der Code möglichst modular aufgebaut ist, sodass man auch mal Effekte oder so weglassen kann und er einfach besser verständlich ist.

PS: Das ist meine Meinung (Ich finde sie aber begründet) und ich will damit auch auf keinen Fall eine hizige Diskussion über das richtige Spiel anstoßen!

EDIT: Weitere feste Angaben fände ich noch gut...

Ich finde auch, warum nicht einfach probieren. Es sind ja anscheinend ein paar dabei die Spaß an sowas hätten, also warum nicht. Ob es hinterher einen Nutzen hat wird sich dann zeigen. Ich würde Vorschlagen da die Idee von unserem Cookie kommt könntest du ja vielleicht mal eine Umfrage zum Spiel starten. 2D/3D muss auch irgendwie geklärt werden. Und dann können sich halt irgendwie Teams für die einzelnen Sprachen/Engines zusammen finden. Man kann ja auch erst mal mit 1 oder 2 Engines/Sprachen anfangen und für den Rest finden sich vielleicht mit der Zeit ein paar Leute. Weiß man natürlich nicht 100%. Ich würde sagen da du die Idee dazu hattest könntest du an sich ja auch das ganze managen.