Eine Homepage hier, eine Infoseite da,…
Mal ehrlich: Webtechnologien werden zum Großteil relativ einseitig genutzt -> zum Transport, Anzeigen und teilweise auch zum Generieren von Content.
Keine Frage: kleine, mittlere und große Agenturen, genauso wie auch “one-man-shows zum Erstellen von Internetseiten” sind ein gut funktionierendes Business – weil jedes Unternehmen heute einen oder mehrere gute Webauftritt(e) benötigt.
Aber es ist definitiv nicht das innovativste Business.

Auch wenn die Vermittlung und Strukturierung von Inhalten, die grafische Darstellung und die Benutzerfreundlichkeit bei jedem Projekt immer wieder eine neue Herausforderung darstellen..
Und auch, wenn kaum eine Seite oder ein Portal wirklich je komplett wie das andere ist (obwohl sich viele Dinge schon sehr einander annähern und der Mut zum Neuen oftmals der Sicherheit des bewährtem Einheitsbreies weicht) -> Letztendlich greifen die meisten Seiten im Internet auf dieselben (bewährten) Technologien und Techniken zurück.

Klar.. HTML und CSS zur inhaltlichen und grafischen Aufbereitung. Da gibt es nicht viel zu rütteln. Wobei es gerade schon bei CSS beginnt, dass bei Webentwicklern oftmals immer wieder dieselben Attribute Verwendung finden, statt sich auch einmal an “exotischere/neuere” Dinge zu wagen.

Ein Hauptgrund dabei, ist die Bestrebung (und meist Notwendigkeit) immer zu allen gängigen Browsern (auch zu älteren Versionen) kompatibel zu bleiben.
Damit gilt: während sich Webtechnologien, seit dem Aufkommen von HTML 5, in rasantem Tempo weiterentwickeln, hinkt die Nutzung neuer Dinge meist jahrelang hinterher.

Manchmal eben wegen benötigter Abwärtskompatibilität. Manchmal, weil die zur Verfügung gestellten neuen Technologien in erwähntem herkömmlichen Kontext – also traditionellen Webseiten – einfach gar nicht benötigt werden.
Wer benötigt schon wirklich WebGL 3D-Animationen (oder vielleicht sogar Interaktionen) auf einem reinen Informationsportal?
Manchmal aber auch, weil Webdeveloper mit bestimmten Neuerungen gar nicht erst in Berührung kommen und daher gar nicht wissen, dass es sie gibt.

Kein Wunder – reine WebApps (also interaktive Anwendungen, die ausschließlich über den Browser funktionieren) sind heute immer noch eher eine Nische -> vor allem im mobilen Bereich.
Viele “fancy technologies”, die mit HTML 5 kamen – und stetig dazu kommen – werden gar nicht erst evaluiert, da man bei “echten Anwendungen” dann doch eher auf der nativen (oder “hybriden”) Ebene bleibt.

Dabei könnten in den nächsten Jahren reine Webanwendungen eine echte Alternative zu herkömmlichen Apps bieten -> zumindest in manchen Anwendungsfeldern.
Die technologischen Möglichkeiten wachsen – längst schon sind Themen wie getrennte Ausführungs-Threads und das zur-Verfügung-stellen von offline Inhalten von allen modernen Browsern gut unterstützt.
Der Browser lässt daneben aber auch immer öfter direkte Kommunikation mit verbundener Hardware zu.
Umgehen mit Sensorendaten, Geräteinformationen und Connections zu externen Geräten/Beacons/…?
Vieles gibt es schon – und man kann schon fast sagen: was es noch nicht gibt, wird gerade standardisiert.

Das Thema Performance? Wenn man die Dinge nicht kennt, die sich in den letzten Jahren im Performance-Sektor von Webanwendungen getan haben, wird man überrascht sein, was da bereits seit einigen Jahren existiert, um JavaScript Code um ein gutes Stück schnell machen zu können (bei voller Abwärtskompatibilität).
Vor allem aber wurde in den letzten Jahren aber auch eine gänzlich neue Technologie entwickelt, die Webanwendungen performance-technisch auf ein neues Level bringen kann/soll. Eine Technologie, mit dem klingenden Namen “WebAssembly”, die mit dem Erscheinen von Safari 11, im vergangenen Monat (September 2017), bereits von allen aktuellen Browsern (Desktop und Mobile) unterstützt wird.
An dieser Stelle soll aber noch nicht gespoilert werden ;).

Es gibt viele Vorteile, welche sich aus reinen Webanwendungen ergeben, wie z.B. :

• Unabhängigkeit von herstellerspezifischen App-Stores
• direktes Anbieten von App-Services über die jeweiligen Homepages eines Unternehmens
• wegfallen der Notwendigkeit einer Installation (eine Hürde, die für viele Anwender oftmals immer noch sehr groß ist und daher keinesfalls unterschätzt werden sollte)
• […]

Damit wäre es nicht verwunderlich, wenn echte Webanwendungen in den nächsten Jahren – zumindest in einigen Einsatzgebieten – eine ernst(er) zu nehmende Konkurrenz zu nativen bzw. hybriden Anwendungen werden könnten -> gerade auch im mobilen Bereich.

In den kommenden Monaten wird sich diese 3-teilige Posting-Reihe mit “less known” Web Technologien (auf der Client Seite) beschäftigen.
Technologien, die sich entweder gerade noch in der Phase Standardisierung befinden (und daher von vielen Browsern noch gar nicht oder erst partiell/experimentell implementiert sind…).
Aber auch mit Technologien, die schon einen Schritt weiter sind, aber dennoch “wenig genutzt” bzw. dem “traditionellen Webentwickler” vielleicht einfach noch nicht richtig bekannt sind.

Dabei wird sich der erste Teil (im Folgenden) mit Technologien im Bereich “Communication & Media” beschäftigen. Der zweite Teil (im Dezember 2017) wird sich mit den Themen Offline Verfügbarkeit, Datenspeicherung und Threading befassen.
Der dritte Teil (März 2017) wird sich schließlich dem Thema “High-Performance” bei Webanwendungen widmen – und dort dann auch auf das zuvor angekündigte Thema „Webassemblies“ eingehen.
Ein Thema, das für jeden Web-Interessierten durchaus sehr spannend ist .
Das soll aber nicht heißen, dass im gleich Folgenden 1. Teil nicht auch etwas sehr Spannendes (hoffentlich noch für die meisten Leser relativ Unbekanntes) stecken sollte.

In jedem dieser drei Teile werden kurz unterschiedliche Technologien vorgestellt – wobei immer eine der vorgestellten Technologien (die schon etwas breitere Browserunterstützung genießt und damit bereits zum Basteln geeignet ist) etwas genauer behandelt wird.
Auf Basis dieser genauer vorgestellten Technologie wird in jedem Teil auch jeweils ein praktisches, selbst programmiertes, Beispiel vorgestellt.
Soviel sei verraten: In diesem Teil wird ein rein HTML5/JavaScript-basiertes Echtzeit-Schachspiel mit integriertem Videochat vorgestellt.

Es wird NICHT detailgenau auf die gesamte Programmierung dieser Beispiele eingegangen (das würde den Rahmen, zumindest bei dem ersten vorgestellten Beispiel, sprengen).
Aber es darauf eingegangen, wie die “Haupttechnologie”, die darin vorgestellt wird, verwendet wird.

Wichtig ist auch, dass in jedem Beispiel auch die vorgestellte “Haupttechnologie” aller vorhergehenden Teile mit einfließt.
Damit soll letztendlich in Teil 3 eine kleine, praktisch einsetzbare, Anwendung entstehen, die man aus App-Stores in unterschiedlichsten Ausführungen kennt.
Eine Anwendung , die sehr viele User in irgendeiner Form auf ihrem Smartphone installiert haben – die hier aber als wirklich reine WebApp umgesetzt werden soll und als solche noch kaum bis gar nicht bekannt sein dürfte.
Damit soll am Ende demonstriert werden, was moderne Browser heute bereits alles vollbringen können.

2. First Chapter: Communication & Media

Web NFC

Web NFC existiert bislang nur als Draft, verspricht allerdings eine Kommunikation mittels NFC direkt aus dem Webbrowser -> in beide Richtungen.
Das mag auf den ersten Blick vielleicht nicht notwendig erscheinen, da NFC im Consumer Bereich meist für sehr spezielle Anwendungsfälle (wie etwa bargeldloses Zahlen oder Entwerten digitaler Tickets) eingesetzt wird. Für diese Anwendungsfälle lädt man sich ohnehin meist zuvor eine spezifische App auf das Smartphone.

Wirft man aber einen zweiten Blick auf dieses Thema, könnte Web NFC dennoch einer breiteren Masse sehr nützlich werden:
NFC Tags sind günstig, lassen sich einfach an verschiedensten Objekten anbringen und können Daten speichern.
So könnte es künftig z.B. sein, dass NFC Tags klassische QR Codes ersetzen und man z.B. über eigene Webanwendungen, oder über die Webseiten von Unternehmen/Institutionen, standortspezifische Informationen abrufen kann bzw. Aktionen durchgeführt werden können.

