Schulprojekt: Spiel "Domino" programmieren!

[He4dnut]

Hallo zusammen!
Ich habe mich ganz frisch angemeldet, da aktuell die Projektarbeit unseres Informatikkurses beginnt. Diese geht über ca. 5 Wochen. Ziel des Projektes ist es eben, eigenständig ein Programm, bzw. Spiel, zu programmieren. Wir haben uns jetzt für das Spiel "Domino" entschieden, ja, das mit den bekannten Dominosteinen ;)

Kurz zu dem Spiel:
Es gibt eine bestimmte Anzahl von den Dominosteinen. Diese Dominosteine haben zwei Seiten, mit jeweils Augenzahlen von 0 bis 4 (für den Anfang). Die Steine werden unter den beiden Spielern aufgeteilt, jedoch nicht alle! Ein Stein wird als Anfangsstein vor die Spieler gelegt. Ein Spieler beginnt und legt einen passenden Stein an eine Seite des Anfangssteines. Ein Stein passt, wenn er auf einer hälfte die selbe Augenzahl wie eine hälfte des Anfangssteines hat. Mit dieser Seite wird der Stein darangelegt. Der nächste Spieler ist an der Reihe. Wenn ein Spieler keinen passenden Stein hat, muss er einen unverteilten Stein ziehen, oder aussetzten, wenn diese bereits alle weg sind. Ein Spieler hat gewonnen, wenn er all seine Steine angelegt hat.

Ich stehe jetzt noch ganz am Anfang. Wir hatten vor, ganz geplant an die Sache ran zugehen. Also dass wir im Vornherein Sachen wie Variablenzuordnung etc bereits bestimmen.
Meine Frage an euch bezieht sich jetzt darauf, wie ich genau anfangen soll. Ich kann mir bisher noch überhaupt nicht konkret vorstellen, wie ich das Spiel programmieren soll. Fakt ist, wir brauchen "2-Seitige" dominosteine. Welches Objekt wähle ich für diese Steine ansich am Besten aus? Buttons? Und dann könnte man diese ja mit zwei Variablen x und y meinetwegen benutzen. Jedem Stein werden diese Variablen zugeordnet. Für einen Stein mit den Augenzahlen 1 und 4 würde man dementsprechend seine Variablen zuordnen. Aber wie kann man einem "Stein" überhaupt Variablen zuordnen? Dann stelle ich mir das so vor, dass der Stein, an den man anlegen muss, bzw die Steinkette ja auch zwei Enden mit x und y hat. Also müsste das Programm überprüfen, ob ein x- oder y-Wert mit dem vom Spieler ausgewählten Stein übereinstimmt, also ob sie die gleiche Augenzahl haben. Ist dieses der Fall kann der Stein angelegt werden. Also wenn man z.B. die 1er Seite eines Steines anlegt, und dieser Stein auf der anderen Seite die Zahl 4 hat, so ist die neue Zahl 4, für die der andere Spieler einen passenden Stein haben muss. Also: wie kriege ich dieses Abgleichen hin, und das "Anlegen" ansich?

Ich bin mir sicher, ich werde noch auf mehrere Fragen stoßen. Leider bin ich noch sehr unerfahren im Programmieren und habe so gut wie keine Ahnung über diese endlos vielen Möglichkeiten. Allgemeine Ahnung vom Programmieren habe ich allerdings schon. Also haben wir z.B. einen Taschenrechner und Umrechnungs-hilfen programmiert im Unterricht.

Ich hoffe ihr könnt mir helfen!
MfG Philip

[Wolfgang Mix]

Erstmal herzlich willkommen in der DP :dp:

Ich bin mir sicher, daß Du hier richtig aufgehoben bist und Hilfe bekommst!
Wenn Du mit Deinen Grundüberlegungen fertig bist, zeige uns 'mal ein bißchen
Code und Stellen, wo es zu haken beginnt.

Grüß

Wolfgang

[ryLIX]

Für die Steine könntest du eine eigene Klasse erstellen die von TObject abgeleitet ist.
Eventuell könntest du die Steine selber zeichnen mit GDI oder mit der G32 Lib.
eigenlich müsstest du nur die Punkte jeweils zeichnen weil der Stein ist ja immer gleich.

[hoika]

Hallo,

TStringGrid mit Grid.Cells[Col,Row]:= '1' .. '4'

Im OnDrawCell wird dann je nach Nummer ein bestimmtes Bild gemalt.


