![Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht](misc/logos/logo.png) |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Schnism
![](images/avatars/669524975416d101427814.gif)
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 07.03.2016, 09:33 Titel: |
|
|
KAISER ist der Vorgänger aller anderen Wirtschaftssimulationen.
ich kombiniere "Fugger (1989)", "Patrizier (1992)" und eben "Kaiser( 1984)".
Wirktschaft steht im Vordergrund. Krieg ist ein Mittel zum Niederhalten des Gegners oder um ihm Land zu klauen. Aber eher "Nebensache"
Ich habe aber auch nichts gegen einen gut gestalteten Krieg. _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 12.03.2016, 13:28 Titel: |
|
|
3. Entwicklungsschritt: Als die Krieger laufen lernten.
Quellcode
.exe
In dieser Demo sucht sich zu Anfang jeder der 2 x 1000 Krieger den Feind, der ihm am nächsten ist und bewegt sich auf ihn zu, wobei er dessen Bewegung folgt, ohne dabei das Schlachtfeld zu verlassen oder mit jemand anderem zu kollidieren. Die Bewegung endet, wenn er diesen erreicht hat oder die weitere Bewegung durch einen anderen Krieger versperrt wird.
Ich finde, der Eindruck von zwei aufeinander zustürmenden Haufen ist recht gut getroffen. Die Muster, die am Ende entstehen, erinnern irgendwie an Eisenfeilspäne in einem Magnetfeld. Ein wunderbares selbstorganisierendes Chaos, trotz sparsamen Einsatzes des Zufallsgenerators.
Eine Frage an die Experten: Gibt es eine Möglichkeit, einem Objekt innerhalb einer Sub/Function den Zugriff auf eine Variable zu ermöglichen, ohne daß diese in der Parameterliste erscheint oder als Shared deklariert wird? Im konkreten Fall: Wenn ich das Array krieger() als Parameter an eine Prozedur übergebe, daß dann die Properties von tKrieger Zugriff auf Variablen wie schlachtfeld oder sfmap() haben, ohne daß ich diese entweder als Shared deklarieren oder jedesmal komplett in der Parameterliste aufführen muß?
Und falls jemand eine effektivere (= schnellere) Methode kennt, den räumlich nächsten Feind zu ermitteln: Auch hier bin ich offen für Neues.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Toa-Nuva
Anmeldungsdatum: 14.04.2006 Beiträge: 204 Wohnort: München
|
Verfasst am: 12.03.2016, 17:46 Titel: |
|
|
grindstone hat Folgendes geschrieben: | Eine Frage an die Experten: Gibt es eine Möglichkeit, einem Objekt innerhalb einer Sub/Function den Zugriff auf eine Variable zu ermöglichen, ohne daß diese in der Parameterliste erscheint oder als Shared deklariert wird? Im konkreten Fall: Wenn ich das Array krieger() als Parameter an eine Prozedur übergebe, daß dann die Properties von tKrieger Zugriff auf Variablen wie schlachtfeld oder sfmap() haben, ohne daß ich diese entweder als Shared deklarieren oder jedesmal komplett in der Parameterliste aufführen muß? |
Ich hab mir den Code jetzt nicht im Detail angesehen, aber du könntest Referenzen auf schlachtfeld und sfmap als zusätzliche Properties zu tKrieger hinzufügen. Dann hat eben jeder Krieger seine eigenen Referenzen auf dasselbe Schlachtfeld. So würde ich es wahrscheinlich machen.
grindstone hat Folgendes geschrieben: | Und falls jemand eine effektivere (= schnellere) Methode kennt, den räumlich nächsten Feind zu ermitteln: Auch hier bin ich offen für Neues. |
Das von dir beschriebene Szenario ist im Prinzip eine Nächste-Nachbarn-Anfrage, und es gibt einige Datenstrukturen (z.B. Quad-Trees, R-Trees), mit denen solche Anfragen effizienter durchgeführt werden können. Dazu wird der komplette Datenraum (also das Schlachtfeld) in kleinere Abschnitte unterteilt. Bei einer Anfrage müssen dann nur ein paar dieser Abschnitte durchsucht werden. Wenn sich z.B. ein Krieger im unteren rechten Viertel des Schlachtfeldes befindet und der gesuchte nächste Nachbar ebenfalls, dann muss sich der Algorithmus die anderen drei Viertel des Schlachtfeldes u.U. gar nicht ansehen.
Solche Verfahren werden gewöhnlich eher für riesige Datenmengen entwickelt, an denen sich nicht mehr sonderlich viel ändert; Aber bei kleineren, volatilen Datenmengen (so, wie sie in einem Spiel vorkommen) soll es wohl auch praktikabel sein, in jedem Schritt/Tick/Frame/Zug die Datenstruktur einmal komplett neu aufzubauen (mit speziellen "Bulk-Load"-Verfahren), darauf alle Anfragen durchzuführen und die Datenstruktur anschließend wieder zu verwerfen. Wurde mir mal in einer Vorlesung über die Entwicklung von (MMO-)Spielen so erklärt.
Für ein kleines Projekt wie dieses hier könnte so ein Verfahren aber womöglich doch Overkill sein. ![zwinkern](images/smiles/icon_wink.gif) _________________ 704 Signature not found |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Schnism
![](images/avatars/669524975416d101427814.gif)
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 13.03.2016, 01:22 Titel: |
|
|
grindstone hat Folgendes geschrieben: | Ich finde, der Eindruck von zwei aufeinander zustürmenden Haufen ist recht gut getroffen. |
Ohne zweifel! _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 13.03.2016, 02:24 Titel: |
|
|
also zu erst einmal wuerde ich ein sleep16 oder screensync einfuegen,
so sieht man erstmal besser was passiert
auserdem denke ich das dein pol2kart und kart2pol da auch noch
optimiert werden kann. ich hab da irgenwas mit normalisierten
vectoren im sinn (glaub das war einfach schneller zu berechen).
ansonsten gefaellt mir das schon sehr gut
salute
edit: evtl koennte man die krieger ja auf der y achse sortieren so das sich
die naechsten halt schon im array "gegenueberstehn" ka ob das hilft
aber ne idee waers ![grinsen](images/smiles/icon_biggrin.gif) |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Elor
Anmeldungsdatum: 12.07.2013 Beiträge: 205 Wohnort: Konstanz
|
Verfasst am: 13.03.2016, 14:19 Titel: |
|
|
Zitat: |
Ich hab mir den Code jetzt nicht im Detail angesehen, aber du könntest Referenzen auf schlachtfeld und sfmap als zusätzliche Properties zu tKrieger hinzufügen. Dann hat eben jeder Krieger seine eigenen Referenzen auf dasselbe Schlachtfeld. So würde ich es wahrscheinlich machen.
|
Ich glaube nicht das sich das Problem mit Property's lösen lässt. Ich hab mir die Programmstruktur mal angeschaut und habe festgestellt, dass da zwar mit so was ähnlichem wie Objekte gearbeitet wird, aber eben nicht Objekt Orientiert!
Ich glaube, da müsstest mal ansetzen werden, dann würden sich auch die „Shared“ Dimensionierungen in Luft auf Lössen. |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 15.03.2016, 16:35 Titel: |
|
|
Vielen Dank für das Feedback, mit soviel Resonanz hatte ich gar nicht gerechnet!
@Toa-Nuva + Elor:
Danke für den Tip. Doch, es geht mit Properties, auch wenn es das Ganze um einiges komplizierter macht (Pointer sind ausgesprochen widerspenstig ). Die Referenzen auf die externen Variablen werden jetzt im ansonsten unbenutzten krieger(0) abgelegt, wo sie bei Bedarf von jedem Element abgefragt werden können. Das Programm (Quellcode) ist jetzt Shared - frei.
Was die Feindfindung betrifft: Das Problem ist die Verzögerung am Anfang, wo sich jeder "seinen" Feind sucht, der definitiv nicht in der Nähe ist. Bei 2 x 1000 Kriegern (2 x 1000 x 1000 = 2 Millionen Berechnungen) ist die Verzögerung kaum spürbar, die 200 Millionen Berechnungen, die bei 2 x 10000 Kriegern anfallen, dauern aber doch schon einige Sekunden.
@Haubitze:
Bei meinem betagten Rechenknecht (Pentium 4 / 3GHz / 1 Kern) reicht das Sleep 1. Wenn es dir zu schnell geht, setz den Wert einfach hoch.
Bei pol2kart glaube ich nicht, daß es da etwas zu verbessern gibt, die Sinus- und Cosinus - Funktionen von FB sind schon ziemlich flott. Bei kart2pol benötigt die ATan2 - Funktion vielleicht etwas mehr Rechenzeit, aber dafür liefert sie ohne weiteres "Gedöns" den benötigten Wert (siehe https://de.wikipedia.org/wiki/Polarkoordinaten).
@Schnism:
Danke!
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 15.03.2016, 17:55 Titel: |
|
|
Hi Grindstone,
auch wenn ich nich wirklich durchsehe in deinem code ;D
in deiner hauptschleife initialisierts du ja mit
Code: |
For x = 1 To UBound(krieger)
reihenfolge(x) = x
Next
|
jedes mal das reinfolge array neu und wuerfelst das dann durch.
es reicht aber auch wenn du die initialisierung vor dem DO machst
und dann immer neu durchwuerfelst.
Code: |
...
ReDim reihenfolge(UBound(krieger))
For x = 1 To UBound(krieger)
reihenfolge(x) = x
Next
Do
'reihenfolge durcheinanderwürfeln
For x = 1 To UBound(krieger)
Swap reihenfolge(x),reihenfolge(Int(Rnd * UBound(krieger)) + 1)
Next
...
|
ausserdem empfinde ich das immerwaerende redimen von krieger als
arg. daher mein vorschlag in der krieger initialisierung ab zeile 287
Code: |
...
ReDim krieger(0)
redim preserve krieger(spieler(0).heer.milizen.anzahl+spieler(1).heer.milizen.anzahl)
Dim As Integer k, kmax0 = 5
Dim As Integer x, y
schlachtfeld.x = 500 'grösse des schlachtfelds in metern
schlachtfeld.y = 600
ReDim sfmap(schlachtfeld.x, schlachtfeld.y) 'schlachtfeldkartekarte anlegen
k = 0
For x = 0 To 1 'beide spieler
'milizionäre
With spieler(x).heer
For y As Integer = 1 To .milizen.anzahl
If .schwerter + .hellebarden + .spiesse = 0 Then
Exit For
EndIf
k += 1
'ReDim Preserve krieger(k)
krieger(k).array = krieger() 'referenz auf array setzen (muß nach jedem ReDim gemacht werden)
krieger(k).zugehoerigkeit = x
krieger(k).typ = miliz
krieger(k).kampfkraft = .milizen.kampfkraft
krieger(k).motivation = .milizen.motivation
If .schwerter Then
krieger(k).schwert = 1
.schwerter -= 1
ElseIf .hellebarden Then
...
|
fuer dein entfernungsproblem hab ich zZ auch keine gute loesung, ich teste grade mit nem distance_index_array welches ich dann in
jedem lauf neu berechne und sortiere aber das is auch nich das wahre :/
naja so weit von mir.
salute und weiter machen
edit: bei der ersten feinfindung kannst du ja zB zwei feinde immer gleichzeitig setzen. hatt spieler1 einen naechsten feind gefunden
so hatt ja spieler2 auch einen gefunden.
ergo spieler2.naechterfeind=spieler1.naechster feind.(oder so aehnlich)
das sollte es schon mal etwas kuerzen aber getestet hab ich das jetzt
nich ![Zunge rausstrecken](images/smiles/icon_razz.gif) |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Elor
Anmeldungsdatum: 12.07.2013 Beiträge: 205 Wohnort: Konstanz
|
Verfasst am: 15.03.2016, 19:46 Titel: |
|
|
grindstone hat Folgendes geschrieben: |
...Doch, es geht mit Properties...
|
Hab's zwar anders gemeint, da wäre die Streitmacht teil des Landes gewesen, aber so geht's natürlich auch!
Ich finde das hier sehr interessant weil ich selber noch nie ein Spiel Programmiert hab und bin mal gespannt, was da am ende raus kommt.
Also weiter so! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 16.03.2016, 17:17 Titel: |
|
|
@Haubitze:
Zu "reihenfolge()" und "ReDim": Du hast in beiden Punkten Recht, ich habe das entsprechend in den Quellcode übernommen.
Den Ansatz mit der Entfernungstabelle hatte ich auch schon probiert, das war aber deutlich langsamer als die derzeitige Methode. Man braucht dabei zwar nur halb soviele Entfernungswerte zu berechnen, aber die notwendige Verwaltung frisst den Zeitvorteil wieder auf.
Natürlich könnte Krieger 1 seinen eigenen Index an Krieger 2 übermitteln, sobald er diesen als seinen nächsten Feind erkannt hat. Der Haken dabei ist, daß diese Information zu dem Zeitpunkt, an dem Krieger 2 sie auswertet, möglicherweise schon wieder ungültig ist, weil Krieger 1 sich inzwischen bewegt hat.
@Elor:
Im ersten Ansatz hatte ich die Armeen in zwei getrennten Arrays untergebracht aber dann festgestellt, daß die Handhabung mit einem einzigen Array einfacher ist. Die Trennung ist ja durch den Index (kmax0) klar definiert, selbst der Record zuordnung ist eigentlich überflüssig.
Zitat: | ...und bin mal gespannt, was da am ende raus kommt. | Ich auch! So eine "echte" Simulation zu programmieren habe ich noch nie versucht. Mal sehen, welche Überraschungen da noch warten...
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Schnism
![](images/avatars/669524975416d101427814.gif)
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 22.03.2016, 00:55 Titel: |
|
|
Mal anklopf... ! ![lächeln](images/smiles/icon_smile.gif) _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 22.03.2016, 10:44 Titel: |
|
|
Immer langsam mit den jungen Sauriern!
Aber gut, zur Befriedigung der allgemeinen Neugierde hier der aktuelle Stand der (Programm-)Entwicklung:
Quelltext
.exe
Das Ganze ist aber noch eine Baustelle. Die Krieger schlagen sich inzwischen einigermassen wirkungsvoll die virtuellen Köpfe ein, es gibt jedoch einige Dinge, die noch nicht richtig rund laufen. Im Augenblick versuche ich herauszufinden, warum der Spielfluß gegen Ende immer mehr stockt, obwohl die Kämpfe weniger werden.
Immerhin habe ich inzwischen die Lösung für das das Problem mit den globalen/lokalen Variablen gefunden: ganz einfach, indem man sie innerhalb des UDT als Static deklariert. Dann haben alle Elemente des UDT Zugriff auf denselben Wert (alte Technikerweisheit: "Wenn gar nichts anderes hilft: Lesen Sie die Gebrauchsanleitung!" - in diesem Fall die Befehlsreferenz ).
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 22.03.2016, 14:54 Titel: |
|
|
mir scheint das irgenein, speicherzugriffsfehler zu sein.
leider sehe ich den wald vor lauter baeumen nich
wenn ich das richtig beobachte dann laest du die armeen ja
mehrmals kaempfen oder? zumindest bei mir geht es wohl in einen
2. durchlauf der gleuch zu beginn uebelst laeggt wenn er denn
nich gleich abstuerzt.
ich glaube ja auch es waere besser gewesen das ganze in
"classen" zu kapseln und die armeesn teil des schlachtfelds zu
machen. das macht den code uebersichtlicher und man kann leichter
debuggen. evtl setz ich mich mal ran und model das um ;D
trozdem sieht das schon cool aus und man bekommt einen eindruck
wo es hingehen soll
salute
PS: was sind die weisen punkte die sich so schnell bewegen
wenn die beiden armeen aufeinander treffen? |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
nemored
![](images/avatars/18585278245ddb8b9d8710.png)
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 22.03.2016, 16:54 Titel: |
|
|
Ahahaha ... wie brutal, wenn sich die siegreichen Kämpfer in Scharen auf die letzten verbleibenden Gegner stürzen. Wenn jetzt noch ab irgendeinem Zeitpunkt die unterlegenen Truppen zu fliehen beginnen würden ...
Der zweite Durchlauf laggt bei mir auch total, und ab dem dritten springt bei mir nur noch das Grafikfenster auf und zu. Gut dass Geany immer gleich eine Konsole mit öffnet, die man schließen kann. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Schnism
![](images/avatars/669524975416d101427814.gif)
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 23.03.2016, 01:44 Titel: |
|
|
ich denke, die "Menge" ist einfach eine unrealistische Grössenangabe.
Also zumindest was das Spiel angeht. 1000 Soldaten kann man kaum bezahlen.
Geschweigedenn "ausrüsten" ..
Also 300 Soldaten + Milizen sind schon ne starke Armee in dem Spiel.
Und dann sind die Schwach. Wenn man die moralisch noch stärken will.. kann man es vergessen. (also rein Finanziell)
In so spielen ist es eben auch üblich, "Grenzen" einzubauen. _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 23.03.2016, 06:42 Titel: |
|
|
klar Schnism, ich denke das hier ist auch erstmal nur ein stresstest.
aber irgendwo is da noch was im argen. |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Elor
Anmeldungsdatum: 12.07.2013 Beiträge: 205 Wohnort: Konstanz
|
Verfasst am: 23.03.2016, 12:44 Titel: |
|
|
Haubitze hat Folgendes geschrieben: |
ich glaube ja auch es waere besser gewesen das ganze in
"classen" zu kapseln und die armeesn teil des schlachtfelds zu
machen. das macht den code uebersichtlicher und man kann leichter
debuggen. evtl setz ich mich mal ran und model das um ;D
|
Das hatte ich ja auch schon angedeutet, ich glaube aber auch, dass der Umstieg von der Prozeduralen Programmierung zur OOP für niemanden einfach ist! Ich hatte mal, ich glaube ende der 80iger, mit Turbo Pascal 3.01A angefangen. Die nächste Version die ich mir gekauft hatte war TP 6.0. Beim Blick in die TVison war mein erster Gedanke „sind die nicht ganz Dicht?“. Heute kann ich fast gar nicht mehr anders. Lange Rede, kurzer Sinn, warum Würfelt Ihr euch nicht zu einer Projektgruppe zusammen?
@Schnism: Du kennst das Spiel ja offensichtlich in und Auswendig, bist also der Ideen Geber!
@grindstone: Du bist derjenige der mal schnell einen Code aus dem Hut Zaubern kann, dass hast Du schon oft gezeigt!
Wenn Haubitze das ganze OO verpackt und dann auch noch erklärt wird wie das ganze Funktioniert (es sind ja auch Einsteiger hier), dann werden hier noch lange sehr viele Spaß haben! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 23.03.2016, 17:52 Titel: |
|
|
Ich habe ja gesagt, daß das Programm noch eine Baustelle ist. Die Ursache für die Abstürze beim 2. und 3. Durchlauf ist die falsch gesetzte Sprungmarke "anfang:". Die muß weiter nach oben, direkt hinter die Funktionsdeklarationen.
Erläuterung zum Konzept: Ein Schleifendurchlauf entspricht einem Zeitabschnitt von einer Sekunde, ein Pixel auf dem Bildschirm einem Meter auf dem Schlachtfeld. Das Schlachtfeld ist in Quadrate von 1 m Kantenlänge aufgeteilt, in jedem Quadrat kann sich nur ein Krieger aufhalten. Für einen Kavalleristen habe ich einen Platzbedarf von 2x2m und für ein Geschütz 3x3m geplant. Ab einer Verwundung von 80% ist ein Krieger kampfunfähig (roter Punkt auf dem Schlachtfeld).
Das Ruckeln am Ende des Durchgangs habe ich inzwischen beseitigt, mein Problem im Moment ist, daß sich die Krieger immer wieder festlaufen, weil sie von ihren eigenen Leuten eingekeilt werden. Das ist ähnlich wie bei einer Panik in einem Gebäude, wo alle gleichzeitig durch eine Tür wollen, da geht dann am Ende gar nichts mehr. Mein derzeitiger Lösungsansatz ist, daß ich jeden, der seit 60 Sekunden nicht mehr vom Fleck gekommen ist, nehme und an einen zufällig gewählten Ort in 50 m Umkreis setze, wo er sich dann einen neuen Feind sucht. Das scheint ganz gut zu funktionieren. Wenn später die anderen Kriegertypen dazukommen und Waffen von unterschiedlicher Reichweite, wird sich das vermutlich sowieso entzerren.
Elor hat Folgendes geschrieben: | warum Würfelt Ihr euch nicht zu einer Projektgruppe zusammen? | Ja, warum nicht? Ich wäre prinzipiell nicht abgeneigt.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 25.03.2016, 01:35 Titel: |
|
|
So, das Grundgerüst ist soweit fertig.
Quellcode
exe
Dieses (Test-)Programm ist hier bei mir jetzt ein paar Stunden gelaufen, ohne daß es Abstürze oder sonstige Ungereimtheiten gegeben hätte.
Als nächstes werde ich die ganzen noch fehlenden Einflussgrößen einarbeiten, wie Kampfkraft, Motivation, Ermüdung usw.
Noch ein kleiner Hinweis: Die endgültige Fassung wird weit weniger blutrünstig sein als die jetzige Testversion. Schließlich versuche ich, einigermassen die Realität zu simulieren, und zur damaligen Zeit hatte ein Soldat eine Überlebenswahrscheinlichkeit von über 95%. Richtige Massaker gab es nur bei sehr ungüstigen Begleitumständen, etwa, wenn einer der Gegner in die Enge getrieben wurde, oder, wie in Magdeburg 1631, wenn sich monatelanger extremer psychischer Druck entludt.
Zu diesem Thema gibt es zwei sehr lesenswerte Websites:
http://www.gledde.de/Die%20DeutschRitter/Kloster/Heer%20im%20Mittelalter/Kloster_Heer_im_Mittelalter.htm
http://dasmittelalterderblog.com/category/irrtumer-des-mittelalters/
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
Schnism
![](images/avatars/669524975416d101427814.gif)
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 25.03.2016, 16:11 Titel: |
|
|
Tip Top
Ich habe mir das nun 20 minuten angeschaut.
Was auffällt: WENN eine Seite gewinnt, was sie ja muss, dann immer überdeutlich. D.h. ob nun weiss oder grün: es bleiben immer SEHR viele davon übrig.
"Knappe" Ausgänge scheint es in der reinen Zufallsberechnung nicht zu geben?? Woran liegt das?
(Denn Bewaffung, Moral und dergleichen hast du ja noch nicht drin, wo es möglich wäre, mit einer Zahlenmässig unterlegenen Angriffswelle trotzdem des Sieg zu erringen. ) _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
![](templates/subSilver/images/spacer.gif) |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|