Ok, is deine Meinung.Zitat
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?
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!
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.
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.Wäre aber nicht so toll, da man dann immer nur einheiten an den "Rand" des momentanen Blickfeld schicken müsste!
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?)
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.
--The illusion or impression of never having experienced something
that has actually been experienced many times before
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?
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).
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.
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...
Geändert von Nevius (18.10.2005 um 08:18 Uhr)
Du täuschst, da Chars im 2k/2k3 eine größe von 32x24 haben können (Höhe x Breite).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
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:
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.
--The illusion or impression of never having experienced something
that has actually been experienced many times before
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
Geändert von Nevius (18.10.2005 um 15:08 Uhr)
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)
Geändert von Gekiganger (18.10.2005 um 18:15 Uhr)
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 ganzwie willste das scripten? Also ich denke mit meinem System sind wir gut bedient
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?
Geändert von Nevius (18.10.2005 um 18:27 Uhr)
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^^
Ich habs getstet und ich denke, dass das wohl die beste Methode ist. Habe jedenfalls keine Mängel festgestellt.
Tolle Arbeit.
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.
Geändert von Macros (18.10.2005 um 21:37 Uhr)
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...
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:
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:
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.
Geändert von Macros (19.10.2005 um 00:19 Uhr)
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!
Berechtigungen
Zitieren
