About Us

is a small, independent game studio with a long memory. The “About Us” page you’re reading is the original one — a snapshot from the early 2000s, when the studio was two people, a shared home office, and a stubborn belief that you could build real games without a publisher breathing down your neck.

We’ve kept it largely intact because it’s honest about where we came from, and because the people on it are still the people who make the games. What follows is that same page, expanded: who we are, what we actually do, how we work, and why a studio that started with C++ and DirectX on a PlayStation 2 ended up shipping HTML5 games and board-game adaptations.

Key Takeaways

• Massively Fun is a two-person independent studio founded and run by Stephen and Angela Wilkinson, operating since the mid-1990s.
• Stephen’s background is professional console and PC engineering — C++, DirectX, and shipped titles on PS/2, Xbox, and GameCube-era hardware.
• Angela’s background spans Java, C++, ASP, and Delphi, plus the far harder job of running the household that keeps the studio alive.
• The studio’s output has moved with the industry: from native console work to browser-based HTML5/JavaScript games and digital adaptations of physical board games.
• We build in small, shippable increments and treat “done and released” as more valuable than “ambitious and unfinished.”
• Everything here — reviews, downloads, dev notes — comes from people who actually make games, not from a content farm.

Who We Are

Stephen Wilkinson — Sr. Software Engineer. Stephen spent years as a professional game engineer, most notably at Paradigm Entertainment, an Infogrames company, working on console titles during the PS2/Xbox/GameCube generation. That’s the era when “shipping a game” meant fitting inside a fixed memory budget, hand-tuning a renderer, and debugging on devkits that cost more than a car. He graduated in 1987 from Duncan High School in Duncan, Oklahoma — which tells you he’s been writing software for a very long time, and that he came to games through the same route a lot of us did: curiosity, a home computer, and too many late nights.

His stated skills are the ones that matter for this studio: writing computer games, C++, DirectX, and console development across PS/2, Xbox, and a bit of GameCube. In practice that means he’s comfortable all the way down the stack — from memory management and rendering to gameplay systems and tooling.

Angela Wilkinson — Arthur’s mom, and coder on standby. Angela’s official title undersells her. Her toolkit is Java, C++, ASP, and Delphi, plus what the original page calls “Mom 1.0” — the operating system that actually keeps a two-person studio running. Anyone who has tried to build games with a family knows that the second job is the harder one, and that a studio without someone managing logistics, schedules, and morale doesn’t ship anything.

Her favorites list is short and telling: Arthur (and Stephen). That’s the whole studio in one line.

Related: Unity Asset Store — Ready-made art, tools and templates that drop straight into your Unity project.

What We Actually Build

Massively Fun’s catalog spans a few distinct kinds of work, and it’s worth being explicit about them because “indie studio” can mean almost anything.

• Original HTML5/JavaScript games. Browser-first titles built to run without a plugin, without an install, and without a storefront gatekeeper. This is the modern core of what we do.
• Digital adaptations of board games. Our best-known work in this space is Catan World, a digital take on Klaus Teuber’s Catan — a game whose rules are simple to state and genuinely hard to implement correctly, because the whole experience depends on turn order, resource trading, and the social negotiation between players.
• Small, sharp arcade-style games. Fast Iron and Word² sit in this bucket: tight loops, quick sessions, and mechanics you can explain in a sentence but spend weeks tuning.
• Reviews and commentary. We play a lot, and we write about it. Reviews on this site come from working developers, which changes what we notice — we tend to care about systems, feel, and technical execution as much as presentation.

That mix isn’t accidental. It reflects a deliberate strategy: keep the scope of any single project small enough that two people can finish it, and keep several different kinds of project in flight so the studio isn’t dependent on one title’s success.

How We Got Here: From DirectX to the Browser

The original About Us page is a time capsule of a specific moment in game development. In the late 1990s and early 2000s, if you wanted to make a game, you wrote it in C or C++ against a platform SDK — DirectX on Windows, or a console’s proprietary libraries — and you shipped it on physical media through a publisher. Paradigm Entertainment was exactly that kind of studio, and working there meant learning the discipline of console development: fixed hardware, hard deadlines, certification requirements, and no ability to patch after launch.

If you are shopping: Construct 3 — Browser-based, no-code HTML5 engine that exports to web, mobile and desktop.

The web changed the economics of all of that. When browsers gained a real 2D canvas and, later, WebGL, it became possible to ship a game to anyone with a URL. No publisher, no disc, no certification queue. The trade-offs are real — you give up direct hardware access, you fight browser quirks, and you can’t assume a consistent frame rate — but the upside is that a two-person team can reach players worldwide on day one.

That shift is why Massively Fun’s center of gravity moved to HTML5 and JavaScript. The engineering habits from console work didn’t disappear; they just got applied to a different target. Memory discipline, deterministic update loops, and careful profiling matter just as much in a browser as they did on a devkit.

How We Work

Two-person studios live or die on process, and ours is built around a few principles that have survived contact with reality.

Ship small, ship often. A game that exists and is playable beats a game that is theoretically better and unfinished. We scope to what two people can complete, then cut until it fits.

Prototype the risky part first. If a mechanic might not be fun, we build the ugliest possible version of it before writing any art or UI. Most ideas die here, which is the point.

