Tresorknacker

Dos2k3 schrieb:

Ich schätze, es würde nichts passieren, da der Else-Zweig überflüssig ist.

Richtig. Dazu noch eins: nach If, Do Until und Co. sind Vergleiche mit True und False überflüssig. Du kannst die Sub also zweimal etwas verbessern, indem Du Folgendes schreibst und damit die Verschachtelung um eine Stufe senkst:

Dos2k3 schrieb:

Menü.Show()
habe ich umgeändert in
Menü.Visible = True

Vom Degen in die Schlaufe. .Show macht das Gleiche wie .Visible = True
Das Problem ist nicht Show oder Visible, sondern Menü! Weißt Du, was Menü in Menü.Show genau ist? Wo wurde dieses Menü-Ding definiert, also wo steht, was Menü genau ist? Bitte sagen.

Ansonsten noch die Geschichte mit And ↮ AndAlso (siehe am Ende meines letzten Posts).
Und cmdAbbrechen.PerformClick(): Neeneenee. Pack den Inhalt der Sub CmdAbbrechen_Click in eine eigene Sub mit passendem Namen und rufe diese Sub dann von CmdAbbrechen_Click aus auf. Und statt cmdAbbrechen.PerformClick() rufst Du dann auch die neue Sub auf.

Aber hey! Respekt, dass Du Option Strict On und die Entfernung des VB6-Namespaces alleine hinbekommen hast! Da tut sich so manch anderer echt schwer oder versucht es gar nicht erst. Gut!

Dos2k3 schrieb:

Das Menü-Ding ist eine Form, die als Startformular festgelegt ist

Das ist nur die halbe, halbe Wahrheit. Halb zum einen, weil die Form Menü eine Klasse ist, also ein Bauplan! Damit kann man nicht zur Laufzeit an sich arbeiten. Klassen müssen instanziiert werden. Anders ausgedrückt: Man muss mithile des Bauplans (also der Klasse) ein Objekt erzeugen. Und mit diesem Objekt kann man arbeiten. Daher ist Menü zwar eine Klasse. Aber die kann man nicht als Startformular festlegen, da sie eben kein Objekt, sondern ein Bauplan ist. Und zum anderen Halb: Menü ist nämlich noch was:

Dank VisualBasic6-Rückkompatibilität gibt es noch etwas, was "Menü" heißt. Und das ist nämlich tatsächlich ein Objekt. Nur hast Du das nicht aktiv erzeugt, sondern wird im Hintergrund erzeugt. Das heißt, wenn Du schreibst Menü.Show(), dann glaubst Du zwar, mit der Klasse Menü zu arbeiten. Aber in Wirklichkeit arbeitest Du mit einem Objekt, was Dir der Compiler untergeschoben hat. Jetzt könnte man natürlich sagen: "Was soll's? Hauptsache es funktioniert." Aber Verständnis ist eben was anderes. Denn spätestens wenn Du Dir eine eigene Klasse schreibst - was Dir auch empfohlen wurde, schließlich ist doch das Ziel "besser programmieren", oder?* - wirst Du merken, dass sowas hier nicht klappt - obwohl es doch beim Form scheinbar auch funktioniert hat:

Denn dann meckert plötzlich der Compiler, dass Tresor eine Klasse ist, aber kein Objekt. Und dieser scheinbare Widerspruch zu Menü und Co. wird erst klar, wenn man sich darüber bewusst ist, dass eben Menü nicht immer das ist, was man glaubt.

Noch eine Sache, um das Spiel etwas spannender zu machen: Nach jeder Eingabe und Wechsel auf die nächste Eingabe könntest Du ja ne Nachricht einblenden lassen, sowas wie "Du bemerkst, wie der Alarm ausgelöst wurde.", "In der Ferne hörst Du die ersten Polizeisirenen.", ...

* OOP ist eine Möglichkeit, aber es gibt ja auch z.B. funktionale Programmierung. Oder ein alter Schinken: prozedurale Programmierung (das ist ungefähr das, was hier vorliegt - soll aber keine Beleidigung sein, sondern ist nur meine neutrale Einschätzung). Man muss sich nur auf irgendwas festlegen.

