arlegermi

Genau so wie @Whiz-zarD schreibt. Genau wie du in deiner Form-Klasse Sachen in Variablen abspeicherst (z.B. _player), machst du das auch in "Fight". Wenn du den Spieler und das Monster also im Konstruktor übergibst, speicherst du sie in (private) Variablen und kannst dann in der Methode "FightRound" auf diese zugreifen.

Genau. Das war das, was ich heute morgen geschrieben habe. Du würdest einfach in deinem Formular ein Objekt der Klasse "Fight" (o.ä.) erzeugen, das die Player-Instanz und das Monster mitbekommt und als Methode sowas wie "FightRound()" hat, die dann je 1x den Spieler und das Monster angreifen lässt (sofern noch am Leben).

Könntest du da mal Beispiele nennen? In meinem WiInf-Studium kam außer Grundlagen betrieblicher Kommunikation (Netzwerke) kaum etwas dran, was ich so im Alltag mit Admin-Tätigkeiten in Verbindung bringen würde. Klar, so Dinge wie Projektmanagement sind Sachen, die man immer brauchen kann und Grundlagen VWL/BWL sind auch nicht verkehrt; würde ich jetzt aber auch nicht für einen "Standard-Admin" als wirklich entscheidend betrachten.

Wenn du wirklich "nur" System-Administrator werden möchtest, bin ich mir nicht sicher, ob dir ein Studium in der Hinsicht wirklich helfen würde. Ich könnte mir gut vorstellen, dass dir in dem Fall die drei Jahre Berufserfahrung mehr bringen als ein Bachelor in WiInf. Zum Thema Wirtschaft & WiInf: Ja, rund die Hälfte (wenn ich mich richtig erinnere) der Veranstaltungen haben einen Wirtschaftsbezug. Das macht den Studiengang ja so wertvoll für den Arbeitsmarkt. Du kannst immer noch voll in die Software-Entwicklung rein damit, aber auch ohne weiteres Richtung Management.

Wenn du bereits Angebote bekommen hast, scheint dein aktueller Kenntnisstand ja kein grundlegendes Problem zu sein. Ich wüsste nicht, wieso du deshalb lieber noch ein Jahr warten solltest. Was ich eher glaube, ist, dass du mit deinen Ansprüchen jetzt zu spät dran bist. Du kannst natürlich immer noch Glück haben und ein passendes Unternehmen finden, aber die attraktiven Ausbildungsplätze sind häufig schon zu Beginn des Jahres vergeben.

Das sehe ich auch so. Wenn man nicht entwickeln möchte, sondern eine grundlegende IT-Bildung erlangen möchte, ist WiInf dafür gut geeignet. Nicht, dass man mit einem WiInf-Studium nicht auch Entwickler werden könnte - es ist nur einfach nicht so technisch wie bspw. Angewandte Informatik o.ä.

Naja, wenn @tigerdimix tatsächlich in einer Firma arbeitet, in der das automatische Deployen und Skalieren notwendig ist, dann ist das schon ein wenig mehr als nur installieren. Automatisch auf Lastspitzen reagieren, die Docker-Container automatisch im Netz registrieren und das entsprechende Routing kann schon komplex sein. Ich glaube nur, dass Docker in vielen Fällen wegen des Hypes zum Einsatz kommt und nicht weil's nötig ist. Und das klingt hier auch so.

Dafür hatten wir in der BWL-Veranstaltung eine Bestehensquote von 93%. Uni-Mathe-Veranstaltungen sollte man nicht als Maßstab heranziehen, das ist auch da das größte Sieb So gut wie jeder kommt durch die Ausbildung, wenn auch nur etwas Einsatz da ist. Man kann sich jetzt drüber unterhalten, ob das Niveau der Ausbildung zu niedrig ist (ich denke, dass es so ist), aber Fakt ist, dass die FI-Ausbildung (zum Bestehen) kaum intellektuelle Anforderungen stellt, die über Schulniveau hinaus gehen. Dazu kommt dann, wie @D-eath richtig sagt, dass teilweise monatelang für zwei Klausuren gelernt wird, die sich zum Großteil mit reinem Wissen bestehen lassen. Dazu dann der Multiple-Choice-WiSo-Teil, der einem die Punkte ja auch schenkt, wenn man sich ein bißchen vorbereitet.

