Die Scripting Reference lesen

[Sascha]

Okay, du hast die Scripting-Tutorials (oder andere) gelesen und weißt jetzt, wie man [einen Würfel dreht/eine Farbe ändert/irgendetwas anderes macht].

Aber wie kannst du jetzt [eine zufällige Farbe erstellen/machen, dass die Wand durchlässig wird/noch irgendetwas anderes machen]?

 

Einfach mal im Forum fragen.

Was kriegt man dann als Antwort zurück? "Das sollte mit [link] und [noch ein link] zu machen sein".

Die Links führen in die Unity Scripting Reference, wo man sich alles weitere anlesen und dann mit den erworbenen Grundkenntnissen und den Informationen über dies und das eine eigene Lösung programmieren kann.

Denn jemand anderem eine fertige Lösung zu schreiben ist etwas, das Leute nur machen, wenn sie gerade zufällig richtig gut drauf sind oder Geld dafür kriegen.

 

Nun ist aber das Problem: Da steht alles so kryptisch! Ohne Beispiele kann ich damit nichts anfangen!

Das ist schade, denn Besipiele sind für Anfänger noch begrenzt nützlich, aber dass sie doch eher der Sonderfall sind, liegt daran, dass bereits alles nötige da steht - ohne Beispiel.

 

Man muss es nur lesen können.

 

Die Scripting Reference lesen

 

Teil 1 - Die Oberfläche

 

Zuerst einmal - hier ist sie, die Reference: http://docs.unity3d....criptReference/

Beim ersten Besuch sollte man sich oben rechts die Lieblingssprache aussuchen, damit eventuelle Beispiele immer in dieser Sprache angezeigt werden. Achtung: Einige Beispiele sind nur in einer Sprache verfügbar, also nicht wundern, wenn der Code bei euch nicht geht. Schaut am besten generell, was das Beispiel macht, anstatt den Code zu kopieren, da habt ihr sowieso mehr von.

 

Wie man durch die Dokumentation navigiert, ist euch überlassen. Ich haue immer meinen Suchbegriff direkt oben rechts in die Suche und spare mir dabei mehrere Male Klicken und Scrollen.

 

Teil 2 - Klassen / Structs

 

Das erste, was man oft in der Reference findet, sind Klassen bzw. Structs. Sie sind die logischen Einheiten, in denen der Unity-Code aufbewahrt wird.

Leider verschweigt die aktuelle Reference gerne mal, ob es sich bei einer Klasse nicht doch um ein Struct handelt. Das muss man sich dann im Zweifelsfall zusammenreimen, das "Wie" führt hier aber zuweit.

 

Ob man gerade eine Klasse oder ein Struct ansieht, erkennt man allerdings daran:

Die Überschrift der Seite ist [Name]. Nichts weiter.

Sucht z.B. mal nach der Klasse Collider. Die Überschrift der Seite ist "Collider".

 

(Im Folgenden lasse ich das "bzw. Struct" bei "Klasse" immer weg, sonst werde ich irre )

 

Es folgt eine kurze Beschreibung der Klasse und dann kommen die so genannten "Member" der Klasse.

Damit sind alle Einzelteile gemeint, die in der Klasse stecken: Die Variablen und die Methoden, die hier "Funktionen" genannt werden.

Dabei gibt es noch weitere Unterteilungen, z.B. ob der Member statisch oder geerbt (inherited) ist.

Dann gibt es noch Messages, die sind ein wenig besonders und nicht Teil einer gewöhnlichen API.

 

Auf diese Member kann man klicken, um mehr zu erfahren.

Schauen wir uns doch einen Member der Collider-Klasse an:

Klickt auf "isTrigger".

 

Teil 3 - Variablen

 

Dass wir jetzt einen Member der Klasse betrachten, erkennt man am Titel. Hier steht jetzt "Collider.isTrigger".

Damit wissen wir, dass wir isTrigger ansehen, welches Member von Collider ist.

Die kleine Zeile darunter ist jetzt das wichtigste an der ganzen Seite: Der Kopf des Members.

In unserem Fall steht da

bool isTrigger;

 

was bedeutet: Es ist eine bool-Variable und sie heißt isTrigger.

Das ist noch relativ langweilig, aber bedeutet schon recht viel.

