onli blogging

Shogun 2 hat mich positiv überrascht. Vor kurzem waren die Spiele der Total War Reihe reduziert, und ich wählte Shogun 2 statt Hannibal, weil es in den offiziellen Anforderungen den Mesa-Treiber erwähnt. Tatsächlich lief es dann auch einwandfrei mit diesem.

Das war nicht die Überraschung, sondern das Spiel selbst war es. Ich kannte bisher nur Medieval und Rome. Beide Unterserien kranken am Balancing und an der Diplomatie. Mit Balancing meine ich das Problem, dass große Reiche unregierbar werden. Und die kaputte Diplomatie meint vor allem Kamikaze-Herrscher, die ohne Grund und ohne Chance Kriege anfangen, und nicht aufgeben selbst wenn eine Riesenarmee vor ihrer letzten Stadt steht. Shogun 2 hat beide Probleme nicht, es ist großartig.

Beide Probleme werden durch die kleinere Karte entschärft. Es gibt zwar einige Reiche, aber sie sind kleiner, und insgesamt gibt es weniger Provinzen. In diesem engeren Rahmen entscheiden die KI-Reiche sehr viel rationaler. Und es gibt sinnvolle Zusatzfunktionen, beispielsweise kann bei manchen Provinzeroberungen stattdessen ein Vassallenreich erschaffen werden. Das kämpft dann KI-gesteuert an der Seite des eigenen Reiches, und seine Provinzen zählen zum eigenen Gewinnziel. Denn darum geht es: Einige bestimmt Zielprovinzen einnehmen, und insgesamt genug beherrschen. Im kurzen Modus sind das 25 Provinzen, und immer ist Kyoto eine der Zielprovinzen.

Mit Kyoto kommt ein netter Kniff ins Spiel. Nimmt der Spieler Kyoto ein und krönt sich so zum Shogun, oder wird das Reich so groß dass der Shogun sich bedroht fühlt, kommt es zum Realm Divide. Jede Runde wird das Diplomatieverhältnis zu den anderen Reichen schlechter, bis irgendwann alle dem eigenen Reich den Krieg erklären. Bestehende Allianzen bleiben erstmal bestehen, Vasallen sind auch erstmal loyal, aber beides kann sich mit der Zeit ändern. Das muss man wissen und sich drauf vorbereiten, insbesondere weil die Handelseinnahmen wegfallen, aber es führt zu einer tollen Schwierigkeitskurve. Am Anfang arbeitet sich das Reich hoch, und wenn es anfängt übermächtig zu werden muss man gegen alle anderen Reiche kämpfen, was dann immer noch herausfordernd ist.

Shogun 2 profitiert viel von seinem Szenario und baut einiges aus der Historie Japans ein. Europäische Händler wollen landen, was Geld und Schießwaffen bringt, aber Christentum und Schande bringen kann. Schande wie in Unehre, denn der Daimyo hat einen Ehrenwert, der in Provinzen und bei Generälen für Loyalität sorgt. Fällt er, gibt es entsprechend Probleme. Kavallerie ist relativ schwach, Artillerie gibt es erstmal nicht. Das Reich muss für neue Einheiten, Gebäude und Boni über einen Forschungsbaum modernisiert werden. Und die Einheiten sind natürlich japanisch, Katana-Samurais und Bogenschützen, buddhistische Mönche, mit japanischen Festungen. Es gibt sogar als Sonderereignis ein europäisches Schiff mit Kanonen, das sehr viel stärker als alle japanischen ist und an der Insel vorbeisegelt, das man natürlich kapern kann.

Dies ist das erste mal, dass ich ein wirklich funktionierendes Spiel dieser Reihe spiele. Und dann läuft es auch noch gut unter Linux. Sehr erfreulich.