Heiko

[mkinzler]

Dann wäre vielleicht ein TDrawGrid noch besser

[hoika]

Hallo,

da fehlt aber das Cells,
d.h. die Datenhaltung muss man selbst machen
(OK, muss man eh ;) ).


Heiko

[mkinzler]

Die Visualisierung erfolgt eh in einer der späteren Phasen

[Sir Rufo]

Als erstes würde ich empfehlen: "Nicht alles auf einmal machen!"

Teile das Projekt ein:
- Objekte
- Eingabe
- Logik
- Ausgabe

Die Objekte solltet ihr gemeinsam erstellen (so hattest du ja auch geschrieben), denn diese bilden die Basis für eure weiteren Arbeiten, die dann aufgeteilt werden können.

Stellt erst mal zusammen, was ihr alles braucht:

- Dominosteine
- Spielfeld
- Spieler
- etc.

und dann was diese einzelnen Teile für Eigenschaften aufweisen müssen/sollen.

Erst dann sollte das Objekt-Grundgerüst erstellt werden.

Und dann geht man an die weiteren Aufgaben.
Dann kommen erst die Fragen nach "Wie zeichne ich das?"

[He4dnut]

Hallo, erstmal danke für die schnellen Antworten, doch leider muss ich Sie soweit enttäuschen, dass ich mit Begriffen wie DrawGrid etc. nichts anfangen kann :(

An Sir Rufo:
Deine Herangehensweise halte ich für richtig. Nur auch dazu Fragen: Was genau verstehst du unter Objekten, Eingabe, Logik und Ausgabe?

Die Dominosteine habe ich bereits in Paint gezeichnet und spaßhalber mit TImage in die Form eingefügt. Ob mir das was bringt, weiß ich noch nicht.

Ich muss jetzt leider ganz schnell weg. Vielen Dank nochmal und bis morgen hoffentlich ;)

MfG Philip

[Sir Rufo]

Objekte: Dominosteine, Spieler, Spielfeld, etc.
Eingabe: ja, die Eingabe von Daten halt :mrgreen:, sonst spielt das Programm nur mit sich selbst
Logik: Was ist erlaubt uns was nicht, darf Spieler 1 jetzt seinen Zug machen, darf DER Dominostein dahin gelegt werden
Ausgabe: Die grafische Aufarbeitung des Ganzen

Meines Erachtens bringt es nix wenn ihr jetzt schon lustig versucht irgendwelche Sachen auf den Bildschirm zu bringen. Das ist zwar kurzweilig, hilft euch für das Projekt nur sehr bedingt weiter.

Für die ersten Schritte braucht ihr keinen Computer, sondern nur Papier und Stift und lustiges Brainstorming.

[He4dnut]

Wir haben einmal wie vorgeschlagen Brainstorming betrieben!:) Unser Ergebnis:


Objekte:
Dominosteine sind z.B. Bilder, 2 feste Variablen zugeordnet, stehen für die zwei Augenzahlen,
2 Spieler, die noch verfügbaren Steine des Spielers der an der Reihe ist werden angezeigt, Stapel der übrigen Steine, die man ziehen muss, wenn man nicht kann (->müssen verdeckt sein), Aktuelle Endsteine der Reihe oder Komplette Reihe muss angezeigt werden, Endsteine müssen immer aktualisiert werden (falls man nur die Endsteine anzeigen lässt, da diese ja nur von Bedeutung sind)


Eingabe:
Vor dem Spiel wird abgefragt die Spieleranzahl (zunächst 2, später mehrere Möglichkeiten), Spielernamen und die Anzahl der Steine (4-er Domino, 6er-Domino, etc.,-> entspricht Spieldauer), während des Spiels muss ein Stein ausgewählt werden (entweder darauf klicken, oder Radio Button o. Ä.)

Logik:
1) Mindestens eine Variable des ausgewählten Steins muss mit mindestens einer Variablen eines aktuellen Steines übereinstimmen, bei mehreren Anlegemöglichkeiten muss noch das genaue „Ziel“ gewählt werden.
2) man klickt auf eine Hälfte eines Steines und dann auf die Hälfte an der er angelegt werden soll, oder durch ziehen falls möglich,
wenn die Variablen übereinstimmen, soll der Stein angelegt werden, wenn nicht, kurze Fehlermeldung. Das eigentliche testen kann durch einfache Abfrage geklärt werden:„ if x1 = x2 do […Prozedur „Steinanlegen“…] else showmessage(‚Der ausgewählte Stein passt hier nicht hin!’)
Hierbei wären x1 und x2 jetzt die Variablen der zwei Hälften (=Augenzahl).
Variante 2) erscheint sinnvoller...
Der Spielzug ist zuende..
1. nach erfolgreichem Anlegen,
2. nach Ziehen eines Steines wenn man nicht anlegen konnte oder
3. wenn der Spieler aussetzen muss, da 1. und 2. nicht erfüllt werden konnten.

