spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Als kleines Addendum möchte ich Nephtyz hier voll und ganz zustimmen, einen Probelauf machen hat uns sehr viel gebracht. Dadurch, dass wir den Vorteil hatten, einen Designer zu haben (Sanity) der einfach zwischen mir (Design und dabei am Stück Pixeln) und Programmierung springen konnte hat uns das Ganze natürlich enorm vereinfacht.

Wenn ich etwas mit Sanity am Design ausgearbeitet habe, musste ich Nephtyz nicht extra noch erklären was zu tun ist und wie wir etwas gemeint haben. Sanity hat einfach einen Task erstellt und im schlimmsten Fall noch eine kurze Rückfrage beantwortet. So konnte ich einfach weiter zeichnen und somit mehr oder weniger beide Arbeitsfelder zeitgleich abdecken.

Hier auch nochmal danke an alle Tester die ich nichts Ahnend gegriffen habe und in den Gottesdienst schicken musste.
Die gut angebrachte Kritik von den Testern hat uns gezeigt wo wir Fehler gemacht haben und wo wir richtig lagen!

Vielen dank für das Feedback der Jury nach der Entscheidung, wir haben Dadurch für unser eigentliches Hauptprojekt einen unglaublichen Selbstvertrauens-Boost bekommen und hoffen, dass wir auch bald mehr vorzeigen können.
Ich für meinen Teil würde es lieben, wenn eine so fähige Community wie diese hier unser Spiel testen möchte.

In diesem Sinne,
Gott sei mit euch! ( )

Also bei mir lief das in etwa so:

Da ich schon ein paar Jahre teilgenommen habe, war meine Vorbereitung (mal wieder), das Projekt aus dem letzten Jahr zu kopieren und alles bis auf ein Minimum zu loeschen oder auszukommentieren. Ich hatte also schonmal ein schwarzes Fenster und etwas auskommentierten Code um Grafiken/ Musik zu laden und anzuzeigen und ein kleines Framework, das beliebig viele Objekte verwalten kann.

Ich war dann etwa um 13:00 auf der Dusmania angekommen. Die Eroeffnungsrede lies ja etwas warten und in der Zeit beschloss ich dann schonmal mangels Mitstreiter, das ich diesmal irgendwas "im Grid" baue. Habe also meinen Gameobjekte Integer Koordinaten gegeben und dann konnte man sie mit z.b. den Pfeiltasten schonmal durch die Gegend fahren. Bzw. sprangen sie dann immer einen Feld weiter, was fuer den Anfang auch ok war. Ich baute schonmal vier von den Dingern, die erstmal einfach weisse Kreise waren und die ich dann schonmal unabhaengig ueber den Bildschirm fahren konnte. bzw. auch aus dem Bildschirm raus. Oder durcheinander hindurch...

Dann wurde endlich das Thema bekannt gegeben. Ich fand dann das Wort Tueftelarbeit, also klar: was zum tuefteln bauen! Ich hatte dann die Idee eine Art Sokoban zu bauen aber mit dem Twist, das man verschiedene Charaktere mit unterschiedlichen Eigenschaften hat. Urspruenglich wollte ich noch jemand, der was rotieren kann, aber das war dann zu kompliziert. Also machte ich meine Kugeln zu abgerundeten Rechtecken. Im Hintergrund zunaechst ein provisorisches Schachbrett, dann noch Spieler einfaerben, fertig (kurz vor 4): https://www.dropbox.com/sh/vlrtpdb05m1zu…ll-DSC07354.JPG

