Über uns

ist ein kleines, unabhängiges Spielestudio mit einem langen Gedächtnis. Die „Über uns“-Seite, die Sie gerade lesen, ist die ursprüngliche – eine Momentaufnahme aus den frühen 2000ern, als das Studio aus zwei Personen, einem gemeinsamen Homeoffice und dem eigensinnigen Glauben bestand, dass man echte Spiele bauen könne, ohne dass einem ein Publisher im Nacken sitzt.

Wir haben sie größtenteils unverändert beibehalten, weil sie ehrlich zeigt, woher wir kommen, und weil die Personen darauf immer noch die Personen sind, die die Spiele machen. Was folgt, ist dieselbe Seite, jedoch erweitert: wer wir sind, was wir tatsächlich tun, wie wir arbeiten und warum ein Studio, das mit C++ und DirectX auf einer PlayStation 2 begann, am Ende HTML5-Spiele und Brettspiel-Adaptionen veröffentlicht hat.

Wichtige Erkenntnisse

• Massively Fun ist ein unabhängiges Zwei-Personen-Studio, gegründet und geleitet von Stephen und Angela Wilkinson, das seit Mitte der 1990er Jahre besteht.
• Stephens Hintergrund liegt im professionellen Konsolen- und PC-Engineering – C++, DirectX und veröffentlichte Titel auf Hardware der PS/2-, Xbox- und GameCube-Ära.
• Angelas Hintergrund umfasst Java, C++, ASP und Delphi sowie die weitaus schwierigere Aufgabe, den Haushalt zu führen, der das Studio am Leben hält.
• Die Produktion des Studios hat sich mit der Branche mitentwickelt: von nativer Konsolenarbeit hin zu browserbasierten HTML5/JavaScript-Spielen und digitalen Adaptionen physischer Brettspiele.
• Wir bauen in kleinen, lieferbaren Schritten und betrachten „fertig und veröffentlicht“ als wertvoller als „ehrgeizig und unvollendet“.
• Alles hier – Rezensionen, Downloads, Entwicklernotizen – stammt von Leuten, die tatsächlich Spiele machen, nicht von einer Content-Farm.

Wer wir sind

Stephen Wilkinson – Sr. Software Engineer. Stephen verbrachte Jahre als professioneller Spieleentwickler, vor allem bei Paradigm Entertainment, einem Unternehmen von Infogrames, wo er an Konsolentiteln der PS2/Xbox/GameCube-Generation arbeitete. Das war die Ära, in der „ein Spiel zu veröffentlichen“ bedeutete, in ein festes Speicherbudget zu passen, einen Renderer manuell zu optimieren und auf Devkits zu debuggen, die mehr kosteten als ein Auto. Er schloss 1987 die Duncan High School in Duncan, Oklahoma, ab – was Ihnen verrät, dass er schon sehr lange Software schreibt und dass er den Weg zu den Spielen über dieselbe Route fand wie viele von uns: Neugier, ein Heimcomputer und zu viele späte Nächte.

Seine angegebenen Fähigkeiten sind diejenigen, die für dieses Studio zählen: das Schreiben von Computerspielen, C++, DirectX und Konsolenentwicklung für PS/2, Xbox und ein wenig GameCube. In der Praxis bedeutet das, dass er sich über den gesamten Stack hinweg sicher bewegt – von der Speicherverwaltung und dem Rendering bis hin zu Gameplay-Systemen und Tooling.

Angela Wilkinson – Arthurs Mutter und Programmiererin in Bereitschaft. Angelas offizieller Titel verkauft sie unter Wert. Ihr Toolkit umfasst Java, C++, ASP und Delphi, plus das, was die ursprüngliche Seite als „Mom 1.0“ bezeichnet – das Betriebssystem, das ein Zwei-Personen-Studio tatsächlich am Laufen hält. Jeder, der versucht hat, Spiele zusammen mit einer Familie zu entwickeln, weiß, dass der zweite Job der schwierigere ist und dass ein Studio ohne jemanden, der Logistik, Zeitpläne und die Moral managt, nichts veröffentlicht.

Ihre Favoritenliste ist kurz und aussagekräftig: Arthur (und Stephen). Das ist das gesamte Studio in einer Zeile.

Verwandte: Construct 3 — Browserbasierte HTML5-Engine ohne Code, die ins Web, auf Mobilgeräte und auf dem Desktop exportiert.