Ausgabe:
Noch unklar…

Fragen:

„Wie kann ich einem Objekt (Dominostein) zwei Feste Werte zuordnen, die vom Programm abgefragt werden können?“

Oder (falls man jede Hälfte einzeln betrachtet siehe Logik 2):

„Wie kann ich einem Objekt (Dominosteinhälfte) einen festen Wert zuordnen, der seiner Augenzahl entspricht? Und wie erreiche ich, dass zwei Hälften dann immer zusammengehören, d.h., dass wenn ich die eine Hälfte anlege, die andere Hälfte die aktuelle Augenzahl ist, an die angelegt werden muss?“

Ich hoffe ihr versteht was ich meine :mrgreen:

[tkone]

Zitat:

Zitat von He4dnut

Fragen:

„Wie kann ich einem Objekt (Dominostein) zwei Feste Werte zuordnen, die vom Programm abgefragt werden können?“

Oder (falls man jede Hälfte einzeln betrachtet siehe Logik 2):

„Wie kann ich einem Objekt (Dominosteinhälfte) einen festen Wert zuordnen, der seiner Augenzahl entspricht? Und wie erreiche ich, dass zwei Hälften dann immer zusammengehören, d.h., dass wenn ich die eine Hälfte anlege, die andere Hälfte die aktuelle Augenzahl ist, an die angelegt werden muss?“

Ich hoffe ihr versteht was ich meine :mrgreen:

würde hier nen record nehmen, oder nen array.
dabei kann dir die erste variable die dominosteinnummer angeben(von 1 bis x) und dazugehörig die zwei einträge für die wertehälften.
also so, dass jeder stein eine nummer hat und unter dieser nummer die beiden werte abgespeichert sind.

beim anlegen kannst du dann prüfen ob dominonummer1.wert1 = liegenderstein.wert2 und dominonummer1.wert2 = liegenderstein.wert2

wenn wert1 passt, dann soll er den stein setzen.
wenn wert2 passt, dann soll er wert1 und wert2 des steins tauschen und dann setzen.

[Sir Rufo]

Zitat:

Zitat von He4dnut

Objekte:
Dominosteine sind z.B. Bilder, 2 feste Variablen zugeordnet, stehen für die zwei Augenzahlen,
2 Spieler, die noch verfügbaren Steine des Spielers der an der Reihe ist werden angezeigt, Stapel der übrigen Steine, die man ziehen muss, wenn man nicht kann (->müssen verdeckt sein), Aktuelle Endsteine der Reihe oder Komplette Reihe muss angezeigt werden, Endsteine müssen immer aktualisiert werden (falls man nur die Endsteine anzeigen lässt, da diese ja nur von Bedeutung sind)

Ich gehe jetzt mal erst nur auf die Objekte ein:

Objekt "Dominostein" benötigt folgende Eigenschaften:
- Wert1 : zahl
- Wert2 : zahl

Objekt "Stapel" benötigt folgende Eigenschaften:
- Liste mit "Dominostein"
- Oberster Stein : "Dominostein"

Objekt "Spieler" benötigt folgende Eigenschaften:
- Name : text
- Liste mit "Dominostein" (Steine des Spielers)

Objekt "Spielfeld" benötigt folgende Eigenschaften:
- Liste mit "Dominostein" (alle Steine auf dem Spielfeld)
- Erster Stein : "Dominostein"
- Letzter Stein : "Dominostein"

Objekt "Spiel" benötigt folgende Eigenschaften:
- Liste mit "Dominostein" (alle Steine)
- Liste mit "Spieler" (alle Spieler)
- Aktueller Spieler : "Spieler"
- Der Stapel : "Stapel"
- Das Spielfeld : "Spielfeld"

so sieht der Anfang eigentlich aus (ist nicht komplett) aber so solltet ihr das aufschreiben.

