Anmelden
Vergangene Woche hat der TV-Streaming-Dienstleister Zattoo seine neue Progressive Web App veröffentlicht [1], die nun den alten Web-Player ersetzt. ÜberKreuz konnte kurz nach Veröffentlichung bei Zattoo Deutschland in Berlin-Neukölln hinter die Kulissen blicken. Über die Entwicklung der PWA sprach Christian Liebel mit Bogdan Plieshka, Senior Frontend Engineer, und Jörg Schindler, Product Manager Core Platform.
ÜberKreuz: Woher kam die Idee, eine Progressive Web App zu entwickeln?
Jörg Schindler: Am Anfang stand die Entscheidung, unseren Web-Player neu zu entwickeln. Bei diesem Relaunch wollten wir unbedingt auch eine mobile Experience implementieren, die es zuvor nicht gab. Anwender mit einem Smartphone wurden vorher einfach abgewiesen.
Bogdan Plieshka: Bei einem internen Hackathon wurden die ersten Grundlagen für eine Neuentwicklung unseres Web-Clients gelegt. Im Verlauf des daraufhin startenden Relaunch-Projekts hatte ich die Gelegenheit, mich mit den PWA-Schnittstellen zu beschäftigen. Damit kann ja gerade auch auf mobilen Geräten eine sehr gute Benutzererfahrung erreicht werden. Daraufhin haben wir die PWA-Unterstützung einfach auf dem Weg mitgenommen.
ÜberKreuz: Welche PWA-Features werden genutzt?
Plieshka: Ein Teil der Anwendung wird im Service-Worker-Cache [2] abgelegt und kann von dort sehr schnell geladen werden. Offlinefähig sind wir als TV-Streaming-Plattform aber nicht. Auf Wunsch kann der Anwender die PWA auf seinem Gerät installieren [3]. Außerdem nutzen wir neue Schnittstellen wie die Picture-in-Picture-API, um den Videoplayer in einem eigenen kleinen Fenster darstellen zu können.
ÜberKreuz: Bringt die Web-Plattform alle Schnittstellen mit, die Zattoo benötigt?
Plieshka: Im Webbrowser ist sehr viel möglich, aber leider nicht alles. Zum Beispiel sind die Chromecast-Schnittstellen eingeschränkt. Safari verhält sich außerdem sehr restriktiv, so ist Autoplay nicht ohne Weiteres erlaubt [4].
Schindler: Schön wäre es außerdem, wenn Entwickler auch App-Icon-Shortcuts hinterlegen könnten. Das ist momentan nicht möglich. Weil eben noch nicht alles geht, halten wir auch an den nativen Apps fest.
ÜberKreuz: Welche Bibliotheken werden eingesetzt?
Plieshka: Die Webanwendung selbst ist in React geschrieben und verwendet Redux für das State-Management [5]. Es gibt aber auch viele Bereiche, die in Vanilla-JavaScript geschrieben sind, um Framework-unabhängig zu sein. Für die Generierung des Service Worker setzen wir Workbox [6] ein.
ÜberKreuz: Was fiel bei der Entwicklung schwer?
Plieshka: Die PWA-Eigenschaft "app-like" setzt voraus, dass sich PWAs wie native Anwendungen anfühlen. Daher haben wir massiv in die Performance unserer Webanwendung investiert. Nutzerinteraktionen wie Scrollen und Gesten fühlen sich sehr flüssig an.
ÜberKreuz: Was fiel bei der Entwicklung leicht?
Plieshka: Zwei Architekturentscheidungen haben uns sehr geholfen. Durch die Implementierung des Webclients als Single-Page-Applikation war es sehr einfach, die PWA-Unterstützung zu realisieren. Im Gegensatz zum vorherigen Monolithen hilft uns Redux beim Bugfixing. Damit sind wir deutlich schneller geworden.
Schindler: Auch unsere Plattform kommt uns entgegen: Beim TV-Streaming gibt es rechtliche Rahmenbedingungen, die sich je nach Land unterscheiden. Diese Businesslogik wird in der Middleware implementiert, im Client gibt es also keine Weichen.
ÜberKreuz: Wie lange hat die Entwicklung gedauert und wie viele Entwickler waren beteiligt?
Schindler: Die Entwicklungszeit für die PWA betrug netto etwa eineinhalb Jahre mit durchschnittlich zwei Entwicklern, zuzüglich Designern und QA.
ÜberKreuz: Vor dem Rollout gab es eine mehrstufige Betaphase mit insgesamt über 10.000 Teilnehmern. Welches Feedback haben die Testkunden zurückgemeldet?
Plieshka: Das Feedback der Testkunden hat uns sehr überrascht. Es gab zwar einzelne Kritikpunkte, diese bezogen sich aber primär auf Änderungen im UX, die dem User, der den alten Web-Player gewohnt war, eine gewisse Umgewöhnung abverlangten. An etlichen Stellen konnten wir hier den Usern durch Anpassungen noch während der Betaphase entgegenkommen. Davon abgesehen war das Feedback fast durchgängig positiv. Manche Kunden haben sogar schon gefragt, wann diese Anwendung im App Store heruntergeladen werden kann oder wann manche der Funktionen auch in den nativen Apps landen. Das hat uns gezeigt, dass Nutzern die Plattform völlig egal ist. Zwischen nativer App und PWA merkt man praktisch keinen Unterschied.
URL dieses Artikels:http://www.heise.de/-4512794
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Zattoo-veroeffentlicht-erstmals-eine-Progressive-Web-App-4512143.html[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[4] https://www.heise.de/mac-and-i/meldung/iOS-10-Safari-spielt-stumme-Videos-automatisch-ab-3278893.html[5] https://www.heise.de/ratgeber/JavaScript-Bibliothek-React-State-Management-mit-Redux-4476579.html[6] https://www.heise.de/ratgeber/Tutorial-Progressive-Web-Apps-mit-Workbox-Teil-1-4232415.html
Copyright © 2019 Heise Medien
Zattoo ist eine TV-Streamingplattform. Nutzer können über Apps für native Plattformen sowie Smart-TVs Fernsehprogramme über das Internet empfangen und Sendungen aufzeichnen. Nun erweitert der Anbieter sein Produktportfolio um eine Progressive Web App.
Die Progressive Wep App [1] läuft auf allen Endgeräten, die einen aktuellen Webbrowser ausführen können, neben den gängigen Mobil- und Desktop-Plattformen also auch auf Smart-TVs, Set-Top-Boxen oder TV-Sticks. Die Anwendung wird dabei das bestehende Produktportfolio aus nativen Apps ergänzen. Sie ersetzt den früheren Web-Player, der Nutzer mit Smartphones komplett ausgesperrt hat.
Anwender können die PWA auf Wunsch auf dem Home-Bildschirm der Plattform installieren, um einen einfacheren Zugang zu erhalten. Von dort startet Zattoo in einem Standalone-Modus, der sich in der Darstellung von nativen Apps nicht unterscheidet. Die App unterstützt das Streaming von Inhalten via Chromecast und implementiert mit der Picture-in-Picture-API [2] eine moderne Webschnittstelle, die das Darstellen des Videoplayers in einem eigenen Fenster erlaubt, das sich über andere Fenster legt. Somit können Nutzer auch Fernsehprogramme oder Aufzeichnungen sehen, ohne das Hauptfenster der App geöffnet haben zu müssen. Dank der Zwischenspeicherung von Anwendungsquelldateien wird eine schnelle Ladezeit erreicht. Eine Offline-Unterstützung ist derzeit allerdings nicht vorgesehen.
Ein besonderes Augenmerk wurde auf die Benutzererfahrung und die Performance der App gelegt, sowie auf ein frisches Design. Die PWA passt sich an die Abmessungen und Orientierung des jeweiligen Bildschirms an, vom Smartphone bis zum Fernseher. Für die Nutzung von Zattoo ist ein kostenfreier Account erforderlich. Für zusätzliche Sender und Features wie TV-Aufnahmen oder werbefreies Umschalten muss ein kostenpflichtiges Abo abgeschlossen werden.
Das ÜberKreuz-Blog durfte in Berlin-Neukölln einen Blick hinter die Kulissen der Entwicklung der Zattoo-PWA werfen. Ein umfassendes Interview mit dem Entwicklerteam erscheint in wenigen Tagen hier auf dem ÜberKreuz-Blog.
URL dieses Artikels:http://www.heise.de/-4512143
Links in diesem Artikel:[1] https://www.zattoo.com[2] https://github.com/w3c/picture-in-picture/blob/master/explainer.md
Copyright © 2019 Heise Medien
Word braucht es, Visual Studio Code braucht es, Photoshop braucht es: Die Rede ist vom Zugriff auf das native Dateisystem. Was im Web lange Zeit unerreichbar schien, wird nun bald Wirklichkeit: Die Native File System API könnte gleich einen ganzen Schwung von Anwendungen ins Web bringen. Mit Google Chrome 77 wird ein erster Wurf der Schnittstelle [1] getestet.
Für eine Vielzahl von Anwendungen ist der fehlende Zugriff auf das native Dateisystem der wohl größte Blocker, um sie als Progressive Web App – also als reine Web-Applikation ohne nativen Unterbau – herauszugeben. Office-Anwendungen, Medienplayer, IDEs sowie Text-, Bilder oder Videoeditoren brauchen schlichtweg einen Zugriff auf Dateien und Ordner, die im Dateisystem des Computers abgelegt sind. Als Teil der Project-Fugu- bzw. Web-Capabilities-Schnittstellen [2] testet Google nun die Native File System API, die es Webanwendungen erlaubt, Ordnerinhalte aufzulisten sowie Dateien zu lesen und zu schreiben.
Zum Beispiel Microsoft Visual Studio Code: Der quelloffene Editor von Microsoft ist bereits eine Webanwendung, die derzeit in einem nativen Container (Electron) verpackt ausgeliefert wird. Dieser Container bündelt einen Chromium-Browser mit einer Node.js-Installation und gewährt der Webanwendung darüber Zugriff auf native Funktionen wie das Dateisystem oder das Terminal.
Allerdings werden somit selbst Hello-World-Anwendungen gleich mehrere dutzend Megabyte groß. Weiterhin ergibt sich durch die separaten Laufzeitprozesse ein RAM-Overhead. Beides entfällt, wenn die Anwendung direkt innerhalb des Browsers ausgeführt werden kann. Das setzt aber voraus, dass es eine passende Webschnittstelle gibt, die die gewünschte Funktionalität implementiert. Mit Erscheinen der Native File System API sinkt daher die Notwendigkeit, einen Texteditor wie VS Code als native App herausgeben zu müssen.
Moderne Webschnittstellen werden so entworfen, dass sie grundsätzlich plattformübergreifend verwendbar sind. Entwickler müssen also nicht das Betriebssystem prüfen und davon abhängig verschiedene Implementierungen ansprechen, sondern verwenden immer dieselbe API. Das gilt auch für die Native File System API. Spezifiziert wird sie bei der Web Incubator Community Group [3] (WICG) des W3C.
Die Native File System API erweitert dabei die Schnittstellen des globalen Window-Objekts. Durch den Aufruf der Methode chooseFileSystemEntries() öffnet sich der bekannte Dateiauswahldialog. Der Methode lässt sich ein Konfigurationsobjekt übergeben. Darüber kann die Mehrfachauswahl aktiviert, die erlaubten Dateiendungen eingeschränkt und der Dialogtyp (Datei öffnen, Verzeichnis öffnen, Datei speichern) angegeben werden. Standardmäßig wird ein Datei-öffnen-Dialog mit Einfachauswahl angezeigt. Das nachstehende Listing zeigt, wie eine Auswahl für TXT-Dateien angezeigt und der Inhalt der gewählten Datei ausgelesen werden kann:
FreshRSS btnOpenFile.addEventListener('click', async () => {
const handle = await window.chooseFileSystemEntries({
accepts: [{ extensions: ['txt'] }]
});
const file = await handle.getFile();
console.log(await file.text());
});
Bricht der Benutzer den Dateiauswahldialog ab, erhält die Webanwendung gar keinen Zugriff. Andernfalls erhält sie ein Handle, mithilfe dessen auf die vom Benutzer gewählte Dateien beziehungsweise Verzeichnisse zugegriffen werden kann. Mit dem Handle ist auch ein Überschreiben der gewählten Datei möglich. Dazu steht auf ihm die Methode createWriter() bereit. Der Aufruf dieser Methode gibt einen FileSystemWriter zurück, der schreibenden Zugriff auf die zuvor ausgewählte Datei erlaubt.
const writer = await handle.createWriter();
await writer.truncate(0);
await writer.write(0, 'this is Chrome');
await writer.close();
Der Webbrowser fordert Anwender in diesem Fall noch einmal gesondert auf, das Überschreiben der Datei zu bestätigen. Stimme sie zu, darf die Webanwendung die Datei ohne weitere Abfrage überschreiben – bis die aktuelle Registerkarte geschlossen wird.
Alle modernen Webschnittstellen müssen Sicherheitsvorkehrungen gegen eine missbräuchliche Verwendung der API ergreifen – das gilt auch für die Native File System API. Wie für die meisten modernen Webschnittstellen üblich, wird die Übertragung der Website über eine gesicherte Verbindung (HTTPS) vorausgesetzt. Der Dateisystemzugriff darf nur infolge einer Benutzerinteraktion (Klick oder Tastendruck) angefordert werden. Anwender müssen das Lesen und Speichern von Dateien jeweils vorher bestätigen.
Hat eine Webanwendung gerade schreibenden Zugriff auf das Dateisystem, weist Chrome durch ein Symbol in der Adresszeile prominent darauf hin. Darüber hinaus verweigert der Webbrowser den Zugriff auf Systemordner und andere sensible Verzeichnisse.
Im ersten Wurf ist es nicht möglich, das Handle und somit die Berechtigung zum Zugriff auf bestimmte Dateien oder Verzeichnisse zu persistieren. Anwender müssen stattdessen vor jeder Verwendung den Zugriff explizit wieder freigeben – vergleichbar zur Contacts Picker API [4]. Für die Zukunft ist angedacht, dass auf dem Gerät installierte Progessive Web Apps [5] das Handle in der lokalen Clientdatenbank IndexedDB speichern dürfen. Das erlaubt es etwa, "Zuletzt verwendet"-Menüs anzubieten. Nicht installierte Webanwendungen müssen die Erlaubnis hingegen erneut einholen.
Die Native File System API wird mit Google Chrome 77 erstmals ausgerollt, verbirgt sich jedoch noch hinter einem Flag (chrome://flags/#native-file-system-api). Die Schnittstelle kann schon heute in Google Chrome Canary und Microsoft Edge Canary ausprobiert werden. Wie üblich soll die API in der sogenannten Origin Trial einem begrenzten Publikum auch ohne vorherige Aktivierung des Flags verfügbar gemacht werden können. Diese Implementierungsphase wird für Chrome 78 erwartet. Das Google-Entwicklerteam freut sich auf Feedback seitens der Webentwickler im zugehörigen Discourse-Thread bei der WICG [6] sowie auf Twitter unter dem Hashtag #nativefs.
URL dieses Artikels:http://www.heise.de/-4505949
Links in diesem Artikel:[1] https://developers.google.com/web/updates/2019/08/native-file-system[2] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[3] https://wicg.github.io/native-file-system/[4] https://www.heise.de/developer/artikel/Contacts-Picker-API-Kontakte-Zugriff-fuer-Progressive-Web-Apps-4493480.html[5] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[6] https://discourse.wicg.io/t/writable-file-api/1433
Copyright © 2019 Heise Medien
Eine Frau, ein Mann und ein Zitronenbaum sind die letzten Überlebenden einer Apokalypse, die fast die ganze Welt mit Wasser bedeckt hat. Was an eine abgespeckte Version der biblischen Geschichte von Adam und Eva erinnert, ist der Einstieg in das Early-Access-Spiel Last Wood von Just Us, das Ende August 2019 gestartet ist.
Last Wood ist ein Ozean-Survival-Spiel, bei dem man zu Anfang zwei Charaktere auf einer winzigen Planke steuert. Holz liefert ein Zitronenbaum, den man fällen und neu pflanzen kann. So lässt sich die Planke allmählich zu einem Floß ausbauen. Weitere praktische Rohstoffe sammelt man mit herumtreibenden Gegenständen wie Fässer, Kisten und Müllsäcken ein.
Neben allerlei praktischen Dingen spült der Ozean auch Überlebende an, mit denen die Anzahl der spielbaren Figuren auf dem Floß steigt. Ein für ein Survival-Spiel ungewöhnliches Highlight an Last Wood ist die Möglichkeit für zwei Figuren, sich fortzupflanzen. Vorausgesetzt sie haben genug Platz, Privatsphäre und Zeit auf dem Floß, können sie somit die nächste Generation an Floßbewohnern zeugen.
Neben den ganzen schönen Aspekten des Lebens auf einem Floß, handelt es sich doch um eine postapokalyptische Welt. Als echtes Survival-Game haben die Floßbewohner daher auch Feinde: Haie, Fischmenschen und Krakenmonster stehen auf der Tagesordnung. Sie lassen nichts unversucht, um das Boot oder seine Bewohner zu vernichten. Mit selbst gebauten Waffen muss man sich verteidigen und schützen, was einem lieb ist. Dazu kommen noch ganz andere Probleme: faule Crewmitglieder, die keine Lust haben zu arbeiten, Hungertod oder die Gefahr zu ertrinken. Bis wirklich ernstzunehmende Probleme auftauchen und die Kämpfe spannender werden, dauert es allerdings eine ganze Weile.
Dank vieler Crafting-Möglichkeiten kann man sich auch in Last Wood kreativ ausleben. So lässt sich das Floß mit mehreren Etagen und allerlei selbstgebauten Möbelstücken ausbauen. Bei einem Händler kann man zudem seltene Gegenstände zu erwerben. Durch den Ausbau von Technologien, kann man ganze Farmen oder gar Wassergewinnungsanlagen bauen. Im Laufe der Zeit wird so aus der anfänglichen Planke womöglich ein richtiges Kreuzfahrtschiff.
Last Wood erinnert zwar durch Umfeld und Spielweise an eine Mischung aus Minecraft und Raft, zeichnet sich jedoch durch einfache Grafik und gleichzeitige Liebe zum Detail aus. Besonders bei der Ausarbeitung der Spielfiguren haben sich die Entwickler viel Mühe gegeben. Jeder Schiffbrüchige hat eine eigene Hintergrundgeschichte und individuelle Stärken und Schwächen.
Vier verschiedene Schwierigkeitsstufen lassen die Wahl, ob man den Spielfokus auf Survival- oder Crafting-Elemente legen möchte.
Last Wood bietet bereits reichlich Spielspaß, doch man merkt hin und wieder, dass es noch in der Entwicklung steckt. Gelegentliche Bugs tun dem Spielvergnügen zwar keinen Abbruch, gelegentlich bleiben Spielfiguren aber einfach noch stehen und Gegenstände gehen verloren. Auch die Steuerung ist noch verbesserungsfähig. Wen diese Fehler zu sehr stören, der sollte den Entwicklern noch Gelegenheit geben, Fehler zu beheben, bevor er Last Wood ausprobiert. Auch zwei weitere Spielmodi sind noch in der Entwicklung.
Das Ozean-Survival-Game Last Wood ist als Early-Access-Titel auf Steam für 12,49 Euro für macOS und Windows verfügbar. Mit dem Kauf erhält man auch alle künftigen Updates und die finale Version des Spiels.
()
URL dieses Artikels:http://www.heise.de/-4536578
Links in diesem Artikel:[1] https://www.heise.de/bilderstrecke/bilderstrecke_4542933.html?back=4536578;back=4536578[2] https://www.heise.de/bilderstrecke/bilderstrecke_4542933.html?back=4536578;back=4536578[3] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Zeitreisen mit einer Wunderlampe sind ganz praktisch – im Adventure "The Great Perhaps" wechselt man damit munter von der Vergangenheit in die düstere Gegenwart.
Der Astronaut "Kosmos" wacht in einer Forschungsstation im Erdorbit aus dem Kryoschlaf auf und starrt vom Bullauge hinab auf die Erde. Nicht nur, dass er hundert Jahre geschlafen hat, nein: Er ist auch der einzige Mensch, der eine gewaltige Katastrophe überlebt hat, vor der er sich mit knapper Not ins Schiff retten konnte.
Der wie das ganze Stil im Comic-Stil gehaltene Trailer am Anfang des Spiels erzählt, wie es weitergeht: Der Astronaut ist verzweifelt und fordert die künstliche Intelligenz "L9" auf, den Sauerstoff aus der Raumstation abzupumpen. Hätte L9 das gemacht, wäre das Spiel bereits nach dem Trailer zu Ende gewesen. Doch in Anspielung auf den Supercomputer HAL 9000 (aus dem Film "2001: Odyssee im Weltraum") sagt L9: "Das kann ich nicht tun!"
Sie überzeugt ihn, sich zur Spurensuche auf die Erdoberfläche zu begeben, will aber im Rucksack des Astronauten mitreisen, weil sie nicht allein bleiben möchte. Für das Spiel ist das ein Gewinn, denn in den vergangenen hundert Jahren hat sie ein wenig an ihrer Humorfunktion arbeiten können und im Spiel gibt sie ab und zu Tipps, was man tun könnte. Eine Wahl hat man dabei aber ohnehin nicht.
Der Spielverlauf in The Great Perhaps ist völlig linear: Man muss tun, was die Geschichte von einem verlangt, sonst stirbt man. Aber auch wenn das geschieht, ist es nicht weiter schlimm, weil es den Spieler nur auf den letzten, vom Spiel automatisch erstellten Speicherpunkt zurückwirft. Weder gehen Reichtümer verloren noch verliert man Level, denn sowas gibts bei The Great Perhaps nicht.
Die Erdoberfläche ist indes kein Tummelplatz, den man nach Lust und Laune erforschen könnte – The Great Perhaps ist kein Open-World- oder gar ein Zombie-Horde-Crafting-Spiel wie 7 Days to die [1], sondern ein grafisch nett gemachter Side-Scroller in 2D-Grafik. Per A- und D-Taste (oder den Pfeiltasten) bewegt man sich nach links oder rechts, mit der Leertaste hüpft man, die Taste E lässt Kosmos Türen öffnen, Dinge aufheben und Dialoge führen und mit F kann man Gegenstände werfen. Die wenigen Dinge, mit denen Kosmos interagieren kann, sind durch einen hell blinkenden Punkt oder Rahmen hervorgehoben, eine lange Suche nach der Nadel im Heuhaufen entfällt somit.
Schnell findet Kosmos eine rätselhafte Laterne, mit der man mit der Taste Q in die Vergangenheit schauen und mit langem Tastendruck sogar in diese Zeitlinie wechseln kann – und wieder zurück. Diese Wunderlampe muss er schnell benutzen, denn ein schwarzer Schattenmann rückt dem Astronauten auf die Pelle.
Um im Spiel weiterzukommen und herauszufinden, was die große Katastrophe verursacht hat, muss man immer wieder Dinge aus der einen Zeitlinie besorgen und in der anderen einsetzen: Schlüssel für abgeschlossene Räume, Bücher aus Bibliotheken, die angehende Selbstmörder davon abhalten, vom Dach zu springen. Oder man nutzt die andere Zeitlinie, um an Hindernissen und lauernden Monstern sowie mordlustigen Krankenpflegern vorbei zu kommen.
Hin und wieder muss man kleine Rätsel lösen. Sie stellen aber allesamt keine allzu große Herausforderung dar, auch nicht für Gelegenheitsspieler.
Die Story ist zwar recht dünn und das Setting auch nicht gerade übermäßig originell, aber das Spiel schafft es, mit einer sehr stimmigen Musikkulisse und handgemalten Details eine melancholische bis niederdrückende Atmosphäre zu schaffen. Im Trailer ist beispielsweise – fürs Spiel geradezu doppelsinnig - ein Kinoplakat zum Film "Zurück in die Zukunft" zu sehen.
Humor beweisen die Entwickler besonders in Details, die für den Spielfluss an sich nicht wichtig sind: Im Büro eines Schlüsselbewahrers fehlt beispielsweise in der Jetztzeit der Kalender mit – angedeutet – leicht bekleideten Damen, während anderer Wandschmuck offenbar in den Wirren der Endzeit keine Interessenten gefunden hat. Ein Graffiti in der U-Bahn zeigt die hohle Phrase "Thoughts and Prayers", die Politiker bei jeder Katastrophe abgesondern. Daher lohnt es sich durchaus, das Spiel nach dem ersten Durcheilen nochmal zu spielen, dann aber mit Blick auf solche Ostereier der Entwickler.
Der grafische Stil greift auf die Motive der Sowjetzeit zurück: Helden der Raumfahrt, hier und da ein roter Stern und natürlich überall kyrillische Schriften. Die Zeit nach der Apokalypse verbreitet spröden Lost-Place-Charme, auch durch die weniger bunte Farbgestaltung.
The Great Perhaps hat keine deutschsprachige Vertonung, aber die englische ist gut eingesprochen, wenig nuschelig und die deutschen Untertitel können die eine oder andere sprachliche Lücke schließen.
Das Spiel "The Great Perhaps" stammt vom russischen Entwicklerstudio Caligari Games, Publisher ist Daedalic Entertainment, die man vielleicht von Deponia kennt. Seit Mitte August ist "The Great Perhaps" für einen schlanken Zehner auf der Gaming-Plattform Steam [4] zu haben, und zwar für macOS (ab Sierra), Windows (ab 7) und Linux. Ein Core2Duo ab 2,4 Gigahertz reicht laut Steam, mit einem i5-MacBook pro (2013) lief es flüssig, ebenso auf Windows-Rechnern mit i5. Höchstleistungen verlangt die Grafikabteilung im Rechner bei diesem Spiel nicht.
Wer sich fragt, wieso das Spiel "The Great Perhaps" heißt: Dabei handelt es sich um die letzten Worte des Dichters Francois Rabelais [5]. Noch berühmter wurde der Ausdruck durch das Buch "Looking for Alaska [6]" von John Green.
Insgesamt ist The Great Perhaps für all jene interessant, die ein Spiel suchen, für das man nicht viel lernen muss. Rätsel sind recht einfach lösbar und man kann das Spiel in endlicher Zeit bewältigen. Grafisch ist das Adventure schön gemacht, bietet immer wieder Anspielungen auf bekannte Sujets und bringt einen Soundtrack mit, der die düster-melancholische Stimmung untermalt. Selbst das Ende hat etwas zumindest Küchenphilosophisches. Wer bis dahin gekommen ist, sollte es vielleicht noch mal spielen, weil sich dann einige Elemente der Geschichte als vorweg genommene Hinweise entpuppen.
()
URL dieses Artikels:http://www.heise.de/-4532540
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/c-t-zockt-LIVE-7-Days-To-Die-fuer-blutende-Anfaenger-4521152.html[2] https://www.heise.de/bilderstrecke/bilderstrecke_4532781.html?back=4532540;back=4532540[3] https://www.heise.de/bilderstrecke/bilderstrecke_4532781.html?back=4532540;back=4532540[4] https://store.steampowered.com/app/1016930/The_Great_Perhaps/[5] https://de.wikipedia.org/wiki/Fran%C3%A7ois_Rabelais[6] https://de.wikipedia.org/wiki/Eine_wie_Alaska[7] mailto:mil@heise.de
Copyright © 2019 Heise Medien
Heute im Livestream ab 18 Uhr: So überlebt man als Neueinsteiger die ersten Tage im Zombie-Horde-Survival-Game 7 Days To Die.
Zombies, Naturgewalten, wilde Tiere, Hunger und Durst: Die Gefahren der Postapokalypse sind vielfältig und gemeinsam leichter durchzustehen. In unseren Gamer-Reihen haben wir doch tatsächlich noch einen gefunden, der sich bisher nicht in die Zombie-Apokalypse von 7 Days To Die gewagt hat. Jetzt gehen wir mit ihm die ersten Schritte ins Zombieland.
Kurz vor dem Release der nächsten großen Version Alpha 18 bereiten wir einen weiteren Überlebenden der Apokalypse auf das Schlimmste vor. Dabei gilt es den ersten Tag zu überleben (und natürlich alle weiteren), ein sicheres Zuhause zu finden, Essen und Wasser aufzutreiben und die eigenen Fähigkeiten zu verbessern.
Das Survival-Game "7 Days To Die" vereint verschiedene Elemente: Im Nahkampf mit Keule und Faust oder mit Distanzwaffen wie Bogen, Pistole und anderen Schusswaffen verteidigt man sich gegen unterschiedlich gefährliche Zombies sowie Bären, Wölfe, Schlangen und Hunde. Zum Tower-Defense-Game mutiert das Spiel, wenn es darum geht, die große Horde abzuwehren, die alle sieben Tage vor der Tür steht. Klassische Survival-Elemente wie Hunger, Durst, Hitze und Kälte erschweren das Überleben zusätzlich. Dabei hat das Spiel weit über 100 Orte, die ihre eigenen kleinen Abenteuer bereithalten und eine Erkundung wert sind.
Wer Spaß am Bauen hat, kann sich hier ebenfalls ausleben: Der Kreativität sind ähnlich wie in Minecraft keine Grenzen gesetzt. Das Open-World-Abenteuer setzt nur am Ende der Map den eigenen Schritten ein Ende. Alles ist zerstörbar und liefert dabei unterschiedliche Ressourcen zurück. Entsprechende Erfahrungswerte vorausgesetzt, lässt sich mit den vielen unterschiedlichen Ressourcen so einiges craften.
Schon seit 2013 ist "7 Days To Die" als Early-Access-Titel in der Entwicklung. Die Spieleschmiede The FunPimps hat scheinbar keine Eile, es fertigzustellen. Die mindestens einmal jährlich veröffentlichten neuen Versionen bringen stets neue Herausforderungen und Funktion, werfen aber manchmal auch Althergebrachtes wieder um. Mittlerweile hat sich das Spiel eine beachtliche Fangemeinde erworben.
Das Zombie-Horde-Survival-Crafting-Game "7 Days To Die" gibt es für Linux, macOS und Windows bei Steam [3] für rund 23 Euro. Der Kauf des Early-Access-Titels schließt alle künftigen Versionen bis zur Fertigstellung ein.
Im Livestream auf Youtube [4] und Twitch [5] zeigt das c't-zockt-Team heute ab 18 Uhr, wie man die ersten Tage in 7 Days To Die überlebt – oder wenigstens mit Anstand stirbt. Wer noch tiefer einsteigen will, findet reichlich Tipps und Tricks rund um das Spiel in unserer Tutorial-Reihe zu 7 Days To Die [6] – die übrigens auch erklärt, wie man die Einstellungen für mehr Performance optimiert.
()
URL dieses Artikels:http://www.heise.de/-4521152
Links in diesem Artikel:[1] [2] [3] https://store.steampowered.com/app/251570/7_Days_to_Die/[4] https://www.youtube.com/watch?v=t_MucdKnNBg[5] https://www.twitch.tv/events/3LlsEwnVQ12hslpIhRzlUw[6] https://www.heise.de/ct/artikel/Videotutorial-7-Days-To-Die-optimal-einstellen-und-ueberleben-4415885.html[7] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
data/config-user.custom.php #2490
mod_authz_core instead of mod_access_compat when running on Apache 2.4+ #2461COPY_LOG_TO_SYSLOG to see all logs at once in e.g. docker logs -f #2591FRESHRSS_ENV to control Minz development mode #2508themes/xTheme-* #2511
Eine Frau, ein Mann und ein Zitronenbaum sind die letzten Überlebenden einer Apokalypse, die fast die ganze Welt mit Wasser bedeckt hat. Was an eine abgespeckte Version der biblischen Geschichte von Adam und Eva erinnert, ist der Einstieg in das Early-Access-Spiel Last Wood von Just Us, das Ende August 2019 gestartet ist.
Last Wood ist ein Ozean-Survival-Spiel, bei dem man zu Anfang zwei Charaktere auf einer winzigen Planke steuert. Holz liefert ein Zitronenbaum, den man fällen und neu pflanzen kann. So lässt sich die Planke allmählich zu einem Floß ausbauen. Weitere praktische Rohstoffe sammelt man mit herumtreibenden Gegenständen wie Fässer, Kisten und Müllsäcken ein.
Neben allerlei praktischen Dingen spült der Ozean auch Überlebende an, mit denen die Anzahl der spielbaren Figuren auf dem Floß steigt. Ein für ein Survival-Spiel ungewöhnliches Highlight an Last Wood ist die Möglichkeit für zwei Figuren, sich fortzupflanzen. Vorausgesetzt sie haben genug Platz, Privatsphäre und Zeit auf dem Floß, können sie somit die nächste Generation an Floßbewohnern zeugen.
Neben den ganzen schönen Aspekten des Lebens auf einem Floß, handelt es sich doch um eine postapokalyptische Welt. Als echtes Survival-Game haben die Floßbewohner daher auch Feinde: Haie, Fischmenschen und Krakenmonster stehen auf der Tagesordnung. Sie lassen nichts unversucht, um das Boot oder seine Bewohner zu vernichten. Mit selbst gebauten Waffen muss man sich verteidigen und schützen, was einem lieb ist. Dazu kommen noch ganz andere Probleme: faule Crewmitglieder, die keine Lust haben zu arbeiten, Hungertod oder die Gefahr zu ertrinken. Bis wirklich ernstzunehmende Probleme auftauchen und die Kämpfe spannender werden, dauert es allerdings eine ganze Weile.
Dank vieler Crafting-Möglichkeiten kann man sich auch in Last Wood kreativ ausleben. So lässt sich das Floß mit mehreren Etagen und allerlei selbstgebauten Möbelstücken ausbauen. Bei einem Händler kann man zudem seltene Gegenstände zu erwerben. Durch den Ausbau von Technologien, kann man ganze Farmen oder gar Wassergewinnungsanlagen bauen. Im Laufe der Zeit wird so aus der anfänglichen Planke womöglich ein richtiges Kreuzfahrtschiff.
Last Wood erinnert zwar durch Umfeld und Spielweise an eine Mischung aus Minecraft und Raft, zeichnet sich jedoch durch einfache Grafik und gleichzeitige Liebe zum Detail aus. Besonders bei der Ausarbeitung der Spielfiguren haben sich die Entwickler viel Mühe gegeben. Jeder Schiffbrüchige hat eine eigene Hintergrundgeschichte und individuelle Stärken und Schwächen.
Vier verschiedene Schwierigkeitsstufen lassen die Wahl, ob man den Spielfokus auf Survival- oder Crafting-Elemente legen möchte.
Last Wood bietet bereits reichlich Spielspaß, doch man merkt hin und wieder, dass es noch in der Entwicklung steckt. Gelegentliche Bugs tun dem Spielvergnügen zwar keinen Abbruch, gelegentlich bleiben Spielfiguren aber einfach noch stehen und Gegenstände gehen verloren. Auch die Steuerung ist noch verbesserungsfähig. Wen diese Fehler zu sehr stören, der sollte den Entwicklern noch Gelegenheit geben, Fehler zu beheben, bevor er Last Wood ausprobiert. Auch zwei weitere Spielmodi sind noch in der Entwicklung.
Das Ozean-Survival-Game Last Wood ist als Early-Access-Titel auf Steam für 12,49 Euro für macOS und Windows verfügbar. Mit dem Kauf erhält man auch alle künftigen Updates und die finale Version des Spiels.
()
URL dieses Artikels:http://www.heise.de/-4536578
Links in diesem Artikel:[1] https://www.heise.de/bilderstrecke/bilderstrecke_4542933.html?back=4536578;back=4536578[2] https://www.heise.de/bilderstrecke/bilderstrecke_4542933.html?back=4536578;back=4536578[3] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Zeitreisen mit einer Wunderlampe sind ganz praktisch – im Adventure "The Great Perhaps" wechselt man damit munter von der Vergangenheit in die düstere Gegenwart.
Der Astronaut "Kosmos" wacht in einer Forschungsstation im Erdorbit aus dem Kryoschlaf auf und starrt vom Bullauge hinab auf die Erde. Nicht nur, dass er hundert Jahre geschlafen hat, nein: Er ist auch der einzige Mensch, der eine gewaltige Katastrophe überlebt hat, vor der er sich mit knapper Not ins Schiff retten konnte.
Der wie das ganze Stil im Comic-Stil gehaltene Trailer am Anfang des Spiels erzählt, wie es weitergeht: Der Astronaut ist verzweifelt und fordert die künstliche Intelligenz "L9" auf, den Sauerstoff aus der Raumstation abzupumpen. Hätte L9 das gemacht, wäre das Spiel bereits nach dem Trailer zu Ende gewesen. Doch in Anspielung auf den Supercomputer HAL 9000 (aus dem Film "2001: Odyssee im Weltraum") sagt L9: "Das kann ich nicht tun!"
Sie überzeugt ihn, sich zur Spurensuche auf die Erdoberfläche zu begeben, will aber im Rucksack des Astronauten mitreisen, weil sie nicht allein bleiben möchte. Für das Spiel ist das ein Gewinn, denn in den vergangenen hundert Jahren hat sie ein wenig an ihrer Humorfunktion arbeiten können und im Spiel gibt sie ab und zu Tipps, was man tun könnte. Eine Wahl hat man dabei aber ohnehin nicht.
Der Spielverlauf in The Great Perhaps ist völlig linear: Man muss tun, was die Geschichte von einem verlangt, sonst stirbt man. Aber auch wenn das geschieht, ist es nicht weiter schlimm, weil es den Spieler nur auf den letzten, vom Spiel automatisch erstellten Speicherpunkt zurückwirft. Weder gehen Reichtümer verloren noch verliert man Level, denn sowas gibts bei The Great Perhaps nicht.
Die Erdoberfläche ist indes kein Tummelplatz, den man nach Lust und Laune erforschen könnte – The Great Perhaps ist kein Open-World- oder gar ein Zombie-Horde-Crafting-Spiel wie 7 Days to die [1], sondern ein grafisch nett gemachter Side-Scroller in 2D-Grafik. Per A- und D-Taste (oder den Pfeiltasten) bewegt man sich nach links oder rechts, mit der Leertaste hüpft man, die Taste E lässt Kosmos Türen öffnen, Dinge aufheben und Dialoge führen und mit F kann man Gegenstände werfen. Die wenigen Dinge, mit denen Kosmos interagieren kann, sind durch einen hell blinkenden Punkt oder Rahmen hervorgehoben, eine lange Suche nach der Nadel im Heuhaufen entfällt somit.
Schnell findet Kosmos eine rätselhafte Laterne, mit der man mit der Taste Q in die Vergangenheit schauen und mit langem Tastendruck sogar in diese Zeitlinie wechseln kann – und wieder zurück. Diese Wunderlampe muss er schnell benutzen, denn ein schwarzer Schattenmann rückt dem Astronauten auf die Pelle.
Um im Spiel weiterzukommen und herauszufinden, was die große Katastrophe verursacht hat, muss man immer wieder Dinge aus der einen Zeitlinie besorgen und in der anderen einsetzen: Schlüssel für abgeschlossene Räume, Bücher aus Bibliotheken, die angehende Selbstmörder davon abhalten, vom Dach zu springen. Oder man nutzt die andere Zeitlinie, um an Hindernissen und lauernden Monstern sowie mordlustigen Krankenpflegern vorbei zu kommen.
Hin und wieder muss man kleine Rätsel lösen. Sie stellen aber allesamt keine allzu große Herausforderung dar, auch nicht für Gelegenheitsspieler.
Die Story ist zwar recht dünn und das Setting auch nicht gerade übermäßig originell, aber das Spiel schafft es, mit einer sehr stimmigen Musikkulisse und handgemalten Details eine melancholische bis niederdrückende Atmosphäre zu schaffen. Im Trailer ist beispielsweise – fürs Spiel geradezu doppelsinnig - ein Kinoplakat zum Film "Zurück in die Zukunft" zu sehen.
Humor beweisen die Entwickler besonders in Details, die für den Spielfluss an sich nicht wichtig sind: Im Büro eines Schlüsselbewahrers fehlt beispielsweise in der Jetztzeit der Kalender mit – angedeutet – leicht bekleideten Damen, während anderer Wandschmuck offenbar in den Wirren der Endzeit keine Interessenten gefunden hat. Ein Graffiti in der U-Bahn zeigt die hohle Phrase "Thoughts and Prayers", die Politiker bei jeder Katastrophe abgesondern. Daher lohnt es sich durchaus, das Spiel nach dem ersten Durcheilen nochmal zu spielen, dann aber mit Blick auf solche Ostereier der Entwickler.
Der grafische Stil greift auf die Motive der Sowjetzeit zurück: Helden der Raumfahrt, hier und da ein roter Stern und natürlich überall kyrillische Schriften. Die Zeit nach der Apokalypse verbreitet spröden Lost-Place-Charme, auch durch die weniger bunte Farbgestaltung.
The Great Perhaps hat keine deutschsprachige Vertonung, aber die englische ist gut eingesprochen, wenig nuschelig und die deutschen Untertitel können die eine oder andere sprachliche Lücke schließen.
Das Spiel "The Great Perhaps" stammt vom russischen Entwicklerstudio Caligari Games, Publisher ist Daedalic Entertainment, die man vielleicht von Deponia kennt. Seit Mitte August ist "The Great Perhaps" für einen schlanken Zehner auf der Gaming-Plattform Steam [4] zu haben, und zwar für macOS (ab Sierra), Windows (ab 7) und Linux. Ein Core2Duo ab 2,4 Gigahertz reicht laut Steam, mit einem i5-MacBook pro (2013) lief es flüssig, ebenso auf Windows-Rechnern mit i5. Höchstleistungen verlangt die Grafikabteilung im Rechner bei diesem Spiel nicht.
Wer sich fragt, wieso das Spiel "The Great Perhaps" heißt: Dabei handelt es sich um die letzten Worte des Dichters Francois Rabelais [5]. Noch berühmter wurde der Ausdruck durch das Buch "Looking for Alaska [6]" von John Green.
Insgesamt ist The Great Perhaps für all jene interessant, die ein Spiel suchen, für das man nicht viel lernen muss. Rätsel sind recht einfach lösbar und man kann das Spiel in endlicher Zeit bewältigen. Grafisch ist das Adventure schön gemacht, bietet immer wieder Anspielungen auf bekannte Sujets und bringt einen Soundtrack mit, der die düster-melancholische Stimmung untermalt. Selbst das Ende hat etwas zumindest Küchenphilosophisches. Wer bis dahin gekommen ist, sollte es vielleicht noch mal spielen, weil sich dann einige Elemente der Geschichte als vorweg genommene Hinweise entpuppen.
()
URL dieses Artikels:http://www.heise.de/-4532540
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/c-t-zockt-LIVE-7-Days-To-Die-fuer-blutende-Anfaenger-4521152.html[2] https://www.heise.de/bilderstrecke/bilderstrecke_4532781.html?back=4532540;back=4532540[3] https://www.heise.de/bilderstrecke/bilderstrecke_4532781.html?back=4532540;back=4532540[4] https://store.steampowered.com/app/1016930/The_Great_Perhaps/[5] https://de.wikipedia.org/wiki/Fran%C3%A7ois_Rabelais[6] https://de.wikipedia.org/wiki/Eine_wie_Alaska[7] mailto:mil@heise.de
Copyright © 2019 Heise Medien
Das erste Jakarta-EE-Release bringt keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war. Hinter den Kulissen hat sich aber einiges mehr getan.
Fast auf den Tag genau zwei Jahre, nachdem Oracle Java EE geöffnet und an die Eclipse Foundation übergeben hat, war es am 10. September endlich soweit: Jakarta EE 8, die erste vollständige Open-Source-Variante des Enterprise-Java-Standards, wurde veröffentlicht [1].
Was erwartet uns mit diesem Release? Eine zu 100 Prozent kompatible Version zu der bisher unter der Obhut von Oracle stehenden Java Enterprise Edition 8. Das ist nicht wirklich viel für zwei Jahre harter Arbeit, werden sich jetzt manche Leser sicherlich denken. Trotzdem stellt dieses Release einen der wohl wichtigsten Meilensteine in der mittlerweile 20-jährigen Geschichte der Java Enterprise Edition dar. Denn in den vergangenen 24 Monaten wurde in der Eclipse Foundation die Grundlage für eine offene, Community-getriebene Weiterentwicklung des Enterprise-Java-Standards in Richtung Cloud-native geschaffen und damit eine Zukunft für den bereits totgesagten Standard ermöglicht – nicht mehr und nicht weniger.
"Open Source Cloud Native Java: Powered by participation, Jakarta EE is focused on enabling community-driven collaboration and open innovation for the cloud”, heißt es entsprechend prominent auf der Startseite von Jakarte EE.
Natürlich verwundert gerade vor diesem Hintergrund ein wenig, dass sich im aktuellen Release keine neuen (Cloud-)APIs finden. Das hat seinen Grund.
Dass Jakarta EE mit seinem ersten Release noch keine Innovationen mit sich bringen würde, war bereits sehr früh klar. In einem ersten Schritt wollte die Jakarta EE Working Group, in der sich neben der Eclipse Foundation auch Vertreter von Oracle, Fujitsu, IBM, Payara, Red Hat und Tomitribe finden, zunächst sicherstellen, dass Jakarta EE 8 vollständig kompatibel zum bisherigen Standard ist. Nur so kann gewährleistet werden, dass alle bisherigen Nutzer von Java EE ihre Anwendungen mit möglichst wenig Aufwand migrieren und so ihr bis dato getätigtes Investment sichern können. Ein Muss für die Akzeptanz innerhalb der Java-EE-Community.
Das alleine dieser Schritt schon einem erheblichen Kraftakt gleichkommt, zeigt ein Blick auf die Webseite von Jakarta EE 8 [2]. Insgesamt 43 Projekte mit mehr als 60 Millionen Zeilen Code mussten von Oracle zur Eclipse Foundation umziehen, um dort, ein wenig aufgeräumt, in eine eigene Build- und Deplyoment-Infrastruktur eingebettet und via Git-Repositories der Öffentlichkeit zur Verfügung gestellt zu werden. Neben den Spezifikationen der APIs [3] selbst betrifft das vor allem die TCKs. Witzigerweise mussten auch alle Bugs beziehungsweise Issues übernommen werden, um eine 100-Prozent-Kompatibilität zu gewährleisten.
Das erste Jakarta-EE-Release bringt also keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war, hinter den Kulissen hat sich aber in den letzten zwei Jahren einiges mehr getan.
Alle Jakarta-EE 8-Spezifikationen wurden gemäß dem neu geschaffenen Jakarta EE Specification Process (JESP [4]) beschrieben, welcher der Nachfolger des Java Community Process (JCP) ist. Auch wenn die Namen der Spezifikation im Rahmen der Migration sinnvollerweise vereinheitlicht wurden und somit dem Wildwuchs der vergangenen Jahre – JMS zum Beispiel ist ein Service, JTA dagegen eine API und JCA eine Architektur – ein Ende gesetzt wurde, sind sie inhaltlich kompatibel zu ihren Java-EE-8-Pendants. Das gilt sowohl für die APIs und Javadocs als auch für die verwendeten javax.*-Namespaces. Eine Ausnahme stellen lediglich die Oracle-Trademarks dar, die ausgetauscht werden.
Neben den Spezifikationen selbst wurden auch die zugehörigen TCKs migriert und als Jakarta EE 8 TCKs veröffentlicht (Eclipse Public Licence, EPL 2.0). Auch diese sind kompatibel zu den Java EE 8 TCKs.
Bereits Anfang des Jahres wurde Eclipse GlassFish 5.1 veröffentlicht und mit Java EE 8 zertifiziert. Während die Sourcen des Anwendungsservers zu diesem Zeitpunkt bereits bei der Eclipse Foundation lagen, liefen die Tests damals noch auf der Infrastruktur von Oracle. Zeitgleich mit der Veröffentlichung von Jakarta EE 8 durchlief Eclipse GlassFish 5.1 auch auf der eigenen Infrastruktur die TCKs und gilt somit nicht nur als Java-EE-8- sondern auch als Jakarta-EE-8-kompatibel (Full Platform und Web Profile). Eine Liste aller bereits heute kompatiblen Server findet sich unter "Jakarta EE 8 Compatible Products [5]".
Der ganze Aufwand der letzten zwei Jahre rechnet sich natürlich nur dann, wenn die Zukunftsvisionen der Eclipse Foundation auch realisiert werden. Wir erinnern uns: "Open Source Cloud Native Java". Laut Aussage der Open-Source-Organisation möchte man zukünftig deutlich schneller und regelmäßiger neue Releases veröffentlichen. Schaut man sich einmal die Releasezyklen des JDKs oder aber der ebenfalls in der Eclipse Foundation beheimateten MicroProfiles an, scheint das ein durchaus realistisches Ziel zu sein.
Zusätzlich möchte man die Einstiegshürde deutlich verringern. Das gilt sowohl für Hersteller von Application-Servern als auch für Unternehmen, Gruppen oder einzelne Personen, die den neuen Standard vorantreiben wollen. Ein erster wichtiger Schritt hierzu ist durch die Öffnung der TCKs sowie dank des neu geschaffenen Jakarta EE Speficication Process bereits getan.
Laut eigenen Angaben sollen neue Spezifikationen zukünftig vornehmlich nach dem "Code First"-Ansatz entstehen. Das heißt, APIs sollen sich erst einmal in der Praxis etablieren, bevor sie in eine Spezifikation gegossen werden. Eine in der Open-Source-Community gängige Praxis, die vor den aus der J2EE-Welt – und teilweise auch noch aus der Java-EE-Welt – nur zu gut bekannten, am Reißbrett entworfenen Elfenbeinturm-APIs schützten soll und darüber hinaus sicherlich die Akzeptanz in der Community für neue APIs erhöhen wird.
Eine Umfrage in der Community [6] hat gezeigt, dass vor allem Cloud-native-Themen wie Microservices, Kubernetes und Services-Meshes (insbesondere Istio) kritisch für den zukünftigen Erfolg von Jakarta EE sein werden und daher Top-Kandidaten für neue Spezifikationen sind. Insbesondere in Hinblick auf die Unterstützung von Microservices ist davon auszugehen, dass neben der Spezifikation neuer APIs vor allem eine stärkere Annäherung an MicroProfile.io [7] stattfinden wird. Das legt auch die Agenda der parallel zum Release von Jakarta EE stattgefundenen Online-Konferenz JakartaOne [8] nahe, in der sich etliche Vorträge mit der gemeinsamen Verwendung von Jakarta EE 8 und MicroProfile 3 beschäftigt haben.
Bevor allerdings die nächsten Schritte angegangen werden können, muss zunächst noch ein "kleines" Problem aus der Welt geschaffen werden: Die Umbenennung aller Java-API-Packages von javax.* zu jakarta.*. Oracle hat zwar die weitere Verwendung des Package-Präfix javax gestattet, das aber nur dann, wenn die APIs unverändert bleiben. Neue APIs oder Änderungen (dies gilt übrigens auch für Bugfixes) an bestehenden APIs führen automatisch auch zu einem Verbot der Verwendung von javax.
Eine Diskussion darüber, ob es zukünftig immer dann zur Umbenennung kommen soll, wenn eine API angefasst wird oder alternativ alle Packages einmalig refaktorisiert werden sollen, hat eine klare Tendenz in Richtung Big Bang aufgezeigt. Man war sich ebenfalls einig darüber, dass lediglich ein Austausch von javax.* zu jakarta.* stattfinden soll, weitere Änderungen hinter dem Präfix aber zu unterlassen sind.
Entsprechend sieht es aktuell danach aus, dass auch das kommende Release Jakarta EE 9 weiterhin keine neuen APIs mit sich bringen wird, sondern lediglich die neuen Package-Strukturen realisiert. Bestehende Anwendungen, die zukünftig auf Jakarta EE 9 Servern laufen wollen, müssten also entsprechend umgestellt werden. Hierbei können die Refactoring-Tools der IDEs helfen. Alternativ könnten die Application-Server intern die alten Package-Namen auf die neuen mappen, sodass existierende Jakarta-8-Anwendungen ohne jeglichen Aufwand auch auf Jakarta 9+ lauffähig wären. Neben dem ganzen Voodoo, den Application-Server schon heute betreiben, kein wirkliches Hexenwerk.
Weiterhin ist davon auszugehen, dass nach GlassFish, OpenLiberty (IBM) und WildFly (Red Hat), auch andere Java-EE-8-Application-Server die Jakarta TCKs durchlaufen und sich somit Jakarta-EE-kompatibel nennen dürfen. Selbst Oracle hat bereits angekündigt, dass man mit Hochdruck an einer gleichzeitig mit Java EE 8 und Jakarta EE 8 kompatiblen Version des WebLogic Application Server arbeitet.
"We're extremely pleased that Jakarta EE 8 has been released. This represents the culmination of a great deal of work by the entire Jakarta EE community, including Oracle, and we appreciate everyone's contributions. Oracle is working on the delivery of a Java EE 8 and Jakarta EE 8 compatible WebLogic Server implementation…", so Tom Snyder, Vice President Oracle Software Development.
Die ersten wirklichen Innovationen in Richtung Cloud-native sind wahrscheinlich erst mit Jakarta EE 10 zu erwarten. In Zeiten des JCPs wäre das in fünf bis zehn Jahren gewesen. Die Eclipse Foundation schafft es hoffentlich in einem Zehntel der Zeit. Ein erster heißer Kandidat für eine neue API ist Jakarta NoSQL [9] zur herstellerunabhängigen Anbindung und Nutzung von NoSQL-Datenbanken innerhalb von Jakarta-EE-Anwendungen.
Es kommen spannende Zeiten auf uns zu. Zeiten, die über die Zukunft des Enterprise-Java-Standards entscheiden werden. Nach meiner persönlichen Erfahrungen mit der Eclipse Foundation (im Rahmen von MicroProfile.io) und der Enterprise-Java-Community bin ich sehr guter Hoffnung, dass diese Zeiten positiv sein werden.
URL dieses Artikels:http://www.heise.de/-4522665
Links in diesem Artikel:[1] https://www.heise.de/meldung/Quelloffene-Enterprise-Java-Spezifikation-Jakarta-EE-8-geht-an-den-Start-4519179.html[2] https://www.jakarta.ee/release[3] https://github.com/jakartaee/specifications[4] https://jakarta.ee/about/jesp/[5] https://jakarta.ee/compatibility[6] https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf[7] https://microprofile.io[8] https://jakartaone.org/#plan-of-the-day[9] https://projects.eclipse.org/proposals/jakarta-nosql
Copyright © 2019 Heise Medien
Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses mal habe ich mit Gunnar Morling über Change Data Capture und das Open-Source-Projekt Debezium gesprochen.
Thorben Janssen: Vielen Dank, dass du wieder für ein Gespräch bereitstehst. Der eine oder andere hat vielleicht das frühere Interview mit dir über die Bean-Validation-2.0-Spezifikation [1] verpasst. Kannst du dich bitte noch mal kurz vorstellen?
Gunnar Morling: Ich bin als Open-Source-Softwareentwickler für Red Hat tätig. Zunächst habe ich als Teil des Hibernate-Teams unter anderem an Projekten wie Hibernate Validator und Hibernate Search gearbeitet und die Entwicklung von Bean Validation 2.0 (JSR 380) geleitet. Als ein Bestandteil der Java-EE-Plattform wird aktuell übrigens auch die Bean-Validation-Spezifikation nach Jakarta EE überführt und künftig unter dem Dach der Eclipse Foundation weiterentwickelt werden.
Seit nunmehr reichlich zwei Jahren arbeite ich an Debezium [2], einer Open-Source-Plattform für Change Data Capture. Vielleicht kennt mich der eine oder andere Leser auch schon von Konferenzen wie dem JavaLand oder meiner Arbeit an anderen Projekten wie MapStruct und Deptective.
Janssen: Seitdem Microservices zunehmend an Popularität gewonnen haben, wird auch wieder mehr über Patterns zum Datenaustausch zwischen verschiedenen Datenquellen gesprochen. Eines davon ist Change Data Capture (CDC). Was genau hat es damit auf sich und was ist die grundlegende Idee dahinter?
Morling: Die Idee von Change Data Capture ist schnell erklärt: Wenn immer sich in einer Datenbank etwas ändert, also zum Beispiel ein Kunde angelegt, ein Auftrag aktualisiert oder eine Lieferung gelöscht wird, wird diese Änderung erfasst und als Event an interessierte Consumer verteilt. Diese Events beschreiben alten und neuen Zustand des betroffenen Datensatzes sowie Metadaten wie den Zeitstempel der Änderung, Transaktions-ID und einiges andere mehr. Im Sinne einer losen Kopplung werden die Change Events dabei typischerweise asynchron über Message Broker wie Apache Kafka an die Konsumenten übertragen.
Janssen: Und wie sieht ein ideales Anwendungsszenario für CDC aus?
Morling: Die Anwendungsfälle für CDC sind ausgesprochen vielfältig:
Zum einen kann man direkt auf die Events reagieren und zum Beispiel korrespondierende Einträge eines Caches invalidieren. Auch Streaming Queries fallen in diese Kategorie: Dabei werden vordefinierte Abfragen (z.B. "Wie hoch ist der akkumulierte Auftragswert der Produktkategorie Möbel innerhalb der letzten 60 Minuten?") automatisch ausgeführt, wann immer ein relevantes Change Event eintrifft, also etwa "Purchase order created". Die kontinuierlich aktualisierten Ergebnisse einer solchen Streaming Query können dann wiederum genutzt werden, um etwa ein Dashboard live zu aktualisieren oder zum Beispiel ein Alerting zu implementieren, wenn der Bestand eines Produkts unter einen bestimmten Schwellwert fällt.
Zum anderen können die Daten der Change Events auch genutzt werden, um andere Datenspeicher zu aktualisieren und konsistent mit der Quelldatenbank zu halten. Dies könnte etwa ein Volltextsuchindex in Elasticsearch sein, ein Data Warehouse oder andere Datenbanken für Analysezwecke. Aber auch Audit Logs oder optimierte Lesedatenmodelle in einer CQRS-Architektur (Command Query Responsibility Segregration) können per CDC erzeugt werden.
Im Kontext von Microservices kann Change Data Capture genutzt werden, um Datenänderungen zwischen verschiedenen Services zu propagieren. Services können dann beispielsweise eine Kopie der Daten anderer Services in ihrer eigenen lokalen Datenbank anlegen, wodurch synchrone Aufrufe zwischen den Services vermieden werden können.
Janssen: Mit dem Debezium-Projekt bietet ihr eine Implementierung der CDC-Patterns. Wie funktioniert das genau und mit welchen Datenquellen kann ich es verwenden?
Morling: Debezium implementiert das sogenannte Log-basierte CDC, das heißt, die Quelle der Change Events sind die Transaktionslogs der Datenbank. Dies bietet große Vorteile gegenüber alternativen Ansätzen wie dem Polling (also der wiederholten Ausführung von Queries, um neue oder geänderte Datensätze zu identifizieren):
Debezium basiert auf Kafka Connect [3], einem Framework zur Implementierung und Ausführung von Kafka-Konnektoren, welches unter anderem das Management von Konnektoren (Konfiguration, Start, Stopp etc.), Monitoring und Hochverfügbarkeit mittels Clustering von Kafka-Connect-Instanzen ermöglicht. Auch die Fehlertoleranz ist dabei berücksichtigt: Stürzt etwa ein Konnektor ab oder muss einfach aufgrund eines Updates neu gestartet werden, gehen keine Change-Events verloren, sondern das Log wird einfach ab der zuletzt verarbeiten Position weitergelesen. Im Kontext von Kafka Connect gibt es eine Vielzahl sogenannter Sink-Konnektoren, die mit Debezium genutzt werden können, um Datenänderungen zum Beispiel an andere Datenbanken, Elasticsearch, Hadoop-Cluster usw. zu übertragen.
Neben dem Deployment per Kafka Connect kann Debezium auch als Bibliothek in beliebigen Java-Applikationen genutzt werden, wovon Nutzer Gebrauch machen, um etwa Change-Events nach Amazon Kinesis zu streamen.
Debezium unterstützt diverse Datenbanken wie MySQL, PostgreSQL, SQL Server und MongoDB. Auch arbeitet die Community aktuell an einem Konnektor für Apache Cassandra.
Janssen: Was muss ich tun, wenn ich Debezium einsetzen möchte?
Morling: Ein Startpunkt könnte die Lektüre des Debezium-Tutorials [4] sein, das die erforderlichen Komponenten (eine Datenbank wie MySQL, Apache Kafka, Kafka Connect, Debezium) als Container-Images bereitstellt und die Schritte von der Konfiguration eines Konnektors bis zur Anzeige der Change-Events in Kafka aufzeigt.
Für den produktiven Einsatz basierend auf Kubernetes/OpenShift empfiehlt sich das Strimzi [5]-Projekt, welches einen Kubernetes-Operator zum Betrieb von Kafka und Kafka Connect bereitstellt. Hierfür gibt es bei Bedarf kommerziellen Support [6] durch Red Hat; dies gilt auch für Debezium selbst (aktuell als Developer Preview verfügbar [7]).
Janssen: Aktuell liegt Debezium in der Version 0.9 vor. Ist es bereits für den produktiven Einsatz geeignet? Was fehlt noch zur Version 1.0?
Morling: Die Community setzt die diversen Debezium-Konnektoren bereits im großen Stil in Produktion ein. User berichten von Deployments mit zum Teil Hunderten von Datenbanken. Wir als Entwicklungsteam sind daher sehr darauf bedacht, in neuen Releases die Kompatibilität mit früheren Versionen zu gewährleisten und ein möglichst reibungsloses Upgrade zu ermöglichen. Aktuell arbeiten wir an Version 0.10, welche unter anderem einige Vereinheitlichungen der Event-Formate der diversen Konnektoren und eine erste Version des Cassandra-Konnektors umfasst.
Debezium 1.0 sollte als Nächstes folgen, hier wird der Fokus im Wesentlichen auf Vereinheitlichungen bezüglich der Konfigurationsoptionen der Konnektoren und dem Ausbau der automatisierten Test-Suite liegen, um die Stabilität der Konnektoren noch weiter zu verbessern.
Einige Schlagworte für mögliche künftige Weiterentwicklungen sind die Integration mit dem CloudEvents-Standard, Integration mit weiteren Message-Brokern, Unterstützung für die Erstellung denormalisierter Datensichten und einiges andere mehr. Wir richten uns dabei sehr nach den Bedürfnissen der Community und passen die Roadmap stetig an.
Janssen: Wo kann ich mehr über das Projekt erfahren?
Morling: Zentraler Anlaufpunkt ist unsere Website [8]. Dort können die Konnektoren heruntergeladen werden; es gibt die Referenzdokumentation [9] und das oben genannte Tutorial für einen schnellen Einstieg. Im Blog [10] informieren wir über neue Releases und weiterführende Themen wie Demos zu spezifischen CDC-Use-Cases.
Für Fragen steht die Community bei Bedarf mittels einer Mailing-Liste [11] und einem Chat-Room [12] zur Verfügung, und natürlich findet man @debezium [13] auf Twitter.
Janssen: Und wo kann man dich finden?
Morling: Ich bin über die diese Kanäle und auch auf Twitter unter @gunnarmorling [14] erreichbar.
Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg mit Debezium.
URL dieses Artikels:http://www.heise.de/-4513865
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Bean-Validation-ist-sehr-nuetzlich-fuer-Microservice-Architekturen-3321829.html[2] https://debezium.io/[3] https://kafka.apache.org/documentation/#connect[4] https://debezium.io/docs/tutorial/[5] http://strimzi.io/[6] https://access.redhat.com/products/red-hat-amq#streams[7] https://access.redhat.com/articles/4259091[8] https://debezium.io/[9] https://debezium.io/docs/[10] https://debezium.io/blog/[11] https://groups.google.com/forum/#!forum/debezium[12] https://gitter.im/debezium/user[13] https://twitter.com/debezium[14] https://twitter.com/gunnarmorling
Copyright © 2019 Heise Medien
Heute im Livestream ab 18 Uhr: So überlebt man als Neueinsteiger die ersten Tage im Zombie-Horde-Survival-Game 7 Days To Die.
Zombies, Naturgewalten, wilde Tiere, Hunger und Durst: Die Gefahren der Postapokalypse sind vielfältig und gemeinsam leichter durchzustehen. In unseren Gamer-Reihen haben wir doch tatsächlich noch einen gefunden, der sich bisher nicht in die Zombie-Apokalypse von 7 Days To Die gewagt hat. Jetzt gehen wir mit ihm die ersten Schritte ins Zombieland.
Kurz vor dem Release der nächsten großen Version Alpha 18 bereiten wir einen weiteren Überlebenden der Apokalypse auf das Schlimmste vor. Dabei gilt es den ersten Tag zu überleben (und natürlich alle weiteren), ein sicheres Zuhause zu finden, Essen und Wasser aufzutreiben und die eigenen Fähigkeiten zu verbessern.
Das Survival-Game "7 Days To Die" vereint verschiedene Elemente: Im Nahkampf mit Keule und Faust oder mit Distanzwaffen wie Bogen, Pistole und anderen Schusswaffen verteidigt man sich gegen unterschiedlich gefährliche Zombies sowie Bären, Wölfe, Schlangen und Hunde. Zum Tower-Defense-Game mutiert das Spiel, wenn es darum geht, die große Horde abzuwehren, die alle sieben Tage vor der Tür steht. Klassische Survival-Elemente wie Hunger, Durst, Hitze und Kälte erschweren das Überleben zusätzlich. Dabei hat das Spiel weit über 100 Orte, die ihre eigenen kleinen Abenteuer bereithalten und eine Erkundung wert sind.
Wer Spaß am Bauen hat, kann sich hier ebenfalls ausleben: Der Kreativität sind ähnlich wie in Minecraft keine Grenzen gesetzt. Das Open-World-Abenteuer setzt nur am Ende der Map den eigenen Schritten ein Ende. Alles ist zerstörbar und liefert dabei unterschiedliche Ressourcen zurück. Entsprechende Erfahrungswerte vorausgesetzt, lässt sich mit den vielen unterschiedlichen Ressourcen so einiges craften.
Schon seit 2013 ist "7 Days To Die" als Early-Access-Titel in der Entwicklung. Die Spieleschmiede The FunPimps hat scheinbar keine Eile, es fertigzustellen. Die mindestens einmal jährlich veröffentlichten neuen Versionen bringen stets neue Herausforderungen und Funktion, werfen aber manchmal auch Althergebrachtes wieder um. Mittlerweile hat sich das Spiel eine beachtliche Fangemeinde erworben.
Das Zombie-Horde-Survival-Crafting-Game "7 Days To Die" gibt es für Linux, macOS und Windows bei Steam [3] für rund 23 Euro. Der Kauf des Early-Access-Titels schließt alle künftigen Versionen bis zur Fertigstellung ein.
Im Livestream auf Youtube [4] und Twitch [5] zeigt das c't-zockt-Team heute ab 18 Uhr, wie man die ersten Tage in 7 Days To Die überlebt – oder wenigstens mit Anstand stirbt. Wer noch tiefer einsteigen will, findet reichlich Tipps und Tricks rund um das Spiel in unserer Tutorial-Reihe zu 7 Days To Die [6] – die übrigens auch erklärt, wie man die Einstellungen für mehr Performance optimiert.
()
URL dieses Artikels:http://www.heise.de/-4521152
Links in diesem Artikel:[1] [2] [3] https://store.steampowered.com/app/251570/7_Days_to_Die/[4] https://www.youtube.com/watch?v=t_MucdKnNBg[5] https://www.twitch.tv/events/3LlsEwnVQ12hslpIhRzlUw[6] https://www.heise.de/ct/artikel/Videotutorial-7-Days-To-Die-optimal-einstellen-und-ueberleben-4415885.html[7] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Vergangene Woche hat der TV-Streaming-Dienstleister Zattoo seine neue Progressive Web App veröffentlicht [1], die nun den alten Web-Player ersetzt. ÜberKreuz konnte kurz nach Veröffentlichung bei Zattoo Deutschland in Berlin-Neukölln hinter die Kulissen blicken. Über die Entwicklung der PWA sprach Christian Liebel mit Bogdan Plieshka, Senior Frontend Engineer, und Jörg Schindler, Product Manager Core Platform.
ÜberKreuz: Woher kam die Idee, eine Progressive Web App zu entwickeln?
Jörg Schindler: Am Anfang stand die Entscheidung, unseren Web-Player neu zu entwickeln. Bei diesem Relaunch wollten wir unbedingt auch eine mobile Experience implementieren, die es zuvor nicht gab. Anwender mit einem Smartphone wurden vorher einfach abgewiesen.
Bogdan Plieshka: Bei einem internen Hackathon wurden die ersten Grundlagen für eine Neuentwicklung unseres Web-Clients gelegt. Im Verlauf des daraufhin startenden Relaunch-Projekts hatte ich die Gelegenheit, mich mit den PWA-Schnittstellen zu beschäftigen. Damit kann ja gerade auch auf mobilen Geräten eine sehr gute Benutzererfahrung erreicht werden. Daraufhin haben wir die PWA-Unterstützung einfach auf dem Weg mitgenommen.
ÜberKreuz: Welche PWA-Features werden genutzt?
Plieshka: Ein Teil der Anwendung wird im Service-Worker-Cache [2] abgelegt und kann von dort sehr schnell geladen werden. Offlinefähig sind wir als TV-Streaming-Plattform aber nicht. Auf Wunsch kann der Anwender die PWA auf seinem Gerät installieren [3]. Außerdem nutzen wir neue Schnittstellen wie die Picture-in-Picture-API, um den Videoplayer in einem eigenen kleinen Fenster darstellen zu können.
ÜberKreuz: Bringt die Web-Plattform alle Schnittstellen mit, die Zattoo benötigt?
Plieshka: Im Webbrowser ist sehr viel möglich, aber leider nicht alles. Zum Beispiel sind die Chromecast-Schnittstellen eingeschränkt. Safari verhält sich außerdem sehr restriktiv, so ist Autoplay nicht ohne Weiteres erlaubt [4].
Schindler: Schön wäre es außerdem, wenn Entwickler auch App-Icon-Shortcuts hinterlegen könnten. Das ist momentan nicht möglich. Weil eben noch nicht alles geht, halten wir auch an den nativen Apps fest.
ÜberKreuz: Welche Bibliotheken werden eingesetzt?
Plieshka: Die Webanwendung selbst ist in React geschrieben und verwendet Redux für das State-Management [5]. Es gibt aber auch viele Bereiche, die in Vanilla-JavaScript geschrieben sind, um Framework-unabhängig zu sein. Für die Generierung des Service Worker setzen wir Workbox [6] ein.
ÜberKreuz: Was fiel bei der Entwicklung schwer?
Plieshka: Die PWA-Eigenschaft "app-like" setzt voraus, dass sich PWAs wie native Anwendungen anfühlen. Daher haben wir massiv in die Performance unserer Webanwendung investiert. Nutzerinteraktionen wie Scrollen und Gesten fühlen sich sehr flüssig an.
ÜberKreuz: Was fiel bei der Entwicklung leicht?
Plieshka: Zwei Architekturentscheidungen haben uns sehr geholfen. Durch die Implementierung des Webclients als Single-Page-Applikation war es sehr einfach, die PWA-Unterstützung zu realisieren. Im Gegensatz zum vorherigen Monolithen hilft uns Redux beim Bugfixing. Damit sind wir deutlich schneller geworden.
Schindler: Auch unsere Plattform kommt uns entgegen: Beim TV-Streaming gibt es rechtliche Rahmenbedingungen, die sich je nach Land unterscheiden. Diese Businesslogik wird in der Middleware implementiert, im Client gibt es also keine Weichen.
ÜberKreuz: Wie lange hat die Entwicklung gedauert und wie viele Entwickler waren beteiligt?
Schindler: Die Entwicklungszeit für die PWA betrug netto etwa eineinhalb Jahre mit durchschnittlich zwei Entwicklern, zuzüglich Designern und QA.
ÜberKreuz: Vor dem Rollout gab es eine mehrstufige Betaphase mit insgesamt über 10.000 Teilnehmern. Welches Feedback haben die Testkunden zurückgemeldet?
Plieshka: Das Feedback der Testkunden hat uns sehr überrascht. Es gab zwar einzelne Kritikpunkte, diese bezogen sich aber primär auf Änderungen im UX, die dem User, der den alten Web-Player gewohnt war, eine gewisse Umgewöhnung abverlangten. An etlichen Stellen konnten wir hier den Usern durch Anpassungen noch während der Betaphase entgegenkommen. Davon abgesehen war das Feedback fast durchgängig positiv. Manche Kunden haben sogar schon gefragt, wann diese Anwendung im App Store heruntergeladen werden kann oder wann manche der Funktionen auch in den nativen Apps landen. Das hat uns gezeigt, dass Nutzern die Plattform völlig egal ist. Zwischen nativer App und PWA merkt man praktisch keinen Unterschied.
URL dieses Artikels:http://www.heise.de/-4512794
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Zattoo-veroeffentlicht-erstmals-eine-Progressive-Web-App-4512143.html[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[4] https://www.heise.de/mac-and-i/meldung/iOS-10-Safari-spielt-stumme-Videos-automatisch-ab-3278893.html[5] https://www.heise.de/ratgeber/JavaScript-Bibliothek-React-State-Management-mit-Redux-4476579.html[6] https://www.heise.de/ratgeber/Tutorial-Progressive-Web-Apps-mit-Workbox-Teil-1-4232415.html
Copyright © 2019 Heise Medien
Zattoo ist eine TV-Streamingplattform. Nutzer können über Apps für native Plattformen sowie Smart-TVs Fernsehprogramme über das Internet empfangen und Sendungen aufzeichnen. Nun erweitert der Anbieter sein Produktportfolio um eine Progressive Web App.
Die Progressive Wep App [1] läuft auf allen Endgeräten, die einen aktuellen Webbrowser ausführen können, neben den gängigen Mobil- und Desktop-Plattformen also auch auf Smart-TVs, Set-Top-Boxen oder TV-Sticks. Die Anwendung wird dabei das bestehende Produktportfolio aus nativen Apps ergänzen. Sie ersetzt den früheren Web-Player, der Nutzer mit Smartphones komplett ausgesperrt hat.
Anwender können die PWA auf Wunsch auf dem Home-Bildschirm der Plattform installieren, um einen einfacheren Zugang zu erhalten. Von dort startet Zattoo in einem Standalone-Modus, der sich in der Darstellung von nativen Apps nicht unterscheidet. Die App unterstützt das Streaming von Inhalten via Chromecast und implementiert mit der Picture-in-Picture-API [2] eine moderne Webschnittstelle, die das Darstellen des Videoplayers in einem eigenen Fenster erlaubt, das sich über andere Fenster legt. Somit können Nutzer auch Fernsehprogramme oder Aufzeichnungen sehen, ohne das Hauptfenster der App geöffnet haben zu müssen. Dank der Zwischenspeicherung von Anwendungsquelldateien wird eine schnelle Ladezeit erreicht. Eine Offline-Unterstützung ist derzeit allerdings nicht vorgesehen.
Ein besonderes Augenmerk wurde auf die Benutzererfahrung und die Performance der App gelegt, sowie auf ein frisches Design. Die PWA passt sich an die Abmessungen und Orientierung des jeweiligen Bildschirms an, vom Smartphone bis zum Fernseher. Für die Nutzung von Zattoo ist ein kostenfreier Account erforderlich. Für zusätzliche Sender und Features wie TV-Aufnahmen oder werbefreies Umschalten muss ein kostenpflichtiges Abo abgeschlossen werden.
Das ÜberKreuz-Blog durfte in Berlin-Neukölln einen Blick hinter die Kulissen der Entwicklung der Zattoo-PWA werfen. Ein umfassendes Interview mit dem Entwicklerteam erscheint in wenigen Tagen hier auf dem ÜberKreuz-Blog.
URL dieses Artikels:http://www.heise.de/-4512143
Links in diesem Artikel:[1] https://www.zattoo.com[2] https://github.com/w3c/picture-in-picture/blob/master/explainer.md
Copyright © 2019 Heise Medien
Word braucht es, Visual Studio Code braucht es, Photoshop braucht es: Die Rede ist vom Zugriff auf das native Dateisystem. Was im Web lange Zeit unerreichbar schien, wird nun bald Wirklichkeit: Die Native File System API könnte gleich einen ganzen Schwung von Anwendungen ins Web bringen. Mit Google Chrome 77 wird ein erster Wurf der Schnittstelle [1] getestet.
Für eine Vielzahl von Anwendungen ist der fehlende Zugriff auf das native Dateisystem der wohl größte Blocker, um sie als Progressive Web App – also als reine Web-Applikation ohne nativen Unterbau – herauszugeben. Office-Anwendungen, Medienplayer, IDEs sowie Text-, Bilder oder Videoeditoren brauchen schlichtweg einen Zugriff auf Dateien und Ordner, die im Dateisystem des Computers abgelegt sind. Als Teil der Project-Fugu- bzw. Web-Capabilities-Schnittstellen [2] testet Google nun die Native File System API, die es Webanwendungen erlaubt, Ordnerinhalte aufzulisten sowie Dateien zu lesen und zu schreiben.
Zum Beispiel Microsoft Visual Studio Code: Der quelloffene Editor von Microsoft ist bereits eine Webanwendung, die derzeit in einem nativen Container (Electron) verpackt ausgeliefert wird. Dieser Container bündelt einen Chromium-Browser mit einer Node.js-Installation und gewährt der Webanwendung darüber Zugriff auf native Funktionen wie das Dateisystem oder das Terminal.
Allerdings werden somit selbst Hello-World-Anwendungen gleich mehrere dutzend Megabyte groß. Weiterhin ergibt sich durch die separaten Laufzeitprozesse ein RAM-Overhead. Beides entfällt, wenn die Anwendung direkt innerhalb des Browsers ausgeführt werden kann. Das setzt aber voraus, dass es eine passende Webschnittstelle gibt, die die gewünschte Funktionalität implementiert. Mit Erscheinen der Native File System API sinkt daher die Notwendigkeit, einen Texteditor wie VS Code als native App herausgeben zu müssen.
Moderne Webschnittstellen werden so entworfen, dass sie grundsätzlich plattformübergreifend verwendbar sind. Entwickler müssen also nicht das Betriebssystem prüfen und davon abhängig verschiedene Implementierungen ansprechen, sondern verwenden immer dieselbe API. Das gilt auch für die Native File System API. Spezifiziert wird sie bei der Web Incubator Community Group [3] (WICG) des W3C.
Die Native File System API erweitert dabei die Schnittstellen des globalen Window-Objekts. Durch den Aufruf der Methode chooseFileSystemEntries() öffnet sich der bekannte Dateiauswahldialog. Der Methode lässt sich ein Konfigurationsobjekt übergeben. Darüber kann die Mehrfachauswahl aktiviert, die erlaubten Dateiendungen eingeschränkt und der Dialogtyp (Datei öffnen, Verzeichnis öffnen, Datei speichern) angegeben werden. Standardmäßig wird ein Datei-öffnen-Dialog mit Einfachauswahl angezeigt. Das nachstehende Listing zeigt, wie eine Auswahl für TXT-Dateien angezeigt und der Inhalt der gewählten Datei ausgelesen werden kann:
btnOpenFile.addEventListener('click', async () => {
const handle = await window.chooseFileSystemEntries({
accepts: [{ extensions: ['txt'] }]
});
const file = await handle.getFile();
console.log(await file.text());
});
Bricht der Benutzer den Dateiauswahldialog ab, erhält die Webanwendung gar keinen Zugriff. Andernfalls erhält sie ein Handle, mithilfe dessen auf die vom Benutzer gewählte Dateien beziehungsweise Verzeichnisse zugegriffen werden kann. Mit dem Handle ist auch ein Überschreiben der gewählten Datei möglich. Dazu steht auf ihm die Methode createWriter() bereit. Der Aufruf dieser Methode gibt einen FileSystemWriter zurück, der schreibenden Zugriff auf die zuvor ausgewählte Datei erlaubt.
const writer = await handle.createWriter();
await writer.truncate(0);
await writer.write(0, 'this is Chrome');
await writer.close();
Der Webbrowser fordert Anwender in diesem Fall noch einmal gesondert auf, das Überschreiben der Datei zu bestätigen. Stimme sie zu, darf die Webanwendung die Datei ohne weitere Abfrage überschreiben – bis die aktuelle Registerkarte geschlossen wird.
Alle modernen Webschnittstellen müssen Sicherheitsvorkehrungen gegen eine missbräuchliche Verwendung der API ergreifen – das gilt auch für die Native File System API. Wie für die meisten modernen Webschnittstellen üblich, wird die Übertragung der Website über eine gesicherte Verbindung (HTTPS) vorausgesetzt. Der Dateisystemzugriff darf nur infolge einer Benutzerinteraktion (Klick oder Tastendruck) angefordert werden. Anwender müssen das Lesen und Speichern von Dateien jeweils vorher bestätigen.
Hat eine Webanwendung gerade schreibenden Zugriff auf das Dateisystem, weist Chrome durch ein Symbol in der Adresszeile prominent darauf hin. Darüber hinaus verweigert der Webbrowser den Zugriff auf Systemordner und andere sensible Verzeichnisse.
Im ersten Wurf ist es nicht möglich, das Handle und somit die Berechtigung zum Zugriff auf bestimmte Dateien oder Verzeichnisse zu persistieren. Anwender müssen stattdessen vor jeder Verwendung den Zugriff explizit wieder freigeben – vergleichbar zur Contacts Picker API [4]. Für die Zukunft ist angedacht, dass auf dem Gerät installierte Progessive Web Apps [5] das Handle in der lokalen Clientdatenbank IndexedDB speichern dürfen. Das erlaubt es etwa, "Zuletzt verwendet"-Menüs anzubieten. Nicht installierte Webanwendungen müssen die Erlaubnis hingegen erneut einholen.
Die Native File System API wird mit Google Chrome 77 erstmals ausgerollt, verbirgt sich jedoch noch hinter einem Flag (chrome://flags/#native-file-system-api). Die Schnittstelle kann schon heute in Google Chrome Canary und Microsoft Edge Canary ausprobiert werden. Wie üblich soll die API in der sogenannten Origin Trial einem begrenzten Publikum auch ohne vorherige Aktivierung des Flags verfügbar gemacht werden können. Diese Implementierungsphase wird für Chrome 78 erwartet. Das Google-Entwicklerteam freut sich auf Feedback seitens der Webentwickler im zugehörigen Discourse-Thread bei der WICG [6] sowie auf Twitter unter dem Hashtag #nativefs.
URL dieses Artikels:http://www.heise.de/-4505949
Links in diesem Artikel:[1] https://developers.google.com/web/updates/2019/08/native-file-system[2] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[3] https://wicg.github.io/native-file-system/[4] https://www.heise.de/developer/artikel/Contacts-Picker-API-Kontakte-Zugriff-fuer-Progressive-Web-Apps-4493480.html[5] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[6] https://discourse.wicg.io/t/writable-file-api/1433
Copyright © 2019 Heise Medien
"Ich bin Guybrush Threepwood, ein mächtiger Pirat." Die selbstbewusste Vorstellung des Helden von "The Secret of Monkey Island" stimmt nicht ganz, denn Guybrush will erst noch einer werden.
Tief im Herzen der Karibik. Die Insel Mêlée Island – so fängt wohl eines der berühmtesten Adventures der Computerspielegeschichte an. Das c't-zockt Team spielt das Retro-Game heute ab 18 Uhr live.
Der Held mit dem bemerkenswerten Namen Guybrush Threepwood möchte Pirat werden. Einfach machen es ihm die Piraten-Anführer von Mêlée Island nicht; sie stellen der Landratte drei schwere Aufgaben. Doch damit fängt das Abenteuer erst an, in dem der üble Geisterpirat LeChuck und die schöne Gouverneurin Elaine die Hauptrollen spielen.
Viele Kritiker sehen Monkey Island 1 als eines der besten Adventure-Spiele überhaupt an. Das 1990 zuerst erschienene Adventure von Lucasfilm Games – später in LucasArts umgenannt – stammt von Computerspiele-Legende Ron Gilbert, der seine Version der Pirates of the Caribbean zusammen mit Tim Schafer umsetzte. Obwohl Guybrush zahlreiche Gefahren bestehen und Degenkämpfe ausfechten muss, kann er im Spiel nicht sterben, denn alles hängt vom Rätselgeschick des oder der Spieler ab. Bei Zweikämpfen etwa zählen nicht die Körpertreffer, sondern die richtigen Beleidigungen.
Das Spiel war dermaßen erfolgreich, dass außer vier Sequels auch eine Special Edition mit komplett überarbeiteter Grafik, moderner Spielsteuerung und besserem Sound inklusive Sprachausgabe entstand. Dabei legten die Entwickler Wert auf akkurate Umsetzung des Spiels. Das geht so weit, dass man an beliebigen Stellen per Tastendruck auf die alte Pixelgrafik inklusive Original-Steuerung umschalten kann.
Das Team von c't zockt begibt sich am heutigen Donnerstag ab 18:00 Uhr live auf Zeitreise ins eigene Gedächtnis – klar haben wir Monkey Island alle gespielt, aber das ist lange her – und tief in die Karibik. Wir versuchen, mit Guybrush Threepwood die schöne Elaine vor dem garstigen LeChuck zu retten – wenn wir an den bissigen Piranha-Pudeln vorbeikommen. ()
URL dieses Artikels:http://www.heise.de/-4496089
Links in diesem Artikel:[1] https://www.heise.de/bilderstrecke/bilderstrecke_4497060.html?back=4496089;back=4496089[2] https://www.heise.de/bilderstrecke/bilderstrecke_4497060.html?back=4496089;back=4496089[3] mailto:rop@ct.de
Copyright © 2019 Heise Medien
[unable to retrieve full-text content]
Dank Digitalisierung sind Software und IT für die Wettbewerbsfähigkeit entscheidend. Oder ist das IT-Chauvinismus?
Viele Produkte sind mittlerweile reine Software oder Software definiert zumindest wesentliche Eigenschaften. Ein Software-Update reichte aus, um Teslas Autos mit besserem Beschleunigungsvermögen auszustatten. Fahrassistenten der Teslas werden ständig verbessert. Ein Software-Update könnte eines Tages sogar autonomes Fahren ermöglichen. Wenn solche wichtigen Features, aber auch die Fahrleistungen "nur" von Software abhängen, dann ist diese selbst für so physische Produkte wie Autos entscheidend. Wer schneller und besser Software entwickelt, wird über kurz oder lang die besseren Produkte haben und wettbewerbsfähiger sein.
Dazu kommt, dass viele Geschäftsprozesse mittlerweile durch Software umgesetzt werden. Wer also seine Geschäftsprozesse optimieren will, muss am Ende Software schreiben. Auch hier gilt: Wer die Softwareentwicklung besser beherrscht, kann Prozesse besser optimieren und so wettbewerbsfähiger werden.
Viele Softwareexperten sagen, dass die Qualität der Software und die Codequalität entscheidend für die Änderbarkeit der Software und damit den wirtschaftlichen Erfolg eines Unternehmens sind. Nach einiger Zeit in der IT-Branche beobachtet man aber, dass wirtschaftlich erfolgreiche Unternehmen oft große Herausforderungen in ihren IT-Systemen haben. Eine offensichtliche Beziehung zwischen Softwarequalität und wirtschaftlichem Erfolg scheint es nicht zu geben. Warum?
Eine mögliche Erklärung ist, dass Marktmechanismen Zeit benötigen, um zu greifen. Wer zu wenig in IT und Software investiert, der wird vom Markt gefegt, aber das kann einige Zeit dauern. Mitwettbewerber werden mit überlegener IT schneller Features ausrollen, Marktanteile gewinnen, und dann ist es zu spät. Also müssen sich Unternehmen mit einer hervorragenden IT früher oder später durchsetzen.
Wer seine IT nicht ausreichend optimiert, kann sich schon mal einen geeigneten Insolvenzverwalter suchen. Damit ist der Sieg von besserer IT und überlegenen Softwareentwicklungsansätzen wie Agilität unausweichlich. Es erscheint aber oft nicht so, als würden diese Marktmechanismen wirklich so effektiv wirken. Daher muss es auch andere Erklärungsmöglichkeiten geben.
Vielleicht ist die Wahrnehmung der IT einfach falsch. IT-Experten finden IT wichtig, weil es ihr Bereich ist. Sie beschäftigen sich tagtäglich mit ihr. Wenn IT für einen persönlich so wichtig ist, nimmt man schnell an, dass es für alle wichtig sein muss. In einem Projekt habe ich die Aussage gehört, dass man im Notfall das Unternehmen ohne Fachbereich weiterführen kann, weil die IT die Prozesse ja sowieso am besten versteht. Das war zwar scherzhaft gemeint, zeigt aber, wie wichtig sich die IT teilweise nimmt.
Wenn IT für den Geschäftserfolg nicht entscheidend ist, dann muss es andere Dinge geben, die zum Erfolg oder Misserfolg eines Unternehmens führen. Und zwar muss es sie selbst dann geben, wenn das Produkt IT-getrieben ist. Ein Beispiel ist die Finanzbranche: In ihr ist eigentlich alles nur IT und Daten. Ein Konto, ein Depot oder eine Versicherungspolice haben anders als ein Auto keine physische Ausprägung, sondern existieren nur als Teil eines IT-Systems.
Also sollte alles ganz einfach sein: Fin-Tech-Start-up gründen, ein neues IT-System aufbauen und so unbelastet von der Legacy der etablierten Konkurrenz schnell neue Features ausliefern und den Markt aufrollen. In der Finanzbranche sind aber ganz andere Faktoren entscheiden: Finanzen, Versicherungen und Banken sind Vertrauenssache. Nicht jeder vertraut einem frischen, hippen Unternehmen sein Geld an. Ich kann mir beispielsweise nicht vorstellen, dass meine Eltern jemals von der Bank, bei der sie jetzt schon viele Jahrzehnte sind, zu einer anderen Bank wechseln. Wenn ein Fin-Tech-Start-up sie als Kunden gewinnen will, muss ein etabliertes Finanzunternehmen, bei dem sie bereits Kunden sind, die Produkte für das Start-up vertreiben. Ein lange am Markt präsentes Unternehmen genießt auch bei anderen Kunden sicherlich mehr Vertrauen als ein neues Start-up.
Demnach ist IT sogar in der so virtuellen Finanzbranche nicht der alleinige Faktor für eine bessere Wettbewerbsfähigkeit. Vielleicht ist es noch nicht einmal der Wichtigste. Das sollten wir IT-Experten im Hinterkopf behalten, denn es ist nur natürlich, die eigene Tätigkeit wichtiger zu finden, als sie tatsächlich ist. Außerdem dürfen wir Investitionen in IT nicht nur mit Wettbewerbsfähigkeit begründen oder gar darauf hoffen, dass sich bessere IT wegen der Marktmechanismen von selbst durchsetzt.
Vielen Dank an meine Kollegin Anja Kammer für die Kommentare zu einer früheren Version des Artikels.
IT ist oft weniger wichtig für den Erfolg eines Unternehmens, als wir IT-Experten denken.
URL dieses Artikels:http://www.heise.de/-4494332
Copyright © 2019 Heise Medien
Im modernen Web stehen viele sehr mächtige Schnittstellen zur Verfügung, die Webanwendungen Zugriff auf Funktionen erlauben, die man früher nur nativen Anwendungen zugerechnet hätte. Eine Schnittstelle, die dem Web bislang noch fehlte, ist eine API zum Zugriff auf das Adressbuch des Anwenders. Mit der Contacts Picker API befindet sich diese nun in Spezifikation [1].
Die Schnittstelle befindet sich gerade im Entwurfsprozess bei der Web Incubator Community Group (WICG) des W3C; der API-Entwurf findet sich auf GitHub [2]. Die Contacts Picker API erlaubt einen eingeschränkten, lesenden Zugriff auf das Adressbuch des Anwenders: Der Anwender kann einen oder mehrere Kontakte auswählen, deren Daten (wahlweise Name, Telefonnummern und/oder E-Mail-Adressen) mit der Website geteilt werden sollen. Nützlich ist diese Schnittstelle etwa für E-Mail-Clients, soziale Netze und andere Anwendungen, die Zugriff auf Kontaktdaten Dritter benötigen.
Als Teil der Project-Fugu- beziehungsweise Capabilities-Schnittstellen [3] wird die Contacts Picker API ab Google Chrome 77 für Android (erscheint im September) erstmals für ein begrenztes Publikum bereitgestellt [4]. Das Vorhandensein der Schnittstelle kann wie folgt geprüft werden. Steht die API nicht zur Verfügung, müssen Anwendungen die Kontaktdaten auf einen anderen Weg einholen, etwa per HTML-Formular.
if ('contacts' in navigator && 'ContactsManager' in window) {
requestContacts();
}
Steht die Schnittstelle zur Verfügung, kann auf dem ContactsManager (unter navigator.contacts) die Methode select() aufgerufen werden. Diese nimmt zwei Parameter entgegen: Einmal eine Auflistung der gewünschten Kontakteigenschaften (derzeit name für den Namen, email für E-Mail-Adressen und tel für Telefonnummern) sowie optional ein Konfigurationsobjekt, über das derzeit allein die Mehrfachauswahl von Kontakten angefordert werden kann.
const contacts = await navigator.contacts.select(['name', 'email', 'tel'], { multiple: true });
Daraufhin erscheint die Benutzeroberfläche des Contacts Picker. Die Methode gibt bei Aufruf ein Promise zurück, das mit der Liste der gewählten Kontakte auflöst, sobald der Anwender die Kontaktauswahl bestätigt. Bricht der Anwender den Auswahldialog ab, wird eine leere Liste zurückgegeben. Sind die Kriterien zur Anzeige des Dialogs nicht erfüllt, wird das Promise abgewiesen.
Die Kontaktauswahl kann nur als Ergebnis einer Benutzerinteraktion, also eines Klicks auf eine Schaltfläche oder nach einem Tastendruck ausgelöst werden. Das verhindert das automatische Öffnen der Benutzeroberfläche ohne Zutun des Anwenders. Darüber hinaus muss die Website über eine gesicherte Verbindung (HTTPS) ausgeliefert werden, und der Aufruf darf nur aus dem Top-Level-Browsingkontext, also etwa nicht aus einem IFrame heraus geschehen.
Außerdem steht der Datenschutz des Anwenders im Fokus: Die Contacts Picker API erlaubt keinen vollständigen Zugriff auf das Adressbuch des Anwenders, sondern nur auf die ausgewählten Kontakte. Apps können also nicht das komplette Adressbuch des Anwenders auswerten. Unterstützt werden derzeit nur Name, E-Mail-Adressen und Telefonnummern – nicht etwa Geburtsdaten oder postalische Adressen. Der Anwender kann sich auch dafür entscheiden, nicht alle angeforderten Kontaktdetails mit der Website zu teilen. Es ist derzeit kein manipulierender Zugriff möglich, sondern ein rein lesender. Ebenso kann die Erlaubnis des Anwenders nicht persistiert werden: Sollen dieselben Kontakte wieder geteilt werden, müssen diese abermals über die Benutzeroberfläche ausgewählt werden.
Noch können nicht alle Websites auf die neue API zugreifen. Getreu des Google-Prozesses zur Bereitstellung neuer Webschnittstellen wird die Schnittstelle zunächst über die sogenannte Origin-Trial verfügbar gemacht. Webentwickler können ein Token beziehen, das die Verwendung der API unterhalb einer Origin (Kombination aus Protokoll, Hostnamen und Port) zu Testzwecken erlaubt.
Optional kann die grundsätzliche Verwendung der API über chrome://flags aktiviert werden, die Einstellung heißt dort #enable-experimental-web-platform-features. Die Origin-Trial für die Contacts Picker API beginnt mit Google Chrome für Android in Version 77 und verbleibt dort voraussichtlich bis Version 80. Mit Chrome Beta unnd Chrome Canary kann die Schnittstelle schon heute ausprobiert werden, zum Beispiel über die Demoseite zur API [5]. Das Chrome-Team ruft Entwickler dazu auf, ihr Feedback zur Schnittstelle etwa über das Forum der WICG [6] mitzuteilen.
URL dieses Artikels:http://www.heise.de/-4493480
Links in diesem Artikel:[1] https://wicg.github.io/contact-api/spec[2] https://github.com/WICG/contact-api[3] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[4] https://developers.google.com/web/updates/2019/08/contact-picker[5] https://glitch.com/~contact-picker[6] https://discourse.wicg.io/t/proposal-contact-picker-api/3507
Copyright © 2019 Heise Medien
Das Multiplayer-Spiel "We Need To Go Deeper" hat die Early-Access-Phase hinter sich gelassen. Das fertige Spiel gibt es auf Steam für Linux, macOS und Windows.
Aus dem Unterwassergraben "The Living Infinite" ist noch kein U-Boot wieder aufgetaucht, doch das schreckt Dich und Deine Crew nicht. Im nun als Version 1.0 vorliegenden Spiel steuert man ein U-Boot in möglichst große Tiefen. Das klappt nur im Team: Ein Spieler steuert, einer übernimmt den Schießstand (an Gefahren und Monstern herrscht kein Mangel), weitere Spieler bedienen den Maschinenraum, flicken Lecks in der Bordwand oder bekämpfen Eindringlinge.
"We Need To Go Deeper" von Deli Interactive startete 2017 als Early-Access-Spiel auf Steam am 8. Februar – Jules Vernes Geburtstag. Der Einfluss der SciFi-Klassiker prägt das witzige Spiel, was man nicht erst bemerkt, wenn plötzlich H. G. Wells Zeitreisender an Bord auftaucht. Das c't-zockt-Team hat die Early-Access-Version zuletzt Ende 2018 getestet [1]. In der Entwicklungszeit hat Deli Interactive regelmäßig neue Inhalte hinzugefügt. Bis zur nun veröffentlichten Version 1.0 waren es den Entwicklern zufolge 112 Updates.
Deli Interactive will die Tastatur aber nicht gleich in die Ecke werfen und hat weitere Inhalte angekündigt. Dabei will das Studio wie schon in der Vergangenheit auch Anregungen aus der Spieler-Community umsetzen.
Die übliche Preiserhöhung für die fertige Version von We Need To Go Deeper bleibt moderat: Statt 10 Euro bekommt man das Spiel bei Steam nun für 13,29 Euro [2] und zusammen mit dem DLC "Buried Treasure" für 16,51 Euro. Wer das Spiel während der Early-Access-Phase gekauft hat, bekommt das DLC automatisch und gratis. Das Spiel läuft nicht nur unter Windows, es gibt auch Versionen für Linux und macOS – bei der Crew-Zusammenstellung ist man also nicht auf eine Plattform beschränkt.
Das Team von c't zockt lässt sich die fertige Version von "We Need To Go Deeper" natürlich nicht entgehen: Am kommenden Donnerstag, den 8. August geht es ab 18 Uhr auf Twitch [3] und Youtube [4] wieder abwärts auf der Suche nach Ruhm, sagenhaften Schätzen, fremden Unterwasserkulturen und unbekannten Gefahren. Haltet Eure Rohrzangen bereit, es gibt wieder viele Lecks zu stopfen ...
()
URL dieses Artikels:http://www.heise.de/-4486610
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/We-Need-To-Go-Deeper-c-t-zockt-Live-Expedition-in-die-Tiefsee-ab-17-Uhr-4221261.html[2] https://store.steampowered.com/app/307110/We_Need_To_Go_Deeper/[3] https://www.twitch.tv/ctzockt[4] https://www.youtube.com/ctzockt[5] mailto:rop@ct.de
Copyright © 2019 Heise Medien