Gar nicht mal so schlecht geschlussfolgert. Ok, der Name Form1 ist ausbaufähig. Aber vom Prinzip her richtig. Mit Dim Form1 As New Menü erzeugst Du selbst ein Menü-Objekt namens Form1. Und damit weißt Du, wenn Du Form1.Show() aufrufst, dass Du mit einem "echten" Objekt arbeitest. Jetzt ist die Sache bei Dir allerdings so: Menü brauchst Du nicht explizit zu instanziieren, da Du dies bereits durch Festlegung des Startformulars vom Compiler machen lässt. Aber! Wenn Du vom Menü aus das Spielformular Tresorknacker richtig (!) aufrufen willst, musst Du mit Instanziierung vorgehen, also am besten:

Das mit dem Using ist dafür da, um das Tresorknackerspielfeld aufzubauen und nach Schließen des Spielfensters es auch sauber wieder zu entsorgen.
Und dann kannst Du Menü.Show und Meü.Hide in Tresorknacker.VB entsorgen. Nicht nur, weil sich das Hauptmenü darum selber kümmert, sondern weil Tresorknacker auf Menü gar keinen Einfluss nehmen darf! (Es geht leider, aber ist m.E. ein sog. code smell).

Ich würde die Formen anders benennen.
Anstatt Tresorknacker in frmTresorknacker.
Wenn ich das Spiel starten möchte, und auf den cmdBeginnen Button klicke passiert nix.
Ich müsste zuerst If Not SpielLäuft Then Return raus kommentieren.
Außerdem sollte man die Form auf FixedDialog stellen,
um den Fehler zu beseitigen - (Siehe Anhang!).

Das mit If Not Spielläuft ist auf meinem Mist gewachsen. Richtig ist If Spielläuft.
Der Tresor-Code, der richtig gewesen wäre, wird am Ende nicht mehr angezeigt.
An dem Code ist noch viel ausbaufähig, aber das Endbild ist bei mir ok.

Ich habe die Form Größe mit der Maus verändert.
Deshalb sollte man die Festeinstellen(FixenDialog).
Außerdem habe ich den Return Wert von Code_generieren()
in die MaskedTextboxen eingegeben.
Und herausgefunden das man immer verliert!
Auch wenn der Code richtig war.
Deshalb ändere diesen Code:


Jetzt sollte das Problem beseitigt sein!

Bzgl. der MTBs schau ich noch. Aber zu der anderen Geschichte weiß ich weiter. Du hast zwar angefangen, nicht mehr mit Tresorknacker.Show() zu arbeiten, bist aber noch nicht mal auf halber Strecke stehengeblieben. Es sind z.B. noch Über.Show(), aber auch Meldung.Show() übrig. Und was machst Du innerhalb von der Meldung-Klasse? If Tresorknacker.Spiel_Gewonnen = False.
1. Vergleiche bei If mit True und False sind zu ersetzen, das hatten wir auch schon.
2. Nachdem Du in Menü nun mit Using Spielfeld As New Tresorknacker arbeitest, hast Du nun 2 Tresorknackerobjekte: Die verhasste, da untergeschobene und vom Compiler heimlich erzeugte Property namens Tresorknacker und das von Dir korrekt erzeugt Objekt namens Spielfeld. Der Spieler sieht nun Spielfeld und macht dort seine Eingaben. Aber in Meldung wertest Du die Spiel_Gewonnen-Variable von Tresorknacker aus, was aber nie zu sehen war. Daher musst Du, wenn Du gewonnen/verloren hast, nicht Meldung.Show aufrufen, sondern welche zwei Schritte stattdessen machen? Instanziieren und anzeigen! Und dann kannst Du mehreres machen, um das Spielergebnis anzeigen zu lassen. Du kannst:

• einen Meldung-Konstruktor mit Parameter erzeugen und dem bei Instanziierung den Spielstand übergeben
  
• eine Sub innerhalb der Meldung-Klasse erzeugen und dort den Gewinn-Parameter übergeben
  
• eine Public Property (notfalls für den Anfang auch eine normale Public Variable) in Meldung erzeugen, die dann zwischen Instanziierung und Anzeige Deines Meldung-Objektes verändert wird
  

