Der erste Satz muss sitzen (Uwe Post)
Ep. 04

Der erste Satz muss sitzen (Uwe Post)

Episode description

Wie wird aus einem Physikstudenten, der Science-Fiction-Kurzgeschichten schreibt, ein Fachbuchautor für Spieleentwicklung? Uwe Post hat in Bochum Physik und Astronomie studiert, ein Volontariat beim c’t-Magazin gemacht und arbeitet heute als Chefentwickler bei der Spiele-Schmiede Ludetis. Parallel schreibt er seit den 90ern satirische Science-Fiction und Fachbücher für Rheinwerk – unter anderem »Besser coden«, »Fit fürs Studium – Mathematik«, »Fit fürs Studium – Elektrotechnik« und »Spiele programmieren mit Godot«. Du erfährst, wie Uwe in einer Internet-Community das Kurzgeschichten-Handwerk gelernt hat, warum er Manuskripte mit einer klaren Struktur plant statt drauflos zu schreiben und was Godot als offene Spiele-Engine für Einsteiger, Jugendliche und kleine Teams leistet.

Themen der Folge

  • Von der mechanischen Schreibmaschine zu ersten Science-Fiction-Kurzgeschichten
  • Was Uwe im Forum kurzgeschichten.de über Textkritik gelernt hat
  • Volontariat bei der c’t und der Weg zum professionellen Schreiben
  • Wie aus einem Reorg-Leerlauf das erste Android-Buch entstand
  • Godot im Vergleich zu Unity: Open Source, Blender-Workflow und GDScript
  • Nodes, Physik und der Nutzen einer Game Engine gegenüber nativer Entwicklung
  • Block-Coding, Scratch und die Didaktik hinter dem Godot-Einsteigerbuch
  • Tipps für angehende Fachbuchautor*innen

Über den Gast

Uwe Post, Jahrgang 1968, ist Diplom-Physiker, IT-Profi, Fachbuch- und Science-Fiction-Autor. Nach Stationen als Wissenschaftsjournalist beim c’t-Magazin und als Entwickler bei Vodafone arbeitet er heute als Chefentwickler der Spiele-Schmiede Ludetis, wo er Projekte in den Bereichen Android, Java, Microcontroller und Softwarearchitektur betreut. Sein Roman »Walpar Tonnraffir und der Zeigefinger Gottes« gewann den Kurd-Laßwitz-Preis und den Deutschen Science-Fiction-Preis. Nebenbei unterrichtet er privat – meist rund um den Übergang von der Schule zum Studium.

Links

Credits

Du hast Lust, noch mehr Neues zu lernen? In unseren Newslettern versorgen wir dich regelmäßig mit nützlichen Inhalten aus unseren Büchern und Wissensbeiträgen unserer Expert*innen. Aber natürlich auch mit Informationen rund um Neuerscheinungen, Buchempfehlungen, Rabatt-Aktionen, Events und vielem mehr. Melde dich jetzt an!

Download transcript (.vtt)
0:00

Uwe Also wenn man sich jetzt mal vorstellt, eine Kurzgeschichte würde man verfilmen und auf YouTube bringen. Wenn da nicht nach zehn Sekunden irgendwas Interessantes passiert ist, sind die Leute weg. Und das ist eben bei Kurzgeschichten schon immer ein ganz wichtiger Aspekt gewesen.

0:18

Christian Mein Gast heute ist Uwe Post. Er hat an der Ruhr-Universität Bochum Physik und Astronomie studiert. Nach Stationen als Wissenschaftsjournalist und in verschiedenen IT-Firmen arbeitet er heute als Chefentwickler der Spiele-Schmiede Ludetis. Dort betreut er parallel Projekte in den Bereichen Android, Java, Microcontroller und Softwarearchitektur. Seit den 90er Jahren schreibt er vor allem satirische Science-Fiction. Im Fachbuchbereich schreibt er für Rheinwerk, darunter Besser Coden sowie die Studienreihen Fit fürs Studium Mathematik und Fit fürs Studium Elektrotechnik. Sein letztes Buch, Spiele programmieren mit Godot, erklärt altersgerechte Spielentwicklung in 2D und 3D. Im YouTube-Kanal des Rheinwerk-Verlags gibt es eine vierteilige Videoserie mit ihm, in der er mit Godot ein kleines Jump-and-Run-Spiel programmiert. Hallo und herzlich willkommen, Uwe.

1:11

Uwe Hallo Christian, schön dich zu hören.

1:14

Christian Ja, das geht mir auch so. Was ich total spannend finde an deinem Lebenslauf ist, dass du im Grunde so zwei Persönlichkeiten hast. So einmal so die fiktive Seite und einmal so die Fachbuchseite. Das finde ich vielleicht nicht unbedingt einzigartig, aber, bei den deutschen Autoren schon eher ungewöhnlich, dass du Fachbücher schreibst für Rheinwerk und auf der anderen Seite auch Science-Fiction-Literatur. Ich glaube, Science-Fiction-Literatur war am Anfang und die Sachbücher kamen später. Oder wie war die Reihenfolge bei dir?

1:51

Uwe Ja, das kann man schon sagen. Das war die Reihenfolge. Allerdings Nicht-Fiktives, habe ich auch schon vor den Fachbüchern geschrieben. Beim c't-Magazin, da habe ich ein Volontariat gemacht in den 90ern, Ende der 90er und da habe ich eben auch schon Fachartikel geschrieben. So gesehen war das jetzt nicht was völlig Neues. Nur wirklich konkret Fachbücher zu schreiben, ja, das kam einfach dadurch, dass ich irgendwann einfach angeschrieben wurde vom jetzigen Rheinwerk Verlag, ob ich nicht ein Android entwickeln Buch schreiben möchte.

2:27

Christian Ah, okay. Aber wie bist du überhaupt ins Schreiben reingerutscht? Also wenn ich mir so deine Anzahl von Büchern anschaue, dann sind es ja mehr Science-Fiction-Bücher als jetzt Fachbücher. Also Science-Fiction-Bücher schreibst du ja deutlich regelmäßiger. Wie bist du in das Schreiben, wie hast du das Schreiben für dich entdeckt? Also kann ich mir Uwe als kleinen Bub vorstellen, der aus dem Fenster guckt und von UFOs und Aliens träumt? Oder was waren so die Anfänge des Schreibens?

2:59

Uwe Das ist total lustig, dass du das sagst, aus dem Fenster guckt. Also bei meinem eigenen Zimmer, wenn ich da rausgeguckt habe, habe ich nicht viel gesehen. Aber wenn ich aus dem Küchenfenster geguckt habe, habe ich eine Bahnstrecke gesehen und habe mir immer die Züge angeguckt. Das war halt damals mein größtes Interesse und tatsächlich schreibe ich gerade an, also mein nächster Roman wird sich um, wird keine Science-Fiction und es wird sich um einen Jungen drehen, der aus dem Fenster guckt und da kommt ein Geisterzug, also ein Zug, der nicht im Fahrplan steht. Ah, jetzt erzähl ich, ich verrate schon zu viel. Also es kam, wie bin ich zum Schreiben gekommen? Ich habe, wie viele Jungs in meinem Alter auch, diese, ja, diese Science-Fiction-Romane, die es damals total billig gab, auf Krabbeltischen für eine Mark oder so, Die habe ich verschlungen. Und ja, obwohl ich so schlechte Noten in Deutsch hatte und mein Deutschlehrer nicht sehr glücklich mit mir war, habe ich einfach mal irgendwann angefangen. Also erst auf einem Blatt Papier, dann hat mir mein Onkel eine uralte mechanische Schreibmaschine geschenkt. Also da war nicht mehr viel Platz auf meinem Schreibtisch. Das war ein Riesenmonster. Irgendwann habe ich auch einen Schreibmaschinenkurs gemacht und eine bessere Maschine gehabt. Damals gab es ja noch keine PCs, an denen man einen Text hätte schreiben können. Man musste ja wirklich noch Buchstaben direkt aufs Papier befördern. Ja, das hat mir Spaß gemacht, aber das war natürlich alles schlecht, muss man sagen. Klar, wenn man keine Ahnung vom Schreiben hat und nicht jetzt irgendwie ein Kurs kreatives Schreiben irgendwie mal gemacht hat, man kann sich ein bisschen was abgucken, vor allem so aus diesen Kurzgeschichten. Es gab immer so Science-Fiction-Kurzgeschichten-Bände. Isaac Asimov's Science Fiction Magazin, sage ich mal als Stichwort. Das gab es so kleine Büchlein, die recht billig waren. Und das war super originell oft und sehr inspirierend. Da hatte ich dann irgendwann auch eigene Ideen und habe einfach mal so kleine Geschichten geschrieben. Deswegen, ja, es fing wirklich so mit den fiktiven Dingen und mit der Science-Fiction an.