Ich bin selber Entwickler, aber auch unsere Systemer machen keinen Wochenenddienst. In den vier Jahren, die ich jetzt hier bin, bin ich exakt 1x für 2h an einem Sonnabend in's Büro, um noch schnell etwas fertigzumachen für eine Messe am kommenden Montag. Das lag in dem Fall allerdings am Freigabe-Prozess von Apple (wir sind da noch neu, was iOS-Entwicklung angeht), bei dem wir uns verschätzt hatten. Ansonsten ist hier im Büro an einem Freitag um 18 Uhr niemand mehr da. Überstunden gibt's hier zwar auch, aber in Maßen und mit entsprechendem Ausgleich.

Ich sehe das wie @Chief Wiggum. Docker löst ja bestimmte Probleme (Konfigurationsmanagement, Isolation, ressourcenschonende Virtualisierung, ...). Treten diese denn bei euch auf? Oft ist Docker doch dann relevant, wenn man mehrere Services (bzw. Service-Instanzen) hat, die man unabhängig voneinander deployen können möchte und ggf. zügig skalieren. Docker nur der Neuheit wegen zu machen, ist für ein Abschlussprojekt nicht drin.

Ne, das ist völlig in Ordnung, dazu gibt es ja öffentliche ("public") Methoden, damit sie von außen aufgerufen werden. Ein Punkt von OOP ist ja gerade, dass Klasse nach außen hin bestimmte Methoden bereitstellen, die dann den internen Zustand des jeweiligen Objekts manipulieren (wenn du da nachlesen möchtest, die Stichwörter sind "Encapsulation" und "Information Hiding"). Das ist richtig. Das ist erstmal Geschmackssache, wie du das modellierst. Für "richtige" Spiele ist das ganze noch deutlich komplexer und es kann durchaus Sinn machen, eine dritte Klasse einzubeziehen, die solche Kämpfe "koordiniert". Für dich ist es völlig ok, eine "Player.Attack(Monster m)"-Methode zu haben. Erstmal ist wichtig, dass es völlig ok ist, Methoden mit wenig Logik zu haben. Es gibt im Bereich von OOP durchaus viele Leute, die der Meinung sind, dass Methoden (und Klassen) kurz sein sollen. Bei Klassen gibt's verschiedene Aussagen dazu, die allermeisten sind sich einig, dass eine durchschnittliche Klasse unter 500 Zeilen Code bleiben sollte, vorzugsweise nicht mehr als 200 (wie gesagt: das sind keine empirisch belegbaren Limits, sondern Erfahrungswerte und Geschmackssache). Zum anderen ist das vllt. in deinem jetzigen Fall so. Aber wenn man mal ein wenig weiterspinnt, kann es bei so einer Methode schon eine ganze Menge Logik geben. Was ist denn mit Ausweichen? Rüstung? Verfehlen? Tageszeit (hat ein Wolf in der Nacht Vorteile? Was ist, wenn der Spieler eine Fackel trägt?)? Ich würde daher auf jeden Fall bei deiner Implementierung mit Player.Attack und Monster.TakeDamage bleiben. Zum Beispiel könnte es ja sein, dass auf dem Monster gerade ein Effekt ist, der das Sterben verhindert. Oder das Monster trägt Rüstung, die den Schaden halbiert. Oder oder oder... Ein kleiner Hinweis noch zu deiner Player.Attack-Methode Wieso übergibst du hier den Player nochmal als Parameter? Du rufst die Methode doch auf dem Player-Objekt auf. Du kannst die Methode daher so schreiben: public int Attack(Monster monster) { //... bspw. Ausgabe "Player attacks monster" var attack = // Logik zum Ermitteln der Angriffspunkte; vllt. gibt ein Schwert ja einen Bonus? monster.TakeDamage(attack); return monster.CurrentHitpoints; }

@LetaleDosis: Ich kann dich schon verstehen. Wenn man Energie in eine Firma steckt, kann man bei sowas schwer sagen "das geht jetzt halt mal den Bach runter". Ich glaube, jeder stimmt hier zu, dass solche Sachen, wie du sie beschreibst, in Ausnahmefällen mal vorkommen können. Das ist blöd und irgendjemand hat da vorher was verbockt, aber es passiert. Bei dir klingt's aber so, als würde man dich eher regelmäßig im Regen stehen lassen. Wie @Graustein schreibt: Du hast viel zu viel zu koordinieren und bekommst dabei auch noch Stöcke zwischen die Beine geworfen. Es kann z.B. nicht sein, dass ihr für einen Workshop euer Produktivsystem nutzen müsst. (So klang das jedenfalls, weil du offenbar ja nicht den alten Stand deployen kannst, weil das andere Kunden beeinträchtigen würde). Es kann auch nicht sein, dass so ein offensichtlich schwerwiegender Bug, dass er eine Präsentation verhindert, wochen- oder gar monatelang nicht entdeckt wird, so dass dann solche Feuerwehraktionen gefahren werden müssen. Ich an deiner Stelle würde auf jeden Fall mal ein klärendes Gespräch mit der GF suchen, in dem du die Missstände klar darlegst und erklärst, dass das auf Dauer nicht gut geht. Denn du steuerst mit dem, was du hier so erzählst, eindeutig auf persönliche Probleme zu.

