HeldenGenerator für "Das Weltenbuch"

[yipyip]

ups, zuuu spät...

yipyip

[cofi]

ups, zuuu spät...

yipyip

Wobei das String-Formating viel schöner ist

[yipyip]

Wobei das String-Formating viel schöner ist Smile

...kommt immer drauf an...
Hatte mich nur spontan für '%s...' % (... ) entschieden,
weil ich's manchmal übersichtlicher finde.


yipyip

[Leonidas]

Das String-Formatting ist eigentlich immer schöner, weil es nicht-Strings von selbst nach bestimmten Regeln in Strings konvertiert und in die Strings einsetzt.

[yipyip]

ACK!

yipyip

[Hyperion]

Eher nicht. Ein Objekt der Logik-Schicht hat keine Ahnung vom Darstellungsmedium und kann sich deswegen auch nicht "drucken". Dafür ist dann die entsprechende Ansicht in der Präsentationsschicht verantwortlich.

Da es hier um die Stringrepräsentation geht, halte ich das durchaus für sinnvoll. Natürlich nicht im Sinne von grafischer Darstellung aller Art! Da hast Du natürlich Recht. Aber eine __str__() Methode zu haben ist schon sinnvoll imho. Ich hätte das sofort klarer ausdrücken müssen.

[lunar]

Naja, das kommt auch darauf an. Ein Objekt, dass sich sinnvoll in eine Zeichenkette überführen lässt, sollte auf jeden Fall eine __str__ Methode haben. Das kanonische Beispiel wäre eine Zahl ...

Bei einem komplexeren Objekt, dass keine sinnvolle String-Darstellung hat, ist __repr__ besser, um eine Repräsentation der internen Daten zu erzeugen.

[sma]

Mir ist nicht aufgefallen, dass jemand schon das Attribut-Array angesprochen hat. Das würde ich so nicht realisieren. Es ist nicht [0] sondern Geist, nicht [5] sondern Sinne. Daher würde ich hier ein eigenes Objekt vorschlagen:

Code: Alles auswählen

class Attributes:
  def __init__(self, geist, körper, geschick, sozial, wille, sinne):
    self.geist, self.körper, self.geschick, self.sozial, self.wille, self.sinne = ...

held.attributes = Attributes(geist=4, körper=6, ...)
if held.attributes.wille < 5:
  print "Du bist zu willensschwach, um dem Zauber zu widerstehen..."

Falls dich das ö wundert: Wenn's jetzt mit Python losgehen soll, würde ich gleich bei Python 3.0 starten und da kann man alle Buchstaben, die der Unicode-Zeichensatz hergibt, für Namen benutzen. Andernfalls müsste man "koerper" benutzen, was weniger schoen ist.

Stefan

[cofi]

Guter Einwurf, wobei man zum Erzeugen der Attributs-Objekte aber hinzufügen sollte - da es ja rassenspezifische Startattribute gibt, dass man das entweder in einen Wrapper packt, der die Rasse auswertet, oder das über die Attributsklasse löst (evtl weniger schön).

Das mit den Umlauten stimmt schon, die Frage ist aber, ob man nicht generell den Quelltext in Englisch schreiben sollte, da es zum Programmieren eh benötigt wird und da es den einfachsten Schriftsatz hat - auf einer englischen Keymap ein `ü' zu schreiben ist eine sehr lustige Geschichte, wenn man keinen Editor hat, der Digraphen unterstützt .

[Leonidas]

Das mit den Umlauten stimmt schon, die Frage ist aber, ob man nicht generell den Quelltext in Englisch schreiben sollte, da es zum Programmieren eh benötigt wird und da es den einfachsten Schriftsatz hat - auf einer englischen Keymap ein `ü' zu schreiben ist eine sehr lustige Geschichte, wenn man keinen Editor hat, der Digraphen unterstützt .

Ja, ich finde auch dass Umlaute in Bezeichnern alles andere als gewünscht ist. Es mag sein, dass das für sehr beschränkte Sachen nützlich ist. Aber ich habe mir angewöhnt alles in Englsich zu machen: Bezeichner im Code, Kommentare, Dokumentation.

[sma]

Ich habe mir die Regeln nicht so genau angeschaut. Es gibt Rassen, die andere als die sechs Attribute haben? Das fände ich komisch. Aber das Regelwerk soll ja auch komisch=satirisch sein... :)

Etwas, das es nur auf deutsch gibt, jetzt extra nochmal zu übersetzen finde ich doch recht komisch. Wären die Regel ursprünglich englisch gewesen, dann hätte ich mich - einfach weil ich's gewohnter finde - für englisch ausgesprochen. Aber so gilt IMHO die Regel, dass man so nahe wie möglich an der Sprache der Fachdomaine bleiben sollte und deren Begriffe sind nun mal alle deutsch. Und das cofi keine deutsche Tastatur hast, kann doch kein Argument sein ;)