Was wir tatsächlich bauen

Der Katalog von Massively Fun umfasst einige verschiedene Arten von Arbeiten, und es lohnt sich, hier explizit zu sein, da „Indie-Studio“ fast alles bedeuten kann.

• Original HTML5/JavaScript-Spiele. Browser-First-Titel, die so gebaut sind, dass sie ohne Plugin, ohne Installation und ohne Storefront-Gatekeeper laufen. Dies ist der moderne Kern dessen, was wir tun.
• Digitale Adaptionen von Brettspielen. Unsere bekannteste Arbeit in diesem Bereich ist Catan World, eine digitale Umsetzung von Klaus Teubers Catan – ein Spiel, dessen Regeln einfach zu formulieren, aber wirklich schwer korrekt zu implementieren sind, da das gesamte Erlebnis von der Zugreihenfolge, dem Ressourcenhandel und den sozialen Verhandlungen zwischen den Spielern abhängt.
• Kleine, präzise Arcade-Spiele. Fast Iron und Word² fallen in diese Kategorie: tighte Loops, kurze Sessions und Mechaniken, die man in einem Satz erklären kann, an deren Feinabstimmung man aber Wochen verbringt.
• Rezensionen und Kommentare. Wir spielen viel und schreiben darüber. Die Rezensionen auf dieser Seite stammen von aktiven Entwicklern, was verändert, worauf wir achten – wir legen tendenziell ebenso viel Wert auf Systeme, Spielgefühl und technische Ausführung wie auf die Präsentation.

Diese Mischung ist kein Zufall. Sie spiegelt eine bewusste Strategie wider: den Umfang jedes einzelnen Projekts so klein zu halten, dass zwei Personen es abschließen können, und mehrere verschiedene Projektarten gleichzeitig zu verfolgen, damit das Studio nicht vom Erfolg eines einzelnen Titels abhängig ist.

Wie wir hierher gekommen sind: Von DirectX zum Browser

Die ursprüngliche „Über uns“-Seite ist eine Zeitkapsel eines spezifischen Moments in der Spieleentwicklung. In den späten 1990ern und frühen 2000ern schrieb man, wenn man ein Spiel machen wollte, in C oder C++ gegen ein Plattform-SDK – DirectX unter Windows oder die proprietären Bibliotheken einer Konsole – und veröffentlichte es auf physischen Medien über einen Publisher. Paradigm Entertainment war genau diese Art von Studio, und dort zu arbeiten bedeutete, die Disziplin der Konsolenentwicklung zu lernen: feste Hardware, harte Deadlines, Zertifizierungsanforderungen und keine Möglichkeit, nach dem Launch Patches zu veröffentlichen.

Unsere Wahl: Udemy Game Development Courses — On-Demand-Kurse zu Unity, Unreal, C++, C# und Shader-Programmierung.

Das Web hat die Wirtschaftlichkeit all dessen verändert. Als Browser eine echte 2D-Canvas und später WebGL erhielten, wurde es möglich, ein Spiel an jeden mit einer URL zu liefern.

Kein Publisher, kein Datenträger, keine Zertifizierungswarteschlange. Die Kompromisse sind real — man gibt den direkten Hardware-Zugriff auf, man kämpft mit Browser-Macken und man kann keine konsistente Bildrate voraussetzen — aber der Vorteil ist, dass ein Zwei-Personen-Team am ersten Tag Spieler weltweit erreichen kann.

Diese Verschiebung ist der Grund, warum der Schwerpunkt von Massively Fun auf HTML5 und JavaScript verlagert wurde. Die technischen Gewohnheiten aus der Konsolenarbeit verschwanden nicht; sie wurden nur auf ein anderes Ziel angewendet. Speicherdisziplin, deterministische Update-Loops und sorgfältiges Profiling sind in einem Browser genauso wichtig wie in einem Devkit.

Wie wir arbeiten

Zwei-Personen-Studios leben oder sterben durch ihre Prozesse, und unser Studio basiert auf einigen Prinzipien, die den Kontakt mit der Realität überstanden haben.

Klein releasen, oft releasen. Ein Spiel, das existiert und spielbar ist, schlägt ein Spiel, das theoretisch besser, aber unvollendet ist. Wir begrenzen den Umfang auf das, was zwei Personen bewältigen können, und kürzen dann so lange, bis es passt.

