Mein Unity Buch: Spiele entwickeln mit Unity

[Aragom]

Nur ein kleiner Furz ??

 

Der riecht aber schon gewaltig :-))

[Carsten]

Hallo Leute, vielen Dank erst einmal für das viele Feedback und die wirklich interessante Diskussion in diesem Thread. Ich finde es schon sehr spannend zu sehen wie die Ansichten so stark auseinander gehen. Als ich das Buch geschrieben hab, dachte ich z.B., dass der Programmieranteil viel zu groß sei, schließlich ist es ein Unity-Buch, kein reines C# Buch (wie hier ja auch u.a. Malzbie schon treffenderweise angemerkt hatte).

Aber eines kann ich tatsächlich nicht verstehen: Warum sollte ich Dinge, die ich im Fließtext erläutere (der dann auf ein Listing verweist), nocheinmal im Programmcode selber als Kommentar dazu schreiben? Was die einzelnen Befehle machen erläutere ich (hoffentlich) alle in dem Buch und das dann nochmal im Code zu machen würde nur die Seitenzahl und damit Preis aufblähen ohne den tatsächlichen Inhalt zu erhöhen.

Zudem hab ich gerade in anderen Programmierbüchern nachgeschaut und da werden auch später nicht mehr jede einzelne Zeile erläutert sondern nur noch der Kontext (sicher aus dem gleichen Grund).

Versteht mich nicht falsch, ich nehme wirklich sehr gerne Kritik an, aber diesen Punkt kann ich eben nicht ganz nachvollziehen Ihr könnt mir ja mal sagen welche Programmierteile ich beim nächsten Mal vielleicht noch intensiver beleuchten sollte oder was nicht verständlich ist Oder Ihr sagt mal bei welchem Listing zusätzliche Kommentare wichtig gewesen wären. Bei komplexen Dingen kann man das ja machen, nur nicht immer

[toxicon]

Hallo Carsten,

Ich hoffe das herauslesbar war, dass ich mich auf mein eigenes Verständnis und nicht auf deine Erklärung beziehe.

Natürlich beschreibst du im C# Kapitel Einzelheiten. Das ist für mich auch nachvollziehbar, da alles sehr faktisch abgehandelt wird.

Mit Scripting in Unity Kapitel war ich sehr schnell überfordert. Auch wenn du im Fliesstext schreibst was die folgende Methode / Funktion macht hatte ich Mühe die Infos aus dem C# Kapitel zu transferieren.

Womit ich Schwierigkeiten habe ist, zu verstehen wie man etwas im Script schreibt.

...Keine Ahnung... zbsp.

 

zbsp.

public float GameObject gameObject (pipapo);

( keine Ahnung ob das Korrekt ist :-) )

 

Wieso wird das Gameobject doppelt geschrieben, wieso sind die Klammern dahinter manchmal leer und manchmal stehen irgendwelche Sachen drin?

 

Grundlegend liegen dort meine Verständnisprobleme.

Die Begriffe auswendig zu lernen ist natürlich die eine Sache, aber diese auch an der richtigen Stelle nützlich einzubringen die andere.

Man muss ja die Logik des Scriptes verstehen um es dann auch selbst schreiben zu können.

 

Also quasi, das kommt da hin, das kommt dahin usw.

 

Wie aber schon hundert mal erwähnt. Ich beziehe mich ausschliesslich auf mich und möchte, was ich schreibe, auch nicht verallgemeinern. Es ist interessant sich mit der Materie zu befassen. Ich hatte auch nicht die Hoffnung im Buch eine Sammlung fertige Scripte zu finden. Eher den Anstoss etwas zu lernen, einen Anfang zu finden, auf dem ich aufbauen kann. Aber ich hab es einfach noch nicht begriffen, wie es tatsächlich funktioniert. Vielleicht denke ich auch zu kompliziert.

 

Momentan arbeite ich deine 3 Buchempfehlungen aus dem Blog durch.

Was mir speziell am "GuideToC#" gefällt, ist die Methode im "Klassen und Strukturen" Kapitel wo anhand eines zunehmend aufbauendem Script das meisste erklärt wird.

Das soll aber deine Arbeit am Buch nicht schmälern. Ich suche eben weiter nach dem Anfang und dem ersten AHAA.

[Aragom]

Hi Toxicon..

 

die Sorge hatte ich auch.... ich habe ein super tolles Tutorial gesehen... Wo das so super erklärt wurde, dass

ich es sofort begriffen habe.... such es mal raus... hoffe finde es wieder..

 

Gruß Olli

[Carsten]

@toxicon Vielen Dank für Deine Erläuterung. Keine Angst, ich habe Dich schon richtig verstanden Dein genanntes Beispiel erläutere ich übriges auf Seite 48 im Abschnitt 3.10.2

 

Ich hab so langsam das Gefühl, dass das Problem von Dir (und einigen anderen) nicht das Fehlen von Informationen ist, sondern die beim Programmieren ansteigende Lernkurve. Da dies kein reines Programmier-Übungsbuch ist, erläutere ich zu Beginn einmal alle Grundlagen (wo man sie dann auch jederzeit wieder nachlesen kann), setze in den weiteren Kapiteln aber natürlich dann dieses Wissen in gewissem Rahmen voraus. Ansonsten würde das Buch doppelt so lang werden und diejenigen, die schon etwas programmieren können, langweilen sich. Könnte das sein?

 

Vielleicht erwartest Du aber auch einfach von Dir (oder einem Buch) zuviel. Eine echte Sprache lernst Du ja auch nicht nur durch das Lernen von Wörtern und der notwendigen Grammatik. Das ist ein langer Prozess bis man instinktiv weiß wie man sich mitteilt. Hattest Du Dir eigentlich schon mal mein Schlusswort vom Buch durchgelesen? Vielleicht "hilft" Dir das ja

[fairygirl]

Sprache lernst Du ja auch nicht nur durch das Lernen von Wörtern und der notwendigen Grammatik.

 

das ist ja immer meine Rede. nur eine scriptsprache lernen ist ja nicht automatisch das Programieren lernen.

 

toxicon für Desigenr gibt es daher auch virtual Programmingtools die einem erst mal vor dem Syntax bewahren, den Fokus nur aufs programieren lenken .und beim debuggen genau vor augen führen was da gerade passiert Viellicht versuchst du es auch erst mal mit der "Blümchenprogramiersprache" um ein besseres Verständnis zu bekommen ?