5:03

Christian Ja, also ich hatte ja mal gelernt, dass Geschichten normalerweise ja immer so einen weichen, schönen Anfang haben und alles funktioniert so toll und plötzlich gibt es irgendein Hindernis und der Held muss irgendwas überwinden. Dann gibt es irgendwie so einen Konflikt, der gelöst werden muss. Und irgendwie, oh, alle sind böse auf den Helden und zum Schluss wird alles wieder gut. Also ich glaube, das ist ja irgendwie so ein typischer Ablauf. Wie hast du das dann gelernt? Hast du Kurse belegt oder kreatives Schreiben, hast du gerade erwähnt? Also wie hast du dich dann konstant verbessert?

5:37

Uwe Zunächst mal stimmt es relativ genau, was du gesagt hast. Das ist fast die Struktur eines Romans, ein Drei-Akter. Bei Kurzgeschichten ist ein bisschen anders, die fangen halt mitten in der Handlung an und davon abgesehen hat man natürlich auch sehr viele Freiheiten. Es ist tatsächlich so, auch in der Schule, im Deutschunterricht lernt man ja, was ist eine Kurzgeschichte, man liest auch Kurzgeschichten, dummerweise uralte, langweilige Kurzgeschichten. Das geht dann mit Novellen und Romanen auch so weiter. Die Kids werden ja mit, Texten aus dem vergangenen Jahrhundert gequält, muss man schon sagen. Klar lernen die dann auch ein bisschen was Historisches und so. Das ist auch gar nicht verkehrt, sich mit sowas auseinanderzusetzen. Aber heute sind natürlich so Geschichten ein bisschen anders strukturiert und, die Bedürfnisse des Publikums sind auch andere. Also wenn man sich jetzt mal vorstellt, eine Kurzgeschichte, würde man verfilmen oder auf YouTube bringen. Wenn da nicht nach 10 Sekunden irgendwas Interessantes passiert ist.

6:42

Christian Sind die Leute weg.

6:43

Uwe Und das ist eben bei Kurzgeschichten schon immer ein ganz wichtiger Aspekt gewesen. Deswegen müssen sie direkt in der Handlung anfangen und direkt irgendwie interessant sein, nach Möglichkeit der erste Satz muss schon sitzen. Beim ersten Satz müssen die Leser schon denken, was ist hier los? Und lesen dementsprechend weiter. Ich habe das Kurzgeschichten-Handwerk im Internet gelernt. Es gab damals eine sehr, sehr rege Community in einem Internetforum namens kurzgeschichten.de, Gibt es auch in gewisser Weise immer noch, aber das ist nicht mehr zu vergleichen mit dem, was es damals gab. Wir haben dort Geschichten gepostet und uns gegenseitig kritisiert, und zwar sachlich. Und das war eine sehr, sehr anspruchsvolle, aber auch gleichzeitig sehr kollegiale, freundschaftliche Atmosphäre. Aber es gab dann auch Usertreffen, wo wir auch über Texte geredet haben, wie wir schreiben. Wir haben auch kleine Lesungen veranstaltet in Bibliotheken oder dergleichen im Ruhrgebiet. Das war so Anfang des Jahrhunderts. Ja, und es gibt einen Autor, der auf kurzgeschichten.de groß geworden ist, mit dem ich auch da kennengelernt habe, mit dem ich auch viel zusammen gemacht habe, der heute richtig berühmt ist. Das ist der Torsten Sträter.

8:08

Christian Der Torsten, der Dortmunder.

8:09

Uwe Der hat auf kurzgeschichten.de seine ersten Geschichten veröffentlicht und also unter Pseudonym.

8:17

Christian Sträter, andersrum. Wie hieß denn sein ... kannst du das sagen?

8:25

Uwe Ich weiß es nicht. Ich weiß es nicht. Ich weiß es nicht. Ich weiß nicht, ob die Sachen da noch drauf sind oder ob er diese hat löschen lassen, wie das da mit Copyrights ist oder dergleichen. Keine Ahnung. Also da bin ich lieber vorsichtig. Ähm. Ja, auf jeden Fall war das einfach eine Atmosphäre, da hat man sich dann gegenseitig so angespornt, gegenseitig auch mit Herausforderungen wie Thema des Monats, auch im Science-Fiction-Bereich dann gegenseitig gepusht und dadurch wurden wir wirklich immer besser.

8:59

Christian Du bist ja irgendwann mal in eine etwas andere Richtung gelaufen und hast dann Physik und Astronomie studiert. Wie kann ich mir das zeitlich vorstellen? Also warst du da schon aktiv am Schreiben und hast dann dein Studium begonnen? Oder kam das Studium eigentlich eher zuerst und dann kam parallel dazu das Schreiben? Wie war das zeitlich einzuordnen?

9:22

Uwe Das kam parallel. Ich hatte schon zu Schulzeiten angefangen mit meinen ersten Versuchen. Und dann Anfang der 90er habe ich dann studiert. Und ja, es gab auch so damals so Science-Fiction-Brief-Clubs, wo man so kleine fotokopierte Hefte auch durch die Welt geschickt hat. Da waren dann auch mal Geschichten drin und so. Das war natürlich alles sehr, sehr amateurhaft. Ich habe auch während meines Studiums bei der Fachschaftszeitschrift mitgearbeitet. Das war auch sehr, sehr spaßig, vor allem sehr, sehr schräg, was wir da gemacht haben. Der Kernspalter hieß diese Zeitschrift. Was natürlich für Physik natürlich total angemessen ist. Ja, und, so gegen Ende oder eigentlich eher so nach dem Studium begann dann vor allem durch die Arbeit bei der c't wirklich die konzentrierte Auseinandersetzung mit Texten und mit Textqualität. Denn natürlich habe ich im Rahmen des Volontariats bei der c't auch sehr viel über das Schreiben gelernt, speziell über das professionelle Schreiben. Ich meine, gerade in Kurzgeschichtenszenen und auch in der Schriftstellerei gibt es ja Autoren, wenn du denen irgendwie sagst, dass, dir die Geschichte nicht gefällt, dass dir da dies und jenes nicht dran gefällt, dann liegt das ja an dir.

10:49

Christian Genau. Es gibt ja Autoren.

10:51

Uwe Die sind also so ein bisschen von sich selbst überzeugt. Vielleicht ein bisschen zu sehr von sich selbst überzeugt. Und ich meine, das kennen wir ja auch, wenn wir unser Manuskript an den Lektor beim Rheinwerk Verlag schicken und dann kommt die Mail mit dem korrigierten Text. Also ich habe dann immer so ein bisschen Angst, bevor ich das öffne. Also ich meine, es ist dann natürlich tatsächlich nicht so schlimm, wie man befürchtet. Oder jetzt, als ich für mein Elektrotechnik-Buch, da gab es natürlich auch ein Fachgutachten von einem Elektrotechnik-Professor. Da hatte ich schon ein bisschen Schiss. Aber es ist halt eine Frage der professionellen Einstellung, dann zu sagen, klar, der weiß dann die Dinge besser. Es ist wichtig, dass der mich korrigiert und natürlich nehme ich diese Korrekturen dann an und verbessere dann entsprechend den Text, um das bestmögliche Produkt, nämlich das Buch, auf den Markt zu bringen. Das ist eine professionelle Einstellung und letztlich gilt das auch bei Kurzgeschichten oder bei Romanen. Ich möchte ja am Ende, weiß ich nicht, bei Amazon gute Bewertungen kriegen und es soll ein Bestseller werden und so. Und wenn ich mich dann darauf versteifen würde, die Geschichte ist so gut und richtig, wie sie ist und die hat sich ja auch so entwickelt wie so ein Pflänzchen und dieses zarte Pflänzchen, das darf man auf keinen Fall beschneiden oder so. Nein, also man muss da schon wirklich eine professionelle Einstellung an den Tag legen, finde ich. Und ich glaube, die erfolgreichen Autoren machen das auch.

12:27

