Objektorientiertes Code-Design in einem Spiel

Helium

MaSTaH, ich würde auch erstmal einer Ebene weiter unten ansetzen. Deine Mediator-logik kannst du ja immernoch obendrüberstülpen.

miller_m

ok neues beispiel:

// eigentliches spiel, bindet die engine oder mediator ein
#include "engine.h"

int main(int argc, char *argv[])
{
    CEngine *pEngine = new CEngine();
    // engine starten parameter: fenstername, breite, höhe, farbtiefe, fullscreen
    pEngine->Init("SDL Engine", 800, 600, 24, false);

    // mainloop
    while(!bDone)
    {
        pEngine->GetTimer()->Update();
        pEngine->GetInput()->Update();

        if(pEngine->GetInput()->GetKeyDown(SDLK_ESCAPE)) bDone = true;

        // spiel relevanter code
        // ---------------------
        // bsp: hier kommt es darauf an wie ich auf die tasten reagiere

    }

    // engine aufräumen
    pEngine->Shutdown();
    delete pEngine;

    return 0;
}

// header der hauptklasse (engine)
// verwaltet die ganzen pointer verteilt sie innerhalb und nach aussen
#ifndef __ENGINE_H
#define __ENGINE_H

#include "types.h"
#include "log.h"
#include "timer.h"
#include "input.h"
#include "resource.h"

class CEngine
{
    public:
		CEngine();
		~CEngine();
		// I N I T / R E L E A S E ---------------------------------------------
        // fenster erstellen
		bool Init(
            const char *pCaption,       // fenstertitle
            int nWidth,                 // breite
            int nHeight,                // höhe
            int nBits,                  // farbtiefe
            bool bFullscreen);          // vollbildmodus
		// engine beenden
		void Shutdown();

		// A C C E S S O R   M E T H O D E N------------------------------------
        CTimer           *GetTimer()            { return m_pTimer; }
        CInput           *GetInput()            { return m_pInput; }
        SDL_Surface      *GetSurface()          { return m_pSurface; }

    private:
        CLog                *m_pLog;
        CTimer              *m_pTimer;
        CInput              *m_pInput;

        int                 m_nScrWidth;        // screenbreite
        int                 m_nScrHeight;       // screenhöhe
        int                 m_nScrBPP;          // farbtiefe

        SDL_Surface         *m_pSurface;        // sdl backbuffer surface
};
#endif
// inputklasse
// siehe oben

vielleicht wird es jetzt klarer, was ich meinte

Walli

Helium schrieb:

MaSTaH, ich würde auch erstmal einer Ebene weiter unten ansetzen. Deine Mediator-logik kannst du ja immernoch obendrüberstülpen.

Ich glaube ich werde wirklich zunächst einige wiederverwendbare Klassen schreiben (Input etc.).

Danke euch allen!

TGGC

Man sollte überhaupt keine alten Klassen ändern (mach nie alte Files auf, du machst sie nur kaputt). Ich würde also, wie schon oben gesagt, aufteilen in "kann immer benutzt werden" und "wird nie wieder benutzt".

Bye, TGGC (Der Held ist zurück)

volkard

TGGC schrieb:

Man sollte überhaupt keine alten Klassen ändern (mach nie alte Files auf, du machst sie nur kaputt).

wie bist denn du drauf? wenn du nur für den mülleimer schreibst, dann haste von c++ aber noch nix kapiert.

rapso

volkard schrieb:

TGGC schrieb:

Man sollte überhaupt keine alten Klassen ändern (mach nie alte Files auf, du machst sie nur kaputt).

wie bist denn du drauf? wenn du nur für den mülleimer schreibst, dann haste von c++ aber noch nix kapiert.

c++ heißt nicht dass man in alten files rumfrickeln soll, sondern dass man eine solide klasse einmal codet und sie reused.

rapso->greets();

TGGC

volkard schrieb:

TGGC schrieb:

Man sollte überhaupt keine alten Klassen ändern (mach nie alte Files auf, du machst sie nur kaputt).

wie bist denn du drauf? wenn du nur für den mülleimer schreibst, dann haste von c++ aber noch nix kapiert.

