Technik - Was ist machbar?

[Macros]

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)

[Macros]

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?

[Gekiganger]

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.

[Ryo Saeba 1000]

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.

[Nevius]

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?

[Nevius]

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?)

[Phönix Tear]

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

[Nevius]

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.)

[Bauzi]

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?

[Nevius]

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

[Ryo Saeba 1000]

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 ).

...

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.

[Nevius]

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

[Gekiganger]

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)

[Nevius]

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 wie 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?

[DR_Zeph]

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

[WoOdY49]

ich glaub wir diskutierne nur aber ich fänds cool wenn was dabei rauskäm^^

[Phönix Tear]

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:

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

[Phönix Tear]

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 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).

[Nevius]

Wow, hätte nicht gedacht dass das so einfach ist , haste wirklich sehr gut gemacht! Also machen wir jetzt alle zusammen n kleines RTS? Wenn wäre das Rahmendings von Phönix doch besser

[DrateR]

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?