Das Ganze spielt man dann so durch:
- Ich habe Zugang zum Spiel.
- Dadurch weiß ich, wer dran ist (Aktueller Spieler)
- Dadurch weiß ich, welche Steine dieser Spieler hat (Aktueller Spieler->Liste mit "Dominostein"

usw.

[hugo1990]

Mal eine allgemeine Frage, da jetzt hier schon einige objekt-orientierte Vorschläge gekommen sind.
Habt ihr diese überhaupt behandelt? Weil wenn ich so deine Fragen lese sieht das eher so aus, als wäre dies nicht der Fall gewesen.
Und wenn ich an meine Schulzeit zurück denke, muss ich sagen, dass war bei uns auch nicht der Fall. Unser Infolehrer hatte gar keinen Plan von OOP, dass durfte ich ihm dann mal so ansatzweise erklären, wie das funktioniert.

[Blup]

Grundlagen kann man sich aneignen. Ein Entwurf mit Objekten ist einfacher als mit Records und Pointern zu arbeiten. Auf jeden Fall sollte man das ganze Spiel erst einmal funktionstüchtig entwerfen, bevor man sich mit der Darstellung beschäftigt. Sonst bekommt man ganz schnell Probleme.

Die Spielklasse sollte z.B. mit Datenobjekten jede Spielsituation darstellen können (nicht zu verwechseln mit Bildschirmanzeige).
Jede Änderung der Spielsituation sollte über geeignete Methoden erfolgen.

Mal so ein kleiner Entwurf:

Delphi-Quellcode:

TStein = class
  constructor Create(AZahl1, AZahl2: Integer);
private
  FZahl1: Integer;
  FZahl2: Integer;
public
  property Zahl1: Integer read FZahl1;
  property Zahl2: Integer read FZahl2;
end;

TSpieler = class
  constructor Create(AName: string);
private
  FName: string;
  FSteine: TList; {TStein - alle Steine die der Spieler in der Hand hält}
public
  property Name: string read FName;
  property Steine: TList read FSteine;
end;

TSteinPos = class
  constructor Create(AStein: TStein; APos: TRect);
private
  FStein: TStein;
  FPos: TRect;
public
  property Stein: TStein read FStein;
  property Pos: TRect read FPos;
end;

TDomino = class
  constructor Create();
private
  FSteine: TObjectList;    {enthält TStein - alle Steine die im Spiel vorkommen}
  FStapel: TList;          {enthält TStein - alle Steine gemischt, die auf dem Stapel zum Ziehen liegen}
  FSpieler: TObjectList;   {enthält TSpieler - alle am Spiel beteiligten Spieler}
  FReihe: TObjectList;     {enthält TSteinPos - alle gesetzten Steine mit Pos}
  FAmZug: TSpieler;        {Spieler der aktuell am Zug ist}
public
  property Reihe: TObjectList read FReihe;
  property Spieler: TObjectList read FSpieler;
  property AmZug: TSpieler read FAmZug;
  procedure Spielstarten;
  function  Zug(AStein: TStein; APos: TRect): Boolean;
end;

[He4dnut]

Zitat:

Zitat von tkone

würde hier nen record nehmen, oder nen array.
dabei kann dir die erste variable die dominosteinnummer angeben(von 1 bis x) und dazugehörig die zwei einträge für die wertehälften.
also so, dass jeder stein eine nummer hat und unter dieser nummer die beiden werte abgespeichert sind.

beim anlegen kannst du dann prüfen ob dominonummer1.wert1 = liegenderstein.wert2 und dominonummer1.wert2 = liegenderstein.wert2

wenn wert1 passt, dann soll er den stein setzen.
wenn wert2 passt, dann soll er wert1 und wert2 des steins tauschen und dann setzen.

Ja so ähnlich habe ich mir das wohl vorgestellt :) Nur wie genau würde das aussehen?
Muss ich für jeden Dominostein die zwei Werte festlegen, in etwa so:

Delphi-Quellcode:

type TDominostein = record
        Wert1 : integer;
        Wert2 : integer; 
   end;

oder wie mache ich das am Besten? Mit dem Array habe ich mich auch ein bisschen befasst, doch das bereitet mir noch Probleme. Denn wenn ich jetzt z.B. habe Dominostein[1,2], dann kann kann ich damit ja nur einen Wert auslesen, bzw speichern in der Zelle der 1. Spalte und 2. Zeile! Bräuchte ich ein Dreidimensionales Array oder wie?