Das event "HpChanged" gehört nicht in's Formular, sondern in die Player-Klasse. Das Formular "subscribed" dann auf das Event: // im Formular: _player.HpChanged += UpdateHitpointLabel; public void UpdateHitpointLabel(object sender, PropertyChangedEventArgs e) { labelCurHp.Text = _player.CurHp; } // in Player: public event PropertyChangedEventHandler HpChanged; public void TakeDamage(int damage) { currentHp -= damage; HpChanged(this, new PropertyChangedEventArgs("currentHp")); }

"Brauchen" tust du die Sachen nicht, man kann da immer auch drum herum programmieren. Wie @Whiz-zarD schreibt sind das allerdings wirklich einige der Basis-Bausteine von objektorientierter Programmierung. Zu deinem Problem mit der Verknüpfung von Oberfläche und Player: Da gibt es ein paar unterschiedliche Möglichkeiten Unsauber: Du könntest das Formular im Konstruktor an die Player-Klasse übergeben, so dass diese direkt Änderungen daran vornehmen kann (Texte ändern, Buttons aktivieren, ...). Das ist zwar die schnelle Lösung, wird auf Dauer aber zu sehr unübersichtlichem Code und sehr enger Verknüpfung zwischen Oberfläche und Logik führen, was gemeinhin vermieden werden sollte. Events: Du könntest in der Player-Klasse Events deklarieren (Kurzbeschreibung von Microsoft). Du hättest also irgendwie sowas: public event PlayerHandler PlayerAttributesChanged; // im Formular: _player.PlayerAttributesChanged += UpdatePlayerTexts; public void UpdatePlayerTexts(object sender, PlayerAttributes a) { lblHp.Text = a.Hitpoints; // ... } INotifyPropertyChanged: Das ist ein von .NET definiertes Interface, das das, was ich drüber mit Events beschrieben habe, generalisiert für sämtliche Änderungen an Objekten. Das ist im Augenblick das Standard-Muster, nach dem Änderungen an Daten an die Oberfläche gelangen. Das zugrundeliegende Konzept nennt sich Databinding (das gibt's nicht nur in C#, das ist in sehr vielen Sprachen vorhanden). Nochmal Inversion of Control: Ich hatte in einem der Beispiele weiter oben schon einmal was ähnliches beschrieben: Du könntest deiner Player-Klasse im Konstruktor ein Objekt übergeben, das sich um sämtliche Oberflächen-Interaktion kümmert. Somit muss die Player-Klasse weiterhin nichts von WinForms wissen und du kannst sie auch in einer Konsolen-Anwendung oder im Web nutzen. Das könnte sehr grob so aussehen: public class Output { public Output(Form gameForm) { this.Form = gameForm; } public void Print(string msg) { this.Form.Output.AppendText(msg); } public void DoAction(string action) { switch(action) { case "go north": //... case "attack": //... } } } // in Player: public Player(Output output) { this.Output = output; } public void Attack(Monster m) { m.Hitpoints -= this.Attack; Output.Print("Player attacked monster, monster has " + m.Hitpoints + " left!"); } Das ist auch nicht wirklich sauber (idealerweise löst man das mit Interfaces und abstrakten / virtuellen Methoden), könnte für dich aber ein guter Mittelweg sein. (Die komische Formatierung bitte verzeihen, irgendwie fügt das Forum die Tabs hier komisch ein und ich habe keinen Nerv damit zu kämpfen )

Ich würde auch nicht versuchen, gezielt bestimmte Themen für die Ausbildung zu lernen. Zum einen ist da immer die Gefahr, dass sich unangenehme Sachen einschleichen (gerade bei FIAE), zum anderen weißt du wahrscheinlich noch gar nicht, was in deinem Ausbildungsbetrieb tatsächlich gefragt ist. Ich würde dir einfach raten, dich generell zu informieren, was FIAEs so alles machen und wenn dir davon irgendwas besonders gefällt, da ein wenig nachzulesen, vielleicht auch etwas experimentieren.

