spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich würde mit der OOP erst einmal ein wenig herumprobieren und mich einarbeiten bevor ich versuche ein Spiel damit zu machen.

Edit: Du kannst nicht erwarten das dir hier im Forum jemand den Anfang eines Spieles schreibt da dies mit (vergleichsweise) enormen Zeitaufwand zu tun wäre

Fang einfach an dein Spiel zu entwickeln (ohne an passende Klassen zu denken) und kapsel zusammengehörige/n Datenelemente und Code sobald sie funktionieren.

Zitat von »De_Struktor«

ich würde gerne erfahren, wie ich in der praxis mit dieser erkenntnis zu arbeiten habe.
also, wie verwende ich dieses neu erworbene wissen.

Welche Erkenntnis? Das Gleichheit und Identität ein Unterschied ist?

Da gbit es nichts anzuwenden, das ergibt sich einfach so. OOP ist eine Kunstform, die man nur durch Anwendung lernen kann. Es gibt zig Bücher in denen steht, was toll und was schlecht ist, aber meiner Meinung nach kann man das erst dann verstehen, wenn man es selber an seinen eigenen Projekten gemerkt hat. Man lernt das auch nicht über Nach, sondern über viele, viele Jahre. Wenn du nach 10 Jahren Erfahrung den Code den du letztes Jahr geschrieben hast, noch toll findest, heißt das nicht, dass du letztes Jahr schon toll warst, sondern dass du dieses Jahr nichts dazu gelernt hast. So ungefähr läuft das.

Das schlimmste ist, dass Bücher und Tutorials einem oft erst eine imperative Denkensweise beibringen. Viel besser wäre es eigentlich direkt Objekt Orientiertes Denken beizubringen, wenn es sich doch schon um eine OO Sprache handelt. C# gehört ja dazu. Hör erst mal auf, erst Programme imperativ zu schreiben und dann umzuformen, sondern fang direkt mit Klassen an. Es ist normal, dass man hinterher ein bisschen aufräumen und neustrukturieren musst.
Überdenke mal Aussagen wie, "Dafür bin ich zu faul". Faul sein im Bezug aufs programmieren kann dir schnell zum Verhängnis werden. Wenn man da Wenn man was lernen will, sollte man bei dem Thema nicht faul sein
Der ganze Kram mit den Identitäten ist erst mal egal. Hör auf die da theoretische Sachen und so Unsinn durchzulesen. Hast du nicht irgendein Buch mit welchem du C# lernst? Wenn nein, dann schnell ab zu Bücherei, oder zum nächsten Buchladen. Das hilft dir wirklich gut weiter. Und ansonsten heißt es für den Anfang einfach mal ein wenig machen. Mach dich mit den verschiedenen Konzepten vertraut. Schreib mal eine Klasse. Schreib mehrere Klassen die miteinander interagieren. Dafür reichen ja erst mal Konsolenprogramme. Die Klassen müssen nichts sinnvolles machen, sondern müssen erst mal nur von der Logik sinnvoll sein. Schreib eine Klasse Fahrzeug, eine Klasse Auto, eine Klasse Fahrrad, und weitere dazu. Guck wie diese voneinander abhängen können, wo du verallgemeinern könntest und so Sachen. Einfach mal die unterschiedlichen Prinzipien ausprobieren. Wenn du die Konzepte verstanden hast (und die sind eigentlich gart nicht so schwer wenn man sie selbst mal einfach benutzt), dann setzt du dich wieder an dein Bomberman Spiel. Dann überlegst du dir einfach grob, was alles eine eigene Klasse wird und fängst an. Wenn du damit fertig bist guckst du wo du zusammenfassen kannst und was du ändern kannst. So näherst du dich dann immer weiter deinem endgültigen Design an und siehst selbst was sich lohnt und was nicht.

Zitat von »Schorsch«

Hör erst mal auf, erst Programme imperativ zu schreiben und dann umzuformen, sondern fang direkt mit Klassen an.

Genau das Gegenteil von dem, was ich empfohlen hab. Ich halte dieses Vorgehen gerade für Anfänger ungeeignet.
In den meisten fällen versuchen sie es, haben eine Klasse "Spieler" und wissen nicht wie sie die Methoden definieren müssen und was sie mit der Klasse überhaupt anfangen sollen.
Ausserdem müssen sie sich dann nicht nur mit einem neuen Gebiet(der 2D Spieleprogrammierung), sondern zusätzlich mit der komplizierteren Syntax der OOP herumschlagen. Das sorgt dafür, dass sie bei eventuellen Fehlern nicht wissen wo sie suchen sollen. Setzen Anfänger etwas erst Imperativ um und schreiben Klassen dafür sobald es funktioniert können sie sich auf ein Gebiet konzentrieren.