Und dann, wenn das Meldung-Objekt angezeigt wird, wird die Meldung-interne Variable, die von Deinem Spielfeld-Objekt manipuliert/geändert wurde ausgewertet und die entsprechende Ergebnisanzeige erfolgt.

Habe gestern mal den source code überflogen, folgendes ist mir aufgefallen:

Die Formatierung ist etwas kaotisch.
Mal gibt es Leerzeilen zwischen den Methoden, mal nicht.
Inline Kommentare finde ich auch eher ungünstig.
Insgesammt etwas uneinheitlich, das betrifft auch die Benamung.

Die Methoden Versuch_1 bis Versuch_8 können durch eine Methode ersetzt werden, indem du ihr einen Parameter mitgibst:

Ich nutze hier string-interpolation um die durchnummerierten controls anzusprechen, alternativ kann man auch String.Format() nutzen.

Ähnlich sieht es auch mit den beiden Methoden Gewonnen() und Verloren() aus, die können auch in einer Methode erledigt werden:


Die ganze String splitterei ist gar nicht nötig, wenn du entsprechende Datentypen verwendest.
Der Code ist numerisch, warum also mit Strings rumhantieren ?
Die MasketTextBox kümmert sich doch schon um die validierung, also warum die Eingabe nochmal überprüfen ?
Ich habe das mal in einer kleinen Anwendung nachempfunden, so oder so ähnlich würde ich das angehen:
Edit: @Dos2k3 : Habe noch eine Variable eingefügt (Form1.vb Zeile 22), da sonst in jedem Durchlauf der For Schleife Replaced wird.

Und ein Bug ist mir aufgefallen.
Wenn man verloren hat, wird einem der richtige code nicht angezeigt, die Variable Code bleibt Nothing.

Hier mal ein Gegenvorschlag mit (etwas mehr) OOP. Wesentlicher Unterschied neben der Verwendung von 2 zusätzlichen Klassen: Verwendlung von UserControls, die je eine TextBox und das dazugehörige Label zusammenfassen. Erleichtert etwas die Arbeit. Versuch mal soviel wie möglich nachzuvollziehen.
Großer Minuspunkt: Keine Unit-Tests

##########

Dos2k3 schrieb:

Hättet ihr ein paar Tipps, wie ich das mit dem Timer angehen sollte?

Was für einen Timer meinst Du?

Ja, wenn man gewonnen oder verloren hat, ist ja das Spiel vorbei. Also Absicht.
Unit-Tests sind extra Funktionen, die man verwendet, um die Korrektheit der eigentlichen Spielfunktionen zu testen. Das macht man nicht zur Laufzeit, also während des Spiels, sondern dafür gibt es extra Testprojekte, die man ausführen kann, ohne das Spiel zu starten. Wenn man also einen Unit-Test für GetCodeWithMatchesFrom schreibt, dann testet man, ob das rauskommt, was man erwartet. Denn wenn nicht, weiß man, dass man falsch programmiert hat. Mit sowas sollte man zwar so früh wie möglich anfangen, aber es ergibt eigentlich nur dann wirklich Sinn, wenn man TDD und seine Derivate/Erweiterungen betreibt.

##########

bzgl Timer: Sobald man den Start-Button klickt, startet man nen Timer, der auf Interval = 1000 (ms) eingestellt ist und bei jedem Tick ein Label mit der Restzeit aktualisiert. Gleichzeitig wird die Restzeit (die bei z.B. 30 s (Schwierigkeitsgrad einbauen? Der dann ggf. auch die Anzahl der Versuche noch einschränkt) beginnt) um 1 gesenkt. Und wenn sie bei 0 ist, ist das Spiel verloren. Wo scheitert es an der Umsetzung?

Kurze Fragen, sind das Open-Source Bilder oder sind dafür Lizenzen notwendig?
Ich frage es aus dem Grund, da bei dem Intro-Bild ein Bild ist welches sehr noch Gigantic erinnert, kann mih auch täuschen

Aber nichts desto-trotz, solltest DU eventuell abgeben von wo die Bilder herkommen.
Heute klagt ja fast schon jeder, wegen kleinsten Scheiß

Aber das Spiel hört sich interessant an