Whiz-zarD

Konstruktoren sollte keine Logik besitzen. Wie der Name schon sagt, dient er zur Konstruktion eines Objektes. Daher sollte der Konstruktor auch nur dafür verwendet werden. Sprich, die Zeilen: player.MoveTo(World.LocationById(World.location_id_fight)); MonsterAppear(this, new EventArgs()); Sollten da raus.

Du reichst Player und Monster in den Konstruktor der Fight-klasse rein und speicherst diese dann als Membervariable in dieser Klasse ab.

Die Methode ist doch in der Spieler-Klasse definiert, dann kannst du doch die Eigenschaften/Methoden der Klasse aufrufen public int Attack(Monster monster) { var attack = this.GetDamage(); monster.TakeDamage(attack); return monster.CurrentHitpoints; } private int GetDamage() { // Logik }

Das ist eigentlich auch der richtige Weg. Die Attack()-Methode in der Player-Klasse verursacht einige Probleme. Zum einen vermischt man Datenhaltung mit der Logik. Wenn man es weiterspinnt, dann wird es ja bei der Attack()-Methode nicht bleiben. Dann gibt es vielleicht noch eine Talk()-, eine Walk()-, eine Use()-, etc. Methode. Die Klasse hat dann mehrere Zuständigkeiten. Sie hält also nicht nur die Daten des Spielers, sondern ist auch noch für den Kampf, fürs Reden, fürs Laufen, etc. zuständig. Darüber hinaus wird die Player-Klasse von der Monster-Klasse abhängig. Das mag vielleicht in einem einigen Projekt nicht so schlimm sein aber wenn man z.B. die Monster in ein separates Projekt auslagert, so wird es schon etwas problematischer, wenn man dann die Player-Klasse einzeln testen möchte. Eine Klasse, die den Kampf koordiniert, dient dann als "Verbindungsstück" (Integration) zwischen Spieler, Monster und ggf. der UI und die Player- und Monster-Klassen können als "dumme" Objekte (POCOs) behandelt werden und brauchen dann keinerlei Logik.

INotifyPropertyChanged Ein anderes Stichwort wäre "Data Binding"

Wenn du es vernünftig machen willst, dann ja, denn das sind die Grundkonzepte der Objektorientierung. Wenn du fehlerhaften, unwartbaren, unübersichtlichen, komplizierten und verdoppelten Code produzieren willst, dann nein. Weil du dich strikt weigerst, etwas neues zu lernen: Man könnte dir von Patterns, etc. erzählen aber das ist einfach vergeudete Mühe, weil du die sowieso nicht einsetzen willst.

Ein weiterer Tipp: Solche Konstruktoren, wie z.B. public Player(int curHP, int maxHP, int gold, int curExp, int maxExp, int level, int attack) { ... } Sind unter C# nicht nötig und auch beim Aufruf schlecht lesbar. Keiner wird auf den ersten Blick verstehen, welche Parameter was ist: private Player _player = new Player(20, 20, 0, 0, 10, 1, 2); Man muss den Konstruktor kennen, um zu wissen, was z.B. die letzte 2 bedeutet. C# bietet hier den Objectinitializer, der das Ganze lesbarer macht: private player = new Player { CurHP = 20, MaxHP = 20, Gold = 0, CurExp = 0, MaxExp = 10, Level = 1, Attack = 2 }; Anstatt eine List<Monster> zu nehmen, um darüber dann zu iterieren, um das jeweilige Monster mit der Id herauszusuchen, verwendet ein Dictionary<int, Monster>. Beispiel: public Dictionary<int, Monster> monsters = new Dictionary<int, Monster> { { monster_id_wolf, new Monster(monster_id_wolf, "Wolf", 10, 10, 1, 10, 2, 1) }, { monster_id_bee, new Monster(monster_id_bee, monster_id_bee, "Bee", 1, 1, 1, 1, 1, 1) } } Dann brauchst du die MonsterById()-Methode nicht mehr, sondern kannst direkt mit monsters[monster_id_wolf] darauf zugreifen. Natürlich kannst du auch hier den oben genannten Tipp mit dem Konstruktor nehmen. Ansonsten ist da noch sehr viel, was man anders machen sollte aber darüber zu reden bringt wohl nichts.

Und das ist schon falsch...

Ich habe keine hohen Ansprüche. Das Problem ist einfach, dass dir nicht klar ist, was du da eigentlich tust und das wird zu Frustration führen. Du willst auch nichts dazu lernen, indem du dich strikt weigerst neue Dinge zu lernen und mit deinem Laienwissen bist du noch nicht so weit, ansatzweise sowas aufbauen zu können. Das fängt schon damit an, dass du Klassen und Membervariablen static machst, ohne den Sinn dahinter zu verstehen und was das bedeutet, wenn du diese static machst.

Auweia. Da ist so ziemlich alles falsch, was man nur falschmachen kann. Ich komme erst am Wochenende dazu, etwas längeres zu schreiben aber man sieht schon deutlich, dass dies für dich einige Nummern zu groß ist. Sorry, aber fange mit was kleinerem an. Ehrlich, du machst dir keine Freude damit.

Web-Applikationen sind auch nicht mehr das "Nonplusultra". Der Trend geht in Richtung Mobile-First. D.h. es wird zuerst eine Mobile-App entwickelt, bevor man eine Web-App entwickelt. PHP- und ASP.NET-Anwendungen sind auch schon auf dem Rückzug. Sie werden uns zwar noch viele Jahre begleiten aber der Trend in Web-Apps geht in Richtung sog. Single-Page-Applikationen (SPA). SPAs haben den Vorteil, dass der Server entlastet wird, indem das Rendering auf dem Client stattfindet. D.h. der Server schickt nur noch die rohen Daten zum Client (Browser) und der Browser bastelt daraus selbst das HTML-Dokument. Für SPAs braucht man auch keinen dicken Webserver ala Apache, sondern es reicht auch was leichtgewichtiges, was die Anfragen annimmt und jemandem damit beauftragt. In der .NET-Welt gibt es z.B. NancyFx, was einen HTTP-Request annimmt und verarbeiten kann. NancyFx ist angelehnt an das Ruby-Projekt Sinatra. NancyFx könnte also z.B. ein HTTP-Request entgegennehmen und es an einen Microservice weiterleiten und das Ergebnis zurück zum Client schicken. Auf dem Client läuft dann ein Framework ala AngularJS oder React, mit denen dann die HTML-Dokumente erstellt werden. Klassische WinForms Anwendungen gibt es zwar noch in der Business-Welt aber die sind eher historisch begründet. Wir entwickeln auch noch eine aber wir haben mit der Planung der nächsten Generation angefangen und die deutliche Mehrheit unserer Kunden (Banken) wollen keine Desktop-Applikation, weil sie damit einen höheren Aufwand haben, da sie virtuelle Desktops bereitstellen müssen. Auch der Trend bei unseren Kunden geht also hin zu mobilen Endgeräten. Also nein, auf Desktop-Anwendungen würde ich heutzutage nicht mehr setzen, es sei denn, du hast da was sehr spezielles, was in einem Browser nicht funktioniert oder vom Vorteil wäre, wenn es auf einem Desktop läuft aber selbst bei 3D-Grafiken ist WebGL da schon sehr weit. Man muss auch berücksichtigen, dass selbst bei Ottonormalverbrauchern der Trend in Richtung Mobile-Geräten geht und da sollte man sich schon fragen, ob es Klug ist, eine sehr große Klientel auszugrenzen.

Er ist über 30. Mit Sicherheit geht er nicht mehr zur Schule...

Ich sehe das ähnlich, wie @Gottlike. Dein Kenntnisstand ist noch nicht so weit, um so ein Projekt anzugehen. Ich will nicht zu Nahe treten aber dir ist OOP offenbar immer noch nicht so wirklich klar. Das fängt schon, wie gesagt, mit der statischen Klasse für den Spieler an. Wieso soll sie statisch sein? Das macht überhaupt keinen Sinn. Statische Klassen machen nur in wenigen Situationen wirklich Sinn. In der Praxis werden sie aber oft dann verwendet, wenn der Entwickler gar nicht weiß, was er eigentlich tut. Das nächste ist, dass dir gar nicht klar ist, wie man Programmlogik von der Oberfläche trennt. Die Main-Methode einer klassichen WinForms-Anwendung besteht lediglich nur aus drei Zeilen Code: static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } Was du noch in die Main()-Methode reinkloppen willst, erschließt sich mir erst mal nicht. Ein erfahrener Entwickler wird mit Sicherheit diese Methode noch erweitern, z.B. mit der Initialisierung eines IoC-Containers oder sonstigen Frameworks aber das sind Techniken, mit denen du mit deinem Wissensstand noch nichts anfangen kannst. Ich vermute auch mal, dass dir die ganzen Designpatterns nichts sagen. Wenn man dein Beitrag auch durchliest, machst du dir viel mehr Gedanken, um die Oberfläche, anstatt um die Architektur der Software, daher ist das Ziel noch viel zu hochgesteckt. Fange mit Konsolenanwendungen an, um überhaupt OOP zu verstehen und um ein Gefühl dafür zu bekommen. Eine Oberfläche ist eigentlich nur ein schmuckes Beiwerk für eine Software. Ich persönlich würde vielleicht vorschlagen, eine API für Schach zu entwerfen. Ohne Oberfläche. Also überlegen, welche Datenstruktur ein Schachbrett und die Figuren haben könnten und dann noch Logiken, die ermitteln, welche Figur welchen Zug machen kann. Testen kann man das Ganze ja auch mit Unittests. Eine grafische Oberfläche muss ja nicht immer eine gute Note bedeuten aber keine Ahnung, ob das nicht schon zu schwer ist. Eine einfachere Form wäre Dame oder noch einfacher: Tic-Tac-Toe.

