Anmelden
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Android feiert 10. Geburtstag und die besten Smartphones 2018 sind fast alle vorgestellt: Zeit für eine Bilanz und einen Blick nach vorne.
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
Nur noch 20 Sekunden Sauerstoff! Schaffe ich es, die Lebenserhaltung zu reaktivieren? Im Adventure "Deliver Us The Moon" kämpft der letzte Astronaut um sein Leben und um die Rettung der Menschheit.
Das Indie-Adventure Deliver Us The Moon: Fortuna spielt in einer Zukunft, in der die Energiereserven der Erde verbraucht sind. Mittlerweile gibt es eine Siedlung auf dem Mond und eine neue Energiequelle, die den Fortbestand der Menschheit sichern soll. Über ein Energieübertragungsnetz wird die Erde vom Mond aus versorgt – bis eines Tages das Licht ausgeht. Vom Mond kommt kein Lebenszeichen mehr. Und keine Energie.
Jahre nach dem Blackout wagen die wenigen verbliebenen Mitarbeiter der World Space Agency einen verzweifelten Rettungsversuch: Der Spieler schlüpft in die Rolle eines WSA-Astronauten, der mit der letzten verbliebenen Rakete zum Mond fliegen soll mit dem Auftrag: Deliver Us The Moon.
Das Adventure stammt von dem kleinen niederländischen Entwicklerteam KeokeN Interactive [1], die sich 2016 über eine Kickstarter-Kampagne [2] erfolgreich finanziert haben und Ende September 2018 den ersten Teil "Fortuna" des Adventures Deliver Us The Moon auf Steam veröffentlicht haben. Schon 2015 hatten sie in der Indie Arena auf der Gamescom mit der detailreichen Grafik des Spiels für Aufsehen gesorgt. Die ist wirklich sehenswert.
Als erste Aufgabe muss der Spieler die Rakete startklar machen, wobei nur eine Kollegin per Funk einige Anweisungen gibt und vor einem nahenden Staubsturm warnt. Der Sturm ist dann auch dafür verantwortlich, dass der Kontakt mit dem Kontrollraum kurz nach dem Start abbricht. So ist der Astronaut auf sich alleine gestellt. Auf ihn warten zahlreiche Aufgaben wie das Ankoppeln an die Station Kilometer über der Mondoberfläche und die Aktivierung der Lebenserhaltung. Einige Aufgaben lassen sich entspannt erledigen, bei anderen zählt jede Sekunde – meist, weil die Luft knapp wird.
Neben den dringenden Aufgaben muss der Spieler Hinweise auf den Verbleib der Stationsbesatzung und auf die Ursache des Blackouts sammeln. Die Handlung ist – typisch für ein Adventure – linear, hält aber einige Überraschungen bereit. So findet der Spieler im weiteren Verlauf einen kleinen, ASE genannten Roboter als Sidekick.
Das Adventure überzeugt mit seiner sehenswerten Grafik und dichter Atmosphäre, die trotz Monstermangel teilweise an Alien erinnert. Die Energiestation ist in ihrer Dreidimensionalität der ISS nachempfunden. Die Steuerung über die Tastatur lässt sich leider nicht ändern – bei der Bewegung in Schwerelosigkeit helfen abgesehen von WASD weitere Tasten. Glücklicherweise unterstützt das Spiel auch Gamepads.
Stirbt man bei einer schwierigen oder zeitkritischen Aufgabe, geht es ab dem letzten Speicherpunkt weiter. Diese bestimmt allerdings das Spiel, eine manuelle Speicherfunktion gibt es nicht. Oft bleibt deshalb nur, die letzen Schritte noch einmal durchzuspielen.
Die Grafik von Deliver Us The Moon basiert auf der Unreal-4-Engine. Die erste Episode Fortuna läuft derzeit nur auf Windows-PCs (mindestens Windows 7, DirectX 11) und kostet auf Steam [5] rund 20 Euro. Auf Kickstarter hatten die Entwickler auch eine Version für die XBox in Aussicht gestellt. Geplant sind insgesamt fünf Episoden – der Mond wird also noch einige Überraschungen bereithalten.
()
URL dieses Artikels:http://www.heise.de/-4188115
Links in diesem Artikel:[1] https://www.deliverusthemoon.com/[2] https://www.kickstarter.com/projects/keoken/deliver-us-the-moon?lang=de[3] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4187955.html?back=4188115[4] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4187955.html?back=4188115[5] https://store.steampowered.com/app/428660/Deliver_Us_The_Moon_Fortuna/[6] mailto:rop@ct.de
Copyright © 2018 Heise Medien
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
Mehr Infos zu den heutigen Themen:
Google Plus: https://heise.de/-4183950
Linux: https://heise.de/-4183628
Portal und Portal+: https://heise.de/-4183638
Funk für Ampeln: https://heise.de/-4183853
Mehr Infos zu den heutigen Themen:
Fachkräftemangel: https://heise.de/-4182854
Mobilfunkversorgung: https://heise.de/-4182625
British Airways: https://heise.de/-4183263
Rechtspopulist Jones: https://heise.de/-4158441
"Ein Computer auf jedem Schreibtisch und in jedem Haushalt" -- das prognostizierte Microsoft-Gründer Bill Gates in den siebziger Jahren; und er behielt recht. Inzwischen verdrängt eine immer größere werdende Armada von spezialisierten, "smarten" Geräten den klassischen PC; die Verkaufszahlen von Desktops und Notebooks sinken seit Jahren.
Ist der PC nun dem Tode geweiht? Oder wird er auch in zehn Jahren noch so relevant sein wie heute? Über dieses saukontroverse Thema diskutieren Carsten Spille und Jan-Keno Janssen vom c't Magazin mit Fabian Scherschel von heise online und Robert Thielicke von Technology Review.
Die c't 21/18 gibt's am Kiosk, im Browser und in der c't-App für iOS und Android.
Alle früheren Episoden unseres Podcasts gibt es unter www.ct.de/uplink.
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
Komplexität ist die zentrale Herausforderung in der Softwareentwicklung. Daher gilt es, immer bestrebt sein, Komplexität zu eliminieren. Schließlich sollten wir immer lieber einfache Probleme lösen wollen als komplexe. Aber manchmal beten wir Komplexität an – und das kann Komplexitätsprobleme unlösbar machen.
In der Softwareentwicklung geht es nur scheinbar ums Programmieren. Einen Zehnzeiler kann jeder schreiben. Das Problem sind komplexe Systeme. Wenn ein System so groß ist, dass ein einzelner Mensch allein es nicht verstehen und weiterentwickeln kann, sind Konzepte wie Modularisierung entscheidend. Modularisierung teilt das System in kleine Einheiten auf, die ein Mensch weiterentwickeln kann. Dann wird Komplexität entscheidend. Aber bei solcher Komplexität können Einzelpersonen keine Projekte mehr durchführen, sondern nur noch Teams. Das führt zu organisatorischen Herausforderungen.
Wichtig ist in diesem Zusammenhang das Gesetz von Conway [1]. Es besagt, dass die Architektur eines Systems die Kommunikationsstrukturen der Organisation abbildet, die das System umsetzt. Für jedes Modul in der Software gibt es also eine Einheit in der Organisation und für jede Kommunikationsbeziehung zwischen Organisationseinheiten eine Abhängigkeit zwischen den Modulen in der Software.
In Conways Paper von 1968 ist aber noch etwas anderes beschrieben: Wenn eine Organisation ein großes System entwickeln will, dann muss sie viele Leute in das Projekt holen. Da Kommunikation in einem großen Team schwierig ist, bricht sie ab einer bestimmten Teamgröße zusammen. Da Kommunikation und Architektur sich gegenseitig beeinflussen, führt die mangelhafte Kommunikation zu einer chaotischen Architektur und zusätzlicher Komplexität.
Conway geht aber weiter: Offensichtlich sollte man sich, wenn irgend möglich, auf elegante Lösungen fokussieren, die ein kleines Team umsetzen kann. Aber das Prestige eines Managers hängt von der Größe des Teams und des Budgets ab, für das er oder sie zuständig ist, so Conway. Daher wird ein Manager möglichst ein großes Team und ein großes Budget anstreben.
Das scheint zunächst kein Problem zu sein. Wenn das Projekt eigentlich mit einem kleineren Team gelöst werden kann, sitzen eben einige rum. Das kostet Geld, gefährdet aber Projekt und Architektur nicht. Conway sagt aber, dass das Parkinsonsche Gesetz [2] zuschlägt. Parkinson erklärt mit dem Gesetz, warum einige Verwaltungen zwar mehr Mitarbeiter einstellen, aber trotzdem nicht mehr leisten. Dieses Gesetz besagt, dass eine Aufgabe die zur Verfügung stehende Zeit aller Mitarbeiter vollständig ausfüllt. Auch wenn die Aufgabe einfach und schnell bearbeitet werden kann, beteiligen sich immer mehr Personen daran, bis alle Personen in der Organisation mit Arbeit versorgt sind. In einem Software-Projekt werden also alle Teammitglieder an dem Projekt arbeiten, unabhängig davon, ob das notwendig ist. Dementsprechend wird dann die Organisation groß werden, die Kommunikation gegebenenfalls zusammenbrechen und die Architektur chaotisch werden
Die Erkenntnis von Conway, die mittlerweile 50 Jahre alt ist, ist vor allem interessant, weil sie eine Erklärung dafür sein kann, wenn ein großes wichtiges Projekt eine schlechte Architektur hat und schwer weiterentwickelt werden kann.
Die Manager aus diesem Paper beten Komplexität an, ohne dass ihnen das klar ist. Sie wollen ein möglichst großes Team und machen so ein Problem zu komplex, weil eine große Organisation die Architektur zusammenbrechen lassen kann.
Aber nicht nur Manager, sondern auch wir Softwarearchitekten beten manchmal Komplexität unbewusst an. Das passiert beispielsweise, wenn wir unreflektiert Patterns wie Event Sourcing, Architekturen mit vielen Schichten oder Microservices nutzen, ohne den Nutzen in dem spezifischen Kontext und die Komplexität genügend abzuwägen.
Auch der Technologie-Spieltrieb kann zu überbordender Komplexität führen. Schließlich suchen wir alle technische Herausforderungen und wollen besonders spannende Projekte umsetzen. Dazu sind moderne Ansätze und besonders komplexe Systeme gut geeignet. Ebenso lösen wir manchmal technische Probleme, die sich eigentlich gar nicht stellen. So entstehen sehr generische oder skalierbare Lösungen, die von den tatsächlichen Anforderungen so nicht gefordert werden und dadurch zu viel Komplexität erzeugen.
Ein besonders krasser Fall von Komplexitätsanbetung ist die Aussage "Das funktioniert bei uns nicht. Unsere Herausforderungen sind viel größer als die von Amazon oder Google." Ich habe das schon von Mitarbeitern unterschiedlicher Unternehmen gehört. Solche Äußerungen sind verwunderlich: Unternehmen wie Amazon oder Google betreiben ausgesprochen komplexe IT-Systeme und ihr wirtschaftlicher Erfolg hängt unmittelbar von diesen IT-Systemen ab. Sie gehören nicht zuletzt wegen dieser IT-Systeme zu den wertvollsten Unternehmen der Welt.
Auf den ersten Blick kann man die Äußerungen als Abwehrhaltung interpretieren: Amazon und Google haben eine moderne Organisation und eine Cloud-Infrastruktur, aber in der noch viel komplexeren Umgebung des Unternehmens geht das alles leider nicht. Aber vielleicht schwingt Stolz mit, denn schließlich kümmert man sich um nahezu beispiellose Herausforderungen. So oder so gilt auch hier: Die Komplexität hat zwar natürlich Nachteile, aber eben auch den Vorteil, dass man sich eben mit bestimmten Ansätzen wie Cloud, Continuous Delivery oder Microservices nicht beschäftigen muss, weil das ja eh nicht geht.
Es ist also fraglich, ob wir Komplexität wirklich immer vermeiden. Sich nur auf Techniken zu konzentrieren, Entwürfe möglichst einfach und elegant zu machen, nützt nichts, wenn wir unbewusst Komplexität doch anbeten. Deswegen ist es wichtig, sich über diese unbewussten Mechanismen klar zu werden. Natürlich gibt es dennoch viele komplexe Probleme, die tatsächlich schwer zu lösen sind.
Vielen Dank an meine Kollegen Jens Bendisposto, Jochen Christ, Lutz Hühnken, Michael Vitz und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
In der Softwareentwicklung geht es vor allem darum, Komplexität zu handhaben. Am besten wäre es, Komplexität gleich zu vermeiden. Aber leider kommt es manchmal zur – bewussten oder unbewussten – Komplexitätsanbetung, die zu unnötig komplexen Systemen führt.
URL dieses Artikels:http://www.heise.de/-4170914
Links in diesem Artikel:[1] http://www.melconway.com/Home/Committees_Paper.html[2] https://de.wikipedia.org/wiki/Parkinsonsche_Gesetze
Copyright © 2018 Heise Medien
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
[unable to retrieve full-text content]
Heute mit: Facebook, openWB, Uber, Deutschlandradio
Immer mehr Haushalte können schneller ins Internet. Aber welche Technik ist dafür zuhause nötig und was lässt sich aus dem Internetzugang herausholen?
FreshRSS