Projekt Gruppe B


Space Kitty (letztes update 29.06.2007)

Spiel-Genre

  • 3D Shot 'em up
  • orientiert an Spielen wie R-Type, Gradius, Parodius, etc...
  • 2D Sidescroller in 3D
  • Third Person Shooter Elemente

Strory

Vor mehr als 1000 Jahren fassten die Shmox den waghalsigen Plan ein galaxisweites öffentliches Verkehrsnetz zu errichten. Leider stellte sich bald heraus, dass die Shmox zwar alle begnadete Weltraumbusfahrer waren, aber über keinerlei kaufmännisches Geschick verfügten. Ihr intergalaktisches Verkehrsunternehmen stand kurz vor dem Bankrott... Deshalb beauftragten die Shmox eine große intergalaktische Softwareschmiede mit der Entwicklung einer künstlichen Intelligenz, die ihrem Unternehmen wieder zu schwarzen Zahlen verhelfen sollte. Die K.I. „T-Boom“ wurde termingerecht fertiggestellt und auf den Zentralrechner des Shmox‘schen Mutterschiffes übertragen. Leider kam es wärend der Übertragung zu einem fatalen Fehler... T-Boom verlor den Verstand und versklavte das hilflose Volk der Shmox. Er baute ihr ehemals friedliches Verkehrsunternehmen zu dem größten intergalaktischen Rüstungskonzern aus und versucht seither sich das Universum Untertan zu machen... Es gibt nur eine, die den Mut hat sich ihm in den Weg zu stellen... SpaceKitty!

Charaktere

  • Space Kitty: Die Heldin des Spiels

  • Die Shmox: ehemalige Weltraumbusfahrer. Jetzt Skaven des AI Regimes

  • T-Boom: Der böse Roboter-Pirat

  • Space Kitty's Freunde

beschreibungen folgen

Steuerung

  • Maus: zielen
  • Maustasten: Schiessen, Spezial
  • Tastatur: hoch, runter, schneller oder langsamer fliegen

Power Ups

  • Energiecontainer (groß/klein): gibt etwas energie zurück
  • S: Speed up
  • P: Power up Weapon
  • Bombe: eine weitere kann benutzt werden

Waffen

die primärwaffe kann durch halten der Schusstaste aufgeladen werden. es kann immer nur eine Primärwaffe gleichzeitig getragen werden.

Primär:
  • Standart

  • Multiway (pro level steigt die anzahl der multi schüsse)
  • Wave (pro level wird der strahl breiter)

Sekundär:
  • Laser (wird diagonal verschossen und prallt an rändern ab)
  • Raketen (suchen und zerstören feinde)

Add-ons:
  • Drone (schiesst zusätzlich und umkreist das raumschiff)
  • Schild (wirft schüsse zurück)

Feautures

3D-Effects:

  • Vertex Buffer
  • Bump Mapping / Normal Mapping
  • Particle System
  • Height Mapping
  • Terrain Shader
  • Glow/Glare

Projektstand

haupt und hilfs 3D Models, 2D Artwork und Code-Design in Arbeit

abgeschlossene und angefangene Implementierungen:

  • Kollision
  • LevelSystem (erweitert: standardfunktionen)
  • WaffenSystem (erweitert: upgradebare Waffen)
  • FeindSysten (erweitert: mehr Feindarten)
  • Partikel
  • BumpMapping
  • VertexBuffer (still Buggy...)
  • VertexArrays
  • Glow
  • Motion Blur (im moment nicht funktional)
  • Planetenoberflächenlevel mit himmel und landschaft
  • Indoor level
  • Terrain Shader
  • Normal Mapping
  • EventSystem
  • Screen Text System
  • Hölenlevel
  • LevelScripts (neu)
  • Loading Screen (neu)
  • Boss (neu)
  • Space Level (neu)
  • Sound (neu)

Größte Meilensteine

Sound: zusammenschluss aus openAL und der fmod library