Zuerst den riskanten Teil prototypen. Wenn eine Mechanik möglicherweise keinen Spaß macht, bauen wir die hässlichstmögliche Version davon, bevor wir Art oder UI erstellen. Die meisten Ideen sterben hier, und genau das ist der Punkt.

Verwandte: Amazon: Game Dev Books & Gear — Bücher zur Spieleprogrammierung, mechanische Tastaturen, Monitore und Dev-Desk-Hardware.

Die Toolchain langweilig halten. Für HTML5-Arbeiten bedeutet das im Allgemeinen eine JavaScript/TypeScript-Codebasis, einen leichtgewichtigen Rendering-Ansatz (rohes Canvas oder WebGL, oder eine kleine Bibliothek anstelle einer schwergewichtigen Engine) und Node.js für Build-Skripte, Asset-Pipelines und lokale Dev-Server. Langweilige Tools bedeuten weniger Überraschungen und weniger Zeit, die mit dem Debuggen des Toolings anstatt des Spiels verbracht wird.

Auf dem schlechtesten Gerät testen, das man finden kann. Browserspiele laufen auf allem, von einem High-End-Desktop bis zu einem fünf Jahre alten Telefon. Wenn es auf dem langsamsten Ziel standhält, hält es überall stand.

Alles aufschreiben. Dev-Notes und Reviews sind kein Marketing — sie sind die Art und Weise, wie wir denken. Eine Designentscheidung in Prosa zu erklären, ist einer der schnellsten Wege, um herauszufinden, dass es eine schlechte Entscheidung ist.

Unsere Wahl: Unity Asset Store — Vorgefertigte Grafiken, Tools und Vorlagen, die direkt in Ihr Unity-Projekt eingefügt werden.

Die Wahl eines Tech-Stacks: Wie wir entscheiden

Eine der häufigsten Fragen, die wir von Hobby-Entwicklern erhalten, lautet: „Womit soll ich bauen?“ Es gibt keine universelle Antwort, aber es gibt einen Entscheidungsprozess. Hier ist in etwa, wie wir darüber denken.

Überlegung	Tendenz zu rohem Canvas/WebGL + JS/TS	Tendenz zu einer vollständigen Engine (z. B. Godot, Unity oder eine JS-Engine)
Teamgröße	1–2 Personen, die Kontrolle lieben	Größere Teams oder Artists, die Editoren benötigen
Spieltyp	2D, Arcade, Puzzle, Brettspiel-Ports	3D, physiklastig, komplexe Scene Graphs
Ziel	Browser-first, schneller Ladevorgang, kleiner Download	Multiplattform, einschließlich Konsolen/Desktop
Stärken	Man liebt Systeme und Low-Level-Kontrolle	Man verbringt lieber Zeit mit Content und Design
Zeitbudget	Man kann es sich leisten, eigenes Tooling zu bauen	Man benötigt sofort einen Editor und eine Asset-Pipeline

Der ehrliche Vorbehalt: Engines sparen einem enorme Zeit beim Rendering, der Physik und dem Asset-Management, aber sie erzwingen auch ihre eigene Architektur und ihre eigenen Bugs. Wenn man es selbst baut, hat man die totale Kontrolle und die totale Verantwortung.

Für ein Zwei-Personen-Studio, das Browserspiele veröffentlicht, war ein Mittelweg — eine kleine Rendering-Bibliothek plus die eigene Spiellogik — meist die richtige Entscheidung. Für das erste Projekt eines Hobbyisten ist eine Engine fast immer der schnellere Weg zu etwas Spielbarem.

Wenn Sie tiefer in die beteiligten Standards und Plattformen eintauchen möchten, sind die MDN Web Docs zur Canvas API die kanonische Referenz für 2D-Browser-Rendering, und die von der Khronos Group gepflegte WebGL-Spezifikation deckt den GPU-beschleunigten Pfad ab. Für den Brettspiel-Teil unserer Arbeit ist die offizielle Catan-Website die maßgebliche Quelle für das Spiel, das wir adaptiert haben.

Motion Control und andere Experimente

Ein Teil der Geschichte des Studios umfasst Motion-Control-Plattformen — die Welle kamerabasierter und sensorbasierter Eingaben, die mit der Wii-Ära und der Kinect kam. Motion Control ist ein wirklich interessantes Designproblem, da es die Abstraktionsebene eines Buttons entfernt. Spieler erwarten, dass das Spiel ihren Körper versteht, und das tut es normalerweise nicht, zumindest nicht präzise.

