spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Man muss allerdings auch dazu sagen, dass es deutlich mehr Spiele gibt, die lieber vernünftiges Design machen als solches Kauderwelsch. Das PDF zieht buggy-pixels gern mal heran und jedes Mal wirkt es wieder so, als wolle er den Leuten verkaufen, dass ein vernünftiges Spiel nur mit solchem Data-Oriented-Design geschrieben wird. Das ist aber nicht der Fall. Bei Konsolen und mobilen Geräten wird da sicherlich schon etwas mehr drauf geachtet (mache ich selbst auch so), da die Resourcen knapper sind und man eben doch schneller einen Engpass findet. Aber das kann man so nicht generalisieren. Das ist falsch.
Meist ist es eben doch so, dass das Rendering einer Szene wesentlich länger dauert als der ganze Kram rundrum. Und zwar um Größenordnungen. Da bringt ein Data-Oriented-Design eines Codes, welcher nur 5-10% der aktuellen CPU-Zeit verbraucht, auch keinen großen Vorteil. Im Gegenteil wird es gern sogar sehr schnell unübersichtlich, was am Ende mehr schadet als nützt. Man muss eben abwägen, ob man es wirklich braucht oder nicht. Und meistens ist das meiner Meinung eben nicht der Fall, denn wie gesagt... 5-10% auf 3-7% oder sogar 1-4% runterzudrücken macht den Braten nicht fett.

4096 ist übrigens 2^12. Da er mit Bitmasken arbeiten wollte, ist eine Zweierpotenz also durchaus sinnvoll.

Zu dem Problem mit dem Update:
Ja, das stimmt, da muss man dann leider ein hässliches Controlling einführen, damit man keine Rekursion von Notifications bekommt, wenn der Controller mal selbst eine Änderung durchführt. Du kannst natürlich wahlweise einen optionalen Parameter in den jeweiligen Methoden einführen, welcher dafür sorgt, dass die Notification nicht durchgeführt wird. Kann generell mal nützlich sein. Ist aber am Ende leider auch nicht viel schöner. Besser wäre da eventuell dennoch einen zusätzlichen Parameter einzuführen und zwar einen, der angibt welches Objekt die Änderung erbeten hat. Sowas hatten wir damals in unserem Server. Jede tatsächliche Aktion (Änderung des Lebenszustands, der Items, HP/MP eines Objekts, Bewegungszustände etc) erforderten ein auslösendes Objekt als "Actor" sozusagen. Basierend darauf konnten die Änderungen auch zu verschiedenen Resultaten führen.
Beispiel:
- Feindlicher Actor reduziert HP eines Players auf 0 -> kill-score des Feinds steigt.
- Freundlicher Actor reduziert HP eines Payers auf 0 -> Actor wird auf feindlich geändert.
Da schleift man zwar auch sehr viele Parameter in Funktionen mit, kann aber die Reaktionen prima intern gekapselt behandeln, kann weitere Events aufrufen oder eben nicht (was hier dann der wichtige Punkt für deinen Controller wäre!) und so weiter.

Gibt genauso gut auch andere Beispiele von professionellen Spieleentwicklern, die einen schönen objektorientierten Ansatz benutzen. Ich lese zum Beispiel zur Zeit das Buch "Game Coding Complete" von Mike McShaffry. Dort werden einige ganz interessante Konzepte erläutert, welche alle auch so schon in Projekten an denen er mitgewirkt hat eingesetzt wurden. Er geht dort zum Teil auch auf Konsolen ein, und zeigt Stellen auf, die gut organisiert und durchdacht werden müssen. Da gehts dann zum Beispiel um Sachen wie ResourceCaching. Wenn man sich an solchen Stellen gute Prinzipien und Designs erstellt, bringt das den wirklichen Performance schub. Denke da auch wie BlueCobold. Bei einem Teil der eh wenig ins Gewicht fällt bringt mir die Optimierung nicht so viel wie an den Stellen, an denen es wirklich langsam läuft.

Wenn du mich fragst stehen Data oriented Design und OOP nicht wirklich in Konkurrenz zu- sondern ergänzen einander. OOP ist auf höherer und Data oriented Design auf niedrigerer Ebene sinnvoll...

