Hauptidee

Es wurden viele Bücher, Artikel und Tutorials über Benchmarking-Anwendungen, Engines und verschiedene Softwaresysteme geschrieben.

Folgendes gibt uns die alte Wikipedia zu diesem Thema:

Leistungstest, Benchmark (englischer Benchmark) - die Kontrollaufgabe, die zur Bestimmung der vergleichenden Leistungsmerkmale eines Computersystems erforderlich ist.

Aber was ist, wenn wir ein wenig von der anderen Seite zum Thema Benchmarking von Game-Engines kommen? Alle Game Engines und SDKs für die Spieleentwicklung (und nicht nur) bewerben sich häufig als sehr intuitive und leicht verdauliche Tools. Wir verkaufen Einfachheit zum Lernen, eine erstaunliche Lern- und Einstiegskurve, leichte und schöne Beispiele, bei denen ein Bildschirm mit Code beim Start eine Art wunderbare Magie erzeugt. In Vorbereitung auf das bevorstehende Ludum Dare- Event habe ich mich erneut entschlossen, mich umzuschauen und zu sehen, was die „Märkte“ für die einfache Emele bieten - jemanden, der seit einer Woche ohne ein Jahr im Spielentwickler ist. Das heißt, eine der Personengruppen der CA, die diese erstaunlichen Eigenschaften der leichten Verdaulichkeit des Motors verkauft.

Was ist, wenn wir ... versuchen, uns selbst zu messen, während wir mit verschiedenen Engines zum Schreiben von Spielen arbeiten? Ja, ja, das heißt, ihre Produktivität auf sie. Nehmen Sie buchstäblich ein paar davon, schließen Sie sich mit einem Laptop, Internet und einer Stoppuhr in eine Höhle ein, schreiben Sie alle unsere Ergebnisse auf ein ordentliches Tablet und versuchen Sie dann, einige Schlussfolgerungen zu ziehen. Gleichzeitig stellen wir fest, dass es mir gefallen hat, was mich bei der Arbeit mit dem einen oder anderen Motor überrascht oder belastet hat.

Über Benchmark

Die Testobjekte sind also drei Spiel-Engines. Hier lohnt es sich wahrscheinlich, Ihre "Konfiguration" mehr oder weniger formal (so weit wie möglich) zu beschreiben (ja, wie bei typischen Benchmark-Ergebnissen schreiben sie die Eisenkonfiguration, in der sie die Läufe, die Benchmark-Beschreibung usw. durchgeführt haben).

"Konfiguration" oder Über mich

Ich bin ein Java-Entwickler. Erfahrung in der industriellen Entwicklung 5+ Jahre. Auch in der Arbeit habe ich ein wenig in JavaScript geschrieben, Lua (sehr, sehr leicht), Shell. Höhere technische Ausbildung. Ich habe keine Designkurse absolviert, ich habe kein Spieledesign gelernt, ich war nur ein begeisterter Fan verschiedener PC-Spiele. Letztes Jahr interessierte er sich für die einfachsten Computerspiele.

Über die Aufgabe

Ein Testprojekt des Klons des Spiels Doodle Jump wurde ausgewählt. Ich bin sicher, dass viele Leute es wissen oder gespielt haben. Dies ist ein sehr cooles und sehr gut entwickeltes Spiel für Android.

Die Regelung lautet wie folgt:

1. Jeder Motor hat 4 Stunden Zeit. Dies beinhaltet das Lernen, Bekanntschaften, Nasenpicken, den Versuch, einen Prototyp zu schreiben, das Debuggen des Spiels im Allgemeinen den gesamten Zyklus der Erstellung des Spiels.
2. In einer kurzen Pause werde ich jede halbe Stunde versuchen, das zu korrigieren, was getan wurde, um meine Arbeit irgendwie zu korrigieren, einen weiteren Arbeitsplan zu skizzieren, Notizen, Notizen usw. zu machen.
3. Bevor wir mit dem Testen jeder Engine beginnen, werden wir versuchen, das Spielprojekt in seine Bestandteile zu zerlegen, um ihnen konventionelle Einheiten zuzuweisen. Daher messen wir unsere "Produktivität" des Spieleentwicklers für jede Engine in Papageien und können die Ergebnisse nicht in Worten, sondern zumindest in Zahlen vergleichen.

