Sichtweitenberechnung

    Habe mir dazu folgendes überlegt:

    Ob man eine Armee sehen kann oder nicht hängt von folgender Formel ab:

    round(((1 / pow($armeegroesse,0.2)) * (1/$armeespeed) * ($armeeentfernung*4) * (1/$stadtaufmerksamkeit)),1);

    Anders geschrieben:

    (1 / Armeegröße ^ 0.2) * (1 / Armeegeschwindigkeit) * (Entfernung der Armee * 4) * (1 / Aufmerksamkeit der Stadt) = X

    Ist X kleiner gleich 1,5, ist die Armee zu sehen.

    Hab dazu mal ein kleines Testscript geschrieben:
    http://dev.openhope.de/sichttest.php
    Achso, das was Rot ist, wird gesehen. ;)

    Die Formel ist noch nicht final, liefert aber gute Werte.

    Das einzig schwierige wird sein, die Entfernung, bzw. die Stadt, zu der das Berechnet werden soll, zu bestimmen.
    Optimalerweise passiert sowas direkt in der DB.
    Um Performance zu sparen, kann ich mir vorstellen, das die Sichten nicht dynamisch, sondern vorab berechnet werden. Da ja alles tickbasiert ist, sollte das kein Problem sein, da das Spiel schon beim Berechnen des Ticks weiß, wo alle Armeen stehen werden.

    P.S. Zusätzlich gibt es eine Anzeige, wieviele Armeen sich in der Nähe der Stadt befinden. Das wird in etwa so aussehen: "Sire, wir haben keine/wenig/vermehrt/massiv/alarmierende Gerüchte von fremden Truppenbewegungen in der Nähe von <Stadtname> vernommen".
    Das soll verhindern, das findige Leute einfach alles splitten und erst kurz vor dem Ziel zusammenführen, auch wenn das trotzdem eine gute Taktik sein wird, da der Stadtbesitzer dann erstmal suchen gehen muss. ;)

    ich denke das ist sehr rechenintensiv. jedes mal wenn sich eine armee bewegt, musst du städte im radius der maximalen sichtweite (->fläche=40*40) neu berechnen lassen, ob die armee gesehen wird.
    in late-game mit vielen armeen und vielen städten könnte das sehr teuer werden ^^

    ausserdem finde ich 20 felder sichtweite recht fies für den angreifer ;)

    Edited once, last by Flunsi (May 6, 2007 at 9:46 AM).

    Denke nicht, das es so krass sein wird, besonders wenn das eben im Hintergrundjob mit erledigt wird.
    20 Felder ist auch das Maximum und betrifft ja nur die richtig großen Armeen und die will ich ja eh nicht fördern. ;)
    Allerdings denke ich, das ich es doch auf maximal 10 Felder reduzieren werde, alles andere wäre doch übertrieben. Dafür gibts ja dann eh die Sache mit den Gerüchten, wer da nicht selber aufklärt ist dann selber Schuld.
    Eigene Armeen haben auch nicht diesen großen Aufklärungskreis und Dörfer haben gar keine Sichtweite.

    Ich würde so etwas nicht grundlegendes viel später erst implementieren. Zunächst sollte es funktionieren, damit man einen realistischen Bezug erst geistig entwickeln kann.

    Code
    CREATE FUNCTION calcVisibility (armysize INT, armyspeed FLOAT, distance INT, cityalertness FLOAT) RETURNS FLOAT 
DETERMINISTIC 
NO SQL
RETURN ROUND(((1 / POW(armysize,0.25)) * (1/armyspeed) * (distance*4) * (1/cityalertness)), 1);


    SQL-Realisierung der Funktion

    mit stored procedure bin ich sehr vorsichtig...
    wenn man die logik an verschiedenen fronten hat, muss man gut aufpassen ;)

    sowas bau ich nur gezielt ein, wenn ich nen klaren performance-gewinn davon habe.
    und das wird sich erst im laufenden betrieb zeigen.

    Edited 2 times, last by Flunsi (May 9, 2007 at 8:46 AM).

    Ich will versuchen, die ganze Kartenabfrage in die DB zu verlegen, damit ich eben massiv Performance gewinne. Dann pflege ich das nur noch in der DB und nirgendwo sonst.
    Gebe ich dir dann gerne was ab davon. ;)

    Im Prinzip gehört die ganze Logik eh in die Datenbank. Warum soll ich mir Daten holen, die ich nicht brauche, wenn die DB mir gleich nur die benötigten Daten liefern kann?

    der hauptteil der arbeit muss ja sowieso gemacht werden. ob das jetzt der db-server oder appl-server ist (falls sie getrennt sind ^^), spielt eigentlich keine rolle.
    ich bin da einfach zuwenig in der materie drin um genau sagen zu können, was wieviel performance-gewinn bringt. man kann sich nämlich auch irren und dann hat man das geschenkt ;)

    deshalb hab ich bei mir eine stats-seite eingerichtet, bei der man sehen kann, welches script wieviel performance frisst. wenn sich ein script abhebt, geh ich dort über die bücher und mache wenn nötig auch ein refactoring. aber bis es soweit ist, lass ich mich davon nicht abhalten ^^

    So, die Kartenerstellung passiert nun in der DB:
    http://trac.openhope.de/trac/browser/d…ap_function.sql

    Das ersetzt nun:
    http://trac.openhope.de/trac/browser/f…map.inc.php#L98

    Was da nun fehlt, ist die Ermittlung der sichtbaren Armeen. Ich denke, dass das vorab berechnet wird und da dann nur noch ein weiterer Join passiert. Sollte diese Woche noch drin sein.
    Dazu will ich diese Woche die Armeeerstellung fertig stellen und evt. auch das Marschsystem implementieren, mal gucken. Und soviel davon in der DB wie nur möglich. ;)

    Ich möchte anmerken, das ich auf diese SQL-Anweisung recht stolz bin. :D