Dass hinter isTrigger keine Klammern stehen, sagt uns, dass es sich nicht um eine Funktion, sondern eben um eine Variable handelt.

 

Naja... das ist nur die halbe Wahrheit. Es kann nämlich genauso gut eine sog. "Property" sein.

In den meisten Fällen ist das aber bei der Anwendung total egal.

Schaut euch allerdings gerne Collider.attachedRigidbody an - das ist eine Property.

Den Unterschied merkt man hier lediglich darin, dass man den Wert zwar auslesen, aber nicht ändern kann. Das ist aber keine notwendige Eigenschaft einer Property.

 

Jedenfalls kann man mit den Variablen so arbeiten, wie man es von seinen eigenen Variablen kennt:

if(irgendeinCollider.isTrigger) //isTrigger ist ja schließlich ein bool

oder

irgendeinCollider.attachedRigidbody.AddForce(10,0,0); //attachedRigidbody hält die Referenz auf den Rigidbody, der für den Collider zuständig ist

 

Anders funktioniert das bei statischen Variablen. Aber dazu später mehr.

 

Teil 4 - Funktionen

 

Bevor ihr euch fragt: Was ist der Unterschied zwischen Funktionen und Methoden?

Methoden sind Funktionen, die Member einer Klasse sind. In anderen Programmiersprachen als den dreien von Unity kann man Funktionen auch außerhalb von Klassen definieren, daher die Unterscheidung. In Unity sind die Begriffe gleichbedeutend.

Und wehe, mir kommt einer mit "aber in JS geht das doch". Nicht in Unity.

Genau genommen sind nicht alle "Funktionen" "Funktionen", auch wenn das da steht. Gibt die Methode nichts zurück, ist's eigetlich eine "Prozedur".

 

Funktionen/Methoden sind ebenfalls Member von Klassen. Sie sind unter "[...] Functions" eingeordnet, und der aufmerksame Leser ahnt schon: Beim Kopf des Members erkennt man Funktionen an den Klammern. Schaut euch z.B. Camera.ScreenPointToRay an.

Der Kopf der Methode besteht nun aus folgenden Teilen:

Ray - das gibt die Methode zurück. Ein Ray-Objekt. Steht da "void", gibt die Methode nichts zurück.

ScreenPointToRay - vermutlich der Name der Methode.

Dann kommen die Klammern, an denen man Funktionen erkennt und darin stehen die Parameter, die man beim Aufruf der Methode übergeben muss.

In diesem Fall:

Vector3 position - Man soll ein Vector3-Objekt (kein Klugscheissen wegen Struct pls ^^) übergeben. Dass der Parameter "position" heißt ist beim Programmieren egal. Allerdings steht weiter unten oft, was die einzelnen Parameter machen - und nur durch die Namen weiß man dann, was gemeint ist.

Aber wie gesagt, in eurem Code spielt das keine Rolle.

 

Aus all diesen Informationen (und einer weiteren aus der Reference) kann ich jetzt schließen, dass das hier gültiger Code ist:

var ray = irgendeineKamera.ScreenPointToRay(Vector3.zero);

 

Teil 5 - Static

 

Wer jetzt den Link in der Klammer angeklickt hat, findet im Kopf von "Vector3.zero" das wort "static"

Was static überhaupt bedeuet, könnt ihr hier lesen.

Wenn ihr das verstanden habt, bleibt nur zu sagen, dass das static der Hinweis darauf ist, dass man statt

irgendeinVector3.zero

einfach

Vector3.zero

schreibt.

 

Teil 6 - Messages

 

Messages sind kein eigentlicher Teil der Klasse. Sind Messages für eine Koponente gelistet, bedeutet das nur genau eines: Ihr könnt durch das Deklarieren einer Methode mit dem Namen der Message in einem Skript auf Events reagieren.

Dieses Skript muss auf demselben GameObject liegen wie die Komponente, die das Event bekommt.

Ausnahme ist hierbei "MonoBehaviour" (die Superklasse aller eurer Scripts), auf dessen Seite alle Events, für die Unity Messages versendet, aufgelistet sind.

 

Wenn also beim Collider das Event "OnTriggerEnter" steht, dann könnt ihr an ein GameObject mit einem Collider ein Script hängen, das folgendes beinhaltet:

JS:

function OnTriggerEnter(other : Collider)
{
 //was passieren soll, wenn jemand in den Trigger läuft oder wir in einen Trigger laufen
}

C#:

function OnTriggerEnter(Collider other)
{
 //was passieren soll, wenn jemand in den Trigger läuft oder wir in einen Trigger laufen
}

 

Den Parameter kann man übrigens in diesem Fall einfach weg (und die Klammer leer) lassen, wenn man ihn nicht braucht.

 

Teil 7 - Die Beschreibung

 

Ich halte den Kopf der Member für das wichtigste, weil er einem sagt, wie man ihn beim Coden benutzen kann. Die Beschreibung, die darauf folgt, ist aber meist natürlich nicht weniger wichtig.

So z.B. bei OnTriggerEnter: Liest man die Beschreibung nicht, weiß man vermutlich nicht, dass

1. das Event auch bei dem ausgelöst wird, der den Trigger betritt (oder das Gegenteil...)

2. das Event nur ausgelöst wird, wenn ein nicht-kinematischer Rigidbody im Spiel ist.

 

Teil 8 - Abschließend

 

Sinn dieses Tutorials ist nur eines:

Dass ihr, wenn ihr das, was ihr zum Lösen eures Problems braucht, in der Reference gefunden habt, auch wisst, wie ihr es benutzen könnt.

Dass, wenn ihr z.B. Light.intensity vor Augen habt, lesen könnt:

float intensity;

 

Das ist eine Variable vom Typ float. Und in der Beschreibung steht "geht von 0 bis 8".

 

Also kann ich schreiben:

light.intensity += 0.5f;

 

Ich hoffe, es hat geholfen

 

Nachtrag: Zwei Beiträge weiter unten hat Marrrk eine praktische Kurzreferenz gepostet!

[Tiles]

Super Sache! Vielen Dank dass du dir die Mühe gemacht hast!

 

Bin immer noch am durchackern und verstehen. Bin aber super optimistisch dass mir das in Zukunft ein paar Forenwege erspart. Und wenn nicht komme ich euch halt trotzdem löchern

[Mark]

Sascha hat es super erklärt. Daher ist folgendes nur als Quickreferenz zu verstehen:

 

static RückgabeTyp FunktionsName(ParameterTyp parameterName, ParameterTyp parameterName2);

 

static RückgabeTyp variablenName;

 

static - bedeutet dass die Funktion/Variable ein Teil des Typs ist und nicht teil der Instanz, wenn static dann den Typnamen (Vector3.zero) und nicht Instanznamen (meinVector.zero) schreiben. static kann vorhanden sein oder nicht.

 

RückgabeTyp - Der Typ der Funktion/Variable, Funktionen können void als Typ haben, welches bedeutet dass die Funktion nichts zurück liefert.

 

FunktionsName - Der Name der Funktion, Funktionen werden in der Unity API immer mit einem großen Anfangsbuchstaben geschrieben und besitzen eine öffnende und eine schließende Klammer.

 

variablenName - Der Name der Variable, Variablen werden in der Unity API immer mit einem kleinen Anfangsbuchstaben geschrieben.

 

ParameterTyp - der Typ welcher die Funktion als Eingabeparameter erwartet.

 

parameterName- der Name des Eingabeparameters. Der Name ist nur relevant für die Dokumentation, die Variablen die ihr der Funktion gebt müssen also nicht so heißen, nur der Typ muss stimmen.

 

ParameterTyp und parameterName kann 0 bis X mal vorhanden sein.

[reppiz]

ZACK

und schon sind gefühlte 70% der Fragestellungen im Forum beantwortet

[Sascha]

Und wenn nicht komme ich euch halt trotzdem löchern

So ist's richtig!

 

Danke Marrrk für den Beitrag, habe ihn weiter oben erwähnt

 

Freut mich, dass es euch gefällt!

[malzbie]

Fein gemacht!

Ich war so frei und habe das Thema mal angepint. Nicht dass dieses gute Stück nach unten wandert.

[Sascha]

Ich hab's ja in den Scripting-Tutorials verlinkt, die ich ja immer als ganzes Paket verlinke.

Denke, das reicht

[malzbie]

Ah, ok. Des hob i net gwisst.

[Sascha]

Jetsch woast