Christian Ich stelle mir das bei Science-Fiction viel schwieriger vor, Geschichten oder Handlungsstränge nachträglich noch zu ändern als in einem Sachbuch. Also ist dir das mal selber passiert, dass du geschrieben hast und irgendwann, durch einen, nennen wir es mal, Probeleser aufmerksam gemacht wurdest auf ein paar Schwachstellen der Geschichte, wo du gesagt hast, ja okay, die Abfolge passt ja eigentlich überhaupt nicht. Ich glaube, hier gehe ich nochmal dran. Also ist das schon bei dir passiert? Und hast du dann kein Problem, Sachen wegzuschmeißen und zu sagen, ja, stimmt, jetzt schreibe ich nochmal neu. Oder nee, das will ich noch irgendwie retten, der schöne Text! Meine Fingerchen haben so schön getippt.

13:02

Uwe Das ist ganz unterschiedlich. Also es ist ganz unterschiedlich. Es ist so, dass ich bei Kurzgeschichten, aber insbesondere natürlich auch bei Romanen, mir erst mal sehr lange Gedanken über die Struktur der Geschichte mache. Also was für Figuren, wo findet das statt, was ist der Spannungsbogen? Und solange, was ist der Schluss, also gerade bei Kurzgeschichten ist wichtig, dass es einen knackigen Schluss gibt, am besten mit so einer Wendung, solange man sich, also wenn man sich darüber keine Gedanken macht, sondern einfach drauf losschreibt, dann ist also die Wahrscheinlichkeit einfach sehr hoch, dass man einen großen Teil hinterher wegschmeißen muss. Deswegen, dass ich alles wegschmeiße, das passiert eigentlich gar nicht. Was halt schon mal passiert ist, dass eine Kurzgeschichte einfach unveröffentlicht bleibt, weil sie einfach nicht so gelungen ist und weil es eben natürlich auch nicht so viele Möglichkeiten gibt, sie zu veröffentlichen. Es gibt nicht so viele Magazine, die Kurzgeschichten bringen oder Anthologien. Gerade auf dem deutschen Markt kann man Kurzgeschichten gegen Honorar eigentlich nur im c't-Magazin und im Spektrum der Wissenschaft veröffentlichen, also Science-Fiction-Kurzgeschichten. Dann gibt es auch das Exodus-Magazin. Aber das hat schon wieder eine ganz viel niedrigere Auflage. Nein, also gerade bei Kurzgeschichten, ist es einfach so, dass die Entstehungszeit deutlich länger ist jetzt im Verhältnis zur eigentlichen Schreibdauer oder dem eigentlichen Umfang der Geschichte. Also die Gedanken, die man sich machen muss, sind einfach viel umfangreicher. Eben weil ja auch die Kurzgeschichte komprimiert sein muss, Das heißt, da muss man sich schon genau Gedanken drüber machen, wie beschreibt man eine Szene. Was für Figuren sind interessant, wie macht man die Figuren interessant, wie bringt man das alles auf einen Punkt, sodass es auch richtig spannend und farbig für die Leser rüberkommt. Ja, und da muss man schon auch mal, also gerade Testleser, ich habe natürlich auch Testleser, ich schicke eigentlich jede Geschichte, bevor ich sie an einen Verlag oder an die c't schicke, mindestens einen Testleser, kritischen Testleser. Ich meine, es ist ganz wichtig, dass ein Testleser nicht nur sagt, ach, schön, toll, du hast ja viele Ideen. Also so typischerweise so Eltern oder so. Keine guten Testleser. Also da muss schon Kritik kommen. Und zum Beispiel so, ja, diese Figur handelt jetzt nicht so ganz plausibel. Wieso macht die das? Das finde ich nicht überzeugend. Da kann man überlegen, ändert man die Figur oder ändert man, wie die Figur handelt. Die Situation muss schon irgendwie nachvollziehbar sein.

15:47

Christian Dein erstes Fachbuch war ja über Android. Wie bist du zu Android-Entwicklungen gekommen? Was gab es da für einen Auslöser? Wolltest du Apps programmieren? Wolltest du Spiele programmieren? War das der erste Job gewesen, wo dein Arbeitgeber dich reingedrückt hat? Wie bist du dazu gekommen, letztendlich auch ein Buch über Android zu schreiben?

16:08

Uwe Es war viel lustiger.

16:09

Christian Oh.

16:10

Uwe Es war viel lustiger. Ich war damals bei Vodafone in Düsseldorf als Entwickler, Und Vodafone ist ja so ein Monster-Konzern. Und was Monster-Konzerne gerne machen, ist, sie strukturieren sich um. Und was bei so einer sogenannten Re-Org passiert ist, diese Re-Org wird angekündigt und dann werden drei Monate lang Meetings abgehalten, also auf mittlerer Management-Ebene. Und dann wird das Ergebnis bekannt gegeben, wer jetzt dann in welchem Team ist und so. Und währenddessen werden im Grunde alle produktiven Arbeiten eingestellt, weil man sowieso nicht weiß, wo man dann landet oder ob das Projekt überhaupt weitergeführt wird oder sowas. Und in so einer Reorg war es dann so, dass da gerade die ersten Android-Phones rauskamen. Und wie es so bei Vodafone war, wir hatten da einen Raum, weil wir mussten ja auch Sachen testen und so. Dieser Raum bestand quasi bis zur Decke nur aus Kisten voller Handys. Also damals natürlich noch Feature-Phones oder normale Handys, aber da kamen dann eben auch die ersten Smartphones. Also habe ich mir so ein Smartphone geschnappt und mal geguckt, wie man das programmieren kann. Durfte ich, ne? Also ich habe natürlich meinen Teamleiter gefragt, kann ich das machen? Und der sagte, boah, super Idee, kann man bestimmt mal gebrauchen und dann habe ich das gemacht. Und dann habe ich, ja, erst dann natürlich habe ich ein kleines Spielchen dann programmiert, genauer genommen, eines, das ich früher mal für den Atari ST programmiert habe, aber nie veröffentlicht. Das habe ich dann quasi adaptiert, Einfach mal geguckt, wie das funktioniert. So mit einfachen Grafiken. Das hat gut funktioniert. Das Spiel gibt's noch. Das heißt Secret of the Mirror Mage. Es ist eigentlich nur so ein Symmetrie-Puzzle-Spiel. Und es hat, glaube ich, ungefähr null Downloads. Aber es war mein erstes. Also ich hab's inzwischen aufgepeppt. Ein bisschen. Das kann man sich schon mal angucken. Mal gespannt, ob jetzt im Nachlauf nach diesem Podcast die Installationszahlen, Also, probiert's aus, Leute. Es ist cool. Es hat auch superschöne fraktale Grafiken. So. Ja, und dann habe ich was programmiert, was auch ein bisschen erfolgreich war, nämlich, ich interessiere mich auch für Fußball und dann habe ich den ersten Online-Multiplayer-Fußballmanager für Android programmiert. Der heißt Kick It Out. Den gibt's immer noch und der wirft auch immer noch Geld ab. So. Ja, der hat natürlich auch eine Server-Komponente, ne? Das ist ja eigentlich so, da wo ich herkam, ne? Server-Anwendungen in Java programmieren, das konnte ich ja auch schon alles, deswegen also ich war eben dazu in der Lage, zusammen mit meinen Kompagnons, wir hatten ja eh eine kleine Firma gegründet, weil wir Browser-Games machen wollten eigentlich. Browser-Games, weiß eigentlich heutzutage noch jemand, was das ist?

19:12

Christian Ja, Flash.

19:14

Uwe Die Zeiten sind vorbei, die Zeiten sind vorbei, als man Browser Games in Facebook gespielt hat oder irgendwie sowas, Ja, wir waren einfach schnell, weil Android war nagelneu und alle großen Spielefirmen mussten wahrscheinlich erst mal, brauchten wahrscheinlich drei Monate, um ein Meeting zu organisieren, um zu überlegen, was man denn jetzt vielleicht machen könnte. Und da waren wir schon längst fertig und hatten das schon am Markt. Und deswegen, damals war es auch noch so, dass im Play Store, die neuen Apps oder erfolgreichen Apps, die wurden dann wirklich nach oben sortiert. Heutzutage wird ja quasi nur nach oben sortiert, wer halt für Werbung bezahlt und so. Und deswegen hatte das eine sehr große Sichtbarkeit. Und dementsprechend, ja, war es eben sehr erfolgreich, so erfolgreich, dass uns irgendwann halt der Server abgekackt ist.

