Die besten Programme enthalten keine Klassen!?

Raptor

Der Spieleprogrammierguru André LaMothe hat in seinem Buch 'Game Programming für Dummies' gesagt, dass die besten Programme keine Klassen enthalten.
Ich muss zugeben, dass ich das ehrlich gesagt ziemlich schwachsinnig finde,
aber mich wuerden mal eure Meinungen interessieren.

MfG

Raptor

Shade Of Mine

Raptor schrieb:

Der Spieleprogrammierguru André LaMothe hat in seinem Buch 'Game Programming für Dummies' gesagt, dass die besten Programme keine Klassen enthalten.

Mhm, kann sein. Kommt darauf an was "die besten Programme" sind.
Das hat aber nix mit Klassen oder nicht zu tun.

Ich muss zugeben, dass ich das ehrlich gesagt ziemlich schwachsinnig finde,
aber mich wuerden mal eure Meinungen interessieren.

Spieleprogrammierer haben da oft eine sehr eigenartige Einstellung

Helium

das hieße ja, das Javaprogramme prinzipeill nie zu den Besten gehören können.

Das beste Programm ist doch sowieso das "Hello world!"-Programm und da gehören keine Klassen rein.

k1ro

Helium schrieb:

das hieße ja, das Javaprogramme prinzipeill nie zu den Besten gehören können.

das is ne binsenweisheit

Im Grunde beeinflusst, wie Shade gesagt hat, die Codeart (OOP, oder C-style) nicht wirklich die Qualität eines Programms. Ich denke, das durch gutes Design aber vieles leichter machbar ist. Aber den entgültigen Code kann man mit oder ohne OOP versauen, soviel steht fest.

mfg

Ich denke aber doch, dass man gerade in der Spieleprogrammierung viel von Klassen profitiert.

@Helium: Damit ist Java wieder im Rennen. Außerdem kann man ja in Java auch nicht-OO coden. Einfach alles static machen.

Shade Of Mine

Optimizer schrieb:

Ich denke aber doch, dass man gerade in der Spieleprogrammierung viel von Klassen profitiert.

nur scheinbar hat es sich dort noch nicht wirklich rumgesprochen.
zumindest war der code der paar bücher die ich angelesen habe verdammt mies. und das hängt dann nach - denn die leute lesen solche bücher (wo teilweise blödsinn über klassen, exceptions, templates, etc. verbreitet wird) und verwenden es dann auch nie...

Kann sein. Ich lese eigentlich keine Bücher über Spieleprogrammierung, sondern allgemein über Programmierung (C++, Java), vielleicht ist das dann ganz gut so.

(das beste Spiel hat zur Zeit 38 Klassen und 3 "Interfaces" )

Artchi

Schwachsinn! Wie alt ist denn das Buch? Ich meine nur, wann wurde es ursprünglich geschrieben? Ich habe hier ein Buch von LaMothe und es ist schon älter (DirectX 5) und er benutzt selber Klassen. Überhaupt sind seine Bücher schon alt.

Lange Zeit hat auch der Quake-Entwickler groß rum getönt, das C++ für Spielecoding ungeeignet ist und er nur C ist geeignet. Warum? Weil er es nicht verstanden hat! Heute codet er aber selber in C++.

Jover

Shade Of Mine schrieb:

Optimizer schrieb:

Ich denke aber doch, dass man gerade in der Spieleprogrammierung viel von Klassen profitiert.

nur scheinbar hat es sich dort noch nicht wirklich rumgesprochen.
zumindest war der code der paar bücher die ich angelesen habe verdammt mies. und das hängt dann nach - denn die leute lesen solche bücher (wo teilweise blödsinn über klassen, exceptions, templates, etc. verbreitet wird) und verwenden es dann auch nie...

Welche hast du denn angelesen? Im allgemeinen Stimmt es wirklich, dass die miesen Code produzieren.

Am besten ist es erstmal reine C++ Bücher zu lesen und die Sprache lernen. Wenn man dann da mal gut drauf ist, kann man solche Bücher lesen und es besser machen.

otze

auch wenn man mich jetzt steinigen wird: oop ist ein bischen langsamer als prozedurale programmierung.
das liegt einfach an den bei anständiger programmierung sehr verschachtelten klassen,aber es ist wirklich nicht sehr viel, weil die compiler inzwischen sehr gut optimieren.