Ja, sie schließen sich nicht vollständig aus. Aber die Kapselung, die bei OOP eigentlich unabhängige Entitäten schafft, die wird durch Data Oriented Design natürlich schon irgendwie gebrochen. Ich sehe kein Problem beides zu kombinieren. Ich sehe es nur als überflüssig an dort zu optimieren, wo eventuell überhaupt kein Bedarf besteht und wo statt dessen die Wartbarkeit (und Pointer auf Speicher-Bereiche, die in anderen Klassen gehalten werden sind de fakto schlechter wartbar) darunter leidet.

Eben das ist der Punkt. DoD ist genausowenig der heilige Gral wie OOP. Beides hat sinnvolle Einsatzbereiche die evtl. ein wenig überlappen aber einfach jegliches OOP aus dem Fenster zu werfen ist sicherlich nicht die Lösung und kein professioneller Spieleentwickler der sein Handwerk versteht wird das machen.

Zitat von »dot«

Wenn du mich fragst stehen Data oriented Design und OOP nicht wirklich in Konkurrenz zu- sondern ergänzen einander. OOP ist auf höherer und Data oriented Design auf niedrigerer Ebene sinnvoll...

Ganz genau. Auch ich verwende ja eine Klasse in meinem Beispiel für den UnitController. Ich habe nie gesagt, dass man kein OOP verwenden sollte, oder
das Klassen generell schlecht sind. Niemand sagt das.

Aber einige wollen es halt mit aller Gewalt falsch verstehen und suchen nach dem kleinsten bisschen. Dazu kommt dann noch ein bisschen Blödsinn erzählen dazu und schon hat man seine festgefahrene Meinung. Ist ja auch nicht schlimm. Jeder soll es doch so machen, wie er es meint. Ich habe nie gesagt, dass mein Weg der einzig richtige ist. Lediglich ein Vorschlag.
Wenn ich mir dann aber durchlese, was manche dann für einen Mist abgeben, dann bin ich froh, dass ich nicht mit denen zusammen arbeiten muß.
Das sind genau die Kandidaten, wo dann nach der Version 1.0 die neue Version in Angriff genommen wird, weil die erste "nicht so doll geworden ist und
wir uns wohl etwas verrannt haben." Kenn ich.

Also jetzt reicht es aber! Ich würde vorschlagen, dass Du mal weniger persönliche Angriffe und Beleidigungen, sowie Unterstellungen verwendest und dafür mal Deine eigenen Kommentare etwas mehr durchdenkst. Beleidigen kann ich Dich aber natürlich auch gern, wenn Du das unbedingt möchtest. Wir sind doch hier nicht im Kindergarten. Kaum sagt ihm mal jemand, dass eine Optimierung an einer ihm völlig unbekannten Stelle im Code eines Anderen nicht unbedingt sinnvoll ist und schon fängt er an solche Verunglimpfungen auszupacken. Das ist doch wohl nicht Dein Ernst!? Denn auch wenn Du keinen Namen genannt hast, ist es offensichtlich, dass Du mich direkt damit ansprichst. Unterlass das in Zukunft bitte.

Jap da muss ich auch zustimmen. Verhaltet euch mal alle erwachsen. Auch wenn hier sicherlich viele sind die noch relativ jung sind, sollte man so viel Anstand und Reife besitzen, hier auf einem Vernünftigen Niveau zu diskutieren. Wenn man das nicht kann, sollte man vielleicht ein anderes Forum aufsuchen. Am besten reagieren sich buggypixels und BlueCobold ein bisschen ab und wir versuchen uns hier mal auf das Problem des Threaderstellers zu konzentrieren. Es ging ja darum, ob eine Fassade in Spielen sinnvoll ist. Alles in allem denke ich kann man zusammenfassen, das Fassaden sicherlich Sinn machen können, du dir jedoch etwas weniger vornehmen solltest. Du scheinst es dir durch dein "übertriebenes" Design zu aufwändig zu machen. Ich denke dein Projekt wird relativ überschaubar sein, und da solltest du nicht zu viel wollen. Taste dich langsam an dein Design ran. Du kannst dir deine Klassen ja mal aufzeichnen und die Abhängigkeiten modellieren. Überleg dir vorab einfach dein grobes Konzept. Kleine Änderungen sollten sich hinterher noch bewerkstelligen lassen. So kannst du vielleicht einfach ein bisschen rumprobieren und mit der Zeit weißt du dann wann sich was für dich lohnt und wann nicht. Ich denke so kommst du für den Anfang erstmal ganz gut weiter.