Zu Sir Rufo habe ich folgendes einmal aufgeschrieben:

Delphi-Quellcode:

 type TDominostein = record
        Wert1 : integer;
        Wert2 : integer; {Zwei verschiedenen Werte für Augenzahlen}
   end;
 type TSpieler = record
        Name : String;
       {HandDomino : array of TDominosteine}
 end;
 type TSpielfeld = record
        ErsterStein : TDominostein;
        LetzterStein : TDominostein;
      { ZiehDomino : array of TDominostein}
 end;
 type TSpiel = record
      { AlleDomino : array of TDominostein}
      { AlleSpieler : array of TSpieler}
        AktSpieler : TSpieler;
      { und so weiter...)
 end;

Kann ich irgendetwas davon gebrauchen? Ansonsten habe ich nicht ganz verstanden, wo jetzt mein nächster Schritt liegen soll, außer aufzuschreiben, welche Eigenschaften verschiedene Objekte haben sollen..

Zu hugo1990:
Also uns wurde der Begriff erst Bei der Java-Programmierung erläutert. Ich weiß nicht in wiefern wir bis dahin in Delphi objekt-orientiert gearbeitet haben. Ich dürfte doch jetzt auch einmal behaupten, dass unser Info Lehrer auch nicht das Superhirn ist..

Zu Blup:
Damit kann ich bisher leider recht wenig anfangen :?
Ich versuche das zu verstehen, ich glaube das ist soetwas ähnliches wie meine Record-Deklarationen oben oder? Könntest du vielleicht einmal kurz erläutern was das genau bedeutet? Das wäre nett...

An Alle:
Jetzt schon habe ich ganz viele verschiedene Herangehensweisen vorgeschlagen bekommen, doch ich müsste mich wirklich für eine entscheiden^^ Vielleicht könnte sich ja jeder einmal die Vorschläge der anderen durchlesen und diese Kommentieren. Aber wir können auch gerne noch etwas warten und erstmal sammeln :) Kanns zwar kaum erwarten mit dem Programmieren anzufangen, aber "Abgabetermin" ist wirklcih noch hin!

Großes Dankeschön soweit schonmal an alle und bis dann!

[He4dnut]

Delphi-Quellcode:

 

type TDominostein = record
        Wert1 : integer;
        Wert2 : integer; {Zwei verschiedenen Werte für Augenzahlen}
   end;                      

{Im echten Quelltext steht hier noch was..}

procedure TForm1.Button1Click(Sender: TObject);
var Dom : array[1..10] of TDominostein;
begin
  Dom[1].Wert1:= 0;
  Dom[1].Wert2:= 0;
  Dom[2].Wert1:= 1;
  Dom[2].Wert2:= 0;
  Dom[3].Wert1:= 1;
  Dom[3].Wert2:= 1;
  Dom[4].Wert1:= 2;
  Dom[4].Wert2:= 0;
  Dom[5].Wert1:= 2;
  Dom[5].Wert2:= 1;
  Dom[6].Wert1:= 2;
  Dom[6].Wert2:= 2;
  Dom[7].Wert1:= 3;
  Dom[7].Wert2:= 0;
  Dom[8].Wert1:= 3;
  Dom[8].Wert2:= 1;
  Dom[9].Wert1:= 3;
  Dom[9].Wert2:= 2;
  Dom[10].Wert1:= 3;
  Dom[10].Wert2:= 3;
  k := StrToInt(edit1.text);
  if k>10 then edit2.text := 'Bitte nur Zahlen von 1 bis 10 eintragen!'
  else if k<1 then edit2.text := 'Bitte nur Zahlen von 1 bis 10 eintragen!'
  else edit2.text := 'Wert1 vom Dominostein '+ IntToStr(k) +' beträgt '+ IntToStr(Dom[k].Wert1);
end;

Mit dieser "Kombination" aus Dem Record und Array ist es mir gelungen, 10 verschiedenen Dominosteinen 2 Werte zuzuordnen. Also eigentlich genau das was ich wollte oder? :-D Nunja in Wirklichkeit hat man natürlich mehr Steine, aber für den Anfang reicht das. Das Abfragen der Werte habe ich auch getestet, indem man "k" eingegeben hat, also die Nummer des Dominosteins, und es wurde der passende Wert1 des Steines ausgegeben. Mit dem Wert2 funktioniert das genauso!

