Browergame - Mitstreiter gesucht

[Igor der Schreckliche]

Hallo zusammen,

ich spiele mit dem Gedanken, mein Browser-Game-Projekt, das ich
gestartet hab um mich in Python einzuarbeiten, zum Open-Source-Projekt
zu machen. Ich habe das Projekt als reine Spielerei und zum Lernen gestartet, und möchte es auch genau so weiterführen. Das währe mein erstes Open-Source-Projekt.

Suchen würde ich Mitstreiter, die mit mir am Projekt arbeiten. Todos
gibts im Python-Code, im Game-Balancing und im Design. Wer helfe möchte muss weiß Gott kein Profi sein, ich hab auch gern Leute im Projekt, die selber im und am Projekt lernen möchten. Vor allem in Sachen Game-Balancing und Einheiten definieren sind garkeine Programmierkentnisse nötig, da dass alles XML-basiert ist. Aber auch
lernwillige Python-Neulinge sind gern gesehen Auch HTML-Coder
brauchen keine Ahnung von Python zu haben, da das erzeugen der HTMLs
ausschließlich in Templates von Statten geht.

Die Idee hinter dem Spiel ist, eine kleine Realitäts-ähnliche Welt mit
Model-Charakter zu bauen. Dazu gehört eine ausgeprägte
Wirtschaftssimulation, in der Rohstoffe gefördert werden müssen, zu
Metallen verarbeitet, diese dann wiederzum zu Stahl-trägern, bevor man
damit Häuser bauen kann (nur als ein Beispiel). Es gibt also sehr viele
Wahren-Typen. Man muss aber nicht alles selber erzeugen, sondern kann
auch alles kaufen, man kann mit allem handeln, wie in Echt halt.
Irgendwas muss man jedoch produzieren und verkaufen, sonst fehlt das
Geld

Neben der Wirtschafts-Simulation gibt es auch eine militärische
Komponente. Hier gibt es verschiedene Einheiten (im Moment nur
Fuß-Einheiten), die verschieden weit schießen können. Hier kann man sich
in Sachen "Einheiten erschaffen" sehr austoben. Ausserem ist geplant,
dass sich Einheiten verstecken können. Soldaten können dann aus einem
Wald rausschießen, ohne gesehen zu werden. Das soll die strategische
Komponente des Spiels ausmachen.

In Zukunft soll es auch noch eine gesellschaftliche Komponente geben,
sodass man sich um Bildung, Gesundheit und so weiter kümmern muss. Tut
man das nicht, oder zu schlecht, soll das Nachteile in der Wirtschaft
und im Militär geben. Aber das ist Zukunftsmusik

Der aktuelle Status:

Grundsätzlich funktioniert das alles irgendwie. Es ist zwar alles recht rudimentär, aber die Grundfunktionalitäten sind gegeben. Ich hab auch schon einige Stunden gezockt und hatte echt Spaß dran Man kann also direkt mit der Spiel-Verbesserung starten!

Die Architektur sieht folgendermassen aus:
Es gibt einen pure-Python Standalone-HTTP-Server, welcher selbst das Handling der Requests übernimmt. Als Persistenz dient eine Mysql-Datenbank. Die Definition der Einheiten und der Wahre-Typen erfolgt in einer XML-Datei. Alle Fähigkeiten von Einheiten werden über Plugins realisiert, deren Konfiguration ebenfalls in der XML-Datei steht. Das Design der HTML-Seiten ist Template-basiert (cheetha).

Was steht an Arbeit an:

TODOs HTML-Design:
Das Design ist bis jetzt rein auf funktionalität ausgelegt. Hübsch ist
da garnix.. da könnte man quasi alles neu machen, wenn man will

TODOs für Game-Balance/Einheiten/Wahrentypen:
Neue Kampf-Einheiten designen, mit Fähigkeiten ausstatten
Balancing
Umsetzten von Wirtschaftszusammenhängen, Einheiten erschaffen, die Dinge
bauen, Wahren erzeugen.

