verdammt, ich kapier es einfach nicht

Fragen zu Tkinter.
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

derkai hat geschrieben:ok, Farbe ist vorerst auch fertig :

Code: Alles auswählen

    farbe = ("#F6C783","#F6C783","#F6C783",         
             "#F6C783","#F6C783","#F6C783",                     #hellbaun
             "#F6C783","#F6C783","#F6C783",                     
             "#F6C783","#F6C783","#F6C783",
             "#F6C783","#F6C783","#F6C783",
             "#18C85A","#A0A6F5")                               #gruen,blau
      
Kai
Dann mach es doch wenigstens so:

Code: Alles auswählen

farbe = ("#F6C783",)*15+("#18C85A","#A0A6F5")
derkai
User
Beiträge: 169
Registriert: Montag 12. Mai 2008, 11:43

ja, das ist viel besser. schon geändert

Gruß
Kai
imac
20 Zoll
2,4 ghz
Benutzeravatar
~Mitneid~
User
Beiträge: 5
Registriert: Samstag 5. Juli 2008, 04:59

Das sieht ja schon ganz schön gut aus!

vielleicht magst Du ja noch zwischen Zeile 58 und 59 noch:

Code: Alles auswählen

master.state('zoomed')# maximiert automatisch das Fenster aus Vollbild
master.overrideredirect( 1 )# die Kopfzeile wird entfernt (mehr Platz :-) )
Vielleicht sagt Dir ja eines von beiden zu. Das Fenster läßt sich nach overridedirect mit "Alt F4" Taste wieder schließen, bis man einen Mechanismus gebastelt hat, um auf andere Wege das Fenster zu schließen.
ausserdem könnte man den Hintergrund noch einfärben

Code: Alles auswählen

 spiel = tk.Canvas(master, width=1024, height=768,bg="yellow")# kannst ja mal ein paar Farben probieren..

natürlich nur wenn Du magst.. ist ja Dein Blumenkohl :wink:
Der Mensch ist weder Engel noch Tier, und das Unglück will es, dass, wer einen Engel aus ihm machen will, ein Tier aus ihm macht.
Blaise Pascal (1623-1662)
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

Code: Alles auswählen

master.state('zoomed')# maximiert automatisch das Fenster aus Vollbild
master.overrideredirect( 1 )# die Kopfzeile wird entfernt (mehr Platz :-) )
Die Geschichte mit dem "zoomed" funktioniert bei mir nicht:

Code: Alles auswählen

Traceback (most recent call last):
  File "nixnix.py", line 4, in <module>
    master.state('zoomed') # maximiert automatisch das Fenster aus Vollbild
  File "../python2.5/lib-tk/Tkinter.py", line 1594, in wm_state
    return self.tk.call('wm', 'state', self._w, newstate)
_tkinter.TclError: bad argument "zoomed": must be normal, iconic, or withdrawn
yipyip
User
Beiträge: 418
Registriert: Samstag 12. Juli 2008, 01:18

Hallo Leute,
sorry, wenn ich mich hier einmische.
:D
Ich verfolge diesen Thread schon seit 3 Tagen.
Gestern Nacht juckte es mich derart in den Fingern, dass
ich nicht umhin kam, endlich auch so ein Hexfeld Programm
zu schreiben.

Inspiriert von wuf's code bin ich
(vorlaeufig) auf Folgendes gekommen...

Code: Alles auswählen

#!/usr/bin/env python

####

import Tkinter as tk
from math import sin, cos, pi
import random as rand

####

def unit_poly(n):

  delta = 2 * pi / n
  return([(cos(i * delta), sin(i * delta)) for i in xrange(n)])

####

def scale_poly(x_scale, y_scale, poly):

  return [(x_scale * x, y_scale * y) for (x, y) in poly]

####

def trans_poly(x_tr, y_tr, poly):

  return [(x_tr + x, y_tr + y) for (x, y) in poly]

####
          
def int_poly(poly):

  return [(int(x + 0.5), int(y + 0.5)) for (x, y) in poly]

####
          
def draw_hexes(cv, x_offset, y_offset, x_delta, x_max, y_max,
               colors, distrib):

  poly = unit_poly(6)
  x_delta3 = x_delta / 3.0
  x_delta2 = x_delta / 2.0 
  y_delta = sin(pi / 3.0) * x_delta3 
  
  poly = scale_poly(x_delta3, x_delta3, poly)

  x_max1 = x_max - 1
  even_odd = 1
  
  for iy in xrange(y_max):
    even_odd ^= 1
    y_pos = y_offset + iy * y_delta

    for ix in xrange((x_max, x_max1)[even_odd]):
      x_pos = x_offset +  ix * x_delta + (0, x_delta2)[even_odd]
      col = colors[rand.choice(distrib)]
      draw_poly(cv, int_poly(trans_poly(x_pos, y_pos, poly)), col)

####

def draw_poly(cv, poly, col, bordcol='#000000'):
  
  cv.create_polygon(poly, fill=col, outline=bordcol)

####

def distribute(weights):
  '''generate a list for weighted color indices'''
  
  return reduce(lambda x, y: x + y,
                [[i] * w for i, w in zip(xrange(len(weights)), weights)])

####

def main_hex(**conf):

  root = tk.Tk()
  hexfield = tk.Canvas(root, width=conf['width'], height=conf['height'],
                       bg=conf['backcol'])
  hexfield.pack()

  # make the hexfield reproducible
  startseed = conf['startseed']
  if startseed:
    rand.seed(startseed)
    
  draw_hexes(hexfield, conf['x_offset'], conf['y_offset'],
             conf['delta'], conf['x_max'], conf['y_max'],
             conf['colors'], distribute(conf['weights']))
  
  root.mainloop()
                       
####

the_conf = {'width': 800,
            'height': 600,
            'backcol': '#000000',
            'x_offset': 15,
            'y_offset': 15,
            'delta': 22,
            'x_max': 36,
            'y_max': 91,
            'colors': ['#00ff00', '#ffff00', '#00ffff'],
            'weights': [8, 3, 2],
            'startseed': 1}

####
  
if __name__ == '__main__':

  main_hex(**the_conf)

####
@ derkai:
Ich weiss, das Obiges ein bisschen arg komprimiert fuer Dich ist.
Falls Du jedoch weiter machst wie bisher,
hast Du spaetestens nach 600 Zeilen
den Ueberblick verloren.
(Ist wirklich nicht boese gemeint :wink: )
Daher wuerde ich Dir raten, noch etwas mehr Zeit in die Strukturierung Deines Programmes zu investieren,
und genau zu ueberlegen, welche Datenstrukturen,
Funktionen, usw. du brauchst und wie diese interagieren sollen.

...ach so, der 1. Entwurf ist meistens fuer die Tonne,
ist auch bei mir so... :wink:

Bitte nimms mir nicht uebel...
:wink:
LG yipyip
derkai
User
Beiträge: 169
Registriert: Montag 12. Mai 2008, 11:43

schon in Ordnung, schön dass es auch alte Hasen juckt.

Ich bin ja froh, dass ich für den Moment noch vieles verstehe,
daher ist an eine Komprimierung für mich im Moment noch
wirklich nicht zu denken.

Wenn diese Modul mal alles kann, was ich so benötige, dann
werde ich das in Angriff nehmen.

Das mit dem Zoomen ist für den Moment noch nicht so interessant,
da das Spielfeld am Ende mehr als doppelt so groß wie Stand heute werden wird. Da werde ich dann wohl noch Scrolbalken einfügen müssen.

Kai
imac
20 Zoll
2,4 ghz
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

@yipyip:

Dein Code enthält interessante (neue) Ansätze, manche davon sicher bedenkenswert.

Die Sache mit int_poly() ist aber z.B. überflüssig. Die Canvas-Zeichenmethoden kommen auch mit Fließkommawerten zurecht.

Das mit dem even_odd gefällt mir nicht; dass man den alternierenden Ablauf eleganter lösen kann als mit einer wechselnden Indexierung einer eigens dafür aufgesetzten Sequenz, wurde in diesem Thread ja schon gezeigt.
yipyip
User
Beiträge: 418
Registriert: Samstag 12. Juli 2008, 01:18

...das wusste ich nicht, das Tkinter da auch Fliesskommazahlen schluckt...
Vielleicht kann man's ja dann fuer eine andere Graphikbibliothek brauchen.
:-)

Das Bit-toggeln stammt wohl noch aus meiner
C-Vergangenheit.
Ich halte das im Vergleich zur
Modulo-Rechnung aber
nicht fuer sooo vollkommen unelegant.

(...an der Stelle passte es mir besser ins Gesamtkonzept...)

LG yipyip
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

yipyip hat geschrieben:Das Bit-toggeln stammt wohl noch aus meiner
C-Vergangenheit. Ich halte das im Vergleich zur
Modulo-Rechnung aber nicht fuer sooo vollkommen unelegant.
Mir ging es ja nicht um die Bit-Geschichte, sondern um das künstliche Aufsetzen einer Sequenz um den alternierenden Zugriff zu realisieren. Wer lieber mit Bits als mit modulo arbeitet, kann die Zeile, auf die du dich beziehst, ja auch so schreiben ... :wink:

Code: Alles auswählen

ypos = yorg + (not x&1)*0.5*yoffset
Benutzeravatar
wuf
User
Beiträge: 1529
Registriert: Sonntag 8. Juni 2003, 09:50

Hallo yipyip

Herzlich willkommen im Sub-Forum der Programmierkünstler. Es ist nett von dir, dass du hier dein super Code-Snippet veröffentlichst. Hut ab! Natürlich freut es uns auch speziell, dass du ein GUI-Toolkit einsetzt das uns auch bekannt ist. Hier ist jedes Code-Snippet willkommen. Da jedes geschriebene Stück Code Wissen bereitstellt, welches beim optimieren des Projekt-Codes einfliessen kann.
yipyip hat geschrieben:Gestern Nacht juckte es mich derart in den Fingern, dass
ich nicht umhin kam, endlich auch so ein Hexfeld Programm
zu schreiben.
Es ist Absicht, dass dieses doch schon längere Thema zum 'jucken' reizt.

P.S. Be aware you are working with an outcasted GUI-Toolkit :lol:

Für mich ist dein Beitrag fast ein bisschen 'suspect'! Dein Super-Code, die brauchbaren Anregungen und dies schon bei deinem ersten Forum-Beitrag. In anderen Worten möchte ich dich als 'Under Cover Agent' entlarven. Das heisst du könntes dir als Mitglied, welches schon länger diesem Forum angehört, einen zweiten Benutzer-Namen zugelegt haben um hier nicht aufzufallen. :lol:

Es war nur Spass und nicht so gemeint. :wink:
yipyip hat geschrieben:Daher wuerde ich Dir raten, noch etwas mehr Zeit in die Strukturierung Deines Programmes zu investieren,
und genau zu ueberlegen, welche Datenstrukturen,
Funktionen, usw. du brauchst und wie diese interagieren sollen.
Ja schon aber ich würde dies nur unter Einbeziehung des Target-GUI-Toolkit befürworten.

Es stimmt gewisse Leute haben ein Problem mit Programmen deren Code-Zeilen eine bestimmte Anzahl übersteigt. Das hängt aber nur von der Darstellung und Dokumentation des Skriptes ab. Für mich kann ein Skript 50 oder 10'000 Zeilen haben, sofern es mit einer überblickbaren Struktur aufgebaut ist. Eine Gefahr sind lange kommentarlose 'Einzeiler', welche mit Logik und Mathematik verlinkt sind. Da fragt man sich manchmal, wo ist die gute Lesbarkeit des Pythoncodes geblieben. Damit hätte ich auch Mühe nicht nur nach 600 sondern schon weniger Zeilen den Code in kurzer Zeit zu verstehen. OK das ist eine rein persönliche Sache. Es kommt darauf an in welchem Umfeld jemand aufgewachsen ist.

Ich habe auch schon versucht mich in Sourcen von Programmen einzuarbeiten die aus vielen Subsourcen bestanden. Bei der ersten Source mit zwei 'include' Statements dachte ich noch ist kein Problem es sind ja nur zwei weitere Dokumente. Aber beim durchlesen dieser zwei Subsourcen wurde mir schnell einmal klar das dies noch lange nicht das Ende ist. Auf der ersten Subsource standen vier weitere 'include' Statements und auf der zweiten Subsource standen sogar 10! weitere 'include'-Statements und so ging es weiter den ganzen Baum hinunter. Da möchte einmal dabei sein, wenn sich ein Neuling einarbeiten muss.

OK. yipyip willkommen im Forum und noch alles Gute wuf :wink:
Take it easy Mates!
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Numerix Ansatz kann man mit Booleans noch etwas erweitern:

Code: Alles auswählen

>>> (not True)*0.5
0.0
>>> (not False)*0.5
0.5
>>> 
yipyip
User
Beiträge: 418
Registriert: Samstag 12. Juli 2008, 01:18

Mit den Sequenzen kann ich die benoetigten Parameter
schon vor der zeitkritischen Hauptschleife berechnen.

Ich denke, sowas wie

Code: Alles auswählen

half_yoffset = yoffset / 2.0
....
for...
    ypos = yorg + [0, half_yoffset][togglebit]
sollte etwas schneller sein als

Code: Alles auswählen

for...
    ypos = yorg + togglebit * 0.5 * yoffset
Ausserdem finde ich es sogar praktischer und uebersichtlicher.

Aber ich weiss, Python ist nicht der Ort, wo man
um Prozessortakte feilscht.
;-)
LG yipyip
Benutzeravatar
wuf
User
Beiträge: 1529
Registriert: Sonntag 8. Juni 2003, 09:50

Hallo Midneid

Code: Alles auswählen

master.state('zoomed')# maximiert automatisch das Fenster aus Vollbild
Mit dem habe ich die gleichen Probleme wie 'numerix'. Mein OS hier ist SuSE 10.0 Linux.
Du verwendest vermutlich Windows?

Ich hole mir die Schirmabmessungen mit den Methoden:

Code: Alles auswählen

master.winfo_screenwidth()
master.winfo_screenheight()
Gruss wuf :wink:
Take it easy Mates!
yipyip
User
Beiträge: 418
Registriert: Samstag 12. Juli 2008, 01:18

Hach Leute...
ich wollte hier doch keine Lawine lostreten...
:D
Erstmal vielen Dank fuer die tolle Begruessung!
Ihr macht einen ja ganz verlegen...
;-)

Zuerst muss ich jedoch was klarstellen:
Bin weder ein Code-Guru noch Sonstwie-Experte,
Leuten wie 'BlackJack' oder vielen anderen kann
ich garantiert nicht das Wasser reichen.
(Programmiere in Python erst seit
knapp einem 3/4 Jahr)
Ich bilde mir jedoch ein, ein gewisses
Grundverstaendnis fuers Programmieren
zu besitzen.

Da mich das Thema reizte und ich befuerchtete,
dass derkai noch weiter ins Schwimmen geraet,
wollte ich das Ganze etwas
in die 'richtigere' Richtung lenken.

Mit den '600 Zeilen' wollte ich eigentlich ausdruecken,
dass derkai sich mehr mit den Grundlagen
auseinandersetzen sollte, etwa im Stil von
http://www.htdp.org/2003-09-26/Book/
(Nein, ich habs auch noch nicht gemacht :wink: )
Sowas wie Tkinter sollte erst viel spaeter folgen.

Womit wir beim naechsten Thema waeren:
Ich mag Tkinter bzw. das TK! :-)
(...auch wenns unsexy ist...
...und Totgesagte leben meistens laenger...)

'It fits my brain' , weil es nicht der C++ Denkweise
in WxPython entspricht (hab letzteres aber nur kurz angelesen).

Das 'zoomed' funktioniert bei mir uebrigens auch nicht.
(Ubuntu 8.04, Python 2.5.2)

So, das waers fuers erste.
(Nein, ich hab hier wirklich keinen anderen Account...)
:wink:

Goodnight
yipyip
derkai
User
Beiträge: 169
Registriert: Montag 12. Mai 2008, 11:43

tja, also irgendwie fehlt mir wieder einmal der entscheidende Hinweis ?

ich möchte ein Dictionary erzeugen :
feld_liste {}

dieses soll dann foglende Werte bei jedem Schleifendurchlauf erhalten
(UND DAS ERST EINMAL WIEDER VÖLLIG SIMPEL UND MIT ZU VIEL CODE)

INDEX :
- Index soll bsp so aussehen : (Zeile/Reihe) 01 + (Feld Nr.) 14 = INDEX
0114 (das soll dann eben logischer Weise das 14 te Feld der Reihe 1
bedeuten)
WERTE :
- x1,y1 ... x6,y6
- Farbe
- spätere Eigenschaften, die die Felder der unterschiedlichen Farbe
erhalten werden

meine Schleife sieht ja bekanntlich so aus :

Code: Alles auswählen

    for feld in range(1,3):

        if spalten_nummer == UNGERADE :

            for f in range(ungerade_spalten):
                create_hex_polygon(spiel,xpos,ypos,hex_point_list,farbe)
                xpos = xpos + (xoffset *2)
            spalten_nummer = GERADE
            xpos = xorg + xoffset
            ypos = ypos + yoffset / 2

        else :
            
            for f in range(gerade_spalten):
                create_hex_polygon(spiel,xpos,ypos,hex_point_list,farbe)
                xpos = xpos + (xoffset *2)
            spalten_nummer = UNGERADE
            xpos = xorg
            ypos = ypos + yoffset / 2         
Jetzt ist aber das Problem, dass sich die XY Werte ja in der Funktion
create_hex-polygon befinden und "nur" als Rückgabewerte zur Verfügung
stehen. Es ist doch aber richtig, dass eine Funktion nur EINEN Rückgabeaufrug haben kann, oder ?

mit feld_liste [f] = hex_ponit

könnte ich beispielsweise das Dictionary füllen.

Wie sage ich nun aber, dass der INDEX/KEY "F" eine Kombination
der Zählervariablen der Schleifen "feld" + "f" ist ?

Mal nebenbei gefragt, welche Auskünfte erhalte ich eigentlich über
die jeweilige ID ? Hilft mir die hier vielleicht weiter ?

Mit für Eure Geduld dankenden Grüßen

Kai
imac
20 Zoll
2,4 ghz
Benutzeravatar
wuf
User
Beiträge: 1529
Registriert: Sonntag 8. Juni 2003, 09:50

Hallo derkai

Ich hätte vorab einige Fragen zu deinem Spiel:

a) Ist das Spiel, dass du entwickelst eine eigene Erfindung oder ist es ein Spiel das in der Öffentlichkeit bekannt ist und gespielt wird? Hat es einen Namen?

b) Hast du, oder gibt es eine Spielanleitung hierfür? Mir ist das Spiel noch nicht bekannt.

c) Wie werden die einzelnen Sechsecke auf dem Spielfeld selektiert? Werden sie mit einem Mausklick, mittels Tastatur oder über das Programm direkt selektiert? Was passiert mit den selektierten Sechsecken während des Spielablaufes? Werden sie mit der Maus, Tastatur oder durch das Programm verschoben?

Gruss wuf :wink:
Take it easy Mates!
BlackJack