Also wenn ich jetzt noch so andere Dinge wüsste, z.B. wie das mit dem Anlegen klappen soll undso, dann bin ich guter Dinge :mrgreen:

Genug für heute! Bis morgen ;-)

[mkinzler]

Ich würde mir überlegen aus derm Record eine Klasse zu machen.

[hugo1990]

@Blub:
Natürlich kann man sich Grundlagen aneignen. Aber wenn man einfach etwas an den Kopf geworfen bekommt, was man noch nie gesehen hat und auch nicht weiß, was es ist, kann man damit auch recht wenig anfangen. Und die Reaktion von He4dnut zeigt ja, dass er damit nichts anfangen kann.
Und ich finde auch, dass man sich nicht unbedingt noch neue Sachen aneignen sollte um ein Projekt für die Schule zu schreiben. Weil die Zeit für das Projekt ist ja begrenzt und wenn man nicht abschätzen kann, wie lange man brauchen wir, eh man das ganze verstanden hat, ist das blöd. Weil man dann dafür womöglich ne ganze Menge Zeit verbrät und im Endeffekt nicht mehr genügend Zeit hat das Projekt fertig zu stellen. Und bei so einem Projekt ist es ja auch wichtig, dass es nicht nur Funktioniert, sondern man auch verstanden hat, was man da gemacht hat. Weil wenn man Sachen verwendet, die man Unterricht nicht behandelt hat, dann darf man das meistens auch erklären und wenn man dann keine richtige Ahnung hat, wird der Lehrer skeptisch ob man es wirklich selber gemacht hat.
Wie gesagt, ich durfte das damals bei meinem Infolehrer machen, aber ich kannte mich aber auch bereits bevor ich Info hatte, mit der OOP aus.
Also es ist deine Entscheidung, was du machen willst und wie du es im Endeffekt lösen möchtest. Mit Records ist das aber auch ohne Probleme zu lösen. Mit der OOP kann man zwar viele Sachen einfacher und eleganter lösen, aber wenn man sich halt erst noch in die OOP einarbeiten muss, dann dauert es halt auch erstmal, eh man das ganze so toll lösen kann.

[Blup]

Deine Argumente sind in diesem Fall wohl zutreffend, obwohl hier Vererbung und Interfaces nicht benötigt werden, also keine "richtige OOP".
Wer allerdings mit Records arbeiten will, muss zwangsläufig auch mit Pointern arbeiten und das fällt Anfängern deutlich schwerer, als das Verständnis für Objekte zu entwickeln. Die Datenstrukturen und Prozeduren die entwickelt werden müssen, sind letztendlich die Selben, nur Schreibaufwand und Komplexität sind für Records/Pointer höher als bei Verwendung von Objekten.

[hugo1990]

Zitat:

Zitat von Blup

... Wer allerdings mit Records arbeiten will, muss zwangsläufig auch mit Pointern arbeiten ...

Dem will ich mal widersprechen. Denn wenn ich mir so meine alten Projekte anschaue, wo ich noch nicht mit der OOP vertraut war, habe ich ständig mit Records gearbeitet, aber ich habe dort nie mit Pointern arbeiten müssen, weil ich zu dem Zeitpunkt noch nicht mal wusste was Pointer sind.
Und ich würde mal behaupten das diese Projekt hier auch mit Records und ohne die Verwendung von Pointern zu realisieren ist.
Ich wüsste jetzt nicht wirklich wo du hier direkt mit Pointern arbeiten willst.

[He4dnut]

Danke euch beiden, dass ihr mir die Vor- und Nachteile einmal geschildert habt! Also Ich denke ich werde das mit diesen Records machen. Da habe ich mich bereits gut eingelesen und habe auch eine Vorstellung davon, wie ich es realisieren kann, bzw DASS ich es ÜBERHAUPT realisieren kann :mrgreen:
Der Begriff Pointer ist mir auch öfter schon über den Weg gelaufen. Ich werde mich mal damit beschäftigen.

Ansonsten könnte jemand mal zu meinem letzten Post was sagen? Da bin ich nämlich ziemlich stolz drauf :mrgreen:

Zu mkinzler:
Also müsste ich das dann so schreiben?:

Delphi-Quellcode:

type TDominostein = class
       private
         FWert1 : integer;
         FWert2 : integer;
       public
end;

Könntest du mir sagen, was das für ein Vorteil hätte im Gegensatz zum Record?

Gruß! :-)

[DeddyH]