TODOs für Python-Coder:
Login-Sessionhandling - Im Moment ist das Ding ein Single-User-Game
AI - Computergegner sind im moment denkbar blöde..
Sicherheitslöcher - im Moment gibt es mehrere Möglichkeiten, Schindluder
zu treiben

Screenshots:
http://www.knexe.de/screenshots/spielfeld.jpg
http://www.knexe.de/screenshots/feldinfo.jpg
http://www.knexe.de/screenshots/uebersicht.jpg
http://www.knexe.de/screenshots/uebersicht.jpg
http://www.knexe.de/screenshots/warenliste.jpg

Also, wenn ihr Lust habt, mitzusmachen, traut euch und schreibt mir

Viele Grüße und bis dann,

Igor

[jonas]

Find ich witzig die Menschen unter Waren aufzuführen

[Igor der Schreckliche]

Politisch sicher nicht 100% korrekt, aber was solls

[sma]

Hallo Igor,

willkommen im Python-Forum (und wie schön, dass man auf deiner Webseite auch sehen kann, wie du aussiehst, weil ihr euch bei einer Einweihungsparty mit Krepppapier beschriftet habt ;). Ich finde Browser-Games sind ein interessantes Thema und daher hier auf diesem Wege mein moralischer Support. Wenn du's zu einem Opensource-Projekt machst, bin ich gespannt auf einen Blick in den Quelltext.

Von deiner Ankündigung hier weiß ich allerdings noch nicht so recht, was ich davon halten soll. Sie hat leider recht viele Rechtschreibfehler und leider kann ich nicht anders, als davon auf die Qualität des Quelltexts zu schließen. Das mag falsch sein, aber das ist, was ich dir an ungefragtes Feedback anbieten kann.

Hast du die Webanwendung "from scratch" gebaut oder ein Rahmenwerk (Django, Pylons, usw.) benutzt? Aus deinem Text schließe ich ersteres. Warum? Das könnte helfen, "Sicherheitslöcher" prinzipiell zu vermeiden. Wenn du Cheetah benutzt, ist dein Server wahrscheinlich CherryPy, oder? Warum noch zusätzlich XML? Ich hätte wahrscheinlich einfach Python selbst zur Konfiguration benutzt. Ich stelle ich es mir außerdem recht schwer vor, ein Einpersonen-Spiel auf ein Mehrpersonen-Spiel umzuschreiben, ohne nicht fundamentale Änderungen machen zu müssen.

Dennoch: Mein Respekt dafür, überhaupt so weit gekommen zu sein. Ich könnte wohl technisch so ein Spiel schreiben, doch scheitere meist daran, mir funktionierende Regeln auszudenken. Das finde ich das schwerste.

Stefan

[cofi]

Hoert sich ziemlich nett an.

Wie sieht es denn mit Infrastruktur aus? Repository, Issuetracker, Hosting und dergleichen?

Du schreibst Browserspiel, aber willst Computergegner?

Das XML seh ich aehlich wie Stefan: Das ist einfach ueberfluessig. Python ist auch nicht schwerer zu schreiben, gleichzeitig kommen Klassen und andere schoene Sachen fuer Simulationen in Betracht. Stellt man da genug Hilfen auf, kann man die grundlegenden Sachen - das, was mit XML moeglich ist - machen ohne wirklich Python zu kennen.

Michael

[Igor der Schreckliche]

Guten Morgen Stefan, guten Morgen Michael,

Danke für euer Feedback. Danke für euer Interesse

Ich möchte gern auf jeden Punkt eingehen. Also:

Webseite: Dann weißt Du jetzt auch, wie ich in Bademantel eine IKEA-Küche zusammen schraube

Rechtschreibung: Da hast Du mich hart an einer meiner schwächsten Stellen getroffen. Ich weiß, dass meine Rechtschreibung etwas schwach ist. Es tut mir leid wenn da durch das Lesen meiner Beiträge etwas nervig ist. Ich arbeite daran...

