Ärgert mich, dass ich bei der Minimap nicht gleich auf das System gekommen bin^^
Ja ich bin auch für den rm2k, weil den hat so gut, wie jeder!
Ein einschaltbares Raster wäre natürlich auch hilfreich (natürlich eines mit 16x16 Feldern!). Die alten C&C Teile sind IMO machbar auf dem rm2k und zum Menü:
Das wären doch so viele Bilder... Da muss einfach ein besserer Picture Patch her!
--
hä wozu brauchst du bei sowas nen raster? ^^
bin auch für 2k
Erleichtert das hinbauen von Häusern, wenn sie aus Pics bestehen!Zitat von Woody 49
(Ja aber das sollte nur optinal sein, da sowas IMO nur in nicht rundenbasierten KS wichtig ist)
--
Auf dem 2k auch.
Falsch.. Starfox ist keinesfalls "pseudo 3D" ^^' da kommen echte Polygone zum Einsatz und das ist mit dem RPG Maker (ob nun 2k oder XP ist da egal) in dieser Form undenkbar.
Ein "ausreichendes" Pathfindingscript sollte auch auf dem 2k möglich sein. Aber eine Lösung nur mit Ruby würde mich auch mal interessieren. Zumindest wie das Prinzip mit Ruby besser als im 2k umgesetzt werden kann. (um wieviel die A* Methode in Ruby schneller ist als beim 2k wär zB. mal interessant)
Pixelmovement ist übrigens nicht nötig für ein Echtzeitstrategiespiel, denn sowohl das erste Warcraft als auch das erste C&C basieren auf einem Raster (wenn man's so nimmt -> Tiles).
--The illusion or impression of never having experienced something
that has actually been experienced many times before
Pathfinding auf dem 2k? Würd ich gern mal sehen! Pathfinding script für den XP kann ich dir liefern wenn du willst! Und das mit Starfox is ja echt krass wenn das richtige Polygone sind O.o ich dachte der SNES kann kein 3D darstellen x.x
A* sowie auch andere pathfinding methoden wurden schon umgesetzt (www.rmxp.net)
Say never no nice guys
3D is Possible i have 'n idea
Well done guys it work so :
A Script check the ID of the Terra around the Hero.
Now we have the IDs of the Area so we get all tills a Pic.
Now we can with the % control the View Forward and Backward.
(ich wollt schon immer mal auch in Englisch rechtschreib fehler machen)
--
Hab den XP nicht installiert... trotzdem thx^^
Bei einem RTS Game würde ich eine einfachere Pathfindingroutine als A* wählen (da die ziemlich viel Leistung schluckt, selbst kommerzielle Produkte vereinfachen da, weil bei zu großer Einheitenanzahl zuviel Performance draufgeht).
Ich würde es eher auf ein grobes Prinzip reduzieren, wo kleinere Objekte (Einheiten und Gebäude) umgangen werden können, aber nicht größere Geländeformationen.
Was das mit dem SNES angeht: Starfox besitzt ja den FX-Chip, der die schnelle Verarbeitung einfacher, texturierter Polygone ermöglicht. Einfache 3D Grafik (Vektorgrafik... also Drahtgittermodelle hne Texturen) sind aber auch ohne möglich.
Es gab ja auch schon ein Spiel komplett in 3D auf dem NES^^
-> Elite
--The illusion or impression of never having experienced something
that has actually been experienced many times before
Nunja aber wie willste pathfinding aufm 2k umsetzen?
Würde da gerne mal ne demo sehen...
Gibt ein paar Scripte dazu. Hier sind ein paar Sachen dabei, einfache Systeme, wo kleine Hindernisse umgangen werden:
http://forum.rpg2000.4players.de/viewtopic.php?t=46397
(das von Gekiganger war afaik ganz gut)
A* wurde auch schon umgesetzt, allerdings ist der Link von Lachsen down und ich hab das Script leider auch nicht mehr.
Hier der Thread (hab da die "A*Anleitung" geposted).
http://forum.rpg2000.4players.de/vie...nding&start=30
--The illusion or impression of never having experienced something
that has actually been experienced many times before
der DL link in dem thread den du verlinkt hast is tot....
Regelt den Pathfinding Scheiss unter euch, bitte.
Es wurde schon gesagt, was das Thema ist also hoert auf darueber zu raetseln, was denn nu besprochen werden soll, danke.
--"Unverständlichkeit ist kein Zeichen für tiefgehende Gedanken"
ai junge pathfinding is wichtig für nen echzeit strategiegame!
Wegfindesysteme an sich sind nicht besonders schwer, man kann an schlüsselstellen Waypoints setzen und um
diese herum zugehörige Wayareas definieren und für den Weg zu diesen einen mehr oder weniger
ausgereiften rekursiven Wegfindealgorithmus schreiben. Das Problem dabei ist, wie bei allen anderen Situationen
auch, dass man Events nicht als Objekte ansehen kann und ihnen so keine Variablen auf ihre Referenz zuweisen kann,
sondern sich aus dem globalen Variablenpool bedienen muss. Auch kann man keine eventspezifischen Methoden
deklarieren, sondern nur globale, die sich aus dem selben Variablenpool bedienen und bei mehrfacher, gleichzeitiger
Ausführung, auf den selben Variablen schreiben.
Das macht es natürlich sehr schwer, da wirklich jedes Event seine eigenen Variablen und Methoden benötigt
und man den Code so ständig kopieren und anpassen muss.
Hinzu kommt die unperformante Ausführungsgeschwindigkeit des Maker-Scriptcodes, welcher viele gleichzeitige
oder komplexe Prozeduren nahezu unmöglich macht.
Bei einem Echtzeitstrategiespiel muss jede Einheit auf jede reagieren, da obige Features der Objektorientierung
im Maker fehlen, müsste man unglaublich komplexen Code schreiben, für jede einzelne Einheit, der ausserdem
äußerst Ressourcenhungrig ist. Man müsste sich bei der Anzahl der Einheiten stark beschränken, ich wage es
zu bezweifeln, dass auch nur mehr als 10 Einheiten bei einer mittelmäßigen KI überhaupt laufen würde, eher
noch weniger.
Thema Fog of War:
Das Verdecken der Spielkarte ist nur eine Möglichkeit, dem Spieler das frühzeitige Auskundschaften der Map
ohne Späheinheiten zu erschweren. Im Maker wäre das nur dadurch zu reallisieren, auf jedes Feld ein Event zu
legen, welches den Untergrund verdeckt. Eine sehr ressourcenlastige Angelegenheit.
Besser wäre es, die Bewegung der Maus auf dem Feld durch Koordinatenabfragen einzuschränken. So könnte
der Spieler auch keine Areale erreichen, die noch nicht erspäht wurden. Kundschafter könnte man über eine
Minikarte in unbekanntes Terrain lotsen.
Pixelmovement ist möglich, auch mit völlig freiem laufen, indem man für alle Pictureobjekte eine Positionskorrektur
laufen lässt, sobald sich der Screen mitbewegt. Das ist keine große Sache. Auch Kollisionsabfragen sind dank Terrain ID
und deren Umrechnung auf Pixelkoordinaten einfach und ressourcenschonend zu lösen.
Die Schwierigkeit liegt darin, dass man Pictures nicht variabel, sondern nur statisch anzeigen lassen kann.
Das wird dann zum Problem, wenn sich zwei Objekte (beide durch Pictures dargestellt) drohen, zu überschneiden.
Welches wird über bzw. unter dem anderen dargestellt? Je nach Position lässt sich da keine feste Regel aufstellen
und die Pictures müssten zur laufzeit ihre Z-Position ändern. Man müsste für jedes Objekt die Pictureanzeigen
für alle 50 möglichen Z-Positionen in reserve halten, um dies dynamisch gestalten zu können.
Ein ungeheurer Skriptaufwand für eine eher triviale Sache, der bloßen Darstellung.
Pseudo 3d gibt es bereits in Maker spielen, z.B. Scrolling des Untergrunds in die Tiefe. Richtungswechsel sind dabei
allerdings nicht möglich, lediglich änderungen am Scrollspeed.
Auch kann man Parallax-Scrolling als eine Form von pseudo-3d ansehen.
In dem Spiel Deathcat hingegen ist der Hintergrund z.B. in statischem 3d gehalten. Man kann sich aber dreidimensional
über die Map bewegen und die Spielfigur ändert dabei, abhängig von der Entfernung zur Kamera, ihre Größe.
Was Schach eingeht, so ist die KI wirklich die einzige Schierigkeit, die sich bei einer Reallisierung stellt und das
sprachenunabhängig. Allerdings hat es diese Schwierigkeit so richtig in sich.
Über die Umsetzung zur Bewegung der Figuren oder der Einhaltung der Regeln braucht hier nicht diskutiert zu
werden, das sind triviale Angelegenheiten, die sich durch ein bis zwei Tage Skriptaufwand leicht reallisieren
lassen.
Eine KI hingegen müsste erst einmal alle möglichen Züge der eigenen noch auf dem Feld stehenden Figuren
ermitteln und zwischenspeichern. Dazu müsste man eine Art virtuellen Stack deffinieren, in dem diese gespeichert
werden. Nun muss ausgewertet werden, welcher dieser Züge den größtmöglichen Vorteil bieten würde, dabei
werden Züge, die eine gegnerische Figur vernichten, natürlich höher gewertet . Bei Zügen, die sich ins
Nichts verlaufen, müsste man natürlich wieder eigene Regeln deffiniert werden, welche denn nun bevorzugt werden,
z.B. Züge, die die Spielfiguren denen des Gegners näher bringen.
Jedenfalls ist das alles schon ein gehöriger Aufwand und dabei sind noch nicht einmal die Reaktionen des Gegners
berücksichtigt, geschweige denn Strategien über mehrere Runden.
Ab hier wird der Aufwand auf dem Maker sehr hoch. Den Stack, den man dazu definieren müsste, wäre riesig.
Man könnten dies aber beschränken, in dem man nur die gegnerischen Züge speichert, die eine eigene Figur
vernichten könnten.
An dieser Stelle mache ich mal Schluss, da es von nun an nur noch um das Referenzieren einer exponentiell
steigenden Anzahl von Spielzügen und deren Auswertungen geht.
Umständig vor allem! Nur als Beispiel: Ich habe ein SKS gebaut für bis zu sechs Gegner und jeder von den Gegnern hat Widerstände und Schwächen. Das ganze ergab an die 80 Variablen um das ganze zu definieren.
Ich sehe das als unmöglichkeit im Maker! Seht euch doch mal Warcraft zwei an! Wie möchte man sowas realisieren?
Wäre aber nicht so toll, da man dann immer nur einheiten an den "Rand" des momentanen Blickfeld schicken müsste!
Verstehe ich nicht ganz! Redet ihr von Einheiten oder Gebäuden? Bei Gebäuden sehe ich nämlich nicht wirklich ein Problem!
Mhmm mir kam jetzt eine bessere Idee für einen "Echtzeit-Hack&Slay-Mix":
Man hat am Anfang so an die 5 Helden (a la Warcraft 3 in der Stärkerichtung) und der Gegner kontrolliert ein Gebiet und mehrere Einheiten. Das ganze soll dann einen Mix aus Hack&Slay und Echtzeitstrategie ergeben. So müsste man sich nur im "größten" Teil auf die Gegner KI beschränken.
Pathfindig kurz angeschnitten:
Im Mousepatch gab es doch mal ein paar Scripte für die Möglichkeiten, da war doch sowas dabei!
--
Also ich hätte da noch ein Idee, die mähsig funktionieren würde, dafür aber ohne eine MIllionen Events und verhältnissmähsig ressurcensparent.
Man müsse sich vorstellen, das wir am oberen Ende unsere Basis haben und der Gegner seine unten.
Wir teilen uns nun die Map geistig in 6 Teile. Von Oben nach unten.
Man könnte dann die Ganze map mit 5 schwarzen Pictures besetzen.
Eins für jedes Teil (da wo du startest is keins). Wenn dann eine Einheit einen bestimmten Y-Wert überschritten hat. Würe das ganze Picture für diesen Teil aufgedeckt werden.
Meiner Meinung wäre das der Best Fog of War. Das was ich beschrieben habe war noch sehr einfach.
Man könnte die Map zusätzlich noch vertikal unterteilen.
Also hätte man dann z.B. für jeden X-Wert 3 Pictures und für jeden Y-Wert 5.
Ich hoffe ich habe mich net zu umständlich ausgedrückt.
Geändert von Macros (17.10.2005 um 11:12 Uhr)
Jaah das ist ne sehr gute idee
Aber wie macht man das mit der KI ? Hat die keinen fog oder was?
Ich finde die Idee ziemlich schlecht, da das viel zu ungenau wäre imo. Man könnte da mit einer Einheit einen vielfach größeren Beriech aufdecken (indem man nur einen Bruchteil des Bereiches betritt).
Dann doch lieber mit Events für FOW arbeiten.
--The illusion or impression of never having experienced something
that has actually been experienced many times before
Was is schlecht dran das man mit einer einheit nen grösseren Bereich aufdecken kann? Mann muss die Einheit dann ja auch dort lassen sonst sieht man wieder nix! So gibt es einen Kampf wer mehr sichtradius hat und mann kann rasch nur 1 einheit schicken um ein gebiet zu überwachen!
Ja für die KI hätt ich noch die Idee, das wenn die KI sieht das du zbs. luft einheiten baust, dann baut sie etwas gegen luft! Oder gegen Panzer baut sie Bazooka Soldaten!
Hey die Idee ist klasse! Die gefällt mir!
Dann könnte man vielleicht noch zusätzlich machen, wenn keine deiner Einheiten in dem Gebiet ist, dann würde der Nebel, wieder kommen, aber sowas braucht nur unnötig viele Koordinatenabfragen, aber wenn man die sowieso immer abfragen muss könnte man das vielleicht verbinden.
--
Hmmmm...
Hast recht, soweit hatte ich noch net gedacht. Mann könnte auch anstatt das Picture zu Löschen es 100% Tranzparent machen und wenn keine Einheit da is, wird es dann langsam wieder schwartz.
Geändert von Macros (17.10.2005 um 17:19 Uhr)
Berechtigungen
Zitieren
