| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| theorie:patterns [2023/03/08 10:37] – [Was bietet uns Unity?] typo spielzimmer | theorie:patterns [2023/03/11 10:40] (aktuell) – Objektorientierung Kapitel angelegt spielzimmer |
|---|
| Wenn du schon programmieren oder skripten kannst, dann stehst du bei mittelgroßen Projekten vermutlich wie ich vor der Frage: Wie strukturiere ich den Code, wenn ich auf der Suche nach Bugs nicht immer wieder über 1000 Zeilen Code lesen will?? | Wenn du schon programmieren oder skripten kannst, dann stehst du bei mittelgroßen Projekten vermutlich wie ich vor der Frage: Wie strukturiere ich den Code, wenn ich auf der Suche nach Bugs nicht immer wieder über 1000 Zeilen Code lesen will?? |
| |
| Ein spielbares Minigame in Unity hat bei mir 250 Zeilen Code, die sich auf 4 Dateien verteilen. Das Player Skript ist mit 115 Zeilen die größte Datei. Darin finde ich mich noch gut zurecht, da brauche ich mir nicht die Mühe machen den Code elegant zu strukturieren. Sobald ein Spiel aber ernst zu nehmend groß wird, gehen die Zeilen in die 10 Tausende. [[https://www.google.com/search?q=wie+viele+zeilen+code+hat+ein+spiel|Google sagt sogar]]: "Für ein modernes kommerzielles Computerspiel schreiben oft bis zu 30 Programmierer schätzungsweise über eine Million Zeilen Quellcode." | Ein [[game_design_doc:fallobst|spielbares Minigame]] in Unity hat bei mir 250 Zeilen Code, die sich auf 4 Dateien verteilen. Das Player Skript ist mit 115 Zeilen die größte Datei. Darin finde ich mich noch gut zurecht, da brauche ich mir nicht die Mühe machen den Code elegant zu strukturieren. Sobald ein Spiel aber ernst zu nehmend groß wird, gehen die Zeilen in die 10 Tausende. [[https://www.google.com/search?q=wie+viele+zeilen+code+hat+ein+spiel|Google sagt sogar]]: "Für ein modernes kommerzielles Computerspiel schreiben oft bis zu 30 Programmierer schätzungsweise über eine Million Zeilen Quellcode." |
| |
| Auch Romane werden in Kapitel eingeteilt, also müssen wir irgendwie sinnvolle Aufteilungen für unseren Code finden. | Auch Romane werden in Kapitel eingeteilt, also müssen wir irgendwie sinnvolle Aufteilungen für unseren Code finden. |
| Hier kommen [[wpde>Schnittstelle_(Objektorientierung)|Interfaces]] ins Spiel. Sie definieren keine Codebausteine, sondern nur Aktionsnamen. Wenn eine Klasse von so einem Interface erbt, dann sage ich damit nur, dass die Klasse eine Aktion bereitstellt. Was sie macht, muss ich im Code der Klasse selber schreiben. Wie hilft uns das also? | Hier kommen [[wpde>Schnittstelle_(Objektorientierung)|Interfaces]] ins Spiel. Sie definieren keine Codebausteine, sondern nur Aktionsnamen. Wenn eine Klasse von so einem Interface erbt, dann sage ich damit nur, dass die Klasse eine Aktion bereitstellt. Was sie macht, muss ich im Code der Klasse selber schreiben. Wie hilft uns das also? |
| |
| Wir können zum Beispiel ein [[https://gamedevbeginner.com/interfaces-in-unity/|Interface namens IClickable schreiben, die die Methode "Interact()" definiert]]. Im Player Skript (oder wo sonst User Input abgehandelt wird) sind wir dadurch unabhängig von allen einzelnen Szenenelementen, auf die man klicken kann. Wir brauchen nur das GameObject mit TryGetComponent fragen, ob es das Interface IClickable bereitstellt, und falls ja seine Interact Methode ausführen. Was im Einzelnen passiert hängt von dem Objekt ab, auf das geklickt wurde. | Wir können zum Beispiel ein [[https://gamedevbeginner.com/interfaces-in-unity/|Interface namens IClickable schreiben, die die Methode "Interact()" definiert]]. Im Player Skript (oder wo sonst User Input abgehandelt wird) sind wir dadurch unabhängig von allen einzelnen Szenenelementen, auf die man klicken kann. Wir brauchen nur das GameObject mit TryGetComponent fragen, ob es das Interface IClickable bereitstellt, und falls ja seine Interact Methode ausführen. Was im Einzelnen passiert steht brav in der Klasse des Objekts, auf das geklickt wurde. |
| | |
| | ===== Objektorientierung ===== |
| | |
| | Ganz allgemein bietet die Verwendung der [[wpde>Objektorientierung|objektorientierten]] Programmiersprache [[wpde>C-Sharp|C#]] die Möglichkeit, meinen Code in Klassen und [[wpde>Methode_(Programmierung)|Methoden]] zu strukturieren. Das heißt ich denke mir Namen für Code Bausteine aus, die ich überall verwenden kann wo ich sie brauche ohne den Code kopieren zu müssen. Wenn ich also in so einem Code Baustein einen Bug fixe, dann brauche ich nicht mehr alle Stellen suchen, wohin ich diesen Bug kopiert habe. |
| | |
| | Außerdem kann ich dadurch den Code lesbarer machen. In FixedUpdate zum Beispiel passiert sehr viel nacheinander. Ich kann für jedes "Kapitel" eine Methode erstellen, sodass in FixedUpdate nur noch die Liste der Kapitelnamen steht und ich schnell einen Überblick bekomme, was in welcher Reihenfolge passiert. In den Methoden sehe ich dann nach, wenn in diesem Teilbereich etwas nicht funktioniert. |
| |
| ===== State Machine ===== | ===== State Machine ===== |