Codequalität: Ich finde es recht gewagt, von Rechtschreibung auf Codequalität zu schließen. Aber kurz zu meinem Hintergrund: Ich bin gelernter Fachinformatiker Anwendungsentwicklung mit einigen Jahren Berufserfahrung in Java. Ich lerne Python nicht als erste Sprache. Der Code folgt dem MVC-Konzept, ist im großen und ganzen recht robust und modular aufgebaut. Bugs habe ich bis jetzt recht wenig gefunden. Was leider etwas kurz gekommen ist, ist die Doku und die Unit-Tests. Hier müsste ich noch nacharbeiten, wenns zu einem OpenSource-Projekt wird.

Webanwendung: Jup, die Webanwendung ist komplett selbst geschrieben und sehr rudimentär. Unter dem Gesichtspunkt des Lern-Wertes eine ganz einfache Entscheidung. Allerdings hänge ich nicht an dem Code. Ich habe ihn geschrieben, ich habe daraus gelernt, jetzt kann er gern durch ein Framework ersetzt werden. Dieses selbst geschriebene Framework mappt Aufrufe anhand eines "view"-Parameters auf verschiedene Cheetah-Templates.

Sicherheitslöcher: Mir sind bis jetzt keine Sicherheitslöcher per Design bekannt. Eher sind hier folgende Dinge gemeint:
- Fehlende Parameter-Format-Prüfung
- Fehlende Prüfungen, ob der User das tun darf/kann, was er gerade tut. Er kann sich momentan Infos über Einheiten anzeigen lassen, die nicht ihm gehören, einfach weil die Abfrage fehlt. Das Projekt ist entstanden mit mir als einzigem User, und ich hatte nicht vor mein eigenes Projekt zu hacken, also hab ich auf solche Abfragen verzichtet. Aber natürlich kann einem ein Web-Framework einiges an Arbeit abnehmen, wogegen ich mich auch gar nicht verschließen will.

XML: XML hat viele Vorteile. Hier nur einige davon:
1) Mit einem ordentlichen XML-Editor und einem XML-Schema habe ich eine super Code-Vervollständigung beim Konfigurieren.
2) Konfiguration hat im Code schlicht und ergreifend nichts verloren, auch wenns "einfach" ist.
3) Einfache Prüfung der Konfiguration durch XML-Schema
4) Ich schreib dir in 15 Minuten ein XML-Stylesheet, dass aus der XML-Datei eine python-Datei macht. Das ist anders rum bedeutend schwerer.
5) Ich wollte ausprobieren, wie Python mit XML umgeht

Um dem Argument der Performance zuvor zu kommen: Die Konfig wird beim Serverstart einmalig geparsed, dass dauert ca 5 Sekunden (AMD2100+). Das halte ich für eine Server-Anwendung durchaus vertretbar.

Multiplayer: Da hab ich mich wohl etwas missverständlich ausgedrückt. Es ist von der Konzeption her ein Multiplayer-Spiel. Jede Einheit hat einen Besitzer, Einheiten unterschiedlicher Besitzer bekämpfen sich. Mengen von Verfügbaren Waren werden Pro Spieler verwaltet, Nachrichten sind Spielern zugeordnet. Was noch zu tun ist: Es gibt derzeit eine statische Session, die nur einen Eintrag hat, nämlich eine Hardcodierte player-id (0). Es gibt kein Login! Es muss also eine Login-Seite entstehen und die Session muss an einen Cookie gehangen werden, oder an eine Session-id. Dann ist der Multi-Player-Part schon fertig. Das war nur bis jetzt nicht notwendig, da ich allein bin. Also: keine fundamentalen Änderungen nötig, geht wahrscheinlich von selbst mit einem fertig-Web-Framework.

Infrastruktur: Gibts nicht! Hier müsste entschieden werden, was verwendet werden soll. Sourceforge, google-code, ... ich hab keine Erfahrung damit, bin für Tipps dankbar!

Computer-Gegner: Wie gesagt, ich war bis jetzt allein, da braucht man wenigstens ein Dummy-Gegenspieler, der irgendwas baut, was man zerschießen kann. Das muss man glaub ich nicht weiter verfolgen.


So, ich hoffe meine Argumentationen sind nachvollziehbar.

Viele Grüße,

Igor

[lunar]

