Hi, I'm Alex!

Always Creative

I’ve played games all my life, but I was always more interested in making things than playing them. It’s all just software to play with, some more playful than others. As a kid that meant building levels in Little Big Planet (two even became school projects), shooting short films, animating stick figures in Flash, messing around in Garry’s Mod, tinkering in Game Maker, learning After Effects, getting my first taste of code in HTML, cutting fan game trailers, modeling in Blender, and drawing in Photoshop, to name a few.

Still the same today, always one new tool deep into some idea.

Why Tools

Every tool I picked up eventually got in my way. I’d be mid-idea and hit some hard edge the opinionated software wouldn’t let me past, and the idea would turn to vapor while I fought the tool. Eventually I stopped hunting for a better tool and started building my own.

That’s what tools are to me: a way to stay in the part of the work that’s actually creative. A good tool keeps you in ideation mode. It doesn’t dilute your thoughts with implementation, and it never makes you mold the idea to fit the tool.

To University

Years of self-taught game development meant I could build almost anything I could picture. What I couldn’t do was design. I had no shortage of neat mechanics, but I didn’t know the craft of turning one into a whole game: the actual steps, the decisions, the discipline.

So I went somewhere design-heavy. At Uppsala University I took Game Design and Programming, which let me put years of programming to use while finally learning game design from the ground up.

Solo Programmer

I’ve worked as a solo programmer on several projects, owning both the design and implementation of their systems. I came into university at 26 with 7 years of programming behind me, and as the most experienced person there I naturally ended up mentoring my peers. Eventually I chose to work purely as the solo programmer: dropping the mentoring let me move faster and get better results. I worked plenty of weekends and picked up the responsibility others let slip, and what I’m proudest of is how much we pulled off inside extremely short development cycles.

Design Leadership

On every team I’ve been part of, I’ve gravitated toward design leadership. Not because I chase the role, but because I get deeply invested in where a project is headed, and I’m not shy about defending the direction I believe in. I’m detail-obsessed, I scope aggressively, and I put in the extra hours to get the work done.

On Splish Splash Submarine I chose not to be project owner, and the game’s core design problems landed on me anyway. I did much of the rescue work that made it actually play, including the redesign that fixed our dodging-instead-of-shooting problem. That taught me something I’d taken for granted: I’d assumed whoever held the vision would be as invested in it as I was. They weren’t, so now when a project’s direction matters to me, I take ownership of it instead of assuming it’s in good hands.

On Hauntel Management I took the lesson to heart and became both project owner and solo programmer. I assembled a team of five and scoped every feature against a 9-week deadline, leaving two full sprints of buffer.

Finally, on Untitled Driving Game, a research project with a team of three, we kept failing to find common ground on what to build. I reluctantly pitched an idea I’d been sitting on for a while, and it became the game we made. I led the design and programmed it solo.