Stëfan

[cofi]

Nuja zumindest aktuell hat er die Attribute in einem Tuple Also entweder wirds in der Klasse entpackt oder im Wrapper.
Das bei der Instanzerzeugung als Argumente zu entpacken dient meiner Meinung nach nicht wirklich der Lesbarkeit.

Ich habe eine deutsche Tastutar - um genau zu sein sogar einen Haufen ... ich hab da einen kleinen Tick - aber man muss sich doch nur mal vor augen halten, dass man mit deutschen Begriffen quasi mit drei Sprachen gleichzeitig jongliert, ausserdem soll Code ja des öftereren Ausbüchsen und sich neue Lebensräume suchen Auch wenn das Regelwerk momentan nur auf deutsch ist.

[gkuhl]

Guten Abend,

haltet ihr für die Attribute wirklich eine weitere Klasse für sinnvoll, ich hätte ich gedacht statt der Tupel ein Dictionory zu verwenden, z.B.

Code: Alles auswählen

hero.attribute["Stärke"] = 5

Dann entfällt vor allem das lästige Übersetzungsproblem. Vor allem wenn ich weiter an die Implementierung der Fähigkeiten denke, wäre ja eine weitere Klasse fällig und damit die Übersetzung aller Fähigkeiten ins Englische. Meiner Meinung ist das eher kontraproduktiv, vor allem weil es keine Garantie gäbe, dass ein potentieller Übersetzer des RPG die gleichen Übersetzungen wählt.

Nochmal zu den Attributen: Es gibt 6 Attribute, die werden der Heldenerstellung leicht modifiziert werden können und im weiteren Spielverlauf weiter steigen können.

Was die Verwendung von Sonderzeichen im Code angeht, will ich mir so was nun wirklich nicht angewöhnen. Vor allem weil gerade im Ausland bin und die einzige deutsche Tastatur ist die von meinem Laptop. Am Ende kriege ich noch lauffähigen Code mit griechischen Buchstaben oder chinesischen Zeichen.


Gerrit

[cofi]

Naja das Übersetzen entfällt nicht wirklich weil du dann auch wieder deutsche Wörter in Code hast. Aber das ist deine Entscheidung.

Falls du noch nicht Python 3 sondern noch 2.x einsetzt solltest du aber daran denken Unicode-Strings zu verwenden:

Code: Alles auswählen

hero.attribute[u"Stärke"] = 5

Ob Dictionary oder eigenes Objekt sollte in dem speziellen Fall - du hast ja keine eigenen Methoden für das Objekt - komplett egal sein. Das Dictionary könntest du auch in deiner config.py verwenden und dann direkt für deinen Code verwenden. Eventuell müsstest du dann aber eine Kopie des Dictionarys benutzen.

[gkuhl]

Okay, das mit dem Übersetzen ist dann nicht wirklich gelöst. Allerdings habe ich dann alle deutschen Wörter in Strings isoliert, gefällt mir dann irgendwie besser. Ich verwende zur Zeit noch die Version 2.5. Python 3 muss ich bei Gelegenheit mal kompilieren.

Zu Unicode: Ist die Verwendung von Unicode-Strings auch noch notwendig, wenn ich folgenden Cookie verwende? Bei mir funktioniert das bis jetzt problemlos.

Code: Alles auswählen

# -*- coding: UTF-8 -*-

[cofi]

Es funktioniert, ja. Aber Python operiert auf String-Literalen mit dem ASCII-Codec was zu "nette" nebeneffekte haben kann:

Code: Alles auswählen

In [14]: a = "stärke"

In [15]: type(a)
Out[15]: <type 'str'>

In [16]: unicode(a)
---------------------------------------------------------------------------
UnicodeDecodeError                        Traceback (most recent call last)

/home/jim/<ipython console> in <module>()

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2: ordinal not in range(128)

[sma]

ich hätte ich gedacht statt der Tupel ein Dictionory zu verwenden

Würde ich nicht empfehlen, denn damit drückst du dich um ein OO-Design. Was wenn du z.B. die Attribute eines Charakters zufällig ermitteln willst. Da wäre doch nett, eine "randomize"-Methode bei "Attributes" zu haben. Und komme mir keiner mit der Idee, eine Unterklasse von dict dafür zu bauen. Wenn es immer nur die gleichen 6 Attribute sind, dann sollten auch auch Attribute eines Objekts sein und nicht Werte, die man sich unter einem Schlüssel merkt. IMHO.

Stefan