Ein Beispiel: Ein Museum kann Inhalte zu seinen Ausstellungsstücken über das gewohnte CMS einpflegen. Man kann diese Inhalte über die Webseite manuell aufrufen. Geht man aber durch das Gebäude, wird anhand der NFC Tags automatisch der jeweilige Inhalt geladen. Gerade bei Museen und Ausstellungen möchte man sich oft nicht immer eigene Apps runterladen.

Kurzer Überblick über die API
Wie bereits angedeutet, wird die API bislang von keinem Browser offiziell unterstützt. Die Drafts zur Spezifizierung/Standardisierung sehen folgende zwei Core-Funktionen vor, um einerseits Daten über NFC auszulesen bzw. andererseits Daten zu übertragen:

navigator.nfc.watch(callback, options)
 Registers for a notification about the data read from the NFC adapter specified by options.

navigator.nfc.push(message, options)
 Triggers sending the message (string, ArrayBuffer or NDEF record structure) to the NFC adapter specified by options.

Web Bluetooth API

Wohl ein wenig bekannter und auch weiter entwickelt ist die Web Bluetooth API.

In Chrome ist diese API bereits implementiert – auch wenn nicht auf jedem Betriebssystem alle Funktionen verfügbar sind (siehe hier: https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md ).

Grundsätzlich kann man mit der API, z.B. mittels Einsatz von Bluetooth Beacons, auch sehr ähnliche Szenarien abbilden, wie mittels NFC.
Ihre Stärke spielt die Web Bluetooth API aber dabei aus, den Browser direkt mit Bluetooth bzw. Bluetooth LE Geräten kommunizieren lassen zu können.
Das mag auf den ersten Blick etwas unnötig erscheinen, wenn man an die üblichen Bluetooth-Geräte denkt: Mäuse, Tastaturen, Kopfhörer…
-> Denn diese sind ohnehin auf Betriebssystem Ebene installiert und die Inputs (also etwa die User Eingaben) bzw. Outputs (also etwa Audio-Daten für die Kopfhörer) werden über diese „Bridge“ übertragen, ohne dass der Browser hierbei irgendetwas spezielles leisten müsste.
Der Entwickler einer Webanwendung muss sich natürlich keine Gedanken machen, ob da letztendlich eine Bluetooth Maus verwendet wird, oder eine USB Maus, …

Interessant wird es aber, wenn man als Entwickler mit Services eines Bluetooth-Devices interagieren möchte, über die keine Standardbrücke durch das OS gelegt wird.
Und hier sind die Anwendungsfälle zahlreich. Moderne BluetoothLE Geräte verfügen über sogenannte „GATT-Services“.
Über diese Services können verschiedenste Werte/Daten von einem Gerät ausgelesen bzw. auch geschrieben werden – sogenannte „Characteristics“. Diese Characteristics können ihrerseits wieder über Properties verfügen.
Verfügt ein Characteristic über eine sogenanntes notification oder indicator Property, dann wird eine Änderung dieses Characteristics an den Client (in unserem Fall wäre das dann der Browser) mitgeteilt. In diesem Fall kann man z.B. EventHandler für relevante Characteristics definieren. Somit bekommt der Client (also hier der Browser) immer mit, wenn sich ein bestimmter Wert beim Sender verändert hat.

Ein Beispiel: Man verwendet etwa ein Arduino Board mit Temperatursensor, das zudem auch noch über Batterie betrieben werden kann. Dieses Board verfügt über einen BluetoothLE Sender. Hier könnte man nun zwei GATT Services implementieren: Einen für den Batteriestatus und einen für die gemessenen Temperaturwerte.
Der erste GATT Service könnte nun z.B. ein Characteristic enthalten, dass einen Wert für den momentanen Batteriestand darstellt – dieses verfügt über ein „indicate property“ und der Client kann daher bei einer Veränderung unmittelbar reagieren (z.B. dem Anwender den neuen Batteriestand ausgeben).

Ein anderes Characteristic von diesem Service könnte z.B. der maximal-Wert für die Batterie sein. Dieser verändert sich nicht und muss vom Client nur einmalig ausgelesen werden. Damit kann der Client auch immer prozentuell darstellen kann, wie voll die Batterie noch ist.

Das zweite GATT Service wäre in diesem Fall dann das „Interessante“ – es würde die gemessenen Daten des Temperatursensors als Characteristics zur Verfügung stellen… Also etwa die aktuelle Temperatur und eventuell auch die Luftfeuchtigkeit (je nachdem wie der Sensor funktioniert). Auf dieses Arduino Board können natürlich noch andere Sensoren platziert werden, die wiederum als eigene Services implementiert werden und ihr Werte als Characteristic zur Verfügung stellen und Änderungen bei diesen in aller Regel als notifications oder indicates sofort beim Client „melden“.

Damit ist der Browser plötzlich in der Lage, mit beliebigen externen Geräten zu kommunizieren und Daten zu empfangen (aber natürlich auch zu versenden) – ohne, dass er dafür über den Umweg eines Servers gehen müsste.

Kurzer Überblick über die API

navigator.bluetooth.requestDevice(serviceFilters)
 Scans for the device in range supporting the requested services. Returns a Promise.

device.gatt.connect()
 Returns a Promise resolved with the server object providing access to the services available on the device.

server.getPrimaryService(name)
 Returns a Promise resolved with the particular Bluetooth service on the device.

service.getCharacteristic(name)
 Returns a Promise resolved with the GATT characteristic object.

characteristic.readValue()
 Returns a Promise resolved with a raw value from the GATT characteristic.

characteristic.writeValue(value)
 Writes a new value for the GATT characteristic.

WebRTC

In Zeiten von Websocket-Verbindungen wirkt das klassische HTTP Request-Response Modell schon beinahe passé.
Kein Wunder – wurde das klassische Web „zu seiner Zeit“ ursprünglich eher als Medium konzeptioniert, das relativ statische Informationen auf Anfrage an den (anfragenden) Zielrechner übermitteln soll. Fertig.

Konzeptioniert und entwickelt zu einer Zeit, wo wahrscheinlich kaum jemand damit gerechnet hätte, wie sich die Anwendungen und Möglichkeiten des Webs – und auch die immer steigenden Anforderungen – des Mediums im Laufe der Zeit wandeln würden.
Vom statischen Informationsmedium hin, zu einem umfassenden, universellen, multimedialen Austausch- und Kommunikationsmedium.
Dabei muss an dieser Stelle unterschieden werden -> zwischen dem Internet, als reine technologische Infrastruktur (wie es auch in herkömmlichen Anwendungen, Spielen und Apps verwendet wird) und dem “Web”, das an dieser Stelle für Inhalte steht, die über das Internet klassisch mittels Browser konsumiert/ausgeführt werden.

Während ersteres theoretisch schon immer für alle Arten von Anwendungen herangezogen werden konnte (sieht man von hardwaretechnischen/infrastrukturellen Einschränkungen ab), hat sich letzteres Schritt für Schritt in “gesundem Maß” immer mit den Gegebenheiten weiterentwickelt.

Diese Weiterentwicklung war stets geprägt von drei Faktoren:

1. Die zur Verfügung stehenden Technologien/Ressourcen/Bandbreiten -> es war kein Zufall, dass in den Zeiten, als noch analoge Modems zur Einwahl ins Internet benutzt wurden, das zuvor genannte klassische Verfahren der HTTP-Request-Response entwickelt und  HTTP als DAS Internet-Protokoll etabliert wurde. Für einen kontinuierlichen Austausch von Daten war das Web in seinen Ursprüngen eher weniger gedacht.
2. Die Anforderungen -> wie bereits erwähnt: Zu Beginn des Internets/Webs, waren auch die Anforderungen ganz andere, als sie es heute sind. Doch mit steigenden Bandbreiten (und anderen Faktoren) haben sich auch die Wünsche/Anforderungen der Anwender weiterentwickelt. Und damit auch die Webtechnologien selbst.
3. Die Plattformunabhängigkeit -> Wichtig war dabei stets, dass Webtechnologien immer auf unterschiedlichsten Plattformen (und innerhalb dieser, auch auf unterschiedlichen Browsern) funktionieren. Mit dem Aufkommen der ersten Touch-Smartphones wurde diese Anforderung nochmals um einiges wichtiger.

Analysiert man nun etwa den zweiten Punkt, so merkt man, dass durch innovative Ansätze (wie etwa die “Entwicklung” von AJAX) versucht wurde – innerhalb der gegebenen Limitationen – Webanwendungen um einiges dynamischer zu gestalten, als sie es bis dahin waren.
Und sie somit an neuere Anforderungen anzupassen.
Spätestens mit Aufkommen von HTML 5 und dessen multimedialen Elementen,  ging der Trend allmählich schrittweise dazu, die ursprünglichen Ideen/Hintergründe des klassischen Webs aus technologischer und aus anforderungstechnischer Sicht neu zu bewerten.
Es galt/gilt vieles zu hinterfragen und die ursprünglichen Konzepte & Limitationen allmählich “aufzubrechen” un zu modernisieren.

