Archiv verlassen und diese Seite im Standarddesign anzeigen : Technik - Was ist machbar?
Hi,
kurz zur Erklaerung:
Ich glaub es gab mal im Quartier so nen Thread. Es geht darum, dass erst abgestimmt wird, ueber welches Thema man diskutiert und dann darueber spricht.
Also man diskutiert darueber, wie man etwas bestimmtes mit der Maker-Technik umstezen koennte.
In dem Quartier Thread ging es zum Beispiel um Pathfinding.
Jo dann fang ich mal an. Hoffe das geht mit den Mods klar...
Vorgeschlagene Themen waeren:
Fake 3D im Maker
Echtzeit Strategie im Maker
Anstaendiges Pixelmovement mit dem Maker
Grafisches/Spielerisches Aufpushen des Standard KS
Schach auf dem Maker
Also dann waehlt schon.
(Hoffe das war verstaendlich genug ^^)
Das letzte, das is noch realistisch (Fake 3D sieht kacke aus, Echtzeit scheitert an den fehlenden Klassen, ich stell jedenfalls net für jede mögliche Figur ein neues Event hin, und Pixelmovement... ohne Klassen funzt auf Kollisionsfrage net so gescheit, man bräuchte gigantische Datenspeicher und mit gigantisch meine ich gigantisch)
Ja, wie Dhan schon gesagt hat, ist eigenlich alles machbar, nur das es oft ein riesen Haufen an Aufwand ist, und es sich dann auch einfach nicht lohnen wird. Das Standart KS aufzupeppen ist eigenlich kein alzu großes Problem, und oft sieht es auch relativ gut aus...
Naja...
Man kann mit dem Maker ja eigentlich (wie man schon oft gesehen hat) alles machen, ob man es kann ist die andere Frage...
LG Henry
Naja mal schaun ob das was wird...
Ich bin für "Echtzeitstrategie", weil mir schon einiges dazu eingefallen ist was klappen könnte, wenn man Häuser und Einheiten limitiert!
Ich schließ mich Bauzi an.
Echtzeit Strategie ist ehrlich gesagt in keinem Makergame so richtig gut umgesetzt worden, VD² hat den Anfang mit den BES gemacht.
Also ebenfalls für RTS. ;D
Garo
bluedragon05
13.10.2005, 12:20
Ich schließ mich Garo Black und Bauzi auch an.^^
Das wär sicher mal interessant, wenn irgendwas in dieser Richtung mal Zustande kommen würde, was auch gut ankommt.
Die Sache mit dem 3D Fake: Also ich glaube nicht, dass man wirklich sehr viel dreidimensionales einbauen kann. Man kann vielleicht die Perspektive ein wenig mehr Räumlichkeit verleien, so dass alles etwas mehr in Richtung 3D geht, aber so richtig alles in 3D, glaub ich eher nicht.
Und das Standart-KS aufzubessern, wäre eher langweilig, weil es zu diesem Thema schon genug gab (auch an Bsp.).
Also bin ich für Echtzeit Strategie im Maker!
öhm ja was ist denn die sogenannte Echtzeit Strategie? Kann mir darunter nichts vorstellen.
Gruß Miroku
bin auch für das echtzeit strategie dingens, weil mir auch
nich einfällt, was das is ^^
ich denke 3d grafik hat weniger mit technik zu tun, eher mit
mapping. man kann ja chipsets aus der 3d perspektive herstellen,
bloß ob man es auch KANN is die frage. :^^:
öhm ja was ist denn die sogenannte Echtzeit Strategie? Kann mir darunter nichts vorstellen.
so wie age of empires
starcraft
warcraft
etc...
ich denke 3d grafik hat weniger mit technik zu tun, eher mit
mapping. man kann ja chipsets aus der 3d perspektive herstellen,
bloß ob man es auch KANN is die frage. :^^:
nein es reicht nich einfach ein "3d chip" zuerstellen
das wäre dann höchstens iso
und das is ja wiederrum kein 3d ^^
@topic
bin auch für rts
haben viele genommen, also behandeln wir das thema wohl auch
so wie age of empires
starcraft
warcraft
etc...
aso, danke ^^
nein es reicht nich einfach ein "3d chip" zuerstellen
das wäre dann höchstens iso
und das is ja wiederrum kein 3d ^^
hm, schade ^^
aber was versteht man denn überhaupt unter 3d?
denkt ihr da echt an gegenstände, die mehrere
seiten haben? das kann man doch mit dem maker
voll vergessen, oder?
@topic
bin auch für rts
sind wohl alle also gehe ich mal davon aus, dass wir das nehmen ^^
Phönix Tear
13.10.2005, 15:13
Hmm, zum topic sag ich erstmal das ich auf für echtzeit Strategie. Ist für mich am interessantesten. Wie erwähnt sehen alle 3D Fakes nicht gerade toll aus und mit dem Standart KS will ich mich auch net beschäftigen ^^.
Pixelmovement... Nee, muss auch net sein ;)
@Samogas:
Es gab da glaub ich mal ein beispiel von einer engischen Seite. Ist so ein Jahr her (glaub ich). Da lief man in einem (recht schlechten) 3D Labyrinth durch die Gegend. Ich hab die Steuerung aber net ganz kapiert und hab mich total verfangen. Man sah einfach nur vor sich und an den Seiten ein paar graue Wände an denen man sich durch drücken der Pfeiltasten entlangbewegen konnte. Mehr war das nicht. Ich glaube kaum einer ist so vermessen zu versuchen echte 3D Graphiken mit dem Maker umzusetzen (also Kamera frei im Raum drehbar).
Caine Luveno
13.10.2005, 15:54
Nun, Fake 3D ist echt mies...
Echtzeitstrategie ist machbar, aber eben auch in begrenzter Weiße. Eine Kombination aus Pictures und Events denke ich wäre da angebracht. Bzw. da es keine dynamischen Events gibt (also nen Befehl "Create Event" oder so was) ist es schwierig...
Das Standard KS aufpeppen wurde schon zu oft gemacht. Der Trick mit Charas in den Batlle Animations ist nicht mehr neu... da wäre ich für n neues KS.
Nun, Fake 3D ist echt mies...
Echtzeitstrategie ist machbar, aber eben auch in begrenzter Weiße. Eine Kombination aus Pictures und Events denke ich wäre da angebracht. Bzw. da es keine dynamischen Events gibt (also nen Befehl "Create Event" oder so was) ist es schwierig...
Das Standard KS aufpeppen wurde schon zu oft gemacht. Der Trick mit Charas in den Batlle Animations ist nicht mehr neu... da wäre ich für n neues KS.
Der SChlüssel ist der:
Es gibt pro Einheit ein Event mit vielen Seiten für Aussehen usw... deswegen ist auch die Einheitszahl begrenzt!
Dann baut man was und dann wird das Ereignis vor eine Kaserne oder so hinteleportiert und die nötigen TABS aktiviert (war die grobe Erklärung)
Caine Luveno
13.10.2005, 16:38
Das ist logisch.... anders würde ich es auch nicht machen. Aber z.B. die Gebäude würde ich als Pictures einbauen.
Das größere Problem wäre eine funktionierende KI für Computergegner.
Wenn schon über Echtzeitstrategie diskutiert werden soll, dann würde mich eine Methode interessieren um den Fog of War darzustellen. Da sehe ich beim 2k und beim 2k3 absolut keine vernünftige(!) Möglichkeit.
Sorry Doppelpost! :rolleyes:
So ich habe es hin bekommen,auch mit dem path finding,habe jetzt nur noch ein Problem,wie kriege ich es im Xp Maker hin das die Kamera immer dem aktuellen Held(event) folgt.
Das problem ist nämlich im XP das ich nicht sagen kann der soll zu der und diesem X,V Variable.Bräuchte also einen anderen Trick,damit die Kammera immer dem aktuellen Helden folgt!
Wenn ich dies noch hinbekomme ist die Gegner KI dran und das mit dem Level der Helden.Sobald ich weiss wie die Kamera dem aktuellen Held(event)folgt,kann ich euch die ersten screenshots und vieleicht in 1-2 Wochen eine Demo zeigen.
Das Kampfsytem kommt nämlich dann im mein aktuelles Game the fifth element.
Das ist logisch.... anders würde ich es auch nicht machen. Aber z.B. die Gebäude würde ich als Pictures einbauen.
Das größere Problem wäre eine funktionierende KI für Computergegner.
Schonmal "Red Com" von Venoran gespielt? Ich weiß er war schon lange nicht mehr on, aber mit seiner Hilfe kriegen wir sicher eine Lösung für die KIs!
Die KI ist in der Form mit viel Aufwand hinzukriegen:
Man nimmt eine Gegnereinheit (von mir aus einen Soldaten) und geben ihm...sagen wir 6 Variablen:
Eine für Mut,
Eine für Feigheit,
Eine für Stärke,
Eine für Verteidigung,
Eine für Leben
und Eine für Magiepunkte whatever.
Diesen Variablen können wir jetzt spezifische Werte zuordnen, sagen wir Mut: 60, Feigheit: 40, Stärke: 80, Vert.: 40, Leben: 100, Magiepunkte: 100.
In einem Map eigenen Event fragen wir dann die Werte ab.
Sollte es so bleiben, überwiegen Stärke und Mut und der Recke zieht mutig in die Schlacht.
Nun fragen wir die Größe der eigenen Armee per Variable ab, die immer dann +1 addiert wird, wenn wir eine neue Einheit erstellen.
Sollte wir uns in der Übermacht befinden, würden sich die Werte der Variablen für diese Einheit ändern, am Besten je nach Größe der eigenen Armee. Das sähe wohl so aus:
Mut: 40, Feigheit: 60, Stärke: 40, Vert.: 80, Leben: 100, Magiepunkte: 100.
Dabei sollte man darauf achten, das die Werte sich nie über 100 bewegen, da man sich sonst unnötige Arbeit macht.
Diese Werte werden nun wieder abgefragt.
Da sich Feigheit und Verteidigungswerte in der Überzahl befinden, wird sich die Einheit zurückziehen.
So sollte eine einigermaßen vernünftige KI zustande kommen. ;D
So, meine Currywurst wird kalt,
Garo
Offensichtlich geht es wohl um Echtzeitstrategie?
Wartet ma noch n bisschen bitte ehe ihr zu diskutieren anfangt. ;)
Caine Luveno
13.10.2005, 18:56
Wenn schon über Echtzeitstrategie diskutiert werden soll, dann würde mich eine Methode interessieren um den Fog of War darzustellen. Da sehe ich beim 2k und beim 2k3 absolut keine vernünftige(!) Möglichkeit.
Da sehe ich schon eine. Z.B. viele kleine Pictures. Das wäre ne Mordsmäßige berechnung da wir ja davon nicht so viele anzeigen können um z.B. auf jedes Tile ein eigenes schwarzes Picture zu legen.
D.h. anhand von Variablen die speichern wo der Nebel noch ist und wo nicht müsste man nach jeder Scroll Bewegung der Map den Kram neu berechnen. Man könnte ja Pictures nehmen die 2x2 Tiles abdecken. Dann wird zwar mit einem Feld betreten 4 freigegeben, aber das sieht dann immerhin wie eine Art Sichtradius der Einheit aus.
Ich schließ mich Bauzi an.
Echtzeit Strategie ist ehrlich gesagt in keinem Makergame so richtig gut umgesetzt worden, VD² hat den Anfang mit den BES gemacht.
Also ebenfalls für RTS. ;D
Garo
Ich hab VD2 noch net gespielt aber vom Trailer her, öhm das sah net grade nach Echzeit aus... also ich bin ein Fan von Rundenbasiert, find ich net schlecht aber Echtzeit isses eben net
@Samogas: 3D heißt, dass das System zumindest mal dreidimensional rechnet und der Maker rechnet eben zweidimensional weil er nur 2 Achsen benutzt. Auf jeden Fall bedeutet 3D, dass Dinge tatsächlich mehrseitig gespeichert sind
Der SChlüssel ist der:
Es gibt pro Einheit ein Event mit vielen Seiten für Aussehen usw... deswegen ist auch die Einheitszahl begrenzt!
Dann baut man was und dann wird das Ereignis vor eine Kaserne oder so hinteleportiert und die nötigen TABS aktiviert (war die grobe Erklärung)
Joa, aber wie in meinem Eröffnungspost gesagt und wie du ja auch selbst meinst, das limitiert sehr stark Einheitenzahl und Einheitstypenzahl, find ich blöd
@Garo Black: Das is net groß KI. Es geht auch darum, wie die Einheiten den Weg finden, wann sie anfangen, jenen Gebäudetypen zu bauen (sie müssen sich ja dem Spieler anpassen, sonst kann der ganz schnell herausfinden, welche Kampftaktik von der KI nicht zu besiegen ist und dann wirds ja langweilig) etc... du denkst ja beim Spielen eine Strategiespiels auch tiefer nach nehm ich mal an
@Caine Luveno: Massig Events und diese eingebunden in eine riesige Berechnung weil ich nehm mal an, man will, dass der Fog of War von jeder eigenen Einheit aufgedeckt werden kann... net schwer aber seeeehr viel Aufwand
Öhm ansonsten, wie wärs mit einem Gespräch über die Umsetzung des anspruchsvollstem aller Strategiespiele, dem Schach? (natürlich als 2-Spieler Spiel, eine Schach-KI bekommt hier wohl keiner hin ^^ ...außerdem kenn ich grademal so die Werte von Figuren, nicht aber die von Stellungen... die Werte waren doch, Bauer 1, Springer und Läufer 3, Turm 5 und Dame 9, oder so in der Art?)
So ich habe es hin bekommen,auch mit dem path finding,habe jetzt nur noch ein Problem,wie kriege ich es im Xp Maker hin das die Kamera immer dem aktuellen Held(event) folgt.
Also wenn der Held jetzt als char nichts(also durchsichtig) oder einen Mauszeiger oder so hat, dann könnte man ja den Events manuell folgen.
Wenn ich dich richtig verstanden habe willst du das man auf ein event klickt und dann die Kamera folgt oder??
Wenn du nun über dem Event stehst und dann eine eventseite mit Tastendruck aktiviert wird die folgendes sagt würde es funktionieren:
Es müssten die xy-Koordinaten vom Helden und vom ereignis abgefragt werden und dann minus genommen. Wenn dann nicht 0 raus kommt, muss ein bewegungs ereigniss kommen. Zb. wenn der wert x=0 und y=-1 raus kommt müsste der Held nach unten laufen.
Solltest du sonst mit der KI oder mit den anderen Technischen Sachen Probleme haben kannst du mir auch ne Pn schicken.
Auserdem würde ich beim Xp die Häuser als Events machen, da erspart man sich Zeit und aufwand.
Hm Jo Schach klingt interessant fuer mich.
Habs mal in den ersten Post editiert.
Also nochmal an alle:
Schach auf dem Maker ist noch ein Moegliches Diskussionsthema!
Ich bin gegen Schach!
Das ist nicht echtzeit und dabei eine Gegnerki zu kreieren (eine gute!) ist glaube ich schon zu schwer... (besonders wenn er züge voraus denken soll!)
@Beril:
Mach den Echtzeitstr.thread auf ich kanns nicht erwarten :X
Also es ein art schach,da die figuren ja nicht alle unterschiedlich wie beim schach nur nach oben können,sondern diese können in einen bestinmmten umkreis pro runde laufen.Eine runde würde heissen 10 gegner und 10 eigene figuren,es kommt dann immer auf die jeweilige figur an die man grade steuert,ein reiter kann dann beispiels in einem grösseren feld laufen als ein bogenschütze,der kann aber wiederrum ein feld zwischen sich und dem monster haben und kann dann angreifen.
Übrigens,das mit dem Pathfinding geht doch net,mein event und der held standen nur unsichtbar im weg :( .Suche noch Leute die viel erfahrung mit dem Path finding haben.
held standen nur unsichtbar im weg
Beim Xp musst du ein Bewegungereignis auf den Held machen, das synchronisieren AN macht.
Beim 2k nännt sich das dann Durchfall
Suche noch Leute die viel erfahrung mit dem Path finding haben.
Ohne dein Genaues Problem kann ich dir net helfen, also endweder poste es in den Thread oder eine Pn
Edit:
dem Schach? (natürlich als 2-Spieler Spiel, eine Schach-KI bekommt hier wohl keiner hin
KI ist eben die Königs disziplin. Ein zwei Spieler Schach könnte ich in einer Woche basteln, nur reizt es mich nicht.
An sich wäre das ganz einfach:
1.Auswählen- man klickt (zb.) den Turm an, per taste drücken event. Es wird gespeichert das man über turm1 steht und ein allgemeines Ereigniss aufgerufen werden...
2.Bewegen- Wärend dieses Allgemeinen Ereignisses werden die Tasten abgefragt, per Kayptch. Drückt der Spieler hoch, läuft das Ding hoch usw. Das funtzt auch für diagonal. Wie es laufen kann, wird dan per Bedingung endschieden, wir haben ja gespeichert, das wir über einen Turm stehen.
Davor die variblen vergleichen ob da net was steht.
Man könnte sogar noch ein Picture anzeigen lassen, das Zeigt wie das Ding sich bewegt.
3.Eine Figur Schlagen- Tja wenn da dann doch eine Figur steht und die is vom gegner- TOT, gederme, Lunge, Auge ARRGH!! (oder in Eventbefehlen ausgedrückt- event löschen)
Ist nicht besonders Anspruchsvoll, du hast nämlich vergessen warum Schach so ein erstaunliches Spiel ist. Es ist sehr einfach in den Regeln, aber wenn man es verstanden hat birgt es unendlich Potentzial. Das liegt aber in der KI.
Caine Luveno
14.10.2005, 18:26
N Schach würde ich n bissel anders bauen.
Ich würde keine Tasten verwenden, sondern eher die Mausunterstützung.
Hierzu würde ich abfragen über welchem Event sich der Mauszeiger befindet. Bei einem Klick könnte man dann anzeigen wie sich die Figur bewegen kann und eventuelle Schlagmöglichkeiten markieren. Per zweitem Mausklick bewegt sich die Figur, falls möglich, auf das entsprechende Feld wo sich der Mauszeiger befand.
Fänd ich persönlich besser... für zwei Spieler leicht gemacht.
Aber eine KI? Das könnte schwer werden.... ich habe von Schwachprogrammen gehört die bis zu 100 Züge im voraus berechnen können aber dennoch leicht zu schlagen sind. Wenn man weiß wie...
D.h. da man im Maker niemals 100 Züge voraus berechnen können wird, wäre die einzige Möglichkeit bestimmte Zugkombinasstionen einzubauen und diese je nach dem Verhalten des menschlichen Spielers auszuführen. Wäre aber sehr leicht zu durchschauen.
Phönix Tear
14.10.2005, 18:55
Nein, ich wäre ganz gegen eine Umsetzung von Schach auf dem Maker. Das ist vielleicht eine ganz nette Aufgabe (wenn man viel Zeit hat) jedoch finde ich es nicht sondelich sinvoll. Gerade bei Dingen wie Schach kommt es auf eine gute KI an. Da würde dann schon eher die 2 Spieler Variante gehen. Trotzdem könnte man (imo) Schach nicht so toll umsetzen. Da rate ich dann doch eher zum Brettspiel. Es gibt viele Dinge die (auch wenn es sie schon so oder besser gibt) im Maker ihren Charme haben, aber Schach gehört definitiv nicht dazu.
Die Umsetzung eines Echtzeit Strategiespiels ist da sehr viel interessanter. Von der KI her auch sehr anspruchsvoll (wenn sie gut sein soll), aber vom Rest her wesentlich interessanter (weil man einfach unglaublich viel mehr Möglichkeiten hat das ganze umzusetzen).
@Macros: Du machst es dir einfach ^^
Ein Schachscript benötigt z.B. eine Routine, die überprüft, ob man einen Zug machen kann, der den eigenen König nicht bedroht und massig Script, das zwar net schwer aber aufwendig ist und das einfach nur überprüft, ob eine Rochade möglich ist etc. (wie hieß nochmal die eine Regel wo ein Bauer hinter einen gegnerischen läuft, der weiter läuft und so den ersten schlägt ohne ihn zu berühren?)
Aber wenns dir immer noch zu leicht is, wie wärs mit Räuberschach? (Regeln: 1. Du musst alle Figuren verlieren um zu gewinnen 2. Du musst schlagen wenn du schlagen kannst)
Btw, ich erwarte natürlich eine Lösung, die simpel genug ist um ohne massig Bugs aus Überblicksverlust umgesetzt werden zu können
@Fansoftware: Nein, Schach.
*hust*
Also beim Schach kann ich mitreden ich mal ein Schachscript versucht habe.
Dasganze umzusätzen ist nicht so schwer.Das woll schwerste an der aufgabe ist die Verwaltung der Figuren und die einhaltung der Regeln.Die KI ist recht einfach geschrieben das problem ist nur dem Script schach beizubringen :(
wie hieß nochmal die eine Regel wo ein Bauer hinter einen gegnerischen läuft, der weiter läuft und so den ersten schlägt ohne ihn zu berühren?)
das ist das schlagen "en passant (beim vorübergehen)"^^ (komisch das ich sowas weiss ^^)
wir sollten uns jetzt mal für was entscheiden
also rts oder jetzt doch schach?
Ryo Saeba 1000
14.10.2005, 22:10
Der Thread stammt btw ursprünglich aus dem Kami.
Wenn ihr nach dem Schwierigkeitsgrad gehen wollt, dann wäre Schach (ohne CPU KI) wesentlich einfacher umzusetzen als zB. RTS und würde imho auch nicht wirklich genug Gesprächsstoff liefern.
Die Steuerung und Regeln zu implementieren ist doch recht trivial.
"Fake-3D" ist auch nichts weiter, als ein paar Picturespielereien (mit zugegebenermaßen recht vielen Pics) und das Aufpushen des Standard-KS ist mMn auch kein besonders ergiebiges Thema.
Pixelmovement und RTS halte ich für die interessantesten Themen, auch weil ich beide schon theoretisch durchdacht und teilweise praktisch am RPG Maker 2k/2k3 gelöst habe.
Das mit dem Path Sytem habe ich durch einen Trick geregelt.
Damit können die Leute jetzt nur begrentz weit gehen bis zum nächsten zug.
Die KI ist als nächstes dran.Werde das mit Variablen lösen.
Das Problem ist dank Makros auch gelöst.
Damit bleibt jetzt noch das Menü und die KI.
IN 1-2 Wochen bekommt ihr dann ein Film.
!!!Das ist Versprochen!!!
Okay es ist eigentlich eindeutig:
Das Thema ist "Echtzeitstrategie"
Aalso dann froehliches Diskutieren.
Das erste problem, was sich meiner meinung nach auftut ist Positionierung von Gebaeuden.
Ich wuerde erstmal ein Limit fuer Gebaeude festlegen, indem man z.B. sagt man darf nur 4 Kasernen Bauen etc.
Dann macht man halt alle Events, die man braucht, um z.B. 4 Kasernen darzustellen und positioniert die irgendwo, wo der Spieler sie nicht sieht oder so (macht sie halt unsichtbar mit Change Graphic z.B.) Dann werden die Events auf die aktuelle Helden-Position teleportiert, so dass sie zusammen das Gebaeude darstellen. In der Database hat man zuvor eingestellt (per Terrain ID), welche Chips passierbar sind und welche nicht.
Jetzt fragt man alle Terrain IDs ab, die das Gebaeude bedeckt und wenn ein Feld nicht passierbar ist, dann kann das Gebaeude nicht platziert werden...
Okay war nicht zu schwer aber egal...
Go Ahead ;)
Ich würde das Problem generell anders angehen:
Ein neuer Picture Patch für 200 Bilder oder so muss her, der Key und der Mauspatch!
Dann Grafikfrage:
Welche Auflösung hat das ganze?
Ich meine Sprechen wir von einer mini map oder einer 500x500 mit normaler M&B Grafik (-->Problem schnelles scrollen mit der Maus und Minimap). Und werden in einem Event nur eine Einheit angezeigt, oder mehrere, wie ein Battalion MG Schützen oder Bogenschützen...
Solche Dinge sollten wir mal klären!
Das mit dem Path Sytem habe ich durch einen Trick geregelt.
Damit können die Leute jetzt nur begrentz weit gehen bis zum nächsten zug.
Die KI ist als nächstes dran.Werde das mit Variablen lösen.
Das Problem ist dank Makros auch gelöst.
Damit bleibt jetzt noch das Menü und die KI.
IN 1-2 Wochen bekommt ihr dann ein Film.
!!!Das ist Versprochen!!!
das wäre dann doch wiederrum rundenbasiert oder?
irgendjemand hat hier mal gepostet das er ein rts macht
und ich glaub der war auch schon recht weit
ob man einen Zug machen kann, der den eigenen König nicht bedroht
Wenn du in einem zwei Spieler Schach scheiß Züge machst verlierst du halt, oder net?
Hätte gerne noch draüber Diskutiert, aber das gehört inzwischen nicht mehr zum Thema.
für 200 Bilder oder so
Der Picturepatch benutzt eine Datei vom rpg-maker2003, da der nun auch keine 200 pictures benutzt wird das wohl net möglich sein.
Auserdem wäre es nutzlos und würde viel Leistung verbrauchen.
@Topic
Machen wir jetzt ein fictives Echtzeitstrategiespiel auf den Xp oder auf den 2k? Denn auf den Xp wäre das wieder was anderes.
Ich wäre für den Xp (wer hätte das gedacht). Vielleicht sollten wir vorher darüber abstimmen.
Phönix Tear
15.10.2005, 14:25
Stimmt, wäre sicherlich besser auch das abzustimmen. Ich persönlich bin eindeutig für den 2k, da ich den XP nicht habe. Sowieso besitzen ja noch die meisten den 2k, also halte ich das für sinvoller (auch wenn das mal ein Test für den XP wäre...).
@Topic:
Das mit den Pictures würde ich nicht so machen. Wie gesagt zu viel Rechenaufwand. Außerdem kommt das mit Char-Sets imo besser. Wenn man Pictures benutzen will, kann man die ja zur Positionierung verwenden. Also sobald man in der Menüleiste (so wie bei C&C) ein Gebäude ausgewählt hat und auch die nötigen Rohstoffe besitzt folgt automatisch ein Picture mit dem Gebäude der Maus. Sobald man klickt muss man dann von den Pixelkoordinaten auf die Feldkoordinaten umrechen. Das Picture wird entsprechend verschoben, wenn man dann nochmal klickt wird das Gebäude platziert und das Picture gelöscht (solange man da auch bauen kann). Um es dann etwas leichter für den Spieler zu machen kann man natürlich noch einiges an Vereinfachungen einbaun. Z.B. das man Gebäude bei denen man einmal geklickt hat (also noch nicht gebaut hat) automatisch wieder aufnehmen kann wenn man das Feld mit der Maus verlässt, etc.
Ansonsten würde ich mich im Maker stark an den alten C&C Teilen orientieren. Die Einheiten und Gebäude werden noch im Menü gebaut und dann platziert. Auf die Abfrage ob man nah genug an anderen eigenen Gebäuden drann ist würde ich dann verzichten.
Die Gebäude als Chars wären ja nicht so das Problem, wenn man eben nicht zu viele haben will. Jedes bekommt seinen Switch, wird hinteleportiert und der Switch angeschaltet.
Minimap:
Hier könnte man das ganze dann mit einer umgekehrten Rechnung des Heldenpunktes auf der Map machen. Normalerweise rechnet man ja die Position des Heldens auf der Map um, damit der kleine Positionspunkt auf der Karte angezeigt werden kann. Diesmal nehmen wir die Spitze des Mauszeigers als Punkt und rechnen umgekehrt. Damit können wir ein Feld feststellen auf das man geklickt hat. Nun nur noch ein Memorize-Place mit der momentanen Map ID, die X und Y Koordinaten selber eingeben und dann ein "Goto Memorized Place". Fertig. (Diese Variante schließt natürlich ein, dass die Kamerabewegung am Held orientiert ist und der Teleport auf "Instant" (oder wie das in der Data-Base heißt) gestellt ist.)
Mehr Zeit hab ich gerade leider nicht, ich hoffe trotzdem das die Diskussion beim 2k bleibt und noch interessante Dinge hinzukommen ;)
mfg
Phönix Tear
Ä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
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)
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!
Ryo Saeba 1000
16.10.2005, 18:00
Anständiges Pixelmovment sowie pathfinding funktioniert auf dem XP
Auf dem 2k auch.
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.
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).
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 :D
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 :D )
Ryo Saeba 1000
16.10.2005, 18:12
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
Nunja aber wie willste pathfinding aufm 2k umsetzen?
Würde da gerne mal ne demo sehen...
Ryo Saeba 1000
16.10.2005, 18:20
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/viewtopic.php?t=59760&postdays=0&postorder=asc&highlight=pathfinding&start=30
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.
ai junge pathfinding is wichtig für nen echzeit strategiegame!
Gekiganger
16.10.2005, 22:39
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.
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.
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?
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!
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!
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.
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.
Enolagay
17.10.2005, 14:41
Also Strategie-spiele ist wohl am besten!
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 :D, 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 :O
Aber wie macht man das mit der KI ? Hat die keinen fog oder was? :O
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)
Ryo Saeba 1000
17.10.2005, 17:34
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.
Ich finde die Idee ziemlich schlecht, da das viel zu ungenau wäre imo
Ok, is deine Meinung.
Allerdings kommt das auf das Verhältniss an.
Du könntest es ja auch mit 100 Feldern machen.
So wie ich es beschrieben habe hast du 24 Felder. Meinermeinung wäre das voll in Ordnung, weil bei einem "echten" Strategiespiel, wird der Fog ja in einem Radis um die Figur aufgedeckt. Hier ist es ähnlich.
@Topic: Hat jemand noch ne andere Idee, wie man die KI machen könnte, auser Meiner, oder noch ne' Verbesserung?
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.
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!
Gekiganger
17.10.2005, 19:32
In dieser Idee für den Fog of War sehe ich eine gute, aber auch eine schlechte Seite.
Die gute ist, dass sich eh nicht viele Einheiten mit dem Maker reallisieren lassen werden, dadurch wird jede Einheit, die man zum aufdecken eines solchen Feldes abstellen muss, zu einem Verlust. Dadurch stört die grobe Auflösung auch nicht so besonders.
Die schlechte ist allerdings, dass man bei einem Strategiespiel mit vielen Einheiten und Kontrollmöglichkeiten ein HUD benötigt, für welches jedes einzelne Picture wertvoll ist. Diese dann für den Fog of War zu verschwenden, würde ziemlich schmerzen.
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!
Dafür gibt es ja die Minikarte, die nichts über den Aufenthalt des Gegners verrät, sondern nur zur Steuerung der Einheiten in Gebiete, ausserhalb des eigenen Einflussbereichs, zu schicken, dient.
Ja du hast recht! Mit bildern sollte man echt sparsam sein! Beim XP sinds nur 50 pro map x.x ! (Kann man doch sicher irgendwie erhöhen oder so? maybe bilder mit RGSS anzeigen?)
Ryo Saeba 1000
17.10.2005, 20:29
Die schlechte ist allerdings, dass man bei einem Strategiespiel mit vielen Einheiten und Kontrollmöglichkeiten ein HUD benötigt, für welches jedes einzelne Picture wertvoll ist. Diese dann für den Fog of War zu verschwenden, würde ziemlich schmerzen.
Die Pics könnten wirklich knapp werden. Ich glaube zwar nicht, dass das HUD mehr als 20 Pics verbrauchen würde, allerdings hat von euch eigentlich schon jemand an die Rahmenauswahl gedacht? (also den Rahmen den man bei gedrückter Maustaste um mehrere einheiten zieht, um mehrere Einheiten gleichzeitig auszuwählen.)
Diese Sache allein verbraucht schon massig Pics imo.
Mit maximal 40Pics im 2k3 wird das schon recht knapp, wenn man dann auch noch Pics für den FOW verwenden müsste.
Die Pics könnten wirklich knapp werden. Ich glaube zwar nicht, dass das HUD mehr als 20 Pics verbrauchen würde, allerdings hat von euch eigentlich schon jemand an die Rahmenauswahl gedacht? (also den Rahmen den man bei gedrückter Maustaste um mehrere einheiten zieht, um mehrere Einheiten gleichzeitig auszuwählen.)
Diese Sache allein verbraucht schon massig Pics imo.
Mit maximal 40Pics im 2k3 wird das schon recht knapp, wenn man dann auch noch Pics für den FOW verwenden müsste.
Hmm ja so ne Rahmenauswahl brauch natürlich auch wida pics... ich denke man sollte es so machen dass man einfach ctrl gedrückt halten muss und dann die einheiten anklicken welche man kommandieren kann. Is auch ne möglichkeit, einfach umständlicher beim spielen! Kann man da nix machen damit man mehr pics hat?
Phönix Tear
17.10.2005, 22:10
Der Fog of War dürfte eigentlich nicht mehr als 4 Pictures fressen. Wir müssen sie ja nicht immer Anzeigen, wir können auch abfragen wo sich das Blickfeld des Spielers gerade befindet (auf jeden Fall wenn der Blick Held-Zentriert ist, sonst vielleicht mit einer Umrechnung der Maus Position (X-Y Koordinate und X-Y Scene (nimm die X-Y Koordinaten mal 16 und ziehe davon die Scene X-Y Werte ab und du hast die linke obere Ecke des Bildschims (glaub ich zumindest ^^°)))). Wenn nun dieses Blickfeld einen speziellen Wert überschreitet haben wir einen kleinen Code der dann das passende Pic an der richtingen Stelle Anzeigt (wir haben ja feste Grenzen). Ich kann mal davon ausgehen das ein Pic minimal so groß wie der Bildschirm ist. Ob nun das Bild angezeigt wird oder nicht macht man wohl am besten einfach mit einem Switch. Der wird eben an und aus geschaltet sobald sich eine Einheit rein, bzw. raus bewegt. Maximal 4 Pictures sind es dann, weil ein Bild minimal so groß wie der Bildschrim ist, dementsprechend kann man auch maximal 4 Bilder auf den Bildschirm haben (jeweils in den entgegengesetzten Ecken).
Somit sollte diese Version des Fog of War eigentlich umsetzbar sein.
Das mit dem Rahmen ziehen halte ich schonmal für nicht so gut umsetzbar. Da man die Einheiten beschränkt, würde ich sowieso dafür sein das man eine Armee hat, die von einer einzelnen Einheit verkörpert wird, daher kann man sich dann schon mal die mühe machen und die Armeen einzeln anklicken (bei maximal 10 sollte das schon noch gehen ;) ). Außerdem ist der Rahmen dann wieder so eine Sache... Wie genau will man den umsetzen? Ich würde vielleich 4 sehr sehr lange Striche machen, die dann einfach weiter auseinander gehen (je nachdem wie man die Maus bewegt), aber einen richtigen Rahmen... Da wüsste ich jetzt spontan wirklich keine Lösung...
Soviel erstmal
mfg
Phönix Tear
Der rahmen wäre wie folgt gemacht (picture fressend):
Wenn wir als Einheiten Events nehmen, ist das Movement ja über einen Raster (den Eventraser des rpgmakers), so würde man jetzt ein grüne-transparentes Bild haben (nur beispiel) das genau 16x16 pixel gross ist (das ist die Tilegrösse des rpgmakers 2k(3)) also wenn wir jezt irgendwo hinklicken würde auf dem Rasterfeld dieses grüne quadrat erscheinen, wenn wir nun die Maus ziehen erscheint überall auf dem weg ein neues Picture und es formt sich ein Rechteck.
Ja das wäre eine Idee, aber soviele pictures haben wir auf keinen fall, also müssten wir die Grösse des Rahmens beschränken.
Dann gäbe es noch die möglichkeit das wir für jeden Rahmen der möglich wäre (also 1x1 bis 20x15) ein eigenes bild anfertigen würden. Das wäre dann 1x1, 1x2, 1x3, 1x4 ..... bis 20x15 !
Dann könnten wir immer das jeweilige Rahmen Picture durch ein neues ersetzen, so würde nur 1 Picture verbraucht werden. Ich glaub ich setz mich mal ran und mach ne Demo damit ihr seht was ich meine.
Beim XP gäbe es noch die Möglichkeit anstatt Pictures den 3. Layer zu benutzen. (Im XP gibt es ja 3 Layer, in jeden Layer kann man normale Tiles sowie Events setzen, somit können 3 Events übereinander sein.)
Das Problem Rahmen gehe ich von der logischen Seite an:
Ich denke mir mal, dass Einheiten „groß“ sind also: 20x15 Pixel groß sind! Also warum nicht gleich eine Art „Einrastfunktion“? Wer kennt Idraw? Da gibt's ja so eine schöne Einrastfunktion und so was müsste man irgendwie umsetzen können. Also:
1.Man nehme ein Pic mit nur EINER Farbe, also ein 20x15 Rechteck (das mit der Farbe kommt später)
2.Wenn man jetzt den Mauszeiger zieht muss das Bild sich nach vergrößern und die linke obere Ecke muss dann seine Koordinaten korrigieren. (Das sollte doch nicht so schwer sein!)
3.Weil es nur ein einfaches Rechteck mit einer Farbe ist, gibt es dann keine übergroßen ecklig große
Pixelvergrößerungen. (Wenn man dem Rahmen ein Muster gibt, dann muss man ihn größer machen und immer nach verkleinern.
4.Wie groß kann man den Rahmen ziehen?
Tja.... deine möglichkeit is aber wieder n tick schwerer, 1. müsste man für grössere Einheiten entweder keine Events benutzen 2k(3) weil die da ur 16x16 gross sein können, sondern pictures. Oder den XP benutzen in dem Evetns verschieden gross sein können (Ja ganz recht ich mach immer den XP gut ;D).
2. Müsste man für JEDES PIXEL ein Rechteck machen! (Das is net wie bei meiner variante alle 16x16 pixels) Weil der Maker nicht wie du meinst bei Irgendwelchen Bildern die Ecke irgendwo anders hinsetzen kann :eek: .
Zu der grösse des Rahmens: Bei meiner Variante 1 würde das Programmieren leicht sein aber MAX nur ungefär 5x5 gross (und damit meine ich maximal) da er sonst zuviel Pics frisst.
Bei meiner Variante 2, kann er unendlich Gross sein und frisst immer nur 1 Pic, aber je grösser man ihn haben will, umso umsändlicher wird das Programmieren.
Ich arbeite gerade an einer Umsetzung meiner Variante 2 mit einem maximalen Rahmen von 3x3 (braucht trotzdem nur 1 pic). 3x3 Rahmen mach ich weil es ja nur ne demonstration sein sollte und mir 5x5 oder mehr zulange gehen würde und zu umständlich wäre.
Wer die Methode dann in dem Game verwenden will, und nen grossen Rahmen von bis zu 20x15 haben will (also bis den ganzen screen voll), muss ich halt dann die Mühe machen und das scripten...
Ryo Saeba 1000
18.10.2005, 12:15
Tja.... deine möglichkeit is aber wieder n tick schwerer, 1. müsste man für grössere Einheiten entweder keine Events benutzen 2k(3) weil die da ur 16x16 gross sein können, sondern pictures. Oder den XP benutzen in dem Evetns verschieden gross sein können (Ja ganz recht ich mach immer den XP gut ;D).
Du täuschst, da Chars im 2k/2k3 eine größe von 32x24 haben können (Höhe x Breite).
Das Problem Rahmen gehe ich von der logischen Seite an:
Ich denke mir mal, dass Einheiten „groß“ sind also: 20x15 Pixel groß sind! Also warum nicht gleich eine Art „Einrastfunktion“? Wer kennt Idraw? Da gibt's ja so eine schöne Einrastfunktion und so was müsste man irgendwie umsetzen können. Also:
1.Man nehme ein Pic mit nur EINER Farbe, also ein 20x15 Rechteck (das mit der Farbe kommt später)
2.Wenn man jetzt den Mauszeiger zieht muss das Bild sich nach vergrößern und die linke obere Ecke muss dann seine Koordinaten korrigieren. (Das sollte doch nicht so schwer sein!)
3.Weil es nur ein einfaches Rechteck mit einer Farbe ist, gibt es dann keine übergroßen ecklig große
Pixelvergrößerungen. (Wenn man dem Rahmen ein Muster gibt, dann muss man ihn größer machen und immer nach verkleinern.
4.Wie groß kann man den Rahmen ziehen?
Das Problem bei deiner Methode ist leider, dass wir dann nur einen "festen Rahmen" haben, dessen Größe zwar variabel ist, aber dessen Seitenverhältnisse "starr" sind (soll heißen immer Verhältnis 20:15)... was die Rahmenauswahl doch recht unpraktikabel macht.. würde ich nicht so lösen.
Dann schon eher wie Nevius es vorschlug:
Dann gäbe es noch die möglichkeit das wir für jeden Rahmen der möglich wäre (also 1x1 bis 20x15) ein eigenes bild anfertigen würden. Das wäre dann 1x1, 1x2, 1x3, 1x4 ..... bis 20x15 !
Nur anstatt eines "grüne-transparentes Bildes" würde ich nicht-ausgefüllte Rechtecke nehmen. Kommt am Ende auf's selbe raus, wenn man für jede Möglichkeit ein Bild erstellt und es sieht besser aus imo.
So hab nun mal n kleines script für den Rahmen im 2k geschrieben.
http://rapidshare.de/files/6433692/rahmen.rar.html
Einfach den Baum anquatschen und schon gehts los. Linke Maustaste drücken und man kann einen Rahmen ziehen. Der Rahmen darf nur 3x3 Tiles gross sein, sonst verschiebt er sich (das verschieben kann man auch wegmachen). 3x3 maximal ist es weil ich zu faul war um mehr zu scripten (is ja auch nur ne demonstration), ginge Problemlos auch nen Rahmen der den ganzen Screen ausfüllt. (wäre halt bissel aufwendig, aber wenn ihrs braucht für n game mach ichs gern) Script dürf ihr gerne erweitern oder verbessern (postet es dann mal hier). Ich glaube hiermit ist das mit dem Rahmen geklärt, diese Methode ist gut umsetzbar und braucht nur 1 pic!
Nächste frage: Wie stellt ihr euch das mit dem Scrollen vor? der Mauszeiger is der Hero oder was? Oder unsichtbarer Hero is unterm Mauszeiger und daum Scrollt es?
Da mit der Eventgrösse habe ich mich wirklich getäuscht, sorry, aber Eventiles sind doch 16x16 gross :D
Gekiganger
18.10.2005, 18:11
Für kleine Rahmen ist das System sicher gut geeignet, da man nur ein Picture braucht und sich der Skriptaufwand im Rahmen hält.
Allerdings steigt der Picturebedarf dabei proportional zu der Anzahl der zu erfassenden Felder an. Sprich, um einen Bereich von 20x15 Felder, also einen Screen, zu erfassen, bräuchte man 300 Pictures.
Ab solchen Größen halte is es für besser, einmal Bilder für die X- und einmal Für die Y- Achse zu machen, die sich dann jeweils um ein Feld in ihre jeweilige Richtung erweitern.
Bsp. X-Achse:
Pic1: #
Pic2: ##
Pic3: ###
Pic4: ####
Pic5: #####
Um solch einen Rahmen aufspannen zu können, braucht man allerdings 4 Pictures. Auch ist der Skriptaufwand höher, da man die Darstellungen 4x machen muss.
Dafür lässt sich mit dieser Methode ein Feld mit nur x+y-1 Bilder aufspannen, bei einer Größe von 20x15 Felder also 34 Stück.
Auch wird die Erweiterung des Skriptes und damit der Feldgröße, je größer das Feld werden soll, immer einfacher im Gegensatz zur anderen Methode.
Was das Scrollen angeht, so würde ich es ganz klassisch machen; Mauszeiger als Picture, von welchem die Position bei Aktionen auf die Mapkoordinaten umgerechnet wird. Berührt die Maus den Bildschirmrand, so läuft der Hero in die Jeweilige Richtung.
Vorteil: auch schräges Scrolling ist möglich.
Nachteil: durch ein Skript muss verhindert werden, dass der Hero jemals den Maprand erreicht, da er sich sonst aus der Bildmitte hinaus bewegen würde, wodurch es bei einem Richtungswechsel in die entgegengesetzte Richtung so aussehen würde, als würde der Screen kurz hängen. (bis der Hero wieder zur Bildmitte gelaufen ist)
hö? meinste jetzt mei nscript damit? das braucht imemr nur 1 picture egal wie gross der rahmen wird o.o Oder meinst du die pics im ordner (also die bilder) ?
Dein system kapier ich ned so ganz :O wie willste das scripten? Also ich denke mit meinem System sind wir gut bedient :D
Das scrollskript das du vorgeschlagen hast find ich gut!
Mal noch so ne frage am rande: Wird das jetzt son Projekt hier? Also machen wir jetzt hier n Echzeitstrategiespiel? Oder diskutieren wir nur?
nya, das Scrollen würde ich imo mit dem Pan Screen Befehl machen,
läuft imo auf's gleiche hinaus wie es mit dem hero zu machen, jedoch erübrigt sich das Problem, mit dem Rand...
ich glaub wir diskutierne nur aber ich fänds cool wenn was dabei rauskäm^^
Zitat von: Nevius
So hab nun mal n kleines script für den Rahmen im 2k geschrieben.
Ich habs getstet und ich denke, dass das wohl die beste Methode ist. Habe jedenfalls keine Mängel festgestellt.
Tolle Arbeit.
ich glaub wir diskutierne nur aber ich fänds cool wenn was dabei rauskäm
Jo, irgendwie fände ichs auch cool. Es wollte ja mal Jemand ein Echtzeitstrategiespiel machen, aber ich denke es liegt auf Eis.
Es könnte ja zum Schluss in einem Reisenproject, wie Metropolis enden.
Also das jeder der will, nach dem was im Thread steht etwas scriptet und wir das dann zusammenfügen.
Is natürlich nur eine Idee nebenbei.
Phönix Tear
18.10.2005, 23:31
Ich habs getstet und ich denke, dass das wohl die beste Methode ist. Habe jedenfalls keine Mängel festgestellt.
Tolle Arbeit.
Einen habe ich schon gefunden. Fang mal weiter rechts einen Rahmen an und bewege dann die Maus nach links. Nun kannst du sie beliebig hin und her bewegen, der Rahmen geht nicht über seine start X Koordinate hinaus und bewegt sich entgegengesetzt zu deiner Mausbewegung... Ich bleibe zwar eigentlich dabei das wir keinen Rahmen brauchen, jedoch fände ich, dass diese Methode dann nicht wirklich den Zweck erfüllt. Wenn man schon extra eine Rahmenfunktion einbaut dann aber auch so das alles funktioniert. Zuerst hätte ich aber gerne noch die Frage geklärt wie ihr dann die Charas die ihr dann ausgewählt habt, einfach und zusammen bewegen wollt. Im Gänsemarsch oder eine ganz neue Pathfinding Methode bei der man auch Formationen berücksichtigt? Vielleicht könnten wir auch einfach jeden Chara einzeln berechnen und am Ende einfach wieder (wenn möglich) den Positionen in der Formation zuweisen...
nya, das Scrollen würde ich imo mit dem Pan Screen Befehl machen,
läuft imo auf's gleiche hinaus wie es mit dem hero zu machen, jedoch erübrigt sich das Problem, mit dem Rand...
Nee, bin ich nicht für. Es läuft ja nicht aufs selbe hinaus. Ich hab ja einmal schon geschrieben das es sicherlich besser ist den Helden immer da zu haben da man sich dann einige Scherereien mit der Berechnung des zu sehenden Bildausschnittes, etc. ersparen kann.
Das Problem mit dem Rand ist eigentlich (hoffe ich ^^°) noch recht leicht zu lösen. Mir fallen da spontan 2 Möglichkeiten ein:
Fehlerkorrektur nach der Aktion:
Nach jeder Bewegung des Helden wird seine Scene Position berechnet. Entspricht diese nicht der Mitte des Bildschrims wird er auf die richtige Position zurückbewegt.
Problem: Ich schätze es könnte zu (mehr oder weniger) leichtem Ruckeln (bis hin zum völligen Absturtz) kommen wenn man nun den Mauszeiger zum Kartenrand bewegt, da eigentlich eine Endlosschleife entstehen müsste...
Direktes vermeiden von Fehlern:
Da eine Map ja immer nur 4 Ecken hat müssten wir lediglich am Anfang 4 Variablen angeben. X-Links, X-Rechts, Y-Oben und Y-Unten (natürlich die Scene Positionen der Ränder (z.B: 0,160,0,320 für eine 10x20 Map (X-Links und Y-Oben könnten wir uns dann eigentlich auch sparen ^^°))). Bevor nun die Bewegung des Helden ausgeführt wird, wird erst kontrolliert ob der Mauszeiger nicht einem dieser Werte entspricht. Wenn ja findet keine Bewegung statt und (wahlweise) schalten wir ein nettes Picture an das zeigt das es in diese Richtung nicht weiter geht (wie in C&C). Natürlich müssen wir berücksichtigen das sich der Held schon bewegen soll, falls man die Maus in eine der Ecken bewegt (dann aber eben nur in die "offene" Richtung).
Das sollte eigentlich funktionieren. Wenn wir ein "Wait" einbaun dürfte es keine Nebenwirkungen geben...
Nochmal zum Rahmen:
Ich bleibe dabei das ein Rahmen aus 4 sehr langen Strichen eine einfache und (wenn es denn sein muss) angemessene Lösung ist. Es sieht vielleicht nicht so toll aus, zeigt aber auch einen anderen (und glaub ich sogar) völlig neuen Stiel ;)
Hier wie ich das meine:
http://www.directupload.net/images/051019/temp/2yZcgq57.png (http://www.directupload.net/show/d/490/2yZcgq57.png)
Natürlich wäre dann das vom Rahmen umkreiste nicht ausgefüllt, das hab ich jetzt nur zur besseren Übersichtlichkeit gemacht ;)
Wie gesagt, es sieht nicht sonderlich toll aus, aber es sollte funktionieren...
mfg
Phönix Tear
Ich habe mir das Script im Maker noch nicht angeschaut, aber die Fehler die auftreten, hängen doch damit zusammen dass man momentan nur ein Feld von 3x3 tiles ziehen kann. Dieses Script war wohl auch mehr zur demonstration gemacht. Wenn es so ausgereift ist, dass man den Ganzen Screen ausfüllen kann, scriptet man einfach noch dazu, dass man nicht weiter raus kann, solange mann einen Rahmen zieht.
Zur unvollständigeit des Scripts und dessen Zweck der Veranschaulichung zitiere ich folgendes von Nevius:
Linke Maustaste drücken und man kann einen Rahmen ziehen. Der Rahmen darf nur 3x3 Tiles gross sein, sonst verschiebt er sich (das verschieben kann man auch wegmachen). 3x3 maximal ist es weil ich zu faul war um mehr zu scripten (is ja auch nur ne demonstration), ginge Problemlos auch nen Rahmen der den ganzen Screen ausfüllt. (wäre halt bissel aufwendig, aber wenn ihrs braucht für n game mach ichs gern) Script dürf ihr gerne erweitern oder verbessern (postet es dann mal hier).
Ausserdem braucht man bei deiner Methode vier Pics, hier nur eins. Man müsste sehen wie deine Version aussieht, jedoch stelle ich mir das etwas unkonfortabler vor.
Macros hat eigentlich schon alles gesagt, ich möchte es aber noch gerne bestätigen:
Mein Rahmen-Script ist nur für einen Rahmen von 3x3 gedacht, nur zur demonstration... Es funktioniert problemlos denn ich habe es la nge genug getestet... Wie Makros gesagt hat müsste man dann einfach das Scrollen unterbinden und das Rahmenscript auf 20x15 erweitern... (wäre halt n bischen arbeit aber in 2 tagen hat man das auch... wenn nicht weniger!)
Direktes vermeiden von Fehlern -> Find ich gut, sollten wir so machen!
Dein Rahmen -> Mach doch mal ne demo, kann mir net so vorstellen wie du das scripten willst... wäre wahrscheinlich noch umstänlicher als meins!
Phönix Tear
19.10.2005, 13:23
OK, kein Problem.
Wie gewünscht habe ich einmal mein Rahmen-System umgesetzt. Bei der Gelegenheit habe ich auch gleich noch das Scollen eingebaut. Es funktioniert einwandfrei ^^.
Auf der Map befinden sich 3 Soldaten die die Armeen darstellen sollen. Wenn ihr den Rahmen um sie zieht werden sie von transparent auf normal gesetzt und kriegen so eine beispiel Statusanzeige auf sich gelegt. Klickt ihr wieder irgendwo anders hin verschwindet die Auswahl wieder. Im Code habe ich an allen möglichen Stellen Comments reingepackt, auch welche die die meisten warscheinlich nicht brauchen werden ^^.
Was ich noch hätte machen können ist, das der Rahmen nur erscheint wenn man auch wirklich zieht, jetzt erscheint er immer, auch bei einem einzelnen Klick.
HIER (http://rapidshare.de/files/6476978/Rahmen_Test_2.rar.html) dann erstmal die Datei...
Hoffe ihr kommt damit klar ;)
mfg
Phönix Tear
P.S.:
Wenn ihr im Spiel die rechte Maustaste drückt könnt ihr die Scrollgeschwindigkeit erhöhen / verringern (erst einmal erhöhen, dann wieder verringern).
Wow, hätte nicht gedacht dass das so einfach ist :D, haste wirklich sehr gut gemacht! Also machen wir jetzt alle zusammen n kleines RTS? Wenn wäre das Rahmendings von Phönix doch besser :)
Könnte man diese Einheitenbegrenzungen nicht umgehen, indem man es ähnlich "Die Siedler 2" macht, dh die Einheiten einfach in ihren Gebäuden sitzen und bewachen und nur für Angriffe/Verteidigung rauskommen? Oder ist das einfach vom spielerischen her nicht so beliebt?
Ok, habe mir das Script angeschaut und muss zugeben dass es wirklich bessr ist.
Könnte man diese Einheitenbegrenzungen nicht umgehen, indem man es ähnlich "Die Siedler 2" macht, dh die Einheiten einfach in ihren Gebäuden sitzen und bewachen und nur für Angriffe/Verteidigung rauskommen? Oder ist das einfach vom spielerischen her nicht so beliebt?
Habe mir das auch schon überlegt und hätte im prinzip nichts dagegen, jedoch ist dies ja ein Diskusions Thread, mit einem doch etwas perfectionistischen Hintergrund.
Anstatt das einfach hinzunehmen, sollten wir lieber alle Probleme, die uns an eine Einheitenbegrenzungen binden aufschreiben und uns überlegen, wie wir die systematisch umgehen.
Phönix Tear
19.10.2005, 23:37
Spontan falen mir 6 Gründe ein, warum wir eine Einheitenbegrenzung brauchen:
- Wir verwenden als Einheit jeweils ein Event, welche wir vorher haben müssen und nicht nach belieben erstellen können
- Pathfinding ist so schon recht komplex, wenn zu viele Einheiten auftauchen wird es sehr, sehr schwer werden
- Kämpfe dürften im normalen Bildschirm mit vielen Einheiten sehr schwer zu machen sein, sowie auch recht unübersichtlich und schwer zu steuern
- Es wirkt zwar so als wäre der Bildschirm recht groß, trotzdem lässt er sich sehr leicht mit einzelnen Einheiten überfüllen was die Übersichtlichkeit einschränkt
- Viele Einheiten brauchen unglaublich viele Variablen die wir alle einzeln einstellen müssen (außer wenn wir sie per Nummer zuweisen)
- Mit ergänzenden Scripten wie z.B. für die Rahmen kann das sehr Ressourcen fressen werden (denkt ans KS)
- Mehr fällt mir jetzt nicht ein
Den ein oder anderen könnte man umgehen. Das Problem mit den Variablen z.B. mit Zuweisungen per Variablen Nummer, trotzdem können wir so nicht unendlich viele Einheiten aufstellen, da sonst die Abfrage zu kompliziert wird (Rahmen und KS). Der ein oder andere Punkt spricht auch noch dafür, das wir garnicht so viele Einheiten haben wollen. Ich wäre bei sowas immer noch dafür ein eigenes KS aufzubaun. Die Frage ist nur wie wir das verbinden. Ein echtzeit Strategiespiel basiert ja auch darauf das man seine Einheiten umher schickt und diese dann angreifen können, ohne das man einen extra Kampfmodus braucht (sonst hätten wir ja sowas wie bei "Heros of Might and Magic"). Wir sollten uns (imo) eher damit beschäftigen wie wir ein ordentliches KS mit wenig Einheiten umsetzen, anstatt uns darüber den Kopf zu zerbrechen wie viele wir einbringen können.
Es muss ja nicht immer nur durch weitere Events geregelt werden. Auch Regeln im Spiel können da abhelfen (automatische Zustellung neuer Truppen zu einer bestehenden Armee, etc.). Am Ende sollte nur etwas zustande kommen, dass einem Spaß macht, es zu spielen. Natürlich ist (momentan) unser Augenmerk erstmal darauf gerichtet, wie man neue technische Probleme am besten mit dem Maker löst, aber einige haben ja angesprochen das da am Ende was gutes bei rauskommen soll, also müssen wir uns früher oder später auch um die Wünsche der Spieler kümmern. Aber wie gesagt: Alles zu seiner Zeit ;)
Ich würde im Moment gerne von euch hören wie ihr überhaupt gedenkt das KS umzusetzen... Jetzt nicht direkt das Problem mit dem Pathfinding, eher wie es generell laufen soll...
mfg
Phönix Tear
Also ist das nächste Thema das KS und Pathfinding!
Erstma zum KS:
Da müssen wir uns am AKS orientieren. Ich denke jetzt mal das es in einem RTS Fernkampf sowie nahekampf einheiten gibt! (Wobei Zauber auch zu Fernkampf gehören) Also für Nahekampfeinheiten habe ich mir das so vorgestellt, wir Speicher die Position von Gegner1 und Nahekämpfer1 in Variabeln, dann benutzten wir Pathfinding um Nahekämpfer1 zu Gegner1 zu lotzen. Jetzt hackt Nahekämpfer1 auf Gegner1 ein bis er tot ist oder sich nichtmehr in reichweite befindet, ist Gegner1 ausser Reichweiter wird wieder Pathfinding eingesetzt... usw... dann könnte man sozusagen noch ne art sichtfeld für die Einheiten scripten, die Einheit greift Gegner Automatisch an welche sich im Sichtfeld befinden! So würde Nahekämpfer1 sich einem andern Gegner zuwenden(sofern dieser in Sichtweite ist) nachdem Gegner1 tot ist!
Fernkämpfer:
Gibt der Spieler ihnen den Befehl irgendwo hin zulaufen, bleiben sie Stehen wenn ein Gegner in ihre Reichweite kommt, und ballern auf ihn, geht er aus der Reichweite wenden sie sich wieder dem Bewegungsbefehl von vorhin zu.
Pathfinding:
Ein sehr, seeehr grosser grund den XP zu benutzen! Alles wird einfacher, unkomplizierter! Ich hab da schon ein Script it A*, also würden wir das einfach in eine Function schreiben (Function/Method = Common Event in ruby) und wenn wir Irgendwie Pathfinding brauchen würden, einfach die Function Callen, die einheit und ihr Ziel der Function angeben und schon funktioniert alles :D
PS: Hab doch noch n nachteil in deinem Rahmen gefunden: Er braucht 3 Pictures mehr :D Is aber trotzdem besser ;)
Einheitenlimit:
Ich sehe ja ein das man nicht "unbegrenzt" Einheiten haben darf, aber es sollte halt auch nicht akuter Mangel bestehen. Es hatte glaube ich jemand von 10 Einheiten gesprochen und das finde ich auf jeden Fall zu wenig.
Wenn wir dann ein Einheitenlimit haben, sollten wir die Upgrades der Einheiten in den Vordergrund stellen.
Pathfindung...seeehr grosser grund den XP zu benutzen
Das ist bei wietem nicht der einzige. Beim Xp haben wir Lokale taps. Auch habe ich ein Aks Script gesehen mit mehreren Parymitgliedrn, die keine Events waren.
@Nevius:
Du hast einen Denkfehler drin. Ein Trupp von dir und ein Trupp vom Gegner treffen sich in der Mitte. Nun greift Gegner1 Einheit1 an. Die steht, aber garnicht dort, sondern in deiner Basis, dumm oder?
Aber jetzt erst zum KS:
Hmmm.Schwierig.
Ich versuche mich in einem "Ansatz".
Wenn man mit den Einheiten loszieht, sollte man die Angriffsformation bestimmen und wie sie reagieren sollen (agressive/passive), nun sollte abgefragt werden, ob im Umkreis Gegner sind.
Dafür nimmt man die Variabele einer Einheit (der einfachhalts halber, wobei das Problem endsteht, dass wir net wissen von welcher, ausser wir sagen das bei jedem Trupp automatisch eier zum Leader erklärt werden muss-fände ich eigendlich cool).
Wenn wir nun die Variabel der einen Einheit fragen wir ab, ob bei der y-Variabelen +/-10 ein Gegner steht und bei der X-Var. +/- 10.
Um Ressurcen zu sparen könnte man vorher abfragen in welchen Gebit Gegner sind.
Man fragt ja schon ab in welchen Gebit "wir" sind, wegen dem Fog of War, wenn wir in einem Gebit nahe den der Gegnerischen Einheiten sind wird das Abfragen der Variabelen aktiviert.
Wenn nun da ein Gegner steht, werden die einheiten in den Angriffsmodus geswitcht.(wobei wir da wieder Probleme bekommen, da der 2k keine Lokale Taps hat.)
Nun stellen sie sich auf, und setzen Nah-und Fernangriffe ein, wie wir es ihne vorher gesagt haben.
Vor dem Angriff muss geklärt werden wer da steht (welche Event Zahl) und "wer" da steht, also Bauer, oder Mega Boss.
Es wird dann abgefragt diese Einheit greift diese an, zur nächsten wird diese Einheit schon angegriffen, wenn ja, dann nehme ich ne andere.
Dann kommt die Schadensberechnun.
Lol logischer weise greift die Nahekampfeinheit1 nicht imemr Gegner1 an... sie greift den sich am nächsten befindenden Gegner an (welcher sich im sichtradius befindet) -.- hab ich ja gesagt sie greift nur gegner im sichtradius an x.x
AKS im Team: Ja das von Fantastica, is aber ne scheiss KI ....
Baka-Chen
20.10.2005, 11:27
Ist es eigentlich möglich jede Taste des Keyboards in den RPG-Maker XP einzubeziehen?
(Hab gedacht passt ganz gut zum Thema...)
hab ich ja gesagt sie greift nur gegner im sichtradius an
Eben das ist sehr umständlich im 2k zu scripten. Im xp könnte man das glaube ich mit RGSS machen, kenne mich mit Ruby aber leider net aus.
Ist es eigentlich möglich jede Taste des Keyboards in den RPG-Maker XP einzubeziehen?
(Hab gedacht passt ganz gut zum Thema...)
Nein das passt eigendlich nicht ins thema, das hättest du wenn du dir den Thread durchgelehsen hättest auch bemerkt. Sollte dies aber nicht um Dauerzustand werden, ist das aber net so schlimm.
So viel ich weis, kannst du, ohne RGSS folgende Tasten belegen:
Enter, space, esc, Num0, Shift, A, S, D, Q, W, Z. X, B, V, C.
Die konfiguration kannst du im Spiel, wenn du F1 drückst vornehmen.
Benutzt wird dies dann mit einem Tasteneingabe ereigniss, was das in eine Variabele speicher, die du in einer Bedingung abfragst.
So ein sichtradius is wirklich easy...
Du vergleichst einfach die Kordinaten der Einheit und von den Gegnern, ist der unterschied 10 oder weniger (wenn der sichtradius jetzt 10 wäre) -> Gegner im Sichtradius
So ein sichtradius is wirklich easy...
Du vergleichst einfach die Kordinaten der Einheit und von den Gegnern, ist der unterschied 10 oder weniger (wenn der sichtradius jetzt 10 wäre) -> Gegner im Sichtradius
Dann müsstest du aber, wenn jeder 20 Einheiten hat 20x20 also 400 Variabelen berechnungen machen.
Wenn der Sichtradius 10 ist, musst du noch abfragen, ob der der da steht im Umfeld mehr/gleich 1 liegt und gleichzeitig weniger/mehr als 10.
Also alles mahl 2. Nun sind wir bei 800.
Für jede Himmelsrichtug 3200 Berechnungen.
Man brauch exakt 3 Variablen für ein Sichtradius :)
Hero X , Hero Y , Event Seiten ID bei in sichtfeld
nun prüft man ein script ob irgentein event mit einer ID über X auf einer passenden Koordinate ist , und sätz diese dann das Event auf seite 2 wo dann Alarm drin sein könnte.
Das ganze bräuchte am ende also nur 3 bzw. wenn man es über Temp. Vars lösen will 5 Variablen.Es sind insgesammt 10*10 also 100 Abfragen aber damit müsste ein guter rechner klarkommen.Ich habe ein Sichtfeld script so mit 5*5 gelöst und es ist Super flexibel.
Achja warum ID über X ? Wir haben nicht nur gegner als events im game ;)
Ich verstehe es nicht. Der Hero ist die Maus.
Also weis ich dann, nach dadie ob Einer unter meiner Maus steht :confused:
Oder meinst du mit , oder meinst du mit Hero y/x eine Einheit.
Dann weis ich das in der Nähe eines meiner Einheiten ein Gegner is, aber dann weis ich immer noch net genau wo. (welche Himmelsrichtung, welcher abstand).
Kannst du mir das bitte noch mal erklären. Ich weis nämlich nicht wie du auf drei Variabelen kommst. Mit fünf kann ichs noch nachvollziehen.
Phönix Tear
20.10.2005, 20:22
Hmm, wie du auf 3200 kommst weiß ich nicht so genau. Wollen wir nun einen Sichtradius der tatsächlich ein Sichtradius ist, oder ein Kasten der um die Einheit verläuft? Ein Sichtradius befände sich natürlich nur da wo der Gegner gerade hinschaut, der Kasten eben auf allen Seiten. Aber auch bei dieser Abfrage komme ich gerade mal auf 6 Variablen. Hier das Beispiel (Die Variablen "Gegnerdurchlauf 1/2" ist am Anfang natürlich auf 0):
<>Lable 1
<>Fork Variable "Gegnerdurchlauf 1", 0 same
<><>Change Variable "Angreifer X" [Armee 1 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 1 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 1", 1 same
<><>Change Variable "Angreifer X" [Armee 2 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 2 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 1", 2 same
<><>Change Variable "Angreifer X" [Armee 3 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 3 Y-Pos]
<>Else:
<>...
<>So jetzt weiter für alle Armeen
<>...
<>End:
<>Fork Variable "Gegnerdurchlauf 2", 0 same
<><>Change Variable "Verteidiger X" [Gegner 1 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 1 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 2", 1 same
<><>Change Variable "Verteidiger X" [Gegner 2 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 2 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 2", 2 same
<><>Change Variable "Verteidiger X" [Gegner 3 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 3 Y-Pos]
<>Else:
<>...
<>So jetzt weiter für alle Feinde
<>...
<>End:
<>Change Variable "Angreifer X" - "Verteidiger X"
<>Change Variable "Angreifer Y" - "Verteidiger Y"
<>Fork Variable "Anrgeifer X" < 0
<><>Change Variable "Angreifer X" * (-1)
<>End:
<>Fork Variable "Anrgeifer Y" < 0
<><>Change Variable "Angreifer Y" * (-1)
<>End:
<>Fork Variable "Angreifer X" < "Sichtradius"
<><>Fork Variable "Angreifer Y" < "Sichtradius"
<><><>Fork Variable "Gegnerdurchlauf 1", 0 same
<><><><>Change Variable "Gegnerdurchlauf 2" + 1
<><><><>Change Variable "Armee 1 Ziel" = "Gegnerdurchlauf 2"
<><><><>Change Variable "Gegnerdurchlauf 2" - 1
<><><>Else:
<><><>Fork Variable "Gegnerdurchlauf 1", 1 same
<><><><>Change Variable "Gegnerdurchlauf 2" + 1
<><><><>Change Variable "Armee 2 Ziel" = "Gegnerdurchlauf 2"
<><><><>Change Variable "Gegnerdurchlauf 2" - 1
<><><>Else:
<><><>Fork Variable "Gegnerdurchlauf 1", 2 same
<><><>...
<><><>So jetzt weiter für alle Armeen
<><><>...
<><><>End:
<><>End:
<>Fork Variable "Gegnerdurchlauf 2" < "Feinde auf dem Feld"
<><>Change Variable "Gegnerdurchlauf 2" + 1
<><>Goto Lable 1
<>Else:
<><>Fork Variable "Gegnerdurchlauf 1" < "Freunde auf dem Feld"
<><><>Change Variable "Gegnerdurchauf 1" +1
<><><>Goto Lable 1
<><>End:
<>End:
So, ich hoffe ich habe nichts vergessen ^^°. Je nachdem auf welcher Seite man schaut muss man nun einfach die Variablen von Freund und Feind vertauschen. Das sollte dann nicht so das Problem sein. Von dem kleinen Wörtchen "Gegnerdurchlauf" sollte man sich nicht verwirren lassen, es gibt beim ersten mal ("Gegnerdurchlauf 1") lediglich an von welcher eigenen Armee man nun die X bzw. Y Werte braucht. "Gegnerdurchlauf 2" beschreibt dann aber tatsächlich, welcher Gegner abgefragt wird.
Einziges Problem an dieser Taktik ist, das so nun (sollten alle Gegner in Reichweite sein) immer nur der letzte angegriffen wird. Eine direkte Abfrage wer nun näher ist, ist also nicht enthalten...
Ich hoffe mal Leute wie Lachsen lesen diesen Thread, denn die finden immer noch so einiges was man vereinfachen kann ;)
mfg
Phönix Tear
<>Var.Set:0001 Hero X : hero X
<>Var.Set:0002 Hero Y : Hero Y
<>Var.Set:0003 View_Side : 2
<>Var.Set:0004 Temp_X_View : 5
<>Var.Set:0005 Temp_Y_View : 5
<>Var.Set:0008 Temp_X : 0001 - 0004
<>Var.Set:0009 Temp_Y : 0002 - 0005
<>Var.Set:0010 Temp_X2 : 0
<>Var.Set:0011 Temp_Y2 : 0
<>Var.Set:0007 Ene_Event : 5
<>Cycle
<><>Event.-ID V[0008] V[0009] V[0006:Event-ID]
<><><>Fork.Varb[V0007:Ene_Event] < V[0006:Event-ID]
<><><><>Event.Call V[0006:Event-ID] V[0003:View_Side]
<><><>END.Fork
<><>Var.Set V[0008:Temp_X] : V[0008:Temp_X] + 1
<><>Var.Set V[0010:Temp_X2] : V[0010:Temp_X2] + 1
<><><>Fork.Varb[V0010:Temp_X2] = V[0004:Temp_X_View]
<><><><>Var.Set V[0008:Temp_X] : V[0008:Temp_X] - V[0004:Temp_X_View]
<><><><>Var.Set V[0009:Temp_Y] : V[0009:Temp_Y] + 1
<><><><>Var.Set V[0011:Temp_Y2] : V[0011:Temp_Y2] + 1
<><><>END.Fork
<><><>Fork.Varb[V0011:Temp_Y2] = V[0004:Temp_Y_View]
<><><><>Cycle.Stopp
<><><>END.Fork
<>Cycle.END
So siht in etwa da Code aus für eine abfrage um den Hero ob ein gegner da ist.Wenn ein gegner da ist wird überprüft ob es ein gegner ist mit hilfe der Event ID alle Events mit einer ID über 4 sind gegner.Nun wird dieses gegner event in den zweiten Modus gestartet über die Event seite die wir über :
<>Var.Set:0003 View_Side : 2 bestimmen.
Tja so einfach geht es :)
Gekiganger
21.10.2005, 01:31
Sicher ist ein Nachteil von Phönix Tears System, dass jede Einheit separat behandelt werden muss und der Code so mit jeder zusätzlichen Einheit anschwillt.
Da sieht dadies System dann doch viel übersichtlicher aus. Allerdings wird bei seinem System, bei einem 5x5 Felder großen Sichtfeld, ständig eine Fläche von 121 Felder durchgegangen, ohne dass sich darauf eine gegnerische Einheit befinden muss (die [0/x],[x/0],[0/0] Felder nicht vergessen!!).
(BTW dadie, schau mal die temporären Zähler an, die würden, so wie du es im Code angegeben hast, nach der 2. Zeile unendlich nach rechts wandern)
Hier werden wiederum bei Phönix's System nur die Einheiten, die auch wirklich existieren, berücksichtigt, was es, obwohl das Skript größer ist, gegenüber dadie's, performanter macht.
Und Performanz ist das, was man bei einem solchen Projekt am meisten beachten sollte.
Da beide Systeme ihre Vor- und Nachteile haben, schlage ich einen Mix aus beidem vor.
Es werden nicht die Felder, auf denen sich ein Event möglicherweiße befinden könnte abgefragt, sondern die Positionen der Einheiten direkt. Allerdings werden diese nicht statisch im Code angegeben, sondern auf sie wird verpointert.
Das ganze könnte so aussehen: <Parallel Process oder Autostart Event>
(wem es zu unübersichtlich ist, sollte die Kommentare herauslöschen)
//setzen: Eventbereich (Etart/Ende) der Einheiten
<>Variable Oper: [0001:$_fUnits startIndex] Set, 2
<>Variable Oper: [0002:$_fUnits endIndex] Set, 3
<>Variable Oper: [0003:$_eUnits startIndex] Set, 4
<>Variable Oper: [0004:$_eUnits endIndex] Set, 5
//setzen: Startpointer auf Einheitenkoordinaten
<>Variable Oper: [0012:$_fUnits Pointer] Set, 7
<>Variable Oper: [0013:$_eUnits Pointer] Set, 9
setzen: Koordinaten-Eventseite auf Einheiten
<>Variable Oper: [0014:$_units Coords Page] Set, 2
//setzen: sichtradius (quadratisch um Einheit)
<>Variable Oper: [0015:$_units Vision Size] Set, 5
//Zähler mit Startwerten initialisieren
<>Variable Oper: [0005:&_friendly index] Set, Var [0001:$_fUnits startIndex]'s Value
<>Variable Oper: [0006:&_enemy index] Set, Var [0003:$_eUnits startIndex]'s Value
//Zählschleife durch eigene Einheiten
<>Loop
//Zählschleife durch gegnerische Einheiten
<>Loop
//Pointer auf Koordinaten der eigenen Einheiten setzen
<>Variable Oper: [0011:%_units KoordsPointr] Set, Var [0012:$_fUnits Pointer]'s Value
//Koordinaten von eigener Einheit in Variablen, auf die Pointer referenziert, speichern
<>Call Event: V[0005:&_friendly index][V[0014:$_units Coords Page]]
//Pointer auf Koordinaten der gegnerischen Einheiten setzen
<>Variable Oper: [0011:%_units KoordsPointr] Set, Var [0013:$_eUnits Pointer]'s Value
//Koordinaten von gegnerischer Einheit in Variablen, auf die Pointer referenziert, speichern
<>Call Event: V[0006:&_enemy index][V[0014:$_units Coords Page]]
//Koordinaten gegnerischer Einheiten von Koordinaten eigener Einheiten abziehen, um Abstand zu ermitteln
<>Variable Oper: [0007:fUnit X] -, Var [0009:eUnit X]'s Value
<>Variable Oper: [0008:fUnit Y] -, Var [0010:eUnitY]'s Value
//negative Werte unerwünscht, daher auf absoluten Wert umwandeln
<>Branch if Var [0007:fUnit X] is 0 Less
<>Variable Oper: [0007:fUnit X] *, -1
: End
<>Branch if Var [0008:fUnit Y] is 0 Less
<>Variable Oper: [0008:fUnit Y] *, -1
: End
//prüfen, ob gegnerische Einheit im Sichtradius der eigenen Einheit liegt (==> ermittelter Abstand muss <= Sichtradius sein)
<>Branch if Var [0007:fUnit X] is V[0015:$_units Vision Size] Less/Equal
<>Branch if Var [0008:fUnit Y] is V[0015:$_units Vision Size] Less/Equal
//gegnerische Einheit wurde gesichtet
Message: Friend \v[5] (Event ID) spots Enemy \v[6] (Event ID)
: End
: End
//gegnerische Einheiten Zähler um 1 erhöhen
<>Variable Oper: [0006:&_enemy index] +, 1
//prüfen, ob gegnerische Einheiten Zähler letzten Gegner durchlaufen hat
<>Branch if Var [0006:&_enemy index] is V[0004:$_eUnits endIndex] Greater
//gegnerische Einheiten Zähler auf Startwert resetten und Zählschleife durch gegnerische Einheiten beenden
<>Variable Oper: [0006:&_enemy index] Set, Var [0003:$_eUnits startIndex]'s Value
<>Break Loop
: End
: End Loop
//eigene Einheiten Zähler um 1 erhöhen
<>Variable Oper: [0005:&_friendly index] +, 1
//prüfen, ob eigene Einheiten Zähler letzte eigene Einheit durchlaufen hat
<>Branch if Var [0005:&_friendly index] is V[0002:$_fUnits endIndex] Greater
//Zählschleife durch eigene Einheiten beenden
<>Break Loop
: End
: End Loop
Aufmerksame Leser werden sich nun fragen, woher denn die Koordinaten zu den Einheiten kommen.
Nun, diese werden im Event der Einheit direkt gesetzt.
Dazu wird im Event der Einheit eine neue Seite erstellt. Diese wird durch einen Switch gesperrt. Da dieser Switch nur zum Sperren dient und im Spiel NIEMALS angeschaltet wird, kann er ebenso für alle weiteren Eventseiten in anderen Events, die gesperrt bleiben sollen, verwendet werden.
Diese Seite enthält folgenden Code: <Push Key>
<>Variable Oper: [V[0011:%_units KoordsPointr]] Set, This Event X Coord.
<>Variable Oper: [0011:%_units KoordsPointr] +, 1
<>Variable Oper: [V[0011:%_units KoordsPointr]] Set, This Event Y coord.
So hat man sogar einen kleinen, objektorientierten Ansatz mit eingebracht, auch wenn das wohl eher eine Vergewaltigung des Begriffes ist. ^^'
Noch ein paar Erklärungen zu den Variablen:
0001:$_fUnits startIndex //Bereich eigener Einheiten (Index beschreibt Event ID) -> Startindex
0002:$_fUnits endIndex //Bereich eigener Einheiten (Index beschreibt Event ID) -> Endindex
0003:$_eUnits startIndex //Bereich gegnerischer Einheiten (Index beschreibt Event ID) -> Startindex
0004:$_eUnits endIndex //Bereich gegnerischer Einheiten (Index beschreibt Event ID) -> Endindex
0005:&_friendly index //Iterator, zählt von 0001:$_fUnits startIndex bis 0002:$_fUnits endIndex
0006:&_enemy index //Iterator, zählt von 0003:$_eUnits startIndex bis 0004:$_eUnits endIndex
0007:fUnit X //X Koordinate einer eigenen Einheit (in ihr wird auch Abstand zwischen eigener und gegnerischer Einheit gespeichert)
0008:fUnit Y //Y Koordinate einer eigenen Einheit (in ihr wird auch Abstand zwischen eigener und gegnerischer Einheit gespeichert)
0009:eUnit X //X Koordinate einer gegnerischen Einheit
0010:eUnitY //Y Koordinate einer gegnerischen Einheit
0011:%_units KoordsPointr //Pointer, über dessen Wert die Koordinaten der Einheiten in die jeweiligen Variablen geschrieben werden
0012:$_fUnits Pointer //Pointerstartbereich für die Koordinaten der eigenen Einheiten (0007:fUnit X)
0013:$_eUnits Pointer //Pointerstartbereich für die Koordinaten der gegnerischen Einheiten (0009:eUnit X)
0014:$_units Coords Page //Nummer der Eventseite in den Einheiten, in denen sich der Code zum setzen der Koordinaten befindet
0015:$_units Vision Size //quadratisch angegebene Größe des Sichtbereichs der Einheiten in Felder
Vorangestellte Zeichen:
$ = statisch (werden zur Laufzeit nicht mehr verändert)
% = Pointer/Zeiger
& = Index/Zähler/Iterator
Hat sich ja viel getan seit ich das letztemal in den Thread geguckt habe 8)
Mit sichtradius ist natürlich ein Kasten gemeint, also das die Einheit sozusagen auch nach hinten sieht, wäre ja Blöd wenn eine Einheit nicht regiert nur weil der Gegner hinte rihr ist :O
Da ja schon einige Scripte für einen Sichtradius gepostet worden sind, ist dieses Prolbem nun auch gelöst!
Wie findet ihr denn meinen Vorschlag für das KS den ich weiter oben schon gepostet habe? Also mit Pathfinding zu gegnerischen einheit -> angriff.
Wäre natürlich aufm XP besser umsetzbar!
Powered by vBulletin® Version 4.2.3 Copyright ©2025 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.