Zerlegung des Spiels in Komponenten

In einer sehr abstrakten und Top-Level-Form sehe ich mich als Bestandteile des Spiels wie folgt:

1. Spieler (Sprite, Sprungverhalten, Reaktion auf die gedrückten Tasten)
2. Level-Objekte: Plattformen, Feinde usw.
3. Physik: Sprunggeschwindigkeit des Spielers, Beschleunigung des freien Falls, Plattformen sollten nur dann mit Kollisionen umgehen, wenn sie von oben gesprungen wurden, und den Spieler durch ihn hindurchlassen, wenn er sie vom Boden der Plattform aus überquert.
4. Prozedurale Level-Generierung: Initialisierung und Erweiterung des Levels (an beliebigen Orten, jedoch mit bestimmten Regeln und Einschränkungen) im Handumdrehen neuer Plattformen und Feinde, wodurch eine verlockende Spielsituation für den Spieler entsteht
5. Eine „Kamera“, die dem Spieler folgt, wenn er das Level nach oben bewegt. Die Kamera sollte den Player für den Player sichtbar halten und schrittweise mit ihm „springen“, wobei neue Plattformen im Rendering-Bereich (in der Sichtbarkeit der Kamera) angezeigt werden.
6. Game Over Auslösemechanismus. Ein Spieler verliert, wenn er den unteren Rand des sichtbaren Bereichs erreicht (nachdem er bereits mindestens einmal gesprungen ist).
7. Einen Spieler punkten. Wir werden nur den Höhenzähler des Spielers aktualisieren. Wir werden den Zähler entsprechend der zuletzt erreichten Plattform aktualisieren (die, von der er das letzte Mal abgestoßen hat).
8. HUD : Spielerfortschritt anzeigen. Höhenanzeige.

Der Einfachheit halber weisen wir jeder Komponente einen Punkt unserer Papageieneinheiten zu. Gesamtmaximum - d.h. Die spielbare Vollversion des Projekts beträgt 8 Punkte.

Nachfolgend sind die in der Anzeige verwendeten Assets aufgeführt. Dies sind handgezeichnete Sprites (ich bin kein Künstler, wie Sie sehen können) und Plattform-Sprites mit den Abmessungen 64x64, * .png-Format.

Und geben Sie auch ein paar Flussdiagramme:

1. Somit wird die Berechnung des "Geschlechts" für den Spieler implementiert (denken Sie daran, dass sich der Bildschirm mit einem Sprung nach oben verschiebt und eine Abweichung über den Bildschirmrand einen Graben bedeutet).
   
2. Und so berechnen und aktualisieren wir die vertikale Geschwindigkeit ( y_velocity ) und die y Koordinate des Spielers bei jedem Schlag. Sie wird von zwei Faktoren beeinflusst: der Schwerkraftbeschleunigung ( GRAVITY ) und den Plattformen, bei deren Erreichen der Spieler mit vollständig wiederhergestellter Geschwindigkeit abgestoßen wird
   
3. Der Algorithmus zur Berechnung der Horizontalgeschwindigkeit wurde wie andere Mechanismen nicht in den Geltungsbereich des Artikels aufgenommen.

Ich habe übrigens noch Fragen:

1. Wie ist es überhaupt besser, Kamera-Tracking für einen Spieler zu implementieren? Bisher wird es an die vertikale Koordinate der letzten, höchsten Plattform gebunden, die der Spieler erreichen konnte, sodass sich diese Plattform im unteren Teil des sichtbaren Bereichs befindet und wir neue Teile des generierten Levels sehen.
2. Der Plattformgenerierungsalgorithmus selbst. Nach meiner Idee wird dies eine Art „Plattformfabrik“ sein, die in jedem Zyklus des Spielzyklus ( dt ) die höchste Plattform kennt, die auf der Ebene existiert, und einen zufälligen Höhenwert aufweist (ein bestimmter Schwellenwert, nicht mehr als die Sprunghöhe des Spielers, aber auch nicht weniger als ein bestimmter Bruchteil von seine Höhen, damit die Plattformen nicht nahe beieinander haften) fügt dem Level eine neue Plattform hinzu, wenn der Spieler fortgeschritten ist. Interessant ist auch hier die Frage nach der zunehmenden Komplexität des Spiels, wie sich die Art der Generierung dieser Plattformen ändern soll.

Ich würde mich sehr über Ihre Ideen, Life-Hacks und Vorschläge in den Kommentaren und PM zu diesen beiden zweifellos spielerischen Themen freuen.

Über Motoren

Drei Kandidaten wurden mit sehr interessanten Eigenschaften für mich ausgewählt. Die Parameter, die bei der Analyse der Testergebnisse hilfreich sein sollten, sind nachstehend zusammengefasst.

Wir sehen also, dass die Auswahl sehr interessant ist. Es ist insofern interessant, als wir uns mit verschiedenen Kombinationen unserer Qualitäten und Eigenschaften der Motoren befassen werden. Und mal sehen, was sich am Ende auflöst: ein Motor, in dem ich schon ein bisschen Hand in Hand habe, ein gepumpter YP oder ein völlig frischer und neuer Motor für mich mit vielversprechenden Chips, der aber überhaupt nicht beherrscht wird und auch nicht in meiner Hauptentwicklungssprache.

Warum nicht Unity / Unreal Engine / Other Awesome Engine usw.?

Viele würden sich wahrscheinlich fragen, warum ich nicht den Standardweg gegangen bin und nicht die gängigsten Flaggschiffe unserer Zeit genommen habe: Unity oder Unreal Engine? Ich würde meine Gedanken so formulieren: Ich möchte ein sehr einfaches, minimalistisches und winziges Spiel bauen. Mit ein paar Spielelementen, die die Spielmechanik ausmachen, einem spielbaren Charakter, einer einfachen Generierung von Levels und ohne Spezialeffekte oder sehr konventionelle Spezialeffekte, wie bei alten Arcade-Automaten. Im übertragenen Sinne ist es meine Aufgabe, einen roten Kreis auf ein schwarzes Quadrat zu zeichnen, und dazu bin ich eingeladen, Photoshop zu nehmen. Einfach ausgedrückt, eine Reihe von Funktionen, Modi und Fähigkeiten von Unity mich erschreckt. Zu diesem Zeitpunkt möchte ich jedes Detail meines Spiels verstehen.

Dies geschieht am besten mit einfachen und kleinen Motoren mit einer begrenzten Anzahl von Funktionen, möglicherweise nicht mit dem besten Tuning und Ökosystem, aber Einfachheit und Einschränkung haben auch ihre eigene Schönheit. Mit nur einer begrenzten Anzahl von Werkzeugen - und im Fall von Love2D ist Ihr Werkzeug Ihr Code und nichts weiter. Sie konzentrieren sich auf den Fan, darauf, etwas Cooles zu schreiben, den Charakter oder die Umgebung des Spielers wiederzubeleben. Bereits kompliziertere Engines erweitern Ihre Auswahl, und das Schreiben von Code fließt reibungslos in viele Dinge ein: Schreiben von Skripten (Code), Verknüpfen von Skripten, Zuordnen von Assets, Hinzufügen von Konfigurationen, Neudefinieren von Konfigurationen, Mischen von Plugins von Drittanbietern, Schreiben von Skripten und Konfigurationen für Plugins von Drittanbietern, mehrfaches Klicken Dutzende und Dutzende von Dialogen und Fenstern ... Sagen wir einfach, dass ich vorerst immer noch Angst vor solch hoch entwickelten und zweifellos fortschrittlichen und leistungsstarken Spieleentwicklungs-Engines habe. Nun, ich möchte mich nicht noch einmal an C # / JS / C ++ erinnern und darauf schreiben.

Ich fasse meine Motivation bei der Auswahl der Engine mit einem Link zu diesem Video zusammen. Mir scheint, dass der Autor das, was ich die ganze Zeit versucht habe, mit Worten für mich und andere zu formulieren, buchstäblich aus meiner Sprache entfernt hat: https://www.youtube.com/watch v = JH8xwNOQ0TM

Entfalten

Defold ist eine plattformübergreifende Engine von King.
Unterstützte Plattformen:

• HTML5 (WebGl)
• Android 2.3 (API Level 9) +
• iOS 8.0+
• Windows Vista +
• OSX 10.7+
• Linux

Die merkwürdige Tatsache ist, dass King Activision Blizzard gehört .
In der Engine hat mich die Entwicklungssprache angezogen - Lua , Unterstützung für eine Reihe von Plattformen für Spiele-Builds sowie die Verteilung ihrer eigenen plattformübergreifenden IDE - kann auch unter Linux installiert werden. Dies bestach mich bei der Wahl zwischen Defold vs. Corona SDK .
Und unten ist das Protokoll dessen, was an den Kontrollpunkten getan wurde:

Unten im Spoiler gibt es einige GIF-Animationen, die den zeitlichen Fortschritt zeigen:

Ergebnis, Benchmark-Punkte:

1. Spieler (Sprite, Sprungverhalten, Reaktion auf gedrückte Tasten) (V) Yes
2. Level-Objekte: Plattformen, Feinde usw. (V) Yes
3. Physik: Sprunggeschwindigkeit des Spielers, Beschleunigung des freien Falls. Plattformen sollten nur dann mit Kollisionen umgehen, wenn sie von oben gesprungen sind, und den Spieler durch ihn hindurchlassen, wenn er sie von der Unterseite der Plattform aus überquert. (V) Yes
4. Prozedurale Level-Generierung: Initialisierung und Hinzufügen des Levels (an beliebigen Orten, jedoch mit bestimmten Regeln und Einschränkungen) im laufenden Betrieb neuer Plattformen und Feinde, wodurch für den Spieler eine verlockende Spielsituation entsteht (X) No
5. Eine „Kamera“, die dem Spieler folgt, wenn er das Level nach oben bewegt. Die Kamera sollte den Player für den Player sichtbar halten und nach und nach mit ihm „springen“, wobei neue Plattformen im Rendering-Bereich (in der Sichtbarkeit der Kamera) angezeigt werden (X) No
6. Game Over-Auslösemechanismus. Ein Spieler verliert, wenn er den unteren Rand des sichtbaren Bereichs erreicht (nachdem er bereits mindestens einmal gesprungen ist) (X) No
7. Einen Spieler punkten. Wir werden nur den Höhenzähler des Spielers aktualisieren. Wir werden den Zähler entsprechend der zuletzt erreichten Plattform aktualisieren (von der er das letzte Mal abgestoßen hat) (V) Yes
8. HUD: Spielerfortschritt anzeigen. Höhenanzeige. Optional scheint es im ursprünglichen Spiel keine Fortschrittsanzeigen zu geben. (V) Yes

Benchmark-Punktzahl: 5/8

Love2d

Dies ist eine sehr minimalistische, aber leistungsstarke und flexible Engine zum Erstellen von Prototypen. Im Allgemeinen eignet es sich mit der gebotenen Geschicklichkeit sogar für die Veröffentlichung vollwertiger Spiele auf dem Markt. Es gibt einige gute inspirierende Beispiele. Nebenbei eins und zwei .