Gerade wenn man auf die Kommunikationsfähigkeiten eines modernen Browsers blickt, sind/werden dessen Kommunikationswege wesentlich vielfältiger, als “nur” über HTTP eine Response zu einem Request zu erhalten oder sogar auch “nur” über WebSockets eine persistente (bidirektionale, realtime) Verbindung zu einem Server aufzubauen.
WebNFC und die Web Bluetooth API haben bereits gezeigt, dass Browser künftig (bzw. zum Teil bereits heute) weitaus mehr können, als „lediglich“ mit Servern zu kommunizieren.

Damit soll am Ende (als „Hauptattraktion“) dieses Artikels nun WebRTC nähergebracht werden – eine Technologie die zwar, wie HTTP oder Websockets, über IP kommuniziert (also anders als Web NFC, oder die Web Bluetooth API) – dabei aber wiederum gänzlich ohne Server auskommt.
Also: Peer to Peer IP Kommunikation… mittels Browser!

WebRTC ist immer noch relativ unbekannt, obwohl die erste veröffentlichte Spezifikation mittlerweile bereits 6 Jahre zurückliegt (2011).
Seitdem wurde WebRTC kontinuierlich weiterentwickelt – es hat allerdings bis zum September dieses Jahres (2017) gedauert, bis die Technologie endlich vollständig in den aktuellsten Versionen aller wichtigen Browser vollständig implementiert wurde (zuletzt Safari)

WebRTC steht für for Web Real-Time Communication. Es bringt Web Browsern unterschiedlicher Geräte die Möglichkeit, direkt zu kommunizieren.
Damit lassen sich einfache (text basierte) Nachrichten genauso austauschen, wie binäre Daten. Sogar Realtime-Streaming zwischen den beiden Endpunkten ist möglich.
Und tatsächlich ist sogar gerade Letzteres eines der Haupteinsatzgebiete, warum WebRTC ursprünglich ins Leben gerufen wurde: Der Austausch zwischen Audio und Video Daten in Echtzeit -> zwischen zwei Browsern… ohne Plugins und ohne Installationen.

Eine der interessantesten Nebeneffekte, als die relativ komplexe Spezifikation von WebRTC in ihrem ersten Entwurf veröffentlicht wurde, war die Integration eines Standards, der Browsern den Zugriff auf Kameras und Mikrofone ermöglichen sollte.
Unter der Spezifikation von WebRTC wurde die JavaScript Funktion navigator.getUserMedia() eingeführt. Mit dieser Funktion können Audio/Video Streams initialisiert werden.
Und obwohl diese Funktion in erster Linie implementiert wurde, um solche Streams mittels WebRTC an einen anderen Browser zu versenden, lassen sich alleine durch diese „Nebenfunktion“ des WebRTC-Standards auch noch ganz andere Anwendungsfälle realisieren.
Etwa ein „Record, View & Store“ Tool für Audio/Video Daten direkt aus dem Browser… oder sogar ganze Audio- und Imageprocessing Anwendungen (z.B. QR Code Scanner) im Browser.
Später wurde diese Funktion durch „navigator.mediaDevices.getUserMedia()“ ersetzt. Deren Syntax ist etwas anders als die ursprüngliche Version, jedoch blieben Zweck und Möglichkeiten unverändert.

Kurzer Überblick über „navigator.mediaDevices.getUserMedia()“

navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
     /* use the stream */
})

.catch(function(err) {
     /* handle the error */
});

Die Constraints geben an, was und wie es aufgezeichnet werden soll. Etwa:
Video, aber kein Audio

var constraints = { audio: false, video: true};

ODER: Video dabei mit einer Auflösung von 1280*720, kein Audio

var constraints = { audio: true, video: { width: 1280, height: 720 } };

 

Mit den Constraints lassen sich (je nach Browserversion/Status der Implementierung/Unterstützung durch Hardware und Betriebssystem) eine Vielzahl von Paramatern für das Audio/Video Capturing verwenden.
Etwa: Mindest-, Ideal- und Maximalauflösung des Videos, Framerate oder auch welches Mikro/welche Kamera verwendet werden soll, wenn mehrere vorhanden sind. Letzteres ist z.B. vor allem bei Mobile Devices wichtig (da diese meist über 2 Kameras verfügen).

Der erzeugte Stream lässt sich jetzt einer (zuvor aufgebauten) WebRTC Verbindung hinzufügen um ihn in Echtzeit zum anderen Endpunkt zu übertragen.
Eine solche, zuvor aufgebaute, WebRTC Verbindung wird durch ein Objekt (im folgenden Beispiel „RTCConnectionWithPeter“) dargestellt.

Beispiel:

navigator.mediaDevices.getUserMedia(constraints).then(function(stream) {
     RTCConnectionObjectWithPeter.addStream(stream);
})

Aufbauen einer WebRTC Connection – wirklich ganz ohne Server?

Wie zuvor bereits erwähnt, sind WebRTC Verbindungen Peer to Peer Verbindungen. Wird also wirklich kein Server benötigt?
Diese Frage lässt sich mit einem „Nein“ beantworten.
Während der Datenaustausch einer WebRTC Verbindung zwischen 2 Clients tatsächlich ohne weitere Zwischenstelle stattfindet, muss zum Aufbau dieser Verbindung zunächst ein sogenannter„ICE Server“ von beiden Stellen kontaktiert werden.

Von diesem ICE Server erhalten die Clients ein „ICE Candidate“ Objekt. Ein solcher ICE Candidate enthält Informationen darüber, wie zu einem Client eine Verbindung aufgebaut werden kann. Da sich die meisten Clients hinter Firewalls oder hinter Routern befinden, muss der ICE Server mit dem Client erst über einige komplexere Verfahren aushandeln, wie ein anderer Client später durch all diese Hürden eine Verbindung zu ihm aufbauen kann.
Dabei kommen Techniken wie „Hole Punching“ zum Einsatz, die etwa auch bei Online-Games eingesetzt werden.

Danach müssen jene zwei Clients, die miteinander kommunizieren möchten, ihre ICE Candidates austauschen.  Dieser Austausch erfolgt über einen sogenannten „Signal Server“. Ist das passiert, können die beiden Clients schließlich eine direkte Verbindung zueinander aufbauen.

Für all diese Schritte sind einige Funktionsaufrufe und Abfragen notwendig. Und natürlich das Vorhandensein eines ICE-, sowie eines Signal-Servers.
Zum Glück gibt es für diese Schritte mit „peer.js“ ein online Service mit entsprechender JavaScript API. PeerJS macht den Verbindungsaufbau über WebRTC sehr einfach.
Man kann den ICE und Signaling Service von „peer.js“ als Cloud nutzen, indem man einfach nur die Javascript API in die eigene Webseite einbindet und darüber die Verbindung aufbaut.
Oder man lädt sich die open source Server-Implementation (nodejs) von peer.js runter und führt diese selbst auf einem entsprechenden Server aus.

Ein Live-Beispiel

Für folgendes Live-Beispiel wurde peer.js verwendet. Der Servercode wird auf einem NodeJS Server über Microsoft Azure gehostet.
Das Live-Beispiel ist ein selbst programmiertes online Schachspiel mit integriertem Video Chat. Zwei Spieler können dabei in Echtzeit miteinander spielen und sehen sich gleichzeitig. Beliebig viele weitere Personen können das Spiel (momentan noch nicht den Videochat) der beiden verfolgen.
Alles ist gänzlich mit modernen Webtechnologien umgesetzt – ohne Plugins oder spezielle Erfordernisse.

LINK ZUM SPIEL: https://dm161564.students.fhstp.ac.at/WebChess/war/

Das Schachspiel selbst läuft über eine Websocket Verbindung und einen NodeJS Server. Die ersten beiden Besucher die eine Spielsession joinen, sind die Spieler. Diese bekommen jeweils einen individuellen Key zugesandt, mit dem sie sich beim PeerJS Server registrieren.
Außerdem erhalten sie jeweils den Key des anderen.

Dadurch sind sie im schließlich in der Lage, eine P2P Verbindung zueinander aufzubauen und Audio/Video Daten auszutauschen.

Der ganze Code für den Videochat ist letztlich sehr simpel:

function videoChat(sessionID,flag)
{
     peer = new Peer(sessionID+flag, {host: '888peerjsserver.azurewebsites.net', port: 443, path: '/myapp', secure: true});
     if (flag=="white")
     {
          peer.on('call', function(call)
          {
                 passiveCall(call);
          });
     }
     else
     {
                   activeCall(peer,sessionID);
     }
}

Die Funktion wird aufgerufen, sobald 2 Spieler mit dem Schachserver verbunden sind und dieser den Beiden das entsprechende Signal (über Websockets) sendet.

Beide erhalten dabei eine Spiel-SessionID und ein individuelles Flag. Mittels „new Peer“ registrieren sich beide am PeerJS Server.