20:03

Christian Juhu, das ist doch eher ein gutes Zeichen. Da muss man heftig nachrüsten.

20:06

Uwe Das war schon, das war heftig. Ja, damals war es natürlich auch noch nicht ganz so einfach mit Skalierung im Server-Seite.

20:12

Christian Ja, hast du noch nicht AWS oder sowas gehabt.

20:14

Uwe Ja, und irgendwie, ich hab das natürlich auch, also das war ja in den Medien, ne? Wir haben ja in irgendwelchen Fachzeitschriften sind so was, sind Artikel darüber erschienen und so. Und darüber ist anscheinend, die damalige Lektorin beim Rheinwerk Verlag auf mich gekommen, weil die hat gesehen, aha, der war bei c't, da hat er geschrieben, der schreibt unterhaltsame Kurzgeschichten und Android programmieren kann er auch. Das wäre genau der Richtige, um ein Android-Apps entwickeln Buch zu schreiben.

20:43

Christian Ja, okay.

20:44

Uwe Ja, und weil ich ja Zeit hatte, ich durfte tatsächlich, ich hatte die offizielle Genehmigung von meinem Vodafone-Teamleiter, während meiner Arbeitszeit an dem Buch zu schreiben.

20:53

Christian Ach, krass.

20:54

Uwe Ja, super krass. Und deswegen war das auch innerhalb von zwei, drei Monaten fertig.

21:01

Christian Jetzt machen wir ja noch Werbung für Arbeitgeber. Ich glaube, die Zeiten sind aber auch vorbei.

21:07

Uwe Ja, nein, weil Vodafone hat die interne Entwicklungsabteilung inzwischen dicht gemacht. Die lagern die Entwicklung aus. Und ich kann Vodafone als Arbeitgeber, jedem empfehlen, der sehr gute Nerven hat. Das geht aber für jeden großen Konzern. Das muss man sich einfach vor Augen halten. Das ist nicht so wie in einer kleinen Firma, wo man dann halt mit, niedrigen Hierarchiestufen Unterschiede hat, sondern da hat man dann einfach irgendwo ein mittleres Management, so einen Typen, den man nie gesehen hat, das ist der Chef und der ändert sich dann plötzlich. Da hat man plötzlich einen anderen Chef und dann ist plötzlich irgendwie, hat man auch plötzlich andere Projekte und man weiß gar nicht, was eigentlich. Das ist einfach in großen Konzernen so. Das ist bei, you name it, ne?

22:02

Christian Ja, klar.

22:03

Uwe Das ist bei allen großen Konzernen das Gleiche.

22:05

Christian Interessant finde ich dann die Fokussierung auf die Spieleentwicklung, weil anschließend kam ja das Buch Spieleprogrammierung mit Android Studio. Also das heißt, die Kreativität, die du beim Schreiben ja schon gefunden hast, die hast du dann übertragen auf Spiele. Und so folgte dann das nächste Buch. Und letztendlich ging das ja auch über in Godot. Also ist es etwas, wo du dich heute heimisch fühlst in Spieleprogrammierung? Ist es so dein Weg, den du gemacht hast, also weg von der klassischen serverseitigen Programmierung mit Web-Services, REST, Datenbank-Zugriffen, LOB, Richtung Spieleentwicklung?

22:45

Uwe Ich mache heute beides. Also ich mache schon die ganze Zeit beides. Erstens mal kann man auf einem Bein nicht stehen. ähm, ich meine, die Konkurrenz auf dem Spielemarkt ist natürlich exorbitant ich glaub gestern hab ich noch irgendwo gesehen dieses Jahr, äh, vergangenes Jahr 2025 sind auf Steam 20.000 neue Spiele rausgekommen.

23:06

Christian Irre!

23:06

Uwe Naja, da soll man erstmal, da muss man erstmal vor allem als kleine Firma oder als Independent Game Studio, so würde ich es jetzt mal einordnen, da muss man erstmal was platzieren, das dann irgendwo eine solche Sichtbarkeit entwickelt, dass das irgendwo auch nur annähernden Erfolg ist. Das ist exorbitant schwer, wenn nicht sogar fast unmöglich heutzutage. Denn auch Spieleentwicklung ist ja quasi demokratischer geworden. Jeder kann einfach hier kostenlos Godot installieren, würde man jetzt heutzutage machen, klick, klick, paar YouTube-Tutorials angucken und schon hat man sein erstes Spiel fertig und kann das veröffentlichen. Und dementsprechend wird eben auch viel veröffentlicht. Also deswegen ist die Spieleentwicklung jetzt nichts, womit man heute reich werden kann oder sagen wir mal auch nur ein sicheres Einkommen haben kann. Erst mal abgesehen von unserem Fußballmanager, der halt regelmäßig noch ein bisschen was abwirft, einfach weil es treue Mitspieler gibt. Ja, und Spiele haben mich schon immer fasziniert. Also bevor es Computer gab, Brettspiele und dann schon zu 8-Bit-Zeiten. Naja gut, damals war es eh so, man musste die Spiele quasi selber programmieren, weil so viele gab es halt einfach nicht und so habe ich dann eben auch Basic gelernt und Assembler gelernt und dann C gelernt und so weiter und so fort. Also das war schon das war schon eigentlich immer so das war nie anders und, inzwischen würde ich sagen mache ich die Spieleprogrammierung so nebenbei zum Spaß und es ist einfach auch toll, dass man Geschichten erzählen kann in Spielen. Also ich meine, Spiele, da gibt es ja so ein Riesenspektrum. Von einem einfachen Ballerspiel bis hin zu. Wirklich erzählerisch, ganz, ganz anspruchsvollen, emotional auch mitreißenden Adventures oder auch Rollenspielen und bis hin zu Grand Strategy Games, die so unglaublich komplex sind, dass man davor sitzt und sich fragt, was passiert, wenn ich jetzt auf diesen Knopf drücke? Werde ich das überhaupt jemals erfahren, was für eine Auswirkung das hat? Oder kann es vielleicht ab diesem Moment den ganzen weiteren Spielverlauf ändern?

25:39

Christian Wenn du mal die pure Android-Entwicklung mit der Entwicklung mit Godot vergleichst, dann würde ich das ja so charakterisieren, dass du bei purer Android-Entwicklung selbst mit modernen Frameworks eigentlich noch super viel selber machen musst. Und dass dir Godot heute so viel abnimmt, beziehungsweise allgemein so Engines wie Unity oder Unreal. Und da würde ich auch sagen, insbesondere mit KI, ist es heute viel, viel einfacher, sofort fertige Spiele zu haben, anstatt alles von Grund auf neu programmieren zu müssen. Also, ich weiß nicht, ich habe Szenen, die ich beschreibe oder einen Sprite-Editor, da klicke ich meine Szene zusammen und man kopiert YouTube-Videos und dann hüpft dat Männeken und man hat sofort innerhalb von einem Tag ein Jump'n'Run-Spiel. Und wenn man dann schöne Grafiken vielleicht auch generiert hat, ist ein Spiel fertig. Also das ist, glaube ich, wirklich so eine Demokratisierung. Aber vergleichen wir mal, weil du hast ja auch das Godot-Buch geschrieben. Warum würdest du Leuten Godot empfehlen? Wo siehst du die konkreten Vorteile jetzt zu Unity oder Unreal, die ja viel verbreiteter zumindest mal waren, eine hervorragende Dokumentation haben, Stärken im 3D-Bereich haben? Also, warum würdest du Menschen Godot empfehlen?

26:48

Uwe Also zunächst mal. Du hast völlig richtig gesagt, also die Spiele Programmierung mit Android sozusagen nativ, damit meine ich jetzt natürlich nicht Native Development, sondern Java oder heute Kotlin, da muss man einfach unglaublich viel selbst basteln und das, ist viel zu viel Aufwand. Früher ging es eben nicht anders, Und mit so ein paar Views, wo dann halt eine Grafik drin ist und die Views positioniert man irgendwo, da kann man schon viel machen. Und da bin ich auch relativ weit gekommen mit den Spielen. Aber ein ganz erheblicher Nachteil ist natürlich, dass es nicht plattformübergreifend ist. Ich kann das nicht einfach mal eben fürs iPhone portieren. Also kann ich gar nicht, geht nicht, null, muss ich komplett neu schreiben. Und das ist natürlich bei Spiele-Engines der große Vorteil. Ich bastel das einmal mit, sei es mit Godot oder Unity, hier schön an meinem Bildschirm zusammen, auch grafisch. Ich habe ja fast what you see is what you get. Ich kann das direkt am PC ausprobieren, und dann kann ich das natürlich mit ein bisschen technischem Aufwand, einmal vorausgesetzt, ich habe einen Mac, fürs iPhone erzeugen als fertiges Spiel und einmal für Android und dementsprechend auch in den entsprechenden Märkten veröffentlicht. Und Godot ist seit ein paar Jahren stark im Aufwind und. Ich glaube, eine der Stärken von Godot ist die Schwäche von Unity, weil Unity, das kann man ja auch so über die ganzen letzten Jahre verfolgen, einige strategische Entscheidungen getroffen hat, unternehmensstrategische Entscheidungen getroffen hat, vor allem mit den Bezahlmodellen und so, dass die sehr viele Entwickler verloren haben. Und viele davon sind halt zu Godot gegangen, was natürlich wiederum die Community vergrößert hat und dann auch wiederum die Anzahl der Mitarbeitenden, die dann halt auch bei der Weiterentwicklung unterstützt haben. Dadurch hat das Ganze halt auch ein bisschen mehr Dynamik bekommen, denn Godot ist halt Open Source. Es hat auch eine Plug-in-Schnittstelle, man kann, es gibt zig Add-ons, die man einfach so über die Oberfläche installieren kann, ist auch alles kostenlos. Es gibt Assets, Asset Library und natürlich gibt es, die einfache Anbindung von 3D-Programmen, hauptsächlich Blender natürlich, was in der Open-Source-Szene halt so das Wichtigste eigentlich ist, das bekannteste und am meisten Verwendete ist. Also man muss eigentlich nur mit Blender sein Objekt basteln und dann legt man das in das Verzeichnis, in das Projektverzeichnis von Godot und dann ist es schon da. Man zieht es in die Szene rein und man hat das. Auch inklusive Animationen. Ein paar Kleinigkeiten fehlen, zum Beispiel Pfade werden nicht übernommen, aber sonst ist halt alles da, inklusive Texturen, und man kann das direkt verwenden. Und wenn man das Objekt ein bisschen verändert im Blender, einfach speichern, es wird automatisch in Godot reimportiert und es ist aktualisiert. Also der Workflow ist da einfach sehr, sehr effizient. Und ich finde, die Oberfläche von Godot ist ein bisschen einfacher als Unity. Und die Lernkurve ist schon hoch, weil es gibt unglaublich viele Dinge, die man anklicken kann. Man muss sich natürlich auskennen, was gibt es für verschiedene Objekttypen, weil im Endeffekt, genau wie bei Unity, auch bei Godot, das gesamte Spiel, Alles, was man baut, besteht im Prinzip aus Objekten, Nodes heißen die genau genommen, die irgendwie zusammengebaut sind, die irgendwo positioniert sind und diese Nodes haben unterschiedliche Typen. Man muss halt wissen, welche Typen es gibt, damit man optimalerweise den Typ verwendet, den man jetzt gerade für den Bedarf, den man gerade hat, am besten gebrauchen kann. Dann gibt es natürlich in Add-ons wiederum weitere Node-Typen, zum Beispiel so einen Simple Character, ja, den zieht man drauf, dann tut man da ein Bildchen rein und schon kann man, den mit Tastatur oder Joystick oder Maus oder Game Controller steuern. Fertig. Man muss überhaupt nichts coden. Ja, und ein Vorteil von Godot ist, dass die Programmiersprache, wenn man denn coden muss, GDScript, sehr Python-ähnlich ist. Und ja, Python wird ja teilweise schon an den Schulen gelehrt, also ist weit verbreitet. Ist, denke ich, auch ein bisschen einfacher als C-Sharp. Das ist ja die Sprache von Unity.

31:36

Christian Vielleicht gehen wir noch mal einen Schritt zurück. Kannst du mal erklären, welche Aufgaben so eine Game Engine im Allgemeinen hat? Wir haben ja gestartet mit, okay, bei reiner Android-Entwicklung muss ich alles selber machen. Und jetzt habe ich eine Game Engine und die macht vieles für mich. Kannst du mal ein paar Beispiele geben, was genau so eine Game Engine macht? Warum es sich lohnt, direkt so was einzusetzen?

31:57

Uwe Ja, was ich gerade andeutete, ist eine ganz wichtige Eigenschaft. Die Game Engine fügt einen Abstraktionslayer ein. Sie ermöglicht es eben, dass ich einmal meine Gameszenen, meine Game-Funktionalität baue und sie auf verschiedenen Plattformen laufen. Im Falle von Godot ist das neben Android und iPhone auch der Desktop, also PC, Mac oder Linux. Und man kann sogar WebGL, also ja, Internetanwendungen, Browser-Games.

32:29

Christian Das möchte ich sagen.

32:32

Uwe Damit machen. Also es gibt so Details, wo man aufpassen muss, aber ansonsten ist es im Prinzip einmal das Spiel gebaut und die Engine läuft auf verschiedenen Plattformen. So, und dann ist die Hauptaufgabe der Engine, für die grafische Darstellung zu sorgen. Das heißt, ich als Entwickler sage nur, hier im zweidimensionalen Raum befindet sich eine Plattform und hier mit etwas da drüber, befindet sich ein Charakter, eine Spielfigur. Die hat ein bestimmtes Aussehen und diese Plattform ist eben ein physikalisches Objekt, da kann man nicht durchfallen, die hat so einen Kollisionskörper, so nennt man das. Ja, und dann drücke ich auf Start und schon kann ich mit dieser Figur auf dieser Plattform zum Beispiel hin und her laufen und wenn ich zum Rand der Plattform laufe, fällt sie runter. Die Engine kümmert sich also A, um die grafische Darstellung, B, um die Physik. Man kann sie natürlich ausschalten, man kann die Schwerkraft ausschalten, wenn man ein Weltraumspiel machen will oder so. Und das ist natürlich ein Riesenaufwand, den man von Hand so gar nicht leisten könnte. Also wenn ich jetzt anfange zu programmieren und Schwerkraft und dann trifft meine Spielfigur, weil sie runterfällt, halt auf irgendein Gegenstand und in welche Richtung prallt sie denn dann ab? Oder so. Das ist ja, da muss man ja Physik für studiert haben. Hab ich ja zum Glück. Trotzdem habe ich keine Lust, da zu programmieren. Das ist viel zu aufwendig. Haben andere Leute ja schon gemacht. Und das ist eben Teil der Engine. Ja, und einfach solche Funktionalitäten, die man oft braucht, wie die Physik, aber eben auch eine UI, ein Head-Up-Display, ich möchte irgendwo die Punktzahl oben anzeigen, die Anzahl der Leben, die ich noch habe oder dergleichen. Dann vor allem im 3D-Bereich, wenn ich in den 3D-Bereich gehe, dann habe ich ja ein richtiges Rendering. Das heißt, ich habe eine Lichtquelle, Ich habe eine Kamera, die ich einfach positionieren kann. Ich kann die Farben einstellen, ich kann die Tiefenschärfe einstellen. Ich habe eine 3D-Figur, die irgendwo steht und die Engine berechnet, die Beleuchtung, die Schatten und die Farben, was eben alles so dazu gehört.

35:16

Christian Warum hat sich, denkst du, Godot für eine neue Programmiersprache entschieden? Weil GDScripts gab es ja vorher nicht. Also warum, denkst du, hat man nicht sowas wie wirklich C-Sharp eingesetzt, wo es auch eine Dokumentation für gibt? Oder Lua ist ja auch recht populär als Skriptsprache. Oder direkt Python. Also warum, denkst du, hat man hier was Neues entwickelt?

35:38