Du weißt aber schon, dass lokale Variablen nur innerhalb der Routine bekannt sind, in der sie deklariert werden? Soll heißen: außerhalb Deiner Button1Click-Methode kannst Du nicht auf Dom zugreifen. Ob das in diesem Fall gewollt ist, musst Du selbst wissen ;)

[hugo1990]

Also ich würde dir empfehlen noch sprechendere Variablennamen zu verwenden, als du dies jetzt tuts. Mit Dom kann man zwar schon etwas anfangen, wenn man weiß, worum es geht. Wenn du es DominoSteine nennst, dann weiß man sofort, was damit gemeint ist. Falls du das ganze nur so kurz machst, weil du schreibfaul bist und nicht jedes Mal die langen Namen schreiben willst, da gibt es was gegen STRG + LEER und die Autovervollständigung wird aktiviert. Und dann könnte man deinen Code ohne hin noch verkürzen, was wieder weniger Schreibarbeit bedeutet. Beispielsweise so:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var 
  I: Integer;
begin
  for I := Low(DominoSteine) to High(DominoSteine) do
    with DominoSteine[I] do
    begin
      Wert1 := Wert1FürStein(I);
      Wert2 := Wert2FürStein(I);
    end;

  {...}

end;

Das Wert1FürStein(I) und Wert2FürStein(I) muss dann noch durch eine geeignete Routine von dir ersetzt werden. Je nach dem wie du es bei deinem Post gemacht hattest. Wenn du nach einem bestimmten Schema vorgegangen bist für die Werte, dann versuche einen geeigneten Alogorithmus dafür zu finden, der das wie in deinem Schema macht. Dafür könnten evtl. die ganzzählige Division (div) und die Restdivision (mod) interessant sein. Falls du das ganze einfach per Zufall gemacht hast dann solltest du dir dafür mal Random anschauen.
Falls du dazu Fragen haben solltest, dann frag gern. Aber ich denke eigentlich, dass es recht selbsterklärend sein sollte.

[Sir Rufo]

Ich würde auch dringend empfehlen so eine Routine nicht im "ButtonxxOnClick" zu schreiben.

Delphi-Quellcode:

procedure TuWas( Parameter : TIrgendwas );
begin
  // Code zur Übernahme der Weltherrschaft
end;

Delphi-Quellcode:

procedure TForm1.DerSuperSpezialButton1OnClick( Sender : TObject );
begin
  TuWas( GanzTolles );
end;

procedure TForm1.DerSuperSpezialButton2OnClick( Sender : TObject );
begin
  TuWas( GanzDoofes );
end;

Vorteil:

- Trennung der GUI von der Logik
- Der Code bleibt übersichtlicher

[Wolfgang Mix]

:)

[hugo1990]

Ja stimmt, Sir Rufo. Bei meinem Beispiel war das Button1Click auch nur noch eines der wenigen Überbleibsel vom Copy&Paste. Weil ich zu faul war das ganze zu schreiben, hatte ich kurzer Hand einfach mal den Quellcode von He4dnut kopiert. Allerdings ist davon dann im Endeffekt nicht mehr wirklich was übrig geblieben. Da hätte ich der Routine dann eigentlich auch noch einen gescheiten Namen geben können.

Offtopic:
Der genaue Code für die Routine:

Zitat:

Zitat von Sir Rufo

Delphi-Quellcode:

procedure TuWas( Parameter : TIrgendwas );
begin
  // Code zur Übernahme der Weltherrschaft
end;

wäre jetzt aber schon mal interessant. :mrgreen:

[He4dnut]

Hmm ja sieht gut aus bisher alles... Das mit den Namen hängt nur mit meiner Faulheit zusammen... Aber ich denke mir immer, dass ERSTMAL ja nur ich das verstehen muss. In der Schule muss ich eh alles, was ich zu Hause programmiere nochmal neu schreiben, dann wird alles ganz ordentlich gemacht ;)

Bei Hugos "Wert1FürStein[I]" sagtest du, dass ich dieses Durch einen geeigneten Algorithmus ersetzen muss. Ja, verstehe ich. Allerdings habe ich jetzt einige Zeit gegrübelt wie ich das anstellen soll... Also ich habe da diese Grafik im Kopf:

http://www.dominoopen.64g.ru/images/sxde.gif

