# Gameobjects



## Thunderstorm (23. Jan 2014)

Hallo liebe Community,

ich bin neu hier und bin gerade an der technischen Konzeption für mein erstes größeres Spiel, nun habe ich aber folgendes Problem : Gameobjects erstellen und Speichern

Kurz zu den Gameobjects : 

Ich benutze eine abstrakte Oberklasse, von denen dann alle Objekte erben. Diese besitzen alle eine Methode use(), die dann ein gewünschtes Event auslöst. Das ist hart implementiert und ich hab mir schon überlegt dort Skripte einzusetzen, aber naja bin nicht gerade der Scriptmeister :noe:

Nun zum eigentlichen Problem : 

Ich handle das derzeit so, dass ich mithilfe meines eigens geschrieben MapEditors wird anhand einer Zahl festlege welches Objekt wo generiert wird. Das sieht dann folgendermasen aus : 
[JAVA=0]
public Gameobject getObject(int ObjectNumber, int key){
	switch(ObjectNumber){
		case 1:
			return new WaterC();
		case 2:
			return new Campfire1();
		case 3:
			return new Building1();
		default:
			return null;
	}
}

[/code]
Erste kleine Frage, ist das, und ich glaube das werden mir 40 Leute sagen :toll:, potthässlich und wird nicht so gemacht, da das bei tausenden Objekte und großen Karten zum Tod des Rechners führt :lol:
oder gibts da keine Alternative? :bahnhof:


Hauptfrage aber ist, wie würdet ihr die Objekte abspeichern. Da kommen nämlich einige Probleme auf einen zu, die mir gerade den Kopf zumüllen ???:L

Zum Einen müssen die Anfangspositionen irgendwo vermerkt sein, dies wollte ich in der Map selbst tun. Dabei werden dann auch die Zahlen z.B 1_3 vermerkt, etwa 1 steht für das Objekt und die 3 steht für etwas eher besonderes daran, etwa 1 wäre ein Schalter und die 3 steht dafür, dass man damit Tür 3 aufmacht, die dann auch diese 3 haben muss.

Darüberhinaus frage ich mich allgemein, wie ich so ein Gameobject abspeichern soll, da es ja unglaublich viele Eigenschaften besitzen kann. Die dann auch wieder von Objekt zu Objekt unterschiedlich sind. :bahnhof:

Zum Anderen müssen beim Speichern eines Spielstandes alle Objekte in den Spielstand rein, da sich ihr Zustand verändern kann. Da ich aber recht viele Maps haben werde, muss ich von allen Maps alle Objekte speichern. Lässt es sich also nicht vermeiden, dass die Spielstände vom Speicherverbrauch her riesig werden oder ist meine Grundidee einfach nur beschissen :rtfm:

Würde mich über konstruktive Kritik freuen :applaus:
Falls einer den Prototypen testen will, oder irgendwelchen Code sehen möchte, so möge er mir eine PM schreiben 

lg Thunder


----------



## eMmiE (23. Jan 2014)

Ich würde generell sagen, dass du deine Objekte in zerstörbar/unzerstörbar aufteilen solltest (im weiteren Sinne beweglich oder nicht)

Dann solltest du ein interface Funktioniert schreiben, mit welchem du festlegst, das das objekt, das das Interface implementiert eine Funktion hat und eine Methode hat, die aufgerufen wird, sobald das Objekt benutzt wird (anvisiert und geklickt z.B. oder von etwas anderem aktiviert wurde)

Zum Abspeichern:
Generell brauchst du für dein Spiel einen Grafik- und einen Logikteil.
Die würde ich strikt voneinander trennen.
(Falls ich hier was Falsches reinschreibe, zerfleischt mich bitte, sonst bleib ich blöd)

Es kommt generell zuerst die Logik und dann die Grafik.
Ich würde das so machen, dass du in der Logik die logischen Komponenten der Objekte abfragst und verabreitest, dann solltest du innerhalb deiner GameObjects eine Methode schreiben: giveFlächen()
Nach diesen Flächen zeichnest du ja deine Welt und dann kannst du es auch so machen, dass die Objekte quasi selbstständig die Flächen in der richtigen Form und Farbe, Schattierung an die Grafik übergeben.

Die GameObjects lädst du ja vorher in die Welt rein. Du musst dir das meiner Meinung nah so vorstellen, dass du in eine bestehende Welt nichts Neues mehr reinlädst, sondern nur das benutzt, was da ist und im richtigen Moment auftauchen lässt
[füge auf jeden Fall in deinen GameObjects die Variable sichtbar ein]

Für die Grafik kann ich dir leider auch nur einen Ansatz geben, da ich selbst gerade ein bisschen an der Performance meines Programms verzweifle.

Ich nehme an, dass du in 3D programmieren willst:
Jedes Objekt setzt sich wie gesagt aus Flächen zusammen.
Um die darzustellen verwendest du am Besten eine API, sonst dauerts ewig und ruckelt (hab ich selbst nicht drin :noe

Die Flächen musst du natürlich im richtigen Format (was die Mathode der API verlangt) bereitstellen, meist in Eckpunkten.
Das solltest du so kurz wie möglich gestalten.
Dazu brauchst du natürlich auch wieder ein Array

Generell empfehle ich Arrays zu benutzen, anstatt ArrayLists, weil die veränderbar sind und sich immer den neuen Speicherplatz selbst holen müssen, was unglaublich viel Zeit kostet

So, genug des Monologs:rtfm::rtfm::rtfm:

Gruß eMmiE


----------



## Ruzmanz (23. Jan 2014)

Die Objekte willst du mit dem Factory-Pattern anlegen. Wenn du ein bisschen danach googelst, findest du Vor- und Nachteile. Prinzipell spricht erstmal nichts dagegen. Ein Simples Beispiel, wobei ich für eher ein Enum nutzen würde, anstatt feste Integer:

Factory Pattern

Über das "Speichern" musst du dir noch ein paar Gedanken machen. Nach meinen Verständnis kann sich ein Zustand niemals ändern. Beim Speichern brauchst du nur eine Momentaufnahme / Zustand. Zum Beispiel ist bei Tetris folgendes interessant:

- Level
- Spielername
- Nächstes Elementtyp
- Aktuellet Elementyp + Position
- Gesetze Elementetypen + Positionen
- Punktzahl

Was dich aber nicht interessiert ist, wie der Spieler die Punktzahl erreicht hat oder welche Elemente zuvor zerstört wurden. Alles was du benötigst, ist bereits im RAM und muss nicht sperat geloggt werden. Hier bietet sich Serialisierung und Deserialisierung an.


----------



## Thunderstorm (25. Jan 2014)

Großen Dank an eMmiE Ruzmanz 

Werde mir das zu Herzen nehmen und das versuchen erstmal gescheit aufs Blatt zu kriegen. Dann melde ich mich erneut mit den hoffentlich guten Ergebnissen :rtfm:

lg Thunder


----------