Der erste Spieler (weiß) registriert schließlich den Eventhandler „on call“ für die Aufgebaute peer Verbindung.
Der zweite Spieler (schwarz) führt später die Funktion „activeCall“ aus, die den weißen Spieler anruft, worauf besagter Event bei ersterem ausgelöst wird.

Die Funktion activeCall:

function activeCall (peer,sessionID) {
            navigator.getUserMedia({video: true, audio: true}, function(stream) {
                    document.getElementById("displayMe").src =
                      URL.createObjectURL(stream);

                    document.getElementById("displayMe").play();
                    var call = peer.call(sessionID + "white", stream);
                    call.on('stream', function(remoteStream) { 
                             document.getElementById("displayOther").src = 
                             URL.createObjectURL(remoteStream);
                             document.getElementById("displayOther").play();
                    });
               }, // errorCallback
                   function (err) {
                    //error action
               }
         );
}

Mittels „navigator.getUserMedia“ wird nun ein Audio- und Videostream geöffnet. Sobald dieser bereit ist, wird er in einem DOM video-node mit der ID „displayMe“ angezeigt – somit sieht der schwarze Spieler seine Videoübertragung zunächst auch selbst.
Gleichzeitig wird mittels „peer.call“ eine Verbindung zum weißen Spieler aufgebaut. Dieser Verbindung wird das erstellte Streamobjekt übergeben.
Wie weiter oben bereits beschrieben, hat der weiße Spieler zuvor mittels „peer.on(‘call‘, …….)“ einen Listener für den Fall eines calls erstellt, der beim Auftreten dieses Events die Funktion „passiveCall“ ausführt.

passiveCall:

function passiveCall (call)
{
    call.on('stream', function (remoteStream) {
            document.getElementById("displayOther").src =
              URL.createObjectURL(remoteStream);
            document.getElementById("displayOther").play();
    });
    navigator.getUserMedia({video: true, audio: true}, function (stream) {
              document.getElementById("displayMe").src =
                URL.createObjectURL(stream);

              document.getElementById("displayMe").play();
              call.answer(stream);
         }, // errorCallback
         function (err) {
             //error action           
         }
    );
}

In der Funktion „passiveCall“ wird beim weißen Spieler zusätzlich der Evenhandler „call on stream“ registriert. Sobald dem weißen Spieler also vom schwarzen Spieler ein Stream geschickt wird, wird dieser als source des DOM Elements „#displayOther“ gesetzt -> es handelt sich dabei wieder ein video-node. Dieses wird anschließend mittels „play“ abgespielt.
Der schwarze Spieler hat den selben Eventhandler in der Funktion „activeCall“ registriert (siehe oben).

Beim eingehenden Call des schwarzen Spielers erstellt der weiße Spieler nun ebenfalls ein Streamobjekt mittels „getUserMedia“.
Auch er zeigt diesen Stream in einem video-node mit der ID „displayMe“ an (sodass auch er sich selbst sieht) und sendet diesen stream wiederum schließlich an den schwarzen Spieler (mittels „call.answer(stream)“ ) -> ähnlich wie es der schwarze Spieler beim Aufbau des Calls bereits gemacht hat.

Damit ist dieser erste Artikel zu Ende. Hoffentlich konnte er das Interesse für die ein oder andere „upcoming“ oder „less known Webtechnologie vermitteln.
Im besten Fall sollte es jetzt zudem leicht fallen, mittels PeerJS, mit wenigen Schritten selbst einen P2P Videochat in die eigene WebApp oder Homepage zu integrieren – ausschließlich mit vorhandenen Browsertechnologien.

The post “less known” client-side web technologies [Part 1] appeared first on Mobile USTP MKL.

The post Lorem Ipsum appeared first on Mobile USTP MKL.

2. Um das hier interessant finden zu können muss man, so glaube ich zumindest, absolut nichts mit dem digitalen Spielesektor am Hut haben… ein generelles Faible für digitale Technik, speziell im mobilen Bereich und/oder allgemein im Entertainment-Bereich, sollte es auf jeden Fall rechtfertigen, diesen Beitrag zumindest mal zu überfliegen.
Denn am Ende entschließt man sich möglicherweise, eine kommende technische Plattform (namentlich: die Nintendo Switch) zumindest ein wenig im Blick zu behalten, selbst wenn einen digitales Gaming eher gar nicht interessiert ;).

Damit aber genug der VORworte. Dafür kommt jetzt erst mal ein RÜCKblick ;).

Das Smart”phone”
Eigentlich ist es nicht so lange her, da gab es keine Smart”phones”. Also keine digitalen Alleskönner -> kleine Rechner, mit allerhand integrierten Sensoren, einer Kamera zwei Kameras, mindestens einem Mikrofon … und einer großen Anzahl an unterschiedlichen externen Verbindungsmöglichkeiten, die man so (zumindest im kabellosen Bereich) selbst bei gängigen PCs oder gängigen Notebooks nicht vorfindet (natürlich kann man an dieser Stelle auch die Frage stellen, ob und warum man bei handelsüblichen PCs Technologien wie etwa NFC überhaupt benötigen würde – aber darum geht es hier ja nicht).

Ein wesentlicher Faktor, der diese kleinen Alleskönner so praktisch macht, ist ihre portable Form, kombiniert mit ihrer Vielfältigkeit. Die Vielfältigkeit kommt zu einen daher, dass sie über diese, gerade eben angesprochene, Vielzahl an technologischen “Einzelbausteinen” verfügen, die in Kombination miteinander und der entsprechenden Software dahinter ganz unterschiedliche Anwendungsmöglichkeiten erlauben.
Telefonieren ist eine davon – bei weitem aber nicht mehr die Beliebteste… dass diese Geräte also tatsächlich Smart”phones” heißen, dürfte eher ihrer historischen Herkunft geschuldet sein:

Bevor Apple sein erstes iPhone 2007 herausbrachte, experimentierte der damalige Markführer im Segment der Mobiltelefone – namentlich: Nokia – schon länger mit Geräten, die für mehr als hauptsächlich Telefonieren konzipiert waren. Diese Geräte waren mit einer offenen Architektur ausgestattet (offener als bisherige Mobiltelefone jedenfalls), die es erlaubte, die Grundfunktionen des Betriebssystems durch zusätzliche Software zu erweitern.
Zu erwähnen ist hier zum Beispiel die Nokia Communicator Reihe…

Wie auch immer: Erst Apple hat dieses Konzept für den Durchschnittsanwender wirklich perfektioniert. Einer der Hauptgründe lag dabei aber nicht nur bei der offenen Software Architektur, sondern im Faktor ihres grundsätzlichen Hardwaredesigns:
Die Verschmelzung der essentiellsten Inputs (Pointing Device, Keyboard) und Outputs(hochauflösendes multicolor Display) eines normalen PCs oder eines Notebooks zu einer kleinen, im Formfaktor sehr praktischen, Einheit -> namentlich dem Touchscreen.
Natürlich hat Apple nicht als erster einen Touchscreen in ein Mobiltelefon verbaut. Und erst recht hat Apple den Touchscreen natürlich nicht erfunden.

Aber Apple hat das gemacht, was diese Firma am besten kann: Bestehende Dinge für den Endanwender so weit perfektionieren und aufeinander abstimmen, dass eine wirklich rundum gutes Endprodukt dabei rauskommt.
Der Touchscreen im ersten Smartphone, das auch in einem breiteren Marktsegment kommerziell wirklich erfolgreich war, bildet einen Bildschirm, ein Pointing Device (wie eine Maus) und ein (virtuelles) Keyboard ab. Natürlich ist das Pointing Device längst nicht so präzise wie eine Maus, die Tastatur eignet sich längst nicht so gut für längere Texte, wie ein herkömmliches Hardwarekeyboard mit entsprechendem Formfaktor. Der Bildschirm ist für ein produktives, multitasking-lastiges Arbeiten natürlich nicht mit einem großen Screen vergleichbar – ABER diese Dinge benötigte unterwegs ohnehin keiner.
Unterwegs muss man schnell Informationen einholen können, kurze Nachrichten verschicken, oder einfache kurze Tasks (wie das Organisieren von Terminen) erledigen können. Im Business Bereich -> im privaten Bereich hat man unterwegs sogar noch viel weniger Anforderungen…
Kein Wunder also, dass dieses Konzept nur gewinnen konnte.

Natürlich sind all diese Tatsachen nichts Neues.
Es sollte an dieser Stelle lediglich verdeutlicht/in Erinnerung gerufen werden, wie in den letzten Jahren aus mobilen Telefonen kleine, extrem universelle Rechner wurden, die durch ihre verbaute Hardware und ihre Portabilität ein enormes Einsatzspektrum erreicht haben. Bei dem Wort Smart”phone” würde jemand, der nicht genau wüsste was hinter diesem Begriff tatsächlich steht, an ein sehr dediziertes Gerät denken – ein Telefon. Ein Telefon, das halt vielleicht noch ein paar extra Features besitzt…
Dabei sind Smart”phones” eigentlich Geräte, mit denen man viele, viele, viele smarte Dinge machen kann… unter anderem z.B. halt auch telefonieren..

