www.OnlineSpiele.de, Düsi's Internet-Spielhalle - Making of WebValley 

English version on www.InternetGames.de

Weitere Spiele | Downloadseite DotValley | WebValley | Spielanleitung | Impressum


The Making of WebValley

Hier erfahrt Ihr aus erster Hand alle geheimen Zutaten zu solch einem Spiel! :-)


Die Macher

Daniel Schwinn
"Düsi"

Programmierung der Java-Version

Tobias Schwinn
"Tobi"

Erstellung der Grafiken

Thilo Schwinn

Leveldesign und
Programmierung der Urversion

 

Die Entstehungsgeschichte

1987 Die Ur-Version von WebValley entstand als eine Studie für ein Boulderdash-ähnliches Spiel auf dem Computer ENTERPRISE 128. Aufgrund technischer Besonderheiten des Enterprise-Computers war es möglich eine große Anzahl Objekte schnell zu bewegen, was Effekte wie das Stürzen von mehreren Dutzend Steinen gleichzeitig ermöglicht. Dies auszuprobieren war eine der Zielsetzungen dieser Studie. Für das damalige Konzept von "Dot Valley" entstanden bereits einige charakteristische Levels in denen zahlreiche Steine und Diamanten in tiefer liegende Kammern stürzen können.
1993 Das Programm wurde unter dem Namen DOT VALLEY von Thilo Schwinn in der Programmiersprache Pascal auf dem PC für MS-DOS fertiggestellt. Hierbei wurden weitere Spielelemente eingeführt und die neue 16-farbige Grafik von Tobias Schwinn erstellt. Die technischen Programmteile (Grafik- und Tastaturtreiber sowie Runtime-Module) wurden von Daniel Schwinn programmiert.
2000 Die Umsetzung in Java durch Daniel Schwinn konnte nach den Erfahrungen, die mit WebTrouble gewonnen wurden schon fast routinemäßig durchgeführt werden. Für die Java-Version wurden die Grafiken geringfügig überarbeitet und in Farbzahl sowie Auflösung etwas verbessert.

Die Grafik

Die Grafiken im Spiel wurden von Tobias Schwinn entworfen. Hierzu kam unser eigenes Grafikprogramm "VGAMAL" zum Einsatz, mit dem schon die Grafiken für zahlreiche Spiele aus dem Hause düsi computer software entworfen wurden. Alle grafischen Bestandteile des Spieles wurden für die Online-Version in GIF-Grafiken umgewandelt.

Das ganze Spiel wird aus einfachen Grafikelementen zusammengesetzt, von denen jetzt einige vorgestellt werden.

Steine und Erde

Aus den folgenden einfachen Grafikelementen wird jeweils der größte Teil des Spielfeldes aufgebaut. Für die Erde stehen 4 verschiedene Zeichen zur Verfügung, um größere Flächen abwechslungsreicher zu gestalten. Alle Spielelemente haben eine Größe von 32 x 32 Pixels.


g71.gif .. g74.gif

f6.gif

f8.gif

f16.gif

Die Spielfigur

Für die Spielfigur werden für jede Richtung und Bewegungsart eigene Grafiken benötigt. Ein paar davon sind hier stellvertretend zu sehen. Zu jeder dieser Grafiken existieren weitere Grafiken für die zugehörigen Bewegungsphasen der entsprechenden Aktion.


g91.gif

g101.gif

g111.gif

g121.gif

g131.gif

g141.gif

Grafik für das Spielfeld

Der Rand des Spielfeldes und die Meldungsfenster sind ebenfalls Grafiken, als Beispiel zeigen wir hier die Statusleiste vom unteren Bildschirmrand.


panele.gif

Die Zahlen in den Zählern werden aus einzelnen Grafiken zusammengesetzt, von denen die ersten 5 hier zu sehen sind:


n1.gif

n2.gif

n3.gif

n4.gif

n5.gif

Die Programmierung

Die Programmierung von WebValley in Java erfolgte durch Daniel Schwinn, der schon Teile der Version für MS-DOS in Pascal programmiert hatte.

Bei der Programmierung von WebValley konnte - wie schon zuvor bei WebTrouble - keine 1:1-Umsetzung des ursprünglichen Pascal-Programmes in Java vorgenommen werden. Auch hier mußten einige Dinge in Java recht umständlich realisiert werden. So enthielt die Pascal-Version eine Sprungtabelle mit den Bewegungsprogrammen der Grafikelemente durch die extrem schnell und direkt die korrekte Animationsroutine angesprochen werden konnte. In Java wurde dies dann durch einen umfangreichen switch-Befehl realisiert.

Ein weiteres Problem ergab sich daraus, daß Java-Programme mit Animation trotz Pentium sonstnochwas und Beschleunigergrafikkarte von der Geschwindigkeit her langsamer sind als MS-DOS-Programme auf einem 286'er. Auch konnten Beschleunigungstricks, wie z.B. Programmteile in Inline-Assembler oder linearer Zugriff auf mehrdimensionale Arrays in Java nicht entsprechend angewendet werden.

Im Folgenden wird die historische Entwicklung einer der Programmroutinen aufgezeigt. Der gezeigte Programmteil zeigt die Daten (Level, Score, ...) im Fussteil des Spielfeldes an.Gezeigt wird jeweils die Definition der beteiligten Variablen und der entsprechende Programmabschnitt. Streng geheim!

ENTERPRISE-Version in Z80 Assembler

