Was steckt hinter Stadia?

Der Spielestreaming-Dienst Stadia versteht sich als neue Plattform. Wer für diese Plattform entwickeln möchte, kann sich unter stadia.dev dafür bewerben. Auf der Seite erhält der Leser daneben weitere Informationen über die Plattform.

stadia.dev

Auf der Hardwareseite wird aktuell eine 2,7-GHz-Hyperthread-x86-CPU mit AVX2 SIMD und 9,5 MB L2- und L3-Cache, eine AMD-GPU mit HBM2-Speicher und 56 Recheneinheiten mit einer Leistung von 10,7 Teraflops, 16 GB RAM mit einer Bandbreite von bis zu 484 Gbit/s und SSD-Speicher in der Cloud genutzt.

Auf Softwareseite wird Linux genutzt. Google nutzt hierbei die Linux-Distribution Debian als Grundlage. Als Grafikschnittstelle müssen die Spiele Vulkan benutzen. Dazu wird eine API bzw. ein SDK mitgeliefert, welches Funktionalitäten für die Verwaltung von Spielständen, die Nutzung der Multiplayer-Modi und der Funktionen für die Unterstützung der Unterbrechung und Fortsetzung des Spieles liefert.

Zurzeit unterstützen das Entwicklerwerkzeug Unity und die Unreal Engine den Spielestreaming-Dienst. Daneben existieren weitere Werkzeuge von Google, welche bei der Entwicklung von Spielen für Stadia helfen.

Ideentool wird zu Wryte

2014 veröffentlichte ich die erste Version meines Ideentools. Dabei handelte es sich um ein Werkzeug für Autoren welches unterschiedlichste Generatoren für Namen, Charaktere und ähnliches anbot. Im Laufe der Jahre kamen viele Generatoren hinzu, allerdings wirkte die Technik hinter dem Ideentool mittlerweile etwas angestaubt.

Das alte Ideentool

Im Zuge einiger Überlegungen entstand schlussendlich ein neues Projekt mit dem Namen Wryte. Der Fokus von Wryte ist ein wenig anders als der des Ideentools. So sollte Wryte internationalisierbar sein, also für unterschiedlichste Sprachen zur Verfügung stehen. Daneben sollte das Thema Schreiben etwas weiter gefasst werden, so soll es einmal um das Schreiben im Sinne eines Autoren und Schreiben im Sinne einer Entwicklers gehen.

Hintergrund hierfür war, das ich neben dem Schreiben auch entwickle und jeweils bestimmte Tools für beides immer wieder benötige. Deshalb sind die Werkzeuge in Wryte in zwei Personas unterteilt, einmal für Autoren und einmal für Entwickler.

Ein weiteres Ziel von Wryte war die Unterstützung und Integration in mobile Systeme. So kann die App unter iOS und Android auf den Homescreen gelegt werden und fühlt sich so wie eine native App an.

Wryte ersetzt das Ideentool

Technisch wurde die Architektur sinnvoller gestaltet. Während das Ideentool eine wilde Ansammlung von JavaScript– und PHP-Schnipseln war, wurde Wryte architektonisch in eine REST-API und die eigentliche Frontend-Applikation zerlegt. Die API soll in den nächsten Monaten öffentlich dokumentiert werden, sodass diese auch von anderen genutzt werden kann. Für die API wurde eine Swagger-Datei geschrieben und mittels dieser ein Server-Stub für das Slim Framework erzeugt. Die Frontendanwendung ist eine HTML5-App und kann im Gegensatz zum Ideentool auch auf mobilen Systemen sehr gut genutzt werden. Technisch basiert sie auf dem Framework 7-Framework.

Unter iOS kann die App auf den Homescreen gelegt werden

Zu finden ist Wryte unter wryte.net. Im Gegensatz zum Ideentool, fehlen noch einige Generatoren wie der Charakter- und Geheimnisgenerator, einige Fantasienamengeneratoren und die Generatoren für Titel und Verwandtschaftsverhältnisse. Die meisten dieser Generatoren sollen in den nächsten Wochen und Monaten hinzugefügt werden.

Favicon-Generator

