spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Eine gängige Methode für dein Problem ist es, eine Elternklasse zu erstellen die man nicht instanziieren kann, von der du aber erben kannst.
Hier bei diesem Beispiel mal auf den Player zugeschnitten.

Deine Powerups bekommen einfach ein HealthPowerup Script, welches du im Editor konfigurieren kannst. Du könntest jetzt zur Übung anfangen noch andere Powerups zu erstellen.




Ich habe bewusst einige Fachbegriffe verwendet um zu zeigen, das eine gewissen Grundlage doch hilfreich sein kann um sich auf einer Ebene über ein Problem zu unterhalten
Bei Fragen einfach fragen

P.S.: Ich habe diesen Code nicht getestet.

Ja, so geht es natürlich auch. Aber wie gesagt, von GetComponent() sollte man in Unity die Griffel lassen wo es irgend geht. Das ist sehr langsam. Die Methode das über eine Variable im Inspektor zu referenzieren ist deutlich performanter. Und einfacher

Das ist imho auch ein schönes Beispiel wieso man für Unity nicht erst C# lernen sollte. Unity ist keine C# IDE. Das ist eine Game Engine. Die als Scriptsprache C# verwendet. Und Unity verwendet nur einen klitzekleinen Bruchteil von C#. Vieles lässt sich natürlich Eins zu Eins übernehmen. Aber vieles auch nicht. Weil es eben immer auch den Unity Weg gibt.

Um einfach mal einen anderen Weg in den Raum zu werfen (mal ohne Inspector, mit Inspector wäre natürlich 0.2 Nanosekunden performanter, aber man ist auch stärker auf Unity angewiesen)

Vielleicht habt ihr ja auch Verbesserungsvorschläge...

Kollisionsabfragen habe ich fertig in einer globalen Klasse, weil die Abfrage ja immer die gleiche ist.



Durch die Signatur muss ich dann nur noch an eine Methode denken

Ebenso brauche ich immer wieder den Spieler. Den kann ich im Inspector setzen oder per Code, aber dann in Start, nicht im Trigger Event. Ebenfalls eine globale Methode, die ich mir in Start aufrufe



Das Pickup selbst benötigt den Spieler ja nur für die Kollisionsabfrage. Der HealthController selbst liegt ja bei den UI Elementen, also der Healthbar. Die kann ich also wieder im Inspector setzen oder mir in der Startmethode holen.

Das TriggerEvent sieht bei mir dann so aus



Da kann man auch wieder einiges in Basisklassen auslagern.

Naja und



macht bei der Healthbar eigentlich nur folgendes



Wobei das jetzt mehr Pseudo Code ist, weil ich mir die Spielerwerte natürlich vom "Spielstand" hole, ein Objekt, das zwischen den Szenen nicht zerstört wird und den Speicherstand darstellt, die Daten erzeugt und beim Beenden natürlich alle Daten abwickelt.

Japp, so könnte eine mögliche Lösung über Tags aussehen. Top

Zitat

(mal ohne Inspector, mit Inspector wäre natürlich 0.2 Nanosekunden performanter, aber man ist auch stärker auf Unity angewiesen)

Du bist doch schon in Unity. Du baust ja ein Spiel damit. Dann würde ich auch alle Möglichkeiten ausschöpfen die das Ding zu bieten hat

Über eine Inspectorvariable zu gehen ist einfach eine kostenlose und schnelle Möglichkeit der Mikrooptimierung, also Best Practice. Du sparst da schon einige Milisekunden. Und je komplexer das Rig ist um so mehr Zeit brauch es um durch die Hierarchie zu gehen. Das mag im Einzelfall tatsächlich nicht grossartig was ausmachen. Aber wenn du das mit der Inspectorvariable nicht weisst, dann ballerst du beim Entwickeln erst mal alles mit GetComponent voll. Das summiert sich dann auf. Und im schlimmsten Fall kommt es dann zu Stotterern wenn alle GetComponent Dinger mal gleichzeitig am Rödeln sind. Und das dann nachträglich zu optimieren ist dann doch recht mühsam.

Und in unserem Fall mit dem Health Pack würden wir auch Code einsparen. Das wäre einfach nur oncollisionenter + if other.tag is player, add to health variable vom referenzierten Player, destroy game object. Das Script ans Healthpack, und gut is.