Soweit ich das verstanden habe geht es um eine Art BattleTech, also ein Brettspiel, wo man Kampfroboter, Panzer und ähnliches auf einer Karte mit hexagonalen Feldern bewegt. Implementierung in Java: http://megamek.sourceforge.net/idx.php?pg=main

Und ich muss *wieder* sagen: Das Projekt wird hier IMHO am falschen Ende begonnen. Die GUI sollte als letztes oben aufgesetzt werden und Objektorientierung ist Grundvoraussetzung um das ordentlich umsetzen zu können. Man braucht eine ordentliche Datenstruktur um die Karte programmintern, ohne Grafik, repräsentieren zu können und die für's Spiel notwendigen Abfragen und Manipulationen vornehmen zu können. Also zu Beispiel Koordinaten über die man die einzelnen Felder ansprechen kann, und die Möglichkeit Nachbarfelder zu ermitteln.
derkai
User
Beiträge: 169
Registriert: Montag 12. Mai 2008, 11:43

es ist bzw. soll eine Abwandlung des uralten Brettspiels Battle Tech werden. Allerdings und der Einfachheit halber nicht mit Robotern, sondern mit Panzern.

Diese werden erst einmal nach dem Gewicht in Tonnen unterschieden.
Je nach eingebautem Reaktor resultiert daraus eine mögliche Bewegungsrate. Will heissen, es wird unterschieden ob die Panzer
sich bsp 3 Felder (langsam), oder 5 Felder (schnell) bewegen können.

Je nach Anzahl der zurüchgelegten Feldern entscheidet sich dann, welche zusätzliche Vorgabe für den Gegner aus der eigenen Bewegung resultiert.
Vorgabe beduetet, welche Zahl der Gegner würfeln muss, um mit einer abgefeuerten Waffe einen Treffer zu erzielen. Jede Waffe, und darin unterscheiden sich die Panzer dann im weiteren, kann eine kurze, mittlere und lange Reichweite schiessen. Dies wird in der Anzahl der Felder zum Gegner gemessen und ist wiederum je Waffenart und Waffe unterschiedlich.
Es gibt Laser, Raketen usw....

Durch meine eigene Bewegung und das abfeuern der Waffen wird im Panzer Hitze / Wärme aufgebaut. Diese werden durch s.g. Wärmetauscher intern auch wieder abgebaut. Allerdings reicht die Anzahl der Wärmetauscher meist nicht aus, um die Bewegung und das Abfeuern aller Waffen wieder abzubauen. D.h. ich muss mich entscheiden, was ich tun möchte. Übersteigt die Hitze definierte Werte, so ergeben sich wieder Konsequenzen bsp auf die eignene Bewegung der nächsten Spielrunde, oder es die Möglichkeit mit einer Waffe zu treffen erschwert sich.

Bei den Teffern verhält es sich so, dass zuerst die äußere Panzerung, die man am besten mit der Anzahl bestimmter Panzerwerte :
vorne, links, rechts, hinten und dem Turm
beschrieben könnte.
Sind diese Panzerwerte aussen verbraucht, existieren noch weitere
Panzerwerte intern. Im Unterschied zur äußeren Panzerung verbergen sich hier aber auch die :
- Waffen
- Reaktoren
- und weitere Dinge, die ein Panzer zum "leben" braucht.
Wird also die Interne Panzerung getroffen, so muss dann zusätzlich geprüft werden, ob internen Schaden angerichtet wurde, oder nicht.
Wenn ja, also wenn bsp die Wafffer : Laser getroffen wurde, so steht diese bei der nächsten Spielrunde eben einfach nicht mehr zur Verfügung. komlizierter wird es bei bei einem Treffer des Reaktors. Den ersten steckt man noch gut weg, es ergeben sich aber Auswirkungen auf diee mögliche Bewegung.

Das Spiel findet in Zyklen statt.

