Seite 3 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 41 bis 60 von 98

Thema: Technik - Was ist machbar?

  1. #41
    Zitat Zitat von Woody 49
    hä wozu brauchst du bei sowas nen raster? ^^

    bin auch für 2k
    Erleichtert das hinbauen von Häusern, wenn sie aus Pics bestehen!
    (Ja aber das sollte nur optinal sein, da sowas IMO nur in nicht rundenbasierten KS wichtig ist)

  2. #42
    Anständiges Pixelmovment sowie pathfinding funktioniert auf dem XP, auch das standart KS aufzupeppen ist auf dem XP kein problem da man quasi alles im standart KS via ruby ändern kann.

    Fake 3D wäre vielzuviel aufwand würde aber auch gehen (siehe starfox auf dem SNES, das is auch sone art pseudo 3d)

    Echzeitstrategie würde vlt. auch gehen aber man könnte sicher keine aufwendigen sachen machen weil 1. man nen sauguten PC bräcuhte um überhaupt zu spielen und 2. der aufwand riesig wäre. Aber mit Pathfinding und Pixelmovment das auf dem XP problemlos funzt (es gibt schon scripts) wäre sicher ein kleines Echzeitstrategie game möglich (so max 20 einheiten)

    Als Thema stimme ich für Echzeitstrategie!

    Achja bin für den XP, is logisch. Is auch der bessere Maker für sowas, man stelle sich Pathfinding (das man für ne gute Computer KI braucht) oder KI auf nem 2k(3) vor... is ja der horror!

    Geändert von Nevius (16.10.2005 um 18:21 Uhr)

  3. #43
    Zitat Zitat
    Anständiges Pixelmovment sowie pathfinding funktioniert auf dem XP
    Auf dem 2k auch.


    Zitat Zitat
    Fake 3D wäre vielzuviel aufwand würde aber auch gehen (siehe starfox auf dem SNES, das is auch sone art pseudo 3d)
    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.

    Zitat Zitat
    man stelle sich Pathfinding (das man für ne gute Computer KI braucht) oder KI auf nem 2k(3) vor... is ja der horror!
    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).

  4. #44
    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)

  5. #45
    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.

    well done guys have fun and Raise your Voice

    (ich wollt schon immer mal auch in Englisch rechtschreib fehler machen )

  6. #46
    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

  7. #47
    Nunja aber wie willste pathfinding aufm 2k umsetzen?
    Würde da gerne mal ne demo sehen...

  8. #48
    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

  9. #49
    der DL link in dem thread den du verlinkt hast is tot....

  10. #50
    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.

  11. #51
    ai junge pathfinding is wichtig für nen echzeit strategiegame!

  12. #52
    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.

  13. #53
    Zitat Zitat
    Das macht es natürlich sehr schwer, da wirklich jedes Event seine eigenen Variablen und Methoden benötigt
    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.

    Zitat Zitat
    Thema Fog of War:
    Ich sehe das als unmöglichkeit im Maker! Seht euch doch mal Warcraft zwei an! Wie möchte man sowas realisieren?

    Zitat Zitat
    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.
    Wäre aber nicht so toll, da man dann immer nur einheiten an den "Rand" des momentanen Blickfeld schicken müsste!

    Zitat Zitat
    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.
    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!

  14. #54
    Zitat Zitat
    Thema Fog of War:
    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)

  15. #55
    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.

  16. #56
    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)

  17. #57

    Enolagay Gast
    Also Strategie-spiele ist wohl am besten!

  18. #58
    Zitat Zitat von Macros
    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.

    Jaah das ist ne sehr gute idee , gefällt mir! Finde es auch besser wenn das picture wieder kommt (also nebel wider da) wenn keine Einheit mehr da ist, das würde noch n strategischen faktor dazugeben weil man im mer ne einheit im Gebiet haben sollte damit man da etwa sieht, und die einehiten vom Gegner vernichten damit er in dem Sektor nix sieht
    Aber wie macht man das mit der KI ? Hat die keinen fog oder was?

  19. #59
    Zitat Zitat
    Hat die keinen fog oder was
    Tja...das ist neben Pathfinding und Fog of war, nun das nächste Problem, waran wir uns wagen müssen.

    Was macht die KI?

    Erlichgesagt... ich hab keine Ahnung.
    Bei einen strategiespiel sollte die KI schon etwas klüger sein als bei den AKS die ich bis dato gebaut hatte (der gegner läuft auf dich zu bis du tot bist).

    Um auf deine Frage zurück zu kommen. Der Gegner hat wohl keinen Fog.
    Das einzige was mir einfällt, wie man versichen könnte den Gegner klug erscheinen zu lassen wäre folgendes:

    Man gibt den Gegner verschiedene Vorgaben was er wann tuhen soll.
    Als Beispiel:

    1. Am anfang kreaturen bauen.
    2. Wenn genug da sind angreifen.

    Wenn dieser Angriff fehl schlieg:
    3. Nach kampf merkt der Ki sich wieviele Einheiten (von dir) übriggeblieben sind.
    4. genauso wie 1. und 2. nur stellt er sich daruf ein was und wie fiehle Einheiten du hast. Schlägt das dann wieder fehl gehts wieder los.

    Zusätzliches:
    5. Der Gegner erobert minen.
    6. Ist die Mine schon von dir Besetzt erobert er sie.
    7. Wenn du ihn angreifst und er erleidet großen schaden fällt 1. und 2. aus und er baut Verteidigung.

    8. Je nach schwierigkeits Grad, auch mal die Reihenfolge vertauschen, oder Pausen machen. Damit er nicht unbesigbar wird.

    9. und noch Spielspeziefische Sachen.( ein Upgrade machen oder so)

    Geändert von Macros (17.10.2005 um 18:15 Uhr)

  20. #60
    Zitat Zitat von Macros
    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.

    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.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •