Theorie ist alles!?

[Eni-Meister]

Ganz einfach...
Die Gegner werden mehreren Ideallinien folgen und je nachdem ob der Fahrer noch Platz hat um die Linie zu halten, so wird er auch auf ihr bleiben/fahren, ansonsten wechselt er die Linie. So könnte man riskante Überholmanöver simulieren...

[RA]

Ich schätze mal die Bafrage ob der Weg blockiert ist ist sehr schwer.Auf meine weise müsste man da für jeden Fahrer und für jedes Feld ne Koordinate anlegen und dann eine ellenlange Abfrage machen oO

[Eni-Meister]

Wenn du wüsstest wie lang eine Abfrage sein kann ohne das es ruckelt...

[Veyrne]

Nicht mal, wenn die in einem logischen Abstand verändert werden, bleibt der Abstand und die abzufragenden Werte ja gleich. Das heißt, man richtet ein das sich die Werte selbst miteinander vergleichen weil es mitrechnet.

[Eni-Meister]

Und durch eine Schleife könnte man alles noch verkürzen...
Man macht einfach nur den Code für einen Wagen und setzt beim erneuten Durchlauf einfach ne neue Varibale ein.
Ich denke der Maker sollte das schnell genug verarbeiten können, wenn es maximal 4 oder 6 Gegner sind.

[tribal of silence]

tut mir leid,aba das versteh ich nich(und ich seh das nich als ganz einfach an).WIE MEINT IHR DAS????????????

ERROR!The message from Eni-Meister(Monday,December 6th 2004,8:43pm)wasn't understand.Please tell it the task "tribal of silence" again.

[Veyrne]

Das heißt das die Werte für die Kollisionsabfrage natürlich anhand der Geschwindikeit des Fahrzeugs immer in einem gleichem Abstand an allen Werten addiert werden müssen. So besteht die Möglichkeit zu prüfen ob die Werte des eigenen Fahrzeugs und die des anderen Fahrzeugs in einem Wert "same" sind. Und Werte der Fahrzeuge kann man bei Unsichtbarkeit doppelt belegen.

[Eni-Meister]

Es heißt einfach nur...

Eine Fahrzeug bekommt seine Koordinaten etc.
Sobald der Gegner alle Werte bekommen hat, wird der komplette Prozes nocheinmal durchlaufen, jedoch diesesmal mit einer Varibale, die für einen zweiten Gegner steht. Das geht aber nur, wenn komplette neue Varibalen angelegt/benutzt werden.
Das erreicht man indem man eine Funktion benutzt. Ich habe nur leide rihren Namen vergessen, aber ich weis wie sich noch funktioniert:

Der Wert der Varibale stellt die Variablennummer da, so kann man beliebig die Varibalennummer wechseln.
Solltest du das nicht verstehen, dann sry!
Besser kann ich es zur zeit nicht erklären. Lies einfach mal den RM2k-Kurs 6, der auf rpg2000.de zu finden ist.

[Veyrne]

Das Thema scheint ja so ziemlich gegessen zu sein.

Dieses Thema ist nicht schwer, sondern ein Aufwand der eigentlichen Arbeit.

Themen per PM an mich oder Eni. Erstmal dicht.

[Eni-Meister]

Endlich geht's weiter!

Zitat von ERSTFASSUNG

Neues Thema: Wie erstelle ich ein Kampfsystem wie in Final Fantasy Tactics Advance?

Zitat von ERSTFASSUNG

Da wahrscheinlich nur wenige dieses Spiel kennen, hier erstmal die Grundlegenden Eigenschaften des KS:

1. GrafikDas Kampfystem beruht auf einer isometrischen Darstellung:
   
   

Zitat von ERSTFASSUNG

1. 
   
   Die Höhenunterschiede beeinträchtigen die Beweglichkeit des aktiven Charakters. Steht ein Bogenschütze höher als sein Ziel, verursacht er höheren Schaden bei besserer Trefferchance. Steht der Angreifer hinter seinem Ziel, ist seine Trefferchance höher, als wenn er neben diesem oder im schlimmsten Falle vor diesem steht.