schwer zu fixende Fehler: fmod kann nicht 2 songs gleichzeitig spielen und openAL kann kein mp3. Also einfach beide genommen smile

Event System & Level Skript: Ging relativ flüssig zu implementieren. Im Grunde kann ein event alles sein (Hintergrund, messageBox, Sound, Boss, etc). Im Skript steht dann lediglich die art des Events und dessen Parameter. zusätzlich zur Zeit nach der das Event gestartet werden soll, wenn es nicht automatisch durch einen anderen auslöser gestartet wird.

schwer zu fixende Fehler: Probleme mit der exakten Zeit in msec. Ist jetzt ein zsammen schluss aus der windows.h Time und der ctime.h funktion um diese zu ermitteln.

Bumpmapping: hat lange gesauert bis wir die funktionsweise, wie es in gl verwirklicht wird, begriffen haben

schwer zu fixende fehler: * Bumpmapping sah schlecht aus: reihenfolge der aktiven texturen falsch, probleme mit gl_color_material (enable, disable hintereinander und es ging)

Glow: Render to texture und dann vertikal und horizontal vergrößert über die szene drübergeblendet.

schwer zu fixende fehler:
  • blend function mit unpassenden parametern (zu hell oder garnix zu sehen)
  • depthtest war aus, ... gewundert warum textur mit größerem z wert nicht größer wurde
  • andere objecte haben textur überschrieben, weil deren activeTexture nicht zurück gesetzt worden war

TerrainShader: anhand von einzelnen texturen (dirt, grass, stone, snow) eine heightmap zu texturieren

schwer zu fixende fehler:
  • vertexShader initialisierte nicht: mal wieder zu früh den vertexshader initialisiert (vor den glut initialisierungen)
  • vertexShader compilierte nicht: vertex Programm file falsch geparsed
  • geshadete objekte schwarz: (8 stunden gerackert weils weder fehler noch info gab...): texturen wurden wohl falsch eingelesen und konnten nicht geblendet werden. sind dann zu ner anderen imageFileReader Bibliotek umgestiegen.
  • plötzlich alles sehr langsam: texturen wurden nicht resetet (auf 0) und wurden bei jedem object geblendet...
  • andere objekte stellten ihre texturen falsch dar: nicht auf activeTexture(texture0) zurückgeschaltet und den TexCoordPointer nicht zurückgesetzt...

Normal Maps: Ein Mesh besteht aus: vertices faces (bestehend aus den vertices) normals und texture Coordinates