Spätestens als das Tablet dann aufkam, war der Faktor “Phone” aus der Gerätebezeichnung endgültig gestrichen. Weil sich das Tablet (das ja eigentlich nichts anderes ist, als ein großes Smartphone), in Anbetracht seines Formfaktors, eher schlecht zum Telefonieren eignet.
Oh.. und zudem haben ja längst nicht alle Tablets Slots für SIM-Karten verbaut. Man könnte also meinen, mit Tablets kann man also gar nicht telefonieren..

Und dennoch kann man mit JEDEM Tablet heute Telefonieren. Weil auch das Telefonieren selbst sich von einem dedizierten Service, der von dedizierten Anbietern (wie Mobilfunkprovidern) zu einer sehr viel offeneren Anwendung gewandelt hat:
Es müssen ja lediglich Daten von A nach B übertragen werden und Empfänger B muss halt verstehen, wie Absender A spricht. Völlig egal ob das jetzt über irgendwelche fixen, dezidierten, Standleitungen passiert oder über Mobilfunkmasten, oder, oder, oder…
Gleiches ist z.B. mit dem Fernsehen zu beobachten.
Hat man früher Fernsehen über dezidierte Broadcasting Anbieter empfangen, sehen wir heute z.B. über Mobilfunkmasten auf unserem Smartphone z.B. via Netflix fern.
Und andererseits telefonieren wir zuhause z.B. über unser WLAN, das sich über unseren Kabelfernseh-Provider (wie z.B. Kabelplus) ins Internet verbinden -> etwa mittels Skype oder einen von vielen, vielen anderen vergleichbaren Diensten.

Was sich in Wahrheit also in den letzten Jahren entwickelt hat, ist der Weggang von dedizierten Services, Technologien und auch Geräten.
Hin zu so offenen Services, Standards und Devices.
Devices mit einem so breiten und vielseitigen Standard-Hardware-Umfang und einem so breiten Spektrum an Standard-Interfaces, dass nahezu alle denkbaren möglichen Szenarien/Services auf jedem möglichen Gerät genutzt und abgebildet werden können…
Es muss immer nur noch die entsprechende Software zur Verfügung gestellt werden. Dann kann man telefonieren -> aber auch Messages aller Art verschicken, Informationen aller Art einholen, fernsehen, spielen, andere Geräte fernsteuern, und und und.
Von wegen also Smart”phone”

Die “Spiele”konsole
Vor ein paar Monaten habe ich mit meinem Bruder telefoniert (gut.. das mache ich öfter.. aber es geht jetzt um ein bestimmtes Gespräch).
Er meinte, dass seine Tochter nicht dauernd das Notebook über Kabel mit dem Fernseher verbinden will, wenn sie Netflix sehen will und ob man Netflix nicht eigentlich auch direkt am Fernseher “empfangen” kann. Er hat da mal sowas gelesen……
Ich fragte ihn, ob es ein smarter Fernseher ist (es war noch ein relativ neues Gerät – etwas über ein Jahr alt). Mein Brunder entgegnete mir lediglich, dass er schon findet, dass das er ziemlich smart aussieht.
Tja.. Mit der Aussage ließ jetzt erst Mal nicht viel machen ;).

Über den Preis des Geräts habe ich dann geschlussfolgert, dass es sich eher nicht um ein Smart-TV Gerät handeln wird.
Das Gespräch ging dann einige Minuten. Minuten, in denen ich ein wenig versucht habe ihm zu erklären, worauf es ankommt…
Ich habe ihm z.B. erklärt, dass er einen Google Chromecast verwenden könnte – dann könnte er mit einem externen smarten Gerät (wie dem Notebook) einfach jeden beliebigen Netflix Stream an den Stick schicken (und der Stick empfängt und decodiert den Stream dann sogar direkt, ohne dass das externe Gerät die ganze Zeit als Zwischenstation herhalten muss).

Bis wir an diesem Punkt des Gesprächs angelangt waren, war dann schon einige Zeit vergangen, weil ich ihm halt immer wieder versucht habe, einige Dinge zu erklären und ihm nahe zu bringen, dass, wenn sein Fernseher nicht smart ist, er halt einfach irgendwas anderes smartes braucht, das man irgendwie mit dem Fernseher verbinden kann. Also “einfach nur” “irgendwas”, das sich ins Internet verbinden kann, das eine halbwegs offene Architektur besitzt und mit dem man dann halt irgendwie die Audio und Video Signale an den Fernseher weitergeben kann.

Er wollte allerdings nicht unbedingt noch ein zusätzliches neues teures Gerät anschaffen müssen. Wenn überhaupt, dann noch ein Kabel oder höchstens etwas in der Preiskategorie eines Google Chromecast Sticks…
Doch sein Einwand, nachdem ich ihm erklärt habe, was der Chromecast genau macht, war auch nicht ganz unberechtigt.
Der, bis dahin zum Netflix schauen verwendete Laptop, war ein Firmenlaptop -> und mein Bruder (und ich) wusste nicht, ob er das entsprechende Browserplugin da so einfach installieren konnte.
Und von seinem PC wollte er den Chromecast nicht steuern -> denn jedesmal zum PC gehen zu müssen, wenn man auf dem Fernseher im anderen Zimmer was streamen möchte, ist auch nicht wirklich so sexy…

Aber da war ich natürlich noch längst nicht am Ende, mit meinem Latein ;D.
“Es kann ja auch ihr Smartphone Smart”phone” sein, über das sie streamt. Und nein: das muss sie ja noch nicht mal mit dem Fernseher über Kabel verbinden. Da gibts ne App für den Chromecast und schon pfeift das. Fertig. Also musst du jetzt wirklich nur noch den Chromecast besorgen.”.

Kaum war das ausgesprochen, erinnerte ich mich daran, dass seine Tochter ja ein iPhone hatte (Teenager…). Da war ich mir dann doch weder unsicher, ob das so einfach ging, was ich gerade noch so großmäulig behauptet hatte.
Erst denken. Dann reden….
Ich war mir nicht sicher, ob man das iPhone so ohne Weiteres mit Chromecast verbinden konnte (heute weiß ich es besser ;D).
Ich wusste zwar, dass es auch einige andere Anbieter von Streamingsticks gab, die in diesem Szenario vielleicht etwas bringen konnten – aber ich wollte ihm nichts empfehlen, womit ich keine persönliche Erfahrung gemacht hatte… Sonst würde er Geld rauswerfen und es würde im schlechtesten Fall nicht funktionieren.

Das Gespräch ging zu dem Zeitpunkt dann doch schon eine kleine Weile und dann habe ich irgendwann mal gesagt “HEAST! Des gibts ja net.. ich hab zuhause zumindest 4 verschiedene Möglichkeiten, wie ich Netflix und Co. auf den Fernseher bekommen könnt… Da muss sich ja bei dir auch irgendwas fin…..”
Und dann schoss es mir ein:
“Du sag mal… ihr hattet doch mal eine Wii oder eine Wii U rumstehen. Gibts die noch?”
Die Antwort war “Ja, sicher.. aber was hat das damit zu tun?”
Und abermals versuchte ich ihm nochmals zu erklären, dass die meisten Geräte heute weitaus mehr sind, als das, was hinter ihrer Bezeichnung steht.

“Im Prinzip ist auch in so einer “Spiele”konsole nix anderes drin, als in einem Notebook oder einem PC. Ein oder mehrere Prozessoren, ein Bisschen Hauptspeicher, jedemenge standardisierte Interfaces (sowohl für input als auch für output, sowohl für Kabelverbindungen als auch für kabellose Verbindungen jeder Art). Und vor allem: Eine so offene Softwarearchitektur, dass jedermann alles mögliche dafür programmieren kann. Früher hat man “Programme” dazu gesagt und das wurde eher mit dem PC assoziiert. Heute wird das Zeug heute meist ‘Apps’ genannt und mit dem Smart”phone” assoziiert. Das ist aber nichts Smart’phone’ exklusives………”.
Es herrschte kurze Stille.
Und dann kam die Frage: “Wie jetzt… ich kann mit meiner Wii ernsthaft Netflix schauen?”.

An der Stelle werde ich die letzten Minuten des Gesprächs nicht mehr wiedergeben, weil nicht weiter relevant ;). Ich denke aber, dass an der Stelle klar wird, worauf diese nette kleine Erläuterung Telefonats aufmerksam machen sollte ;).

