Seite 5 von 5 ErsteErste 12345
Ergebnis 81 bis 98 von 98

Thema: Technik - Was ist machbar?

  1. #81
    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).

    Geändert von Phönix Tear (20.10.2005 um 00:38 Uhr)

  2. #82
    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

  3. #83
    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?

  4. #84
    Ok, habe mir das Script angeschaut und muss zugeben dass es wirklich bessr ist.

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

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

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

    PS: Hab doch noch n nachteil in deinem Rahmen gefunden: Er braucht 3 Pictures mehr Is aber trotzdem besser

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

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

    Geändert von Macros (20.10.2005 um 10:58 Uhr)

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

  9. #89
    Ist es eigentlich möglich jede Taste des Keyboards in den RPG-Maker XP einzubeziehen?
    (Hab gedacht passt ganz gut zum Thema...)

    Geändert von Baka-Chen (20.10.2005 um 12:30 Uhr)

  10. #90
    Zitat Zitat
    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.

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

    Geändert von Macros (20.10.2005 um 14:45 Uhr)

  11. #91
    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

  12. #92
    Zitat Zitat
    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.

    Geändert von Macros (20.10.2005 um 17:57 Uhr)

  13. #93
    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

  14. #94
    Ich verstehe es nicht. Der Hero ist die Maus.
    Also weis ich dann, nach dadie ob Einer unter meiner Maus steht
    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.

    Geändert von Macros (20.10.2005 um 18:34 Uhr)

  15. #95
    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):
    Code:
    <>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

    Geändert von Phönix Tear (20.10.2005 um 21:27 Uhr)

  16. #96
    Code:
    <>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

  17. #97
    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)
    Code:
    //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>
    Code:
    <>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:
    Code:
    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

  18. #98
    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

    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!

Berechtigungen

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