Wieso schreibe ich damit nur für den Mülleimer? Ist nicht viel mehr der Code, den man umschreiben musst, für den Mülleimer? Was soll zum Beispiel diese Sound Klasse, die ich jedesmal umschreibe, wenn sich die Tasten oder Namen der Soundfiles ändern? Also schreibe ich eine Soundklasse, die für alle Files und Tasten funktioniert. Die brauch ich dann auch nur einmal testen, wenn ich sie aber immer wieder ändere muss ich sie immer wieder testen. Wenn das die C++ Philosophie ist, dann hab ich echt was verpasst.

Bye, TGGC (Der Held ist zurück)

volkard

TGGC schrieb:

Wieso schreibe ich damit nur für den Mülleimer?

du schreibst "mach nie alte Files auf, du machst sie nur kaputt", das klingt danach, als würdest du nur code bauen, den man auch auf keinen fall reparieren kann. also write-only code. da mit sicherheit irgendwann einmal ein fehlerchen auftaucht, und man nie eine datei ändern darf, ist sie für den müll.
soweit zur für mich an sich einfachen logik, die dich aber bereits überfordert.

TGGC schrieb:

Ist nicht viel mehr der Code, den man umschreiben musst, für den Mülleimer? Was soll zum Beispiel diese Sound Klasse, die ich jedesmal umschreibe, wenn sich die Tasten oder Namen der Soundfiles ändern?

die wäre ja eh unfug.

Also schreibe ich eine Soundklasse, die für alle Files und Tasten funktioniert.

korrekterweise kennt eine soundklasse keine tasten, oder?

Die brauch ich dann auch nur einmal testen, wenn ich sie aber immer wieder ändere muss ich sie immer wieder testen. Wenn das die C++ Philosophie ist, dann hab ich echt was verpasst.

einmal? naja, kannst es durchaus schaffen, daß die klasse in einem projekt gut geht. aber du wolltest doch reusen. da kommt es immer wieder mal vor, daß ein neues feature her muß. oder man lernt einfach was neues dazu und mag es einbauen. änderungen kommen nunmal vor. und nicht bloß wegschmeißungen. wenn du bloß wegschmeißt, dann ist dein stil unsinnig.
ich grabe gelegentlich alte dateien aus, bis 1998, und passe sie gegebenenfalls der neuen lage an und verwende sie wieder. in bälde sollte mein buddy-allokator fertig sein, dann lohnt sich erst meine alte stack-klasse (afair von 1999). ich werde den stack doch glatt wieder anpassen.
tut mir leid, daß du sowas nicht kannst, aber sag doch nicht den anderen auch noch, das müsse so sein.

TGGC

Dann habe ich es falsch ausgedrückt. Man soll nicht Code schreiben, den man nicht reparieren kann, man soll welchen schreiben, der möglichst universell ist und darum nicht geändert werden muss. Jede Änderung einer alten Datei kann darin neue Fehler produzieren, das ist nicht zu bestreiten. Auf Reparieren trifft dies so nicht zu, denn da ist das File ja ohnehin schon kaputt.

Und wenn du jetzt deine alte Stack Klasse umändern musst, besteht da etwa nicht die Gefahr, das dabei Fehler entstehen?

Bye, TGGC (Der Held ist zurück)

volkard

TGGC schrieb:

Dann habe ich es falsch ausgedrückt. Man soll nicht Code schreiben, den man nicht reparieren kann, man soll welchen schreiben, der möglichst universell ist und darum nicht geändert werden muss.

ok. darin sind wir uns einig. beim entwurf schon drauf achten, daß der code in verschiedenen einsätzen verwendet werden kann, ohne ihn jedesmal umzuschreiben.
ich interpretiere "Man sollte überhaupt keine alten Klassen ändern" mal als "man soll überhaupt keine klassen schreiben, die dauernd verändert werden müssen" und das würde ich sofort unterschreiben.
also mißverständnis. sorry.

Und wenn du jetzt deine alte Stack Klasse umändern musst, besteht da etwa nicht die Gefahr, das dabei Fehler entstehen?

jo, besteht. aber die änderung ist klein, ich muß (vermutlich) nur nen allocator dazufummeln, zur zeit kann der stack nur die operator new() verwenden. da ist umschreiben noch sicherer, als neu basteln. normalerweise bin ich aber ein großer freund des wegwerfens und reimplementierens. beim zehtenmal gehts meistens noch besser, als beim neunten mal.