Als naechstes kam ein Levelformat, das einfach aus einer Text-Datei bestand. Z.B. '1'-'4' fuer die Charaktere "." -> begehbar "x" -> blockiert. Das war einfach einzulesen und funktionierte auf Anhieb. Die Spieler konnten allerdings einfach noch rausfahren in den blockierten Bereich. Kollision musste her. Da die Charaktere mehrere Felder belegten, brauchten sie also erstmal eine Groesse. Vor der Bewegung wurde dann einfach getestet, ob auf dem neuen Platz irgendwo eine blockiertes Tile ist, dann wurde die Bewegung abgebrochen. Jetzt kamen auch noch Kisten dazu, die dann verschiebar werden sollten. Erstmal waren sie aber nur ein billiger Charaktere-Abklatsch, der sich einfach nicht bewegen konnte. Im Prinzip wurde sie also nur angezeigt. Dann hatte ich die Idee mit den Eisfeldern. Das war einfach eine Untergrundtile mit der Eigenschaft, das man darauf bis zum naechsten Hindernis weiterrutschen sollte. Nach der Bewegung wurde nun also getestet, ob man komplett auf Eis steht. Wenn ja, wurde die Taste quasi automatisch nochmal gedrueckt. Das gab den verschiedenen Charaktergroessen auch gleich viel mehr Sinn, weil man quasi je nach Form mit einem "Bein" neben dem Eis bleiben konnte. Hier im Hintergrund sieht man wie das mit meinem Testlevel etwa aussah (halb 7): https://www.dropbox.com/sh/vlrtpdb05m1zu…ll-DSC07376.JPG

Jetzt brauchte ich Kollsion zwischen den Charakteren. Also einfach schauen, ob sich die Rechtecke der Charaktere ueberlappen. Das ging auch recht gut, auch wenn ich erst nen Fehler hatte, das alles ueberall 1 Feld zu gross angesehen wurde. Jemanden Im Eis zu stoppen bekam ich damit gleich noch dazu. Die Kisten waren dann natuerlich auch erstmal blockierend, da sie das gleiche Verhalten hatte. Es erhab sich mittlerweile aber das Problem, das man mit der Eisflaeche quasi in einer Bewegung durch den halben Level sprang. Daher baute ich eine Interpolation ein, damit sich ein Objekt langsam bewegt. Logisch ist es aber trotzdem sofort da. (Das fuehrte spaeter zu dem Fehler, das man Sachen auf der anderen Seite der Eisflaeche sofort anstoesst, obwohl man optisch noch nicht da ist.) Nun kam das schwierigste am Gameplay, das Verschieben der Kisten. Ich entschloss mich das so zu machen: Alle Kisten anschubsen, die den Weg evtl. blockieren, dann Charakter bewegen, soweit wie moeglich. Falls dann immer noch auf einer Eisflaeche, nochmal versuchen Kisten anzuschubsen und weiterbewegen usw. bis nichts mehr geht. Dummerweise gibts auch da kleiner Probleme, wenn man z.b. gleichzeitig durch eine Kiste und eine Wand blockiert ist, kann man die Kiste anschubsen, sich selbst dann aber gar nicht mehr bewegen. Als Letztes brauchte ich noch Zielfelder. Deren Logik ist einfach, wenn sie alle mit irgendwas kollidieren, ist der Level geloest! Jetzt versuchte ich nochmal die Grafik zu verbessern und ersetzte den Hintergrund durch abstraktere Formen.

Die Spiellogk war nurn komplett! Man konnte richtig spielen und ich baute die ertsen Level. Da die ersten zur Einfuherung gedacht waren, gingen die fix. Ich legte mir auch schon zu jedem Level einen Text bereit, um das Spiel zu erklaeren (9 Uhr): https://www.dropbox.com/sh/vlrtpdb05m1zu…ll-DSC07395.JPG

Dann beschloss ich, alle Erklaerungen als Audio auszugeben, da ich ohnehin die passende Hardware dazu dabei hatte und in den Notizen schon einige Sprueche gesammelt hatte. Der Code dazu war einfach hinzuzufuegen. Vermutlich einfach als Textausgaben. Ich malte auch die Tiles nochmal um und bekam eine Kiste von Bjoern. Die einzige professionelle Grafik im Spiel... Ich bastelte noch ein paar aufwendigere Level, wobei ich mir dann nich mehr so sicher war, ob die ueberhaupt jemand zu Gesicht bekam, daher gabs auch noch einen Cheat um weiterzukommen. Alle Tester schafften aber zumindest die ersten 5-6 Level immer auf Anhieb.

Womit ich im Nachhinein nicht zufrieden bin, einmal der Durchnittsspieler wird nur so 10 min Spass mit dem Spiel haben, weil er dann nicht mehr weiterkommt, da es zu schnell zu schwer ist. Und fuer Hardcoregamer sind natuerlich nicht genug Level da. Nochmal spielen, wird es vermutlich keiner. Zweiter Punkt ist die Steuerung. Spaetestens ab dem dritten Charakter nervt es einfach nur noch, das man fuer jeden einzelne Tasten merken muss. Man haette Pfeiltasten + Anklicken gebraucht. Witzigerweise habe ich es selbst vor ein paar Jahren schonmal mit Anklicken gemacht, als ich ein ganz aehnliches Spiel gebaut hab: http://www.games-net.de/hosted/tggc/scor…ne.php?action=1 Das war aber in der kurzen Zeit dann einfach nicht mehr umsetzbar, da ich auch noch Schlafen wollte. ;-)