2. Ablauf eines GefechtsDie beiden Gegner wählen zu Beginn des Gefechtes jeweils 6 ihrer Charaktere aus und plazieren sie beliebig auf ein 2x8 Felder grosses Startgebiet. Der Gegner fährt fort, indem er ebenfalls am anderen Ende des Spielfelds seine Einheiten plaziert. Nun beginnt die Einheit mit dem höchsten Initiative-Wert ihren Zug. Der kontrollierende Spieler kann zwischen den Optionen "Bewegen", "Angreifen" und "Warten" wählen.
   
   Bewegen: Der Charakter kann sich nun so viele Felder fortbewegen, wie sein "Bewegungswert" es ihm erlaubt. Höhenunterschiede nach oben werden dabei jeweils von der Bewegung abgerechnet, Höhenunterschiede nach unten werden nicht beachtet. Des Weiteren kann ein Chara keine grösseren Klippen hinauf- oder hinabspringen, als sein "Springen-Wert" es ihm gestattet. Nach der Bewegung kann der Charakter noch zwischen "Angreifen" und "Warten" wählen.
   
   Angreifen: Der Charakter kann nun zwischen "Attacke" und "Fähigkeit" wählen.
   
   Entscheidet er sich für "Attacke", so muss er einen Gegner innerhalb der Reichweite seiner aktuellen Waffe bestimmen und ihn angreifen.
   
   Der Schaden wird durch die Addition des Grundangriffswertes des Charakters mit dem Wert seiner Waffe(n) berechnet. Zusätzlich spielt der Zufall noch eine kleine Rolle. Danach wird der addierte Abwehrwert des Ziels davon subtrahiert. Der positive Wert wird den gegnerischen KP abgezogen.
   
   Falls er "Fähigkeit" wählt: Hier kann der Charakter eine seiner erlernten Fähigkeiten des aktuellen Berufes oder eine Fähigkeit seines Zusatzberufes wählen. Mehr dazu weiter unten. Die Fähigkeit wird dem Script nach ausgeführt und mit den KP wird gleich verfahren wie im Punkt "Angreifen". Eine Demonstration einer Fähigkeit:
   
   
   
   Nach dem Angriff bestimmt der Chara noch seine Blickrichtung und sein Zug endet. Erst nachdem alle anderen am Gefecht beteiligten Charaktere einmal am Zug waren, kommt er wieder an die Reihe.
   
   Warten: Der Charakter bestimmt seine Blickrichtung und der Zug endet. Er kommt im Ablauf des Gefechtes jedoch früher wieder an den Zug als diejenigen, die noch eine Aktion ausgeführt haben.
3. Berufe und FähigkeitenJeder Charakter kann gewisse Berufe erlernen. Je nach Beruf ändern seine Werte und er kann andere Waffen tragen und Fertigkeiten einsetzen. Da dies jedoch nur begrenzt zum KS gehört, lassen wir es besser beiseite. Wie ein Charakter seine Fertigkeiten erhält, kann auch variieren.
   
   Nun aber zu den Fähigkeiten: Jede Fähigkeit ist einzigartig. Sie können schaden, heilen, den Status verändern, töten, stehlen und vieles mehr. Ich denke, das scripten der Fähigkeiten dürfte nicht das Problem sein. Wichtig ist jedoch, daß jede Fähigkeit eine gewisse Anzahl MP eines Charakters verbraucht und eine gewisse Reichweite besitzt. Viele Fähigkeiten besitzen auch ein Zielgebiet von beispielsweise einem Inneren Kreuz eines 3x3 Felder großen Bereiches. Das Zielgebiet kann natürlich nach belieben variieren.
4. LeveldesignDie Levels sollten, um dem KS gerecht zu werden, isometrisch aufgebaut werden. Allen, die sich keine Vortellung davon machen können, sei empfohlen, eines der obenstehenden Bilder anzuschauen.
   
   Im Grunde müssen nur bereits vorhandene Chipsets editiert werden, um diesen Effekt zu erzielen, indem jede Pixelreihe ein wenig verschoben wird. Des weiteren muss der Maker die genauen positionen der Charaktere festlegen können, da nicht jeder Chip gemittet sein kann, und das Programm muss die Höhenunterschiede erkennen.
5. Waffen
   
   Jede Waffe besitz neben den Standart-RPG-Werten wie Angriff auch eine gewisse Reichweite. Der ausgerüstete Charakter kann während seines zuges in jede Blickrichtung in Weite der Waffenreichweite angreifen, die endgültige Blickrichtung wird erst am Ende seines Zuges festgelegt.
6. Das Leben nach dem Tode...

Verliert ein Charakter während des kampfes all seine KP, s wird er ausser gefecht gesetzt. Er bleibt jedoch weiterhin auf dem Boden liegen und kann durch Heilzauber wiedererweckt werden. Seine KP werden jedoch durch nichts mehr beeinflusst, er kann nicht das ziel von Angriffen sein und kann auch keine Aktion mehr ausführen, d.h. sein Zug wird übersprungen.