Uwe Ja, das ist eine gute Frage. Ich weiß es tatsächlich nicht. Ich könnte da jetzt auch nur raten. Es ist aber so, dass es für Godot auch Bindings in anderen Sprachen gibt. Also Lua glaube ich zum Beispiel auch. C-Sharp auf jeden Fall. Da wird dann halt .NET beziehungsweise Mono intern verwendet. Das heißt, man kann dann halt seine Skripte auch in C-Sharp schreiben. Also im Grunde ist diese Plattform recht offen. Ich meine, der Nachteil dabei ist natürlich, dass dann zum Beispiel .NET beziehungsweise nicht .NET, Mono muss dann mit aufs Gerät deployed werden, was natürlich das ein bisschen größer macht irgendwie. Jetzt auch nicht entscheidend, aber ein bisschen größer macht. Und es gibt vielleicht da auch Performance-Unterschiede. Also es kann Performance-Unterschiede geben. Im Prinzip wird GDScript auch kompiliert in so eine, ja, ich weiß gar nicht genau, es ist so eine Tokensprache. Ich glaube, es ist so ein bisschen ähnlich wie Java und läuft dann auf einer virtuellen Maschine quasi. Also es wird jetzt nicht in Maschinensprache übersetzt, weil dann müsste man ja wieder, weil die Plattformen unterschiedlich sind, das in unterschiedliche Maschinensprachen übersetzen, das kann die Engine eben nicht. Ja, also man ist eben in der Wahl der Sprache relativ frei, und ich denke, man hat GDScript als, ja, wirklich sehr Python-ähnliche Sprache, verwendet, um die Einstiegshürde relativ gering zu halten, weil Python ist einfach recht gut lesbar, ich denke, die Lernkurve ist nicht so hoch. Man hat aber nicht das ganze Drumherum von Python, also so die Verwaltung von Abhängigkeiten über Pip und dergleichen, das fehlt alles, das hat man abgeschnitten. Ich glaube, man wollte es so einfach wie möglich halten.

37:40

Christian Und eine individuelle Programmiersprache hat natürlich auch den Vorteil, dass man sich im Komponentenbaum bewegen kann. Man kann direkt Knoten an Eigenschaften binden oder vergleichbare Sachen machen, was normale Programmiersprachen ja nicht tun. Die haben ja keine Bindung quasi zu der Oberfläche. Also diese Interaktion, glaube ich, über Namenskonvention oder ähnliches kann man natürlich schaffen, was ein Vorteil ist.

38:02

Uwe Genau, das brauchte man auf jeden Fall. Wobei Unity das ja in C-Sharp dann auch quasi macht, aber eben nicht über so Namenskonventionen, Sondern, ja, im Grunde über, ja, so eine Art, ja, ich würde sagen Inversion of Control, ja, also meine Skripte in Unity sind, da bekomme ich erst die Kontrolle, wenn gewisse Properties gefüllt wurden und da sind dann Verweise auf andere Szenen oder auf Objekte drin. Sowas kann man in Godot zwar auch machen, aber es gibt tatsächlich diese spezielle Notation mit einem Dollarzeichen, wo man direkt einen Node referenzieren kann. Und das ist eben sogar so einfach, so intuitiv. Man kann aus dem Node-Tree, den man sieht, kann man einfach mit der Maus den Node drüber ins Skriptfenster ziehen und dann hat man da sofort diese Referenz und kann damit arbeiten. Ist aber meiner Ansicht nach nicht so empfehlenswert. Weil sobald man den Node umbenennt, ist ja der Verweis im Skript kaputt.

39:09

Christian Ja, okay.

39:09

Uwe Also kann man mal machen, also wenn man wirklich weiß, dass man das nicht mehr ändert oder nicht oft ändern wird, dann kann man das machen. Ansonsten bin ich auch immer für dieses Injizieren. Das heißt, ganz sauber, man definiert quasi eine Exportvariable, nennt man das dann. Und die kann man dann in diesem Inspektor von Godot mit einem Wert belegen. Und da kann dann auch nichts mehr passieren, wenn man es umbenennt.

39:33

Christian Allgemein, wie ist denn das Tooling rund um Godot? Also ich sag mal, wenn man jetzt professionell Software, schreibt, sind Werkzeuge wie Debugger, Profiler wichtig, Refactoring-Tools sind wichtig, Arbeiten in Teams ist irgendwie wichtig. Wie siehst du da die Situation bei Godot?

39:52

Uwe Ja, tatsächlich gemischt. Das kann man tatsächlich als Nachteil sehen, jetzt im Vergleich zu Unity, was auch schon viel, ja, was es schon länger gibt und was sich dementsprechend, ja, was vielleicht auch ein bisschen mehr in Richtung professioneller Teams aufgestellt ist. Also, Godot hat einen Debugger, Step-by-Step-Debugger, das ist kein Problem. Man kann auch dann problemlos in Objekte reinschauen, sich die Properties anschauen. Profiler gibt's auch. Den hab ich persönlich noch nicht benutzt, weil ich den Bedarf noch nicht hatte. Was halt schwierig ist, ist die, also der Editor ermöglicht jetzt kein unterstützendes Refactoring. Und ja, die Syntax-Vervollständigung geht ganz gut und die, ja, die Source-Code-Verwaltungs-Integration ist, also es gibt einen Plugin für Git. Das, ich fürchte, wird nicht mehr weiterentwickelt. Also im Moment benutze ich da tatsächlich Git von der Kommandozeile. Das ist dann natürlich ein bisschen, ich meine, ich weiß halt, wie es geht, deswegen ist das jetzt für mich nicht so das Problem. Aber wenn jemand da neu einsteigt, ja, dann hat er da auf jeden Fall eine Hürde vor sich, wohingegen Unity das direkt mit eingebaut hat. Allerdings, also jetzt die Unterstützung von diesem, wie heißt das eigentlich, bei Unity Team oder so, wobei das sehr stark eingeschränkt ist und dann kostet das ganz schnell Geld. Wohingegen, wenn man jetzt sein Projekt auf GitHub packen möchte und einfach Git benutzen möchte, dann ist es bei Unity auch ein bisschen komplizierter. Aber auf jeden Fall einfacher als bei Godot. Also so gesehen würde ich es empfehlen für kleine Teams, aber natürlich auch für Einzelentwickler. Es gibt zahllose Einzelentwickler, die in Godot schon ganz ordentliche Sachen zusammenbasteln. Man darf ja auch nicht. Man sollte sich da auch keine Illusionen hingeben, dass man jetzt wirklich damit, ein erfolgreiches Spiel produziert. Das ist höchst unwahrscheinlich. Also da müsste man dann auch wirklich das Marketingbudget dahinter haben. Sonst kriegt man ja so ein Produkt, so ein neues Spiel überhaupt nicht in den Markt rein. Deswegen denke ich, wir sprechen ja auch hauptsächlich oder uns hören jetzt hauptsächlich Menschen zu, die es vielleicht erst mal sich anschauen möchten, als Hobby mal so nebenbei gucken. Sie haben so eine Idee, vielleicht ein kleines Spiel zu machen und das vielleicht einfach im Freundeskreis rumzureichen oder so. Oder es einfach mal auch von mir aus für Android zu veröffentlichen, das kostet ja fast nichts. und ja, dann mal gucken, was passiert. Und da hat man einfach nicht so diesen professionellen Anspruch und da ist es dann vor allem wichtig, wenn man dann vielleicht mit einem Freund zusammen, sich mit einem Freund zusammentut, dass man sich abstimmt, wie man diese Daten austauscht. Also im Extremfall kann man zum Beispiel sagen, du kümmerst dich um diese Szene, du kümmerst dich um diese Szene, wir packen das Ganze, in eine Nextcloud oder so und wir kommen uns nicht in die Quere. Und dann muss man nicht mergen und dann braucht man kein Git. Also im ganz einfachsten Fall. Das geht auch.

43:26

Christian Ich habe in Erinnerung, dass du mal oder bei dem Godot-Buch die grafische Programmiersprache verwendet hast, Blockly, und dass du irgendwann mal gesagt hast, dass es so einen Bruch gab, weil jetzt kann man das auch nativ irgendwie machen, grafisch programmieren. Das habe ich nicht so genau verstanden. Kannst du nochmal erklären, also was du verwendet hast und was sich jetzt geändert hat, was du quasi aktualisieren könntest im Buch?

43:50