Vervollständigung hilft auch nicht viel, wenn das Format selbst – so wie XML – nur sehr mühsam manuell zu bearbeiten ist. INI-Dateien und Python-Code sind für den Benutzer angenehmer zu bearbeiten, insbesondere dann, wenn mal kein Super-XML-Editor bereit steht, was auf den Servern, auf denen dein Spiel vielleicht mal laufen wird, der Fall sein kann.

Im Übrigen sollst du Konfigurationswerte ja nicht in den Tiefen des Frameworks kodieren, wenn dir geraten wird, Python zu verwenden. Damit ist vielmehr eine separate Python-Konfigurationsdatei gemeint, die mit "execfile()" eingelesen wird. Warum das böse(TM) sein soll, verstehe ich nicht ...

Ein XML-Schema zur Validierung der Konfiguration ist Overkill. Die Konfiguration musst du in deinem Programm eh nachbereiten, also kannst du sie auch gleich da validieren, ohne zusätzlich nochmal ein Schema zu schreiben. Falls du die Validierung magst, gibt es ConfigObj, dass Validierung für ein INI-ähnliches Format bereitstellt.

Bei Java mögen die Dinge anders liegen, bei Python jedenfalls ist es kein guter Weg, XML für alles mögliche zu nutzen. Python is not Java!

[Defnull]

Punkt 5) ist der einzige, den ich gelten lasse

Was Infrastruktur angeht, würde ich dir http://github.com empfehlen. Da gibts WIKI, issue-tracking system, downlaoads, source browser und die besste git unterstützung auf dem Planeten. Und natürlich willst du git als Versionskontrolle nutzen, stimmts?

[Igor der Schreckliche]

Hallo Lunar, Hallo Devnull,

Nur um mal ein Gefühl zu geben, wovon wir reden: Wir reden über eine Datei, die jetzt schon fast 5000 Zeilen hat. Wenn wir über 20 Konfigurations-Schlüssel reden würden, würde ich euch sofort recht geben, dann wäre eine INI-Datei sicher einfacher. Wir reden hier aber über Strukturen, in denen es viele gleiche Blöcke gibt. Definition von x Waren-Typen, deren Struktur immer gleich ist. Definition von Einheiten und deren Plugins, die von der Struktur her immer gleich sind. Gerade dabei kann XML alle seine Vorteile ausspielen! Für 5000+ Zeilen und nervige Fehlersuche bei Konfig-Fehlern halte ich ein Schema keineswegs für Overkill. Und eine solche Datei gehört auch nicht "hands on" am Server editiert.

Ich verspüre hier eine Gewissen Antipathie gegen XML. Könnt ihr mir erklären, warum? Es funktioniert prima...

@git
Ich habe bis jetzt noch nicht mit git gearbeitet. Werds mir mal anschauen.

Grüße,

igor

[Defnull]

Nur um mal ein Gefühl zu geben, wovon wir reden: Wir reden über eine Datei, die jetzt schon fast 5000 Zeilen hat. Wenn wir über 20 Konfigurations-Schlüssel reden würden, würde ich euch sofort recht geben, dann wäre eine INI-Datei sicher einfacher. Wir reden hier aber über Strukturen, in denen es viele gleiche Blöcke gibt. Definition von x Waren-Typen, deren Struktur immer gleich ist. Definition von Einheiten und deren Plugins, die von der Struktur her immer gleich sind. Gerade dabei kann XML alle seine Vorteile ausspielen! Für 5000+ Zeilen und nervige Fehlersuche bei Konfig-Fehlern halte ich ein Schema keineswegs für Overkill. Und eine solche Datei gehört auch nicht "hands on" am Server editiert.

Das schreit nach SQL O.o Wir reden bei dieser Größenordnung und Struktur nämlich nicht mehr über eine Konfiguration (im engeren Sinne), sondern über Daten (im weiteren Sinne). Gibt es einen speziellen Grund, warum du die Konfiguration dann nicht in eine Datenbank packst? Dann kannst du nämlich auch solche Späße machen wie "Es ist Weihnachten, da wird nicht gekämpft, erhöhe die Kosten aller Militärgüter um 50%"

