[Diskussion] The Art of the Sword (Arbeitstitel) - Herangehensweise

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • [Diskussion] The Art of the Sword (Arbeitstitel) - Herangehensweise

      Hallo liebe Gamemaker-Domäne,

      in dieser Diskussion soll es um mein Projekt gehen. Bevor ich euch aber einen ineffizienten Blocktext zumute, hier die relevanten Informationen in gut bekömmlicher Kurzform :D .

      WAS ist mein Projekt: TAOTS (AT), ein rundenbasiertes RPG, inspiriert durch Spiele wie die Final Fantasy-Reihe bishin zu Teil X, 2D, Einflüsse aus diversen RPGs unterschiedlichster Art, vorerst eine spielbare Demo mit den Kern-Features.

      WER bin ich und was ist mein Hintergrund: Vorstellungsthread

      WIE sieht mein Game-Design aus: Hier folgt in Kürze ein Link zu meinem Konzept.

      Diskussionsthematik:

      Die Diskussion in diesem Thread soll mir durch eure hochgeschätzten Erfahrungswerte helfen, die geignete weitere Vorgehensweise meines Projektes zu definieren. Vor Allem in Bezug auf Code-Organisation meiner Engine und das effiziente Anlegen der Datengrundlagen des Spiels. RPGs dieser Art sind in Hinblick auf die reine Code-Basis wahre Datenbanken Ungetüme. Um darüber zu diskutieren, wie der Code am besten organisiert werden sollte, müsst ihr natürlich wissen was die Engine können soll und was ich bereits gemacht habe. Da dies hier nicht der oben erwähnte Konzeptthread ist, werde ich logischerweise genre-bezogen fragen, nicht aber auf mein Projekt bezogen. Denn hier soll es nicht um die Features gehen, sondern um das Anlegen von Datenbanken, aus denen die für die späteren Features relevanten Variablen effizient, also ausschließlich bei Bedarf abgerufen werden können. Das reicht für die aus, die das Genre kennen und bewahrt uns davor den Rahmen zu sprengen.

      Was soll die Engine können? bzw. Was soll die Engine jetzt als Nächstes können?

      Die Engine soll überall, wo es möglich ist, erst dann Informationen (Variablen, Scripte) in den Speicher laden, wenn sie gebraucht werden und diese sofort wieder aus dem Speicher befördern, wenn sie erstmal nichtmehr gebraucht erden. Dies soll die nötige Rechenleistung auf ein machbares Minimum reduzieren und so eine gute Performance gewährleisten. Ein persönlich favorisierter Nebeneffekt davon ist für mich, dass durch die dafür notwendige Code-Organisation einen angenehm organisierten Resource-Tree zur Folge hat. Soweit die Theorie. Ein geignetes Beispiel liefere ich im Abschnitt "Was ich bereits gemacht habe", direkt hierunter. Anfängerproblematik hier: Meine Kenntniss von Variablen (vornehmlich Arrays) wurde zwar durch den unschätzbar talentierten und hilfsbereiten Husi schon vertieft. Ich hätte jetzt aber noch keine praktische Vorstellung davon, wie bzw. wo ich Variablen optimalerweise platzieren sollte um sie, in Bezug auf die oben angepeilte Rechenleistungs-Effizienz, sowohl nur bei Bedarf in den Speicher laden lassen zu müssen und es gleichzeitig zu ermöglichen bestimmte Variablen dieser Datenbanken dauerhaft zu verändern. Ein Beispiel wäre hier ein Script (Script nur weil ich mir das gerade so vorstelle), dass als Speicher für die aktuellen Werte eines Kämpfers funktioniert, welche im einfachsten Fall beim aufleveln des Kämpfers eine dauerhafte Erhöhung des Values der betreffenden Variable (bspw. Stärke) zur Folge hat. Es müsste also das Script mit den Kämpferwerten gecalled werden, dann die Änderungen vorgenommen werden, das "geupdatete" Script gespeichert werden und dann wieder bis zum nächsten Gebrauch aus dem Speicher entfernt werden. Ich weiß ehrlich gesagt noch nichtmal, ob das geht. Ich könnte mir auch vorstellen, dass die Variablen im Script zwar jedes Mal wie gewollt verändert werden, aber beim nächsten callen des Scripts nur die Ausgangspunkt-Version des Scripts gerufen wird, wodurch die gewünschte Funktion ausbleiben würde.

      Was ich bereits gemacht habe: Das Spiel hat momentan drei Räume, jeder Raum ist ein Platzhalter für einen Aspekt des Spiels(Ein Hauptmenü, eine lokale Map, eine Battlemap). So kann ich in voneinander getrennten Departments arbeiten und testen, was echt angenehm ist. Im Ressource-Tree habe ich bereits für jeden Raumtyp (Händlermenü, Spielermenü, Hauptmenü, Lokale Map, Weltkarte, usw.) einen Raum angelegt. Ein persistentes Objekt, meine Engine, wird zu Beginn des Spiels kreiert und kontrolliert und verwaltet allen Code. So ist es zum Beispiel möglich mit F1 bis F3 direkt zu den entsprechenden Räumen zu springen um den neuesten Code zu testen. Das persistente Objekt beinhaltet ein Script indem durch eine Kombination aus Array und Enumerator (Finite-State-Machine) der aktuelle Raum erkannt und dem diesem Raum zugeordneten Steuerungstyp (Menu, Map) entsprechend entweder das Script zur Bewegung der Spielfigur oder die Menüsteuerung geladen wird. Das funktioniert soweit und stellt das im vorigen Beispiel angekündigte Beispiel meiner Vorstellung von effizienter Code-Organisation dar. Im dritten Raum, der Battlemap, möchte ich nun beginnen, das grundlegende, genretypische Kamfsystem zu entwickeln. Anfängrproblematik hier: Bis jetzt werden die sechs Kampfteilnehmer-Objekte einfach durch die Raumoptionen kreiert. Im fertigen Zustand muss das Spiel aber zu Kampfbeginn sowohl aus den aktuellen Einstellungen des Gruppenmenüs des Spielers die richtigen Kämpferobjekte kreiieren und platzieren, als auch zufallsbasiert einen der diesem Raum/ dieser Map zugeteilten Gegnertrupps kreieren und platzieren. Meine ganz konkrete Frage hierzu: Sollte ich zuerst die Datenbank bzw. die Datenbanken entwickeln, die es dem Battlecontrol-Objekt ermöglichen selbstständig die richtigen Kämpfer-Objekte zu platzieren, oder das erstmal ruhen lassen und daran arbeiten, dass die Geschwindigkeitsvariablen der existierenden Kämpferobjekte vom Battlecontrol-Objekt erkannt, verglichen und daraus eine Zugreihenfolge erstellt wird, nach welcher die Kämpfer ihren Zug bekommen?

      Ich hoffe meine Diskussionserläuterung war für ihre Länge ganz angenehm, vielleicht sogar interessant zu lesen und freue mich auf den Austausch mit euch. Mehr zu meinen Features und Mechanics gibts wie angedeutet im Konzeptthread, den ich noch erstellen werde.

      Lieben Gruß,

      Ben

      EDIT: Ich hoffe das meine Erläuterungen jetzt nicht zu sehr ins technische für dieses Forum gehen. Nochmal: Es geht um darum, was sinnvoll wäre als nächstes zu tun. Nicht wie ich das machen soll!

      Nochmals lieben Gruß,

      Ben
      TAOTS: The Art of the Sword (AT) aka The Dream <3

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Riku_no_Sogen ()

    • Hi, ich finds cool, wie viel du immer schreiben kannst :)

      Zwar konnte ich dem nicht ganz folgen, aber letzter Zeit finde ich ds_maps ganz angenehm.
      Meine Vorgehensweise:
      Du kannst ein Objekt erstellen, welches für alle Teilnehmer ist. Dein Battlecontroler muss dann (keine Ahnung wann ein Kampf stattfindet) alle Teilnehmer ermitteln und ein Array, der Größe: Anzahl der Teilnehmer, anlegen. Auf jeder Position erstellst du eine map und füllst sie mit Informationen, wie "health","damage","array_pos"<- für die Position auf dem Array,usw. und erstellst jedes Mal ein neues Objekt, dem du diese Map zuweist und fügst zu Map dann evtl. "object_id" hinzu, um zu wissen welches Obj das dazugehörige ist. Danach erstellst du eine Zählervariable, die du auf 0 setzt. Nach jedem Zug wird die Variable +1 genommen und wenn > als Teilnehmer Anzahl = 0. Geht ganz einfach über Modulator(oder wie das ding heißt): num = (num+1)%len
      Du kannst es dann so lösen, dass jedes Obj nachschaut, welches Obj gerade dran ist, indem er die Zählervariable vom controler mit seiner überprüft.

      Das wäre eine von vielen Möglicheiten ^^
      Ein Bug ist mehr als nur ein Bug, es ist ein... Käfer!
      Egal, wie gut du eine Mauer baust, sie fällt um.... der klügere gibt nach :D

      Willst du mit mir auf Discord Chatten/Quatschen?
      Meine Husi's Tutorial Reihe
    • Ich finde es schonmal gut, dass du so strukturiert an dein Projekt herangehst. Also geb ich dir erstmal ein paar allgemeine Tipps.
      -jeder code der mehrmals vorkommt, sollte am besten gleich in ein script verpackt werden.
      -benutz keine "magic numbers" also hardgecodete Zahlen sondern mach daraus variablen. Gerade bei RPGs.

      Zu deinem Ansatz mit mehreren Räumen;
      Ich nehme an battcontrol ist ein persistentes Object, dass je nach Raum verschiedene Dinge tut. Ich habe zB in meinem aktuellen Project ein persistentes control Object, dass jeweils bei einem Raumwechsel ein script zum spawnen der Spieler aufruft. Die Spieler und deren Attribute sind in einem ds_grid(2d Array) gespeichert und dieses grid geht er durch und erstellt die Spielerobjekte. So wird sollte es bei dir auch passieren.
      Wenn man nun am Partybildschirm, Waffen wechselt oder Charaktäre austauscht dann greift man auch immer auf dieses grid zu.

      Leg dir get und set scripts für die Items an. Du forderst dann mit

      GML-Quellcode

      1. strength = get_weapon(0,0);

      den Stärke wert der Waffe mit deiner internen id 0 an was zB Fäuste sein könnten.
      Das scripts sieht dann so aus.

      GML-Quellcode

      1. get_weapon(weaponnumber,atk_def_or_spd)
      2. var atk = 0;
      3. var def = 0;
      4. var spd = 0;
      5. switch(argument0)
      6. {
      7. case 0://bare knuckles
      8. {
      9. atk = 1;
      10. def = 0;
      11. spd = 5;
      12. break;
      13. }
      14. case 1://wooden sword
      15. {
      16. atk = 2;
      17. def = 2;
      18. spd = 3;
      19. break;
      20. }
      21. default:
      22. {
      23. }
      24. }
      25. switch(argument1)
      26. {
      27. case "atk":
      28. {
      29. return atk;
      30. break;
      31. }
      32. case "def":
      33. {
      34. return def;
      35. break;
      36. }
      37. case spd:
      38. {
      39. return spd;
      40. break;
      41. }
      42. default:
      43. {
      44. return 0;
      45. }
      46. }
      Alles anzeigen

      Das sind dann die Datenbanken aus denen du die StandartAttribute herausliest und in den Leserobject speicherst und veränderst. Die brauchst du auch nicht aus dem Speicher leeren oder sowas. Das ist einfach nur Text und nimmt dir keine Ressourcen weg.
      Was dir Leistung frisst sind unnötig viele Objekte und draw calls also alles was du am Bildschirm zeichnen lässt, aber mach einfach mal und dann kriegst du ein gefühl dafür wo das limit ist. Während der Laufzeit muss man nur in den setensten Fällen etwas aus einem anderen Ordner auslesen, zB wenn du es modfähig haben willst und man texturepacks verwenden will.

      Mach nicht 10 verschiedene Kampfräume, sondern einen Raum und in dem spawnen Spieler, gegner und alles was du zufällig generiert haben möchtest.

      Also dein Spielerobject beinhalten alle Variablen die für Bewegung und Kampf nötig sind und werden durch die scripte manipuliert und das in abhängigkeit zum raum in dem du gerade bist.
      In dem Controller Objekt speicherst du quasi deinen Spielstand. Wo bist du auf der map, wieviel Kämpfe wurden gefochten. Sind alle Partymitglieder am Leben, oder gespawned worden?

      Ich hoffe das beantwortet deine Startfragen. Geh´s mal ganz klein an mit 2 partymitgliedern und 3 Wafen oder so und scher dich noch nicht um die Grafiken, so dass du erstmal auf alle Systeme kommst und das Kampfsystem steht, robust und erweiterbar ist.

      out now: KNOSSOS auf itch.io
      ancient-pixel.com <<< ich freue mich über einen Besuch! ^^
    • Hi ihr Beiden,

      erstmal vielen Dank für die äußerst hilfreichen Antworten. Ich habe durch eure Ausführungen jetzt schon eine ganz andere Vorstellung davon, wie ich weitermachen muss. Natürlich werd ich jetzt trotzdem ganz stumpf einige Fragen zu euren Ausführungen stellen, damit ich nichts falsch verstanden habe. Achtung: Es werden wohl auch Fragen dabei sein, die nur noch mal zur Klarifizierung des von euch angesprochenen dienen, damit ich mir sicher sein kann alles richtig eingordnet zu haben.

      Zu Husi:

      Husi012 schrieb:

      Du kannst ein Objekt erstellen, welches für alle Teilnehmer ist.


      Was heißt für alle Teilnehmer? Persistent? Also können alle Objekte auf den Code bzw. Variablen, die in einem persistenten Objekt vorliegen zugreifen? Und umgekehrt geht das nicht?

      Husi012 schrieb:

      und fügst zu Map dann evtl. "object_id" hinzu


      Mit hinzufügen meinst du, dass die object_id schon Teil der in der Map gespeicherten Values ist, oder steht die in deinem Beispiel außerhalb und wird "zusätzlich" in irgendeiner Form mit verwendet?

      Husi012 schrieb:

      wenn > als Teilnehmer Anzahl = 0


      Dafür müsste dann aber die Anzahl aller Kampfteilnehmer (kann ja von Kampf zu Kampf variieren) erstmal ermittelt werden, richtig? Das bedeutet, dass alle kreiierten Kampfteilnehmer-Objekte eine Kennung zugewiesen bekommen haben müssen und er dann nur zählt, wieviele Objekte mit dieser Kennung gerade existieren und das Ergebnis dann als Variable für die Anzahl der Kampfteilnehmer in diese Formel einsetzt.

      Husi012 schrieb:

      dass jedes Obj nachschaut, welches Obj gerade dran ist


      Ist das so sinnvoller, als an einer Stelle alle Variablen der Kampfteilnehmer-Objekte zu vergleichen und damit zu arbeiten?

      Zu Aku_Ryou:

      Aku_Ryou schrieb:

      "magic numbers" also hardgecodete Zahlen


      "Magic Numbers/ Hardgecodete Zahlen sind platte Zahlen, die ich in einer Berechnung verwende anstatt mit einer Variable die Zahl in die Formel einzusetzen und diese so flexibel zu halten, oder?

      Aku_Ryou schrieb:

      Die Spieler und deren Attribute sind in einem ds_grid(2d Array) gespeichert und dieses grid geht er durch und erstellt die Spielerobjekte.


      Gut, dass du das angesprochen hast. Ich hatte nämlich überlegt, wo der Unterschied zwischen einem zweidimensionalen Array und einer ds_map liegt :D

      Aku_Ryou schrieb:

      Wenn man nun am Partybildschirm, Waffen wechselt oder Charaktäre austauscht dann greift man auch immer auf dieses grid zu.


      Das ist aber dann so umsetzbar, dass die Änderungen gespeichert bleiben, wenn das Grid aus dem Speicher fliegt, bis es wieder gebraucht wird, oder? Mag eine dumme Frage sein, aber an genau solchen Dingen haperts momentan noch bei mir.

      Aku_Ryou schrieb:

      Also dein Spielerobject beinhalten alle Variablen die für Bewegung und Kampf nötig sind


      Achso, in Ordnung. In meiner Anfänger-Vorstellung waren diese Informationen immer in Datenbanken in Scripts (Arrays, Grids) geschrieben und nur bei Bedarf das Scirpt dann gerufen und gelesen worden. Kann mir wenn du das schon extra ansprichst vorstellen, dass deine Variante besser und gängiger ist. Bei mir ist das mit dem Variablen erkennen/ einlesen/ nutzen die nicht in dem Objekt stehen, dass damit etwas tun soll leider noch ein Problem. Hatte mal einen Code, der die agility-variable zweier anderer Objekte vergleichen sollte und das hat vorne und hinten nicht geklappt :D Ich weiß auch immernoch nicht, ob ich da falsche Variablentypen gewählt habe, die das fremde Objekt dann einfach nicht erkennen konnte, mien Code einfach falsch war, oder die ganze Ideee so umständlich war, dass es für mich noch garnicht umsetzbar war, weil mir das Grundverständnis fehlt :D

      Aku_Ryou schrieb:

      Ich hoffe das beantwortet deine Startfragen. Geh´s mal ganz klein an mit 2 partymitgliedern und 3 Wafen oder so und scher dich noch nicht um die Grafiken, so dass du erstmal auf alle Systeme kommst und das Kampfsystem steht, robust und erweiterbar ist.


      Du hast mir sehr weitergeholfen und ich wollte das auch ungefähr deinen Ausführungen entsprechend angehen: Platzhalter-Sprites und Hintergründe und erstmal die Systeme und Mechanics, bevor ich mit dem Content anfange :)
      TAOTS: The Art of the Sword (AT) aka The Dream <3

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Riku_no_Sogen ()

    • Du hast alles richtig verstanden, nur das grid oder die map, jenachdem was du schlussendlich wählst, wird nie aus dem Speicher gelöscht. Das ist immer da, damit immer drauf zugegriffen wird. Daher muss es in einem persistenten Object erstellt worden sein.
      zB hast du ein obj_control bei dem das häkchen persistent gesetzt ist und dort wird im create event das grid erstellt. Jedes neue partymitglied trägt sich dann dort ein mit seinen startattributen. Das obj_control befindet sich da es persistent ist quasi in allen Räumen gleichzeitig. Sein Create Event wird aber nur einmal in dem aller ersten Raum ausgeführt wo es von dir von Hand gesetzt wird.

      out now: KNOSSOS auf itch.io
      ancient-pixel.com <<< ich freue mich über einen Besuch! ^^
    • So, nach zweieinhalb arbeitsreichen Wochen komme ich diese Woche wohl endlich mal wieder längere Zeit dazu mich meinem Projekt zu widmen. Ich habe wo ich konnte das bischen Zeit genutzt mich zu den Themen ds_grid und ds_map zu belesen und mich auch bei Anderen durchgefragt. Jetzt gerade gehe ich meine Designs für das Kampfsystem nochmal durch um eine Liste der benötigten Variablen zu erstellen.

      Meinem Verständnis nach stehe ich jetzt vor der Wahl ds_grid oder ds_map wobei der Unterschied laut Hilfe darin besteht, dass die map sowohl Key als auch Value in einer Zelle beinhaltet und nicht nur ein Value. Worin bestehen nun für mich die Vorteile bzw. Nachteile eine Map anstatt eines Grids zu nutzen?

      Zu Aku_Ryou:

      Du hattest geschrieben, dass es sich bei solchen Datenbanken nur um Text handeln würde und ich nur bei Allem was gedrawed wird darauf aufpassen müsste, es nach Verwendung aus dem Speicher zu löschen. Ist die Hilfe da nur sehr vorsichtig, denn da steht zur ds_map, dass man diese Datenbanken auch immer aus dem Speicher löschen sollte.

      Lieben Gruß,

      Ben
      TAOTS: The Art of the Sword (AT) aka The Dream <3
    • Um den Arbeitsspeicher etwas zu entlasten, ist es im Gegensatz zu map viel besser ein grid zu verwenden.
      Du kannst als Key statt string auch einfach einen enum oder Konstanten benutzen
      enum key {
      health,
      lives,
      ...
      }
      Dann statt
      map[? "health"]
      einfach
      grid[# index, key.health]

      Bei einem grid ist es zusätzlich ein großer Vorteil, dass man nicht pro Teilnehmer eine neue map anlegen muss, sondern kann alles zusammenfassen.
      Zum adden solltest du dir eine Funktion machen.
      Ein Bug ist mehr als nur ein Bug, es ist ein... Käfer!
      Egal, wie gut du eine Mauer baust, sie fällt um.... der klügere gibt nach :D

      Willst du mit mir auf Discord Chatten/Quatschen?
      Meine Husi's Tutorial Reihe
    • Also ich sitze grad an einem Grid. Ich lege alle Informationen (Values), die ein Kampfteilnehmer braucht, in dieses Grid (HP, etc.). Eine Zeile des Grids enthält dann immer alle notwendigen Values eines Kampfteilnehmers. Ich überlege noch ob ich ein einziges Grid für alle Verbündeten und Gegnerklassen zusammen mache, oder Verbündete und Gegnerklassen trenne. Oder ich trenne auch die Gegnerklassen nach Gebieten, in denen diese auftauchen können, so kann ich Gegner aus früheren Leveln aus dem Speicher löschen. Ist aber alles Zukunftsmusik. Was ich jetzt brauche um ein funktionsfähiges System daraus zu machen, ist einmal die gerade angesprochene Grunddatenbank (momentan halt als grid) in der alle Values die ich den Kämpferobjekten zuordnen muss enthalten sind. Diese kommt dann ins Create Event meines persistenten Controlobjects, welches die Werte dann den Kämpferobjekten zuweist, nachdem diese für den aktuellen Kampf kreiiert wurden. Wie weise ich diese Werte denn zu? Haben die Kämpferobjekte alle nur initialisierte aber "leere" eigene grids in ihrem create event und dann setze ich die bestimmten koordinaten in deren grids gleich den entsprechenden values aus meinem Datenbank grid?
      TAOTS: The Art of the Sword (AT) aka The Dream <3
    • Die Kämpferobjekte sollten meiner Meinung nach ein Array enthalten, dass die Größe der Anzahl der Werte hat.
      Die ganze Zeile des Grids kopierst du dann in dieses Array.

      Die Kämpferobjekte würde ich auch so gestalten, dass sie aus diesen Werten zB. die Sprites nehmen usw. dann brauchst du auf jeden Fall nur ein Objekt.
      Ein Bug ist mehr als nur ein Bug, es ist ein... Käfer!
      Egal, wie gut du eine Mauer baust, sie fällt um.... der klügere gibt nach :D

      Willst du mit mir auf Discord Chatten/Quatschen?
      Meine Husi's Tutorial Reihe
    • Dui brauchst den Kämpferobjekten kein eigenes array oder grid zuzuweisen. Alle Berechnungen und Veränderungen finden im persistenten Controller object statt. Dass kann dir im Kampf auch gleich die Kämpfer drawen lassen anstatt dafür auch eigene Objecte zu erschaffen.

      GML-Quellcode

      1. grid[# 0,0] = x;
      2. grid[# 0,1] = y;
      3. grid[# 0,2] = sprite;
      4. grid[# 0,3] = subimage
      5. grid[# 0,4] = hp+get_armour(armourID,"def");
      6. grid[# 0,4] = atk+get_weapon(weaponID,"atk");
      7. grid[# 1,0] = x;
      8. grid[# 1,1] = y;
      9. grid[# 1,2] = sprite;
      10. grid[# 1,3] = subimage
      11. grid[# 1,4] = hp+get_armour(armourID,"def");
      12. grid[# 1,4] = atk+get_weapon(weaponID,"atk");
      13. //etc
      14. //draw
      15. for(i = 0 ; i < partymembers ; i += 1)
      16. {
      17. draw_sprite(grid[# i,2],grid[# i,3],grid[# i,0], grid[# i,1]);
      18. }
      Alles anzeigen

      out now: KNOSSOS auf itch.io
      ancient-pixel.com <<< ich freue mich über einen Besuch! ^^
    • Hallo zusammen,

      endlich komme ich mal wieder dazu hier zu schreiben. Auch wenn ich momentan auf sämtliche meiner Daten, Designs und Dokumente zu meinem Game-Design nicht zugreifen kann und durch eine nervige Rücken-OP beeinträchtigt bin. Ich werde wohl in naher Zukunft nochmal ganz von vorne anfangen müssen und mir dabei einen besseren Weg einfallen lassen zu lernen, da ich mit eurer Hilfe so eine klare Vorstellung davon hatte, was ich machen musste, dass ich schlussendlich viel tiefer in die Materie eingedrungen war, als ich mit meinem Wissen noch hätte verarbeiten können :D

      Erstmal werde ich mich wohl darum kümmern mit meinem hier Gelernten die theoretische Basis meines Designs zu erweitern und einen strukturierten und sinnvollen Plan für die Reihenfolge der Entwicklung einzelner Bestandteile meines Projekts zu machen. Auch interessant wäre vielleicht der Zusammenschluss eines kleinen Teams das interessiert wäre an meinem Projekt zu arbeiten. Unter welchen Umständen, müsste sich dann zeigen, vorher werde ich natürlich noch eine Zusammenfassung meines Designs zur Verfügung stellen, wahrscheinlich im allgemeinen Konzepte-Forum. Mal sehen was so kommt und wer sich möglicherweise interessiert zeigt :D

      Lieben Gruß,
      Ben
      TAOTS: The Art of the Sword (AT) aka The Dream <3