Keep the toolchain boring. For HTML5 work that generally means a JavaScript/TypeScript codebase, a lightweight rendering approach (raw Canvas or WebGL, or a small library rather than a heavyweight engine), and Node.js for build scripts, asset pipelines, and local dev servers. Boring tools mean fewer surprises and less time spent debugging the tooling instead of the game.

Related: JetBrains Rider — Cross-platform .NET/C# IDE with first-class Unity and Unreal Engine support.

Test on the worst device you can find. Browser games run on everything from a high-end desktop to a five-year-old phone. If it holds up on the slowest target, it holds up everywhere.

Write it down. Dev notes and reviews aren’t marketing — they’re how we think. Explaining a design decision in prose is one of the fastest ways to discover it’s a bad decision.

Choosing a Tech Stack: How We Decide

One of the most common questions we get from hobbyist developers is “what should I build with?” There’s no universal answer, but there is a decision process. Here’s roughly how we think about it.

Reader favorite: Amazon: Game Dev Books & Gear — Game programming books, mechanical keyboards, monitors and dev-desk hardware.

Consideration	Lean toward raw Canvas/WebGL + JS/TS	Lean toward a full engine (e.g., Godot, Unity, or a JS engine)
Team size	1–2 people who like control	Larger teams or artists who need editors
Game type	2D, arcade, puzzle, board-game ports	3D, physics-heavy, complex scene graphs
Target	Browser-first, fast load, small download	Multi-platform including consoles/desktop
Your strengths	You enjoy systems and low-level control	You’d rather spend time on content and design
Time budget	You can afford to build some tooling	You need an editor and asset pipeline now

The honest caveat: engines save you enormous time on rendering, physics, and asset management, but they also impose their own architecture and their own bugs. Rolling your own gives you total control and total responsibility. For a two-person studio shipping browser games, a middle path — a small rendering library plus your own game logic — has usually been the right call. For a hobbyist’s first project, an engine is almost always the faster route to something playable.

If you want to go deeper on the standards and platforms involved, the MDN Web Docs on the Canvas API are the canonical reference for 2D browser rendering, and the WebGL specification maintained by the Khronos Group covers the GPU-accelerated path. For the board-game side of our work, the official Catan site is the authoritative source on the game we adapted.

Motion Control and Other Experiments

Part of the studio’s history involves motion-control platforms — the wave of camera- and sensor-based input that arrived with the Wii era and the Kinect. Motion control is a genuinely interesting design problem because it removes the abstraction layer of a button. Players expect the game to understand their body, and it usually doesn’t, at least not precisely.

The practical lessons from that work carry over into everything else we do:

• Latency is the enemy. Any input scheme with noticeable lag feels broken, no matter how clever the mechanic.
• Design for the sensor you have, not the one you want. If the camera can only reliably detect gross motion, build a game about gross motion.
• Always provide a fallback. Accessibility and reliability both demand that a game be playable without the exotic input device.

Those principles apply just as well to touch controls on a phone, which is the motion-control problem of the HTML5 era.

The People Behind the Games

It’s worth restating plainly, because it’s the thing that distinguishes a studio like this from a content site: the names on this page are the people who write the code, tune the mechanics, and play the games we review. Stephen’s favorites list — Final Fantasy Tactics Advance, The Lord of the Rings: The Two Towers on PS2, Fire Emblem, Call of Duty, and a rotating cast of others — is a working developer’s list. It’s heavy on systems-driven games with deep progression, which is exactly the kind of design that rewards the engineering mindset.

Angela’s list is one line long and says everything: Arthur, and Stephen. A studio is a household before it’s a business, and this one has always been both.

Frequently Asked Questions

Who runs Massively Fun?

Massively Fun is run by Stephen and Angela Wilkinson, a two-person team. Stephen handles most of the engineering, drawing on a professional background in console and PC development, while Angela contributes coding across Java, C++, ASP, and Delphi alongside running the household that makes the studio possible.

What games has Massively Fun made?

The studio’s catalog includes original HTML5/JavaScript titles such as Word² and Fast Iron, plus Catan World, a digital adaptation of the board game Catan. The studio also publishes reviews and commentary on games it plays.

What technologies does the studio use?

Historically, C++ and DirectX for console and PC work, including PS/2, Xbox, and GameCube-era development. Today the focus is HTML5 and JavaScript for browser games, with Node.js for tooling and build pipelines, and Java, C++, ASP, and Delphi appearing across the team’s broader experience.

Can I hire Massively Fun or collaborate?

The site has always been a personal studio page rather than an agency storefront, so there’s no formal services listing. The best route for collaboration or questions is to reach out through the contact address published on the site.

Is the original About Us page still accurate?

Yes — the original bios, skills, and favorites are preserved here because they’re still true. The people, their backgrounds, and their tastes haven’t changed; what’s changed is the platform the studio builds for and the size of the catalog.

What advice do you have for hobbyist game developers?

Start smaller than you think you need to, prototype the risky mechanic before building anything else, and pick a tech stack based on your team size and game type rather than on what’s trendy. Shipping one small finished game teaches you more than starting five ambitious ones.

P.S. A few readers have asked which books & hardware we actually reach for — it's Amazon: Game Dev Books & Gear; take a look here if you want the current details.