Ich verspüre hier eine Gewissen Antipathie gegen XML. Könnt ihr mir erklären, warum? Es funktioniert prima...

XML ist ein Austausch-Format. Es war nie dazu gedacht, manuell von Menschen getippt zu werden. Auf meiner Tastatur ist das schlicht grausam Und wenn ich Spezialsoftware brauche und mich über Autovervollständigung freue, nur um den Blumenkübel 2 Goldstücke teurer zu machen, läuft was schief.

Ich habe keine Antipathie gegen XML. Ich mag XML als Austauschformat sogar sehr gerne. Aber bitte bitte nur zwischen Maschine und Maschine. Lass Menschen aus dem Spiel, wenn es um XML geht

[Igor der Schreckliche]

Das schreit nach SQL O.o [...] Gibt es einen speziellen Grund, warum du die Konfiguration dann nicht in eine Datenbank packst?

Das war auch meine erste Idee, aber ich habe den ganzen Kram gerade aus der Datenbank verbannt, weil es extrem inperformant ist. Mein Plan, um die Performance zu steigern war die Daten am Spiel-Start einmal in den Speicher zu laden. Außerdem störte mich an der DB, dass die Verwaltung von Einheiten, Plugins, Einheiten-Plugin-Zuordnungen und Waren schon vier Tabellen benötigt. Das war für mich viel schrecklicher zu verwalten als eine XML-Struktur, da ich dort alle Dinge auf einen Blick habe.

Zu sagen, dass man Code-Vervollständigung braucht, um einen Blumentopf teuer zu machen ist auch etwas schwarz-weiß gedacht. Natürlich kann ich den Preis im vi hochdrehen, aber wenn ich neue Einheiten erfassen will, und "<uni" eingebe, und ein komplettes Template da stehen habe ist das schon nett, aber sicher auch nicht das killer-Argument für XML.

Viele Grüße und danke für die schöne Diskussion bis jetzt

Igor

[lunar]

Ich verspüre hier eine Gewissen Antipathie gegen XML. Könnt ihr mir erklären, warum?

Ich wundere mich vielmehr, warum du nach dem Schreiben von 5000+ Zeilen XML immer noch keine Antipathie gegen XML hegst Du willst doch auch nicht ernsthaft behaupten, dass du in einer solch großen Datei (egal in welchem Format) immer "alles im Blick hast"?

XML ist mag ja ein tolles Format sein, wenn Datenaustausch zwischen verschiedenen Anwendungen erforderlich ist, aber kein Schema und keine Validierung der Welt ist es wert, Menschen dazu zu zwingen, derartige Mengen an XML händisch zu bearbeiten. Zumal wir – wie bereits gesagt – ja dann auch eher von Daten als von Konfiguration reden.

Im Übrigen ist die Geschwindigkeit ein zweischneidiges Schwert. In einer WSGI-Umgebung ist die Persistenz des Prozesses nicht garantiert, so dass die Idee, alles im Speicher zu halten, nur bedingt sinnvoll ist. In einer Umgebung mit mehreren Prozessen kann das Parsen dieser Datenmengen häufiger vorkommen als gedacht.

Zum Umgang mit Datenbanken gibt es ja ORMs wie SQLAlchemy, die vieles vereinfachen. Da ist es dann auch mehr oder weniger egal, wie viele Tabellen man benötigt. Zwischen einer komplexen XML-Struktur und einem komplexen Datenbankschema ist nur bedingt ein Unterschied festzustellen.

[Igor der Schreckliche]

Naja, ich geb dir recht, 5000 Zeilen-Dateien sind nie ein Spaß. Aber mit XML hab ich immer noch am wenigsten Probleme damit. Und ich habe alles auf einmal im Blick, was ich an zusammengehörigen Daten ändern muss. Will meinen, eine Einheit, ihre Plugins und ihre Herstellungs-Möglichkeiten stehen alle an einer Stelle, und ich muss nicht 1000x durch die Datei scrollen, um eine neue Einheit anzulegen. Denn das währe genauso schlimm wie vorher, in vier Tabellen Einträge machen, bis ich eine Einheit zusammen gestöpselt habe.