Diese Version wurde mit dem legendären Assembler DEVPAC von Hisoft erstellt. Die Programmierung in einer Hochsprache war aus Geschwindigkeitsgründen nicht möglich - das Programm wäre viel zu langsam geworden.
In der Routine printsco werden im Register ix des Prozessors direkte Adressen im physikalischen Videoram berechnet, die dann von der Zahlenausgabe als Startposition verwendet werden. Im Register hl wird der jeweils auszugebende Zahlenwert übergeben.
Hinter der Bezeichnung zahl_01 befinden sich als Beispiel die Gtafikdaten für die Ziffer "1". In der Enterprise-Version sind diese so wie alle anderen verwendeten Grafikzeichen direkt im Programmlisting als sogenannte Definded Bytes abgelegt.

graph     equ #7000 ;Segment ff

score     defw 0
time      defw 0
level     defb 0

...
...

zahl_01   defb #00,#00,#00,#00,#01,#0F,#0F,#08
          defb #02,#0F,#0F,#40,#03,#00,#00,#C0
          defb #03,#00,#00,#C0,#03,#00,#00,#C0
          defb #03,#00,#00,#C0,#03,#00,#00,#C0
          defb #03,#00,#00,#C0,#02,#0F,#0F,#40
          defb #01,#0F,#0F,#08,#02,#0F,#0F,#40
          defb #03,#00,#00,#C0,#03,#00,#00,#C0
          defb #03,#00,#00,#C0,#03,#00,#00,#C0
          defb #03,#00,#00,#C0,#03,#00,#00,#C0
          defb #02,#0F,#0F,#40,#01,#0F,#0F,#08

...
...

printsco  ld hl,(score)
          ld ix,graph+(18*80)+4
          call prnum5
          ld hl,(time)
          ld ix,graph+(18*80)+28
          call prnum4
          ld hl,(level)
          ld h,0
          ld ix,graph+(18*80)+52
          call prnum2
          ret

PC-Version in Turbo Pasal

Die Version in Turbo-Pascal ist wesentlich einfacher zu überschauen, obwohl hier bereits ein größerer Teil des Programmes gezeigt wird. Über die Variable screen wird auf einen Speicherbereich zugegriffen, der von der Struktur her direkt das Video-RAM abbildet. Das Unterprogramm printstr erledigt die Ausgabe einer kompletten Zahl, die als Text übergeben wird. Die Position wird als Koordinaten übergeben: In Y-Richtung in Zeilen und in X-Richtung in Vielfachen von 8 Pixels. Auch hier arbeitet das Programm mit Zahlenwerten, die direkten Adressen im Bildschirmspeicher entsprechen.
Die Funktion formatnat wird zur Formatierung der Zahlen als String verwendet bevor diese ausgegeben wereden.
Die Grafikdaten für die Ziffern werden jedoch nicht mehr im Programmlisting definiert sondern als Binärdatei im direkten Byteformat für den verwendeten Grafikmodus nachgeladen. Hier besteht natürlich eine direkte Abhängigkeit von einem bestimmten Grafikmodus auf einer bestimmten Hardware, in diesem Fall eine VGA- oder EGA-Grafikkarte.

type
  ega_scr=array[0..3,0..199,0..39] of byte;
  ega_handle=^ega_scr;

var
  screen:ega_handle;
  score:longint;
  level:integer;
  tntflag,bombeflag:integer;

...
...

procedure printstr(x,y:integer;s:string);
var
  n:integer;
begin
  for n:=1 to length(s) do begin
    put(screen,x,y,zahlen[ord(s[n])-48]);
    inc(x,2);
  end;
end;

procedure printscore;
begin
  printstr(4,172,formatnat(score,5));
  printstr(19,172,formatnat(prozent,2));
  printstr(27,172,formatnat(tntflag,2));
  printstr(35,172,formatnat(bombeflag,2));
end;

JAVA-Version

In der Java-Version wird auf die Bildschirmausgabe über das Grafikhandle BufGr zugegriffen. Das Programm funktioniert hier fast identisch mit der Version in Pascal. Im Unterschied zu den beiden anderen Versionen wird hier nur noch mit Koordinaten innerhalb des Applets gearbeitet. Die tatsächliche Speicheradresse im Video-RAM ist hier völlig unbekannt, das Programm kennt nicht einmal den genauen Aufbau der Grafikdaten. Die Ziffern sind als einzelne GIF-Bilder geladen worden und werden mit drawImage Ausgegeben.
So kann das Programm für unterschiedliche Grafikkarten oder Betriebssysteme identisch aufgebaut werden, obwohl der tatsächliche Aufbau des Video-RAM auf verschiedenen Systemen unterschiedlich ist.

int prozent;
int score;
int TntAnzahl,BombeAnzahl;
Image[] zahlen = new Image[10];
Graphics BufGr;

...
...

void printstr(int x, int y, String s){
  int nr;
  for (int n=0;n<s.length();n++){
    nr=s.charAt(n)-48;
    BufGr.drawImage(zahlen[nr],x,y,this);
    x+=32;
  }
}

void printscore(){
  printstr(64,344,formatnat(score,5));
  printstr(304,344,formatnat(prozent,2));
  printstr(432,344,formatnat(TntAnzahl,2));
  printstr(560,344,formatnat(BombeAnzahl,2));
}

So, jetzt haben wir genug aus dem Nähkästchen geplaudert ... man muss der Konkurenz ja nicht alles im Internet präsentieren. :-)


(c) 1999 by düsi computer software, Daniel Schwinn, Römerturmstrasse 25, D-73547 Lorch