# 2D Spiel - Physics



## Svens (24. Okt 2014)

Hallo zusammen,

ich bin dabei mir ein 2D-Spiel zu programmieren.
Nun möchte ich eine Klasse (Klassenname: "Physik") erstellen, in der Methoden - wie fallen(),springen() - vorkommen, die nicht nur auf den Spieler, sondern auch auf den Gegner anwendbar sein soll.

Nun möchte ich wissen, welche Klasse welche kennen muss und welche ein Objekt davon haben sollte.

Vlt. versteht ihr was ich meine und könnt ihr mir ja weiter helfen.

MfG Svens


----------



## Sogomn (24. Okt 2014)

Kommt immer darauf an, was für ein Spiel du machst. Ich glaube, es wäre generell besser, wenn du z.B. eine Klasse "Lebewesen", welche die Methoden beinhaltet, erstellst und davon den Spieler sowie die Gegner ableitest.


----------



## Svens (24. Okt 2014)

ich habe gerade nochmal überlegt und ich möchte gerne auch noch objekte (z.B.: Würfel) einbauen, die dann auch die klasse brauchen, in der das mit dem das fallen, durch meine erdanziehungskraft steht.

oder kann/sollte ich ein objekt von physik erstellen, welches ich über meine hauptklasse an spieler,gegner,wuerfel weitergebe? oder wäre das nicht so effektiv?

denn immerhin muss der spieler ja die physik kennen, um sie anzuwenden


----------



## Sogomn (24. Okt 2014)

So wie du das beschreibst, würde ich eher ein Inteface "Physik" machen.
_extends_ = "is-a"-Beziehung
_implements_ = "behaves-like"-Beziehung
So als Faustregel.


----------



## Svens (24. Okt 2014)

ja gut. aber muss ich ein interface erstellen oder wäre es auch eine option ein objekt von "Physik" zu erstellen? und wenn ja wäre das sinnvoll?


----------



## Svens (24. Okt 2014)

so... habe mich mal "kurz" etwas in interface eingelesen. ein interface hätte für mich jetzt hier ja keinen sinn. alle objekte sollen ja den gleichen methoden-body haben,...ohne... das ich in jeder klasse jedesmal etwas ändern muss.
und extenden wäre hier auch für mich sinnfrei, da man nur eine klasse erben lassen kann.

wäre es dann sinnvoll hier ein objekt der klasse "Physik", mit den methoden (fallen,springen,usw.) an Spieler,Gegner,Wuerfel zu übergeben?


----------



## Sogomn (25. Okt 2014)

> da man nur eine klasse erben lassen kann


Das ist nicht richtig, du kannst eine Klasse nur von einer anderen ableiten. Eine Superklasse kann jedoch mehrere Subklassen haben.
Ich würde eine Klasse "BasisObjekt" erstellen, die die Methoden springen, laufen und weitere hat. Von dieser würde ich dann sowohl Gegner und Spieler als auch andere Objekte ableiten.


----------



## Svens (25. Okt 2014)

nein. 
ich habe das anders gemeint als ich geschrieben habe. 

man kann zwar mehrere klasse erben lassen, jaja... aber meine klasse "Spieler" kann nur von einer klasse erben.


----------



## Svens (25. Okt 2014)

ich hatte jetzt vor: ein objekt der klasse "physik" zu erstellen und dem übergebe ich dann spieler und welt.
die physik sorgt dann für die schwerkraft und so...

ist ja wie in echt. die physik kennt ja "alles" und kann sie darauf anwenden. der echte mensch muss ja nicht die physik kennen, um fallen zu können.

wäre dies dann auch eine akzeptable und sinnvolle lösung?


----------



## Sogomn (26. Okt 2014)

Funktionieren tut das warscheinlich. Aber das ist viel umständlicher. Warum lässt du die Physik all das machen, wenn der Spieler es auch selbst tun kann? Ich denke, dass Vererbung hier angebrachter ist.


----------



## Svens (26. Okt 2014)

ich will die physik ja nicht nur auf den spieler anwenden, sondern später auch auf gegner und fallende objekte.
soll ich also bestens den spieler von physik extenden lassen?


----------



## kaoZ (27. Okt 2014)

Inerface erstellen welches die Methoden bereitstellt, abstrackte Basisklasse erstellen welche die Grundform alles sich z.B bewegenden Objekte darstellt, und diese klasse Implementiert dann das Interface.....

Beispiel anhand eines bewegbaren Objektes:


```
public interface Moveable{

  void move();
  
}
```


```
abstract class Entity implements Moveable{
 
  @Override
  public void move(){
     // do some moving stuff right here.... or do noting ( hook )
  }
}
```

du kannst dann auch einfach sagen du implementierst in der Basisklasse garkeine funktionalität (hook) und oder du implementierst die Methode dort erst garnicht , so sorgst du dafür das jede Konkrete Klasse dann ihre eigene Implementierung liefern muss.

Beispiel :


