Memory-Spiel: Ideen

[XardasLP]

Hallo,

ich bräuchte mal eine Idee wie man ein Memory-Spiel in Delphi umsetzen kann. Geplant ist Einzelspieler, Einzelspieler gegen Computer und Mehrspieler (2).
Ich würde gerne Image-Dateien verwenden, welche sich beim anklicken umdrehen (ohne Animation ist ausreichend).

Die Karten z.B. 12 Paare sollen sich zufällig anordnen.

Wie kann ich dies umsetzen?

[Puke]

Kommt auf deine Erfahrung mit Delphi an. Für Anfänger könnte man z.B. ne ImageList verwenden und sich in nem zweidimenionalen Array die Karten merken.

[XardasLP]

Ok, eine eigene neu kreierte Klasse ist nicht zwingend nötig oder?

2D reicht aus. Das Spiel soll dann noch an eine Datenbank angebunden werden mit Highscore Liste und Passwort geschützten Login.^^ :-D

[Sir Rufo]

Eine eigene Klasse ...

Nein, eher mehrere eigene Klassen werden benötigt um das auch übersichtlich programmieren zu können. :stupid:

[blondervolker]

Mach mal eins, wo man die Karten abschießen kann, wie Moorhuhn die Hühner oder? ...:-D
Gab es noch nicht? Oder? :roll::cyclops::-D

[Luckie]

Memory gegen den Computer? Ich habe mal gehört, die können sich unheimlich gut Dinge merken. Wenn das mal nicht zu Frust beim menschlichen Spieler führt. :mrgreen:

Schon etwas älter: http://michael-puff.de/Programmierung/Delphi/Programme/ -> LuckieMemory. Ist mit Quellcode.

[Perlsau]

Zitat:

Zitat von Luckie (Beitrag 1327091)

Memory gegen den Computer? Ich habe mal gehört, die können sich unheimlich gut Dinge merken. Wenn das mal nicht zu Frust beim menschlichen Spieler führt. :mrgreen:

Naja, deswegen hab ich z.B. mein Memmori (man beachte: abweichende Bezeichnung) so konzipiert, daß immer nur ein Spieler spielt und es darauf ankommt, so wenig wie möglich Züge zu benötigen, um alle Bildpaare aufzudecken – quasi ein Memory zum üben, weil man zu Hause ständig gegen den fünfjährigen Nachwuchs verliert. :shock:
Zudem kann man sich die Spiele selber zusammenstellen aus frei wählbaren Grafiken, z.B. Fotos oder Zeichnungen oder Zierfonts oder was auch immer man an Grafiken irgendwo findet, z.B. die vom Memory-Spiel des Nachwuchses. :lol:
Weitere Features: Man kann die Anzeigedauer frei wählen, bevor die aufgedeckten Grafiken wieder umgedreht werden, wenn sie nicht zusammenpassen. Und man kann einstellen, wie viele Grafiken zusammenpassen müssen, von zwei aufwärts. Zwei sind kein Problem, drei geht noch einigermaßen, bei vieren verlangt's schon fast übermenschliche Anstrengungen, bei fünfen ... Gespeichert wird alles in einer Firebird-Datenbank.

@XardasLP: Welche Delphi-Version setzt du denn ein? Wenn du diese Nachfrage in Zukunft vermeiden willst, kannst du deine Delphi-Version in deinem Profil eintragen.

[Headbucket]

Zitat:

Zitat von Luckie (Beitrag 1327091)

Memory gegen den Computer? Ich habe mal gehört, die können sich unheimlich gut Dinge merken. Wenn das mal nicht zu Frust beim menschlichen Spieler führt. :mrgreen:

Schon etwas älter: http://michael-puff.de/Programmierung/Delphi/Programme/ -> LuckieMemory. Ist mit Quellcode.

Was spricht denn dagegen unterschiedliche Schwierigkeitsgrade zu erstellen? :wink:

Leicht: Computer merkt sich gar nichts und wählt stets zufällig 2 Karten.
Mittel: Computer merkt sich jede einzelne Karte mit einer Wahrscheinlichkeit von 50 %.
Schwer: Computer merkt sich stets jede einzelne Karte.

Müsste man natürlich dann ein wenig testen und "feintunen". Ansonsten stelle ich mir das so relativ leicht umsetzbar vor. Vor allem der leichte Computer macht am wenigsten Arbeit.

Grüße

[Mavarik]

Zitat:

Zitat von Perlsau (Beitrag 1327093)

Naja, deswegen hab ich z.B. mein Memmori (man beachte: abweichende Bezeichnung)...

8-) Ich wollte mich auch nicht mit "memory® Ravensburger" anlegen und da ich es in Firemonkey programiert habe nenne ich es auch Firemerk.

Zitat:

Zitat von Sir Rufo (Beitrag 1327089)

Eine eigene Klasse ...

Nein, eher mehrere eigene Klassen werden benötigt um das auch übersichtlich programmieren zu können. :stupid:

Aus pädagogischer Sicht natürlich die richtige Antwort...

Meine 3D Version hat eine Klasse und ca. 400 Zeilen Source... Klar kann man das ggf. noch in Klassen unterteilen... Falls man es als Hausaufgabe sieht...

Mavarik

[XardasLP]

Wir arbeiten mit Delphi 7 Enterprise xD

Das was wir gelernt haben und das was die Lehrer von uns verlangen steht in keinem Verhältnis :) ^^

[Mavarik]

Die Delphi Version ist aber ausreichend für ein Memory Game!

Wo liegt den Dein Problem?

[XardasLP]

Bis jetzt noch keins, brauche aber trotzdem später bisschen Unterstützung. :D

Habe bis April Zeit, also fange in Februar Ferien mal an. Wollte mich nur mal vor informieren.

[XardasLP]

Pff, wenn ich das Lucky Memory sehe dann kann ich das ja schon nicht nachvollziehen.

Wenn ich euch mal schicke wie weit wir mit Klassen sind dann hilft mir das hier sooooo weit.
-.- :roll:

[Perlsau]

Und was möchtest du jetzt von den Usern der Delphi-Praxis konkret? Was erwartest du?

[Luckie]

Dann fang mit was einfacheren an. Schreibt dir ein Programm zum Umrechnen von Temperaturen mit Klassen. Oder lies dich hier mal ein: http://michael-puff.de/Programmierung/Delphi/Tutorials/ -> Klassen_in_Delphi

[XardasLP]

Das bringt ja nicht viel... brauche das ja an einem komplexen Projekt, weiß nicht mal was ich nehmen soll. Also Klasse Spieler 1, Spieler2, Gewonnen, Verloren oder jedes Feld einzeln als Klasse?

[citybreaker]

Zitat:

Zitat von XardasLP (Beitrag 1328456)

Das bringt ja nicht viel... brauche das ja an einem komplexen Projekt, weiß nicht mal was ich nehmen soll. Also Klasse Spieler 1, Spieler2, Gewonnen, Verloren oder jedes Feld einzeln als Klasse?

Hallo XardasLP,

mir würden als Klassen spontan zum Thema Memory folgende einfallen: Spieler, Spielfeld und Karte. Die einzelen Spieler, also Spieler 1 und 2 wären in dem Fall Objekte / Instanzen von der Klasse Spieler.

[Luckie]

Zitat:

Zitat von XardasLP (Beitrag 1328456)

Das bringt ja nicht viel...

Doch. Das ist an einem Nachmittag gemacht und du bekommst ein Gefühl wie das mit den Klassen funktioniert. Dann würdest du auch erkennen, dass eine Klasse für "Gewonnen" und "Verloren" Unsinn ist. Das ist eine Methode der Klasse "Spiel" (zum Beispiel).

[XardasLP]

Hmm, naja immer der Reihe nach erstmal.

Ich benötige einen Login und eine Registrierung (falls man einen neuen Nutzer anlegen möchte).

Also beim eingeben des Benutzernamens und des Passwortes wird gesucht, ob es eine entsprechende .txt Datei mit dem Namen des Benutzers gibt.

Das bedeutet...
Benutzername: Xardas
Passwort: Test

procedure TFormLogin.Button_Login.Click usw.
dann entsteht eine .txt Datei mit dem Namen Xardas.txt
dort wird das Passwort mit Ascii und einem gewählten Schlüssel(programmintern) verschlüsselt.

Mein Problem ist jetzt, dass ich bis jetzt nur eine Verschlüsselung für einen Nutzer gemacht habe und dort der Benutzername + einen Schlüssel verschlüsselt war. (wie oben beschrieben mit Ascii + Schlüssel um die Zahlen zu ändern)

Jetzt muss das Programm aber suchen, sobald ein zweiter Nutzer kommt der auch Xardas heißt, ob es diesen nicht schon gibt.
Das bedeutet Xardas.txt darf nicht überschrieben werden, also Fehlermeldung!

Code:

 if (Editpw.Text = '') or (Edits.Text = '') then
  begin
  showmessage('Bitte Eingaben überprüfen!');
  Editpw.Text := '';
  Edits.Text := '';
  end
    else
    begin
   //if editpw.Text ='12345'
    assignfile (tf, 'pw.txt');    //Die Prozedur weist einer Dateivariablen den Namen einer externen Datei zu.
   reset(tf);                     //Die Prozedur offnet eine vorhandene Datei
    {readln(tf,zeile);
    if zeile = Editpw.text}
   passw:='';
    s:=strtoint(edits.Text);
    while not eof(tf) do
      begin
      readln(tf,zeile);
      a:=strtoint(zeile);
      z:=chr(a-s);
      passw:=passw +z;
      end;

    if passw = Editpw.text
      then begin
         formstart.Show;
         formmain.Visible:=false;

           end
            else begin
                  if anz<2 then
                         begin
                          showmessage('Passwort Falsch !');
                          anz:=anz+1;
                          editpw.Clear;
                          edits.Clear;
                          editpw.SetFocus;
                          end
                          else
                              begin
                               anz:=anz+1;
                               if anz=3
                               then begin
                                showmessage('Sie besitzen keine Zugangsberechtigung!');
                                close;
                                   end;
                  closefile(tf);
                  end;
       end;
end;
end;

Das ist die alte beschrieben Sache...
bei der neuen weiß ich jetzt nicht wie ich dafür sorge das er die Datei nicht überschreibt und ich dann eine Meldung bringen kann. [showmessage('Dieser Nutzer existiert bereits!')

Bis jetzt so weit:

Code:

var
  FormLogin: TFormLogin;
  Benutzername: string;
  tf: textfile;

implementation

uses URegistrierung;

{$R *.dfm}

procedure TFormLogin.Button_RegClick(Sender: TObject);
{1}begin
      FormReg.Show;
      FormLogin.ShowHint := True;
{1}end;

procedure TFormLogin.Button_LoginClick(Sender: TObject);
{1}begin
   if (Edit_Benutzername.Text = '') or (Edit_PW.Text = '') then
      {1}begin
          showmessage('Bitte überprüfen Sie Ihre Eingaben!');
          Edit_Benutzername.Text := '';
          Edit_PW.Text := '';
      {1}end
            else
         {2}begin
              Benutzername := Edit_Benutzername.Text;
              assignfile(tf,Benutzername+'.txt');
              reset(tf);
              closefile(tf);
         {2}end


end;

Geht das mit dem

Code:

assignfile(tf,Benutzername+'.txt');

, weil das ja eine vorhandene Datei normalerweise öffnet.
Bräuchte eine normale Savetofile[] Variante. //NACHTRAG: Ok gut ich schreibe den Inhalt der Edit-Felder in ein unsichtbares MemoFeld und mache dann Memo.Lines.SaveToFile...

[Jumpy]

Ok gut ich schreibe den Inhalt der Edit-Felder in ein unsichtbares MemoFeld und mache dann Memo.Lines.SaveToFile...[/QUOTE]

Schau dir mal die Klasse TStringlist an. Das mach mehr Sinn als ein unsichtbares Memo.
Die Funktion FileExists(Dateiname) kann dir sagen, ob eine Datei mit dem Namen des Benutzers schon existiert.
Statt AssignFile usw. kannst du dann diese Datei in eine StringList laden und damit arbeiten, oder falls die Datei bisher nicht existierte, die entsprechenden Infos in die StringList schreiben und dann unter dem gewünschten Namen abspeichern.


Du könntest dir aber auch mal anschauen, was es mit Ini-Dateien auf sich hat, auch diese könnte man für den Anfang nutzen, um solche Dinge zu speichern. Da könnte man in nur einer Datei, für alle Nutzer die gewünschten Infos speichern, z.B. in dem man für jeden Nutzer eine Sektion anlegt.
Pro Nutzer eine Datei erscheint mir nämlich unnötig kompliziert.

[XardasLP]

Ok so sieht es jetzt schon mal gut aus... jeder neue Nutzer bekommt eine eigene Datei.

Code:

procedure TFormReg.Button_LoginClick(Sender: TObject);
begin
 if (Edit_Benutzername.Text = '') or (Edit_PW.Text = '') or (Edit_PW_1.Text = '') then
      {1}begin
          showmessage('Bitte überprüfen Sie Ihre Eingaben!');
          Edit_Benutzername.Text := '';
          Edit_PW.Text := '';
          Edit_PW_1.Text := '';
      {1}end
            else
         {2}begin
              if Edit_PW.Text <> Edit_PW_1.Text then
             {3}begin
                showmessage('Ihr gewählten Passwörter stimmen nicht überein!');
                Edit_Pw.Text := '';
                Edit_PW_1.Text := '';
               {3}end
                  else
                    if Edit_PW.Text = Edit_PW_1.Text then
                   {4}begin
                        Benutzername := Edit_Benutzername.Text;
                        Memo_Login.Lines.Add(Benutzername);
                        Memo_Login.Lines.SaveToFile(Benutzername+'.txt');
                   {4}end;
         {2}end;
      {1}end;

Ich kann natürlich später dann "append" verwenden, damit es nur eine einzige Datei ist.
Nun muss noch das Passwort angefügt werden für jeden Nutzer einzeln. Halt auch so eine Ascii Verschlüsselung. Das Programm gibt dann einen Schlüssel vor für jeden Account: z.B. 40
also wird aus A --> 51 --> + 40 = 91 (nicht nachvollziehbar ohne den Schlüssel)
der Schlüssel wird vom Benutzer selbst nicht gesehen.


Beim Login muss ich natürlich dann die entsprechende Xardas.txt Datei suchen lassen.

Code:

assignfile(tf,Benutzername + '.txt')
reset(tf)

usw.

[XardasLP]

Zitat:

Schau dir mal die Klasse TStringlist an. Das mach mehr Sinn als ein unsichtbares Memo.
Die Funktion FileExists(Dateiname) kann dir sagen, ob eine Datei mit dem Namen des Benutzers schon existiert.
Statt AssignFile usw. kannst du dann diese Datei in eine StringList laden und damit arbeiten, oder falls die Datei bisher nicht existierte, die entsprechenden Infos in die StringList schreiben und dann unter dem gewünschten Namen abspeichern.

Okey, das hört sich gut an :)

Nachlesen kann ich selbst. Das größte Problem ist einfach das wir kaum Klassen kennen und nur wenig gemacht haben was dem hier jetzt annähernd entpricht. Komme schon gut voran wenn mir nur mal wer sagt wie man was machen kann.

Ist wie wenn man den Datentyp "record" nicht kennt und versucht mit den anderen krampfhaft was hinzubekommen. So ungefähr ist das bei uns. Lehrer die gammeln.

[Mavarik]

Zitat:

Zitat von XardasLP (Beitrag 1328471)

also wird aus A --> 51 --> + 40 = 91 (nicht nachvollziehbar ohne den Schlüssel)

Wenn man dafür einen Blick hat... Erkennt man sofort den "Chiffree"... und mit in bisschen testen hat man das raus...

Dann schon lieber eine Tabelle Result := chr(Table[ord(A)])...
oder einen XOR String zur Verknüpfung...

BTW.: Was hat das mit Memory zu tun?

Abgesehen davon gibt es hier extra einen Delphi-Tag - also nicht Code verwenden...

[Sir Rufo]

Wenn man selber das Password validiert, dann speichert man das nicht verschlüsselt sondern als Hash mit (einer Prise) Salz.

[Luckie]

Um was geht es hier jetzt eigentlich? Um ein Memory Spiel oder wie man Benutzer und Passwort (sicher) in einer Datei speichert und wieder validiert? Das ein hat mit dem anderen nichts zu tun. So ein "Login" für ein Memory Spiel ist ja ganz nett. Aber hat mit dem Problem "Memory Spiel unter Nutzung von Klassen" nichts zu tun. Davon abgesehen, hätte man schon das Login in einer Klasse packen können.

In diesem Thread geht es um das Memory Spiel und nicht um das Speichern von Benutzername und Passwort.

@XardasLP: Mach bitte für ein neues Thema einen neuen Thread auf. Wobei das Thema Benutzer und Passwort abspeichern schon oft genug hier diskutiert wurde.

[XardasLP]

Zitat:

BTW.: Was hat das mit Memory zu tun?

Das Memory kommt ja erst noch.

Login, Registrierung (Benutzer)
Highscore-Liste
Einspieler (alleine und gegen Computer) / Mehrspieler
mehrere Schwierigkeitsgrade

Zitat:

Wenn man selber das Password validiert, dann speichert man das nicht verschlüsselt sondern als Hash mit (einer Prise) Salz.

Wenn das für uns aber als "verschlüsseln" reicht ist das doch ok. geht nur darum das niemand die Testdatei aufmacht und seine Punktzahl so mega easy einsehen und verändern kann.

[XardasLP]

Zitat:

In diesem Thread geht es um das Memory Spiel und nicht um das Speichern von Benutzername und Passwort.

Ich mache doch nicht mehrere Threads für ein Komplexprogramm, am Ende muss das ja alles eine Verbindung haben.


Das einzige was wir mal mit Klassen ("komplex") gemacht haben ist das hier:

Unit1:

Delphi-Quellcode:

unit Umain;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls;

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Label2: TLabel;
    EditID: TEdit;
    ButtonND: TButton;
    Label3: TLabel;
    Label4: TLabel;
    Label5: TLabel;
    Label6: TLabel;
    RG: TRadioGroup;
    ButtonBA: TButton;
    ButtonSAVE: TButton;
    ButtonCLOSE: TButton;
    EditDS: TEdit;
    EditB: TEdit;
    EditLZ: TEdit;
    CB: TComboBox;
    EditmZ: TEdit;
    EditmR: TEdit;
    EditGz: TEdit;
    EditGza: TEdit;
    Label7: TLabel;
    Label8: TLabel;
    Label9: TLabel;
    Label10: TLabel;
    procedure ButtonBAClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure ButtonNDClick(Sender: TObject);
    procedure RGClick(Sender: TObject);
    procedure ButtonSAVEClick(Sender: TObject);
    procedure ButtonCLOSEClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;
  liste: TStrings;
  anz: integer;

implementation

uses UDarlehen;

{$R *.dfm}

procedure TForm1.ButtonBAClick(Sender: TObject);
begin
 EditDS.Enabled := False;
  EditB.Enabled := False;
  EditLZ.Enabled := False;
  CB.Enabled := False;
  Label3.Enabled := False;
  Label4.Enabled := False;
  Label5.Enabled := False;
  Label6.Enabled := False;
  Label7.Enabled := True;
  Label8.Enabled := True;
  Label9.Enabled := True;
  Label10.Enabled := True;
  EditGZ.Enabled := True;
  EditGza.Enabled := True;
  EditmR.Enabled := True;
if (EditDS.Text = '') or (EditB.Text = '') or (EditLZ.Text = '') or (CB.Text = '')
    then begin
    EditDS.SetFocus;
         end
    else begin
        darlehen.set_DS(strtofloat(Editds.Text));
        darlehen.set_BE(strtodate(EditB.Text));
        darlehen.set_LZ(strtoint(EditLZ.Text));
        darlehen.set_JZ(strtofloat(CB.Text));
        case RG.ItemIndex of
          0: begin
                EditMR.Text := formatfloat('0.00',darlehen.get_mon_Raten);
                EditMZ.Clear;
                EditGZ.Text := formatfloat('0.00',darlehen.get_ges_zinsen);
                EditGza.Text := formatfloat('0.00',darlehen.get_ges_zahlung);
             end;
          1: begin
                EditMZ.Text := formatfloat('0.00',darlehen.get_mon_Zinsen);
                EditMR.Text := '';
             end;
    end;
     EditGz.Text := formatfloat('0.00', darlehen.get_ges_zinsen);
     EditGza.Text := formatfloat('0.00', darlehen.get_ges_zahlung);
end;
ButtonSave.Enabled := True;
ButtonClose.Enabled := True;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  liste := TStringList.Create;
end;

procedure TForm1.ButtonNDClick(Sender: TObject);
begin
  ButtonND.Enabled := False;
  EditID.Enabled := False;
  Label2.Enabled := False;
  EditDS.Enabled := True;
  EditB.Enabled := True;
  EditLZ.Enabled := True;
  CB.Enabled := True;
  Label3.Enabled := True;
  Label4.Enabled := True;
  Label5.Enabled := True;
  Label6.Enabled := True;
  if RG.ItemIndex = -1
  then begin
          showmessage('Bitte Darlehensart auswählen! ');
       end
  else begin
          liste.LoadFromFile('darlehen.txt');
          anz := + liste.Count + 1000;
          //showmessage(inttostr(anz));
          EditID.Text := upcase(RG.Items[RG.ItemIndex][1]) + inttostr(anz);
          case RG.ItemIndex of
          0: darlehen := TAnnuitaetendarlehen.create(Editid.Text);
          1: darlehen := TEndfaelliges_Darlehen.create(Editid.Text);
          end;
          ButtonBA.Enabled := True;
       end;
end;

procedure TForm1.RGClick(Sender: TObject);
begin
ButtonND.Enabled := True;
Label2.Enabled := True;
end;

procedure TForm1.ButtonSAVEClick(Sender: TObject);
begin
  liste.Add(darlehen.speichern);
  liste.SaveToFile('darlehen.txt');
  showmessage('Daten erfolgreich gespeichert!');
  liste.Free;
  darlehen.Free;
end;

procedure TForm1.ButtonCLOSEClick(Sender: TObject);
begin
close;
end;

end.

Unit2:

Delphi-Quellcode:

unit UDarlehen;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls, Math;

type
 TDarlehen = class
  protected
    Ident: string;
    Darlehensschuld: real;
    Beginn: TDateTime;
    Laufzeit: integer;
    Jahreszins: real;
    A: real;
  public
    constructor create;
    procedure set_DS (Wert: real);
    procedure set_BE (Wert: TDateTime);
    procedure set_LZ (Wert: integer);
    procedure set_JZ (Wert: real);
    function get_mon_Zinsen(): real; virtual;
    function get_mon_Raten(): real; virtual;
    function get_ges_zinsen(): real; virtual;
    function get_ges_zahlung(): real;
    function speichern(): string;
 end;

 TAnnuitaetendarlehen = class(TDarlehen)
   private
   public
    constructor create(id: string);
    function get_mon_Raten(): real; override;
    function get_ges_Zinsen(): real; override;
 end;

 TEndfaelliges_Darlehen = class(TDarlehen)
    public
      constructor create(id: string);
      function get_mon_Zinsen(): real; override;
      function get_ges_Zinsen(): real; override;
 end;