Den genauen zeitlichen Ablauf der Bubble Schorle werde ich wohl nicht mehr hinbekommen, da ich zu Müde war, aber ein paar Dinge kann ich trotzdem mal zum Spiel sagen.

Ursprünglich bin ich auf die Devmania gefahren, weil ich irgendwas mit Python in Pygame entwickeln wollte, Toa erzählte mir auf der Hinfahrt von zwei Leuten, die das letztes Jahr gemacht haben. Die hab ich dann gleich angesprochen und rausgefunden, dass sie dieses Jahr aus Performancegründen C++ und SFML einsetzen wollen, was mich nicht daran gehindert hat, deren Team trotzdem beizutreten

Ich hatte zuvor weder mit SFML noch Box2D (was wir für Physik genommen haben) gearbeitet und seit ca. 3 Jahren nichtmehr in C++ entwickelt (nur Code gelesen und Papers angeschaut). 2D habe ich auch noch nie gemacht. Deshalb war ich erstaunt, dass wir überhaupt was fertig bekommen haben

Bis das Thema bekannt gegeben wurde haben wir noch die Toolchain ans Laufen gebracht. Dann standen wir eine Weile relativ ratlos vor dem Plakat, bis wir uns für Weinschorle/Winzerschorle entschieden hatten. Das heißt noch nicht, dass wir ne Idee gehabt hätten, aber wir brauchten sowieso noch einen Moment, bis das ganze Crosscompile-Buildsystem endlich funktionierte. Man hätte sich auch vorbereiten können, aber das wäre langweilig gewesen Etwas später hatten wir dann ein Makefile und ich konnte mich schnell in SFML und Box2D einarbeiten, während die anderen beiden an einer Spielidee feilten.

Dann kam uns die Idee, eine kleine Fliege oder Spinne in die Weinschorle fallen zu lassen, die sich dann über die aufsteigenden Luftblasen retten muss. Es galt, einen Prototypen zu bauen, um rauszufinden, wie man am besten die Physik einbaut. Zuerst entstand eine kleine GameObject-Klasse die das Bindeglied zwischen SFML und Box2D bilden sollte, darauf aufbauend kam dann eine Bubble-Klasse. Parallel haben wir uns ein Koordinatensystem ausgedacht, mit dem sowohl wir als auch Box2D zurechtkamen, wobei sich hinterher raustellte, dass wir garnicht gut damit klar kamen. Eine Einheit in Box2D sollten 500 Pixel darstellen, unsere kleinsten Blasen waren 0.1 m groß und damit 50 Pixel (Radius). Anschließend begann das Gerechne, bis die Koordinaten für das "Spielfeld" standen, hat es ganz schön gedauert und ich bin LongHairedHacker auch sehr dankbar, dass er das gemacht hat und nicht ich selbst.

Der Prototyp nahm Gestalt an, ich konnte 50 grüne Kreise auf schwarzem Hintergrund aufsteigen lassen

Es war mittlerweile schon relativ spät abends, und wir bauten die ersten Texturen und ein bewegliches Viewport ein. Die Rechnerei war ekelhaft, wir haben so oft über unser Koordinatensystem und die Box2D-API geflucht... Habe ich erwähnt, dass unsere y-Achse nach unten ging? So ganz unintuitiv? Das hat beim Umrechnen und Positionen ausrechnen immer wieder zu falschen Vorzeichen geführt, wobei wirs mit Humor genommen haben, unseren eigenen Code und uns selbst zur Sau gemacht haben ("Wer hat denn den Scheiß programmiert?!") und unsere Nachbarn wach gehalten haben

