Wie ich programmieren in zehn Monaten lernte

Etwa zehn Monate vor dem Erstellen dieses Artikels habe ich beschlossen mir beizubringen, wie man programmiert. Ich traf diese Entscheidung kurz nachdem ich an der Hochschule meinen Abschluss in BWL gemacht hatte und meine Karriere plante. Ich wägte viele Möglichkeiten ab und beschloss schließlich mir selber beizubringen, wie man programmiert, weil ich ausprobieren wollte etwas zu lernen, dass nur eine kleine Minderheit der Gesellschaft versteht. Meine ersten Eindrücke im Bereich Programmierung sammelte ich während meiner Schulzeit in Game Editoren wie beispielsweise der Aurora Engine. Ich wendete damals aber nie die Zeit auf, um die notwendigen Grundlagen vollständig zu lernen.

Anfangs war ich wie jede durchschnittliche Person von der Komplexität eingeschüchtert, aber nach dem ich an der Thematik dran blieb merkte ich schnell, dass programmieren nicht schwieriger ist als das Erlernen einer neuen Fremdsprache. Programmieren ist zeitaufwendig und nicht etwas, dass man sich an einem Tag, einer Woche oder in einen Monat beibringen kann. Ist man aber der Typ Autodidakt, der niemals aufgibt, ist Programmieren großartig und motivierend, da Fortschritte deutlich fühlbar sind und sich durch diese permanent neue Möglichkeiten ergeben. Etwas wie Programmierung auf eigene Faust zu erlernen ist nichts für jeden. Man muss es wirklich wollen und eine zwanghafte Obsession entwickeln, da man häufig auf scheinbar unlösbare Probleme stoßen wird. Wenn Du gerade selber erst anfängst Dir programmieren beizubringen, und auf der Suche bist, wie man ein Selbststudium gestaltet, hoffe ich, dass Dir dieser Artikel eine Hilfestellung oder Anregungen geben kann.

Ich begann damit ein paar Kurse an der örtlichen VHS zu belegen, um grundlegende HTML und CSS Kenntnisse zu erlangen. Dies war mit Abstand der teuerste Teil meines Selbststudiums mit ein paar Hundert € je Kurs. Doch diese hohen Kosten hatten auch einen positiven Nebeneffekt. Denn ich fühlte ich mich gezwungen, jede Stunde zu besuchen und die Hausaufgaben zu erledigen, weil ich einen Gegenwert für mein Geld bekommen wollte.

Bereits nach den HTML Kursen erkannte ich, dass ich meine Ansichten über die Komplexität der Erstellung von Webseiten überdenken muss. Ich wusste es nicht einmal, aber ich kannte die meisten der Grundlagen von  HTML bereits und das nur durch das regelmäßige Nutzen des Internets. Wenn Du darüber nachdenkst, einen ersten Kurs zu besuchen, dann solltest Du mit HTML beginnen, damit du erste Einblicke in die Struktur und Funktionsweise des Internets bekommst. Nach dem Abschluss meiner VHS Kurse, wurde mir klar, dass ich jede Computersprache lernen kann, wenn ich ausreichend Zeit aufwende.

Ich entschloss mich nach den HTML- und CSS-Kursen, Ruby / Ruby on Rails als meine erste echte Programmiersprache auszuprobieren. Ich entschied mich für Ruby, weil die Syntax von Ruby (angeblich) leichter zu lesen und zu schreiben als bei anderen Sprachen ist. Ich begann mit YouTube-Tutorials und stieß dann auf die Lynda.com Ruby on Rails-Video-Tutorials (die in der Regel OK sind). Ich verbracht etwa einen Monat damit dort Videos zu gucken und einige Programme zu schreiben, aber irgendetwas schien mir dort zu fehlen. Denn ich verstand das Material nicht so schnell wie ich hoffte. Das war etwa 2-3 Monate nachdem ich mit dem Programmieren begann. Doch ich lies mich nicht entmutigen, raffte mich auf und entschied mich schließlich dazu, meine Lernbemühungen woanders fortzusetzen.