Im Allgemeinen empfehle ich für diese Engine eine sehr geeignete Reihe von Tutorials von Habr, die mich anspornten und einen starken Impuls für die Entwicklung dieser Engine gaben. Ich werde nur einen Link zum ersten Teil geben, dann wird es möglich sein, von dort zu den verbleibenden Teilen zu gelangen: Erstellen eines Spiels auf Lua und LÖVE - 1

Im Folgenden finden Sie ein Protokoll darüber, was an den Kontrollpunkten getan wurde:

Berechnen Sie die "Leistung" des Motors:

1. Spieler (Sprite, Sprungverhalten, Reaktion auf gedrückte Tasten) (V) Yes
2. Level-Objekte: Plattformen, Feinde usw. (V) Yes
3. Physik: Sprunggeschwindigkeit des Spielers, Beschleunigung des freien Falls. Plattformen sollten nur dann mit Kollisionen umgehen, wenn sie von oben gesprungen sind, und den Spieler durch ihn hindurchlassen, wenn er sie von der Unterseite der Plattform aus überquert.
   (V) Yes / (X) No // * Implementiert, aber nicht ganz perfekt, mit erheblichen Fehlern. Ich würde hier 0,5 Punkte für die Vervollständigung des Artikels setzen.
4. Prozedurale Level-Generierung: Initialisierung und Ergänzung des Levels (an beliebigen Orten, jedoch mit bestimmten Regeln und Einschränkungen) im Handumdrehen neuer Plattformen und Feinde, wodurch für den Spieler eine verlockende Spielsituation entsteht (V) Yes
5. Eine „Kamera“, die dem Spieler folgt, wenn er das Level nach oben bewegt. Die Kamera sollte den Player für den Player sichtbar halten und schrittweise mit ihm „springen“, wobei neue Plattformen im Rendering-Bereich (in der Sichtbarkeit der Kamera) angezeigt werden (V) Yes
6. Game Over-Auslösemechanismus. Ein Spieler verliert, wenn er den unteren Rand des sichtbaren Bereichs erreicht (nachdem er bereits mindestens einmal gesprungen ist) (V) Yes
7. Einen Spieler punkten. Wir werden nur den Höhenzähler des Spielers aktualisieren. Wir werden den Zähler entsprechend der zuletzt erreichten Plattform aktualisieren (von der er das letzte Mal abgestoßen hat) (V) Yes
8. HUD: Spielerfortschritt anzeigen. Höhenanzeige. Optional scheint es im ursprünglichen Spiel keine Fortschrittsanzeigen zu geben. (V) Yes

Benchmark-Punktzahl: 7,5 / 8

Java

Vielleicht wäre es ein logischer und logischer Schritt, sich die Engines genauer anzusehen, in denen die Entwicklungssprache diejenige ist, in der ich die meiste Erfahrung und Geschicklichkeit habe, nicht wahr? Eigentlich haben mich Intuition und einige innere Empfindungen ein wenig davon abgehalten. Tatsache ist, dass ich als Student meinen Klassenkameraden mit der jMonkey Engine irgendwie jMonkey . Werkzeuge, Arbeiten mit dem Motor, Dokumentation, all dies zusammen ergab ein nicht sehr angenehmes Bild. Es schien, als hätte der Motor Ihnen einfach keine Gelegenheit gegeben, sich mit ihm anzufreunden, und seine Verwendung sah irgendwie unangenehm aus.

Trotzdem habe ich mich entschlossen, mir anzusehen, was heute verfügbar ist, und ich habe nur in Richtung Motoren geschaut, die nur 2D garantieren. Die 3D Unterstützung war mir egal. Eine der Engines, Lightweight Java Game Library 3 , hat ihren Namen und das einleitende Wort Lightweight . Ironischerweise wurden die einfachsten grundlegenden Beispiele auf der Hauptseite, mehrere Bildschirme lang, einfach verängstigt.