Ich gehe nach 5 Jahren selbst noch so vor, wenn ich mit einer neuen Bibliothek arbeite oder etwas ganz neues versuche. Ich hab die Erfahrung gemacht, dass ich bei solchen Dingen immer falsch liege und nachher mit großem Aufwand refaktorisieren oder sogar neu anfangen muss.

Die Vorgehensweise ist ja auch ok. Das Problem was du ansprichst ist eigentlich ein anderes. Man sollte Spieleentwicklung lernen nachdem man programmieren lernt. Wenn man darauf nicht warten soll, soll man halt GameMaker benutzen. Wenn ich neue Bibliotheken nutze, dann arbeite ich natürlich auch erst imperativ. Ich gucke wie alles funktioniert und zusammenspielt. Mache mich mit dem neuen System vertraut. Wenn ich mich eingearbeitet habe und weiß wie alles funktioniert, kann ich mir Gedanken um das Design machen und meine Klassen gestalten. Wenn ich mir aber erst antrainiere, alles Schritt für Schritt zu lösen, bekomme ich schon eine gewisse Denkensart. Da ist es meiner Meinung nach sich direkt an Objektdenken zu gewöhnen. Man muss ja nicht direkt mit Polymorphie und allem hantieren. Nimm mal als Beispiel die Sprache Java. Alles muss in Klassen stecken, weshalb du gar nicht drum herum kommst sie dir anzugucken. Man versteht vielleicht nicht direkt was da alles genau abläuft, aber gewöhnt sich schon mal an gewisse Dinge. Jetzt gucke ich weiter in mein Buch und lerne interessante Dinge zu Variablen, Funktionen, Schleifen und weiß nicht was alles noch. Jetzt kommen auf einmal die Klassen dran und ich habe einen Aha Effekt. Ich weiß jetzt warum ich oben immer Class XYZ hinschreibe und was das ganze bedeutet. Ab jetzt arbeite ich mich immer weiter ein und lerne weitere Objektorientierte Dinge kennen. Diese kann ich ab jetzt direkt benutzen. Ich denke mir Sachen aus um sie benutzen zu können ( Zum Beispiel das Fahrzeug Beispiel in meiner letzten Antwort ). Wenn ich mich jetzt damit weiter vertraut gemacht habe, schreibe ich vielleicht ein richtiges Programm. Natürlich nichts großes. Dabei teste ich das ganze aus. Versuche meine Objekte zu strukturieren und so weiter. Es ist aber ein Unterschied ein Problem zu nehmen, es auszuarbeiten und dann nachträglich Klassen dafür zu schaffen, als mehr oder weniger komplette Spiele zu schreiben und dann hinterher mit Klassen drum herum zu bauen. Im ersten Fall entwickel ich mein Design und im zweiten mache ich es mir erst einfach, weil ich das ganze mit Klassen noch nicht so richtig blicke und versuche es dann hinterher irgendwie einzubauen, weil es ja professioneller und cooler ist Klassen im Code zu haben Wer mit Grafikengines etc anfängt, ohne vorher programmieren zu können, ist selbst schuld.

Du entwickelst doch mit C#. C# ist eine rein Objektorientierte Sprache. Da wird dir schon einiges aufgezwungen. Dein Code steckt ja schon in irgendeiner Klasse. Die Sache ist aber, die Denkweise lernt man nicht durch Theorie sondern durch Praxis. Also mach weiter in deinem Buch und zieh dir den Kram einfach rein. Wenn Beispielaufgaben im Buch sind dann mach die dazu. Wenn keine Vorhanden sind dann denk dir selbst was aus. Kannst ja wenn dir nichts einfällt mit meinem Fahrzeug Beispiel anfangen. Oft werden auch irgendwelche Lebewesen genommen. Die Klassen und Funktionen müssen nichts tolles können. Als Beispiel könntest du ein Auto modellieren, welches einen Motor hat. Jetzt könnte es eine Funktion "StarteMotor" geben. Diese könnte dann einfach ausgeben, dass der Motor gestartet wurde. Wie gesagt konzentriere dich hier erst mal nur auf die Sache mit den Klassen. Dann versuchst du mal alles ein wenig durch. Vererbung Polymorphie und was es nicht alles gibt. Da du ein Buch hast, lies es. Das ist das sinnvollste. Und das mit hinter die Kulissen schauen ist eigentlich Unsinn. Du willst ja nicht verstehen wie es eine Ebene tiefer abläuft. Ansonsten solltest du dir mal was du Sprachtheorie ansehen. Das hilft dir halt nur bei deiner Sache nicht wirklich weiter
Und wie gesagt Programmieren lernt man halt nur durch Programmieren und nicht durch lesen. Also mach Visual Studio auf und fang an.