How to learn to code
Ich stieß auf Codecademy; eine Learn-to-Code Website mit diversen Kursen. Ich kämpfte mich sofort durch den größten Teil der verfügbaren Kurse. Meiner Meinung nach ist Codecademy ein ziemlich guter Ort um zu lernen. Vor allem die API- und HTML Kurse sind sehr empfehlenswert. Etwa zur gleichen Zeit begann ich auch Kurse bei Treehouse und Code School und habe direkt die meisten der Ruby on Rails-Kurse auf beiden Websiten abgeschlossen. Ich belegte ebenfalls andere Kurse wie HTML, CSS und PHP. Ich würde sagen, dass beide Websites vom Konzept her zwar ähnlich sind, aber den Lernprozess auf unterschiedliche Weise ergänzen. Treehouse beispielsweise ist hervorragend für Anfänger und Leute mit wenig Erfahrung und die Treehouse Lernplattform ist die ausgereifteste von allen. Insbesondere die Treehouse Instruktoren sind erstklassig. Sie gestalten die Kurse intuitiv, motivierend und sind darüber hinaus permanent ansprechbar im Treehouse Forum.  Die Beantwortung von Fragen, das anbieten von Hilfestellung und Feedback an Teilnehmer geschieht fast immer zeitnah.

How to learn to code

Codeschool  hingegen richtet sich – wie ich später feststellte – an Fortgeschrittene. Anfangs fand ich Codeschool deshalb nicht so gut, da ich die Kursen nicht wirklich verstanden habe. Aber nach ein paar Monaten mit Treehouse und den dort angeeigneten Grundkenntnissen habe ich gemerkt, dass Codeschool gut ist, sobald man versteht wie man programmiert bzw. über solides Grundwissen verfügt. So wird in Codeschool Kursen mehr Lernstoff in weniger Zeit durchgesprochen als bei Treehouse. Aber sinnvoll strukturiert und aufeinander aufbauend.  Ich werde später nochmal detaillierter auf beide Webseiten eingehen, da diese beiden Webseiten einen großer Teil dazu beigetragen haben,  dass ich so schnell programmieren lernte.
Ich hatte nun etwa 6 Monate Bullemie Lernen hinter mir und fing an  Web-Design sehr gut zu verstehen. Ich war in der Lage HTML und CSS effizient zu lesen und zu schreiben, doch meine Ideen mit Ruby on Rails umzusetzen fiel mir immer noch schwer. Ich bin mir nicht sicher, warum ich mich auf Ruby on Rails so fokussierte, aber heute weiß ich, dass das einer der Fehler war den ich beim gestalten meines Selbststudiums machte. Zu dieser Zeit fing ich an, einige Nebenprojekte für ein paar meiner Freunde umzusetzen, die ihr eigenes Unternehmen gestartet hatten. Diese Projekte zwangen mich, JavaScript und PHP anzuwenden. Aber da ich immer noch auf Ruby fokussiert war, befasste ich mich nur so weit mit JavaScript und PHP wie es für die Arbeit nötig war. Trotzdem bemerkte ich bereits, dass ich diese Sprachen besser als Ruby verstand. Ich kam außerdem zu der  Einsicht, dass wenn ich wirklich etwas lernen will, damit anfangen muss mich außerhalb der Kurse mit den Programmier Sprachen zu befassen. Am besten in dem ich etwas baue, an dem ich wirklich Interesse habe. Denn ich hatte nun zwar alle Grundlagen gelernt, aber diese nicht angewendet und somit noch nicht verinnerlicht.

Nachdem ich die Projekte für Freunde abgeschlossen hatte, begann ich die Arbeit an einem meiner Nebenprojekte von der Hochschule. Innerhalb eines 2 Wochen Sprint hatte ich die Website die ich damals erstellt hatte, vollständig in etwas verwandelt, das tatsächlich einer echten Web-Anwendung ähnelte. Ich war nun auch in der Lage, Ideen die ich hatte, in Code zu schreiben und zu erkennen, wie sie funktionieren. Das war eine ziemlich aufregende Zeit und mein Tagesablauf sah meistens so aus, dass ich um 7 Uhr aufgestanden bin und bis 2 Uhr morgens programmierte.

