Zurück FunOrb Central: Teil 2 - Ist hier noch ein (Speicher-)Platz frei? Nächste

Projekttagebuch-Banner - FunOrb Central

28. Mai 2009 - Ist hier noch ein (Speicher-)Platz frei?

Dieses Tagebuch beschäftigt sich mit einem der größten Probleme bei der Entwicklung von FunOrb-Spielen und FunOrb Central: dem Speicherverbrauch.

Zirens Sprites
Hier seht ihr die verschiedenen Sprites von Ziren aus 'Der Turm'.
Hier seht ihr das komplette Bild.

Die Anordnung des Speichers in einem Computer ähnelt einer Pyramide. An der Spitze befindet sich ein kleiner, sehr schneller Speicher, eingebettet in den Prozessor (-Cache). Unten sitzt der langsame, aber sehr große Speicher (die Festplatte). Zwischen diesen beiden liegt der Speicher, um den es in diesem Tagebuch geht: der Arbeits- oder Hauptspeicher. Die Abstimmung des Datentransfers zwischen diesen drei Arten von Speicher hat einen großen Einfluss darauf, wie gut das Spiel läuft, und ist daher ein entscheidender Aspekt der Entwicklung.

Ein laufendes Java-Applet (z.B. ein FunOrb-Spiel) wird im Hauptspeicher abgespeichert. Alles, was zu dem Applet dazugehört (Grafiken, Musik, Soundeffekte, etc.), müssen ebenfalls in diesen Speicher geladen werden, bevor sie benutzt werden können. Leider haben die meisten installierten Versionen von Java diesen sogenannten 'dynamischen Speicher' auf 64MB begrenzt, und es fällt uns bei FunOrb oft schwer, dieses Limit nicht zu überschreiten. Ein Hintergrund in der Größe eines durchschnittlichen Bildschirms nimmt etwa 1MB in Anspruch und größere Hintergründe wie z.B. eine der Karten von Arkanisten oder die Sprites von 'Der Turm' sind sogar noch speicherintensiver.

Durch FunOrb Central wird der Speicher zusätzlich eingeschränkt, da das Spiel und FunOrb Central sich die 64MB teilen müssen. Aus diesem Grund haben wir beschlossen, FunOrb Central nur einen Speicherplatz von maximal 10MB einzuräumen, damit 54MB für das Spiel übrig bleiben. Viele FunOrb-Spiele benötigen momentan allerdings mehr und müssen überarbeitet werden. Dabei muss das ganze FunOrb-Entwicklerteam Hand anlegen!

Hier sind einige Methoden, die wir dafür benutzen werden:

  1. Inhalte, die nicht mehr benutzt werden, werden verworfen (z.B. ein Intro, sobald es fertig abgespielt wurde).
    Das klingt leicht, kann aber zu Komplikationen führen. Wir können nicht vorhersehen, wann die Daten wieder gebraucht werden, daher lassen wir normalerweise lieber alles im Speicher, damit das Spiel schneller läuft. Wenn das nicht möglich ist, speichern wir stattdessen eine komprimierte Kopie ab. Das ist nicht ganz so schnell, spart aber Platz.
  2. Das Datenformat im Speicher wird geändert.
    Wenn wir uns überlegen, wie wir Inhalte speichern oder laden wollen, müssen wir entweder bei der Schnelligkeit, der Qualität oder der Größe Abstriche machen. Normalerweise wählen wir die am wenigsten komprimierte Version, doch aufgrund von Speicherbegrenzungen müssen wir unter Umständen andere Optionen in Betracht ziehen, z.B. komprimierte Bilder*. Natürlich dürfen die Spieler eventuelle Qualitäts- oder Geschwindigkeitsverluste nicht bemerken!
Konzept von FunOrb Central
Ein sehr altes Konzept des Aussehens und der Features von FunOrb Central (Änderungen vorbehalten)
Hier könnt ihr eine größere Version dieses Bilds sehen.

Sogar diese Techniken reichen nicht aus, um FunOrb Central auf 10MB zu reduzieren, daher werden wir uns, nach Rücksprache mit Andrew, eines kleinen Tricks bedienen. Java wurde vor ein paar Jahren eine Ein-/Ausgabe-Methode hinzugefügt, die auf den etwas obskuren Namen NIO (für 'New Input/Output' oder 'Non-blocking Input/Output') hört. Diese dient in erster Linie dazu, Java-Anwendungen einen schnelleren Zugriff auf Dateien und Netzwerk-Geräte zu gewähren, hat aber einen interessanten Nebeneffekt: Über sie kann man den Applets etwas mehr als 64MB Speicher zuteilen. Wir können also hoffentlich den Großteil der Daten von FunOrb Central in diesem 'Niemandsland' ablegen und nur die Teile, die wir brauchen, für die Dauer ihrer Nutzung in den Hauptspeicher ziehen.

Im Zuge der Speicherverwaltung für FunOrb Central überlegen wir auch, was wir tun sollen, wenn uns zusätzlicher Speicher zur Verfügung steht. In den neueren Versionen von Java können die Applets auf mehr als 64MB Speicher zugreifen - vorausgesetzt, der Benutzer hat das in seinen Speichereinstellungen erlaubt. Wir wollen dieses Extra an Speicher natürlich so gut wie möglich nutzen. Einige unserer bestehenden Spiele tun das bereits, mithilfe einer Java-Technologie namens Soft Reference. Mithilfe dieser Technik belässt Java gewisse Daten solange im Speicher, bis der Speicherplatz ausgeht. Das sollte euch zum Beispiel bei 'Kerkersturm' auffallen: Wenn dem Spiel mehr Speicherplatz zur Verfügung steht, muss es nämlich nicht ständig Animationen dekomprimieren. Nach diesem Muster wollen wir auch FunOrb Central gestalten. Es sollen - sofern genug Platz ist - ganze Spiele im Speicher abgelegt werden, damit sich für die Nutzer der neueren Versionen von Java die Ladezeiten verbessern.

Was bedeutet das also für euch? Nun, wenn die bestehenden FunOrb-Spiele auf eurem Rechner laufen, solltet ihr auch mit FunOrb Central keine Probleme haben, denn die Anforderungen an euren Computer sind ähnlich. Außerdem werden wir die Ressourcen in den neueren Versionen von Java effizienter nutzen. Genauere Anforderungen und Empfehlungen geben wir euch kurz vor der Veröffentlichung.

Mod Artifice
FunOrb-Entwickler

*Photos werden oft im JPEG- (oder JPG-)Format komprimiert, wodurch man detaillierte Grafiken auf einen Bruchteil ihrer Größe reduzieren kann, während die Bildqualität weitgehend erhalten bleibt. Leider dauert es verhältnismäßig lange, solche Bilder wieder zu dekomprimieren. Daher kann man nicht für jedes Einzelbild eines Spiels komprimierte Grafiken benutzen.

Zurück zum Anfang