```
class Player extends Entity{

 @Override
  public void move(){
   if(left){
       x--;
   }
   else if(right){
      x++;
   }
  }
}
```

da die Basisklasse hier nun schon das interface implementiert, und die Klasse Player diese erweitert, hat der Player eben vollen zugriff auf die Methoden und Felder ( je nach Zugriffsmodifizierer ) der Elternklasse.

du solltest dich einfach mal voher hinsetzen und schauen wo du welche Abhängigkeiten erzeugen musst, bzw. wo du diese eben vermeiden solltest, 

es gibt z.B bewegliche Blöcke die eben nicht Spielbar sind, hier könnte man dann wieder zwischen verschiedenen Spezialisierungen unterscheiden. MoveableEntity's oder auch PlayableCharacters, NPC's usw. usw.



> ich will die physik ja nicht nur auf den spieler anwenden, sondern später auch auf gegner und fallende objekte.



Das was du da vorhast ist keine Spieleprogrammierung sondern eher eine Engine, welche sich letzen endes um all diese Dinge kümmert, wie z.B fallen , laufen , springen usw. usw. und dieses ist um einiges komplizierter als erstmal herzugenen und zu sagen das jeweilige Objekt ist selbst für seinen Zustand verantwortlich , im Falle eines Spielers wäre das dann z.B das Springen , der Spieler springt, wie er springt weiß nur der Spieler selbst.


----------



## Svens (27. Okt 2014)

was genau bewirkt es denn, wenn die klasse "Entity" abstrakt ist? welchen sinn macht eine abstrakte klasse überhaupt?


----------



## Joose (27. Okt 2014)

Svens hat gesagt.:


> was genau bewirkt es denn, wenn die klasse "Entity" abstrakt ist? welchen sinn macht eine abstrakte klasse überhaupt?



Bitte einfach mal den Begriff und die Thematik zu "abstrakte Klassen" googlen, da finden sich sehr sehr viele Erklärungen inkl. Beispielen


----------



## kaoZ (27. Okt 2014)

> was genau bewirkt es denn, wenn die klasse "Entity" abstrakt ist?



Zum einen sorgt es dafür das du keine direkten Instanzen dieser Klasse erstellen kannst. ( Anonyme außen vorgenommen )
Zum anderen legst du hier schon fest das es eben eine Abstrakte Definition von irgendetwas gibt.



> welchen sinn macht eine abstrakte klasse überhaupt?



Um es nur mal ganz grob anzureißen, 

Du hast hier die Möglichkeit Gemeinsamheiten zu definieren, und ggf. existierende Grundfunktionen zur Verfügung zu stellen.

Deshalb habe ich auch *Entity* als Klassennamen gewählt , sinnbildlich übersetzt steht dieser Begriff im Deutschen nämlich für *Ding*

Also eine Abstrakte Umschreibung für irgendetwas von dem hier zu dem Zeitpunkt noch keine Definition vorliegt.
Somit könnte eine Entität alles sein , wozu du sie machst, ein Auto , ein Mensch, ein Spieler usw.

Dies hängt dann später von dem Aufbau deiner Vererbungshierarchie und der Implementierung eventueller Interfaces ab.

Somit kannst du eventuelle Funktionalitäten, und oder Attribute ( Member / Instanzvariablen ) bereits definieren auf die dann alle Unterklassen, also Spezialisierungen Zugang erhalten.Man Spricht hier auch von Generalisierung, also wenn du versuchst eine Konkrete Gegebenheit, weiter zu Abstrahieren, du solltest dir dazu wie Joose schon erwähnt hat mal den ein oder anderen Artikel durchlesen.


----------



## Svens (28. Okt 2014)

nochmal zu bestätigung frage ich mal ob das so richtig ist:

das interface gibt vor, welche methoden es gibt, die man im player implementier.
die abstrakte klasse "entity" legt weitere methoden fest, die man übernehmen/erben kann.
und der player kann dann die methoden abändern.


----------



## Joose (28. Okt 2014)

Svens hat gesagt.:


> das interface gibt vor, welche methoden es gibt, die man im player implementier.



Genau das Interface gibt dir Methoden, welche implementiert werden MÜSSEN.



Svens hat gesagt.:


> die abstrakte klasse "entity" legt weitere methoden fest, die man übernehmen/erben kann.



Abstrakte Klassen können abstrakte Methoden beinhalten, diese abstrakten Methoden sind nicht implementiert.
Diese abstrakte Methoden müssen in der Subklasse mit einer konkreten Implementierung überschrieben werden.
(alle anderen Methoden können, müssen aber nicht überschrieben werden, normales Override)

Fazit: Ein Interface und eine abstrakte Klasse ZWINGEN dich dazu vorgegeben Methoden zu implementieren.
Der Unterschied zwischen den beiden ist das eine abstrakte Klasse wie eine normale Klasse Attribute und Methode enthalten kann, welche eine Basisfunktionalität bereitstellen.


----------

