Angriffe optimiert realisieren

Hallo Leute,
ich habe irgendwie probleme beim berechnen der angriffe in einem query
in einer schleife die immer wieder einen query nachm nächsten erstellt ist meiner meinung einfach sch**** , denn dadurch geht der MySQL - Server zu grunde
zumindest denke das das die beste lösung wäre aber hm es funktioniert nich so wie ich es will
Die Tabelle:

CREATE TABLE `feldzug` (

`feldzug_id` int(10) unsigned NOT NULL auto_increment,
`feldzug_von_stadt_id` smallint(5) unsigned NOT NULL,
`feldzug_an_stadt_id` smallint(5) unsigned NOT NULL,
`ein_panzer` smallint(5) unsigned default NULL,
`ein_soldaten` smallint(5) unsigned default NULL,
`ein_swat` smallint(5) unsigned default NULL,
`ankunft_in` int(10) unsigned default NULL,
`zurueck_in` int(10) unsigned default NULL,
`heimweg` tinyint(1) NOT NULL default '0',
`res_kohle` smallint(5) unsigned default NULL,
`res_stein` smallint(5) unsigned default NULL,
`res_eisen` smallint(5) unsigned default NULL,
`besiegt` tinyint(1) NOT NULL default '0',
PRIMARY KEY (`feldzug_id`,`feldzug_von_stadt_id`,`feldzug_an_stadt_id`),
KEY `feldzug_FKIndex1` (`feldzug_von_stadt_id`),
KEY `feldzug_FKIndex2` (`feldzug_an_stadt_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=17 ;
Die Abfrage:

UPDATE feldzug f, staedte s1, staedte s2
SET
f.res_eisen = 0 + IF((@summe_vom_angriff < @summe_verteidigt) AND (f.heimweg
0),0,s2.res_eisen),
f.res_stein = 0 + IF((@summe_vom_angriff < @summe_verteidigt) AND (f.heimweg
0),0,s2.res_stein),
f.res_kohle = 0 + IF((@summe_vom_angriff < @summe_verteidigt) AND (f.heimweg
0),0,s2.res_kohle),
f.heimweg = IF((@summe_vom_angriff < @summe_verteidigt) AND (f.heimweg
0),0,1),
f.besiegt = IF((@summe_vom_angriff < @summe_verteidigt) AND (f.heimweg
0),1,0),
s1.res_eisen = s1.res_eisen + IF(f.heimweg=1,f.res_eisen,0),
s1.res_stein = s1.res_stein + IF(f.heimweg=1,f.res_stein,0),
s1.res_kohle = s1.res_kohle + IF(f.heimweg=1,f.res_kohle,0),
s1.ein_soldaten = s1.ein_soldaten + IF(f.heimweg=1,f.ein_soldaten,0),
s1.ein_swat = s1.ein_swat + IF(f.heimweg=1,f.ein_swat,0),
s1.ein_panzer = s1.ein_panzer + IF(f.heimweg=1,f.ein_panzer,0)
WHERE
s1.stadt_id = f.feldzug_von_stadt_id
AND s2.stadt_id = f.feldzug_an_stadt_id
AND f.besiegt = 0
AND ((f.ankunft_in < '$jetzt') OR (f.zurueck_in < '$jetzt'))
AND (@angriffswert := (f.ein_soldaten*15)+(f.ein_panzer*50)+(f.ein_swat*35))
AND (@verteidswert := (f.ein_soldaten*23)+(f.ein_panzer*50)+(f.ein_swat*35))
AND (@summe_vom_angriff := @angriffswert + @verteidswert)
AND (@aS := (s2.ein_soldaten*15)+(s2.ein_panzer*50)+(s2.ein_swat*35))
AND (@vS := (s2.ein_soldaten*23)+(s2.ein_panzer*50)+(s2.ein_swat*35))
AND (@summe_verteidigt := @aS + @vS + (s2.geb_mauer*16))
Die Variable $jetzt beinhaltet dann immer den aktuellen Timestamp
Ich weiß nicht was daran falsch ist , zumindest wird kein fehler ausgegeben
Habe ich ganz falsch angefangen mit dem "Angreifen" oder wie ihr es nennen wollt^^
Oder ne bessere Frage wie habt ihr es in einem Echtzeit-Strategie-BG realisiert bzw wie würdet ihr es realisieren?
Mit freundlichen Grüßen,
Eugen Bolz

nette idee das in einem sql-statement zu machen.
mit mysql kenne ich mich nicht (mehr) so aus.
geht die update-set-syntax überhaupt so, wenn man die variablen erst im where definiert? ich dachte immer, das muss vorher?! egal.
wie ich das realisiert habe bzw. realisieren will, sind 2 unterschiedliche ansatzpunkte:
in meinem alten spiel hab ich dafür ein php-script geschrieben. der kampf wurde "tickweise" berechnet, wobei ein tick 10 sec waren. das lief dann immer so (grob):
1. wieviele ticks muss gerechnet werden (das script lief immer bei seitenaufruf und global für jeden spieler)
2. wenn ticks > 0, dann
a) daten aus der db holen
b) schleife: schiessen, schauen, ob noch was feindliches überlebt hat -> nächste runde bzw. kampfabbruch
c) die berechneten daten wieder in die db schreiben
3. restliche seite ausgeben
da ich es alles immer extravagant haben will, war bei mir alleine die berechnungsschleife mehrere 100 zeilen lang ..
in meinem neuen spiel wird das anders (unter anderem weil php zu lahm ist und nen großkampf den server komplett lahmlegt.. ka, wieso, aber php hat da ein internes problem. hab ich z.b. x ticks berechnet, dann lief das in < 1 sec durch .. bei x+1 ticks hatte er dann aber schon die 90-sec-marke überschritten... alles sehr komisch).
nun wirds "ordentlich" gemacht. sprich in c++. Das wird so ähnlich ablaufen. nur das nen daemon eben persistent läuft, die daten nur einmal einlädt und dann z.b. alle 10 sec in die db dumped.
Dauert aber noch, bis ich das fertig hab .. weil extravagant so mit "dann können wir ja gleich alles im 2d-raum simulieren .. mit schussradius, taktiken und ki(?!)" .. ich glaub ich hab mir etwas zu viel für ne 1-man-show vorgenommen

hm joa man könnte ja halt auch alles in einer schleife machen doch diese würde bei 20 angriffen auch 20 queries verursachen und das ist alles andere als optimiert^^
wenn man nur ein update über mehrere einträge machen könnte wäre das problem gelöst
oder soll ich einmal die variablen auf 0 setzen und dann nochmal den angriffs query durchlaufen lassen?

hm joa man könnte ja halt auch alles in einer schleife machen doch diese würde bei 20 angriffen auch 20 queries verursachen und das ist alles andere als optimiert^^

Manchmal ist es besser mehr Querys zu machen. Dien diese sind oft schneller, als ein großer. Muss jetzt hier nicht zutreffen.

hm also gibt es keine optimale umsetzung dieses problems? naja dann such ich mal nach anderen guten lösungen^^

Vielleich um es mal kurz einzuwerfen: Datenbanken speichern und rufen Daten ab. Zum (komplexen) Rechnen ist der Programmierer bzw. das Programm da.
Dementsprechend ist auch die Performance bei Rechenoperationen in DB's, die sind auf andere Aufgabenfelder - um es Konkret zu machen: auf Bäume usw. - optimiert.

Ich habe bei mir die Kampfroutinen auch als ein eigenes Modul vorliegen, was außerhalb der Datenbank läuft.
MySQL mag zwar schnell sein, aber die Business Logik sollte schon woanderst liegen als in der Datenbank. Man kann das zwar auch dort realisieren, aber für sinnvoll halte ich es persönlich nicht.

Dem muss ich mich anschließen, das Kampfscript bei meinem MMORPG führt die Kämpfe ausschließlich mit einer eigenen Klasse um, wobei die DB nur zum speichern der Stati und Daten verwendet wird.
Aber man muss auch unterscheiden: Ob man es nicht doch mit der Datenbank lösen kann, hängt wiederum auch von der Komplexität der Berechnungen ab. Wenn es ganz einfache Sachen sind, dann mag es mit der DB noch gehen, aber sobald die Berechnungen komplexer werden, funktioniert das einfach nicht mehr performant.
Gruß,
Marc

Also sind für euch viele Queries selbstverständlich?

Denk nicht weiter drüber nach, warum Dein obiger Code nicht funktioniert, denn damit machst Du Dich mittelfristig nur stark unglücklich. In dem Entwurf ist wohl alles "as bad as possible":
1. Die Datenbank dient als persistenter Speicher für Deine Daten. Nicht mehr, nicht weniger. Auch wenn Datenbanken rechnen und noch ganz andere Sachen können, heißt das nicht, dass man das auch nutzen sollte.
2. Die Geschäftslogik hat nichts in der Persistenz-Schicht verloren.
3. Du machst Dich abhängig von einem bestimmten DBMS. Willst/musst Du wechseln. Fliegt Dir die Sache um die Ohren.
4. Hardcodierte Konstanten sollten auch nicht in den Querys zu finden sein, sondern an zentraler Stelle definiert sein.
5. Es ist leichter, die Anwendung als solche zu skalieren, als die Datenbank. Du schaffst Dir so künstlich einen Flaschenhals
Fazit: Daten aus der DB holen, Ergebnisse in der Anwendung berechnen, Daten zurück schreiben. Wenn Du Dir Gedanken machst, dass die Querys nicht schnell genug ausgeführt werden, dann hängst Du halt weine memcached Instanz vor die DB. Dann ist das Problem auch gelöst, sollte es überhaupt aufkommen.
Nachtrag: Kommt darauf an, was Du unter viel verstehst. Ich habe Seitenaufrufe in meinem BG, da sind 10-20 Querys gar keine Seltenheit.

alles klar dann versuche ich mal alles in einer schleife zu machen , müsste nich so schwer sein^^
Thx

1. Die Datenbank dient als persistenter Speicher für Deine Daten. Nicht mehr, nicht weniger. Auch wenn Datenbanken rechnen und noch ganz andere Sachen können, heißt das nicht, dass man das auch nutzen sollte.

Ich denke, das kommt auch mit auf die Datenbank an. Z. B. ist PostgreSQL eine wissenschaftliche Datenbank die mit vielen mathematischen Funktionen ausgestattet ist, und bei der ich auch direkt Funktionen schreiben kann. Da macht es doch auch Sinn, einiges an Logik (nicht alles, da ist auch PG zu ineffektiv) direkt in die DB zu legen.

Original von progs
Ich denke, das kommt auch mit auf die Datenbank an. Z. B. ist PostgreSQL eine wissenschaftliche Datenbank die mit vielen mathematischen Funktionen ausgestattet ist, und bei der ich auch direkt Funktionen schreiben kann. Da macht es doch auch Sinn, einiges an Logik (nicht alles, da ist auch PG zu ineffektiv) direkt in die DB zu legen.

Vorallem, wenn man sich den Transport von sehr viel Daten damit sparen kann.

ich habe auf manchen seiten bis zu 40 queries, die seite geht aber trotzdem in 0.03 sec über die bühne. ich kann aber auch eine query schreiben die 0.8 sekunden berechnet - garkein problem..
mein tick (kampfberechnung, ressourcen, punkte...) benötigt locker 10.000 queries. klingt viel, ich weiß. ist auch etwas zu viel, da die datei immer noch historisch gewachsen ist und optimiert werden könnte. funktionieren tut das ganze trotzdem in 10 sekunden, was noch locker schnell genug ist.

Wie bereits oben erwähnt: die Anzahl der Querrys hat nicht umbedingt etwas mit der Geschwindigkeit etwas zu tun. Oft sind mehrere Querys schneller, als ein großer und verschachtelter.

HMmm... bei mir wird mittels eines Querys alles was notwendig ist eingelesen. Dann wird das ganze in einer C# Klasse verarbeitet, ausgewertet und wieder in die Datenbank reingeschrieben.
Da ich recht komplexe Kampfformeln habe (Rollenspielbasierend) und die Kämpfe auf große Einheitenmengen ausgelegt sind, kann ich sowas nicht mehr in einer Datenbank realisieren. Würde ich auch nie machen.

Abgesehen davon, dass man dann nicht mehr seine gewohnten Möglichkeiten zum Debuggen nutzen kann.

SQL-Scripte kann man mit ein paar Tricks debuggen. Ok, ist wirklich übelst, aber es geht.
Z.B. hab ich eine StoredProcedure erstellt, welche bestimmte SQL-Server Informationen dumpen kann.
Oder ich bau mir die SQL-Statements zusammen und dumpe die raus.
Möglichkeiten gibt es da viele, aber das ist eine Fummelei... da lohnt der Aufwand schon fast nicht mehr.

Wobei es aber auch hierfür genügend Programme und Tools wie Debugger gibt.

*G*
Erklär mal meinem ChefChef das wir dafür Budget brauchen.
Gib mir aber Zeit vorher einen Bunker aufzusuchen.

AFAIK kann das Visual Studio den SQL Server debuggen, aber das geht hier etwas offtopic... (schon mein 2. Offtopic Beitrag in verschiedenen Threads)

Original von progs
Ich denke, das kommt auch mit auf die Datenbank an. Z. B. ist PostgreSQL eine wissenschaftliche Datenbank die mit vielen mathematischen Funktionen ausgestattet ist, und bei der ich auch direkt Funktionen schreiben kann. Da macht es doch auch Sinn, einiges an Logik (nicht alles, da ist auch PG zu ineffektiv) direkt in die DB zu legen.

Ja, hier schreibst du aber solche "Kleinigkeiten" wie SQRT(99) oder maximal Dinge wie ABS(32 + 93 * 21) aber eben keine Logik. Die Befehle dienen einzig zum Aufbereiten der Daten, nicht zum Ersetzen der Logik.
Logik in der Ebene widerspraeche allen Grundsaetzen moderner Softwaretechnik - ich kenne auch keine Firma die soetwas tolerieren und kaufen wuerde. Das ist schlechter Stil und wenn ne neue Datenbankversion herauskommt, kann es dir alles uebern Haufen haun

Hey
ich wollte keinen neuen thread eröffnen weil das thema zusammenhängt^^
ich weiß nicht wie ich die Überlebenden Truppen ausrechnen bzw bestimmen kann
Habe diesen Ansatz genutzt um zu sehen wer von den Truppen gewinnt oder nich usw:

Alle Stärken werden zusammengerechnet , sowie die Verteidigungswerte

Präfixe:
Ang = Angreifer
Ver = Verteidiger
AngDiff = AngStr - VerVert;
VerDiff = VerStr - AngVert;
Wenn AngDiff größer als VerDiff dann
Angreifer hat gewonnen
ODER
Verteidiger hat gewonnen
END
Jetzt fehlt mir nurnoch wie soll man bestimmen welche und wieviele truppen überleben , hat jemand einen guten ansatz?^^
ich überlege schon seit 3 tagen wie ich das realisieren könnte aber dabei habe ich eher eine denkblockade als einen ansatz^^
hoffe jemand hätte da einen tipp oder ähnliches
Mit freundlichen Grüßen,
Eugen

also, es ist schwierig zu erklären...,
meine strategie
man nehme die angriffstärke des angreifers, und eine schleife....
dann wählt man zufällig einheiten vom verteidiger aus, und schaut ob sie mit der angriffstärke zerstört werden, wenn nein, und auch wenn ja, schaut man weiter, ob noch eine einheit zerstört wird
das ganze dann, bis keine angriffstärke mehr da ist
und dann nochmal für den verteidiger
Das Problem bei der ganzen Sache, es sind enorm viele SChleifendurchläufe, dutzende Arrays und das ganze dann bei mehreren 10.000 Einheiten unter 1 Sekunde ablaufen zu lassen, ist schwierig
na ja, um sich das Ergebnis anzuschauen
sim.zehnsur.de
mfg
topo

Wieso eigentlich das ganze im SQL Server machen?
Ich habe die Routine von Anfang an in C# gelöst und hole zu Anfang 1x die Daten ab.
Die Basiskampfroutine erreicht auf einem 1.8 Ghz Rechner ca. 1.8 Mio Einzelkämpfe, wobei ich hier ein RPG Kampfsystem für Einheit vs Einheit einsetze.
Das ganze ist noch nicht optimiert und ich Rechne mit einer wesentlich höheren Endleistung.

ich habe versucht die methode von sami06 umzusetzen aber irgendwie geht es nich ^^ , wäre cooL wenn du etwas mehr erzählen könntest denn den quelltext will ich nicht anfragen , weil zusehen bekommen würde ich den sowieso nich , also nur den logischen teil bitte^^

Original von EugenE
ich habe versucht die methode von sami06 umzusetzen aber irgendwie geht es nich ^^ , wäre cooL wenn du etwas mehr erzählen könntest denn den quelltext will ich nicht anfragen , weil zusehen bekommen würde ich den sowieso nich , also nur den logischen teil bitte^^

Da mir nicht genau bekannt ist, ob du mich meinst...
Grobkonzept Kampfsystem
Wobei ich hier doch geplanten Änderungen noch nicht eingepflegt habe. Die stehen bei mir im Moment auf einem Schmierzettel weil ich mir nicht sicher bin, ob die Sachen sinn machen

habe eigentlich sami06 gemeint aber dein Grobkonzept wird vllt auch helfen mal sehn^^ ich lese es mir aufjedenfall durch thx

na ja, ok, ich versuchs mal
für jede wichtige eigenschaft einer einheit ein array und dann wie folgt aufbauen
$eigenschaft[$einheitenid] = wert der einheit bei der eigenschaft
dazu dann ein array mit den einheiten des angreifers und des verteidigers
$veinheiten[$einheitenid] =anzahl der einheiten (verteidiger)
$aeinheiten[$einheitenid] =anzahl der einheiten (angreifer)
so, dann hast du schon mal die anzahl der einheiten
dann erstelle ich für beide armeen ein array. in dem jede einheit einzelnd gelistet ist (und genau dies ist der schwachpunkt, enorm großes array entsteht dabei)
dann berechne ich noch die angriffstärke der einheiten, ich schau also wie viel stärke die alle zusammen haben (vom angreifer sag ich mal, und vom verteidiger)
so, nun wird erst zerstört, wenn alle werte feststehen...
dann:
eine schleife, die solange läuft, wie von der angriffstärke noch was übrig ist
in dieser wird dann ein zufälliges element aus dem array des verteidigers genommen
dann wird geschaut ob dessen struktur kleiner als die angriffstärke ist, wenn ja, wirds zerstört, wenn nein, gehts zur nächsten einheit
and so on

ja so habe ich es auch versucht umzusetzen aber irgendwie naja , ich versuchs nochmal mal sehen was ich rausbekomme, vorerst danke^^

jetzt wird auch jede Einheit durch zufall auf beiden Seiten ausgewählt aber der einzige nachteil bei mir dauert zb ein 2000vs2000 kampf ca 2,1 Sec bei nem Kampf 7000vs7400 ca 43sec
benutzt du auch "Lebensenergie" pro Einheit?
wie könnte ich es verschnellern?
bei sami06's KampfScript dauert es max 0,03 Sec , warum ist dieses so schnell?
Mit freundlichen Grüßen,
Eugen

> jetzt wird auch jede Einheit durch zufall auf beiden Seiten
In meiner PHP-Implementation hatte ich mehrere 10.000 Einheiten pro Sekunde. Im Spiel selbst konnte ich ohne Sorgen bis auf 1.000.000 Einheiten pro Seite hochskalieren.
paste-it.net/3463 (Der Quellcode müsste grob aus dem Jahre 2003 sein)

hm das is nett das du dein altes Kampfscript hier postest aber geholfen hat es mir leider garnichts bin schon langsam am verzweifeln
Hier das Script zum Ausführen + Source
battle-world.de/ks_test.php
battle-world.de/ks_test.phps

Ich guck heute abend mal drüber, weil ich ein sehr ähnliches Kampfsystem bei mir einsetze (was allerdings zusätzlich noch mit Erfahrung pro Einheit usw. arbeitet).
Auf den ersten Blick lässt sich aber schon ein bisschen was optimieren...

und was lässt sich da optimieren
es sollte schon weniger als eine viertel sekunde dauern

Es lässt sich bereits einiges optimieren, aber es wäre gut, wenn wir mal direkt via ICQ, Skype oder ähnliches kommunizieren könnten, damit ich genau weiß, welche Teile nötig sind für dein späteres Konzept und welche Teile rausfliegen dürfen. (Kontaktdetails siehe PN)

Sry, bitte löschen

Mittlerweile habe ich schon min. 6 mal neu angefangen
und immer ist es zu langsam >.<
ich wäre über jede erdenkliche hilfe sehr dankbar, denn ich bin mit meinem Latein am Ende

Es gibt doch hunderte Stategie-Games hier, wie habt ihr es gelöst das eure Kämpfe schnell erledigt werden
MfG
Eugen Bolz

wenn es zu langsam ist rechnest du zuviel.
Da muss man lediglich unnötige rechnungen töten.
Einheiten zu Gruppen zusammenfassen und nicht jede einzeln rechnen etc. pp.
In meinem kamfsystem hat jede einheitengruppe genau $waffenanzahl schüsse auf eine andere einheitengruppe abgegeben. Da bei mir die einheiten zusammenstellbar sind habe ich potentiell viele einheiten - allerdings bauen die user nur 4-5 verschiedene "lieblingstypen". so hat jede flotte 4-5 einheitengruppen und schiesst auf jede andere feindliche flotte somit mit 4-5 * $waffenzahl * $feindliche_flottenzahl schüsse pro runde. Egal ob das 10, 100 oder 10000 einheiten von einem typ sind.
das problem ist nur, dass der aufwand (schlimmstenfalls) exponentiell zur anzahl der beiteiligten flotten steigt (wenn jede flotte mit jeder krieg hat).
so hab ich pro runde bei z.b. 5 flotten und 5 waffen pro schiffstyp und 5 verschiedenen schiffstypen 5*4*5*5 = 500 schüsse pro runde. Das ist immernoch besser als bei 1000 schiffen jede runde 1000 schüsse zu berechnen.
sind nur ansätze. Mein system ist auch auf eine berechnung über die zeit ausgelegt. ich habe z.b. in einem script immer nur 1 runde alles 10 sec berechnet. so dauerten die kämpfe 2-3h und sind schön realistisch.
ich bin ein gegner von "oh ein kampf. der bericht ist in ihrem posteingang". wo gibt es kriege, die 0 sec dauern?

werden alle 10sec eine Runde aus allen aktuellen Kämpfen berechnet? oder pro kampf unabhängig?
alles in php? oder macht das programm was alles berechnet?
würde mich interessieren wie du es grob realisiert hast

immer nur der kamf, dessen auswertung am weitesten zurück liegt. ich kann ja in einem rutsch auch 100 runden berechnen.
das war alles php.
Aber da mir das zu ungenau war (und einige bugs hatte) schreibe ich es grad in c++ neu.
2 kleine "screens" auf dem man ein wenig erkennen kann ist hier zu finden:
mission-unknown.de/stuff/fight.png
oder
mission-unknown.de/stuff/fight2.png
100 runden auf einmal, 2 schiffe, das weisse sind die schüsse.
ganz so aufwändig war es an php nicht - da war alles in einem punkt und ich hatte keine bewegung im 2d-raum mit rudimentärer ki und wegfindung.
aber eine highend-c++-daemon-lösung ist für die meisten spiele eh nichts.