Das wären erstmal die wichtigsten Angaben gewesen... Falls jemandem etwas unklar sein sollte, kann er (falls das so geht @Eni) ne PM an mich schicken und ich wird noch was reineditieren. Ich denke jedoch, es sollte soweit alles klar sein.

-Robby Rocket-

[.banshee]

Das erste Problem, dass sich stellt ist die Isometrische Darstellung.
Wie man die darstellen soll ist mir ein Rätsel, klar man rippt zuerst die Grafiken einer Map und stellt alle Teile der Map, die einen Charakter verdecken können per Event dar. Also wenn ein Charakter hinter, sagen wir einem Haus, steht wird das Event auf "Over Hero" gesetzt, steht der Held auf dem Haus stellt man es auf "Below Hero". Jetzt tut sich folgendes Problem auf:
Was passiert wenn beide Fälle gleichzeitig eintreten?
Entweder der Held der eigentlich hinter dem Haus stehen sollte wird nicht verdeckt oder der der darauf steht wird verdeckt.
Soviel zum ersten.

Wenn wir davon ausgehen ,dass ein "Feld" genauso groß ist, wie ein Feld im Maker und wir einfach übersehen ,dass die Felder in FFT größer sind sollten die Befehle Angreifen(außer mit Bogen, sowie Gewehr) und Item, sowie Warten kein Problem darstellen, da hierbei keine Reichweiten zurückgelegt werden müssen.
Ich habe selbst versucht diese Reichweiten darzustellen, sehe mich da aber vor einem unüberwindbarem Problem

[Robby Rocket]

Es ginge mit der Reichweite höchstens gut, wenn man die position des Chars speichert und für jedes Feld in Reichweite folgendes macht:

1.Bestimmen lassen welche X- und Y-Koordinate jeweils grösser ist: Die des Chars oder die des Auswahlcursors
2. Die grösseren X- und Y minus die kleineren X- und Y-koords
3.Fork: Wenn das Ergebnis gleich oder kleiner als die Reichweite der Waffe ist den Angriff erlauben. Sonst halt nicht.
Auf diese Weise könnte man solch einen Angriffsbereich erzeugen:

xxxxx
xxxxx
xxxxx
xxxxx
xxxxx

Ich denke aber, erwünscht wäre solch einer:

ooxoo
oxxxo
xxxxx
oxxxo
ooxoo

... Sonst müsste man auf oben genannte Variante halt für jede Koordinate, auf der ein Angriff relativ zu denen des heros möglich wär, zuerst deren Position bestimmen und dann ausrechnen, ob es in der Reichweite liegt.
-Robby Rocket-

EDIT: Achja, sorry für die schlechte Gleiderung in Enis Zitat, ich habs auf Word vorgefertigt und im Kami-Editor nicht mehr aufs Design überprüft...

EDIT2: Wegen den Gebäuden: Man müsste irgendwie mit der Database und Eventeditor zusammen arbeiten, um sowas hinzukriegen, falls es überhaupt möglich sein sollt. Mit StartSlipTrough und... ach, vergessen wirs. Ich denke nicht, dass sowas geht. Könnte man mal procieren, ein Brückenscript so umzueditieren...

[Eni-Meister]

Aufgrund von Desinteresse wird das alte Thema beendet.

Die neue Frage:
Wie realisiere ich ein Pokemon-Lagersystem?
Vom Fangen über Lagern bis hin zum Aufnehmen in die Party.

Man überlege sich, dass man mindestens 386 Pokemon fangen muss, damit man wenigstens von jedem Pokemon eins besitzt. Hinzukommt, dass Pokemon freigelassen werden können. Als Grundüberlegung würde ich 30-40 Variablen für nur ein Pokemon verwenden. Das würde einen Variablenverbrauch von 11580-15440 ergeben. Wäre soetwas überhaupt realisierbar? Für mich wäre es somit das erste Makergame, dass soviele Variablen verbraucht.
Kriegsseele wollte ein eigenes Art "Pokemon-Game" erschaffen, jedoch scheiterte er an diesem Problem. Der Grund war nicht unbedingt die Technik, eher der Aufwand. Aber lasst euch nicht davor zurückschrecken, es gibt immer mehr Lösungswege, oder?
Mal sehen ob sich genügend daran beteiligen, denn wenn das Problem gelöst wird, könnte es eine Flut von Pokemon-Games verursachen *lach*

[Ryo Saeba]