Oder noch geschickter, du gehst vom Player aus, dann gibts das Collision Script nur einmal at Runtime. Pseudocode: ontriggerenter (other:Collider): + if (other.gameObject.CompareTag ("healthpack")), add to health variable vom referenzierten Player, destroy other.game object. Und in das OnTriggerEnter kannst du jetzt auch alles andere reinpacken was der Player so aufsammeln können soll. Musst halt nur andere Tags nehmen für die Objekte.

Aber ja, über ein einziges GetComponent würde ich mir auch keinen Kopf machen

Zitat von »NullAhnungsJoe«

Für alles andere, öffne ich dann meist aber erst mal eine neue Scene, und probiere etwas herum

Das ist ein sehr guter Ansatz. Problem vereinzeln, lösen, dann wieder einbauen. Ich hatte damals hunderte einzelne Problemlösungsfiles

Man brauch sich keine großen Gedanken um GetComponent<>() zu machen. Die Geschwindigkeitseinbußen sind nicht mal richtig messbar. Laut folgenden Post, sind selbst bei 10+ Millionen Aufrufen keine signifikanten Unterschiede zu erkennen. https://answers.unity.com/questions/1851…my-scripts.html

Außerdem ist die Faustregel, löse Probleme erst wenn sie auftreten, Überoptimierung ist ein Zeitfresser.

Das stimmt natürlich. Viele Wege führen nach Rom, und ein funktionierender langt

Allgemein sollte man Probleme dann lösen wenn sie auftreten. Ich fand es auch eher lästig Dinge im Inspector zuzuweisen. Was einem da jetzt lieber ist bleibt ja jedem selbst überlassen. Aber überlegen wir doch mal von welchem Aufwand wir reden, welcher optimiert werden soll. Ein Objekt hat in Unity eine Liste von Komponenten. Mit GetComponent<> hole ich mir jetzt eben die passende Komponente. Im schlechtesten Fall wird das ganze lineare Laufzeit haben, wobei die Komponenten eben einfach alle unsortiert in einer linearen Datenstruktur liegen und GetComponent<> Komponente für Komponente durchgeht. Selbst wenn dein Objekt jetzt 20 Komponenten hätte dann würde man GetComponent<> in etwa auf 20 Vergleiche runter brechen können. Dazu kommt natürlich noch etwas Overhead, das sollte am Ende aber nicht viel ausmachen.
Wenn du eh gern den Inspektor nutzt und darüber zuweist, dann mach das weiter. Damit aber anzufangen um die Performance zu optimieren ist wohl quatsch. Wenn dein Spiel schlechte Performance hat guckst du mit einem Profiler wo deine Bottlenecks sind. Wenn du die gefunden hast kannst du anfangen zu optimieren. Es gibt da ein schönes Zitat von Donald Knuth: "The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming."

Zitat von »Tiles«

Das ist imho auch ein schönes Beispiel wieso man für Unity nicht erst C# lernen sollte. Unity ist keine C# IDE. Das ist eine Game Engine. Die als Scriptsprache C# verwendet. Und Unity verwendet nur einen klitzekleinen Bruchteil von C#. Vieles lässt sich natürlich Eins zu Eins übernehmen. Aber vieles auch nicht. Weil es eben immer auch den Unity Weg gibt.

Das ist so eine Sache. Ein Bekannter von mir meint auch in vielen Fällen nicht schön Arbeiten zu können, weil er dann eben "gegen" Unity arbeiten müsste. Es gibt am Ende viele Möglichkeiten ein Problem zu lösen. Unity schreibt dir dabei nicht vor einen schmutzigen zu nehmen. Eben weil vielen Leuten bestimmtes Grundlagenwissen fehlt kursieren allerlei Gerüchte im Internet. Ein Beispiel dafür hatten wir ja hier mit GetComponent<>. Das wird verrufen ohne zu wissen warum es jetzt schlecht ist. Noch so eine Sache ist das mit den Structs. Wie oft ließt man im Internet dass Structs in C# für kleinere Dinge da sind da sie die lightweight Klassen sind. Das wird von vielen Leuten so übernommen und am Ende weißt keiner was jetzt der genaue Unterschied eigentlich ist.
Natürlich muss ich kein C# Profi sein um mit Unity irgendwie arbeiten zu können. Es ist aber sinnvoll ein gewisses Grundwissen zu haben um eben vernünftig damit arbeiten zu können.