var
darlehen: TDarlehen;


implementation


//*-----*//TDarlehen//*-----*//

constructor TDarlehen.create;
begin
//
end;


procedure TDarlehen.set_DS (Wert: real);
begin
  Darlehensschuld :=  wert;
end;


procedure TDarlehen.set_BE (Wert: TDateTime);
begin
  Beginn :=  wert;
end;


procedure TDarlehen.set_LZ (Wert: integer);
begin
  Laufzeit :=  wert;
end;


procedure TDarlehen.set_JZ (Wert: real);
begin
  Jahreszins := wert;
end;


function TDarlehen.get_mon_Zinsen(): real;
begin
//
end;


function TDarlehen.get_mon_Raten(): real;
begin
//
end;


function TDarlehen.get_ges_zinsen(): real;
begin
//
end;


function TDarlehen.get_ges_zahlung(): real;
begin
  result := Darlehensschuld + get_ges_zinsen;
end;


function TDarlehen.speichern(): string;
begin
  result := Ident + '#' + formatfloat('0.00',darlehensschuld)
                  + '#' + datetostr(Beginn)
                  + '#' + inttostr(Laufzeit)
                  + '#' + formatfloat('0.00',jahreszins)
                  + '#' + formatfloat('0.00',get_mon_zinsen)
                  + '#' + formatfloat('0.00',get_mon_raten)
                  + '#' + formatfloat('0.00',get_ges_zinsen)
                  + '#' + formatfloat('0.00',get_ges_zahlung);
end;


//*-----*//TAnnuitaetendarlehen//*-----*//

constructor TAnnuitaetendarlehen.create(id: string);
begin
  Ident := id;
end;


function TAnnuitaetendarlehen.get_mon_Raten(): real;
begin
  result := Darlehensschuld * power(1 + Jahreszins/1200, Laufzeit)
            *(Jahreszins/1200) /(power(1 + Jahreszins/1200, Laufzeit) -1);
  //Power errechnet aus Base und einen beliebigen Wert die Potenz. Wird als
  //Exponent ein Bruchwert oder ein Wert größer MaxInt angegeben,
  //muss Base größer als 0 sein.
end;


function TAnnuitaetendarlehen.get_ges_Zinsen(): real;
begin
  result := get_mon_Raten * laufzeit - Darlehensschuld;
end;


//*-----*//TEndfaelliges_Darlehen//*-----*//


constructor TEndfaelliges_Darlehen.create(id: string);
begin
  Ident := id;
end;


function TEndfaelliges_Darlehen.get_mon_Zinsen(): real;
begin
  result := get_ges_Zinsen 
end;


function TEndfaelliges_Darlehen.get_ges_Zinsen(): real;
begin
  result := Darlehensschuld * power(1 + Jahreszins/100 {wegen Prozent},
            Laufzeit/12) - Darlehensschuld
end;                                                                           


end.

[DeddyH]

Zitat:

Zitat von XardasLP (Beitrag 1328510)

Zitat:

BTW.: Was hat das mit Memory zu tun?

Das Memory kommt ja erst noch.

Achso, dann stehst Du auch stundenlang im Baumarkt, weil Du Dich nicht für das richtige Türschloss für Dein neues Haus entscheiden kannst, bevor morgen früh der Bagger kommt, um die Grube auszuheben?

[Monday]

In einem Projekt immer das wichtigste zuerst. Gut, du hast schon viele Ideen gesammelt. Aber das Hauptprogramm ist das Spiel selbst. Deshalb mach zuerst das Memory. Die zwölf Kärtchen, anklicken, umdrehen, vergleichen, zählen und zwar als Einzelspieler. Damit bist du schon genug beschäftigt. (Wenn das nicht funktioniert, ist alles andere sowieso umsonst gewesen.) Mach die Kärtchen ruhig erstmal an einer fixen Position, der Zufall kann später auch noch kommen. Das ist einfacher.

Danach könntest du über Mehrspieler, gegen Computer usw. nachdenken (Das funktioniert nur wenn der Einzelspieler schon läuft, und ist auch noch schwierig genug!).

Menüführung, Login usw. ist hier das unwichtigste (und behandelt einen ganz anderen Teilaspekt). Man braucht es gar nicht, und falls man es wirklich will, kann man es am Schluss noch dazu machen. Auch wenn man im Programm zuerst in das Menü gehen würde, als zweites Einstellungen machen würde usw. ist das beim Programmieren andersrum. Das wichtigste zuerst. Deine Gesamtvorstellungen sind gut, aber über das Ziel hinausgeschossen.

LG

[XardasLP]