Vor zwei Jahren schrieb ich über einen Dienst, welcher Favicons für die unterschiedlichen Systeme erzeugt. In den letzten Tagen war ich für ein Projekt wieder auf der Suche nach einem solchen Dienst. Diesmal bin ich beim Real Favicon Generator gelandet. Im Gegensatz zum damals vorgestellten Generator arbeitet der Real Favicon Generator wesentlich umfassender.

realfavicongenerator.net

Nachdem Upload einer Grafik für das Favicon, werden einige Einstellungen abgefragt und anschließend werden die entsprechenden Bilder erzeugt. Nach der Umwandlung erhält der Nutzer die entsprechenden Dateien und die Informationen zur Einbindung. Neben der Oberfläche, verfügt der Dienst über eine API, mit welcher der Dienst in eigene Projekte eingebunden werden kann. Zu finden ist der Dienst unter realfavicongenerator.net.

Slim Framework

Für wahrscheinlich jede Programmiersprache existieren mehr oder weniger viele Frameworks, welche dem Entwickler bestimmte Aufgaben abnehmen und somit die Entwicklung beschleunigen. Neben den größeren Framework existieren auch eine Reihe von Frameworks mit einem minimalistischeren Ansatz. Eines dieses sogenannten Microframeworks ist Slim. Entwickelt wird und wurde Slim für PHP.

slimframework.com

Slim eignet sich sehr gut für die Umsetzung für REST-APIs bzw. RESTful Webservices. Um ein Projekt zu erstellen, kann der Paket- bzw. Dependency-Manager Composer genutzt werden:

composer create-project slim/slim-skeleton exampleapp

Damit wird ein Grundprojekt angelegt mit welchem gearbeitet werden kann. Auch von seitens des Swagger-Toolings wird Slim unterstützt. So kann eine API über den Swagger-Editor definiert werden und anschließend für das Slim-Framework exportiert werden. Der Quelltext des Frameworks ist auf GitHub zu finden. Es ist unter MIT-Lizenz lizenziert und damit freie Software. Die offizielle Seite des Projektes ist unter slimframework.com zu finden.

REST-APIs unter Apache und Nginx betreiben

Eine der wesentlichen Eigenschaften von REST-APIs bzw. RESTful-Webservices ist ihre Adressierbarkeit von Ressourcen. Wenn ich z.B. über eine API verfüge, welche mir Namen generiert, so kann es in dieser API unterschiedliche Ressourcen geben:

GET https://api.example.com/name/german/
GET https://api.example.com/name/polish/

Rufe ich nun eine der beiden Ressourcen mit dem HTTP-Verb GET auf so erhalte ich entweder einen deutschen oder einen polnischen Namen von dieser Beispiel-API. Für den Webserver ergibt sich allerdings das Problem, das der Ordner name und die entsprechenden Unterordner nicht existieren. Das einzige was in diesem Beispiel existiert ist eine index.php-Datei, welche unter der URL:

https://api.example.com/index.php

zu finden ist. Damit die REST-API ordnungsgemäß funktioniert, müssen die entsprechenden Aufrufe zur index.php-Datei umgebogen werden. Bei dem Webserver Apache kann dies über eine .htaccess-Datei mit folgendem Inhalt erledigt werden:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?_url=/$1 [QSA,L]
</IfModule>

Diese Datei sollte dabei im gleichen Verzeichnis wie die Datei index.php liegen. Bei Nginx muss stattdessen die Konfiguration der Domain bzw. der Seite angepasst werden. Diese Konfigurationen sind unter /etc/nginx/sites-available/ zu finden. Dort muss folgende Konfiguration hinzugefügt werden:

try_files $uri $uri/ @rewrite;

location @rewrite {
	   rewrite ^/(.*)$ /index.php?_url=/$1;
}

Hinterlegt werden muss die Konfiguration in einem server-Block derselben. In diesem Fall würde die URL bzw. der Aufruf:

GET https://api.example.com/name/german/

intern in die URL:

https://api.example.com/index.php?_url=name/german/

umgeschrieben und vom Webserver geladen. Dadurch landen die Aufrufe wieder bei der Datei index.php und können verarbeitet werden.