Uwe Genau. Ich wollte gerne, weil sich das Spieleprogrammieren mit Godot-Buch ja auch an Jugendliche richtet. Ist ja auch noch unter Vierfarben erschienen. Es ist schön bunt. Es ist wirklich Step by Step mit. Niedriger Lernkurve. und ich fand halt Godot, wenn man jetzt direkt damit anfängt, und dann auch anfangen muss zu skripten, fand ich sehr anspruchsvoll, eine zu steile Lernkurve. Deswegen habe ich ein Kapitel vorangesetzt, Spiele programmieren mit Scratch. Scratch wird ja teilweise auch in den Schulen schon gemacht und dann kann man nämlich dieses Scratch-Block-Coding. Dieses Scratch-Block-Coding kann man quasi eins zu eins in ganz einfachen Programm-Code, GDScript, in Godot übersetzen. Und seit kurzem gibt es für Godot auch ein Block-Skript, eine Block-Skript-Erweiterung. Das heißt, ich kann ein neues Godot-Projekt anlegen, installiere dieses Block-Coding-Add-on, und dann kann ich auch so ähnlich wie in Scratch mit Blocks coden. Das ist noch nicht so ganz ausgereift. Für die nächste Auflage würde ich das dann aber auch benutzen und ich kann das durchaus empfehlen. Es schadet natürlich nicht, einmal ein einfaches Spiel mit Scratch gebastelt zu haben, wenn man es noch nie gemacht hat, und dann erst zu Godot zu gehen. Denn die Oberfläche muss man ja auch erst mal kennenlernen. Für dieses Godot-Block-Coding da habe ich sogar so ein bisschen mitgeholfen bei der deutschen Übersetzung, nämlich, Und mit einigen launischen Anmerkungen. Ja, es gibt da zum Beispiel ein Simple Spawner-Node. Das heißt, das setze ich da einfach hin und dann sage ich hier so, einmal pro Sekunde soll da zum Beispiel ein Komet, ein Asteroid rauskommen. Ein Asteroid mit der Anfangsgeschwindigkeit, den gebe ich dann in der Anfangsgeschwindigkeit, zack. Und schon habe ich Asteroiden, einen Asteroidenschwarm, der mir entgegenfliegt. Ein Simple Spawner-Node. Das simple Spawner-Node kann man aber nur mit einem Block-Skript aktivieren. Also es gibt kein Häkchen-Kästchen im Inspektor, womit man das aktivieren kann. Ist also total umständlich, total unnötig umständlich. Solche Anmerkungen habe ich da dann zum Beispiel mal gemacht. Wenn ich mal Zeit habe demnächst, dann wollte ich auch mal bei Block-Coding weiter, also auch mitentwickeln. Zum Beispiel solche Sachen eben. Das ist ja eine ganz kleine Änderung nur. Ich bin nur noch nicht dazu gekommen. Also ich sehe dieses Block-Coding als, sehr gute Einsteigermöglichkeit für Godot. Es ist halt nur noch nicht so sehr bekannt. Es gibt also auch noch nicht so viele Tutorials damit. Und es entwickelt sich auch recht schnell weiter. Das heißt, wenn man Pech hat und ein Tutorial findet, dann ist es veraltet und das, was da beschrieben wird, gibt es gar nicht mehr oder heißt anders. Also da sind wir jetzt gerade in einer sehr dynamischen Phase, da muss man so ein bisschen Leidensfähigkeit und Bastelinteresse mitbringen, wenn man das ausprobieren möchte. Aber dann kann man da durchaus, also ohne zu coden, dann schon sehr viel machen. Man kann ja ohnehin bei Godot auch schon, ohne wirklich Code zu schreiben, sehr viel machen.

47:09

Christian Wie kam dann die Idee, ein Godot-Buch zu schreiben, insbesondere jetzt für vielleicht Kinder oder Jugendliche? Kam das eher von Verlagsseite oder bist du auf den Rheinwerk Verlag zugegangen und hast gesagt, ich habe hier mal eine Idee, was haltet ihr davon, das und das wäre doch toll zu haben? Wie ist das entstanden?

47:28

Uwe Ja, das entstand so eigentlich aus der Diskussion heraus. Also es gab die Idee, weil Godot eben im Aufwind war, ein Godot-Buch zu machen. Und wir haben uns dann überlegt, es gibt jetzt einfach nicht so viele Godot-Entwickler. Das heißt, wenn man jetzt einfach ein Godot-Handbuch schreiben würde, also das einfach komplett alles ziemlich trocken erklärt, das würde wahrscheinlich keine besonders hohe Auflage erreichen. Und dann haben wir uns überlegt, gut, wir sprechen speziell Jugendliche an, die machen das Buch ein bisschen preiswerter, kostet 25 Euro und ist jetzt kein dicker Wälzer für 40 oder 50. Und es ist bunt, dann wünschen die sich das zu Weihnachten oder so. Das ist ein Stück weit auch aufgegangen, denke ich. Also dadurch lohnte sich das einfach mehr, das so rauszubringen. Im Moment zumindest ist es eine Nische. Spiele programmieren ist ohnehin eine Nische. Und dann Spiele programmieren mit einer relativ neuen Engine ist eine Nische in der Nische, muss man ja ehrlich sagen.

48:43

Christian Okay. Das heißt, die Zielgruppe sind ganz klar Leute, Leute, die noch kaum Entwicklungserfahrung haben, die drangeführt werden sollen. Wie hast du dann die Inhalte des Buches geplant? Also hast du dich dann hineinversetzt in jemanden, der kaum programmieren kann, dass gesagt, okay, ich setze mich hin und ich kann eigentlich überhaupt nicht programmieren. Was müsste ich eigentlich in welcher Reihenfolge lernen? Oder wie war dann dein Prozess gewesen, dich hineinzuversetzen in die Person, die quasi ein unbeschriebenes Blatt ist und die am Ende dann ein kleines Spiel entwickeln soll. Wie gehst du als Autor oder als Fachautor da vor, so was darzulegen, so einen roten Faden, so von Null auf am Ende steht ein Spiel? Wie gehst du da vor?

49:35

Uwe Ich hatte einen wichtigen Aspekt, nämlich ich wollte es so machen, dass die ... Die Menschen, die vielleicht ein richtiges Handbuch wollten, dass die auch einen Mehrwert aus dem Buch haben, die können einfach die ersten paar Abschnitte überspringen, wenn sie sagen, ah ja, ich finde mich da bestimmt schnell zurecht, ich muss jetzt nicht mit Scratch rumfummeln. So, und dann ist es so, dass ich mal wieder einen Vorteil hatte durch etwas, was ich in den vergangenen Jahren öfters mal gemacht habe, und zwar Spiele programmieren, Workshops programmieren mit der Maus. Für den WDR. Also die WDR-Maus. Und zwar gibt es, ich glaube, das gibt es auch immer noch, programmieren-mit-der-maus.de, das ist eine Maus-Variante von Scratch. Also gebrandet mit der Maus und dem Elefanten. Das heißt, man hat nicht diese kleine Katze von Scratch, sondern man hat die Maus und man kann die rumhüpfen lassen und dergleichen. Und wir haben halt als ganz, ganz niedrigschwelliges Angebot, das für Kinder, sogar Grundschulkinder, angeboten, in Zusammenarbeit mit WDR eben als Workshops und da hat sich jemand anders als ich schon vorher so ein paar Beispielspiele überlegt. Und zwar, also das war auch sehr, sehr vernünftig durchdacht und da habe ich mich im Prinzip ein bisschen nachgerichtet. Es fängt ganz einfach an, mit Luftballons, die platzen. Es erscheinen Luftballons, man klickt drauf und es macht Pop und der Luftballon platzt. Total simpel, aber es gibt zumindest einen kleinen Effekt und es macht Spaß und wichtig ist. Es muss bunt sein. Also ich habe da sehr viel Erfahrung gesammelt mit den Kids. Wenn ich dann mit denen das da gemacht habe oder ich habe denen zugeguckt, wie die da was gebastelt haben und ich habe ja auch deren Reaktion bemerkt. Ich habe sehr, sehr viel Erfahrung gemacht, damit zu sehen, wo haben die ihre Schwierigkeiten, wo haben die Verständnisschwierigkeiten und was macht denen Spaß. Und daraus konnte ich das eben sehr gut zusammensetzen. Und dementsprechend habe ich die Beispiele zusammengebastelt. Also am Anfang eben was Lustiges, was Buntes. Und dann hinterher, wenn es zu Godot geht, dann der Weltraum, der arme Astronaut, der den Asteroiden ausweichen muss. Und hinterher ist er im Raumschiff. Und da sind dann Aliens, denen er ausweichen muss. Und so was. Gefräßige Aliens, die komische Geräusche machen. Also es ist schon, kindgerecht fast, kann man sagen. Es ist schon wichtig, dass man darauf Rücksicht nimmt, dass das Ganze auch Spaß macht. Es soll ja Spaß machen.