Tja, das da oben ist eine so genannte KOMPLEXAUFGABE bei uns.
Und das was wir jetzt aufgelegt bekommen haben steht in keiner Weise mit dem was wir können in Relation. 85% Unbekannte Sachen herausfinden erscheint mir schon ziemlich krass.

Delphi-Quellcode:

Mach die Kärtchen ruhig erstmal an einer fixen Position, der Zufall kann später auch noch kommen. Das ist einfacher.

Danach könntest du über Mehrspieler, gegen Computer usw. nachdenken (Das funktioniert nur wenn der Einzelspieler schon läuft, und ist auch noch schwierig genug!).

Werde ich denke sowieso machen, denn nur die angebliche Vollversion umfasst zufällige Spielfelder.
Ich muss das ja alles machen, kann mich nicht beschrenken. Das ist gefordert und wie ich das mache interessiert den Typ nicht.

Der meint statt Listbox.Items.Add ist Listbox.Lines.Add richtig... also richtige Gammellehrer wo wir Schüler so krass viel kernen - NICHT!

[Luckie]

Zitat:

Zitat von XardasLP (Beitrag 1328512)

Zitat:

In diesem Thread geht es um das Memory Spiel und nicht um das Speichern von Benutzername und Passwort.

Ich mache doch nicht mehrere Threads für ein Komplexprogramm

Doch genau das sollst du! Oder wie stellst du dir vor, wie man mit der Suche je was wieder finden soll, wenn drei vier Probleme in einem Thread besprochen werden? Davon mal abgesehen, dass es dann im Thread drunter und drüber geht.

Also mache bitte für dein Login Problem einen neuen Thread auf.

Zitat:

am Ende muss das ja alles eine Verbindung haben.

Aber es sind nun mal unabhängige Probleme die einzeln nichts miteinander zu tun haben. Also gilt, laut der Forenregeln, dass man für jedes eigenständige Problem einen separaten Thread auf macht.

[XardasLP]

Ja kann ich ja dann machen. Also in der Prüfung sind beim Klassen-programmieren dann immer diese schon als Klassendiagramm vorgegeben.

Deshalb weiß ich jetzt 0 womit ich anfangen soll, weil ich nur weiß das wir mit set, get und so gearbeitet haben. Aber was da im konkreten dann möglich und umsetzbar ist weiß ich auch nicht.

TSpieler

Zeitmessung dort mit rein oder doch bei TSpiel?


Die Karten werden mit create benutzt und mit .free gelöscht?
Wie mache ich das gefundene Karten nicht im Speicher rumchillen sondern wirklich weg sind.
.Destroy macht ja auch nicht so das was es auf deutsch heißen soll.

Noch dazu fehlt uns der Hilfekatalog bei Betriebssystemen über Windows 7 wird dieser nicht angezeigt

[Luckie]

Zitat:

Die Karten werden mit create benutzt und mit .free gelöscht?

Nein. Mit Create wird ein Objekt von einer Klasse angelegt. Danach kann man die Klasse "benutzen". Mit Free wird das Objekt wieder freigegeben.

Zitat:

Wie mache ich das gefundene Karten nicht im Speicher rumchillen sondern wirklich weg sind.

Jeder Karte ist ein Objekt der Klasse TKarte. Verwaltet werden die Kartenobjekte in einer Liste. Brauchst du ein Kartenobjekt nicht mehr gibst du es frei (Free) und löscht es aus der Liste.

Zitat:

Destroy macht ja auch nicht so das was es auf deutsch heißen soll.

to destroy = zerstören. Und warum denkst du jetzt, dass die Methode nicht das macht, was sie vom Namen her vermuten lässt?

Zitat:

Noch dazu fehlt uns der Hilfekatalog bei Betriebssystemen über Windows 7 wird dieser nicht angezeigt

Neues Thema, neuer Thread!

[XardasLP]

Zitat:

Jeder Karte ist ein Objekt der Klasse TKarte. Verwaltet werden die Kartenobjekte in einer Liste. Brauchst du ein Kartenobjekt nicht mehr gibst du es frei (Free) und löscht es aus der Liste.

Sollten die Karten nicht auf einem Spielfeld, also einem Panel beispielsweise liegen. Was für eine Liste meinst du?

ListBox oder die im Quelltext erstellte liste mit der man auch extern was abspeichern kann?

[Luckie]

Jedes Kartenobjekt hat zum Beispiel die Eigenschaften: Grafik, Position. Verwaltet werden die mit einer Klasse TObjectList (Stellt Delphi schon zur Verfügung).

Die Klasse TSpielfeld geht jetzt die Objektliste durch und zeichnet die Grafik der Karte an die Position aus dem Karten Objekt.

[XardasLP]

Delphi-Quellcode:

var
  FormSpiel: TFormSpiel;
  ObjektListe: TObjectList;

