spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Genau so läuft es bei mir

Zitat von »BlueCobold«

Kann ich nur zustimmen. Reflexion ist großartig und ich verwende es sehr sehr gern um neue Typen dynamisch hinzuzufügen oder aus Dateien zu laden. Ich speichere zwar keine Klassen-Namen, sondern nur IDs, lasse diese aber zur Laufzeit per Reflexion zusammen sammeln. Hat den Vorteil, dass man weniger tippen muss und nie irgendwelche Typen irgendwo fest bei irgendeiner Factory anmelden muss. Nachteil ist offensichtlich, dass IDs kryptisch sind und ein Entwickler erst alle Typen manuell raussuchen muss, wenn er mal *alle* beteiligten kennen will.

Wieso nicht einfach Attribute über die Klasse legen? Immerhin sind die teile unter anderem genau für sowas konzipiert

Äh... wie genau meinst du das und wo steht, dass ich keine Attribute verwende?
Etwas konkreter formuliert wäre nicht schlecht.

Ich bin einfach mal davon ausgegangen das du keine vewendest durch dein vorherigen Kommentar den ich zitiert habe. Eventuell wäre es nicht verkehrt wenn du erstmal expliziter sagen könntest was genau du denn nun mit Reflection anstellst.

Über Reflexion suche ich mir die Klassen aus der Assembly, welche die entsprechenden Kriterien erfüllen. Damit entfällt wie gesagt jedes Hardlinking der Klassen zu irgendeinem Manager im Code (was ich eh immer wieder vergesse hinzuzufügen).

Konkret hat jede Klasse eine ID, welche in den "Skript"-Files referenziert sind. Beim Laden eines entsprechenden Typs oder einer Assembly wird dann (einmalig pro Assembly) per Reflexion durchgegangen, welche Klassen dieses Typs vorhanden sind und welche IDs sie tragen. Also eine Art Factory ohne nötige Anmeldung. Die Konstruktoren werden dabei ebenfalls per Reflexion identifiziert, passend zur ID als Lookup gespeichert und beim Laden eines Files/ID dann passend invoked und die Instanz erzeugt, welche das restliche Laden des Files durchführt.

Ah ok verstehe, mich hat es nur verwundert das du etwas von kryptischen IDs gesagt hast.

Ich nehme an im Editor selbst gibt es eine human readable Übersicht der Klassen inklusive Beschreibung, evtl die Auflistung aller Parameter, Beschreibung dazu etc. Genau auf solche Metainformationen war mein Kommentar mit den Attributen angespielt.

mfg

Naja wobei Scriptsprachen ja noch nen zweiten Vorteil haben. Die Spiellogik eines Spiels komplett in C++ zu schreiben ist aufwändig und mühselig. Scriptsprachen vereinfachen einem die Arbeit. Das ist ein Grund den man grad als Hobbyentwickler nicht vernachlässigen sollte. Auch wenn jetzt sicher einige wieder mit den immer selben Parolen ankommen werden wie "Entweder richtig oder garnicht" und und und. Es geht in die gleiche Richtung wie BlueCobold mit seinem "make games not engines" angesprochen hat. Man hat als Hobbyentwickler einfach nicht immer die Zeit zur Verfügung. Zusätzlich macht es auch nicht jedem spaß nach nem Jahr Entwicklung nicht viel neues am Spiel zu sehen. Es gibt Leute die sagen man soll ruhig alles was nicht performancelastig ist in Scripts auslagern. Wie weit man da jetzt geht ist jedem selbst überlassen. Kommt ja auch immer auf das Projekt an. Aber wie gesagt. Sachen die oft geändert werden und Sachen die nicht sehr viel performance ziehen, können normalerweise auch in Scripts ausgelagert werden.

@Marks: Da der Editor WYSIWYG ist, sind Klassen-Namen, Parameter und so weiter nicht für den User interessant. Der muss nur wissen, was er da für ein Element hat und wie es aussieht
Die IDs werden lediglich für's Speichern und Laden in/aus Files verwendet. Die bekommt ein User nie zu Gesicht. Höchstens der Plugin-Coder muss sich damit beschäftigen.

Stimmt schon der Klassenname und reine Parameter sind sicher uninteressant für denjenigen der den Editor verwendet, allerdings gibt es genug Situationen in dem der User ein par Werte ändern möchte wie zB die HP eines Monsters, direkt im Editor bei dem man nicht unbedingt extra ein spezialisiertes Script anlegen möchte. In diesen Fällen ist es schon ganz praktisch direkt im WYSIWYG Editor ein par Parameter anpassen zu können.

Auch bietet es sich an dem Nutzer zu erklären was nun ein Entity genau macht, wofür es dient, etc.

Kleines Beispiel:

Definitiv, jap. So generisch ist mein Editor aber nicht, da es nicht notwendig ist.
Praktisch aber durchaus, keine Frage.

PS:
Woher kommt das "@"? Das kenne ich nur aus Objective-C.