So eine Generalisierung halte ich für falsch. Davon abgesehen, dass ich eh nichts davon halte, prinzipiell an den Rahmenbedingungen schon mal zu optimieren, kann z.B. vom Compiler realisiertes dynamisches Binden _wesentlich_ schneller sein, als eine if-Kaskade. (Ist die Einheit von dem Typ? Oder von dem Typ? Falls ja, mache dies)
Außer vielleicht man codet die Funktionstabellen nach, da wird man aber nicht mehr des Lebens froh.

RHBaum

Ich denke aber doch, dass man gerade in der Spieleprogrammierung viel von Klassen profitiert.

Naja, ich denk mal eher das gerade spiele von den vorteilen einer OOP am wenigsten profitieren, in der Praxis ! Zumindest sinds die, die am wenigsten drauf angewiesen sind !

Schaut euch doch mal die Spiele aufm markt an ... es ist die einzige Branche wo man sehr viel Geld ausgeben muss, um AlphaTester zu werden ! Wenn Software firmen SW mit diesen QUalitaetsstaenden an Kunden verkaufen wuerden, dann wuerde die SW firma ihre Mitarbeiter nimmer bezahlen koennen, weil das komplette Geld fuer die Anwaelte draufgeht !
Der Komplette Entwicklungsprozess unterscheidet sich doch auch von anderen Projekten. Meist hat nen Designer Ideen, dannn wird programmiert, und die ideen werden soweit umgesetzt wie man ahnung und material zu hat. In der Zwischenzeit vergroessert sich das team, andere ideen kommen hinzu, und ploetzlich geht alles in eine komplett andere richtung. Das ist nen unendlich rekursiver prozess, bis das Projektmanagment sagt Stop!, wir brauchen Geld. Dann geht das Spiel Gold, obwohl es nicht mal Alpha Status hat
Denk mal das ist keine gute Grundlage fuer OOP und saueberes Design.
Ne Spielentwicklung mit richtigen Lastenheft und so kann ich mir einfach ned vorstellen, zumindest wenn ich mir die SPiele anschau ...

Ciao ...

Artchi

Aha, du kannst dir also kein Lastenheft (in der Spieleindustrie "Designdoc" genannt) vorstellen? Sorry, aber du irrst dich gewaltig! Ohne Lastenheft brauchste bei einem Publisher erst garnicht ins Büro! Da kann die Grafik noch so spektakulär sein. Und Spiele profitieren sehr wohl von OO, habe selbst an der Dreamcast-Portierung von Ubisofts "Heroes of Might & Magic III" mitgewirkt, und das ganze PC-Spiel war reines OO-Design. Und das Spiel ist schon älteren Datums und ein Top10-Verkaufshit weltweit. Heute dürften wohl die wenigsten Games Nicht-OO sein. Und ja, Ubisoft und 3DO/NewWorldComputing wollten, bevor sie uns loslegen liessen, ein Designdoc für das Portierungsvorhaben haben von uns haben. Alleine für eine Portierung, nicht mal eine Neuentwicklung wohlgemerkt, war ein Lastenheft nötig!

Soviel zu deiner Theorie die total Praxisfern ist.

Bashar

Artchi schrieb:

Lange Zeit hat auch der Quake-Entwickler groß rum getönt, das C++ für Spielecoding ungeeignet ist und er nur C ist geeignet. Warum? Weil er es nicht verstanden hat! Heute codet er aber selber in C++.

Glaub ich nicht. John Carmack ist ein verdammt helles Köpfchen Er ist auf C++ umgestiegen, als er erstmals noch andere Leute an dem Programm rumcoden lassen hat. C++ macht es ein wenig leichter, Schnittstellen zu definieren und deren Einhaltung durchzusetzen. Ich wette, dass der Code an sich immer noch hauptsächlich C-Style ist.

RHBaum

@Artchi

Ok, bisserl ueberspitzt isses schon.

Unterschied den ich sehe ... Aenderungen(nennen wir es Patches) werden nicht in der Form einkalkuliert wie bei anderen Produkten. Von daher ist die funktionalitaet der SW eher stabil als leicht erweiterbar.

Ohne Lastenheft brauchste bei einem Publisher erst garnicht ins Büro

Sorry, kenn ich mich echt ned so aus, aber ich denk mal den publisher intressiert es weniger, wie modular deine SW ist, welche Ansi-C++ standards eingehalten werden ... Sicher wird etwas von der Technik da auch intressant sein, aber in erster linie denk ich ist es das Spielkonzept. Ob das mit nem Lastenheft vergleichbar ist ... weiss ich ned, glaubs aber ned so wirklich.