Wo schreibt man denn die ObjectList hin, wenn sie angeblich bekannt ist?


Also nicht mit einem Panel Feld machen?
https://gyazo.com/7ec9edf38b5e4696cd6bb1c12b748472


Klassen in eine extra Unit?

[Luckie]

Die KartenListe kann eine Eigenschaft von der Klasse TSpielfeld sein.

Wo und wie du die Karten anzeigst ist dir überlassen. Das können Images auf der Form sein. Das können einzelne Panels für jede Karte sein.

Ob du für jede Klasse eine Unit nimmst, bleibt dir überlassen. Ich würde es aber empfehlen.

[XardasLP]

Wegen dem Memory was es von diesem Michael Puff gibt:

Delphi-Quellcode:

type
  TCardStatus = (csBlind, csRevealed, csFound); //Wieso benötigt das keine Klasse?

type
  TCard = class;

  TOnFlip = procedure(Card: TCard) of object; //Wieso benötigt das keine Klasse? Was macht OnFlip?
  TCard = class(TPanel)
  private
    FValue: Integer; //Bezeichnung der Karte erhalten, warum als Zahl?
    FStatus: TCardStatus; //verdeckt, aufgedeckt, gefunden
    FOnFlip: TOnFlip; //Was macht OnFlip?
    function GetValue: Integer; //Bezeichnung der Karte erhalten, warum als Zahl?
    procedure SetValue(Value: Integer); //Wieso muss der Kartenname geändert werden, warum als Zahl?
    function GetStatus: TCardStatus;
    procedure SetStatus(Value: TCardStatus);
    procedure Click(Sender: TObject); reintroduce; //Wird eine als virtual deklarierte Methode verdeckt (d.h. in einer abgeleiteten Klasse wird eine gleichnamige Methode deklariert, die nicht mit der override-Direktive versehen ist), gibt der Delphi-Compiler Warnungen aus. Um die Warnung zu verhindern, wird die neue Methode, die die virtuelle Methode verdecken soll, mit reintroduce gekennzeichnet.
    property OnFlip: TOnFlip read FOnFlip write FOnFlip; //Was macht "property" auch noch nie verwendet bisher.
  public
    constructor Create(Owner: TComponent); override;
    property Value: Integer read GetValue write SetValue; //Was macht "property" auch noch nie verwendet bisher.
    property Status: TCardStatus read GetStatus write SetStatus; //Was macht "property" auch noch nie verwendet bisher.
  end;

[DeddyH]

Vielleicht hilft das hier weiter: http://downloads.delphi-treff.de/DelphiStarter.pdf

[Luckie]

Boah. Das Programm habe ich vor sieben oder mehr Jahren geschrieben.

Als erstes: Wenn dir Schlüsselwörter nichts sagen, guck bitte in der Hilfe oder nutze das Internet. Und hättest du dir mein Klassen Tutorial mal angeguckt, würden sich schon viele Fragen von selbst beantworten.

Delphi-Quellcode:

TCardStatus = (csBlind, csRevealed, csFound); //Wieso benötigt das keine Klasse?

Weil es eine Typ-/Mengendeklaration ist.

Delphi-Quellcode:

TOnFlip = procedure(Card: TCard) of object; //Wieso benötigt das keine Klasse? Was macht OnFlip?

Weil es eine Ereignisdeklaration ist. Das Ereignis wird ausgelöst, wenn eine Karte aufgedeckt wird. Da muss ja was passieren: ist es die erste Karte oder die zweite? Sind sie gleich oder ungleich....

Delphi-Quellcode:

FValue: Integer; //Bezeichnung der Karte erhalten, warum als Zahl?

Weil ich keine Lust hatte mich mit Grafiken runzuschlagen.

Delphi-Quellcode:

function GetValue: Integer; //Bezeichnung der Karte erhalten, warum als Zahl?

Siehe oben. Der Einfachheithalber habe ich Zahlen benutzt anstatt Grafiken.

Delphi-Quellcode:

procedure SetValue(Value: Integer); //Wieso muss der Kartenname geändert werden, warum als Zahl?

Die Karte muss ja einen Wert erhalten bzw. eine Grafik.

Delphi-Quellcode:

procedure Click(Sender: TObject); reintroduce; //Wird eine als virtual deklarierte Methode verdeckt (d.h. in einer abgeleiteten Klasse wird eine gleichnamige Methode deklariert, die nicht mit der override-Direktive versehen ist), gibt der Delphi-Compiler Warnungen aus. Um die Warnung zu verhindern, wird die neue Methode, die die virtuelle Methode verdecken soll, mit reintroduce gekennzeichnet.

Ist der Kommentar von dir oder von mir? :shock: Aber Hilfe lesen hilft.

Delphi-Quellcode:

property

Siehe Hilfe oder jedes beliebige Tutorial über Klassen.