MidWar [Midgard Kampfsimulator]

[Bernward]

Sieht so aus als ob es wirklich der "kürzeste" Weg wäre. Denn die Midgard Regeln bestrafen die Diagonale nicht mit dem Faktor 1.41.

[Mav3N]

Es gab wirklich einen Fehler in meiner astar.php, bei dem ich vergaß Vorgängerknoten zu aktualisieren. Das Problem ist nun dank Hilfe eines sehr erfahrenen Programmierers gelöst. Astar funktioniert, ich werde es nun mit der restlichen Codebibliothek zusammenfügen - bald können unsere Kämpfer auch auf Karten laufen.

[Mav3N]

So, hab jetzt endlich Version 2.0 fertig. Größte Veränderung ist natürlich die Möglichkeit, dass sich Spielerfiguren wie auf einem Schachbrett bewegen können und sich Wege anhand des A* Algorithmus suchen. Ich lade derzeit alle Daten von piranho auf Lima-city.de - der Server ist besser.

 

http://midwar.lima-city.de/V2.0/insert.php

 

Das ist erstmal gerade die Adresse. Folgende Features unterstützt der Simulator nun:

 

- Angreifen
- Abwehren 
- Abwehren nicht erlaubt wenn Verteidiger 0 AP hat
- Schadenkalkulation
- Kampfunfähig ab 3 LP
- Rüstung
- Nicht unter 0 AP erlaubt
- Minus 2 auf Angriffe wenn Angreifer LP/2 hat
- Minus 4 auf Angriffe wenn Angreifer 0 AP hat
- Plus 4 auf Angriff, wenn Verteidiger 0 AP hat
- Anzeige wer gestorben / Kampfunfähig ist
- Namensgebung möglich
- Zufällige Gegnerwahl
- Kampfinformationen ausschaltbar
- Rundenanzeige
- Statistikkampf
- Inputüberprüfung
- Standardbelegungen für Kämpfer
- Rundenkampf
- Kämpfer können sich bewegen, suchen selbstständig Wege zum Ziel
- Bewegungsweite
- -6 auf EW:Angriff, wenn diese Runde mehr als die Hälfte der Bewegungsweite verbraucht wurde
- -2 auf den EW:Verteidigung, wenn diese Runde mehr als die Hälfte der Bewegungsweite verbraucht wurde
- Positionsanzeige

 

ACHTUNG: Es gibt in dieser Version, weil sich intern im Quellcode immens viel geändert hat, noch einige Probleme.

 

1. Die Eingaben für die X,Y und B Werte in insert.php werden noch nicht überprüft! Hierüber sind derzeit noch Attacken möglich (Ich glaube aber mal nicht, dass sich ein Midgard-Spieler dazu durchringt ) Bitte achtet darauf, dass ihr vernünftige Werte eingebt.

2. Die Gegnerauswahl ist derzeit IMMER NOCH per Zufall, erst in der nächsten Version werde ich hinzufügen, dass er sie sich anhand des Kriteriums der Entfernung aussucht. Trotz alledem suchen sich die Spieler nun den richtigen Weg auf dem Schachbrett, gehen ihn und greifen dann an.

 

Und ganz besonders wichtig: Derzeit lasse ich einen Spieler seine kompletten Aktionen ausführen und erst dann den nächsten Spieler. Das muss ich noch ändern. Es soll am Ende so ablaufen, dass Spieler 1 einen Schritt geht, dann Spieler 2 einen Schritt seines Weges, etc. Schließlich soll das ganze ja möglichst dem Begriff der Gleichzeitigkeit nahekommen. Derzeit läuft ein Spieler leider erst seinen ganzen Weg, greift dann an, und dann ist der nächste dran. Da hab' ich noch eine Menge zutun.

 

Bitte fleißig Fehler suchen, ich vermute, dass eine ganze Menge drinnen sind, da ich so ziemlich die Hälfte des Simulators intern umschreiben musste.

 

