|
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 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 11.02.2016, 13:09 Titel: |
|
|
Hier ein kleiner Vorgeschmack von dem, was ich mir bis jetzt für die Funktion "krieg" überlegt habe:
Zunächst bekommet die Armee einen eigenen Datentyp, der seinerseits Typen für die einzelnen Truppenteile enthält: Code: | Type tInfanterie
personen As Integer
kampfkraft As Integer
ausruestungen As Integer
End Type
Type tKavallerie
personen As Integer
kampfkraft As Integer
ausruestungen As Integer
pferde As Integer
End Type
Type tArtillerie
personen As Integer
kampfkraft As Integer
ausruestungen As Integer
kanonen As Integer
End Type
Type tMilizen
personen As Integer
kampfkraft As Integer
End Type
Type tArmee
name_ As String
rang As Integer
kriegskasse As Integer
infanterie As tInfanterie
kavallerie As tKavallerie
artillerie As tArtillerie
milizen As tMilizen
End Type |
Außerdem gibt es noch einen Datentyp zur Übergabe an die Funktion, in dem die Armeen der beiden Opponenten zusammengefasst werden: Code: | Type tKrieg
ich As tArmee
gegner As tArmee
End Type |
Der Aufruf der Funktion aus dem Hauptprogramm sieht dann ungefähr so aus: Code: | Dim As tArmee armee(7) 'eine Armee je Spieler
Dim As tKrieg truppen 'Container für 2 Armeen
...
truppen.ich = armee(1) 'zusammenfassen der 2 Armeen für die Übergabe an die Funktion
truppen.gegner = armee(2)
truppen = krieg(truppen) 'aufruf der Funktion "krieg"
armee(1) = truppen.ich 'aufteilen der Truppen nach der Schlacht
armee(2) = truppen.gegner |
Und bevor du jetzt fragst: "Wozu soll dieser Sch... denn gut sein?" warte ab, bis du die erste Programmversion siehst (ich arbeite noch daran). In diesem Zusammenhang habe ich eine Frage: Welche Aufgabe/Funktion haben die Milizen?
Und noch eine Anmerkung zu den minimalistisch-kryptischen Variablennamen vergangener BASIC-Versionen:
Für die Verwendung solcher Namen gab es durchaus einen Grund. Die Namen durften zwar (theoretisch) beliebig lang sein, der Interpreter wertete aber nur die ersten beiden (bei einigen Dialekten auch drei) Zeichen des Namens aus. spieler1, spieler2 und sp bezeichneten also dieselbe Variable. Außerdem durfte in dem Namen keine Zeichenfolge enthalten sein, die einem BASIC-Schlüsselwort entsprach. "motor" als Variablenname war beispielsweise nicht zulässig, weil darin das Schlüsselwot "to" vorkam.
Im Gegenzug war es möglich, Programmtexte ohne Leerzeichen zu schreiben. FORX=1TO10:PRINTX:NEXT war zwar nicht besonders leserlich, aber syntaktisch korrekt. Das Ganze diente dazu, den notorisch knappen Speicherplatz möglichst optimal zu nutzen.
Diese Zeiten sind glücklicherweise vorbei, so daß der Benutzung aussagekräftiger Variablennamen nichts mehr im Wege steht, ebenso wie erhellenden Kommentaren im Programmtext.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Zuletzt bearbeitet von grindstone am 11.02.2016, 14:30, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 11.02.2016, 14:28 Titel: |
|
|
Zitat: | Welche Aufgabe/Funktion haben die Milizen? |
Die Milizen werden nicht gekauft, rekrutiert oder was auch immer.
Sie sind die "Grundarmee", die durch die Menge an feldern, Häuser, Mühlen und die Palast/Kathedralenteile definiert werden. Je mehr, desto mehr Milizen zur "Grundsicherung".
Auch auf deren Kampfkraft hat man keinen aktiven Einfluss.
Sie nehmen natürlich am Kampf teil, sind aber nicht sooo stark (Der Kampfbonus ist also unter oder manchmal gleich dem der Infanterie.
Ich habe "mein" lauffähiges Konstrukt fertig.
KLICK
Ich weise extra darauf hin, dass das selbstverständlich noch in meinem Stil erzeugt ist.
Ich habe mal versucht mit SUBs zu arbeiten .. erstens klappt das nicht, wie ich das will und zweitens kann ich keinen VORTEIL erkennen. GOSUB tut doch im Grundsatz das Gleiche. die 50 (return für weiter) hab ich nur einmal drin und verweise bei bedarf darauf. Mit einer SUB verhält es sich doch genausO?
Und das Argument: so macht man das nicht, weil sieht doof aus .. kann man kaum gelten lassen _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 11.02.2016, 17:24 Titel: |
|
|
Zunächst einmal sind (gut benannte) SUBs lesbarer als GOSUBs, denn bei einem "GOSUB 1337" muss man schon ziemlich genau im Kopf haben, was da passiert. Gut, kann man die Marken ja besser benennen.
Ein Problem, das ich mit Sprungmarken habe, ist, dass man schon ziemlich genau hinschauen muss, um zu sehen, ob die nun mit einem GOTO oder GOSUB angesprungen wurden, ob das RETURN bereits stattgefunden hat (oder vielleicht einfach vergessen wurde) usw.; insbesondere gefährlich, wenn bedingte Rücksprünge verwendet werden und man sich bei den Bedingungen vertut. Eine SUB springt am Ende auf jeden Fall zurück und läuft nicht "versehentlich" in die nächste SUB hinein.
Als Hauptargument wird man dir aber sicher immer wieder die Kapselung nennen - eine SUB hat ihre eigene Speicherverwaltung, und du musst dir innerhalb der SUB keinerlei Gedanken über die Speicherverwaltung des Hauptprogramms machen (außer du hebelst das durch SHARED wieder aus). Dadurch ist die SUB auch deutlich besser wiederverwertbar für andere Programme. Als ganz simples "doofes" Beispiel:
Code: | ' mit GOSUB
FOR i = 1 to 10
PRINT i; "-ter Durchlauf:"
GOSUB 100
NEXT
PRINT "fertig"
100:
FOR i = 1 TO 10
PRINT "*";
NEXT
PRINT
RETURN |
Code: | 'mit SUB
DECLARE SUB schreibeSterne
FOR i = 1 to 10
PRINT i; "-ter Durchlauf:"
schreibeSterne
NEXT
PRINT "fertig"
SUB schreibeSterne
FOR i = 1 TO 10
PRINT "*";
NEXT
PRINT
END SUB |
Übrigens können sich SUBs und FUNCTIONs rekursiv selbst aufrufen; mit GOSUB würde ich so etwas lieber bleiben lassen ...
Code: | FUNCTION fakultaet(n AS INTEGER)
IF n < 0 THEN
fakultaet = 0
ELSEIF n = 0 THEN
fakultaet = 1 ' 0! = 1
ELSE
fakultaet = n*fakultaet(n-1) ' n! = n * (n-1)!
END IF
END FUNCTION |
_________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 12.02.2016, 16:16 Titel: |
|
|
@Schnism:
So, ich habe dein Programmstück mal durchgesehen und grob überarbeitet:
die schlimmsten IF..THEN - Wüsten beseitigt
die Sprungmarken durch passende Namen und
die ganzen wilden Sprünge durch ordentliche Strukturen ersetzt.
Damit du die Änderungen leichter nachvollziehen kannst, habe ich die alten Zeilen auskommentiert dringelassen.
http://users.freebasic-portal.de/grindstone/Codes/QBasic/KRIEG2P.BAS
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 12.02.2016, 17:44 Titel: |
|
|
Ok ...danke..
SELECT CASE, CASE IS .. DO WHILE und das DATA gedöns sind für mich böhmische Dörfer.
Ich nehme das mal so rüber und schaue, ob es dasselbe Resultat ergibt, wie meins
Das mit den "aussagekräftigen" Namen ist für mich immer noch nicht so verständlich .. ausser in dem Fall, das ein ANDERER User mit dem Code zurechtkommen soll. Für mich haben sich die kürzel so eingebrannt, ich erkenne das sofort alles wieder
Und vom Speicherplatz ist es doch wohl ein Unterschied, ob ich 1000 mal a2 schreibe oder 1000 mal gegnerischekraftzwischendenwelten ..
?
ob ich überall a9(a2) stehen habe oder vermoegen(spielernummer) ?
a8(a2) oder landbesitz(spielernummer)
? da wird doch viel viel merh speicher verwendet "letztendlich" ?
genauso mit den steten GOSUB befehlen per Namen:
GOSUB 50 .. (return für weiter) komme alle nase lang vor..
GOSUB taste (3 mehr) oder, damit es auch verständlich wird, denn taste stimmt so ja nicht, MUSS ja return sein: GOSUB returntaste (9 mehr)
Braucht das nicht alles mehr speicher? Aussagekräftige Namen dienen NUR! der Übersicht.. Aber ein jeder hat doch die Übersicht in SEINEM CODE? (steinigt mich )
Ok.. wie gesagt.. ich bau das mal genau so ein und versuche (da noch änderungen anstehen, das also nicht alles war) meine änderungen in derartigen Konstrukten zu "transformieren" _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007 Beiträge: 949 Wohnort: Austria
|
Verfasst am: 12.02.2016, 18:32 Titel: |
|
|
Schnism hat Folgendes geschrieben: | (steinigt mich ) |
Also wenn man deine Ansichten und deinen Code so liest hat man gute Gründe dafür . Das klingt so als hättest du die letzten 40 Jahre IT-Geschichte verschlafen.
Es wär ja nicht so dass Konstrukte wie Select Case oder Do While in irgendeiner Weise neu oder kompliziert wären, weswegen ich dir stark ans Herz lege dir wenigstens strukturelle/prozedurale Programmierung anzueignen (die 70er/80er Jahre lassen grüßen).
Der Speicherplatzverbrauch von langen Variablennamen ist schlicht irrelevant. Wenn es kompiliert wird oder in QBs Binärformat gespeichert wird sowieso, aber auch wenn du es im Textformat speichern solltest ist das bei heutiger Hardware völlig vernachlässigbar.
Die Kürzel magst du jetzt intus haben, kurz nachdem du den Code geschrieben hast. Problematisch wird es wenn du mehrere Monate nichts damit zu tun hast und dann wieder dran musst um z.B. den Code zu erweitern oder Fehler zu beheben. Da wirst du den Code dann auch beinahe so lesen wie derzeit ein "anderer".
Im allgemeinen würde ich dir raten auf modernere Software und evt. Hardware umzusteigen. DOS und QBasic werden seit Ewigkeiten nicht mehr unterstützt und kann eigentlich nur mehr emuliert werden. Ich weiß zwar dass es schwierig ist ein vorhandenes System umzustellen, aber nach so vielen Jahren sollte ein QBasic Programm wirklich ausgedient haben und sich eine Umstellung auf eine zukunftsfähige Umgebung lohnen. _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 12.02.2016, 18:48 Titel: |
|
|
Zitat: | ausser in dem Fall, das ein ANDERER User mit dem Code zurechtkommen soll |
So etwas darf man nie ausschließen. Kann ja vorkommen, dass du irgendwann keine Lust mehr an diesem Programm hast, ein anderer es aber toll findet und weiterentwickeln will. Dann sind nicht-aussagekräftige Namen tödlich.
Zu SELECT CASE: Das ist eigentlich nur eine sparsame Variante für bestimmte IF-ELSEIF-Abfragen. Als Beispiel:
Code: | ' mit IF
IF meineVariable = 1 THEN
tueDies
ELSEIF meineVariable = 2 THEN
tueDas
ELSEIF meineVariable = 3 THEN
machWasAnderes
END IF
' mit SELECT CASE
SELECT CASE meineVariable
CASE 1
tueDies
CASE 2
tueDas
CASE 3
machWasAnderes
END SELECT |
Spart bei einer größeren Anzahl an Fällen eine Menge Schreibarbeit und minimiert dadurch auch die Gefahr versehentlicher Tippfehler. Und es ist leichter zu lesen, weil man sich nicht immer die Bedingungszeilen ansehen muss, ob sie alle gleich aufgebaut sind. Wenn dann auch noch statt "SELECT CASE meineVariable" ein "SELECT CASE komplizierterBerechnungsterm" steht, ergibt sich außerdem der Vorteil, dass dieser Term nur einmal berechnet werden muss statt in jeder ELSEIF-Zeile neu.
Zitat: | ob ich überall a9(a2) stehen habe oder vermoegen(spielernummer) ?
a8(a2) oder landbesitz(spielernummer)
? da wird doch viel viel merh speicher verwendet "letztendlich" ? |
Da bin ich mir beim QBasic-Interpreter nicht sicher. Bei einem Compiler ist die Länge der Variablennamen egal, weil der intern dann sowieso eigene Bezeichnungen verwendet. Bei OMIKRON BASIC (Interpreter) weiß ich auf jeden Fall auch, dass er intern eigene Bezeichner benutzt hat und die Länge der Dateinamen damit langfristig egal war (da wurde der benötigte Speicherplatz direkt im Editor angezeigt). Ich halte es durchaus für möglich, dass QBasic das genauso macht.
// edit: ST_Ws Hinweis auf QBs Binärformat legen das nahe.
Zitat: | Es wär ja nicht so dass Konstrukte wie Select Case oder Do While in irgendeiner Weise neu oder kompliziert wären, weswegen ich dir stark ans Herz lege dir wenigstens strukturelle/prozedurale Programmierung anzueignen (die 70er/80er Jahre lassen grüßen). |
Richtig; strukturelle Programmierung hat mit dem Erscheinen von QBasic bereits Einzug gehalten, und das ist ja doch schon 30 Jahre her. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 13.02.2016, 00:04 Titel: |
|
|
St_W hat Folgendes geschrieben: |
Die Kürzel magst du jetzt intus haben, kurz nachdem du den Code geschrieben hast. Problematisch wird es wenn du mehrere Monate nichts damit zu tun hast und dann wieder dran musst um z.B. den Code zu erweitern oder Fehler zu beheben. Da wirst du den Code dann auch beinahe so lesen wie derzeit ein "anderer".
Ganz klares VETO. Wenn du meine vorherigen Posts gelesen hättest, würdest du (in diesem Fall) diese Aussage nicht tätigen (können) .. sie ist schlichtweg falsch.
Im allgemeinen würde ich dir raten auf modernere Software und evt. Hardware umzusteigen. DOS und QBasic werden seit Ewigkeiten nicht mehr unterstützt und kann eigentlich nur mehr emuliert werden. Ich weiß zwar dass es schwierig ist ein vorhandenes System umzustellen, aber nach so vielen Jahren sollte ein QBasic Programm wirklich ausgedient haben und sich eine Umstellung auf eine zukunftsfähige Umgebung lohnen.
Ich mache das alles aus einem einzigen Grund: entspannter Spass. alles andere würde Ehrgeiz vorraussetzen. Den aber besitze ich in dem Kontext nicht. Trotzdem würde und werde ich Tipps, die mir gegeben werden, beachten und wenn ich kann, umsetzen.
Ausserdem macht mir der Erhalt von Altem ebenfalls eine riesen Freude.
Denn aus diesem Grund gibt es ja auch dieses Forum.
|
Ich melde mich wieder, wenn ich mit dem Einbinden von den Vorschlägen parat bin
Danke an alle für die "korrektur meiner inneren Einstellung .. die Infos werden umgesetzt .. " _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 16.02.2016, 10:03 Titel: |
|
|
@grindstone
Ich habe deine Variante nun mal eingesetzt.
Komme noch nicht ganz klar mit dem DATA, wie der das ausliest und auch das hier ist mir nicht klar:
Code: | FOR x = 1 TO (eigeneeinheit - 1) * 4 + gegnerischeeinheit |
Wie kommst du auf die -1 .. ? _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 16.02.2016, 12:38 Titel: |
|
|
Hallo Schnism!
Was das DATA - Statement betrifft, empfehle ich dir den entsprechenden Eintrag in der Befehlsreferenz. Dort ist es ausführlich erklärt (mit Beispielen und besser, als ich es könnte).
Code: | FOR x = 1 TO (eigeneeinheit - 1) * 4 + gegnerischeeinheit
READ abonus, vbonus
NEXT
boni:
DATA 1,1, 1,2, 2,1, 2,1
DATA 2,1, 1,1, 3,1, 2,1
DATA 3,1.7, 3,1, 1,1, 3,1.3
DATA 1,2, 1,2, 2,1, 1,1 |
Warum dort -1 stehen muß, siehst du, wenn du die entsprechenden Werte in die Formel einsetzt:
In der FOR...NEXT - Schleife werden bei jedem Schleifendurchlauf 2 Werte aus den DATA - Zeilen gelesen, nämlich abonus und vbonus. Um beispielsweise an das Wertepaar für eigeneeinheit = 1 und gegnerischeeinheit = 2 zu kommen, muß die Schleife 2mal durchlaufen werden, der Ausdruck hinter dem TO muß also 2 sein:
(eigeneeinheit - 1) * 4 + gegnerischeeinheit --> (1 - 1) * 4 + 2 = 0 * 4 + 2 = 0 + 2 = 2
ohne die -1 ergäbe die Berechnung aber
1 * 4 + 2 = 4 + 2 = 6
Die Schleife würde also 4mal zu oft durchlaufen. Das gilt auch für alle anderen eingesetzten Werte von eigeneeinheit und gegnerischeeinheit.
Ich habe die Werte übrigens nur aus Gründen der besseren Übersichtlichkeit gruppiert und in 4 DATA - Zeilen geschrieben. Die Zeile Code: | DATA 1,1,1,2,2,1,2,1,2,1,1,1,3,1,2,1,3,1.7,3,1,1,1,3,1.3,1,2,1,2,2,1,1,1 | erfüllt denselben Zweck.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 16.02.2016, 17:47 Titel: |
|
|
Schnism hat Folgendes geschrieben: | Ich mache das alles aus einem einzigen Grund: entspannter Spass. alles andere würde Ehrgeiz vorraussetzen. Den aber besitze ich in dem Kontext nicht. |
Nur mal so am Rande: Du bist hier im Forum ja nicht der einzige Hobbyprogrammierer und viele andere hier programmieren auch zur Entspannung. Klar, man kann einfach alles für immer so tun wie man es gelernt hat, aber den möglichen Fortschritt zu ignorieren ist oft eben nicht entspannter als mal was neues zu wagen. Würde ich heute noch so programmieren wie vor zehn Jahren, müsste ich ich wohl auch wesentlich öfter den hier machen ->
Mit moderneren Systemen und neu gelernten Techniken geht vieles so viel einfacher. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 16.02.2016, 21:46 Titel: |
|
|
READ und DATA sollten ein Stück weit als Relikt älterer BASIC-Dialekte betrachtet werden. In modernen Programmiersprachen wie C, Pascal, Java und auch FreeBasic ist die Array-Konstante der geeignete Weg (man kann es in FreeBasic sogar als Read Only für den Compiler kennzeichnen).
Jojo hat Folgendes geschrieben: | Mit moderneren Systemen und neu gelernten Techniken geht vieles so viel einfacher. ;) |
Das ist so, z.B. die von grindstone überarbeitete Version liest sich bereits viel klarer. Um einen guten Code ansetzen zu können: Am besten sich den Fall vorstellen, eine Person müsste mit Bleistift, Papier und Würfel arbeiten und so den Kriegsverlauf "berechnen": Wie würdest Du diese Person instruieren, was sie genau tun muss? Die geeigneten Worte und Sätze führen häufig auch zum geeigneten Code.
grindstone hat Folgendes geschrieben: | Code: | Type tInfanterie
personen As Integer
kampfkraft As Integer
ausruestungen As Integer
End Type
... |
|
Und hier auch etwas ganz Wichtiges: Software-Entwicklung, genauer die Arbeit als Software-Architekt, beginnt häufig mit der Modellierung von Daten wie jetzt hier mit TYPE, danach definiert man die Operationen, welche man an den Daten vornehmen zu gedenkt (=bei der Obektorientierung übrigens die berühmten Methoden).
Habe übrigens unter
http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/SUB-Unterprogramme.html
sogar für QB-Programmierer bereits einen einfachen Leitfaden am Ende (das CAD-Beispiel) drin übers Entwerfen von Software. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 19.02.2016, 14:16 Titel: |
|
|
dreael hat Folgendes geschrieben: | Am besten sich den Fall vorstellen, eine Person müsste mit Bleistift, Papier und Würfel arbeiten und so den Kriegsverlauf "berechnen": |
Falls es jemanden interessiert, ich hatte mir etwa folgendes Szenario vorgestellt:
Die beiden Armeen stellen sich in einem gewissen Abstand voneinander auf. Vorne die Kavallerie, dahinter die Infanterie und hinten die Artillerie. Dann beginnen die Armeen aufeinander loszustürmen, die Kavallerie ca. 5mal so schnell wie die Infanterie, und die Artillerie beginnt, die gegnerischen Truppen zu beschießen. Unterschreitet der Abstand zwischen Freund und Feind einen bestimmten Wert (nach Truppenteilen getrennt) muß die Artillerie das Feuer darauf einstellen, um nicht die eigenen Leute zu treffen.
Jeder Krieger besteht aus Person und Ausrüstung. Wenn ein Feldherr also beispielsweise 100 Infanteristen und nur 75 Ausrüstungen hat, kann er auch nur 75 von ihnen in die Schlacht schicken. Bei einem Kavalleristen kommt dann noch ein Pferd dazu, und bei der Artillerie bedienen jeweils 3 Soldaten ein Geschütz.
Für die Versorgung der Truppen (Sold, Verpflegung, Munition etc.) ist pro Tag und Person ein bestimmter Betrag aus der Kriegskasse erforderlich. Ist die Kriegskasse leer, ist der Krieg verloren (ohne Mampf kein Kampf).
Nach jeder Schlacht gehen die Ausrüstungen der Gefallenen zu gleichen Teilen an beide Kriegsparteien, um nachzustellen, daß in historischer Zeit die Marketenderinnen über das Schlachtfeld zogen, um alles brauchbare einzusammeln (Uniformen und Waffen waren viel zu wertvoll, um sie einfach liegenzulassen).
Als besonderes Schmankerl habe ich noch eine "Rückzug" - Taste angedacht. Wenn der Spieler diese drückt, hat er zwar den Krieg verloren, behält aber seine verbliebene Armee samt Ausrüstung und Kriegskasse. Drückt er die Taste nicht und die Übermacht des Gegners wird zu groß, werden sich seine Truppen ergeben (statt sich sinnlos niedermetzeln zu lassen). Die Krieger werden wieder zu normalen Untertanen und gehen nach Hause (Gefangene habe ich nicht vorgesehen), deren Ausrüstung geht, ebenso wie die Kriegskasse, als Kriegsbeute an den Gegner.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 24.02.2016, 19:31 Titel: |
|
|
Bist du IRRE??
Irgendwie hab ich da die befürchtung, dass das zuviel des Guten ist
Insgesamt ist das schon nett. Der Krieg aber soll eher nicht das Hauptaugenmerk sein.
Auch was im Spiel die Kosten ansich erzeugen, ist schon ne Menge da. Spionage ist sinnvoll.. aber auch teuer.
Wenn ich mir nun vorstelle, ich baue deine ganzen Dinge ein .. wer soll das noch bezahlen
Aber das mit "Grenzen" überschreiten und Formationen.. finde ich schon .... tricky.. ICH kann sowas zumindest nicht programmieren _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 25.02.2016, 12:16 Titel: |
|
|
Das ist das, was ich mir auf deine Aufforderung Zitat: | Wenn also jemand mag, kann er einen vorschlag machen | hin ausgedacht hatte, als Kompromiss zwischen Realitätstreue und Programmieraufwand. Zu diesem Zeitpunkt kannte ich allerdings dein Original noch nicht, das ja einem etwas anderen und deutlich einfacheren Konzept folgt.
Natürlich lässt sich sowas nicht an einem Tag programmieren, und von der programmtechnischen Umsetzung habe ich bis jetzt auch nichts weiter als eine grobe Vorstellung. Meine Grundidee ist, das ganze Geschehen in Zeitabschnitte von beispielsweise 1 Minute (oder auch weniger) zu zerlegen und dafür jeweils die Aktionen und Reaktionen aller Akteure zu berechnen. Wenn man das Ganze strukturiert und übersichtlich aufbaut (die Anlage von passenden Datentypen, wie ich sie bereits gepostet habe, ist der erste Schritt dazu), ist das durchaus umsetzbar.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 25.02.2016, 12:35 Titel: |
|
|
Ja, klar.. das hab ich verstanden.
Ich finde deine Ansicht auch schick.. in meinem Bereich habe ich das durch den "Bonus" im Ansatz erzeugt.
Aber Ausrüstung ..hm .. Infanterieausrüstung, Kavallerieausrüstung, Artellerieausrüstung .. da kommt was zusammen.
Das "könnte" man über die Güter regeln, die die Schiffe mitbringen auf ihren Reisen und den "Helfern (Handwerkern), die aus den Rohstoffen die Ausrüstung produzieren.. (wird ja schon gemacht.. aus Holz, Eisen und Tuch werden als Beispiel Fuhrwagen hergestellt, aus Gold und Silber wird Schmuck erzeugt etc. )
Nur eben das mit der Grenzlinie.. die muss ja für beide gelten.
Auch sind wir uns garantiert einig, das Kriege um die 1700 maximal zu Anfang "geordnet" abliefen. Ab einem bestimmten Zeitpunkt wird aus Ordnung zwangsweise Chaos. Was passiert, wenn die Infanterie zu nah an der Artillerie ist, dann ist die Artillerie absolut ineffektiv.
Wenn du diese passen alle mit einbringen möchtest, wird das ein mammutprojekt ich bin dabei ..aber total hilflos in der Umsetzung. _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 27.02.2016, 20:21 Titel: |
|
|
OK, warum nicht mal ein Retro - Game? Wenn du ernsthaft interessiert bist, können wir das gemeinsam in Angriff nehmen. Vielleicht schaffen wir es ja doch noch, dir strukturiertes Programmieren beizubringen .
Eines werde ich allerdings ganz bestimmt NICHT tun: Das Ganze in QBasic programmieren! Das ist nämlich viel zu mühselig. Dafür biete ich dir an, dein ganzes bisheriges Programm nach freeBasic zu portieren (und dabei gleichzeitig in eine leserliche Form zu bringen ).
Zum Spielansatz:
Zitat: | Aber Ausrüstung ..hm .. Infanterieausrüstung, Kavallerieausrüstung, Artellerieausrüstung .. da kommt was zusammen. | Natürlich, Krieg war schon immer sehr teuer.
Zitat: | Das "könnte" man über die Güter regeln, die die Schiffe mitbringen auf ihren Reisen und den "Helfern (Handwerkern), die aus den Rohstoffen die Ausrüstung produzieren.. (wird ja schon gemacht.. aus Holz, Eisen und Tuch werden als Beispiel Fuhrwagen hergestellt, aus Gold und Silber wird Schmuck erzeugt etc. ) | Das gehört alles zur Vorbereitung und damit nicht in dieses Modul. Das Modul "Krieg" beschäftigt sich ausschließlich mit den Kampfhandlungen.
Zitat: | Nur eben das mit der Grenzlinie.. die muss ja für beide gelten. | Stell dir vor, die Armeen stellen sich in einem gewissen Abstand (beispielsweise 800m) voneinander auf. Dann gibt jemand das Angriffssignal, und beide Armeen stürmen los. Wenn beide gleich schnell sind (wovon wir mal ausgehen), werden sie sich automatisch in der Mitte treffen.
Zitat: | Was passiert, wenn die Infanterie zu nah an der Artillerie ist, dann ist die Artillerie absolut ineffektiv. | Genau, das ist ja der Reiz bei dem Spiel.
Zitat: | Wenn du diese passen alle mit einbringen möchtest, wird das ein mammutprojekt grinsen | Wenn man das Ganze in sinnvolle kleine Teile zerlegt, ist das gar nicht so schlimm. Um beispielsweise einen Vogelschwarm zu simulieren, reichen drei einfache Regeln:1. Folge dem Schwarm
2. Stoße nicht mit anderen Schwarmmitgliedern zusammen
3. Stoße nicht mit Gegenständen zusammen Das so erzeugte Gebilde bewegt sich wie ein echter Vogelschwarm.
Zitat: | ich bin dabei ..aber total hilflos in der Umsetzung. | Wir machen das in ganz kleinen Schritten, und wenn nötig, gibt es ein paar Extralektionen in moderner Programmierung.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 27.02.2016, 22:07 Titel: |
|
|
Schnism hat Folgendes geschrieben: | Wenn du diese passen alle mit einbringen möchtest, wird das ein mammutprojekt :D ich bin dabei ..aber total hilflos in der Umsetzung. |
Am besten noch einmal an die Methode mit Papier, Bleistift und Würfel zurückdenken. Ich will damit nur heraus, wenn Du keinen Computer zur Verfügung hättest, aber dafür eine Handvoll Mitarbeiter wie in einer Firma, die Du genau instruieren musst, dass sie das Richtige für Dich als Vorgesetzter tun.
Ein ebenfalls geeigneter Denkansatz: Dein Spielprojekt als Brettspiel umsetzen, Du müsstest dazu eine Spielanleitung schreiben. Weil der Computer alles genauso macht, wie man ihm es sagt, darf Deine Spielanleitung im Prinzip nirgends Raum für freien Ermessensspielraum offen lassen, d.h. die Anleitung muss so geschrieben sein wie ein Gesetz, wo im Streitfall jeder Richter dieser Welt absolut identisch urteilen würde.
Durchaus denkbar: Gestalte doch am besten einmal mit Buntstiften so ein Spielbrett, suche Material wie Hütchen und Würfel zusammen. Schreibe noch mit einer Textverarbeitung eine Anleitung (zu Beginn einmal noch relativ einfach gehalten). Nun lasse Familienmitglieder und Freunde von Dir das Spiel an einem verregneten Sonntag spielen. Dabei solltest Du auf deren Fragen, wenn etwas unklar ist, eingehen und die Spielanleitung so laufend ergänzen.
Auf diese Weise bekommst Du für die Umsetzung in ein QB- bzw. besser FreeBasic-Programm auch die nötige Basis, händisch am Brett gespielte Situationen dienen Dir gleich als Testfälle, um in ganz konkreten Situationen prüfen zu können, ob Dein Code auch das gewünschte Ergebnis liefert.
Kurz und bündig: Vor jeder Umsetzung eines Algorithmus in einen Code einer beliebigen Programmiersprache sollte man diesen genau definieren und beschreiben können. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 29.02.2016, 01:47 Titel: |
|
|
Vorüberlegungen Teil 2:
Schnism hat Folgendes geschrieben: | Auch sind wir uns garantiert einig, das Kriege um die 1700 maximal zu Anfang "geordnet" abliefen. Ab einem bestimmten Zeitpunkt wird aus Ordnung zwangsweise Chaos. | Du willst Chaos? Bitte sehr:
Warum aus dem Geschehen nicht eine "echte" Simulation machen? Analog zu dem oben erwähnten Vogelschwarm wird aus jedem Krieger ein (programmtechnisches) Objekt, das -jedes für sich- nach bestimmten Regeln handelt:1. Bewege dich auf die feindliche Grundlinie zu
2. Bekämpfe den Feind
3. Suche die Nähe deiner Kameraden
4. Verlasse auf keinen Fall das Schlachtfeld
5. Versuche, am Leben zu bleiben Das gilt für Infanterie und Kavallerie, für die Artillerie, die sich ja nicht bewegt, lauten die Regeln:1. Bekämpfe den Feind
2. Versuche, nicht deine eigenen Leute zu treffen Im Programm ist jedes "Objekt" eine Variable vom Typ "tKrieger" Code: | Type tKrieger
zugehoerigkeit : 1 As UByte '1 Bit: Freund = 0 / Feind = 1
typ : 2 As UByte '2 Bits: Milizionär, Infanterist, Kavallerist oder Geschütz
posx As Single 'x - Position auf dem Schlachtfeld
posy As Single 'y - Position auf dem Schlachtfeld
kampkraft As UByte 'von 0 - 255
Union
motivation As UByte 'bei Infanterie und Kavallerie von 0 - 255
ladezustand As UByte 'bei Artillerie in %
End Union
verwundung As UByte 'in %
End Type | Jedes Objekt hat einen "inneren" Kreis um sich herum, der den Raum kennzeichnet, den es selber einnimmt, innerhalb dessen sich also kein anderes Objekt aufhalten kann (bei einem Infanteristen dachte ich da an 60cm Durchmesser, bei einem Kavalleristen an 2m) und einen "äußeren" Kreis, der dem Aktionsradius seiner Waffen entspricht.
Soviel für den Anfang. Ich werde mal versuchen, ein kleines Testprogramm zu schreiben, aus dem ersichtlich wird, wie das Ganze funktioniert.
Und noch eine gute Nachricht: Wenn dieses Modul als in sich abgeschlossenes Programm erstellt wird, kannst du es -auch als compilierte .exe - Datei- in dein QBasic - Programm "einhängen". Die nötigen Variablen werden dann in einer Datei übergeben, der Aufruf erfolgt von QBasic aus mit dem SHELL - Befehl. Das ist ja so ungefähr das, was du ursprünglich vorhattest.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Schnism
Anmeldungsdatum: 13.10.2004 Beiträge: 58 Wohnort: Schweiz
|
Verfasst am: 29.02.2016, 09:04 Titel: |
|
|
Also halten wir uns dereinst an den "Krieg" und seine Umsetzung.
Derzeit habe ich im Hauptprogramm:
Infanteristen mit Musketen (Die werden auch schon durch Güter hergetellt (Holz und Eisen)
Kavalleristen mit Streitrössern (Pferde werden "Importiert" und von Schiffen mitgebracht oder es gibt sie als Mitgift durch Heirat. Aus Pferden werden durch zureiten Streitrösser gewonnen.)
Artilleristen mit Kanonen (Diese werden durch Eisen und Holz produziert)
Milizen kämpfen mit Schwertern / Helebarden und was es sonst noch so gibt, werden aber nicht separat ausgerüstet, sondern die Menge ergibt sich aus den zu schützenden Bauten / Land und sind auch in ihrer Moral (Kampfkraft) computergesteuert.
Was ich an deinen Code immer wieder vermisse ist die Spielerunterscheidung.
Das Spiel soll für bis zu 6 Spieler sein. Ich nehme an, zu deinen variablen kommt dann auch immer variable(spieler) ? _________________ "...nichts ist so schlimm wie mein programmcode!" |
|
Nach oben |
|
|
|
|
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.
|
|