Ich entschied mich schließlich dazu, dass ich eine persönliche Website benötige,  um kleine Programmideen zu üben. Eines der Projekte war beispielsweise, die Schaffung einer Abzeichen Widget, die automatisch meine Fortschrittsberichte aus den Online-Schulen, mit denen ich lernte, zieht und zu einem progress report verarbeitet. Ich war immer noch nicht wirklich gut in Programmierung, also begann ich es in nur statischer HTML und CSS.

1

Ein paar Wochen später bekam ich die Einladung zu einem Vorstellungsgespräch bei einer größeren IT Firma. Ich muss zugeben, dass ich das Gespräch nicht wirklich ernst nahm, da ich mir keine großen Chancen ausmalte. Dass lag daran, dass ich nun mal keinen Informatik-Abschluss besitze. Sondern nur etwa 8 Monate Autodidakt Bildung vorweisen kann. Aber ich dachte mir, dass es nicht schaden würde hinzugehen, um zu sehen, wie ein „Tech-Interview“ abläuft. Ich zeigte ihnen mein bisheriges Portfolio der Arbeit, die ich verrichtet hatte und die verschiedenen Projekte an denen ich selber gearbeitet hatte. Offenbar war ich gut in dem Interview, denn sie boten mir direkt ein größeres Gehalt an, als das um das ich gebeten hatte. Ich hatte nun 7 Tage Zeit den Job an- oder abzulehnen, also begann ich hektisch herauszufinden, was zum Teufel ich eigentlich tun wollte. In diesen 7 Tage ging ich zu einem anderen Vorstellungsgespräch dass mir ein Freund vermittelt hatte und hätte dort ebenfalls starten können. Sie übertrafen dort mit ihrem Angebot sogar das vorherige der anderen Firma. Innerhalb von 7 Tagen hatte ich es nun geschafft, zwei richtig gute Job Angebote zu bekommen und das nur durch Referenzen aus meinem Selbststudium. Ich nahm direkt eines der Angebote an.

Ich vermute ich habe meinen Job bekommen, weil ich durch mein Portfolio zeigen konnte, dass ich hungrig bin zu lernen und eine große Portion Eigeninitiative und Ehrgeiz besitze. Es macht mich wirklich Glücklich, dass ich mich jetzt in einer Tech-Firma einbringen und meine Erfahrung ausbauen kann.
Parallel führe ich mein Selbststudium auf meiner Website immer noch weiter, aber für ein Unternehmen zu arbeiten fördert mein Verständnis für Programmierung vergleichsweise mehr. Zum einen aufgrund meiner Kollegen, die bereit sind zu helfen. Zum anderen da meine Arbeit mich zwingt, Lösungen außerhalb der Programmiersprache Ruby zu suchen. Ich Code nun meist in PHP und JavaScript und ich wünschte ich hätte mit JavaScript gestartet.

Abschließend werde ich sagen warum:
Anfangs habe ich beschlossen das Ruby die beste Sprache für mich ist, wegen der scheinbar einfachen Syntax. Aber um Ruby größere Projekte zu verwirklichen wird ein gutes Verständnis für die Theorie von Programmierung und des Rails-Framework vorausgesetzt. Vor allem wenn Programmiergrundlagen fehlen, hat Ruby on Rails eine steile Lernkurve. Nun mögen manche argumentieren, dass Ruby on Rails die Programmierung vereinfacht und Entwicklern Zugriff auf eine Menge vorgefertigten Code gibt (Ruby Gems), doch diese können nicht genutzt werden, ohne grundlegende Kenntnisse. Und es erfordert eine Menge an grundlegenden Kenntnissen damit Ruby on Rails beginnt so zu arbeiten, wie man es will.