Mal völlig unstrukturierte Gedanken zu deinem Code: Du hast zu den Locations jeweils eigene Methoden in deinem Formular. Es wäre einfacher, wenn du eine Basisklasse Location hättest, die die Methoden "Explore" und "Wait" hätte. Z.b. so: public class Location { public virtual Name { get; } = "Generic Location"; public abstract string Explore(); public abstract string Wait(); // weitere sinnvolle Methoden, die alle Locations betreffen } Die Rückgabe "string" ist hier dafür gedacht, dass du den Text dann in dem Formular in die Textbox schreiben kannst. So muss die Location nichts von dem Formular wissen und du könntest sie bspw. in einer Konsolenanwendung wiederverwenden. Noch besser als "string" als Rückgabetyp wäre es, wenn du in die Methode ein Objekt reingibst, das sich um die Ausgabe kümmern kann (alternativ in den Konstruktor der Location): public interface IOutput { void Print(string message); } public RichTextBoxOutput : IOutput { private RichTextBox textBox; public RichTextBoxOutput(RichTextBox box) { textBox = box; } public void Print(string message) { box.AppendText(message); } } // in der Location: public void Wait(IOutput output) { output.Print("Du wartest 1h..."); } Das grundsätzliche Prinzip nennt sich Inversion of Control und ist eine der fünf Säulen von SOLID (um mal Stichwörter zu nennen, falls du etwas lesen möchtest ). Deine Methoden an sich sind ganz ok für einen Anfänger. Was eben tatsächlich sehr aufstößt, ist, dass sich das alles in einer Klasse befindet. Was du mal probieren könntest, ist, Player und Monster von einer gemeinsamen Basisklasse abzuleiten. Denn grundsätzlich teilen die sich ja viele Funktionalitäten. Das könnte irgendwie so aussehen: // "abstract" bedeutet, dass du von dieser Klasse keine Objekte erzeugen kannst // dafür sind die abgeleiteten Klassen (hier: Monster / Player) da public abstract class Entity { public int Id { get; private set; } public string Name { get; private set; } public int MaximumHitPoints { get; private set; } public int CurrentHitPoints { get; private set; } public int Strength { get; private set; } public int Experience { get; private set; } public int Gold { get; private set; } public int Level { get; private set; } public abstract void Attack(Entity target); } public class Monster : Entity { public void Attack(Entity target) { if(target is Monster) { // Monster greifen keine anderen Monster an!! (oder vielleicht doch?!) } else { target.CurrentHitPoints -= Strength; // ... } } // eigenschaften / methoden, die nur auf monster zutreffen; "ki" } public class Player : Entity { // eigenschaften / methoden, die nur auf den Spieler zutreffen; bspw. Steuerung } Kleiner Hinweis, was Namen von Variablen, Klassen usw. angeht: In C# ist es Usus, für Klassen, Methoden und Properties im sog. PascalCase zu schreiben. Deine Klasse heißt "Places", obwohl es sich doch um einen einzelnen Platz handelt, oder?

Du benutzt doch cin schon; Einfach davor noch einmal und dann (Pseudo-Code, ich kann kein C/C++) if input == "j" then // Rechnung else // Exit

Wenn du sowas schreibst: theButton.Clicked += dann sollte Visual Studio dir per Tabulator den Rest ergänzen: theButton.Clicked += theButton_Clicked; // weiter unten (so ähnlich): private void theButton_Clicked(object sender, EventArgs e) { } Wenn du jetzt den Namen hinter ".Clicked +=" änderst, dann musst du auch den Namen der Methode ändern, die erzeugt wurde. Alternativ kannst du das auch über den Designer machen, wie @KeeperOfCoffee das geschrieben hat.

War mir klar, dass das wieder kommt. Deswegen habe ich den Satz ja noch ergänzt.

Gleiche Antwort wie immer: Kommt drauf an. Im richtigen Betrieb und mit genug Einsatz kannst du auch ohne Studium weit kommen. In Umgebungen, die formale Kritierien an ihre Stellen knüpfen, hast du u.U. ohne Studium eben die A*-Karte. Gerade bei Behörden setzen bestimmte EG-Einstufungen ein Studium voraus (seltene Ausnahmen mal ausgenommen). Gerade in kleineren, weniger strikten Unternehmen wirst du auch mit einer Ausbildung Karriere machen können. Worauf du dich eigentlich immer verlassen kannst, ist, dass du als Ausgebildeter weniger verdienst als der Studierte auf der gleichen Stelle (auch hier: Ausnahmen bestätigen die Regel).

Wieso braucht das Player-Objekt Elemente des Formulars? Das Player-Objekt sollte von den Buttons überhaupt nichts wissen. Das sollte so laufen, dass der ("echte") Spieler einen Button auf dem Formular anklickt und das Programm dann dem Spieler-Objekt sagt, was es tun soll. Wenn du bspw. einen Button "Wolf angreifen" hast, dann muss die Player-Instanz davon nichts wissen. Eine Möglichkeit wäre es, einfach eine Methode in Player aufzurufen à la public void Attack(Monster m) { m.curHp -= this.attack; if(m.curHp <= 0) { m.Die(); } } (das ist jetzt extrem verkürzt, aber das Prinzip sollte klar sein) Dein Spiel ist doch quasi rundenbasiert. Zu Beginn jeder Runde entscheidet das Programm, welche Aktionen dem Spieler gerade erlaubt sind und zeigt diese an / aktiviert sie. Zusätzlich zeigst du noch die aktuellen Lebens- / Erfahrungspunkte, Gold, usw. an. Für all das muss das Player-Objekt nichts vom einem Formular oder einem Panel wissen (genaugenommen solltest du in der Player-Klasse keinen Verweis auf System.Windows.Forms haben, aber das kann man später mal angehen).

Ich arbeite im Ruhrgebiet und bin nach meiner Ausbildung (als FIAE) mit ~36k eingestiegen, was - wenn ich meinen Mit-Azubis aus anderen Betrieben glaube - leicht überdurchschnittlich war. 40k als frisch Ausgebildeter ist wahrscheinlich auch hier nicht unmöglich, aber eher die Ausnahme für Spezialfälle (Branche, Technologie, Unternehmen müssen da einfach passen).

Bin FIAE und würde mich auf jeden Fall wieder so entscheiden. Bin aber auch tatsächlich aus Leidenschaft dabei - mich fasziniert das Automatisieren von Prozessen, das Optimieren von Arbeitsabläufen und die Möglichkeiten, die sich einem durch die IT bieten. Ich finde es unglaublich befriedigend, mitzuerleben, wie ein Programm / eine Funktion von mir bei einem Kunden dazu führt, dass er seine Arbeit besser / lieber macht. Das bedeutet für mich auch, dass ich zumindest ein Mindestmaß an Kundenkontakt brauche. Wäre ich immer drei, vier Ebenen vom Kunden (der echten Welt) entfernt und bekäme Feedback nur über anonyme Tickets / Requirements, dann wäre das nichts für mich. Wir sind zwar eine Consulting-Firma, für die Entwickler ist der Reiseaufwand dennoch ziemlich gering (meist nur wenige Tage pro Jahr - das meiste machen unsere PMs und Service-Kollegen), was mir persönlich sehr gut gefällt. Ein paar Mal im Jahr direkt zum Kunden zu fahren und da die Einführung einer neuen Software begleiten, bzw. Konzepte zu erarbeiten, macht mir Spaß. Das ständige Reisen meiner Kollegen hingegen würde mich schnell nerven. Was mich tatsächlich stört hier, ist die Tatsache, dass die Uhr in Sachen Software-Entwicklung irgendwie in den 90ern / frühen 2000ern stehengeblieben ist. Bis letztes Jahr haben wir noch CVS benutzt, es gibt teils noch Neuentwicklungen in VB6, von modernen Design-Patterns keine Spur (Sachen wie DI sind völlig unbekannt, Unit Testing "brauchen wir nicht", CI / CD gibt's auch nicht...). Allgemein ist unsere Code-Qualität stellenweise sehr fragwürdig, was einem ab und an den Spaß verdirbt, wenn man sich durch 5000-Zeilen-lange Klassen quälen muss.

Na in gewissem Rahmen schon. Wenn du dich bei Firmen bewirbst, wirst du dir ja auch ein wenig angucken, was die tun. Wenn das eine reine Beratungs-Bude ist, dann ist auf jeden Fall mit Reisezeit und Kundenkontakt zu rechnen. Wenn das dagegen eine Firma mit hunderten von internen Entwicklern ist, dann ist die Chance größer, dass es sich um einen reinen Bürojob handelt.

Das ist das wichtigste Sorry, falls ich zuviel anderen Kram geschrieben habe. Nochmal zu dem Problem mit den Buttons: Da kann man natürlich ein wenig Schreibarbeit sparen. Wenn du deine Buttons regelmäßig anordnest (bspw. in einer Gitter-Struktur), dann lässt sich das durch Schleifen wunderbar kürzen: // nur so weggeschrieben, Details fehlen string[] buttonTexte; Action[] buttonActions; for(int i = 0; i < buttons.Length; i++) { var button = new Button(); button.Text = buttonTexte[i]; button.Clicked += buttonActions[i]; button.Location = new Location(GetX(i), GetY(i)); panel.Children.Add(button); } Dann musst du das Styling und die Positionierung nur 1x schreiben und dich nicht für jeden Button wiederholen.