Tresorknacker

    • Beta
    • Open Source

    Es gibt 42 Antworten in diesem Thema. Der letzte Beitrag () ist von Dos2k3.

      VaporiZed schrieb:

      Weißt Du, was Schlimmes passiert, wenn Du den Else-Zweig mit Exit Sub weglassen würdest? Sag Du es mir.

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


      VB.NET-Quellcode

      1. Menü.Show()
      habe ich umgeändert in

      VB.NET-Quellcode

      1. Menü.Visible = True
      da ich vorher das Menü mit

      Quellcode

      1. Menü.Hide()
      versteckt habe.


      Wozu gibt' eigentlich die Subs lblCode_entsperren und txtCode_entsperren? Die werden doch nirgends benutzt.

      Die werden am Anfang, wenn sich die Form inizialisiert aufgerufen und am Ende jedes Spieles.


      Du solltest für jeder Prozedurdeklaration einen Zugriffsmodifizierer setzen, damit Du weißt, von wo aus man auf die Subs/Functions zugreifen kann.

      Habe ich auch gemacht.


      CType("-", Char()) → "-"c

      Habe ich auch erledigt.


      Der Microsoft.VisualBasic-Namespace ist ja noch bei Projekteigenschaften

      Hab ich leider übersehen. Hab ich jetzt aber entfernt.
      Dateien

      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:

      VB.NET-Quellcode

      1. Private Sub CmdBeginnen_Click(sender As Object, e As EventArgs) Handles cmdBeginnen.Click
      2. If Not SpielLäuft Then Return
      3. 'Einen zufälligen Code erhalten
      4. Code = Code_generieren()
      5. 'Speichern, dass gerade ein Spiel läuft
      6. SpielLäuft = True
      7. 'Die erste Eingabe freigeben
      8. Versuch_1()
      9. End Sub


      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 AndAndAlso (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!
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
      Wo wurde dieses Menü-Ding definiert

      Das Menü-Ding ist eine Form, die als Startformular festgelegt ist. Ich hab da, soweit ich weiß keinen Einfluss drauf, wie Menü dann angezeigt wird.


      Pack den Inhalt der Sub CmdAbbrechen_Click in eine eigene Sub

      Ok, wird gemacht :D

      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:

      VB.NET-Quellcode

      1. Public Class Tresor
      2. Public GewichtInKG As Integer
      3. End Class
      4. '...
      5. Public Sub TrageTresor()
      6. If Tresor.GewichtInKG > 50 Then MessageBox.Show("Zu schwer!")
      7. End Sub

      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.
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
      schließlich ist doch das Ziel "besser programmieren", oder?

      Ja, natürlich


      Du ja ne Nachricht einblenden lassen

      Danke für die Idee :thumbsup: . Ich überlege auch, dazu noch ein Zeitlimit einzubauen, dass man nur einen bestimmten Zeitraum zum knacken hat, bis die Polizei kommt und man verliert.


      Ok, soweit wie ich dass verstanden habe, wird aus der Klasse "Menü" dann ein Objekt erzeugt, dass ich mit 'Menü.Show()' aufrufe. Und genau dieses Objekt habe ich als Startformular für dieses Programm festgelegt. Nach meinem Verständnis müsste ich also 'Dim Form1 As New Menü' und dann 'Form1.Show()' ganz am Anfang machen, was ja irgendwie auch nicht geht oder verstehe ich da was falsch?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Dos2k3“ ()

      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:

      VB.NET-Quellcode

      1. Private Sub CmdStarten_Click(sender As Object, e As EventArgs) Handles cmdStarten.Click
      2. Using Tresorknackerspielfeld As New Tresorknacker
      3. Me.Hide()
      4. Tresorknackerspielfeld.ShowDialog(Me)
      5. Me.Show()
      6. End Using
      7. End Sub

      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).
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
      Ok, danke. Ich glaube, ich habe dass jetzt soweit verstanden und werde das umsetzen.
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Dos2k3“ ()

      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!).


      Visual Basic.NET 8o
      MS-SQL
      8o
      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.
      Bilder
      • Caught.png

        87,41 kB, 910×637, 123 mal angesehen
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
      An dem If Not Spielläuft bin auch ich schuld. Ich hab des einfach übernommen und nicht nochmal überprüft.
      Die Formen habe ich jetzt umbenannt und auf FixedDialog gestellt, wie @Cheffboss geraten hat.
      An dem Problem mit dem richtigen Code bin ich grade dran.
      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:

      VB.NET-Quellcode

      1. Public Shared Spiel_Gewonnen As Boolean = False

      Jetzt sollte das Problem beseitigt sein!
      Visual Basic.NET 8o
      MS-SQL
      8o
      Danke @Cheffboss, jetzt funktionierts wieder. Ich bin auch drauf gekommen dass man immer verliert, aber dass es an Public Spiel_Gewonnen As Boolean = False gelegen hat, da hätte ich noch ein bisschen gebraucht um draufzukommen. Ich frage mich aber, warum des mit Public Spiel_Gewonnen As Boolean = False nicht funktioniert hat. Vorher hat's ja auch funktioniert.

      @VaporiZed dir ist ja auch aufgefallen, dass manche MaskedRexrboxen bei der Eingabe lecken. Hast du eine Idee, warum das so ist?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Dos2k3“ ()

      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.
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

      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:

      VB.NET-Quellcode

      1. Private Sub Versuch(ByVal number As Integer)
      2. Dim txtCode As MaskedTextBox = DirectCast(Controls($"txtCode{number}"), MaskedTextBox)
      3. txtCode.Enabled = True
      4. txtCode.Focus()
      5. DirectCast(Controls($"lblCode{number}"), Label).Enabled = True
      6. End Sub

      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:

      VB.NET-Quellcode

      1. Private Sub Gewonnen(ByVal value As Boolean)
      2. Spiel_Gewonnen = value
      3. Meldung.ShowDialog(Me)
      4. Spiel_abbrechen()
      5. End Sub


      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:

      VB.NET-Quellcode

      1. Imports System.Text
      2. Public Class Form1
      3. Private Code As New List(Of Integer)
      4. Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
      5. GenerateCode()
      6. Text = $"Code: {Code(0).ToString}-{Code(1).ToString}-{Code(2).ToString}-{Code(3).ToString}"
      7. End Sub
      8. Private Sub GenerateCode()
      9. Dim random As New Random
      10. Code.AddRange({random.Next(0, 10),
      11. random.Next(0, 10),
      12. random.Next(0, 10),
      13. random.Next(0, 10)})
      14. End Sub
      15. Private Sub MaskedTextBoxUserCode_KeyDown(sender As Object, e As KeyEventArgs) Handles MaskedTextBoxUserCode.KeyDown
      16. If e.KeyCode = Keys.Enter Then
      17. Dim userCode As String = DirectCast(sender, MaskedTextBox).Text.Replace("-", "")
      18. Dim result As New StringBuilder
      19. For i As Integer = 0 To 3
      20. If Code(i) = CInt(userCode(i).ToString) Then
      21. result.Append(Code(i).ToString)
      22. Else
      23. result.Append("X")
      24. End If
      25. Next
      26. LabelResult.Text = result.ToString
      27. End If
      28. End Sub
      29. End Class

      VB.NET-Quellcode

      1. <Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _
      2. Partial Class Form1
      3. Inherits System.Windows.Forms.Form
      4. 'Das Formular überschreibt den Löschvorgang, um die Komponentenliste zu bereinigen.
      5. <System.Diagnostics.DebuggerNonUserCode()> _
      6. Protected Overrides Sub Dispose(ByVal disposing As Boolean)
      7. Try
      8. If disposing AndAlso components IsNot Nothing Then
      9. components.Dispose()
      10. End If
      11. Finally
      12. MyBase.Dispose(disposing)
      13. End Try
      14. End Sub
      15. 'Wird vom Windows Form-Designer benötigt.
      16. Private components As System.ComponentModel.IContainer
      17. 'Hinweis: Die folgende Prozedur ist für den Windows Form-Designer erforderlich.
      18. 'Das Bearbeiten ist mit dem Windows Form-Designer möglich.
      19. 'Das Bearbeiten mit dem Code-Editor ist nicht möglich.
      20. <System.Diagnostics.DebuggerStepThrough()> _
      21. Private Sub InitializeComponent()
      22. Me.MaskedTextBoxUserCode = New System.Windows.Forms.MaskedTextBox()
      23. Me.LabelResult = New System.Windows.Forms.Label()
      24. Me.SuspendLayout()
      25. '
      26. 'MaskedTextBoxUserCode
      27. '
      28. Me.MaskedTextBoxUserCode.Font = New System.Drawing.Font("Microsoft Sans Serif", 12.0!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))
      29. Me.MaskedTextBoxUserCode.Location = New System.Drawing.Point(12, 12)
      30. Me.MaskedTextBoxUserCode.Mask = "0-0-0-0"
      31. Me.MaskedTextBoxUserCode.Name = "MaskedTextBoxUserCode"
      32. Me.MaskedTextBoxUserCode.Size = New System.Drawing.Size(65, 26)
      33. Me.MaskedTextBoxUserCode.TabIndex = 0
      34. '
      35. 'LabelResult
      36. '
      37. Me.LabelResult.AutoSize = True
      38. Me.LabelResult.Font = New System.Drawing.Font("Microsoft Sans Serif", 12.0!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))
      39. Me.LabelResult.Location = New System.Drawing.Point(83, 15)
      40. Me.LabelResult.Name = "LabelResult"
      41. Me.LabelResult.Size = New System.Drawing.Size(53, 20)
      42. Me.LabelResult.TabIndex = 1
      43. Me.LabelResult.Text = "XXXX"
      44. '
      45. 'Form1
      46. '
      47. Me.AutoScaleDimensions = New System.Drawing.SizeF(6.0!, 13.0!)
      48. Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font
      49. Me.ClientSize = New System.Drawing.Size(140, 49)
      50. Me.Controls.Add(Me.LabelResult)
      51. Me.Controls.Add(Me.MaskedTextBoxUserCode)
      52. Me.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedSingle
      53. Me.MaximizeBox = False
      54. Me.MinimizeBox = False
      55. Me.Name = "Form1"
      56. Me.Text = "Form1"
      57. Me.ResumeLayout(False)
      58. Me.PerformLayout()
      59. End Sub
      60. Friend WithEvents MaskedTextBoxUserCode As MaskedTextBox
      61. Friend WithEvents LabelResult As Label
      62. End Class

      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.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „FormFollowsFunction“ ()

      Ich hab mal versucht, alles so wie oben gewünscht, zu verbessern. Hättet ihr ein paar Tipps, wie ich das mit dem Timer angehen sollte?

      Die Formatierung ist etwas kaotisch

      Ich weiß. Hast du Tipps, wie ich es besser machen könnte?
      Dateien
      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?
      Dateien
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

      Ich habe vor, irgendwann mal einen Timer einzubauen, sodass man nur begrenzt Zeit hat, um den Code zu knacken.
      Für deinen Gegenvorschlag mit OOP bin ich dankbar. Den Grundablauf verstehe ich soweit, aber für mich als Anfänger ist das einfach noch zuviel des Guten. Ich muss mich da mal in Ruhe rantasten. Aber immerhin habe ich jetzt eine Vorstellung, wie das Programm mit OOP aussehen sollte. :thumbsup: Ich werde mal versuchen, alles mehr objektorientiert zu gestalten und ich werde auf jeden Fall ein UserControl machen. Beim Testen deines Programmes ist mir noch aufgefallen, dass sich das Spielfeld nach jedem Spiel schließt und man zum Menü zurückkehrt. Ist das so gewollt oder ist dir das ausversehen passiert? Und noch nebenbei eine Frage: Was sind Unit-Tests ???
      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?
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
      Ich wollte nur davor nachfragen, nicht dass es einen einfacheren und besseren Weg gibt als meinen. Ich hatte das mit dem Timer nämlich auch im Kopf und war mir nicht sicher, ob das der Beste Weg ist.
      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 :D

      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 :)