Und ja, es ist sichergestellt, dass trotz mehrerer Threads die XML-Datei nur einmal gelesen wird.

Viele Grüße,

Igor

[lunar]

Und ja, es ist sichergestellt, dass trotz mehrerer Threads die XML-Datei nur einmal gelesen wird.

Ich sprach nicht von Threads, sondern von Prozessen.

[Igor der Schreckliche]

Sollte es dann bei der Umstellung auf irgendwelche Frameworks Probleme geben, müssen die dann halt gelöst werden. Dies ist dann aber unabhänig von der Art der Datenquelle.

[sma]

Igor, ich wollte dir nur spiegeln, wie ein erster Eindruck wirken kann. Rechtschreibung ist ein Problem - ich selbst bin da auch nicht perfekt - aber es gibt Werkzeuge. In der Regel tippe ich Texte wie diesen hier immer mit aktivierter Rechtschreibprüfung. Wenn mein Vorteil falsch war, um so besser.

Mich würde interessieren, warum du Python statt z.B. Java für den Spiel benutzt hast. Wo lagen deiner Meinung nach die Vorteile von Python gegenüber Java?

Thema XML: Speziell in der Java-Welt hat man es IMHO mit XML extrem übertrieben. Wie Defnull schrieb, als Austauschformat hat XML seine Berechtigung (gerade weil es das bis dato allgegenwärtige Encoding-Problem gelöst hat) doch als Konfigurationssprache für Menschen? Es stimmt zwar, dass du mit einem XML-Schema (eine der wohl grausamsten XML-Sprachen, BTW) und einem guten XML-Editor Hilfestellung bekommst, doch das würde ich nicht so stark bewerten. Man vergleiche:

Code: Alles auswählen

<units>
    <unit-type name="Panzer">
        <movement>3</movement>
        <attack>2d8</attack>
        <defense>6</defense>
    </unit-type>
</unit>

units = [
    UnitType("Panzer", movement=3, attack=Dice(2, d=8), defense=6),
]

Auch beim Einlesen der Python-Variante habe ich eine Syntaxprüfung. Mir fliegt das um die Ohren, wenn ich mir dort vertippe und z.B. `movment` statt `movement` benutze. Ich finde die zweite Variante sowohl lesbarer als auch einfacher, denn ich muss jetzt keinen XML-Spezifikationssprachen-Parser bauen, der mir aus den XML-ELementen, die aus dem normalen XML-Parser fallen, jetzt noch Python-Objekte baut. Erkennst du die Mini-DSL für Würfelwürfe, die ich in dem XML noch habe? In Python habe ich diese auch gleich aufgelöst, ohne das es negativ auffällt.

Und ein Tools wie JAXB von Java ist mir für Python nicht bekannt, selbst wenn man es sich relativ einfach bauen könnte. Doch wozu, wenn Python-Objekte selbst schon ausdrucksstark genug sind.

Wenn ich lese, dass die Konfiguration 5000 Zeilen hat und da Blöcke immer wieder kehren, ist das für ich eher ein Indiz für eine falsche Abstraktion. Kann man da nicht etwas zusammenfassen? Oder Vererbung zur Typisierung nutzen?

Eine DB für eine derartige Konfiguration die nur gelesen, aber nie verändert wird zu nutzen, wie Defnull vorschlug, würde ich nicht empfehlen. Allgemein gilt YAGNI. Nicht mögliche Features auf Vorrat definieren, sondern auf das wesentliche konzentrieren.

Zum Thema Hosting: Github (ich bin ja auch git-Fan) wurde schon erwähnt, Bitbucket wäre das Äquivalent für Mercurial (Hg). Ich finde auch Googles Angebot sehr interessant. Dort kann man entweder traditionell SVN benutzen oder Mercurial. Sourceforge war ja mal der defacto-Standard, hat dann aber verloren. Inzwischen sind die am Modernisieren ihrer Plattform und vielleicht ist ja auch dies einen Blick wert. Ein einfachsten (wenn man git oder hg nicht kennt) ist wohl http://code.google.com/intl/de-DE/projecthosting/ mit Subversion.