Bamba (Ich schaff' das noch alle M4 Regeln umzusetzen!)

[sayah]

Es hat sich ein Fehler bei der Schadensberechnung eingeschlichen: meine Kämpfer hatten Lederrüstungen, aber egal wieviel Schaden der Gegner anrichtet, es wurde immer 0LP Schaden verrechnet.

es grüsst

Sayah el Atir al Azif ibn Mullah

[Mav3N]

Alle Versionen sind auf lima hochgeladen und unter http://midwar.de.vu/ erreichbar.

 

Bamba

[Mav3N]

Es hat sich ein Fehler bei der Schadensberechnung eingeschlichen: meine Kämpfer hatten Lederrüstungen, aber egal wieviel Schaden der Gegner anrichtet, es wurde immer 0LP Schaden verrechnet.

es grüsst

Sayah el Atir al Azif ibn Mullah

 

Ich weiß nicht, was du eingegeben hast, bei mir funktioniert das alles.

 

EDIT: Alle Fehler, die ihr findet bitte mit Screenshot hier posten!

Bearbeitet 16. April 2010 von Bamba

[sayah]

Ich habe auf deinen Link geklickt. 3 Teams erstellt mit je einem Kämpfer:

Kampfinformationen:

�berlebende:

Name ID LP AP Schaden Team Angriffswert Verteidigungswert R�stung Status X Y B

Person_1 1 12 10 1W6 1 5 12 Lederr�stung Unbeeintr�chtigt 1 1 3

Person_2 2 12 10 1W6 2 5 12 Lederr�stung Unbeeintr�chtigt 9 9 4

Person_3 3 12 10 1W6 03 5 12 Lederr�stung Unbeeintr�chtigt 9 1 9

Runde: 1

Anzahl verschiedener Teams: 3

Person 1 sollte ein Oger ab drop down liste sein, wurde nicht übernommen.

"Person_1 mit der ID 1 geht 4 auf Feld 5,3, kann diese Runde aber nicht angreifen, da er diese Runde nicht gen�gend weit gehen konnte." macht keinen Sinn.

"Person_2 mit der ID 2 erzielt 24 und hat Person_1 mit der ID 1 getroffen. Person_1 mit der ID 1 erzielt 22, kann nicht abwehren, erh�lt 4 Schadenspunkte und verliert 0 LP und 4 AP."

Das ist ein schwerer Treffer, die Rüstung sollte LR sein also müssten 2 LP Schaden verrechnet werden.

da so natürlich niemand stirbt endet die Simulation irgendwann mit dem entsprechenden Fehler.

es grüsst

Sayah el Atir al Azif ibn Mullah

[bluemagician]

1. Die Eingaben für die X,Y und B Werte in insert.php werden noch nicht überprüft! Hierüber sind derzeit noch Attacken möglich (Ich glaube aber mal nicht, dass sich ein Midgard-Spieler dazu durchringt ) Bitte achtet darauf, dass ihr vernünftige Werte eingebt.

Wobei X und Y die Startposition angeben (X=0, Y=0 entspricht links oben) und B die Bewegungsweite ist. Ist es Absicht, dass man für die drei Werte maximal eine einstellige Zahl eingeben kann?

 

Und ganz besonders wichtig: Derzeit lasse ich einen Spieler seine kompletten Aktionen ausführen und erst dann den nächsten Spieler. Das muss ich noch ändern. Es soll am Ende so ablaufen, dass Spieler 1 einen Schritt geht, dann Spieler 2 einen Schritt seines Weges, etc.

D.h. du willst zunächst die sekundengenauen Regeln zur Abwicklung einer Kampfrunde umsetzen? Wäre es nicht sinnvoll, erstmal die 10-Sekunden Runde zu implementieren?

 

Was mir noch aufgefallen: Es wäre schön, wenn man einstellen könnte, wie riskant ein Kämpfer kämpfen soll, d.h. ob er z.B. einen überstürzten Angriff macht oder nicht.

 

Screenshots für Fehler sind etwas schwierig, da man hier im Forum als normaler Nutzer keine Bilder anhängen kann. Vielleicht überlegst du dir noch einen Debug-Modus, der ein Text-Debuglog erzeug, das man dann hier posten kann.

 

CU

FLo

[Mav3N]

Bin dabei die Fehler zu suchen, demnächst gibt es eine Fehlerbereinigte neue Version.

 

Ich hab an Elsa eine PN geschickt, in der ich sie darum bitte den Simulator, nachdem ich noch ein wenig Funktionen zur Sicherheit hinzugefügt habe, auf die offizielle Seite zu nehmen. Ich fände es gut, wenn sie sich hier dazu äußert, dann können alle mitdiskutieren.

 

Bamba

[Branwen]

Und wozu soll ich mich äußern?

[Mav3N]

Und wozu soll ich mich äußern?

 

Zum Beispiel darüber, ob du den Simulator auf die offizielle Seite aufnehmen möchtest und wie. Ich hab dir ja bereits gesagt, dass die FreeServer auf denen ich ihn gerade lager nicht gerade die beste Performance haben und somit eine Simulation seeehr lange dauern kann, bisweilen gar nicht geht. Bei dir dürfte das besser sein. Das ist einer der Gründe warum ich ihn auf der offiziellen Seite haben möchte.

 

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

 

Also zusammengefasst: Nenn mir (uns) mal bitte deine Bedingungen, damit er aufgenommen werden würde. Vllt. kann ich Einwände mit Hilfe anderer Programmierer hier entkräften.

 

Bamba

[Mav3N]

Ich habe auf deinen Link geklickt. 3 Teams erstellt mit je einem Kämpfer:

Kampfinformationen:

�berlebende:

Name ID LP AP Schaden Team Angriffswert Verteidigungswert R�stung Status X Y B

Person_1 1 12 10 1W6 1 5 12 Lederr�stung Unbeeintr�chtigt 1 1 3

Person_2 2 12 10 1W6 2 5 12 Lederr�stung Unbeeintr�chtigt 9 9 4

Person_3 3 12 10 1W6 03 5 12 Lederr�stung Unbeeintr�chtigt 9 1 9

Runde: 1

Anzahl verschiedener Teams: 3

Person 1 sollte ein Oger ab drop down liste sein, wurde nicht übernommen.

"Person_1 mit der ID 1 geht 4 auf Feld 5,3, kann diese Runde aber nicht angreifen, da er diese Runde nicht gen�gend weit gehen konnte." macht keinen Sinn.

"Person_2 mit der ID 2 erzielt 24 und hat Person_1 mit der ID 1 getroffen. Person_1 mit der ID 1 erzielt 22, kann nicht abwehren, erh�lt 4 Schadenspunkte und verliert 0 LP und 4 AP."

Das ist ein schwerer Treffer, die Rüstung sollte LR sein also müssten 2 LP Schaden verrechnet werden.

da so natürlich niemand stirbt endet die Simulation irgendwann mit dem entsprechenden Fehler.

es grüsst

Sayah el Atir al Azif ibn Mullah

 

Hallo,

 

es gibt genau 2 Fehler wie es scheint bei deinen Werten und Eingaben. Ein Fehler hat mit dem A* Algorithmus zu tun, den ich gefunden und behoben habe - ich lade die Verbesserung bald hoch. Der andere Fehler (?) scheint sich um die Schadens und Lebenspunkte zu drehen. Das Problem ist, dass es mir nicht gelingt ihn mit deinen Eingaben nachzustellen und zu reproduzieren. Nenn mir daher bitte andere Konstellationen und die komplette Anzeige sowie alle eingegebenen Werte bei denen der Fehler auftritt. Sonst kann ich ihn nicht finden, sofern er existiert.

 

Bamba

[Mav3N]

1. Die Eingaben für die X,Y und B Werte in insert.php werden noch nicht überprüft! Hierüber sind derzeit noch Attacken möglich (Ich glaube aber mal nicht, dass sich ein Midgard-Spieler dazu durchringt ) Bitte achtet darauf, dass ihr vernünftige Werte eingebt.

Wobei X und Y die Startposition angeben (X=0, Y=0 entspricht links oben) und B die Bewegungsweite ist. Ist es Absicht, dass man für die drei Werte maximal eine einstellige Zahl eingeben kann?

 

Und ganz besonders wichtig: Derzeit lasse ich einen Spieler seine kompletten Aktionen ausführen und erst dann den nächsten Spieler. Das muss ich noch ändern. Es soll am Ende so ablaufen, dass Spieler 1 einen Schritt geht, dann Spieler 2 einen Schritt seines Weges, etc.

D.h. du willst zunächst die sekundengenauen Regeln zur Abwicklung einer Kampfrunde umsetzen? Wäre es nicht sinnvoll, erstmal die 10-Sekunden Runde zu implementieren?

 

Was mir noch aufgefallen: Es wäre schön, wenn man einstellen könnte, wie riskant ein Kämpfer kämpfen soll, d.h. ob er z.B. einen überstürzten Angriff macht oder nicht.

 

Screenshots für Fehler sind etwas schwierig, da man hier im Forum als normaler Nutzer keine Bilder anhängen kann. Vielleicht überlegst du dir noch einen Debug-Modus, der ein Text-Debuglog erzeug, das man dann hier posten kann.

 

CU

FLo

 

Das mit den Screenshots ist klar, deswegen bitte immer Eingaben und den gesamten Ausgaben Text bei Fehler mit Fehlerbeschreibung posten.

 

Deine Anregung, dass man einstellen kann, wie riskant ein Kämpfer kämpfen soll, ist bereits auf meiner Todo-Liste und wir demnächst umgesetzt. Ich werde übrigens erstmal die sekundengenauen Regeln umsetzen, und auf Basis dessen die 10-Sekunden Regel anbieten.

 

Ja, im moment ist es noch gewollt, dass man nur einstellige Werte (B kann zweistellige Werte annehmen) einstellen kann. Das hängt damit zusammen, dass nach der Umstellung intern einiges nicht mehr funktionierte und ich mehrstellige X und Y Eingaben derzeit noch nicht erlauben kann.

 

Bamba

[obw]

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

Wie effizient sind die von dir verwendeten Algorithmen? A* hat entweder O(N^2) oder O(N * log(N)), je nach Implementierung. Weitere? Ich bin mir auch nicht sicher, ob die Heuristik für bewegte Kontrollbereiche über eine Runde hinaus monoton ist, das will der Algorithmus aber.

 

Wie wertest Du die übergebenen Parameter aus? Ohne Code Review wird das wohl nix.

[theschneif]

 

EDIT: Alle Fehler, die ihr findet bitte mit Screenshot hier posten!

 

Hallo - ich finde es schade, dass Rundumschläge, beidhändiger Kampf, Fechten, aber auch Pimpzauber wie Bärenwut offenbar nicht abzubilden sind.

 

Denn der echte Charme des Simulators liegt doch darin, ein Gefühl dafür zu kriegen, wann sich eine Spielerfigur noch einer Übermacht stellen kann und wann man besser die Beine in die Hand nehmen sollte.

 

Greetz Schneif

[Branwen]

Zum Beispiel darüber, ob du den Simulator auf die offizielle Seite aufnehmen möchtest und wie. Ich hab dir ja bereits gesagt, dass die FreeServer auf denen ich ihn gerade lager nicht gerade die beste Performance haben und somit eine Simulation seeehr lange dauern kann, bisweilen gar nicht geht. Bei dir dürfte das besser sein. Das ist einer der Gründe warum ich ihn auf der offiziellen Seite haben möchte.

Ich habe keine Ahnung vom Programmieren etc. D.h. es muss anders herum laufen. Du sagst mir, was Du gerne hättest und ich lasse schauen, ob sich das bei einem vertretbaren Aufwand realisieren lässt.

[Mav3N]

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

Wie effizient sind die von dir verwendeten Algorithmen? A* hat entweder O(N^2) oder O(N * log(N)), je nach Implementierung. Weitere? Ich bin mir auch nicht sicher, ob die Heuristik für bewegte Kontrollbereiche über eine Runde hinaus monoton ist, das will der Algorithmus aber.

 

Wie wertest Du die übergebenen Parameter aus? Ohne Code Review wird das wohl nix.

 

Nun zur Komplexität des A* (der in meinem Script mit Abstand der am meisten Performance und Speicherfressende Algorithmus ist), kann ich nur sagen: Keine Ahnung! Ich hab mir den PseudoCode auf der Wikipediaseite angeguckt und einfach in PHP runtergescriptet. Den Code hast du in den vorherigen Beiträgen. Gut programmiert habe ich ihn nicht, aber er funktioniert mittlerweile. Alle meine Messungen lagen aber bei 10x10 Feldern immer unter 15ms.

 

Andere Algorithmen habe ich nicht verwendet, ich habe mich an assoziative 2D Arrays gewöhnt, die ich immer und überall verwende. Diese verbrauchen denke ich auch eine ganze Menge Speicher in meiner fight.php, der Rest ist billiger Kinderkram if($actualChance + $Random >= 20) { ... } etc.

 

Dementsprechend wäre der A* das performancefressendste Konstrukt in meinem Code, gefolgt von sehr großen, häufig verwendeten 2D Arrays. Mehr nicht. (Beim Statistikkampf wird die Situation 100mal durchsimuliert und der Mittelwert genommen). Das wären im schlimmsten Fall 100 * 15ms (astar.php) + 100 * 2ms (fight.php). Ich denke aber daran das demnächst auf 1000 Durchläufe anzuheben. Außerdem werde ich demnächst alles Sekundengenau berechnen, was nochmal den Aufwand in der fight.php um den Faktor 10 anhebt. Im Endausbau sollte das ganze also 1000 * 15ms + 1000 * 20ms = 35 Sekunden für einen Statistikkampf verbrauchen. (Werte richten sich für 10x10 Felder und ca. 5 Kämpfer in 2 Teams). Bei größeren Feldern und mehr Kämpfern steigt das ganze exponential.

 

Bei allen Freehostern hast du ein execution time limit von meist unter 30 Sekunden. Also sehr, sehr wenig. Bei 100 Durchläufen ist das zwar noch machbar aber es wird knapp, wenn ich anfange sekundengenau zu simulieren. Das ganze Skript muss auf einen Server, der diese Beschränkung nicht hat (Elsa könnte das auf ihrem einstellen lassen denke ich) und der bessere Performance besitzt - ich mir die Performance nicht mit X Nutzern beim Freehoster teilen muss.

 

An Elsa: Ich möchte einfach die fight.php, astar.php und insert.php auf deinem Server hosten, nachdem ich nochmal die Sicherheit des Skriptes überarbeitet habe und hoffe dadurch die Beschränkungen der Freehoster zu übergehen.

 

Sicherheitstechnisch kann ich sagen, dass es ja alles von den Eingaben in der insert.php abhängt. Deswegen baue ich die Überprüfungen auch gerade Serverseitig und nicht Clientseitig auf. Derzeit ist es noch clientseitig. Diese könnte man nämlich umgehen, indem man sein eigenes JS Script anstelle von meinem platziert. Wenn die Eingaben abgesichert und überprüft sind, sehe ich kein Problem mehr. Sehr ihr erfahreneren Programmierer das ebenso?

 

Elsa kann nur 2 Probleme bekommen: Sicherheitstechnisch (s. oben) und Performancetechnisch. Es würden Spitzen auftreten, in denen die CPU des Servers stark belastet ist. Diese würden bis zu 10 Sekunden andauern. Daran kann man aber nichts ändern.

 

Jetzt bitte alle erfahrenen Progger äußern.

 

Bamba

[Mav3N]

 

EDIT: Alle Fehler, die ihr findet bitte mit Screenshot hier posten!

 

Hallo - ich finde es schade, dass Rundumschläge, beidhändiger Kampf, Fechten, aber auch Pimpzauber wie Bärenwut offenbar nicht abzubilden sind.

 

Denn der echte Charme des Simulators liegt doch darin, ein Gefühl dafür zu kriegen, wann sich eine Spielerfigur noch einer Übermacht stellen kann und wann man besser die Beine in die Hand nehmen sollte.

 

Greetz Schneif

 

Das kommt doch alles noch.

 

Denk mal bitte nach: Für Rundumschläge und dergleichen, muss der Simulator doch mit Positionen rechnen, damit er simulieren kann, wer um einen rumsteht und ebenfalls getroffen wird... Das habe ich gerade erst hinzugefügt und bin noch am Fehler suchen ... Alle von dir aufgeführten Sachen werden noch kommen, allerdings benötige ich dafür viel, viel, sehr viel Zeit!

 

Bamba

[Solwac]

PHP ist für eine Simulation (die dann auch noch x Mal gemittelt werden soll) ziemlich ungünstig.

 

Wenn Du etwas haben möchtest, was online verteilt werden kann und keine Rücksicht auf eine bestimmte Plattform nimmt, dann programmiere es in Java. Jeder nutzt dann seinen eigenen Rechner und kann selber bestimmen, wann er Pause macht...

 

Noch mehr Performance würde natürlich C/C++ liefern, aber da gibt ein Programm für eine bestimmte Plattform.

 

Wenn A* so viel Zeit braucht, dann könnte auch eine Hashfunktion helfen. Damit würden bereits berechnete Pfade für ein bestimmtes Spielfeld nicht immer neu berechnet werden.

[sayah]

Ich habe diese Fehler auch nicht mehr reproduzieren können... spricht man davon und voila:

System: Mac, 3 Personen 3 Teams, Bewegungsweite 3, Person 1&3 Oger aus dropdown liste (wird nicht übernommen) und es werden keine LP Schäden verrechnet. Selbe Einstellungen, PC, Vista, funktioniert.

Dafür hatte ich in einem anderen run folgendes Problem: 3 Kämpfer in 3 Teams Alles Standardkämpfer mit Bewegungsweite 3. Als die mittlere Person starb bekämpften sich die Ueberlebenden munter weiter, blieben aber auf ihren Positionen stehen und standen im Rösselsprung entfernt damit eigentlich ausserhalb der Reichweite eines Nahkampfangriffs.

Eines noch, zu deiner Berechung der Rechenzeiten: Man het eine Bewegungsweite von rund 20-30. Damit ist ein vernünftiggrosser Kampfplatz wohl auf einem Feld 100x100 anzusiedeln (den man in 3-5 Runden durquert) oder besser grösser, was wohl den Rechenaufwand deines Wegsuchealgorhytmus deutlich erhöht. Nicht?

es grüsst

Sayah el Atir al Azif ibn Mullah

Bearbeitet 19. April 2010 von sayah

[obw]

Alle meine Messungen lagen aber bei 10x10 Feldern immer unter 15ms.

Nimm mal 100x100, das liegt näher an der Midgard-Realität.

 

Im Endausbau sollte das ganze also 1000 * 15ms + 1000 * 20ms = 35 Sekunden für einen Statistikkampf verbrauchen. (Werte richten sich für 10x10 Felder und ca. 5 Kämpfer in 2 Teams). Bei größeren Feldern und mehr Kämpfern steigt das ganze exponential.

Also O(N^2). Man lässt auch keine Anwendungen, die 35 s CPU-Zeit verbrauchen, als Webanwendung laufen. Wenn das jemand laufen lässt, der nicht genau weiß, was im Hintergrund abläuft, bricht er ab und drückt 'reload'...

 

Sicherheitstechnisch kann ich sagen, dass es ja alles von den Eingaben in der insert.php abhängt. Deswegen baue ich die Überprüfungen auch gerade Serverseitig und nicht Clientseitig auf.

Was man auf die Welt loslässt, das hat server side input sanitation. Sorry, ich denglische jetzt. Dein Programm sieht nur einen GET oder POST request, wer es aufruft, muss irgendwelche Eingabeseiten niemals gesehen haben. Das hat nichts mit Javascript oder nicht zu tun.

 

Verwende $_POST[] und $_GET[] für Parameter.

 

Verwende Methoden, um Datentypen festzuzimmern. Casts, Typumwandlungsmethoden in PHP,...traue keinem Input.

 

So große Simulationen mit mehr als 10s Walltime haben als Webapp eigentlich nix verloren.

[Mav3N]

PHP ist für eine Simulation (die dann auch noch x Mal gemittelt werden soll) ziemlich ungünstig.

 

Wenn Du etwas haben möchtest, was online verteilt werden kann und keine Rücksicht auf eine bestimmte Plattform nimmt, dann programmiere es in Java. Jeder nutzt dann seinen eigenen Rechner und kann selber bestimmen, wann er Pause macht...

 

Noch mehr Performance würde natürlich C/C++ liefern, aber da gibt ein Programm für eine bestimmte Plattform.

 

Wenn A* so viel Zeit braucht, dann könnte auch eine Hashfunktion helfen. Damit würden bereits berechnete Pfade für ein bestimmtes Spielfeld nicht immer neu berechnet werden.

 

Hallo,

 

PHP ist nunmal die einzige, die ich wirklich gut genug kann, um soetwas zu erstellen. Außerdem mag ich Java nicht. Mir ist gerade aufgefallen, dass ich ja mit Zend dem ganzen noch einen ordentlichen Performanceboost geben kann - ich glaube das werde ich tun. Mal sehen wie es dann steht. Hashfunktion? Geht nicht! Jedes Ziel ist beweglich und ändert sich fast jede Runde... Bereits berechnete Pfade fallen sofort wieder weg. Lass mich mal A* in zend auslagern, dann dürfte das ganze ein wenig schneller laufen.

 

Bamba

 

@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

[obw]

PHP ist nunmal die einzige, die ich wirklich gut genug kann, um soetwas zu erstellen.

Wenn man einen Hammer hat, sieht jedes Problem wie ein Nagel aus...

 

Außerdem mag ich Java nicht.

Was sehr interessant ist, weil PHP seit Version 5 da viel übernommen hat.

 

Mir ist gerade aufgefallen, dass ich ja mit Zend dem ganzen noch einen ordentlichen Performanceboost geben kann - ich glaube das werde ich tun.

Nimm lieber HipHop - das haben die Facebook-Leute entwickelt und hält sie am Laufen.

 

@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

[Solwac]

@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Was passiert eigentlich, wenn zwei oder noch mehr Leute gleichzeitig etwas machen wollen?

 

Bei jedem Aufruf erst einmal 30s Rechenzeit zu verbraten ist keine gute Idee für einen Server, der auch noch andere Aufgaben erfüllen soll.

 

Solwac

[Mav3N]

So, V2.0.1 ist fertig (Fehlerbehebungen, neues Design, verbessertes Output, Forschrittsanzeige).

 

Ich hab die beiden Fehler bei der Wegberechnung, die sayah genannt hat korrigiert. Den Fehler, dass keine LP abgezogen werden, finde ich nicht und kann ich nicht rekonstruieren. Vllt. ist er jetzt weg? Ich weiß es nicht - bitte einfach weiter beobachten. Außerdem hab ich den Fehler mit den JavaScript Dropdownlisten (diese Dinger wo man einen Orc oder einen Oger übernehmen kann) behoben - sie müssten jetzt endlich wieder funktionieren. Das neue Design ist aus einem Oblivionfanpackage - man darf es überall verwenden. Wie obw schon sagte sind "Fortschrittsanzeigen bei Webanwendungen ... sportlich". Aber ich hab's trotzdem geschafft. So weiß man wenigstens wie lange der noch ca. braucht. Was das verbesserte Output angeht, hab ich mal die Ausgabemeldungen ein wenig überarbeitet - müsste jetzt verständlicher sein.

 

Was ich noch nicht geschafft habe, aber als nächstes kommt ist endlich eine Serverseitige Überprüfung der Eingaben (und damit auch eine Überprüfung der X,Y und B Eingaben, die immer noch nicht überprüft werden), sowie die Möglichkeit, dass man einstellen kann wie Groß das Feld sein soll.

 

Wir haben nach wie vor das Problem, dass alles über einen Freeserver läuft, bei dem die Maximum Execution time extrem niedrig liegt. Der Berechnungsaufwand ist einfach zu hoch. Das führt dazu, dass man derzeit keine wirklich großen Kämpfe berechnen kann - es wird zu früh abgebrochen ... Daher hatte ich mich ja an Elsa gewandt. UPDATE: Mir fällt gerade auf, dass der Fortschrittsbalken auf dem Freeserver nicht läuft, was an HipHop bei Lima liegen dürfte. Irgendeiner der Programmierer hier eine Ahnung was man da machen könnte?

 

Hm gut, ich hab jetzt glaube ich alles erwähnt.

 

Bitte Fehler suchen

Bamba

 

P.S: Die Subdomain http://www.midwar.de.vu von nic.de.vu hat gerade mal wieder Probleme (ja auch ein Freeservice...) daher solltet ihr über die richtige Adresse http://midwar.lima-city.de/ gehen.