Die Texturen kamen, zunächst noch mit einem Grünstich und ohne unsere Schicke Umrandung. Nun ging es daran, den Spieler einzubauen, zunächst noch repräsentiert durch ein weißes Quadrat. Es war mittlerweile so ca. 12 Uhr nachts, und wir haben sicherlich mal wieder zwei Stunden investiert, Zahlen für Kräfte und Impulse in die Physikengine einzutippen. Die Spielerfigur, unsere kleine, putzige Spinne war mittlerweile auch fertig, die Physik stand und ich habe mich daran gemacht, ein Animationssystem zu bauen (SFML scheint sowas ja nicht von Haus aus zu bieten). Das war relativ schnell erledigt und funktionierte auch wunderbar Mittlerweile nahm auch die Grafik gestalt an, aber die Physik gefiel uns noch nicht. Mittlerweile hatten wir eine Abart von Stokesscher Reibung implementiert, auch bekannt als Socksche Reibung, damit unsere Blasen sich auch anständig verhalten und beim Aufsteigen nicht immer schneller werden Die Spinne sprang noch zu schnell, was wir zuerst darauf geschoben hatten, dass das Viewport hart an die Spielerposition gekoppelt war. Nachdem wir das dann kubisch ausgekoppelt hatten (linear sah doof aus, quadratisch ist problematisch wegen Vorzeichen, kubisch ist einfach geil) haben wir gemerkt, dass die Spinne wirklich zu schnell sprang, was sogar dazu führte, dass sie durch manche Blasen einfach durchspringen konnte. Also nochmal eine gefühlte Stunde Zahlen ausprobieren. Irgendwo hier kam dann erstmals das Gefühl auf, dass es eigentlich ziemlich viel Spaß macht, mit der Spinne über die Blasen zu springen und wir haben erstmals überlegt ob wir vielleicht wirklich einen dritten Platz machen könnten, einfach weil das Spiel lustig ist und das Tierchen so total putzig

Dann ging es daran, einen Windows-Build zu erstellen, was uns wieder zwei Stunden gekostet hat (etwa). Die Grafikerin ging so gegen 6 Uhr schlafen, der andere Programmierer so gegen 8. Ein Windows-Build wurde nicht fertig, wir vermuten, dass unser Crappy-Code-Design in der Main daran Schuld ist. Wir haben dann gegen 8 aufgegeben und beschlossen, dass wir auf Linux abgeben. Abschließend habe ich mich noch mit der SFML-Sound-API rumgeärgert, darin ist irgendwo ein Bug. Ich habe dann den Sound gefixt und in der Küche geholfen. Kurz vor Abgabe habe ich die anderen beiden geweckt, wir haben den Code gepackt und abgegeben. Obwohl ich an der Orga beteiligt war habe ich natürlich nicht an der Jury teilgenommen und weiß bis heute nicht, nach welchen Kriterien die Bewerten. Nur falls da jemand Zweifel bekommt

Wir haben nie mit einem zweiten Platz gerechnet. Im Nachhinein sind uns dann ein paar Gründe eingefallen, was an dem Spiel gut war:
- die Physik hat funktioniert. Es gab keine Glitches, tote Ecken oder Bugs die man ausnutzen konnte. Man kann mit der Spinne 3x springen, danach muss sie sich erst wieder auf einer Blase ausruhen. Wir haben Stundenlang Zahlen probiert für Wiederstandskraft, Impuls, Masse, etc. Während dieser Zeit war ich sehr froh, dass ich Physik studiere und die ganzen Zusammenhänge noch aus dem Stehgreif beherrsche.
- Die Spinne ist niedlich Und die Grafiken sahen am Schluss sogar echt schick aus, gewollt retro und pixelig aber auf eine liebenswerte Art und Weise

Ich bedanke mich bei dem tollen Team bei dem ich mitmachen durfte und bei allen anderen Devmania-Teilnehmern. Es hat mir wirklich Spaß gemacht

Wir werden bald noch eine Windows-Version herausbringen (arbeiten grade an einem kleinen Redesign der Main, was unsere Probleme hoffentlich lösen sollte), dann kann auch die Mehrheit der Anwesenden mal Spielen

Was wir hätten besser machen können/was nicht fertig wurde:
- es war geplant, die Bubbles noch auf der y-Achse zufällig zu verteilen und dafür zu sorgen, dass neue Bubbles nur dort entstehen, wo der Spieler ist. Ist uns zu spät wieder eingefallen.
- wir hätten uns vorbereiten können, garnichtmal fertigen Code mitbringen, sondern einfach mal mit SFML und Box2D rumspielen, was aber natürlich schwierig gewesen wäre, da wir uns erst auf dieser Devmania kennen gelernt haben
- mehr schlafen