Problem scheint also der Variablenverbrauch zu sein, da die Pokemon ja anscheinend je ca. 30-40 Statuswerte haben (kenne mich da nicht mehr so gut aus^^')? Klar sollte sein, dass wir den Ressource Hacker nutzen sollten, somit hätten wir schonmal nicht mehr solche Riesenprobleme was die Maximalanzahl der Variablen angeht (500000 sind performancetechnisch grade noch vertretbar).

Hinzu kommt wohl auch, dass beim Original Pokemon ja kaum ein Pokemon derselben Art einem anderen Artgenossen glich o.O es gab immer (wenn auch nur sehr kleine) Unterschiede. Hier müsste man also in einem gewissen Bereich mit einer Zufallsvariable arbeiten um die dann die Ausgangs- oder Grundwerte eines "wilden Pokemons" geändert werden, damit es "einzigartig" wird (durch Zufall kann es natürlich sein, dass man zwei völlig gleiche Pokemon fängt, aber eher unwahrscheinlich).

Aufwendig ist allerdings erstmal die "Grundstatuswerte" zu definieren, bzw. in den Maker einzugeben. Bei 386 Pokemon und je 30-40 Werten, die dann ja auch noch unterschiedlich stark ansteigen, wird das eine ziemlich unzumutbare Arbeit.
Allerdings sehe ich da wirklich keine andere Möglichkeit, als diese per Hand, für jedes einzelne Pokemon einzugeben. Allerdings kann man nun mit den Werten für "Level 1" beginnen. Somit sind die Zahlen noch nicht besonders hoch. Unschön allerdings, dass man jetzt nochmal 30-40 Variablen braucht, in denen man die Anstiegswerte festlegt -> also um wieviel % die jeweiligen Statuswerte bei Levelanstieg steigen. Da müsste man sich dann schon eine ordentliche Formel ausdenken. (Die vom Originalgame kennt ja bestimmt keiner oda?)
Vielleicht könnte man hier auch gleich die Anfangswerte mit dem prozentualen Anstieg koppeln -> soll heißen, dass man aus den Anfangswerten den prozentualen Anstieg mit einer festen Formel errechnet. Somit bräuchte man wieder "nur" noch die Anfangswerte und könnte die Anstiegswerte immer ableiten.

Nun gut.. nun aber zum Einfangen von den Viechern. Man sollte die maximale Anzahl fangbarer Pokemon natürlich beschränken. Geht auch kaum anders, wenn man an die Variablenbegrenzung denkt. Die "wilden" Pokemon werden am besten beim Betreten der Map "generiert" und zwar von jedem zu fangenden Typ ein Exemplar. Zuerst werden die Statuswerte von Level 1 des Pokemons auf das aktuell benötigte Level hochgerechnet und dann noch die Zufallswerte dazu, damit es "einzigartig" ist. Diese temporären Daten (bei jedem betreten der Map werden die ja überschrieben) speichern also die Werte der sich auf der Map fangbaren Pokemon. Wenn man das Pokemon nun gefangen hat, wird dieses mitsamt seinen Statuswerten in das Pokemonsammelsorium des Helden übertragen. Ich denke man sollte die Maximalanzahl fangbahrer Pokemons auf ca. 1000 begrenzen (ca. 300000 -400000 Variablen). Anschließend wird wieder ein neues Pokemon, des eben gefangenen Typs generiert, dank des Zufallsfaktors unterscheidet es sich mit hoher Wahrscheinlichkeit auch vom eben Gefangenen.

Uff... soweit bin ich nun erstmal^^
Problem ist also einmal der immense Arbeitsaufwand, die Daten (Statuswerte) der Pokemonarten anfangs festzulegen und die hohe Variablenanzahl.

Zur Variablenanzahl fällt mir da glatt noch etwas ein. Wenn die Statuswerte jeweils nur bis 999 gehen, dann könnte man in einer Variable durchaus 2 Statuswerte unterbringen.
-> Bsp: aus 568392 wird (wenn wir erst durch 100000, dann durch 10000, 1000, ...usw. teilen und die Zahlen wieder zusammensetzen)
-> 568 und 392

Damit könnte man die Variablenanzahl halbieren.

[Eni-Meister]

Wenn man von 30-40 Variablen aussgeht und man 1000 fangen kann, dann ergibt das doch 30.000 - 40.000. Limit des Makers liegt bei 99.999 Variablen.

Die Überlegung mit dem "Kreieren" des Pokemons ist schonmal eine Möglichkeit, meiner Meinung nach. Aber warum Varibalen zusammenfügen?
Das würde doch nur unnötig mehr Arbeit bedeuten, oder?