jetzt kommt zur normalen textur die normalMap dazu (so regenbogenfarbige bumpmap, die die höhe und im gegensatz zu normalen bumpmaps den winkel der textur an jedem pixel angibt.

diese allein per opengl mit der normalen textur zu blenden sieht schon nicht schlecht aus (wie normales bumpmapping) aber es fehlt die beleuchtung (zb bei einer steinmauer, dass die ränder der steine hell sind, die zum licht zeigen)

um das zu verwirklichken muss man für jedes face des meshs 3 vektoren berechenen um den sog. tangentspace (oder auch texturespace) aufzuspannen. sprich, ein eigenes coordinatensystem für jedes face.

die drei vektoren sind die tangente, die biNormale und die normale.

die tangente und die binormale sind die x und y vectoren des faces und die normale die z koordinate, welche alle zueinander orthogonal stehen.

jetzt muss man nur noch bei jeder lichtpositions änderung, den vector, der vom licht auf jeden vertex des meshes trift berechen: lichtvector = vertex-lichtpos

Dann braucht man zusätlich zur textur ein colorArray(eine zweite textur zur normalmap, welche dann addiert werden). die farben des Arrays werden pro vertex berechenet (opengl verfeinert die übergänge der faces wie wenn man glColor3f benutzt)

die farbe c des vertex kann man jetzt einfach berechen indem man:

c[vertexIndex].red = lichtvektor.x * tangente[vertexIndex].x;
c[vertexIndex].green = lichtvektor.x * tangente[vertexIndex].y; 
c[vertexIndex].blue = lichtvektor.x * tangente[vertexIndex].z; 


c[vertexIndex].red += lichtvektor.y * biNormal[vertexIndex].x; 
c[vertexIndex].green += lichtvektor.y * biNormal[vertexIndex].y; 
c[vertexIndex].blue += lichtvektor.y * biNormal[vertexIndex].z; 


c[vertexIndex].red += lichtvektor.z * normal[vertexIndex].x; 
c[vertexIndex].green += lichtvektor.z * normal[vertexIndex].y; 
c[vertexIndex].blue += lichtvektor.z * normal[vertexIndex].z; 

rot, grün und blau repräsentieren in der normalmap die x,yund z coordinaten des normalVektors.

so wird die farbe je nach lichteinfall verändert und schafft so geblendet mit der normalen normalMap eine völlig neue normalMap, die an lichtposition angepasst ist.

schwer zu fixende Fehler:

  • Es wird nicht angezeigt (nur normales bump mapping):
Ansätze: Fehler in der Mathematik: so lange mit internet-resourcen abgeglichen, bis sicher, das es stimmt. Sogar eine andere Art der berechnung implementiert und ergebnisse verglichen. Daraus geschlossen -> Fehler beim blenden der Opengl funktionen mit dem ColorArray. Reihenfolge ständig verändert. glEnable(GL_COLOR_MATERIAL) MUSSTE eingeschaltet sein, sonst wurde das ColorArray ignoriert beim zeichnen. Problem dabei war, das die normalmap allein flackerte wie die hölle. Erster gedanke war, dass opengl die farbverläufe der vertices falsch mischt, doch das war nicht der fall. Letzendlich nach ca 20 stunden stellte sich herus, das der "stride" parameter beim setzten des color arrays falsch war und deshalb das array falsch gelesen wurde...
  • Langsam
Da bei jedem schritt der Texturespace berechnet werden muss, wenn sich die position des objects oder des lichts verändert kam es zu frame einbußen. Durch Pointerbenutzung und einer ziemlich systemnahen berechnung gibt es jetz kaum mehr performance verlust. Ohne normalMapping: 40 fps, mit 35fps... Dafür sind die texturen jetzt wirklich hübsch smile .
  • Probleme beim berechnen von beweglichen Meshes
Da die Lichtposition für ein statisches mesh berechnet wird, wird das licht falsch angezeigt, wenn man das object zb dreht: ein würfel um 90° nach rechts um y achse. Wenn sich das licht jetzt rechts vom würfel befindet, wird die vorderSeite (die ja vor dem drehen nach rechts zeigte) voll angeschienen. Eine Lösunge (die noch nicht implementiert ist) wäre, dass nicht jedes mal das mesh ändert wenn es sich bewegt (was man gern machen kann wenn man eine diashow ansehen will), sondern einfach die tranformationsmatrizen des objects vor dem übergeben der lichtposition auf diese anwendet. so hat jedes object eine lokale lichtposition, die aber global wieder richtig sein sollte.

ParticleSystem: vertex array als Dots darstellen schwer zu fixende fehler:
  • langsam (wegen mallcos und upsates):

static precalculated memory (der dann geloopt wird) und linear memory mit start und endpointer

Screenshots

das erste bild aus der letzten version.

terrainShader.jpg

normal map von unten beleuchtet normal-map-bottom-light.jpg

normal map von oben beleuchtet normal-map-upper-light.jpg

normal map + fixed glare + neue Partikel + HUD anfänge glare-normal-hud.jpg

Release

http://www.cip.ifi.lmu.de/~promesbe/spaceKitty-release-20070717.rar

-- RobinPromesberger - 29 Jun 2007
Topic revision: r9 - 30 Apr 2008, RobinPromesberger
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Medieninformatik-Wiki? Send feedback