Nintendo Switch
Als ich, in freudiger Vorerwartung, das erste (vorab angekündigte) Video zur neuen Nintendo Konsole (die bis dahin unter dem Arebeitstitel “Nintendo NX” bekannt war) sah, gingen mir ein HAUFEN Gedanken durch den Kopf.
Einer der ersten war: “Na, Gott sei Dank!”
Ich war zunächst mal sehr beruhigt darüber, dass Nintendo nicht auch auf diesen Zug aufgesprungen ist, den seine zwei Hauptkonkurrenten sich seit einigen Jahren liefern: Mit einfach nur immer besserer Hardware groß auftrumpfen und sich überbieten zu wollen. Trauriger Weise funktioniert das bei einem sehr breiten Publikum sehr gut. Und trauriger Weise werden dadurch wirklich gute Spiele (die im Idealfall sogar auch irgendeiner emotionalen Ebene stimulieren können – sei es durch eine tolle Story oder ein witziges Spielprinzip ) Mangelware und im Gegenzug steht Einheitsbrei steht auf der Tagesordnung. Hauptsächlich mordsbombastische grafische Effekte.. alles andere ist aber leider sehr oft zum Gähnen.
Aber das ist eine höchst subjektive Meinung und hat mit dem eigentlichen Thema auch nichts zu tun ;).

Wie auch immer: Nintendo blieb seinem Motto treu.
“Sollen sich die zwei Deppen doch weiterhin gegenseitig die Köpfe einschlagen… wir versuchen uns da dran vorbei zu schleichen und erneut unseren ganz eigenen Markt zu finden.”
Genau an der Stelle beginnt jetzt der (eventuell.. ist natürlich alles noch unbewiesen) genialste Schachzug, den Nintendo überhaupt nur machen hätte können.

Zunächst muss man einmal eines vorwegschicken: Mobiles Gaming war IMMER eines der größten Steckenpferde von Nintendo. They have invented the Gameboy. THE GAMEBOY! ;).
Was Nintendo über kaum ahnen konnte, war, dass dieses Marktsegement in den letzten Jahren sehr plötzlich von einer “anderen Seite” – und zwar extrem unerwartet – geradezu im Sturm erobert wurde und das Zielpublikum dabei sogar noch erheblich vergrößert werden konnte.
Das Schlimmste dabei: Diese “andere Seite” hatte das noch nicht einmal bewusst angestrebt. Diese “andere Seite” repräsentiert einfach nur tragbare Geräte, die sich im Laufe der Jahre soweit weg von einem dedizierten Einsatz, hin zu enorm universellen und leistungsfähigen Alleskönnern entwickelt haben.

Soweit, dass sie dabei viele Märkten – wie z.B. den von Digitalkameras und MP3 Playern – erheblich beeinflusst haben. Mal ehrlich: Wer kauft heute noch einen MP3 Player? ;D.
Aber das waren nicht die einzigen Märkte..
Denn Step by Step (und sicherlich von niemandem beabsichtigt) nahmen diese Geräte – namentlich: Smart”phones” und Tablets – eine enormen gewichtige Rolle im digitalen Spielemarkt ein. Und zwar gerade im mobilen Sektor. Eigentlich ja Nintendos Steckenpferd.

Nicht, dass Nintendo jetzt soviel eingebüßt hätte, dass man sich gleich Existenzsorgen hätten machen müssen: Auf was Nintendo immer noch bauen konnte, waren etablierte Eigenmarken und die jahrzehntelange Erfahrung Games mit “dem gewissen Etwas” entwickeln zu können, die auch heute noch eine breite Fanbase hinter sich haben.
Aber auch so etwas währt nicht ewig. Der Markt ist schnelllebig. Die Konkurrenz groß und keinesfalls unbegabt und “Mario” ist für Kids heute nicht mehr das was “Mario” für meine Generation ist ;).
Gespürt hat Nintendo den Einzug der Smart”phones” in den digitalen Spielemarkt alle Male. Zumal die Geräte in den lezten Jahren immer leistungsfähiger wurden und sich nicht mehr nur Games wie Doodle Jump flüssig spielen ließen. Und zumal diese Geräte eine großartige Plattform für den (ebenfalls stark wachsenden) Markt von Indie Game Developern darstellten.
Und mit den beiden Hardware- und Performancegiganten Microsoft und Sony als starke Konkurrenten am stationären Konsolenmarkt, steuerte Nintendo auf schwere Zeiten zu…
Und das weiß Nintendo auch. Deshalb – und alles was jetzt folgt, sind wirklich nur Hypothesen – hat Nintendo einen umfassenden Plan für eine künftige Positionierung des Konzerns und seiner Produkte geschmiedet. Und wenn man die Zeichen noch etwas freier interpretiert, sogar noch inklusive einem passenden Backupplan im Gepäck*, falls der Hauptplan nicht funktioniert.

Ein Paket – drei Geräteklassen
An dieser Stelle sollte man das Video zur Nintendo Switch zumindest einmal gesehen haben. Deshalb hier ein Link:
https://www.youtube.com/watch?v=f5uik5fgIaI

Zwei Dinge fallen bei diesem Video massiv auf. Beide sind, so denke, ich alles andere als Zufall. Eher massiv durchdacht..
1. Im ganzen Video wird kein einziges Mal gezeigt, dass das Display einen Touchscreen verbaut hat. Das ist insofern interessant, als dass Nintendo durchgehend bei seiner letzten Generation von mobilen Spielekonsolen (Nintendo DS), als auch bei seiner letzten stationären Konsole (Nintendo Wii U) massiv auf ein second Screen Konzept mit Touchscreen gesetzt hat. Gerade bei letzterer wahrscheinlich sogar zu massiv -> immerhin gilt dieses Feature, das externe Hersteller nicht auf Teufel komm raus in ihre Spiele integrieren wollten, als ein Grund für das wachsende mangelnde Desinteresse an der Konsole und deren kommerziellen Misserfolg.
Dennoch scheint es sehr unwahrscheinlich, dass Nintendo vollständig auf dieses Interaktionsmittel verzichten würde. Wenn es weniger als “Zwangfeature” für neue Spiele und mehr nach dem Motto “you can use it, if it seems to make sense” propagiert wird, ist diese zusätzliche Komponente ja wirklich eine sinnvolle (optionale) Ergänzung.

Und ganz ehrlich: Wer verbaut heute noch statische LCD Displays in so einem Formfaktor, wie er bei dem mobilen Teil der Nintendo Switch zum tragen kommt.
Es dürfte recht sicher sein, dass da ein Touchscreen kommt… Und es gibt auch schon erste (natürlich unbestätigte) Gerüchte dazu:
http://de.engadget.com/2016/10/28/ja-das-nintendo-switch-kommt-mit-touchscreen/
Warum also macht Nintendo so ein Geheimnis daraus? So ein Touchscreen ist nun wirklich keine technologische Enthüllung mehr, die man im letzten Moment loslässt um die Konsumenten vom Hocker zu hauen.
Und trotzdem: Es wurde geradezu auffällig darauf verzichtet, in diesem ersten Video der Nintendo Switch, Touchfeatures zu zeigen.
Meine Vermutung: Das wurde ganz bewusst noch ausgelassen, um noch nicht gleich zu offensichtlich zu machen, welche Überlegungen hinter der Nintendo Switch tatsächlich stecken könnten. Ich denke nämlich, dass das nächste Teaservideo inhaltlich GANZ anders ausfallen könnte. Nämlich sehr untypisch für eine “Spiele”konsole..

Das führt nun direkt zu:
2. Am meisten dürfte an der Nintendo Switch dieser unglaublich modulare Aufbau ins Auge stechen. Es ist eine mobile Konsole mit einer festen Station für den Heimbetrieb. Ob diese Station die Rechenleistung der Switch erhöht oder wirklich nur das Signal zum Fernseher weiterleitet, ist noch gänzlich unbekannt. Gerüchten zu Folge, soll das aber der Fall sein. Dies soll an dieser Stelle aber auch gar keine Rolle spielen.
Fakt ist, dass sich selbst der mobile Teil nochmals aufsplitten lässt. Und Fakt ist, dass der mobile Teil um ein vielfaches schlanker ist als etwa der Controller der Nintendo Wii U. Der Formfaktor ist wirklich ein ganz anderer und könnte in diesem Fall ein sehr entscheidender sein.
Nimmt man die Controller vom mobilen Device ab, erinnert dieses schon geradezu verdächtig an ein ganz anderes, mittlerweile sehr vertrautes, Gerät aus unserem Alltag: Es wirkt zu sehr wie ein Tablet, als dass es Zufall sein könnte.
Jetzt könnte jemand denken “WTF? Der Typ schreibt über 2300 Wörter, nur damit er hier behauptet “Die Nintendo Switch ist nichts weiter als ein Tablet, das man bei Bedarf mit zwei Gaming-Controller-Teilen bestücken kann und bei Bedarf auch recht easy mit dem Fernseher verbinden kann? Das scheint zwar nett.. aber nichts davon ist eine wirklich bahnbrechende neue Erfindung.”
Ja! Genau! Nichts davon ist neu. So wie auch der Touchscreen beim iPhone und überhaupt das ganze Smartphone-Konzept dahinter nicht neu war. Aber es war etwas anderes: Extrem durchdacht**.
Und ich glaube, dass man Nintendos neuestes Gerät (und ich schreibe hier ganz bewusst nicht “Nintendos neueste Spielekonsole”) genau aus diesem Blickwinkel betrachten muss.