Trotzdem (oder vielleicht genau deshalb) hatten wir eine Menge Spaß auf der Devmania und es hat mich gefreut auch mal wieder ein paar Gesichter hier aus dem Forum wiederzusehen

Gruß Socke

P.S. Rechtschreibfehler gehören dem Finder Ich übernehme keine Garantie für Zeitspannen und Zeitpunkte Das war alles Gefühlt

Unser Erfahrungsbericht zu Ninja Hobo Connoisseur!



Zunächst einmal: Ich wollte für diesen Contest unbedingt unsere (praktisch hauseigene) HTML5 Spielengine benutzen, an der wir schon eine ganze Weile arbeiten. Wir haben die Engine bewusst getrennt vom Spiel entwickelt und der Contest war dann Test um zu sehen wie gut uns diese Trennung gelungen ist.

Dies war unsere aller erste Devmania und wir waren entsprechend knappt aufgestellt. Von unserem Entwicklerteam (Radical Fish Games) waren nur 2 Personen anwesend: Ich (Grafik & Programmierung) und Intero (Soundtrack).
Dazu kam dann noch Sacaldur, der uns seine JavaScript Kenntnisse angeboten. Schließlich hat er sich vor allem um das Level-Design gekümmert, da es (wahrscheinlich) zuviel Zeit gekostet hätte ihn in unsere Engine einzuarbeiten.

Aber zunächst einmal zum Spiel selber.
Unser Schlüsselwort war "Winzerschorle". Auf dem Titelblatt war ein kleiner Bericht über eine (so typisch deutsche) Haarspalterei: "Winzerschorlen" soll es nur dann heißen, wenn die Weinschorle tatsächlich vom Winzer kommt. Sonst nur "Weinschorle".
Daraus entstand dann die Idee eines Kämpfers für die korrekte Bezeichung von Winzerschorlen. Dementsprechend jemand, der alle "falschen" Winzerschorlen zerstört.
Und so kam es zum Ninja Hobo Connoisseur. (ich bin mir nicht mehr so ganz sicher, wie wir auf Ninja und Hobo kamen... wahrscheinlich war es Schicksal).

Ausarbeitung der Spielidee:
Noch während die ersten Vorträge liefen haben wir uns überlegt, wie wir das Gameplay genau gestalten. Ich muss gestehen dass uns in dem Fall wirklich der alles entscheidende Geistesblitz gefehlt hat. So kam es am Ende auf das (recht banale) "bewerfe alle Weinflaschen mit Korken". Dazu kamen dann noch ein paar Sonderfähigkeiten (in Form von "echten" Winzerschorlen) um etwas Abwechslung rein zu bringen:

• weiße Winzerschorlen lassen einen weit springen
  
• rote Winzerschorlen erlauben das werfen von flambierten Korken um gefrorene Flaschen zu brechen
  
• rosette Winzerschorlen erlauben das Anziehen von metallenen Flaschen.
  

Darüber hinaus hatten wir Ideen für einen (epischen) Flaschenbosskampf. Das haben wir uns aber schon bewusst als "optional" notiert bzw. "zum Schluss wenn noch Zeit ist".

Schlussendlich war das Spielkonzept dann doch erstaunlich nahe an unserem Hauptprojekt (CrossCode) - anstatt Bälle wirft man Korken, ansonsten rennt man herum und springt auf Plattformen.
Das hängt sicherlich damit zusammen, dass die Engine all diese Sachen gut unterstützt - man hätte sich aber auch was ganz anderes ausdenken können. Richtig gebunden waren wir nur an der grafischen Perspektive.

Arbeitsaufteilung

Arbeitsaufteilung war gerade am Anfang kritisch. Nachdem das Konzept in etwa fest stand, brauchten wir erstmal die Grundtechnik möglichst schnell entwickelt. Erst wenn die Technik halbwegs stand, konnte man mit dem Level Design beginnen.
Nun hat es leider viel zu lange gedauert, bist die Grundtechnik stand und der Grund dafür war folgender: Wir haben uns zu Beginn zu sehr auf die Grafik konzentriert. Inbesondere habe ich viel Zeit (ca. eine Stunde) alleine damit verbracht eine aufwändige 6 Posen Lauf Animation (in 3 unterschiedlichen Richtungen!) zu pixeln - bevor ich richtig angefangen habe, die Technik umzusetzen. Es wäre definitiv sinnvoller gewesen, zuerst mit Platzhaltern zu arbeiten.