Sofern Microsoft nicht die Schnittstellen ändert und ältere Clients die neue Schnittstelle nicht implementiert haben...

Okay. Schade. Trotzdem danke.

Genau

Nur irgendwie nervt es. Auch eine Frage wird schnell zu einem Thread, da dort dann weitere Fragen gestellt werden und dann wird es schnell unübersichtlich, was nun die neueste Antwort bzw. Frage ist. Jedes Mal muss man den "Nach Datum sortieren"-Button klicken, um den chronologischen Verlauf zu verstehen.

Kann man irgendwo angeben, dass das Forum die Posts nach standardmäßig Datum sortieren soll und nicht nach Bewertung? Das macht mich immer ganz wahnsinnig.

Bei Onlinespielen der Spieleserver.

Du brauchst du dafür gar nichts. Du musst wissen, wie man zwischen zwei Rechnern Nachrichten verschickt (z.B. über TCP und UDP). Wofür brauchst du denn da eine Datenbank? Nicht nur auf Windows ... Wenn ein Router dazwischen hängt, musst du das Portforwarding aktivieren, damit auch die Datenpakete zum lauschenden Rechner weitergeleitet werden. Um das zu umgehen, verwenden Onlinespiele oder Messengerdienste die Hole Punching-Technik. Darüber würde ich mir aber erstmal keine Gedanken machen.

Ein Datenbank-Server sollte nie direkt von Außen ansprechbar sein. Wenn, dann über ein VPN oder über ein geeignetes Administrationstool, was auf dem Server liegt (z.B. phpMyAdmin) und vor fremden Zugriff abgesichert ist. Ob du eine Datenbank für ein Multiplayer-Spiel brauchst, liegt auch am Spiel selbst. z.B. Minecraft kommt auch ohne Datenbank aus. Datenbanken sind nicht immer das Allheilmittel. Ich würde auch kleinere Brötchen backen, bevor ich mich da an ein Multiplayer-Spiel ranwagen würde. Fange erstmal klein an. z.B. Tic-Tac-Toe und arbeite dich an größere Dinge. Selbst die Implementierung von Schach kann schon sehr kompliziert werden.

Keiner wird für dich deine Hausaufgaben machen. Bitte erläutere, wo deine Schwierigkeiten liegen.

IRC ist das einzig wahre

Das habe ich auch gedacht und da sehe ich die größten Probleme. In der Doku wird einfach lapidar behauptet, dass in der Konfigurationsdatei Host, Port, Nutzer, Passwort und Datenbankname eingetragen wird aber wie steht es mit der Sicherheit des Passwortes? Steht das Passwort in Klartext in der Datei? Das selbe gilt dann auch für die User-Tabelle. Wird das Passwort verschlüsselt abgelegt? Wenn ja, wie? Es sieht auch so aus, als könnte man Benutzer gar nicht sperren. Auch sowas wie Anzahl Login-Versuche und das Datum des letzten Erfolgreichen Logins wird nicht gespeichert. Das sind aber essentielle Dinge, um mögliche Angriffe zu identifizieren. Es fehlt auch das technische Know-How in der Doku. Also warum es so umgesetzt wurde, wie es umgesetzt wurde. Die Schwierigkeiten und Herausforderungen werden nicht deutlich. Technische Dinge, wie z.B. die Grafik mit der PGP-Verschlüsselung stammen 1:1 aus Wikipedia und es wird nicht mal näher darauf eingegangen. Man nimmt es also einfach so hin, ohne es zu reflektieren. Es wird nicht mal erwähnt, wie die Zwei-Faktor-Authentifizierung nun abläuft. Bekommt der Benutzer eine Mail?

Davon gehe ich dann auch mal sehr stark davon aus. Ein Prüfer hat davon auch nichts, wenn er einen Azubi absichtlich durchfallen lässt. Ich weiß nicht, wie es bei anderen aussieht aber bei mir haben zwei Prüfer die Dokumentation angeschaut und wenn die Bewertung weit auseinander liegt, wurde ein dritter Prüfer einberufen.