Ich unterstelle Nintendo also mit der neuen Konsole keinesfalls etwas neu zu erfinden – aber mit der Kombination jeder Menge sehr durchdachter Elemente ein Produkt auf den Markt zu bringen, das so durchdacht ist, dass es weit mehr als nur bisherige Kunden ansprechen könnte. Und vor allem: weit mehr als nur klassische spielebegeisterte ansprechen könnte.
Nämlich weil es am Ende des Tages weit mehr für den Konsumenten sein soll, als ein dediziertes Spielegerät.
Denn: wohin hat sich der Markt bewegt?

Genau: Zu vielseitigen, extrem universell einsetzbaren Geräten (mit einer hohen Leistungsfähigkeit), die so wenig wie möglich einem dedizierten Einsatzfeld zuzuweisen sind, sondern vor allem offen und auf unterschiedlichste Arten verwendbar sind.
Natürlich kauft man mit der Nintendo Switch zunächst mal eine “Spiele”konsole… Genauso wie man immer noch ein Smart”phone” kauft, wenn man ein iPhone erwirbt.
Dennoch würde ich zum momentanen Zeitpunkt noch wetten, dass die nächsten großen technischen Informationen zur Nintendo Switch unter anderem eine sehr umfassende API bereithalten (und zwar für jede Menge Funktionalitäten, auch außerhalb des Spielesektors).
Bis es soweit ist, könnte ich natürlich auch komplett falsch liegen und momentan einfach viel zu viel in Nintendos neuestes Gerät und die Geheimniskrämerei drumherum interpretieren.
Sollte es sich aber wirklich herausstellen, dass die Nintendo Switch über eine ebenso offene Architektur verfügt, wie es sein flexibler Formfaktor vermuten lässt, dann wird es sehr eindeutig, welchen Plan Nintendo da wohl verfolgt:

Wenn die Smart”phones” und Tablets dieser Welt so unverschämt waren und (wenn auch eher unbeabsichtigt) ein sehr großes Stück vom (mobilen) Spielemarkt erobert haben, dann scheint doch die logischste Strategie, genau diesen Spieß umzudrehen und etwas so universelles auf den Markt zu bringen, dass der Durchschnittskonsument sich beim nächsten Tabletkauf womöglich überlegt, ob er wirklich nur so etwas banales und eingeschränktes wie ein simples Tablet kaufen möchte, oder zum etwa gleichen Preis etwas so vielfältig einsetzbares wie Nintendos neueste “Spiele”konsole.

Somit könnte es also nicht schaden, die Nintendo Switch als Entwickler auf dem Radar zu behalten -> eben auch wenn man mit digitalen Spielen nichts tu tun hat.
That’s it. Man darf gespannt also sein ;). Stay tuned.

*Backuplan: Tatsächlich hat Nintendo im Jahr 2016 gleich zweimal ein großes Tabu gebrochen. Mit der offiziellen Ankündigung von “Mario Run” für das iPhone 7, ging Nintendo erstmals gegen seinen eigenen Grundsatz vor, nicht für andere Systeme entwickeln zu wollen. Und der Erfolg des Spiels, welches erst kürzlich released wurde, gab Nintendo recht.
Über ein Hintertürchen hat Nintendo diesen Grundsatz aber tatsächlich schon etwas früher im selben Jahr gebrochen (sehr erfolgreich) -> die Rede ist von Pokemon GO für iOS und Android (das durch das extrene Developmentstudio Niantic entwickelt wurde, hinter dem aber dennoch letztendlich Nintendo steht) war das erste Mal, dass ein Spiel aus einer der hauseigenen starken Franchisereihen im großen Stil für externe Systeme produziert wurde.
Noch vor den Ankündigungen der Nintendo Switch hat Nintendo also bereits auch einen Fuß in den Sektor mobiler Games für Smartphones (also die momentan stärkste Konkurrenz) gesetzt.
Diese Tür kann Nintendo natürlich jederzeit wieder schließen und weiterhin exklusiv für eigene Systeme produzieren (was wahrscheinlich der Fall sein wird, wenn die Nintendo NX den gewünschten Effekt und Erfolg mit sich bringt) -> aber alleine schon diese taktische Neupositionierung (entgegen aller alten Prinzipien des Konzerns), deutet darauf hin, dass Nintendo sich in jedem Fall bewusst ist, sich in der Zukunft ein wenig anders aufstellen zu müssen. Schon alleine deshalb scheint es noch wahrscheinlicher, dass hinter dem Gesamtkonzept der Nintendo Switch wesentlich mehr als nur die Veröffentlichung einer banalen neuen Spielkonsole stecken wird.

**Extrem durchdachte Details: Alleine die Tatsache, dass die Nintendo Switch einen integrierten, ausklappbaren Standfuß besitzt, zeigt, wieviel Überlegung hinter jedem Detail dieser Konsole steckt ;D.
Aber mal echt: Ein integrierter, ausklappbarer Standfuß –> Wie genial ist das? Warum hat da nicht schon längst ein Hersteller daran gedacht??! ;D

The post Nintendo Switch – neue Spielekonsole oder Aufbruch in neue Märkte? appeared first on Mobile USTP MKL.

 Eigentlich wurde sogar die Grundfunktionalität ein wenig verändert, wie in Abschnitt 3 (Erste Umsetzung von Tournament Room) unter Punkt c) nachzulesen ist.

Im Prinzip befindet sich das Projekt also schon in einer zweiten Phase
Zunächst aber zurück zum Anfang und einer kleinen Erklärung:

1. Tournament Room – Grundsätzliche Idee

Die einzige technische Anforderung innerhalb der Aufgabenstellung war, dass ein externer physischer Faktor etwas am mobile Phone beeinflusst/triggert. Dies ist im einfachsten (und herkömmlichen) Fall ein QR Code, der etwa eine URL bereitstellt, die letztendlich z.B. Informationen an den Client übermittelt.
Etwas weiter gedacht kann der QR Code allerdings nicht nur statische Informationen bereitstellen.
Er könnte etwa auch eine Anwendung aufrufen – und im Prinzip kann der QR Code zudem auch gleich Informationen für die aufzurufende Anwendung bereithalten.
Zum Beispiel: Nachdem die Anwendung geöffnet ist, “führe Funktion XY aus” oder “zeige Bereich ABC an”.
Mehrere unterschiedliche QR Codes könnten dann dazu genutzt werden, unterschiedliche Dinge innerhalb einer interaktiven Applikation zu bewirken/zu triggern. Durch dieses Prinzip können QR Codes dazu genutzt werden, klassische Interaktionen innerhalb einer Anwendung über die physische Außenwelt auszulösen (statt, wie üblich, über ein digitales Benutzerinterface) .

Ein Vorteil durch diese Art der Interaktion ist es, dass eine Anwendung dadurch mit sehr simplen Mitteln einen Location-basierten Context bekommen kann, ohne dafür etwa externe digitale Signale (wie GPS, WLAN, Bluetooth/iBeacon, NFC, ….) verwenden zu müssen:
Werden an unterschiedlichen Orten unterschiedliche QR Codes angebracht, die Informationen für die jeweilige App bereitstellen, so kann diese App auf den jeweiligen physischen Raum (oder gar auf einzelne Objekten innerhalb des Raums) “reagieren”, ohne dass sie auf irgendwelche technischen Mittel zur Ortserkennung zurückgreifen müsste.

Dieses Prinzip wird z.B. manchmal bei Ausstellungen verwendet. Verschiedene Ausstellungsobjekte sind dabei mit verschiedenen QR Codes “ausgestattet” und eine eigene Ausstellungsapp zeigt, je nach erkanntem QR Code, entsprechende Inhalte und Informationen an oder bietet weitere Interaktionsmöglichkeiten im Rahmen des aktuellen Kontexts.

Bei “TournamentRoom” wird dieses Prinzip verwendet, um einen physischen Raum in eine digitale “Spielarena” umwandeln zu können.
Die QR Codes beinhalten dazu eine eindeutige Room-ID (z.B. “IMLab”). Zudem beinhalten unterschiedliche QR Codes innerhalb eines Raums (die also alle die selbe Room-ID besitzen) auch unterschiedliche “Kommandos” für die App. Dazu aber gleich mehr.

2. Das Prinzip hinter Tournament Room

Die QR Codes im Raum, welche über die entsprechende Room-ID verfügen, verbinden zwei Spieler innerhalb eines Raums miteinander. Diese zwei Spieler müssen sich dabei weder in einem gemeinsamen WLAN befinden  (der Raum selbst muss nicht einmal über ein WLAN verfügen), noch müssen sie über andere Technologien eine direkte Verbindung miteinander aufbauen.
Die App liest die Informationen aus dem QR Code (primär die Room-ID) und teilt einem Server mit, dass man sich eben in dem entsprechenden Raum befindet – z.B. also im IMLab.
Die Spieler bleiben über diesen externen Server miteinander verbunden und können nun Daten über eben diesen miteinander austauschen. Dabei ist es völlig unerheblich, wie die einzelnen Spieler mit dem Internet verbunden sind (einzig DASS sie es sind, ist wichtig).
Damit ein ständiger Datenaustausch in alle Richtungen möglich ist, läuft die Verbindung der Spieler mit dem Server über das WebSocket Protokoll.