52:19

Christian Wenn ich mal zurückkomme zum Anfang des Gesprächs, wo du gesagt hast, du legst dir für eine Kurzgeschichte eine Reihenfolge vor von Ereignissen, was passieren soll. Im Prinzip hast du das ja für das Fachbuch genauso gemacht. Also das heißt, du bist bei einer Gliederung angefangen, hast dir ganz genau überlegt, was möchtest du an welcher Stelle schreiben und erst als du fertig warst, dann hast du geschrieben. Oder hat sich während des Schreibens tatsächlich noch einiges verändert, wo du gesagt hast, oh, jetzt wo ich das so schreibe, merke ich eigentlich müsste ich das und das aber mal davor schreiben. Oder brauchtest du das gar nicht, weil durch diese Gliederung, die war so gut, dass du eigentlich nur noch runterschreiben musstest?

52:55

Uwe Ja, also die Gliederung ist auch bei so einem Buch natürlich wahnsinnig wichtig, dass die Lernkurve langsam steigt, dass man immer mal ein bisschen noch Spannung reinbringt, denn zu einem guten Spiel gehört ja auch Handlung. Eine gute Handlung, eine motivierende Handlung. Und gerade zum Beispiel bei diesem Astronauten, da habe ich mir dann eben so eine kleine, nur ein paar Zeilen so eine kleine Teaser-Geschichte überlegt. Und um das Ganze mit ein bisschen Leben zu füllen. Und die ganze Struktur, die ganze Gliederung des Buches, ist eben so aufgebaut, dass ja im Grunde auch wie eine Handlung, dass es spannender wird, dass neue Aspekte hinzukommen, wie dann hinterher zum Beispiel die Aliens, die sich dann selbst bewegen und das Raumschiff, das man dann selbst basteln kann aus Einzelteilen, so wie man es gerne möchte. Das regt dann auch zum Experimentieren an und zur Kreativität an. Und das finde ich ganz wichtig. Klar, zwischendurch dachte ich, ah, jetzt könnte ich hier doch auch noch, das hatte ich vergessen, da könnte ich doch noch hier einen kleinen Aspekt reinbringen, noch eine kleine Idee reinbringen. Zum Beispiel, dass diese Aliens sich unterschiedlich schnell bewegen oder so. Ja, und dann baue ich das eben ein, aber ich mache keine grundsätzlichen Änderungen. Es ist keine grundsätzliche Änderung an der Struktur mehr. Das ist eigentlich noch nie nötig gewesen.

54:20

Christian Das heißt, jetzt aktiv ist auch wirklich eine Neuauflage des Buches geplant mit den Änderungen zum Beispiel, was jetzt Blockly oder Scratch angeht, dass du das umschreibst. Wie sieht da der Fortgang aus? Also hast du da schon einen Zeitpunkt, wenn die Neuauflage erscheinen soll oder ist das alles noch im Fluss?

54:40

Uwe Nee, das ist offen. Also wann das erscheint, ist offen. Wir müssen gucken, wann halt die erste Auflage abverkauft ist oder abverkauft sein wird. Man fängt ja mit der zweiten Auflage dann schon vorher an und dann geht das los. Also ich denke mir, irgendwann im Laufe des Jahres wird es damit losgehen. Ich verfolge natürlich auch die Entwicklung von Godot. Das ist ja alles dynamisch. Also ich hoffe, sie machen kein großes grundsätzliches Update mehr, wo sie viele Dinge auf einmal ändern, weil da muss sich auch viel im Buch ändern. Das ist immer ein bisschen anstrengend. Ja, aber erstmal habe ich noch ein paar andere Projekte und dann kommt das irgendwann.

55:21

Christian Gut, dann würde ich dich als allerletzte Frage oder würde ich zum Ende kommen und eine Frage nochmal stellen, die jetzt an neue Autoren geht. Was würdest du Fachbuchautoren raten, die gerne ein Buch veröffentlichen würden? Was für Tipps hast du?

55:39

Uwe Ich erwähnte ja vorhin diese professionelle Einstellung und zu der gehört als allererstes, eine Fachbuchveröffentlichung. Selbst wenn es so viel Spaß macht, sie zu schreiben wie bei so einem Godot-Buch oder meinem Elektrotechnik-Buch oder so, das macht man ja nicht nur aus Spaß an der Freud. Das heißt, man möchte hinterher einen wirtschaftlichen Erfolg haben und deswegen muss man sich sehr genau fragen, wer ist die Zielgruppe, was sind die Bedürfnisse der Zielgruppe, wie kann ich diesen Bedürfnissen. Am besten so nah wie möglich kommen und ja, das geschieht natürlich auch in Absprache mit dem Verlag. Also es ist ja immer so, also auch egal, ob jetzt der Verlag auf mich zukommt oder ich auf den Verlag zugehe mit einem Konzept, wir überlegen da gemeinsam, welche Inhalte sind die wichtigsten, welcher Umfang ergibt sich dann daraus, teilweise eben auch welcher Detailgrad. Wie weit geht man ins Detail, wie weit wird man technisch. Ähm, denn gerade in der IT ist es ja so, dass es nun zum Berufsbild des Entwicklers auch dazu gehört, selbst zu lernen und sich selbst Sachen rauszusuchen, ne, also ein, ein umfassendes Handbuch zum Beispiel hat natürlich die Anforderung, dass da wirklich alles, auch in jedem Detail und auch mit, für jedes, für jedes Detail ein Beispiel drinsteht, Aber in so einem Buch wie dem Spieleprogrammierung mit Godot kann ich natürlich auch an einer Stelle mal sagen, so, und, wenn du das noch ein bisschen besser, noch ein bisschen mehr verbessern möchtest, noch ein bisschen ausbauen möchtest, dieses Spiel, dann schau dir doch mal diese Tipps an. Schau dir mal an, das könntest du noch machen, das könntest du noch machen. Verweis auf die offizielle Dokumentation. Die ist ja auch zum großen Teil eingedeutscht. Das ist ganz gut zugänglich. Und dann kann man sich da noch ein bisschen selbst mit beschäftigen. Dann wird das Buch dünner, dann brauche ich nicht so lange zum Schreiben. Der Verkaufspreis wird niedriger und dementsprechend greifen vielleicht mehr Leute zu. Das sind alles Aspekte, die man sich sehr gut überlegen muss und ein gutes Gesamtpaket schnüren muss in Zusammenarbeit mit dem Verlag. Und dann wird es auch ein Erfolg.

57:58

Christian Ja, ich erinnere mich auch, dass eine der ganz frühen Fragen mit dem Verlag immer sind, was ist die Zielgruppe? Das ist tatsächlich eine super zentrale Frage. Wen adressiere ich? Sind es Einsteiger? Sind es Hobbymenschen? Sind es Profis und wie gehe ich damit um, dass ich nicht alles bis zum Letzten beschreiben kann. Also ich finde es auch ganz gut, moderne Bücher, also ein bisschen so wie Webseiten zu behandeln mit Verweisen. Ich glaube, das hat man früher nicht so häufig gemacht.

58:26

Uwe Ja, ganz genau. Man kann sogar QR-Codes reinmachen, wenn man möchte. Das haben wir jetzt, glaube ich, an ein, zwei Stellen im Elektrotechnik-Buch mal gemacht. Das Smartphone haben die Leute griffbereit und können da halt mal reinschauen. Und übrigens die Zielgruppe, die Frage nach der Zielgruppe, ist nicht nur bei Fachbüchern von zentraler Bedeutung, auch natürlich bei Romanen. Wenn ich einen Roman schreibe, der ein wahnsinnig spezielles Thema hat, dann wird er eine sehr kleine Zielgruppe haben. Dementsprechend schlecht wird er sich verkaufen. Und auch bei Kurzgeschichten sogar. Da kommt es einfach an, wo ich die veröffentliche. Das Einfachste ist, wenn ich eine Kurzgeschichte für das c't-Magazin schreibe. Weil da ist die Zielgruppe c't-Leser. Ganz einfach.

59:06

Christian Gut, ja. Dann danke ich dir ganz herzlich für dieses schöne Interview, Uwe. Und was verbleibt mir nur noch zu sagen, viel Erfolg mit deinen neuen und kommenden Fachbüchern und auch mit deinen Romanen. Herzlichen Dank.

59:20

Uwe Ja, danke schön.

59:21

Christian Tschüss.