Was das Spiel angeht: Hast du eine Spezifikation der Regeln und internen Abläufe oder gibt es nur den Code? Ich kann mir ehrlich gesagt noch nicht so recht vorstellen, was man bei dem Spiel eigentlich machen soll. Wie würdest du das in einem Satz oder Absatz zusammenfassen? So in der Art "Bei diesem Spiel streiten 4 Mitspieler um die Vorherrschaft der Galaxis indem sie Raumflotten bauen und damit Planeten erobern, dort Ressourcen abbauen, mit denen neue Raumschiffe gebaut werden können."

PS: Ich muss natürlich noch Django als Webrahmenwerk der Wahl erwähnen :) Soll der Server permanent laufen (so wie ein Java-App-Server) weiß ich allerdings bislang keinen guten Rat. Vielleicht kann man das mit CherryPy machen, vielleicht bräuchte man einen eigenen Server. Python-Webrahmenwerke funktionieren (in diesem Falle leider) eigentlich immer mach dem CGI-Prinzip und das Programm lebt nur einen Request lang.

Stefan

[Igor der Schreckliche]

Hallo Stefan,

deine Kritik ist auch als konstruktive Kritik bei mir angekommen. Ich hoffe, dass konnte ich auch so wiedergeben. Auch wenn ich etwas schlucken musste, als ich deine Meinung zu meiner Rechtschreibung las, muss ich dir doch recht geben, und hab das als Grund genommen, noch mehr auf meine Rechtschreibung zu achten.

Warum ich Python gewählt habe, habe ich glaube ich schon ausgiebig erklärt: Weil ich es lernen will, und learning by doing meiner Meinung nach eine der besten Methoden ist.

Zu deinem Klassen-Beispiel:
die im XML enthaltenen Daten werden auch alle zu solchen Objekt-Instanziierungen gemapped. Während des Spieles ist XML komplett raus. Es wird nur am Anfang eingelesen und zu Objekten umgesetzt. Es wird wirklich nur als Speicher-Format verwendet, welches aber vom Designer zu bearbeiten ist.

Deinem Beispiel möchte ich kurz ein Beispiel aus der XML entgegensetzten:

Code: Alles auswählen

<unit_type id="129" name="Forstwirt">
			<beschreibung></beschreibung>
			<type>building</type>
			<textur>/pic/buildingtype/foerster.png</textur>
			<max_health>10</max_health>
			<unit_size>1</unit_size>
			<fremd_plugins>
				<plugin id="64" name="CreateUnitForstwirt" class="CreateUnitPlugin">
					<units>
						<id>128</id><!-- Forstwirtschafts-Hütte -->
					</units>
					<properties>
						<property name="unittype_id">129</property>
						<property name="need_time">6</property>
						<property name="railpoint_offset_y">1</property>
						<property name="railpoint_offset_x">0</property>
						<property name="cost_0">1</property>
						<property name="cost_3">-1</property>
						<property name="cost_1000">1</property>
						<property name="parallel_build">1</property>
					</properties>
				</plugin>
			</fremd_plugins>
			<plugins>				
				<plugin_ref id="71"/><!-- ProduceBaumstamm1 -->
				<plugin_ref id="32"/><!-- ProduceBaumstammEdelholz1 -->
				
				<plugin_ref id="0"/><!-- MovingByFeet -->
				<plugin_ref id="4"/><!-- ViewRange1 -->
				<plugin id="65" name="TerraFormingWald2Land" class="TerraFormingPlugin">
					<properties>
						<property name="target_field_type">1</property>
						<property name="need_time">2</property>
						<property name="terraform_label_name">Wald abholzen</property>
						<property name="cost_110">-15</property>
						<property name="source_field_type">3</property>
					</properties>
				</plugin>
				<plugin id="63" name="TerraformingLand2Wald" class="TerraFormingPlugin">
					<properties>
						<property name="target_field_type">3</property>
						<property name="need_time">1440</property>
						<property name="terraform_label_name">Wald pflanzen</property>
						<property name="source_field_type">1</property>
					</properties>
				</plugin>
				<plugin id="11" name="TerraformingHügelwald2Hügelland" class="TerraFormingPlugin">
					<properties>
						<property name="source_field_type">5</property>
						<property name="target_field_type">2</property>
						<property name="need_time">2</property>
						<property name="terraform_label_name">Hügel-Wald abholzen</property>
						<property name="cost_110">-15</property><!-- Baumstämme -->
					</properties>
				</plugin>
				<plugin id="19" name="TerraformingRegenwald2Grassland" class="TerraFormingPlugin">
					<properties>
						<property name="source_field_type">4</property>
						<property name="target_field_type">1</property>
						<property name="need_time">2</property>
						<property name="terraform_label_name">Regenwald abholzen</property>
						<!-- TODO: Edelholz-baumstämme! -->
					</properties>
				</plugin>
			</plugins>
		</unit_type>