Ein neues Feature meines Hardwareempfehlers sind Übersichtsseiten für die einzelnen Komponenten. Jede Seite soll so nützlich wie möglich sein: So stehen dort neben den aktuellen Preisen die ganzen Spezifikationen, Bilder, Links zu Reviews und zur Herstellerseite, und bei Prozessoren und Grafikkarten auch die Benchmarkbewertung.
Mein Lieblingsfeature aber ist inspiriert von einem Reddit-Thread. Dort hatte ein Nutzer eine Reihe von Gehäusen mit CAD gerendert, und es war wirklich aufschlussreich die Dimensionen der Gehäuse im Vergleich zu sehen. Sowas wollte ich für die Übersichtsseiten der Gehäuse haben. Mit WebGL und three.js konnte ich es nun bauen.

Das ist das Ergebnis, als Beispiel die Übersichtsseite samt Größendarstellung des NZXT Source 340:

Was ich schon hatte waren die Dimensionen der Gehäuse: Höhe, Breite, Tiefe. Es geht hier nicht darum, detailgetreue Nachbildungen zu schaffen, sondern abstrakt die Größe darzustellen. Dafür reichen diese drei Werte, denn mit ihnen kann man einen Quader zeichnen. Diesen Quader des aktuellen Gehäuses stelle ich dann neben den Quader nach den Durchschnittswerten aller Mid-Tower in der Datenbank, und auf der anderen Seite den Quader nach den Durchschnittswerten aller Mini-Gehäuse.

Three.js erwies sich dabei als hervorragendes Hilfsmittel. Es ermöglicht das Programmieren von WebGL auf einer hohen Abstraktionsebene, dadurch wird es ziemlich einfach. Dazu gibt es für three.js einige Beispiele und eine hilfreiche Dokumentation.

Der gekürzte Code:

var scene = new THREE.Scene();
scene.background = new THREE.Color(0xE5E5E5);
scene.fog = new THREE.FogExp2( 0xcccccc, 0.02 );
var camera = new THREE.PerspectiveCamera( 60, 400/300, 0.1, 1000 );

var renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setPixelRatio( window.devicePixelRatio );
renderer.setSize( 400, 300 );
document.querySelector('#visualize_size').insertBefore(renderer.domElement, document.querySelector('#case_explanation'));

// current case
var geometry = new THREE.BoxGeometry(WIDTH, HEIGHT, DEPTH );
var materialCurrent = new THREE.MeshPhongMaterial( {
            color: 0x156289,
            emissive: 0x072534,
            side: THREE.DoubleSide,
            flatShading: true
        } )
var cube = new THREE.Mesh( geometry, materialCurrent );
scene.add( cube );

var pointLight = new THREE.PointLight( 0xE6E6FA, 1, 100 );
pointLight.position.set( 10, 10, 10 );
scene.add( pointLight );

var light = new THREE.AmbientLight( 0x222222 );
scene.add( light );

camera.position.set(0.5, 0.5, 2)
camera.lookAt(0, 0, 0)

controls = new THREE.OrbitControls( camera, renderer.domElement )

var animate = function () {
    requestAnimationFrame( animate );
    
    renderer.render(scene, camera);
};

animate();

Zuerst erstellt dieser Code die Umgebung: Es gibt eine Szene, eine Camera, einen Renderer. Dann wird ein Objekt erstellt, ein Cube (=Quader), mit den Daten des Gehäuses. Das Objekt wird in die Szene gesetzt, dann noch Licht hinzugefügt, die Kamera positioniert und mit den OrbitControls steuerbar gemacht. Der Nutzer kann die Kamera später in alle Richtungen bewegen. Schließlich wird das alles gerendert.

Die Lichter waren knifflig für mich, und da meine Lösung dort wahrscheinlich nicht optimal ist habe ich das auch weitestgehend ausgelassen. Die Farben der Lichter beeinflussen ja die Farbe der Gehäuse, und man will gleichzeitig alle Seiten beleuchten, sie aber alle leicht unterschiedlich haben, sodass die Kanten sichtbar sind. Die Szene braucht dafür noch ein paar Lichter mehr, um die Gehäuse von der anderen Seite zu beleuchten.

In meinem echten Code kommen noch die zwei anderen Gehäuse dazu, um einen Größenvergleich zu haben, und ein Rasternetz unten zur Orientierung.