1. Bewegungsphase
d.h. jeder Spieler, jeder Panzer wird auf dem Spielbrett gemäß
seinen Möglichkeiten bewegt.
2. Waffenphase
1. der Computer muss aus verschiedenen Faktoren berechnern, welche
Zahl zu erwürfeln ist um den Gegner zu treffen. Dies ist wie oben
beschrieben je Waffe unterschiedlich
2. Der Spieler muss entscheiden, welche Waffen er einsetzen möchte
3. es wird je Waffe gewürfelt, ob diese trifft.
4. wenn beispielsweise eine Waffe, wie eine Raketenlaffette trifft,
muss zusätzlich ermittelt werden, wie viele der abgefeuerten Raketen
treffen
3. Schadensphase
5. Die Treffer beim Gegner werden verarbeitet
6. Es müssen die Konseauenzen der Treffer ermittlet werden

es beginnt eine neue Spielrunde. Ich weiss, dass die für Erwachsene ziemlich lächerlich klingt, aber es soll nun einmal mein Projekt werden.
Anspruchsvoll genug sollte es sein.

Die Panzer auf dem Feld werde nicht durch die Maus bewegt. Es wird bestimmte button auf einem Canvas geben, genau genommen drei.
Eins, für eine Linksdrehung (kostet einen Bewegungsprunkt) eins für nach recht und ein dritter Button für die Bewegung ins nächte Feld. Bei jeder Bewegung läuft einer Zähler mit und ermittelt somit automatisch die maxmal mögliche Bewegung, aber auch die Anzahl der zurückgelegten Felder...

So, ich hör jetzt erst einmal auf ...

Kai
imac
20 Zoll
2,4 ghz
derkai
User
Beiträge: 169
Registriert: Montag 12. Mai 2008, 11:43

ach so, eine Kleinigkeit viellicht noch :

Für die Bewegung sind die Farben der Felder gedacht. Bewege ich mich
ausschliesslich auf "normalem" Boden, so gilt für die Bewegung, dass jede Drehung, oder das Betreten eines neuen Feldes einen Bewegungspunkt kostet.

Bewege ich mich aber von "normalem" Terrain in den Wald (grün), so
kostet die Bewegung IN DAS Feld einen zusätzlichen Bewegungspunkt.

Nur damit klar wird, warum auch die Farbe eines Feldes später auslesbar
sein muss.

@ BlackJack
Du wirst sich Recht haben mit Deiner Behauptung, dass dies auf einen Programmierprofi sehr wirr aussehen mag. Mit Sicherheit werde ich auch nach einer Weile diverse Fehler finden und neu beginnen müssen. Aber wie soll ich etwas lernen, wenn ich den Fehler nicht machen darf ??? Es geht mir eben nicht darum hier nur einfach Code zu übernehmen, sondern ihn auch zu verstehen. Zu diesem Zweck lese ich alles in diversen Büchern zu Python nach. Allerdings ist Bücher lesen eben doch nur Theorie. Deswegen möchte ich ja an Hand dieses meinen Projektes lernen. Mag sein, dass ich mich damit übernommen habe. Wahrscheinlich sogar. Aber für den Moment möchte ich daran weiter arbeiten und freue mich riesig über die vielen Meinungen, Anregungen und Tips aus diesem Thread

Nix für Ungut

Kai
imac
20 Zoll
2,4 ghz
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Probier doch einfach mal, dich nicht von der GUI-Seite zu nähern und schau wie weit du kommst. Lernen bedeutet ja nicht unbedingt, alle Fehler selber mal zu machen, sonder auch Fehler andere mit einzubeziehen ;-) Das der Weg über die Logik hin zur GUI besser ist wirst du dann ebenso feststellen.

Du könntest vielleicht noch mal deinen letzten Post anschauen: da hebst du zum Beispiel als wichtig hervor, dass du die Farbe eines Feldes auslesen können musst um auf einen Wald schließen zu können. Das ist schon sehr typische GUI-Sicht. Wär es nicht sinnvoller, Felder als das zu speichern was sie sind? Zum Beispiel "Wald". Dann hat "Wald" eine Farbe und bestimmt diese in der GUI.
Antworten