Die praktischen Lehren aus dieser Arbeit übertragen sich auf alles andere, was wir tun:

• Latenz ist der Feind. Jedes Eingabeschema mit spürbarem Lag fühlt sich kaputt an, egal wie clever die Mechanik ist.
• Für den Sensor designen, den man hat, nicht für den, den man will. Wenn die Kamera nur grobe Bewegungen zuverlässig erkennen kann, baut man ein Spiel über grobe Bewegungen.
• Immer einen Fallback bieten. Barrierefreiheit und Zuverlässigkeit erfordern beide, dass ein Spiel auch ohne das exotische Eingabegerät spielbar ist.

Diese Prinzipien gelten ebenso für Touch-Steuerungen auf einem Telefon, was das Motion-Control-Problem der HTML5-Ära ist.

Die Menschen hinter den Spielen

Es lohnt sich, dies deutlich zu sagen, da es ein Studio wie dieses von einer Content-Seite unterscheidet: Die Namen auf dieser Seite sind die Personen, die den Code schreiben, die Mechaniken abstimmen und die Spiele spielen, die wir rezensieren. Stephens Favoritenliste — Final Fantasy Tactics Advance, Der Herr der Ringe: Die zwei Türme auf PS2, Fire Emblem, Call of Duty und ein wechselnder Rest — ist die Liste eines praktizierenden Entwicklers. Sie ist geprägt von systemgesteuerten Spielen mit tiefem Fortschritt, was genau die Art von Design ist, die die Engineering-Mentalität belohnt.

Angelas Liste ist eine Zeile lang und sagt alles: Arthur und Stephen. Ein Studio ist ein Haushalt, bevor es ein Geschäft ist, und dieses hier war schon immer beides.

Häufig gestellte Fragen

Wer betreibt Massively Fun?

Massively Fun wird von Stephen und Angela Wilkinson geleitet, einem Zwei-Personen-Team. Stephen kümmert sich um den Großteil des Engineerings und greift dabei auf einen professionellen Hintergrund in der Konsolen- und PC-Entwicklung zurück, während Angela neben der Leitung des Haushalts, der das Studio ermöglicht, zum Coding in Java, C++, ASP und Delphi beiträgt.

Welche Spiele hat Massively Fun gemacht?

Der Katalog des Studios umfasst Original-HTML5/JavaScript-Titel wie Word² und Fast Iron sowie Catan World, eine digitale Adaption des Brettspiels Catan. Das Studio veröffentlicht auch Rezensionen und Kommentare zu den Spielen, die es spielt.

Welche Technologien nutzt das Studio?

Historisch gesehen C++ und DirectX für die Konsolen- und PC-Arbeit, einschließlich der Entwicklung in der PS/2-, Xbox- und GameCube-Ära. Heute liegt der Schwerpunkt auf HTML5 und JavaScript für Browserspiele, mit Node.js für Tooling und Build-Pipelines, während Java, C++, ASP und Delphi Teil der breiteren Erfahrung des Teams sind.

Kann ich Massively Fun engagieren oder zusammenarbeiten?

Die Website war schon immer eine persönliche Studioseite und kein Agentur-Schaufenster, daher gibt es keine formelle Auflistung von Dienstleistungen. Der beste Weg für eine Zusammenarbeit oder Fragen ist die Kontaktaufnahme über die auf der Website veröffentlichte Kontaktadresse.

Ist die ursprüngliche Seite „Über uns“ noch korrekt?

Ja – die ursprünglichen Biografien, Fähigkeiten und Favoriten bleiben hier erhalten, weil sie immer noch zutreffen. Die Menschen, ihr Hintergrund und ihr Geschmack haben sich nicht verändert; was sich geändert hat, ist die Plattform, für die das Studio entwickelt, und die Größe des Katalogs.

Welchen Rat haben Sie für Hobby-Spieleentwickler?

Fangen Sie kleiner an, als Sie für nötig halten, erstellen Sie einen Prototyp der riskanten Mechanik, bevor Sie etwas anderes bauen, und wählen Sie einen Tech-Stack basierend auf Ihrer Teamgröße und Ihrem Spieltyp und nicht danach, was gerade im Trend liegt. Ein einziges kleines, fertiges Spiel zu veröffentlichen, lehrt Sie mehr, als fünf ehrgeizige zu beginnen.