Level2 Army Builder

[Hajo]

Der OnlineCodex ist recht putzig gemacht. Ich habe mir mal den Source Code besorgt, nachdem ich zuvor in das JAR-Archiv geguckt und keinerlei Datendatei gefunden habe, allerdings einen Verdacht hegte. Tatsächlich ist jede Einheit, die man im Programm vorfindet, eine eigene Klasse. Das könnte man in Hinblick auf die klar definierte Produktpalette und die recht strenge Trennung zwischen Programmierern und Anwendern noch wohlwollend als pragmatisch bezeichnen, würden diese Klassen nicht für jede Sprache existieren --- Programmlogik (z. B. "Angegratzt, der Ungebundene, darf nur in Armeen ab 2000 Punkten verwendet werden.") existiert also ein Mal pro Landessprache. Viel Spaß beim nächsten Update.

Da sich bei der LEVELx-Tabletop-Produktfamilie die Kreativität nicht auf die obere Firmenleitung beschränkt, ist eine Konfigurierbarkeit bzw. Erweiterbarkeit durch den Anwender sehr wichtig und der Ansatz des OnlineCodex nicht zu gebrauchen.

Abgesehen davon ist das Open-Source des OnlineCodex nur eine Blah-Blah-Absichtserklärung, aber keine Lizenz.

[Hajo]

Wie wäre es vorerst mal mit einer Version für ausschließlich fraktionslose Steitmächte?

Ich vermute stark, dass Ehron ein bekanntes Problem nicht ungelöst vor sich her schieben möchte. Das mächte Spaß, wenn es keine unbekannten Probleme gäbe, die garantiert auch noch auftauchen. Einige Geschichten sind aber auch wirklich haarsträubend ("Nur ein einziger Bandenführer darf eine einzige E-Mag-Grante haben."), vielleicht sollte Markus einfach die ganzen Sonderregeln in Level3 streichen.

[Ehron]

Das mit einer Klasse pro Einheit und Sprache klingt grausam, eigentlich sogar geradezu schmerzhaft. Über die Gründe wieso jemand sowas macht kann ich nur mutmaßen.

Und wieder hat Hajo einen weiteren Gedanken von mir aufgedeckt: Erweiterbarkeit durch den Anwender.

Eine reine Version für fraktionslose Streitmächte ohne jegliche Sonderregelung (z.B. Mengenrabatt für Granaten, etc.) wäre sicher relativ schnell machbar (natürlich nicht von heute bis morgen und auch sicher nicht in den nächsten 4 Wochen). Wenn sich vorher keine Gedanken darüber gemacht werden wie die Sonderregeln implementiert werden können, reißt man sich aber mit an Sicherheit grenzender Wahrscheinlichkeit eine Flanke auf die hinterher mehr Arbeit generiert als man hofft. Natürlich muss nicht gleich alles zu 100% durchdacht sein, aber eine gewisse Grundstruktur muss stehen.

Bei ein paar der ganz abstrakten Sonderregeln hab ich mir auch schon überlegt, ob ich die überhaupt abbilden will. Aber wenn man schon anfängt, dann vielleicht auch ganz. Ausrüstungsbeschränken wie z.B. Reizgas für Frauen oder auch die Einmaligkeit von Ausrüstungskombinationen bei Banden sind relativ simpel umzusetzen, andere sind "herausfordernd". Und eigentlich wollte ich die Prüfungen nicht einfach hartkodieren und dann per Schalter aktivieren oder deaktivieren.

Für's erste werde ich mir aber mal Gedanken über ein XML-Schema für Ausrüstung machen, dann kann schonmal jemand mit Abtippen beginnen. Da die Ausrüstungslisten keinerlei Logik enthalten, dürfte die Basis dafür flott stehen, und da das unabhängig von der am Ende verwendeten Technologie ist, kann auch schon damit begonnen werden.

[Damokles]

Mit dem Thread habt ihr mir einen Geist ins Gehirn gesetzt, der jetzt die ganze Zeit da drin rumspukt.

Wenn man den Planer in Teilbereiche aufteilen würde, wäre das ganze etwas besser umsetzbar, denke ich. So könnte man, wenn man mal von einem Tab-Control ausgeht, ein Tab machen, bei dem man einen Kämpfer zusammenstellt und ihn per Knopfdruck einer Liste (Tabelle) hinzufügt, die in einem anderen Tab als Zusammenfassung betrachtet werden kann. Hier können dann auch die Leute 'geclont' und diversen Truppen zugeteilt werden.