Dieses Beispiel gehört nicht zu den Komplexesten. Zu möglicherweise falschen Abstraktion kannst Du dir anhand dieses Beispiels auch deine Meinung bilden. Verbesserungsvorschläge sind immer willkommen. Ich sprach auch von Blöcken mit immer der selben Struktur, nicht von C&P-gleichen Blöcken. Du kannst dir sicher vorstellen, dass jede Einheit einen Block der oben gesehenen Struktur hat, die inhaltlich aber alle unterschiedlich sind.

Was das Spiel-Prinzip angeht: Es geht darum, in einer Echtzeit-Strategie eine realitäts-nahe Wirtschaft aufzubauen, und diese mittels Militär gegen andere Spieler zu verteidigen. das Militär muss dabei aus der Wirtschaft finanziert und produziert werden. Konflikt-Punkte sind dabei Ressourcen, die auf dem Spielfeld vorkommen, die als Grundlage für die Wirtschaft dienen.

Danke für deine Antwort, ich freue mich sehr darüber, über mein Machwerk zu diskutieren

Viele Grüße,

Igor

[Redprince]

Dein Beispiel ist offensichtlich komplexer als das, welches sma zuvor angeführt hat, aber das verhindert ja nicht, dass du diese Konfiguration ohne XML-Umweg direkt in in Python schreibst!

Irgendwie schreckt mich dein Beispiel des Umfangs wegen ziemlich ab. Bist du dir sicher, dass das Spiel in der momentan geplanten Form aufgrund des Resourcenreichtums und der Möglichkeiten nicht schlichtweg zu unübersichtlich ist, weil es an jeder Stelle der Verarbeitung von Rohstoffen viel zu viele mögliche Abzweigungen gibt? Weniger ist ja oftmals mehr

[Igor der Schreckliche]

Hallo Redprince,

natürlich lässt sich auch diese Struktur in python abbilden. Aber ob dann der Übersichtlichkeits-Bonus noch gilt, den Stefan dargestellt hat möchte ich bezweifeln.

Deinen Einwand die Unübersichtlichkeit betreffend verstehe ich ehrlich gesagt nicht so ganz. Sicher ist es komplex, das ist auch von mir durchaus gewünscht, da es notwendig ist, um eine eingermassen realitätsnahe Abbildung hinzubekommen. Unübersichtlichkeit versuche ich zu vermeiden, indem alles, was mit einer Einheit zu tun hat an einer Stelle definiert ist. Dazu gehört die Einheit selber, die Erschaffung der Einheit (was wieder eine Fähigkeit einer anderen Einheit ist), sowie die eigentlichen Fähigkeiten der Einheit.

Was meinst Du mit Abzweigungen für Rohstoffe?

Viele Grüße,

Igor

[Redprince]

Ich habe aus deinem Beispiel geschlossen, dass allein der Forstwirt zwei Dinge produziert und vier verschiedene Dinge erschaffen/formen kann. Übertragen auf viele weitere Rohstoffe mit ähnlich vielen Optionen stellt sich mir die Frage, wie man als Endbenutzer Entscheidungen trifft, was man wozu formt, welchen Rohstoff man bevorzugt etc.

Kurz gesagt: Was verhindert bei dieser Fülle von Möglichkeiten, dass man davon schlichtweg erschlagen wird?