Game Design

Hallo,

ich suche einen brauchbaren Artikel/Tutorial zum Thema Game Design. Damit meine ich den Aufbau aus den einzelnen Komponenten wie Rendering, Input, GUI, Physik, AI, (Netzwerk, ...) und deren Kommunikation untereinander. Der Entwurf sollte so sein, dass die einzelnen Komponenten möglichst entkoppelt sind, d.h. man sollte die Physics-Engine "mal eben" austauschen können ohne gleich den restlichen Code auf den Kopf stellen zu müssen. Auch eine komplette Game-Engine, die das musterhaft umsetzt, ist willkommen.

Ich habe mich bisher vor allem mit den einzelnen Komponenten getrennt beschäftigt aber jetzt möchte ich mit einem kleinen FPS anfangen. Ich will natürlich vermeiden, dass ich die meiste Zeit damit verbringe mein Design über den Haufen zu werfen und wieder von vorn anzufangen, deshalb lieber gleich ein bewährter Entwurf.

Vielen Dank für Eure Vorschläge

Nexus

Ich habe jetzt kein konkretes Beispiel, aber generell lohnt es sich sicher, die Schnittstellen genau zu spezifizieren. Für die einzelnen Komponenten kannst du abstrakte Basisklassen einrichten, welche rein virtuelle Funktionen zur Kommunikation miteinander enthalten. Eine Realisierung erbt von so einer Klasse und implementiert die entsprechende Funktionalität.

Und mach möglichst wenig global (das betrifft auch Singletons), weil dadurch grosse Abhängigkeiten entstehen können. Schau, dass jede Klasse nur gerade die wirklich nötigen Klassen kennt und halte die Beziehungen lokal. Damit wird Wartung und Fehlerbehebung um einiges einfacher.

Was du designen willst ist eine Engine, kein Spiel.

Soso, du willst nen Shooter machen.
So "mal eben" macht man das nicht.

Es gbt mehrere Möglichkeiten.

A.) Eine professionelle GameEngine verwenden

Empfehlen kann ich hier Unity oder das UDK (Unreal Development Kit).
Beide haben Vor- und Nachteile. Der Vorteil beim UDK ist ganz klar der BSP-Brush, welchen ich bei Unity vermisse. Der lässt einen die Struktur für so einfaches FPS schnell aus dem Boden stampfen. Hier liegt aber der Fokus halt auf Design. Es gibt zu UDK auch tonnenweise Videos. Hab hier knapp 8GB auf der Platte.
Unity erlaubt programmieren mit Mono C#. Auch sehr gut umgesetzt.
Beide Versionen sind kostenlos für den persönlichen Gebrauch, wer sein Werk verkaufen will, muss dann aber löhnen.

Wer eher Fokus auf Programmierung legt, der sollte Ogre3D verwenden. 100% kostenlos, Open Source, portabel und 100% OOP.

B.) Selbst eine GameEngine programmieren und sich mit Rendering und dem ganzen Zeug beschäftigen.

Viel Spaß. :p Ich sprech aus Erfahrung.

Von wegen austauschbar sollte du dir das hier mal ansehen:

#include <iostream>

class Interface_Implementation;

class IInterface
{
public:
	IInterface() {}
	virtual void doSomething() = 0;

	virtual IInterface* clone(){ std::cout << "Base" << std::endl; return NULL; }

};

class Interface_Implementation : public IInterface
{
public:
	virtual void doSomething() override { std::cout << "something" << std::endl;}
	virtual IInterface* clone() override{ std::cout << "Derived" << std::endl; return new Interface_Implementation(); }
};

// Die Factory steuert:
class Factory
{
public:
	Factory() : m_interface(NULL) {}
        ~Factory() { delete m_interface; }
	IInterface* RequestNewInterface() { return m_interface->clone(); }
	void SetInterface(IInterface* p) { m_interface = p; }

private:
	IInterface* m_interface;
};

int main()
{
	Interface_Implementation* i = new Interface_Implementation();
	Factory f;
	f.SetInterface(i);
	IInterface* c = f.RequestNewInterface();
	c->doSomething();
        delete c;
}

TravisG schrieb:

Was du designen willst ist eine Engine, kein Spiel.

Nein, nein. Ich suche nur nach einer Möglichkeit, die verwendeten Libraries auf einen gemeinsamen Nenner zu bringen und soweit zu abstrahieren wie nötig.

Also konkret sind das: Ogre, Bullet (Physik), OIS (Input), CEGUI (UI). Wobei die letzten beiden eigentlich auch austauschbar sind. Was ich bisher als Ansatz gefunden habe ist zB Delta3D. Rendering, GUI, Netzwerk etc. erben von Component und besitzen alle die Fähigkeit GameMessage s zu verarbeiten. Ein GameManager verwaltet die Komponenten und versendet die Nachrichten. Das ließe sich bei den obigen Frameworks leicht implementieren weil die meisten in irgendeiner Form die Möglichkeit bieten Callbacks oder Listener zu registrieren. Das wäre wahrscheinlich mal mein erster Anhaltspunkt...

Unity und das UDK waren mir zwar schon ein Begriff, wirklich beschäftigt habe ich mich damit aber noch nicht. Allerdings möchte ich tatsächlich den "Fokus eher auf die Programmierung legen" aber in Sachen Design kann man sich bestimmt das ein oder andere vom UDK abgucken

Wieso willst du diese Libs auf einen Nenner bringen und abstrahieren? Beim entwickeln eines konkreten Spiels ist das eigentlich nicht von Belangen, da du keinen Bedarf hast die Physik Engine je nach System einfach mal so auszutauschen.

Um die Kommunikation zwischen den einzelnen Elementen brauchst du dir eigentlich keine Gedanken zu machen, wenn du nicht unbedingt absolute Austauschbarkeit erzwingenw illst. Dafür bieten dir deine Libs ihre Schnittstellenmethoden an, und die rufst du an der passenden Stelle einfach auf.

Von daher hört es sich für mich eher danach an als willst du eher eine flexible Engine designen, anstatt ein Spiel zu schreiben.

Die meisten Spieleprogrammierer denken, dass sie Spiele entwickeln wollen. Dabei sind die meisten geborene Engine Designer, so lang wie sie an Abstraktionskonzepten rumarbeiten

nurf

_björn schrieb:

Damit meine ich den Aufbau aus den einzelnen Komponenten wie Rendering, Input, GUI, Physik, AI, (Netzwerk, ...) und deren Kommunikation untereinander. Der Entwurf sollte so sein, dass die einzelnen Komponenten möglichst entkoppelt sind, d.h. man sollte die Physics-Engine "mal eben" austauschen können ohne gleich den restlichen Code auf den Kopf stellen zu müssen. Auch eine komplette Game-Engine, die das musterhaft umsetzt, ist willkommen.

Du kannst gerne bei uns mitmachen. Wir entwickeln eine GameEngine unter genau diesen Vorraussetzungen.
Zusätzlich läuft bei uns jedes dieser Module in einem eigenen Thread.

Ich kenne leider keine Online-Resource, die alle diese Themen abdeckt.
An deiner Stelle würde ich mal mit MVC und MVVM als Thematik anfangen.