JavaScript hingegen, ist mit der Einführung von HTML5 (=HTML, CSS / CSS3 und JavaScript), De-facto die „Programmiersprache des Web“ und offizielles Programmier „Rückgrat“ des Internets. JavaScript benötigt auch nicht die Menge an Vorarbeit wie Ruby, sondern kann buchstäblich innerhalb von Sekunden in der Browser-Konsole gestartet werden. Vor allem die JavaScript-Bibliothek jQuery macht es wirklich einfach, Grundprogrammierung in JS zu starten, und wenn man ein wenig CSS kennt, ist man in der Lage, jQuery ziemlich schnell zu verstehen. Anfangs war ich zwar von all den [{Klammern}] und Semikolons eingeschüchtert, aber nach ein paar Wochen hat man diese während der Verwendung der Sprache verinnerlicht. Ich denke immer noch, dass Ruby on Rails eine in der Regel leistungsfähige (serverseitig) Sprache und Framework ist. Aber JavaScript wäre aufgrund der zuvor genannten Gründe die bessere Wahl gewesen, um mit dem Lernen zu beginnen. Ich habe immer noch vor, bald zu Ruby on Rails zurückzukehren um den Lernprozess abzuschließen.  Aber jetzt, wo ich tatsächlich die Grundlagen der Programmierung verstanden habe glaube ich nicht, dass Ruby on Rails noch so schwer zu erlernen sein wird.

 

 

Lehren Aus Doom

Im Gamedesign ein ambitioniertes Ziel zu verwirklichen, wie „die Grenzen des Mediums zu erweitern“, bedeutet nicht zwangsläufig, dass man unbekannte neue Wege einschlagen muss. Manchmal ist es hilfreicher sich mit erfolgreichen Titeln aus der Vergangenheit auseinanderzusetzen. Diese mögen zwar technisch veraltet sein, können aber trotzdem über einige Interessante Ansätze verfügen, die der Inspiration dienlich sind. Der Titel auf den ich anspiele ist Doom. Nicht das Reboot von 2004, sondern die Klassiker: Doom 1, Doom 2, Final Doom und die Master Level, einschließlich der vielen Inhalte, die die Community erstellte. Welche Lehren kann man aus diesen Titeln ziehen?

Doom fühlt sich mehr wie ein 1st-Person Robotron an, als wie ein moderner Ego Shooter

e4m9

Spielt man heute Doom, entsteht nicht wirklich der Eindruck, als würde man einen Menschen steuern, oder sich durch eine reale Welt bewegen. Probiert folgendes aus: Öffnet die Konsole mittels Tab, tippt zweimal „IDDT“ ein und stellt Euch vor, Ihr würdet Geometry Wars spielen. Die Dreiecke die sich bewegen, sind Eure Kontrahenten. Die Programmierer nutzten 1993 diese Ansicht zum arbeiten. Damals waren Ego Shooter noch Neuland und Spiele die konzeptionell die größte Ähnlichkeit aufwiesen, waren 2D Shooter wie Robotron und Tempest. Deshalb sind Ansätze dieser Spiele im Design von Doom zu finden. Realismus spielte im Design von Ego Shootern zur damaligen Zeit keine übergeordnete Rolle. Stattdessen war alles erlaubt, was dem Gameplay dienlich ist. Die Folge daraus war, das auch die Umsetzung abstrakter Ideen als legitim angesehen wurde.

Ein positiver Effekt den diese Entscheidung mit sich brachte ist, dass sich das Gameplay von Doom – wenn man einen Vergleich mit modernen Titeln anstrebt, die ebenfalls ein schnelles Gameplay besitzen und dem Spieler schnelle Entscheidungen und Reaktionen abverlangen („Twitch Games“) – selbst heute noch gut anfühlt. Doom schaffte es, die Geschwindigkeit und Bewegungsmuster der Feinde fein auf das Waffendesign und das Movement des Spielers abzustimmen. Das Leveldesign wiederum bot den passenden Rahmen für diese Einflussfaktoren.