Ein Problem blieb: Mit den drei Gehäusen nebeneinander hatte man immer noch nicht wirklich eine Idee, wie groß sie in Wirklichkeit sind. Wer sich vorstellen kann, wie groß ein durchschnittliches PC-Gehäuse ist, für den funktionierte das. Doch selbst ich fand das schwierig. Deswegen baute ich eine Banane ein, die rechts neben dem aktuellen Gehäuse steht. Ist zwar ein halber Witz, macht es aber doch einfacher.

Ich bin ziemlich glücklich über das Ergebnis. Besonders die Größen von ITX-Gehäusen zu sehen finde ich interessant. Der Kolink Satellite z.B. ist deutlich kleiner als der Thermaltake Core V1, aber Fractals Node 202 hat nochmal einen ganz anderen Ansatz.

Mich hat es auch gefreut WebGL nutzen zu können. Bisher hatte ich mich immer gefragt, warum man solch eine Technik im Browser haben muss. Hier aber war es eindeutig praktisch, und viel einfacher als ich erwartet hatte.

Ich wollte heute eigentlich über WebGL schreiben. Aber als ich diesen Artikel plante fiel mir auf, dass sich meine Artikelplanung im Laufe der Zeit geändert hat. Und da ich schon länger nicht mehr über Meta-Themen oder diesen Blog geschrieben habe, gibt es jetzt erstmal einen Artikel hierzu.

Ganz am Anfang waren die Artikel in diesem Blog sehr kurz. Es waren oft kurze Hinweise auf andere Artikel, oder Videos, oder kurz skizzierte Gedanken. Daneben gab es auch längere Texte, z.B. die Anleitungen zum Informatikstudium (wie die DFA-Minimierung), die auch heute noch von Google gefunden werden. Aber im Vergleich zu dem was ich heute schreiben würde war das schon sehr kurz gefasst.

Natürlich sind in letzter Zeit nicht alle Blogartikel richtig lang geworden. Aber sie sind eben länger, als sie damals geworden wären. Und sie sind anders aufgebaut.

Ich hatte damals oft eine grobe Idee, setzte mich hin und baute dann den Artikel zusammen. Heute sind die Artikelentwürfe im Kopf detaillierter. Das Endergebnis ist daher weniger oft überraschend. Obwohl natürlich die Anleitungen von damals auch durchstrukturiert wurden, nur eben später.

Das ist einfach Praxis, denke ich. Auch wenn ich heute weniger oft schreibe, und auch gar nicht behaupten will der große Profi zu sein. Aber da ist dann doch etwas Erfahrung. Ich weiß in etwa, wie ich die Artikel strukturiere, auch praktisches, wie beispielsweise wo ich Bilder herbekomme, und Stilfragen, wie wann mir flapsige Sprache zu flapsig ist und wann ich sie auch in zwei Wochen noch ertrage. Wenn ich ältere Artikel von mir lese fallen mir oft Konstruktionen auf, die ich heute nicht mehr verwenden würde (wobei das ein Problem ist das ich auch bei anderen Autoren habe, viele der aktuellen Artikel bei Computerbase beispielsweise sind für mich nur schwer zu ertragen). Und für Artikeltypen wie Film- und Spielebesprechungen habe ich inzwischen ein vorgefertigtes Schema, dem ich aber natürlich nicht immer folge.

Beim Programmieren ist das eine ähnliche Entwicklung. Am Anfang kämpft man noch mit der Sprache, direkt vor dem Bildschirm. Inzwischen ist eine feste Problemlösungs- und generelle Designstrategie, eine Baustelle erstmal zu ignorieren bis der grobe Ansatz klar ist. Dieses automatische Arbeiten an etwas geht natürlich nur, wenn die Zeit da ist, und manchmal ist es auch besser einfach Papier und Stift zu nehmen und eine Lösung durchzuplanen. Aber oft genug greift das ineinander über, erstmal reifen lassen, dann skizzieren, dann bauen. Dieser erste Schritt, für den muss das ganze Problem im Kopf sein, und das geht einfacher mit Übung.

