Minecraft2D

Dokumentation in Arbeit

Minecraft2D ist eines meiner ersten wirklichen Spiele die ich von grundauf programmiert hatte. Natürlich habe ich mir zuvor mit dem Programmieren von Tetris oder Vier Gewinnt Grundlagen im Bezug auf das Erschaffen von Videospielen angeignet, aber nach einiger Zeit habe ich mich dazu entschieden nicht nur eine simple „Kopie“ zu erschaffen sondern eine Art Neuinterpretation eines vorhanden Spiels zu kreieren. Die Wahl fiel darauf hin relativ schnell auf das Spiel welches mich wahrscheinlich am meisten in meiner Kindheit fasziniert hat: Minecraft. Minecraft war für mich immer ein Spiel der unendlichen Möglichkeiten und ich habe mir gedacht ob es nicht auch möglich wäre diese grenzenlose Erfahrung auf ein 2D Spiel zu übertragen. Dies war die Geburtsstunde eines Projektes, welches mich daraufhin noch vor einige Probleme stellen sollte.

 

1. Die Engine

1.1 Die Grundidee

Die Frage nach der Engine des Spiels war für mich sehr schwierig , denn ich wollte das Spiel nicht mithilfe einer Third-Party Engine (wie OpenGL, Libgdx u.s.w.) programmieren welches ein simple Grund hat:

  • Die Abhängigkeit: Dieser Punkt bezieht sich vor allem auf die Abhängigkeit der weiterführenden Entwicklung der Engines, denn bei mir ist bei einem vorherigen Projekt , welches ich mit Libgdx angegangen bin, die Problematik aufgetreten, dass plötzlich nach der Veröffentlichung einer neuen JDK (Java Developer Kit) Version das Spiel anfing Performance Probleme zu zeigen. Natürlich habe ich zuerst nach Fehlern in meinem eigenen Code gesucht, aber ohne Erfolg. Darauf hin habe ich nach einer Recherche erfahren, dass das Problem bei der Engine liegt, da die Entwickler kein neues Update für die Kompatibilität mit der neuen JDK Version bereitgestellt haben/  bereitstellen werden. Kurz gesagt: Ich konnte das gesamte Projekt in den Papierkorb verfrachten.

Nun würde man wahrscheinlich auf die Idee kommen eine Entwicklungsumgebung (wie z.B. Unity) zu verwenden, da diese in Sachen Kompatibilität sehr zuverlässig sind, aber auch in dieser Herangehensweise sehe ich einen negativen Punkt:

  • Die fehlende Erfahrungsgewinnung: Es mag vielleicht in wenig absurd klingen aber der rund lautet wirklich, dass mir bei der Arbeit mit z.B Unity der Bezug zur wirklichen Programmierung fehlt, da es für mich eher wie ein Baukasten wirkt. Natürlich würde das die Arbeit massiv vereinfachen, aber die ursprüngliche Intention des Projekts war es nicht in möglichst kurzer Zeit ein perfekten Spiel zu produzieren, sondern Einblicke in die tatsächlichen Hintergründe eines Spiels wie z.B. die Spielphysik zu bekommen.

Letzt endlich blieb mir also nur eine Möglichkeit: Das Aufbauen einer eigene 2D – Engine. Und im folgenden möchte ich einige wichtige Bestandteile jener anhand des entstandenen Spiels zeigen.

1.2 Der Code 


2. Die technischen Grundlagen

2.1 Rendering

Damit die Bewegungen und Aktionen, die über die Eingabegeräte (Maus, Tastatur) eingegeben werden ausgeführt werden können muss das JPanel dauerhaft neu gerendert werden. Innerhalb dieser Rendering-Methode, die sich fast in jeder Klasse befindet werden die verschieden Änderungen an der grafischen Darstellung vorgenommen. Da ich nicht auf jede dieser Änderungen eingehen kann werde ich im Folgenden mithilfe eines Beispiels das Grundprinzip erklären. 

if (mouseFixedItem != null) {
int x = GamePanel.mouse.scaledMouseX;
int y = GamePanel.mouse.scaledMouseY;
g.drawImage(mouseFixedItem.getImage().getScaledInstance(Game.ITEM_SIZE, Game.ITEM_SIZE, 4), x, y, null); }

Als Beispiel ziehe ich ein Teil der Render-Methode in der Inventory Klasse heran (siehe oben). Innerhalb dieser wird falls man in selbem Moment in dem die Render-Methode ausgeführt wird ein Item innerhalb des Inventars verschiebt das Item-Bild an der momentanen Position der Maus „gezeichnet“ . Dadurch gelingt es, dass das Item so lange an die Maus gefixt ist bis der Spieler das Item auf ein anderen Inventar-Platz zuweist und der überprüfte boolean Wert auf false gesetzt wird.

2.2 Die Spielwelt

Der wahrscheinlich wichtigste Teil eines Spiels ist die Welt in der sich der Spieler bewegt und in Minecraft ist eine Spielwelt nie wie die andere, was uns zu einem der auffälligsten Merkmale bringt, der zufälligen Weltengenerierung. Und dieser Punkt brachte mich lange Zeit zum verzweifeln, denn die Welt sollte trotz einer zufälligen Generierung noch authentisch und realistisch sein (Bild 1). Um aber zunächst ein wenig Ordnung in die zufällige Generierung der Welt zu bringen unterteilte ich die Biome der Welt (z.B. Wüste, Berge, Wald, Meer) in ähnliche Genererierungsmerkmale. Somit landeten die Wüste und der Wald zusammen in der Kategorie der flachen Biome, bei diesen musste man also nur dafür sorgen, dass die Welt zwar Unebenheiten  aufweist aber sich im Bezug auf die Höhe sich nicht soweit von der Starthöhe entfernen darf. Dies gelingt natürlich durch das Festlegen der Wahrscheinlichkeit für eine Erhöhung und für eine Vertiefung der Eben auf einen gleichen Wert (siehe Bild 2).