Anmelden
Vor kurzem hat mich bei Twitter jemand nach Tipps gefragt, um ein besserer Software-Entwickler zu werden. Dieser Blog-Post soll dafür sorgen, dass nicht nur einer von den Ideen profitiert. Der Beitrag erhebt nicht den Anspruch vollständig zu sein. Wer also weitere Ideen hat: Ich freue mich über Kommentare!
Software-Entwickler definieren sich oft über die Programmiersprache oder das Framework, das sie nutzen. Ich finde das eigentlich schade, denn beides sind nur Werkzeuge. Eigentlich sollte ein guter Entwickler mehrere beherrschen. Alle Tipps, wie man eine Programmiersprache oder ein Framework lernt, würden den Umfang des Blog-Beitrags sprengen.
Dennoch ist das Erlernen neuer Sprachen sicherlich sinnvoll. Das führt mich zu meinem Buch-Tipp "The Pragmatic Programmer [1]" beziehungsweise "Der pragmatische Programmierer [2]". Es ist eine solche Sammlung von Tipps – und damit genau das richtige für diesen Blog-Beitrag. Das Buch ist zwar fast zwanzig Jahre alt, aber das zeigt gerade, wie grundlegend die Tipps sind. Einer der Tipps ist übrigens, jedes Jahr eine neue Programmiersprache zu erlernen.
Sicherlich gibt es weitere wichtige Bücher, aber der Austausch zwischen Entwicklern ist meiner Meinung nach noch wichtiger. Eine Möglichkeit, ganz praktisch voneinander zu lernen, sind Coderetreats [3]. Dabei üben die Teilnehmer ganz praktisch Techniken wie Refactoring, Pair Programming oder testgetriebene Entwicklung. Am 17. November ist der Global Day of Coderetreat, an dem Coderetreats weltweit [4] stattfinden. Vielleicht ist einer in der Nähe. Wenn nicht: Es gibt eine Anleitung [5], wie man einen eigenen Event auszurichten kann. Ähnliche praktische Lern-Events sind Code Katas [6], bei denen Entwickler gemeinsam Probleme lösen und so voneinander lernen und unterschiedliche Ansätze ausprobieren können. Beim Mob Programming [7] hingegen arbeitet das ganze Team gemeinsam an einem Problem im Code. Auch das stärkt den Austausch.
Solche Aktivitäten können Entwickler mit anderen Interessierten in der eigenen Firma umsetzen. Eine andere Möglichkeit sind die Softwerkskammern [8], in denen sich Gleichgesinnte treffen. Überhaupt findet man mittlerweile in vielen Städten Meetups [9] zu verschiedenen Themen aus der Software-Entwicklung. Und natürlich eine Vielzahl an Konferenzen.
Fehlen darf natürlich auch nicht der Hinweis auf einen älteren Blog-Post [10], der Fortbildungsmöglichkeiten im Bereich Software-Entwicklung nicht nur für Kinder und unterrepräsentierte Gruppen aufgelistet hat.
Soweit die kurze Übersicht – über Ergänzungen und Kommentare freue ich mich!
Entwickler lernen am besten voneinander. Dazu gibt es verschiedene Möglichkeiten.
URL dieses Artikels:http://www.heise.de/-4156718
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/The_Pragmatic_Programmer[2] https://www.hanser-fachbuch.de/buch/Der+Pragmatische+Programmierer/9783446223097[3] https://www.coderetreat.org/[4] https://www.coderetreat.org/events/[5] https://www.coderetreat.org/pages/hosting/hosts/[6] http://codekata.com/[7] https://en.wikipedia.org/wiki/Mob_programming[8] https://www.softwerkskammer.org/[9] https://www.meetup.com/[10] https://www.heise.de/developer/artikel/Mit-Code-und-Bildung-die-Welt-verbessern-3663044.html
Copyright © 2018 Heise Medien
Auf der IFA waren wieder viele c't-Kollegen unterwegs. Zwei von ihnen erzählen uns, was sie entdeckt haben und was auf uns zukommt.
Mehr Infos zu den heutigen Themen:
Dieselverbot in Frankfurt: https://heise.de/-4156155
Digitalsteuer?: https://heise.de/-4156027
KI vs. Weltwirtschaft: https://heise.de/-4155988
Abmahnung für Sony: https://heise.de/-4156240
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Weltweit werden immer mehr SSDs verkauft, der Absatz von Festplatten geht gleichzeitig zurück. Ob das Ende der Magnetspeicher naht, besprechen wir.
Mehr zu:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Free2Play und sonst nichts? Parallel zur Gamescom sprechen wir darüber, auf welche Spiele wir uns freuen können und welche Trends die Branche bewegen.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Ein c't uplink außer der Reihe: Gemeinsam mit den Kollegen von t3n haben wir über Technik-Trends von Machine Learning bis Blockchain gesprochen. Die Folge ist nur als Audio-Datei verfügbar.
In dieser Sonderfolge c't uplink geht's um Trends, Hypes und IT-Journalismus. Gemeinsam mit den t3n-Chefredakteuren Luca Caracciolo und Stephan Dörner diskutieren Achim Barczok und Jan-Keno Janssen vom c't-uplink-Team darüber, wie man in Redaktionen mit Technik-Hypes und Buzzword-Bingo umgeht. Wie entscheiden t3n und c't, welche Themen man bei Heft- und Webseitenplanung nach vorne zieht?
Im zweiten Teil nehmen wir uns konkrete Trends vor: künstliche Intelligenz, Blockchain, Virtual und Augmented Reality, smarte Assistenten und Quantencomputer. Welche davon werden in den nächsten fünf Jahren besonders wichtig - da gibt's durchaus unterschiedliche Meinungen in der Runde.
Entstanden ist die Folge am 14. August 2018 auf der Up-date-Konferenz des Ideenboulevards in Hannover. Vor Ort gab es nur Audio-Technik, deshalb gibt's dieses Mal kein Video.
Hier könnt ihr die Folge anhören (47 min):
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Alle früheren Episoden unseres Podcasts gibt es unter www.ct.de/uplink [9].
()
URL dieses Artikels:http://www.heise.de/-4144186
Links in diesem Artikel:[1] http://blog.ct.de/ctuplink[2] http://blog.ct.de/ctuplink/ctuplink.rss[3] http://blog.ct.de/ctuplink/ctuplinkvideohd.rss[4] https://itunes.apple.com/de/podcast/ct-uplink/id835717958[5] https://itunes.apple.com/de/podcast/ct-uplink-video/id927435923?mt=2[6] http://www.heise.de/video/thema/c%27t-uplink[7] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[8] https://www.facebook.com/ctuplink[9] https://www.ct.de/uplink[10] mailto:acb@ct.de
Copyright © 2018 Heise Medien
Vor über zwanzig Jahren konnte man bereits iterativ-inkrementelle Entwicklungsprozesse beobachten. Sie sind ein Vorläufer agiler Prozesse, die es mittlerweile auch seit mehr als fünfzehn Jahren gibt. Obwohl es Agilität bereits geraume Zeit gibt, ist bis heute die agile Transformation ein Thema. Oft klappt die Transformation auch nicht. Warum?
Agile Verfahren zielen darauf ab, ein erfolgreiches Produkt zu entwickeln. Sie gehen in Iterationen vor. Nach jeder Iteration können Kunden den aktuellen Stand des Produkts nutzen. So bekommt das Team Feedback, welche Features beliebt sind und wie man das Produkt weiterentwickeln kann. Auch das Risiko ist geringer als ohne Iterationen: Es ist jederzeit klar, welche Features in Produktion funktionieren und welche nicht. Ein minimales Produkt kann sehr schnell nach Projektstart live gehen, was das Risiko des Scheiterns und einer Fehlentwicklung weiter reduziert. Auf Basis der bisherigen Geschwindigkeit lässt sich abschätzen, wie viel geschafft ist und wie lange das Team für die weiteren Features brauchen wird. Dabei ist das Team zusammen erfolgreich. Nicht eine einzelne Person trägt die Verantwortung für das Projekt, sondern das gesamte Team.
Agile Methoden reduzieren also das Risiko, führen zu schnellen Erfolgen, ermöglichen eine realistische Planbarkeit und entsprechen einer modernen Teamorganisation. Bei so viel Vorteilen sollte Agilität sich eigentlich von selbst durchsetzen. Aber in der Praxis sind agile Transformationen leider eine Herausforderung.
Tatsächlich gab es ein Projekt, an dem der Autor beteiligt war, bei dem die Vorteile der Agilität plötzlich zu Problemen wurden. Agilität hätte durch die frühe Produktivstellung der Software und die Abschätzungen für den weiteren Aufwand frühzeitig offensichtlich gemacht, dass das Projekt deutlich länger brauchen würde als geplant. Eigentlich ist es gut, wenn dieses Risiko frühzeitig offensichtlich geworden wäre. Aber in dieser Organisation hätte das Risiko vermutlich zum Abbruch des Projekts geführt, weil das Team offensichtlich ja der Aufgabe nicht gewachsen ist. Ohne Agilität hat das Projekt zwar die ursprünglichen Ziele nicht erreicht, aber es ist mit einigen politischen Tricks dem Abbruch entgangen und hat zumindest Software in Produktion geliefert.
Das Problem ist nicht der agile Prozess, sondern der Umgang mit dem Feedback, das agile Prozesse liefern. Werden bei Problemen personelle Konsequenzen gezogen oder Projekte abgebrochen, statt das Problem zu analysieren und konstruktiv zu lösen, wie es eine agile Kultur fordert, dann kann es leider sein, dass Verschleiern von Risiken und Verzögerungen sowie politische Spiele die einzige Möglichkeit sind, um ein risikoreiches Projekt durchzuführen.
Ebenfalls hätte Agilität in diesem Projekt für die Karriere des Projektleiters zu Problemen geführt. Um weiterzukommen, müssen Projektleiter Projekte erfolgreich abschließen. Aber in einem agilen Projekt gibt es keinen Projektleiter. Niemand außer dem gesamten Team ist für den Erfolg oder Misserfolg verantwortlich. Das widerspricht klassischen Organisationen, bei denen Manager oder Projektleiter für den Erfolg der Teams verantwortlich sind und dafür auch belohnt oder bestraft werden. Dieses Verständnis muss sich für agile Prozesse grundlegend ändern. Agilität predigt die Verantwortung des Teams – und das auch völlig zurecht. Aber dieser an sich richtige Ansatz ist eben in einigen Organisationen nicht so einfach umsetzbar.
In einem anderen Projekt stieß eine agile Projektorganisation auf ein klassisches Produktdesign. Letzteres hat in Quartalsreleases gedacht, während die Projektorganisation alle vierzehn Tage neue Software bereitstellen konnte. Das Feedback der Nutzer zu den 14-tägigen Releases konnte nicht in die Produktplanung einbezogen werden. Oft wäre es möglich gewesen, zunächst ein Feature in einer einfachen Art zu implementieren und erst später das Feature vollständig umzusetzen. So hätten Nutzer das Feature frühzeitig ausprobieren können. Wenn es nicht erfolgreich gewesen wäre, hätte man die Investition in das Feature beenden können. Das ist wichtig, weil die Literatur ("Online Experimentation at Microsoft") [1] zeigt, dass Produktdesigner nur bei höchstens 30 Prozent der Fälle die Beliebtheit eines Features richtig einschätzen. Agilität erlaubt es, statt des Schätzens auf das Feedback der Nutzer zu setzen. Dazu muss sich aber das Produktdesign seiner schlechten Trefferquote klar sein und dann Feedback aufnehmen und einarbeiten.
Und schließlich sind die Motive der an einem Projekt Beteiligten unterschiedlich. Dienstleister wollen sicher den Erfolg des Projekts, aber sie müssen auch Geld verdienen, während Auftraggeber Geld sparen wollen. Die entgegengesetzten Ziele führen zu Konfliktpotenzial. Techniker sind oft mehr an Technologien als am Projekterfolg interessiert. Dazu gibt es auch einen Blog-Beitrag auf heise Developer [2]. Am Ende sind an einem Projekt eine Vielzahl an Personen beteiligt, die ganz eigene Motive haben. Ihnen kann der Projekterfolg sehr wichtig oder eher egal sein. Und manchmal sind einige Beteiligte am Misserfolg des Projekts interessiert, um die eigene Karriere weiterzubringen.
Agilität setzt dem ein Menschenbild entgegen, bei dem alle Teammitglieder am Erfolg interessiert sind. Das ist auch sinnvoll, denn wenn die Motive der Projektbeteiligten nicht stimmen, kann man wenig tun, um das Projekt dennoch zum Erfolg zu führen.
Die oben angesprochenen Probleme liegen in Kultur und Management. Organisationen müssten mit Problemen konstruktiv umgehen, die Rolle von Projektleitern überdenken, das Produktdesign agilisieren und ein positives und konstruktives Menschenbild fördern. Anders gesagt: Agile Prozesse funktionieren nur, wenn Umgebung und Kultur dazu passen. Wenn diese Bedingungen nicht passen, muss man sie ändern. Aber können Softwarearchitekten, Entwickler oder Projektleiter eine Organisation so grundlegend ändern? Auch für Manager sind Änderungen in der Kultur schwierig, denn die Kultur ist fundamental für ein Unternehmen als soziales Gefüge. Die Unternehmen sind mit ihren alten Vorgehensmodellen und ihrer Kultur meistens am Markt gut positioniert, sodass gar kein Druck zum Wandel besteht – schon gar nicht zu einem radikalen Kulturwandel, wenn es doch "nur" um ein Software-Entwicklungsprojekt geht.
Das Problem ist nicht auf Agilität beschränkt. Continuous Delivery treibt die häufige Produktivstellung von Software weiter. Microservices unterstützen Agilität und selbstorganisierte Teams. Wenn Agilität wegen der Kultur nur begrenzte positive Auswirkungen hat, dann gilt das auch für Continuous Delivery und Microservices. Und daher wäre es so wichtig, Agilität zum Erfolg zu machen und die Kultur zu ändern.
Lösung?
Wenn die Unternehmen den grundlegenden agilen Wandel in der Kultur nicht mitmachen, wird das Ergebnis ein mehr oder minder halbherziger agiler Prozess sein. Der Autor sieht jedenfalls keine Möglichkeit, Agilität auf diese Kulturen anzupassen. "Echte" Agilität ist aber leider die Ausnahme. Mit anderen Worten: Agilität funktioniert in der Mehrheit der Fälle nicht, und der Grund ist das Problem in der Kultur.
Und dann wird Agilität auch einfach zu oft falsch verstanden. Teilweise ist Agilität sogar zu "noch mehr Druck" geworden, wie zum Beispiel dieser Artikel auf Spiegel Online [3] zeigt. Das hat mit eigenverantwortlichem Team und konstruktivem Umgang mit Feedback nichts mehr zu tun.
Agile Transition wird auch in den nächsten zwanzig Jahren noch ein Thema bleiben und es wird weiterhin viele "agile" Projekte geben, die in Wirklichkeit eben nicht agil sind.
Vielen Dank an meine Kollegen Björn Behrens, Martin Eigenbrodt, Lutz Hühnken, Martin Kühl, Andreas Krüger, Michael Schürig, Stefan Tilkov, Benjamin Wolf und Oliver Wolf für die Kommentare zu einer früheren Version des Artikels.
Agile Transformation ist seit zwanzig Jahren ein Thema. Weil Agilität zu der Kultur vieler Unternehmen nicht passt, wird es ein Thema bleiben. Auch weiterhin werden die meisten agile Projekte nur halbherzig Agilität umsetzen können.
URL dieses Artikels:http://www.heise.de/-4140080
Links in diesem Artikel:[1] http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf[2] https://www.heise.de/developer/artikel/Wir-brauchen-technikfeindliche-Techniker-4044291.html[3] http://spiegel.de/karriere/karriereberatung-ich-kann-beim-arbeitstempo-nicht-mehr-mithalten-a-1204711.html
Copyright © 2018 Heise Medien
[unable to retrieve full-text content]
In der Softwarearchitektur gibt es traditionelle Grundsätze, die oft zu Problemen führen. Sich dieser Herausforderungen klar zu werden, ist der erste Schritt, um sie zu beseitigen oder sogar von Anfang an zu vermeiden.
Wasser soweit das Auge reicht, ein kleines Floß unter den Füßen – und ein Hai: Im Early-Access-Spiel Raft fischt man Treibgut aus dem Meer, um sich über Wasser zu halten und das kleine Floß zu einem veritablen Hausboot auszubauen.
Auf einem kleinen Floß treibt der Spieler im Survival-Game Raft übers Meer. Die Aussichten sind zunächst nicht gut: Wasser bis zum Horizont und ein Hai, der seine Runden um das Floß dreht. Mit einem Haken am Seil fischt man aus dem stetigen Strom an Treibgut das Nötigste – Holzplanken, Plastik, Palmblätter und Fässer, die einiges mehr enthalten. Damit baut man sich erste Werkzeuge und vergrößert das Floß, an dem immer mal wieder der Hai knabbert. Hunger und Durst erinnern ziemlich bald daran, dass Raft ein Survival-Spiel ist.
Statt weitläufiger Open-World-Landschaften beschränkt Raft die Spielewelt auf ein kleines Floß auf dem weiten Meer. Man wandert nicht herum und erkundet eine Welt, sondern lässt sich einfach treiben. Mit einem Segel und einem Paddel lässt sich immerhin die Richtung etwas beeinflussen.
Gelegentlich kommt man an einer kleinen Insel vorbei, die nicht nur über, sondern auch unter Wasser wertvolle Ressourcen liefert. Bauen kann man hier aber nicht. Für weitere Abwechslung sorgen verlassene Floße, die vorbeitreiben. Beim Hinüberschwimmen ist stets auch der Hai zur Stelle.
Mit der Zeit wird das Spiel komplexer: Mit einer Angel fängt man Fische, die auf den Grill wandern. Eine Destille erzeugt aus Salzwasser Trinkwasser und in unterschiedlich großen Pflanztöpfen lassen sich Rüben, Kartoffeln, Ananas, Mango, Wassermelonen und sogar Kokospalmen anbauen. Ein Anker erleichtert das Plündern der Inseln.
Im Laufe des Spiels kann man das winzige Floß zu einem komfortablen mehrstöckigen Hausboot mit Hütte und bequemer Hängematte zur Erholung ausbauen. Fans von Survival-Spielen finden in Raft typische Elemente wieder: Im Inventar gesammelte Dinge lassen sich im Crafting-Menü zu Werkzeugen, Waffen, Möbeln und anderem zusammensetzen. An einem Forschungstisch schaltet man neue Rezepte frei und erweitert so das Crafting-Menü. Etwas später im Spiel kann man eine Funkanlage bauen und damit ein geheimnisvolles Ziel ansteuern.
Hunger und Durst stellen zunächst die größte Gefahr dar: Wer sich zu lange mit dem Sammeln von Treibgut aufhält, verhungert und verdurstet schnell. Der Destillierapparat zur Meerwasserentsalzung, eine Angel und ein Grill stehen deshalb ganz oben auf der Crafting-Liste.
Schlechtes Wetter, hohe Wellen, Regen, Nebel und Dunkelheit gibt es ebenfalls in Raft. Das verändert zwar die Stimmung, ist aber nur in Ausnahmesituationen gefährlich. Hat man es beispielsweise gewagt, bei Wellengang zu einem vorbeitreibenden Floß zu schwimmen, während Nebel aufzieht, findet man womöglich nicht mehr zurück, bevor der Hai einem den Garaus macht. Für Action sorgt vor allem das Erkunden der Unterwasserwelt, denn der Hai lässt sich nur kurze Zeit von einem selbstgebauten Köder ablenken.
Drei Schwierigkeitsgrade stehen bereit. Wer in Ruhe ohne Ressourcenmangel sein Floß ausbauen will, kann zudem beim Spielstart den Kreativmodus mit unbegrenzten Vorräten und Gesundheit wählen.
Bereits im Dezember 2016 veröffentlichten drei schwedische Studenten der Universität Uppsala den Prototypen ihres Spiels für Windows und Linux kostenlos auf der Online-Plattform itch.io [3]. Bis Ende Mai 2017 wurde dieser über sieben Millionen Mal heruntergeladen. Aus Zeitgründen stellten die Entwickler die Linux-Version ab Version 1.05 fürs Erste jedoch ein.
Seit dem 23. Mai 2018 bieten die mittlerweile als Redbeet Interactive firmierenden Entwickler ihr Spiel in einer erweiterteten Version mit deutlich mehr Inhalten und einer rundum neuen Grafik auf Steam als Early-Access-Titel für rund 20 Euro [4] an.
Wer sein Spiel für Freunde freigibt, kann gemeinsam im Koop-Modus sein Glück auf hoher See versuchen. Zu zweit oder dritt spielt es sich entspannter, da man nicht ständig das Meer nach vielversprechenden Fässern absuchen, sich um Nahrung und Wasser kümmern oder den Hai abwehren muss.
Bislang stehen zwei Charaktere zur Wahl (eine Frau und ein Mann), die sich optisch nicht anpassen lassen. Dass Raft den Spielernamen über einer Figur einblendet, erleichtert immerhin das Unterscheiden gleich aussehender Mitspieler.
Ist die Option "Freunden erlauben beizutreten" angehakt, sehen Steam-Freunde das Spiel unter "Welt beitreten". Mit dem aktuellen Update lieferten die Entwickler die Möglichkeit nach, das Spiel zusätzlich mit einem Passwort zu schützen, sodass nur geladene Gäste mitspielen können.
Das c't-zockt-Team hat Raft bereits ausprobiert; ein Mitschnitt des Live-Streams [5] ist bei YouTube zu sehen (siehe unten).
Raft hat einen ausgezeichneten Early-Access-Start hingelegt: Das Spiel enthält reichlich Inhalte für etliche Stunden und macht sehr viel Spaß. Fehler gibt es nur wenige und wenn, so stören sie den Spielfluss kaum. Es kann durchaus vorkommen, dass der Hai mal den Kopf durch Felsen oder das Floß steckt. Schon jetzt sorgt das Ozean-Survival-Game dafür, dass man beim Spielen schnell die Zeit vergisst.
Obwohl Raft jetzt schon eine Empfehlung ist, steht es noch am Anfang seiner Entwicklung. Noch ist die Spielzeit überschaubar, irgendwann gibt es einfach nichts mehr zu tun. Auch das Baumenü lässt noch reichlich Raum für Erweiterungen. Weitere Inhalte sind angekündigt, beispielsweise neue Tiere. Einige Updates haben die Entwickler auch schon ausgeliefert. Im Laufe des Spiels deuten die Entwickler bereits eine spannende Storyline im Stil von Waterworld an, die sicher noch ausbaufähig ist. Wer Spaß an Survival-Spielen hat, neue Spielideen sucht und sich vom Early-Access-Status nicht abschrecken lässt, sollte die 20 Euro für Raft unbedingt investieren.
()
URL dieses Artikels:http://www.heise.de/-4096377
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4096377[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4096377[3] https://raft.itch.io/raft[4] https://store.steampowered.com/app/648800/Raft/[5] https://youtu.be/5tNnB1YxHqo[6] mailto:lmd@heise.de
Copyright © 2018 Heise Medien
Wasser, Hunger, Durst und ein nerviger Hai. Raft fügt dem Survival-Genre eine ungewöhnliche Spiel-Idee hinzu: Per Haken fischt man nach Treibgut und baut damit das Floß zum mehrstöckigen Luxus-Segler aus. c't zockt Raft LIVE ab 17 Uhr.
Bei Raft startet der Spieler in einer scheinbar ausweglosen Situation: Er steht auf einem winzigen Floß, das im Ozean treibt. Um das Floß kreist ein hungriger Hai. Mit dem einzigen Werkzeug, einem Seil mit Haken, zieht man Treibgut wie Planken, Plastik – viel Plastik –, Palmwedel und Fässer zu sich heran.
Mit dem Material baut sich der Spieler weitere Werkzeuge und erweitert das Floß. Letzteres ist auch nötig, da der Hai regelmäßig das Floß angreift und einzelne Segmente davon abbeißt. Das lästige Vieh ist nur durch beherztes Zustechen mit einem Spieß zu vertreiben – den man natürlich auch erst einmal bauen muss.
Da sich Hunger und Durst sehr rasch einstellen, gehört zu den ersten Aufgaben das Herstellen eines Destillierapparates zur Frischwassergewinnung, einer Angel und eines Grills. Wer sich zu lange mit dem Sammeln von Baumaterial oder der Haiabwehr beschäftigt, verhungert und verdurstet schnell: Sicht und Bewegungsfreiheit werden zunächst stark eingeschränkt, dann stirbt man. Ins Wasser springen ist auch keine Lösung, denn der Hai ist schneller – mehr als drei Attacken überlebt der Spieler nicht.
Raft stammt von drei schwedischen Studenten der Universität Uppsala, die Ende 2016 einen spielbaren Prototypen von Raft über die Plattform itch.io[3] zum freien Download anboten. Der wurde bis Ende Mai 2017 über sieben Millionen Mal heruntergeladen und erntete begeisterte Kritiken. Anfangs gab es Raft für Windows und Linux, doch stellten die nun unter Redbeet Interactive[4] firmierenden Entwickler die Linux-Version ab Version 1.05 aus Zeitgründen fürs Erste ein.
Seit dem 23. Mai gibt es Raft bei Steam[5] als Early-Access-Spiel in einer erweiterten Version für rund 20 Euro zu kaufen. Hinzugekommen sind Inseln, die man besuchen kann, eine Unterwasserwelt, neue Werkzeuge, Materialien, gierige Möwen und der Anfang einer Hintergrund-Story. Ebenfalls neu ist der Multiplayer-Modus: Weitere Spieler im LAN und aus dem Steam-Freundeskreis können laufenden Spielen beitreten.
Am Donnerstag ab 17 Uhr begibt sich das c't-zockt-Team LIVE auf ein wackliges Floß und versucht, nicht zu verdursten und zu verhungern – aber wir hoffen auf ein schönes Hai-Steak!
(rop[6])
URL dieses Artikels:http://www.heise.de/-4093041
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4093041[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4093041[3] https://thedev.itch.io/raft-info[4] http://raft-game.com/presskit.html[5] https://store.steampowered.com/app/648800/Raft/[6] mailto:rop@ct.de
Copyright © 2018 Heise Medien
FreshRSS