So kann man dann auch mit weiteren Tabs Fahrzeuge, Kreaturen, etc. noch dazunehmen. Allerdings wird das ein eher unübersichtliches Sammelsurium an Controls (wenn ich nur an die vielen Checkboxen für die Ausrüstung denk..)

Die Prozentualen Modifikationen für diverse Unternehmen wären dadurch zu lösen, dass man in den jeweiligen Teilbereichen möglichkeiten bekommt vergünstigungen einzutragen, was man allerdings nur für die allgemeinen Prozentualen Boni wie 5% billigere Plantate oder so nutzen kann...

Bei den Kernbeschränkungen wird es dann richtig knifflig, allerdings frag ich mich in wie weit die notwendig sind. Man weis ja eigentlich wie die Beschränkung auszusehen hat (zumindest, wenn man ein Regelbuch hat) dann muss man halt in der Hinsicht einfach mitdenken.

[Rescrus]

Nimm Delphi.

[Hajo]

Mein Modell scheitert gerade volle Pulle. Ich kann definieren, dass es die kostenlosen Handschellen nur einmal gibt, dass sie nur Polizisten kriegen, dass Banden keine Unterführer haben, dass Berserker auf einem Nahkämpfer oder Großmeister (Was ist mit dem Einzelkämpfer?) aufbauen. Ich kann sogar definieren, dass ein Bajonett nicht ohne Gewehr (Ist der Netzwerfer ein Gewehr bis das Böse™. 12?) funktioniert. Aber eine Figur mit einem Gewehr kann beliebig viele Bajonetts einstecken. Ach du liebe Güte! Muss ich jetzt unterhalb des Figurenmachers auch noch einen Waffenmacher ansiedeln?

[Damokles]

Tu dir selbst einen gefallen und lass diese Art von Beschränkung raus, auch ohne wird es schon schwer genug. Ich weis ja, dass das dann gegen das Grundprinzip verstößt, ein Programm müsse so gemacht werden, dass auch der DAU das auf Anhieb problemlos einsetzen kann, aber du willst vermutlich in einer absehbaren Zeit und unter einem bestimmten Aufwand auch ein gewisses Ergebnis erzielen..

Bin gerade dabei zu überlegen, die ganzen Daten in eine .csv zu stopfen, die ich in eine Tabelle einlese aus der ich dann die Steuerungsobjekte und die Berechnungen, etc. ableite. (sehr leicht zu manipulieren, aber auch leicht zu warten...)

[Ehron]

DAUs sehe ich ehrlich gesagt nicht als Zielgruppe, sondern eigentlich Leute die das Regelwerk gelesen haben.

Mit Beschränkungen wie "nur ein Bajonett pro Gewehr" hätte ich mich jetzt ehrlich gesagt nicht wirklich beschäftigt, da gibt es ganz andere Probleme zu lösen.

[Niceyard]

Wo steht, dass es verboten ist, mehrere Bajonette an ein Gewehr zu machen?
So ein Waffenmacher ist keine falsche Idee, denn manche Waffen bestehen tatsächlich aus einer ganzen Menge von Bauteilen.
Und dann ist am Ende immer noch nicht klar, ob es eine Zweitwaffe oder eine Erstwaffe sein soll.

[Damokles]

Das Problem ist, dass man das halt nicht einfach mit einbaun kann. Denn wenn man alle Waffenoptionen einbeziehen will würde das 'bauen' einer Waffe praktisch zu einem eigenständigen Programmteil werden.

Das Optimum sähe dann vermutlich so aus, dass man ein Dataset in das System einbindet und dann schrittweise den Aufbau in mehrere Tabellen tätigt.

1. Kämpfer erzeugen (Mensch, Schütze) und in Tabelle mit ID versehen.
2. Dienstgrade und Ausbildung in 2. Tabelle über die ID vernetzt
3. Ausrüstung
4. Plantate
5. Waffen

Am Ende aus den Daten dann einen Report generieren und die Möglichkeit berücksichtigen mehrmals einen Kämpfer mit derselben Ausrüstung zu haben und die einzelnen Kämpfer in entsprechende Gruppen zu verteilen.

PS: Ok, man könnte statt dem relationalen Datenmodell auch einfach entsprechende Objekte erzeugen und in eine Liste einfügen, wobei hier die Frage aufkommt wie das mit der Auswahl und dem Löschen einzelner Objekte aussehen soll.