Versteh mich nicht falsch, das soll keine Selbstbeweihräucherung sein. Dass ich hier nicht grundsätzlich Meisterwerke verfasse ist mir schon klar. Ich will nur zwei Dinge rüberbringen: Erstens, dass ich diesen Wandel in wie man arbeitet interessant finde. Zweitens, dass einen Blog zu führen eine gute Übung ist. In den letzten Jahren beispielsweise habe ich an einer Uni gearbeitet. Um wissenschaftliche Artikel zu schreiben konnte ich durch den Blog eben nicht nur auf das Zurückgreifen, was ich mal in der Schule gelernt hatte. Sondern ich hatte noch andere Einflüsse, was besonders beim Teilen eines Artikel mit anderen hilfreich war.

Immer noch gilt: Mehr Leute sollten Blogs haben.

Power Rangers war eine Kinderserie der Neunziger. Es war eine ziemlich seltsame: eine Gruppe junger Amerikaner lebt in einem kleinen Ort und es gibt die übliche Highschool-Geschichten, aber sie sind gleichzeitig die Power Ranger und tragen dann Anzüge, kämpfen gegen Monster und haben Fahrzeuge sowie Roboter. Die Kämpfe gegen die Aliens waren dabei äußerst merkwürdig umgesetzt. Und inzwischen lernte ich, dass die Serie auch deswegen so seltsam war, weil die Roboter-Kampfszenen mit dem Rest nur sehr lose verbunden waren und aus einer japanischen Serie stammten.

Der Power-Rangers-Film ist wohl der Versuch, aus dieser Grundlage einen halbwegs ordentlichen Actionfilm zu bauen. Und ich meine, die Grundlage ist gar nicht schlecht. Die Power Rangers sind ziemlich bekannt, ihre Kostüme fest in den Köpfen der damaligen Zielgruppe verankert, das Universum absurd und undefiniert genug, um eine interessante Story zu bauen. Wenn man die Ninja Turtles beleben kann, dann gehen auch die Power Rangers.

Nun war der letztjährige Reboot-Film der Ninja Turtles wohl eher ein Flop. Und auch Power Rangers ist kein toller Film geworden.

Die Story passt immerhin zu meinen vagen Erinnerungen an die Serie, ist aber etwas strukturierter. In der Serie gab es einen Kopf, der in der Basis der Ranger diese angeleitet hat. Ihn gibt es wieder, seine Herkunft wird etwas erklärt, ebenso der kleine Roboterhelfer. Auch die angreifenden Aliens haben diesmal eine klare Motivation.

Anfangs sind die Power Ranger mehr oder weniger problematische Schüler. Recht schnell bekommen sie erste Kräfte. Dann aber fokussiert der Film auf die Teamwerdung der Ranger, ihre Bemühungen, die Anzüge freizuschalten, und ihre diversen sozialen Probleme. Und hier wird die Geschichte langatmig. Ich glaube auch, dass dabei das Publikum verfehlt wurde: Zwar entspricht das in etwa dem Schema der Originalserie. Aber der Film versucht doch gerade am Anfang, eine bessere Qualität zu erreichen, und ist auch durchweg besser produziert (was angesichts der Plastikspielzeuge und Billigkostüme der Originalserie nicht schwer war, aber diesen Aspekt regelt Power Rangers erstaunlich gut). Hier aber spricht er wieder nur etwas ältere Kinder und junge Jugendliche an und langweilt dabei den Rest.

Es gibt dann später natürlich, und das sollte wirklich kein Spoiler für niemanden sein, eine Kampfszene mit Robotern und Fahrzeugen. Als dafür bei der Fahrt aus der Basis das "Go Go Power Rangers!" mit fast der Musik von damals ertönt, ist das schon ein guter Moment. Nach dem ganzen Stillhalten zuvor nimmt die Geschichte kurz Fahrt auf, gibt es noch ein halbwegs sehenswertes Finale.

Aber insgesamt scheitert dieser Film daran, aus Power Rangers etwas besseres zu machen, und kann auch die absurden Elemente der Originalserie nicht ausreichend nutzen um durchgehend interessant zu sein. Das ist nicht der leichtgewichtige, amüsante Actionfilm den ich mir erhofft hatte.