Technologisch könnte man an dieser Stelle sogar noch einen Schritt weitergehen und den Server nur als “Mittelsmann” verwenden, der die zusammengehörigen Spieler in einem Raum “miteinander bekannt macht” (sprich, vereinfacht gesagt, deren IP Adressen untereinander weiterleitet). Wenn die App selbst nun über eine integrierte Serverkomponente verfügen würde, könnten die Geräte der Spieler eine Peer to Peer Verbindung zueinander aufbauen. WebRTC wäre dafür sehr gut geeignet.

Auf diesen Schritt verzichtet “Tournament Room” vorerst (wobei es gut denkbar ist, dass dies in einer späteren Version noch ergänzt wird). Die Verbindung zueinander bzw. der Datenaustausch untereinander erfolgt immer über den zentralen Server. Würde man nun unterschiedliche physische Räume zu “Tournament Rooms” machen – also etwa im Labor für interaktive Medien QR Codes mit der Room-ID “IMLab” anbringen und im Usability Labor QR Codes mit der Room-ID “UsabLAB” anbringen, so kommunizieren zwar alle Spieler immer über den selben Server, doch durch die Room-ID als Identifikator können immer nur Spieler zueinander finden/verbunden werden, die sich tatsächlich im selben physischen Raum befinden.

Aufbauend auf dieser Logik könnten nun unterschiedliche kleine und größere Multiplayer-Spiele implementiert werden. Wollen Spieler miteinander spielen, müssen Sie lediglich einen der QR Codes innerhalb eines Raums einscannen. Sie sind nicht gefordert, komplexe manuelle oder halbautomatische Verbindungsprozesse durchzuführen oder erst irgendwelche Daten untereinander auszutauschen, um sich gegenseitig zu finden.
Und dennoch spielen immer nur jene Spieler gegeneinander, die sich im selben Raum befinden.
Somit bietet “TournamentRoom”, als Gegensatz zu herkömmlichen Multiplayer Casual-Games bei denen man oft gegen irgendwelche unbekannten Gegner aus aller Welt antritt, eine “Face-to-Face Competition”. Obwohl digitale Spiele gespielt werden, hat man seinen Gegner immer im Blickfeld und erlebt seine Emotionen, seine Gestik und seine Mimik live mit.

3. Erste Umsetzung von Tournament Room

Als erste Demo dieses Konzepts wurde das klassische Spiel “Hangman” umgesetzt.
Ein weiteres Minigame befindet sich derzeit in Entwicklung. Falls jemand die Muse hat, ein größeres Spiel (z.B. die digitale Abbildung eines klassischen Brettspiels) umzusetzen und mit der TournamentRoom Server Logik zu verknüpfen, so dass jedermann (durch einmaliges Ausdrucken eines QR Codes mit einer individuellen Room-ID) dieses Spiel für den klassischen Brettspiele Abend Zuhause verwenden kann – mit einem digitalem Spielbrett, das jeder Teilnehmer auf seinem eigenen Smartphone/Tablet anzeigen lassen kann –  so soll sich der-/diejenige einfach melden:
dm161564[ AT ]fhstp.ac.at

Umgesetzt wurde das Frontend als herkömmliche Webanwendung. Natürlich ließe sich die TournamentRoom Logik auch von anderen Frontend Technologien nutzen, sofern diese

• QR Codes lesen können und
• WebSocket Verbindungen ermöglichen

Als additional Feature wurde ein QR Code Scanner IN diese Webanwendung integriert. Dazu wurde die Funktion “getUserMedia” von der WebRTC API verwendet, um im Browser auf das Videodevice eines Geräts zugreifen zu können.
Mittels WebWorker und der Library “JSQRCode” (https://github.com/LazarSoft/jsqrcode) werden einzelne Frames des, mittels getUserMedia() erfassten Videostreams, auf das Vorkommen eines QR Codes überprüft. Sollte einer gefunden werden, wird dieser decodiert und ausgewertet.

Dabei enthält der QR Code drei wichtige Informationen:
 

• a) Die URL zur WebApp. Sollte man allerdings tatsächlich den inApp QR Scanner verwenden, so ist dies eine überflüssige Information. Allerdings kann natürlich auch ein externer QR Code Scanner verwendet werden (auf iOS muss dies sogar passieren, da iOS WebRTC noch immer nicht supported und der webbasierte QR Code Scanner daher nicht funktioniert).
  Aus diesem Grund befindet sich die URL im QR Code.
   
• b) Die Room-ID. Diese Information ist in jedem Fall wichtig: Sie ist (wie oben bereits ausführlich beschrieben) der Schlüssel zur Verbindung von Spielern untereinander.
   
• c) Das Kommando zur Spielinitialisierung. Zunächst war Torunament Room so konzipiert und umgesetzt, dass dieses Kommando eine eindeutige PlayerID war (player1, player2). Es gab also zwei unterschiedliche QR Codes pro Tournament Room: Einen mit der RoomID und dem Kommando player1 und einen mit der RoomID und dem Kommando player2.
  Dieses Prinzip wurde nach dem ersten “Livetest” von Tournament Room abgeändert, da es zwei entscheidende Nachteile mit sich brachte.
  Zum einen hat diese Herangehensweise nur das Umsetzen von Spielen mit genau 2 Mitspielern erlaubt (wohingegen die Serverkomponente grundsätzlich ohne derartige Beschränkung entwickelt wurde).
  Zum anderen erlaubte dieses Vorgehen, dass jeweils immer nur 2 Personen in einem Tournament Room ein bestimmtes Spiel verwenden konnten.
  Hätten also zwei Spieler in einem Raum Hangmang gespielt, hätte sonst niemand mehr die Möglichkeit gehabt, dieses Spiel zu im selben Raum zu spielen (bevor die ersten beiden Spieler ihre Session beendet hätten).
  In der neuen Version von Tournament Room sind die Kommandos “player1” und “player2” den Kommandos “new” und “join” gewichen.
   

4. Spielesessions in Tournament Room

Öffnet ein Spieler in einem Tournament Room eine neue Spielesession (in dem er den “New” QR Codes innerhalb des jeweiligen Raums scannt), wird am Server ein “Subroom” zum jeweiligen TournamentRoom erzeugt.
Davon bekommt der Spieler nichts mit.
Ein weiterer Spieler kann nun mittels “Join” diesen Subroom joinen (damit sind diese Spieler miteinander verbunden und, sofern das jeweilige Spiel – wie im Beispiel Hangman – zwei Spieler benötigt, so wird dieses gestartet).
Scannen mehrere Leute hintereinander den “new” Code (es werden also mehrere Subrooms generiert), so bezieht sich join immer auf den neuesten, noch freien Subroom.

Also:

• Spieler A eröffnet eine neue Spielesession (Subroom).
• Spieler B eröffnet ebenfalls eine neue Spielesession.
• Spieler C tut dasselbe.
• Spieler D scannt nun “Join” und landet damit in der Spielesession von Spieler C.

Ist das Spiel dieser Session für zwei Spieler gedacht, startet es und Spieler C und Spieler D spielen miteinander.
Scannt nun Spieler E ebenfalls “Join”, so landet er in der Session von Spieler B.

Durch dieses Vorgehen (“join most recent session”) wird sichergestellt, dass zwei Spieler die sich bewusst dafür entscheiden, gegeneinander anzutreten und unmittelbar hintereinander den new und den join Code des jeweiligen Raums scannen, auch wirklich miteinander verbunden werden.
Jedes andere Vorgehen (“join random session” oder “join oldest open session”) würde dies nicht sicherstellen können.

Wer nun einen eigenen TournamentRoom generieren will, der muss sich also lediglich über ein QRCode Generation Service einen QRCode mit einer individuellen RoomID generieren. z.B. hier:
http://goqr.me/de/

Die beiden QRCodes für new und join müssen lediglich folgende URL Schemen bereitstellen:

• New: http://metamoon.de/TournamentRoom/?pp&IMLab&new
• Join: http://metamoon.de/TournamentRoom/?pp&IMLab&join

Wobei “IMLab” jeweils durch die eigene RoomID zu ersetzen ist.
Das Generieren und Ausdrucken dieser Codes genügt, um Hangman (und alle eventuell künftig folgenden Spiele) im eigenen TournamentRoom spielen zu können.

Jeder der spielen will, muss dann lediglich den “New” bzw. “Join” Code im jeweiligen Raum scannen und schon befindet er/sie sich in einer Spielsession innerhalb des entsprechenden Tournament Rooms.

The post Print-to-Mobile: TournamentRoom appeared first on Mobile USTP MKL.