Ja, natürlich ist Java sehr ausführlich, was Sie wollten, sagen Sie. Aber ich weiß, dass man sehr kompakte und sehr ausdrucksstarke Dinge darauf schreiben kann. Ich habe eine schöne und kompakte API gesehen.
Und am Ende fiel die Wahl auf FXGL . Anfangs hatte ich keine Begeisterung und keine angenehme Aufregung, was vor dem Beginn der Entwicklung einer interessanten Sache oder Bibliothek passiert. Aber schon von den ersten Beispielen und kurzen Seiten mit Dokumentationen und Beispielen hat mich diese Engine immer mehr positiv überrascht. Alles war logisch, verständlich und konsistent in dem von ihm vorgeschlagenen Ansatz und der API. Es hat Ihnen definitiv geholfen, eine klare und flexible Schleife für Ihr Spiel, Ihre HUD , Ihr HUD , Ihre AI , Ihre Kollisionen und andere Elemente zu erstellen.

Interessante Momente und FXGL-Chips:

• Wie der Name vielleicht andeutet, verwendet die Engine für den visuellen Teil die JavaFX-API ( JavaFX wird als Grafik-Framework verwendet) mit all ihren Extras und Anti-Goodies für das Rendern und Layout. Im Allgemeinen halte ich dies für eine gute und recht fundierte Entscheidung. Auf diese Weise hat der Autor eine Reihe von Problemen vermieden (es ist nicht erforderlich, Ihre Rendering-Komponente zu implementieren und zu warten, Sie können eine verfeinerte Lösung aus dem Java Ökosystem verwenden). Folgendes sagt der Autor selbst in einem seiner ersten Tutorials, und dieser Satz hat mir sehr gut gefallen:

  
  

  "Für die meisten UI-Objekte verwenden wir einfach JavaFX-Objekte, da das Rad nicht neu erfunden werden muss."

  Aber im Allgemeinen erhalten Sie natürlich auch eine Reihe von Funktionen und einige Nachteile von JavaFX (ich kenne die Details nicht sehr gut), aber soweit ich weiß, gibt es einige Lizenzbeschränkungen für die Verwendung von JavaFX in Ihren Projekten, und es scheint, dass JavaFX geht und geht nur in begrenzten Lieferungen von JDK ( Oracle , vielleicht noch mehr).

  
  

• Ein Testprojekt aus dem Repository, auf dessen Grundlage ich mit der Gestaltung des Spiels begonnen habe, legt die Protokolle freundlicherweise nach jedem Spielstart im logs/ project ab. Dies ist sehr praktisch, Sie können sofort über die Debug-Informationen hinausschauen. Es ist sehr nützlich für die Diagnose und um zu verstehen, wo Sie Fehler gemacht haben, wenn Sie plötzlich einen Stecker in der Studie des Motors gefunden haben.

  
  

• Außerdem (anscheinend wieder mit Grundeinstellungen) bietet das Spiel ein Popup-Menü durch Drücken der Esc . Auch ein schöner Bonus, ich hoffe es ist angepasst oder zumindest durch Code oder Konfigurationen deaktiviert.

  
  

• Debag funktioniert endlich hier ! Endlich! In Love2D , gelinde gesagt, unpraktisch und unangenehm.

  
  

  Entwicklungsprotokoll

  
  

  Im Folgenden finden Sie eine kurze Zusammenfassung meiner Fortschritte, in der ich kurz notierte, was nach dem 30-minütigen Intervall erreicht wurde, sowie einige meiner Gedanken und Kommentare. Seht das Protokoll meines Bewusstseins in diesen 4 Stunden!

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

, , , ( ). , , Java FXGL , , Lua , . , , .

:

1. FXGL ? . Love2D , Defold , , , , Love2D - , .
2. , . , . (, ), . , - . , , , , . , , , . .
3. gif-, . . , , "" , .

?

, - , ?

Also:

1. , . , , , , . - , - ( Love2D ).
2. - , Love2D , . F to pay respect .
3. . , , , - - , , (, , )
4. . 4 , . - Game Jam , .
5. ! , , - Roadmap , , . (!) (?) . 30 . , . , , ! , pet- 44 - Ludum Dare .