Ubisoft und 3DO/NewWorldComputing wollten, bevor sie uns loslegen liessen, ein Designdoc für das Portierungsvorhaben haben von uns haben.

Ubisoft? kann das sein, das das von mal zu mal unterschiedlich gehandhabt wird ?

Und nein, gibt ja nicht nur schwarze Schafe. Aber leider werden es immer mehr ... bzw. wird es zur Gewohnheit. Ist aber sicher ned nur Sache des SW Designs. Aber Fakt ist, das grad zuvaerlaessigkeit und Erweiterbarkeit und Fehlerfreiheit am meisten von OOP profitieren. Alles sachen wo sich die SpieleIndustrie meist ned so mit Ruhm bekleckert ...

Heute dürften wohl die wenigsten Games Nicht-OO sein

Glaub ich auch, nen Game mit zig Mille programmcode als proceduralen Code ist sicher ned gut handelbar.
Trotzdem wird C++ meiner meinung nach noch viel zu viel gemieden. Ob in der realen Spieleprogrammierung weiss ich ned, aber in vielen angeblich tollen Buechern ueber 3Design, 3D Spieleprogrammierung, DirectX (ohja, ne MS COM Schnittstelle ! ) wird fuer meinen geschmack viel zu viel in C gecoded, das gaenge mit C++ eleganter und fast genau so schnell ...

Ciao ...

Shade Of Mine

otze schrieb:

auch wenn man mich jetzt steinigen wird: oop ist ein bischen langsamer als prozedurale programmierung.
das liegt einfach an den bei anständiger programmierung sehr verschachtelten klassen,aber es ist wirklich nicht sehr viel, weil die compiler inzwischen sehr gut optimieren.

jo, ich steinige dich.

Hast du eine Begründung warum OOP langsamer sein soll?
C++ Programme können zB schneller als C Programme sein, ohne dass man besonders zaubern muss.

otze

ok, ich versuchs mal an einem ganz kurzen codestückchen deutlich zu machen

int addition(int&,int&);//function zum addieren 2er werte
int komplexe_berechnung(int& a,int& b){
    //ganz komplexe berechnung
    return addition(ergebnis1,ergebnis2);
}
class math{
    public:
        int addition(int&,int&);//methode zum addieren 2er werte
};
class irgendeine{
    private:
        math mathe;
    public:
        int komplexe_berechnung(int& a,int& b){
            //ganz komplexe berechnung
            return mathe.addition(ergebnis1,ergebnis2);//erst erfolgt ein memberzugriff, dann wird von dem member die funktion aufgerufen, ergo langsamer       
        }    
};

Helium

Dafür gibt's ein dickes LOL.

Das was du da machst ist nicht OO, aber darum ging es. Du baust einfach irgendwie künstlich ein wenig Overhead ein. Du kannst auch eine Warteschleife einsetzen oder ähnliches und dann sagen, das die Version mit Warteschleife langsamer ist.

Bashar

otze: Dein Beispiel spricht eher dafür, dass du so einiges in der OOP noch nicht verstanden hast. Zuerst mal zur technischen Seite: Die Klasse mathe hat keine Members, die von addition benutzt werden könnten, also kann addition auch gut static deklariert werden. Dann wird der Aufruf vom Compiler genauso übersetzt wie ein normaler Funktionsaufruf. Was auch nicht weiter verwundert, weil du den Code überhaupt nicht von prozedural nach OO umgeformt hast. Er ist weiterhin prozedural, was nur durch die Klasse mathe ein wenig verschleiert wird.

Ich will jetzt nicht im Detail beschreiben, wie nicht-statische Methode und virtuelle Funktionen sich in C umschreiben lassen (in OOP für Dummies gibts ein Kapitel dazu) Fakt ist, dass OOP in der Theorie genauso schnell ist wie prozedurale Programmierung. Praktische Unterschiede ergeben sich -- von eventuell unterschiedlich gut optimierenden Compilern mal abgesehen -- aus der unterschiedlichen Herangehensweise, die in unterschiedlichen Designs resultiert.

Speziell C++ hat gegenüber C sogar theoretisch die Oberhand. Statischer Polymorphismus (Templates) wird in C entweder überhaupt nicht, mühsam und fehleranfällig durch Makros, oder mit dynamischen Mitteln nachgebildet.