Quake 3 wird heute noch als der Maßstab für Bewegungs- und Spielgefühl eines Arcade-Shooters angesehen und die Ursprünge von Quake 3 liegen in Doom – denn der Quellcode von beiden Titeln weist Ähnlichkeiten auf.

Das Defensivverhalten in Doom basiert auf Wendigkeit und ausweichen

Moderne Shooter sind darauf ausgelegt, dass der Spieler sich langsam bewegt und Feinde Attacken einsetzen, die den Spieler nach der Ausführung direkt treffen (instant-hit), ohne das dieser eine Chance hat, auszuweichen. Damit das Spiel trotzdem zu bewältigen ist, kann der Spieler bis zu einer gewissen Menge Schaden absorbieren. Wurden Treffer eingesteckt, genügt es zum regenerieren in Deckung zu gehen und abzuwarten bis der Schaden vollständig geheilt wurde. Dieses System wurde erstmalig in Halo verwendet, wo der Charakter einen Schild besaß, der sich, wenn er einige Sekunden nicht benutzt wurde, automatisch wieder auflud. Ein Spiel das auf diese Mechanik zurückgreift, kann zwar auf regenerierende Power Ups verzichten, doch zwingt den Spieler dafür Pausen auf, die eingelegt werden müssen, um die Lebenspunkte automatisch wieder herzustellen.

Der Doom Guy hingegen rennt nach heutigen Maßstäben mit wahnwitziger Geschwindigkeit durch die Level und muss keine Pausen zur Regeneration einlegen. Außerdem verwenden die meisten Feinde in Doom keine instant-hit Projektile und wenn doch, sind diese relativ Schwach. Projektile in Doom brauchen eine gewisse Zeit, um den Spieler zu treffen. Da dieser zudem wendig ist, ist ausweichen die logische Konsequenz. Mit etwas Übung, funktioniert das sogar gegen mehrere Gegner auf einmal. Das führt zu einer völlig anderen Perspektive auf das Spiel. In modernen Shootern fühlt man sich mächtig, da man wie ein Tank eine bestimmte Menge an Schaden verkraftet. In Doom hingegen ist die Agilität die Komponente, die dieses Gefühl entstehen lässt.

Aufgrund dessen ist es nicht ungewöhnlich, dass man in Doom mit einer riesigen Anzahl von unterschiedlichen Feinden zugleich konfrontiert wird. Diese sind häufig in weitläufigen Arealen platziert, die der Spieler völlig frei erkunden kann. So eine Konstellation gibt es heute nicht mehr.

Doom hat ein abwechslungsreicheres Bestiarium, als die meisten Shooter heutzutage

Doom Eye

Moderne Shooter haben ein relativ beschränktes Gegner Repertoire. Neben leicht bewaffneten Soldaten mit beispielsweise Shotguns und Mps, gibt es häufig noch Sniper und Nahkämpfer. Doom hingegen hat ein vielfältiges Bestiarium, dass Monster mit unterschiedlichen Stärken, Größen, Geschwindigkeiten und Angriffsmustern umfasst. Mutierte Menschen und Imps sind langsam und Kanonenfutter. Hell Barons sind sehr widerstandsfähig und besitzen sowohl Nahkampf, als auch Fernkampfangriffe. Zudem gibt es verschiedene Gegner die aus der Luft angreifen. Lost Souls sind schnell und setzen situativ zum Ansturm auf den Spieler an. Cacodemons hingegen sind zwar langsam, verfügen aber dafür über massig Lebenspunkte und ein schnelles Projektil. Revenants und Mancubi können Projektile abfeuern, die den Spieler verfolgen und Mehrfachschüsse einsetzen. Es gibt ausserdem noch drei Bossgegner, die allesamt über mehrere Attacken verfügen.