Aufgrund dieser Fehlentscheidung konnte Sacaldur als Leveldesigner in den ersten Stunden nicht wirklich viel unternehmen. Glücklicherweise kamen wir dann auf die sinnvolle Idee, dass man die Level zumindest schon mal konzeptionell vor-skizzieren kann, damit dann die Umsetzung schneller und leichter von der Hand ging. Daraufhin habe ich mich darauf konzentriert zunächst "technische Platzhalter" für den Leveleditor zu basteln, die man schon platzieren konnte obwohl sie noch nicht wirklich funktionierten. So konnte Sacaldur dann nach einiger Zeit nach und nach damit Anfangen die Level zu gestalten. Die Einführung zum Leveleditor für Sacaldur (der wie gesagt unsere Engine nicht kannte) ist im Endeffekt zu knapp ausgefallen, weshalb es zwischendurch zu einigen Komplikationen kam - insgesamt hat er sich aber sehr gut geschlagen und sich das meiste Detailwissen eigenständig angeeignet (in dem Sinne: Hut ab!).

Intero hatte sich Anfangs an Grafiken versucht sich dann aber recht bald voll auf Soundtrack und Soundeffekte konzentriert. Damit war er dann auch die meiste Zeit beschäftigt.

Während Intero sich dann etwas Schlaf gönnen konnte haben Sacaldur und ich die Nacht knallhart durchgearbeitet. Die meisten Features haben wir dann tatsächlich umgesetzt bekommen, lediglich die rosette Winzerschorle hat nicht mehr reingepasst.
Dafür haben wir es geschafft das Spiel halbwegs rund zu machen: Es gab einen Startbildschirm und ein Ende mit Spieldauer. Dank Sacaldurs durchgehenden Ansatz hatten wir am Ende ganze 16 Level zusammen gehabt (vielleicht waren dies ein paar zuviel dafür das es nur so wenig Gameplay Inhalte gab).

Insgesamt war die Arbeitsaufteilung am Anfang etwas holprig, hat sich dann aber nach einiger Zeit soweit eingependelt, dass jeder einen guten Teil beitragen konnte.

Ergebnis

Wir haben ein halbwegs rundes Spiel fertig gestellt. Ein paar der geplanten Features konnten wir zwar nicht mehr umsetzen, aber am Ende kam etwas raus, was zumindest eine gewisse Menge Spielspaß hatte.
Persönlich war ich mit dem Ergebnis sehr zufrieden. Auch die Engine hat sich bei der Entwicklung gut gehalten. So kann man sagen, dass die Trennung zuwischen Engine und Spiel bei CrossCode gut gelungen ist.
Im Endeffekt hat unser Spiel dann leider keinen Preis gewonnen. Ich muss gestehen, dass ich ein bisschen enttäuscht war. Ich kann die Entscheidung der Jury aber auch irgendwo nachvollziehen. Unser Spielkonzept hätte sicherlich origineller sein können - Gameplay mäßig war es sehr nah an unserem Hauptprojekt.

Und hier kann man das ganze Spielen:
Ninja Hobo Connoisseur
(das ganze läuft im Browser. gestest unter Chrome, Firefox und Internet Explorer 10)
Anmerkung: Wir haben das Spiel ein klein wenig aufpoliert. Der eigentliche Spielinhalt ist aber praktisch unverändert.

Schluss endlich hatten wir aber vor allem eine Menge Spaß und viel dazugelernt.
In dem Sinne jetzt zum Abschluss:

Lessons learned

• Beim nächsten mal die Technik voll priorisieren und notfalls mit Grafikplatzhaltern arbeiten
  
• Jeweils eine Person für Grafik und Technik ist echt praktisch für Arbeitsaufteilung
  
• Etwas mehr Zeit für ein interessantes Spielkonzept und dafür weniger für eine aufwändiger Umsetzung
  

Und das war es dann von meiner Seite!
Dann spätestens bis zur nächsten Devmania!