Ich persönlich finde die sehr gelungen. Durch das zweidimensionale Array habe ich doch bildlich gesprochen so eine Tabelle erstellt. Also am Anfang sagte ich ja werde ich das ganze Spiel so programmieren, dass der Stein [3,3] der höchste ist, ein 3er-Domino sozusagen. Das heißt, ich habe 10 Steine. Diese Steine könnte man jetzt z.B. so nummerieren, dass man von links nach rechts, und von oben nach unten liest. Also Stein1: [0,0] ; Stein2: [0,1] ; Stein3: [1,1] ; usw.

Aber beim besten Willen fällt mir keine schlaue Rechnung ein, mitder man jedem Stein seinen passenden Wert automatisch zuordnet. Zur Not würde ich auch einfach an einer Stelle der Unit manuell jedem Stein seine Werte zuordnen. Das ist halt einmal viel Arbeit, aber dann hat mans wenigstens einmal richtig ;-)

Soweit erstmal. Danke nochmal!

[He4dnut]

Mein aktuelles Programm einmal für euch...
natürlich alles provisorisch. könnt ihr hier runterladen:
http://www.file-upload.net/download-...ject1.exe.html

[hugo1990]

Die Grafik verstehe ich irgendwie nicht so ganz. Vielleicht kannst du mal erklären, was sie darstellen soll, dann kann ich dir beim Finden eines Algorithmus' vielleicht ein wenig auf die Sprünge helfen. Und mit deinem Programm kann ich auch nicht so wirklich was anfangen, weil es irgendwie noch nicht wirklich etwas tut.
Außerdem sollten Dateien immer direkt an den Thread an gehangen werden, damit sie, wenn sich jemand das Thema später noch einmal ansieht immer noch vorhanden sind.

[Micha88]

Zitat:

Natürlich kann man sich Grundlagen aneignen. Aber wenn man einfach etwas an den Kopf geworfen bekommt, was man noch nie gesehen hat und auch nicht weiß, was es ist, kann man damit auch recht wenig anfangen. Und die Reaktion von He4dnut zeigt ja, dass er damit nichts anfangen kann.

Sowieso eine Unverschämtheit von den Lehrern sowas zu verlangen.

[p80286]

Zitat:

Zitat von MichaelLinden

Sowieso eine Unverschämtheit von den Lehrern sowas zu verlangen.

das habe ich jetzt nicht verstanden.
Ist gemeint
a)Sowieso eine Unverschämtheit von den Lehrern, sowas zu verlangen.
oder
b)Sowieso eine Unverschämtheit, von den Lehrern sowas zu verlangen.

oder vielleich dieses?

Sowieso eine "Unverschämtheit" von den Lehrern, sowas zu verlangen.

Gruß
K-H

[Amateurprofi]

Zitat:

Zitat von He4dnut

Aber beim besten Willen fällt mir keine schlaue Rechnung ein, mitder man jedem Stein seinen passenden Wert automatisch zuordnet. Zur Not würde ich auch einfach an einer Stelle der Unit manuell jedem Stein seine Werte zuordnen. Das ist halt einmal viel Arbeit, aber dann hat mans wenigstens einmal richtig ;-)

Vielleicht so : (schönen Gruß von Carl Friedrich Gauss)

Delphi-Quellcode:

PROCEDURE StoneToValues(stone:integer; var value1,value2:integer);
// var i,j,n:integer;
begin
   value1:=Trunc(Sqrt(stone*2)-0.5);
   value2:=stone-(Sqr(value1)+value1) div 2-1;
   // Oben die korrigierte Version.
   // Die auskommentierte Fassung liefert korrekte Werte, aber 
   // es hat mir keine Ruhe gelassen, dass so ein triviales Ding auch noch ein IF ... benötigen soll.
   // i:=Trunc(Sqrt(stone*2+0.25)-0.5);
   // n:=(i*i+i) div 2;
   // if n>=stone then begin
   //    value1:=i-1;
   //    value2:=value1;
   // end else begin
   //    value1:=i;
   //    value2:=stone-n-1;
   // end;
end;

Oder für einfache Gemüter so :

Delphi-Quellcode:

PROCEDURE SimpleStoneToValues(stone:integer; var value1,value2:integer);
var i,j:integer;
begin
   for i:=0 to stone do
      for j:=0 to i do begin
         dec(stone);
         if stone=0 then begin
            value1:=i;
            value2:=j;
            exit;
         end;
      end;
end;

Beide Funktionen setzen voraus, daß die Steine bei 1 beginnend numeriert sind.