Die Vielfältigkeit an Gegnern, kam sowohl dem Spieler als auch den Level Designern zugute. Denn diese konnten das vorhandene Repertoire sowohl architektisch verwerten als auch beim Zusammenstellen von Gruppen, die sich gegenseitig ergänzen. Stellt man einer großen Gruppe an Kanonenfutter einen widerstandsfähigen Hell Baron zur Seite, muss sich der Spieler mit crowd control befassen, während er die echte Gefahr (Hell Baron) im Auge behält. Große Gruppen an fliegenden Gegner, werden den Spieler animieren Deckung zu suchen, oder eine Engstelle (z.B. Tür) als Angriffspunkt einzusetzen. Nahkämpfer hingegen werden am besten in der Rückwärtsbewegung mit starken Kurz-Distanz Waffen (Schrotflinte) bekämpft. Diese Vielfältigkeit an Möglichkeiten hilft den Leveln Designern bei Ihrer Arbeit und macht sowohl Spielern als auch Entwicklern mehr Spass.

Doom war zwar abstrakt, doch das Leveldesign profitierte davon

Doom First Level

Hin und wieder haben einige von Dooms Leveln ein bisschen Fiktion in Ihrem Titel (z.B. „Hangar“) und verwenden einen dazu passenden Artstyle, z.B. bei den Texturen. Schaut man sich das Level jedoch genauer an, wird man wenige Orte finden, die den Titel tatsächlich repräsentieren bzw. die gewählte Thematik widerspiegeln. Das ist auch genau der Grund, weshalb die Level Designer sich auf das Kernelement des Spiels konzentrieren konnten – die Kämpfe. Es gab keinen Grund, sich künstlerisch einzuschränken und krampfthaft zu versuchen, etwas zu gestalten, dass wie ein Hangar aussieht. Von dieser gestalterischen Freiheit profitierte das Gameplay. Mit dem technischen Fortschritt und dem reifen des Genres, wurde es zur Normalität die Umgebung an die Thematik des Spiels anzupassen. Spiele wie System Shock zeigten zwar, dass ein stimmig gestaltes Level ein echter Anziehungspunkt sein kann, da beim Spieler durch die Atmosphäre Immersion entsteht. Doch der Designer muss sich dafür dem Interesserenkonflikt zwischen optimaler Funktionalität und überzeugender Fiktion stellen, da letztere Einschränkungen mit sich bringt.

Doom war ein Revolutionär, was von Spielern erstellten Content angeht

Obwohl die Technik von Doom seinerzeit state-of-the-art war, war sie trotzdem einfach zu bedienen. Das führte zu der Bildung einer riesigen Mod-Community, die das Spiel mit frischen Leveln, Modifikationen, Conversions und Add ons versorgten. Die Lektion daraus ist einfach. Gebt den Spielern eine einfach zu nutzende und zu modifizierende Technologie an die Hand und diese werden es Euch mit haufenweise Inhalten zurückzahlen, die der Franchise und dem Marketing zu gute kommen.

Es gibt viele Spiele heutzutage die dem Spieler die notwendigen Mittel an die Hand geben. Doch die Einstiegshürden sind aufgrund des gestiegenen Aufwandes viel zu hoch. Es ist wesentlich schwerer jemanden zu finden, der beispielsweise einen Mod für Unreal Tournament 3 entwickeln möchte, als jemanden der das gleiche für Doom vor hat. Eine Karte in Doom zu erstellen dauerte je nach Größe ein paar Stunden oder Tage. In der selben Zeit könnt Ihr für ein modernes Spiel, vielleicht eine einzige hochwertige Textur erstellen. Deshalb sollte abgewägt werden, ob es wirklich zwingend erforderlich und dem gameplay dienlich ist, eine hochglanz Optik zu verwenden,

Ein netter Nebeneffekt von Dooms Simplizität ist übrigens, dass es Level Generatoren gibt, die relativ solide und ausbalancierte Karten automatisch erstellen.

Fazit:

Doom ist heute ein echter Klassiker, dessen weniger offensichtlichen Qualitäten viel zu selten im modernen Gamedesign Anwendung finden.