Game & Technical Designer. I design the systems, lead the teams, and ship the product. Across AAA, VR, live interactive media, and everything in between
Putting the FUN in FUNctional.
A Systematic Approach to...

Solving Problems, from concept to implementation
Building systems that are modular and fun. Intuitive for the user. Clean and reuseable for the developer.

Applying structure when a project needs it most
Turning "creative chaos" into sprint boards, clear scope and stakeholder alignment

Adding reality to a vision without removing it's fantasy
Maintaining strong and joint vision. Coordinating various personalities. Mentoring, and turning vauge creative ideas into achieveable tasks.
The same underlying thinking: Structured, Modular, Human-Centered and Fun. Applying it to whatever the project needs most.
"Mad World" was the proof of a pipeline that served as the groundwork for a company. It was the coming together of two similar yet different industries discovering a new way to work in tandum.It was something that didn't exist yet. Something that needing funding before it could be built, a pipeline before it could run, a team before it could ship, and a character before it could perform. Every layer required a different mode of thinking. Doing all of it on one project and delivering a "world first" is the clearest proof of what "one designer, three hats" looks like in practice.
Headed the design and build of a real-time UE5 pipeline that validated a format no studio had commercially proven before. Delivered six live shows with no failures. Every decision, from camera system to streaming architecture to stage handoffs, was made from first principles: stable enough to repeat, flexible enough to absorb live variables, reusable enough to outlast the project. The same system now runs across Persona3D's real-time productions
Authored and secured funding through the Utrecht ROM program by translating a pipeline concept with no commercial precedent into measurable innovation outcomes, sector impact, and replicability metrics a non-technical body could approve. A remixed version of the same technical truth. The proposal worked. That was the first sign that stakeholder communication was as much a design problem as the pipeline.
Directed ten people across technical, creative, and performance specialization on a project with no industry precedent. Kept the team aligned, the timeline honest, and the scope from expanding past what was actually shippable. Documented the pipeline throughout so it could be handed off and run independently. Ensuring this wasn't a one-off project but rather a repeatable company infrastructure.
Designed the character narrative and interaction segments as a reusable modular system. Defined behavioural parameters, personality constraints, and audience interaction categories as a structured ruleset. So instead of a script, the performer had a decision framework they could improvise with. Mapped input types, assigned response categories, stress-tested across rehearsals. Consistent output under variable conditions. Same principle as a game AI behaviour tree: clear rules, unpredictable outcomes.
Built every pipeline component to outlast the project. Modular by design. Swappable aspects that could function independantly rather than a fixed monolithic system. Ensuring that any part could be updated or replaced without rebuilding from scratch. Persona3D now runs multiple real-time productions on the same foundation, with different teams operating different stages independently. One proof-of-concept became the company's core production infrastructure.
Presented and hosted the experience at United XR. Introducing the character to each new audience, managing the energy in the room, encouraging and maintaining engagement, adapting to improvised moments (both technical and spectacle). Represented Persona3D to an international XR industry crowd across both days.
Running three communication strategies at once wasn't as difficult as I expected. Keeping them from bleeding into each other was a whole different can of worms. Developers needed technical specifics and room to make decisions. Grant bodies needed innovation framing and measurable outputs to assure their money was being used well. The entertainers and their agents needed creative confidence. Same project, same week, completely different conversations.
Get stakeholder alignment on paper earlier. What motivates a developer is vastly different from what motivates a stakeholder, so often the same words were interpreted differently. Short and more frequent alignment checkpoints during earlier stages would have caught the gaps before they became problems. I know that now because I felt the cost of not having it.
The character coaching. I had no formal background in performance direction, and I was worried approaching it through a systems design lens wouldn't resignate well. Suprisingly the performer managed to grasp everything really well and quickly embraced and improved the character herself. Defining the behavioural rules, run rehearsals, watch where the framework breaks, iterate. By show day the character had her own presence.
Grant writing is a design skill and I didn't expect that going in. Making the case for something that doesn't exist yet, in language a funding body finds credible, is the same muscle as pitching a mechanic to a publisher or scoping a feature to an executive. You're not describing the thing. You're designing the argument for why it should exist. I'll use that on every project that needs budget, buy-in, or both.
Something I learned about the music industry is that they do love last-minute additions. Three weeks from client brief to live LED display at one of the world's largest hardcore music events. Masters of Hardcore doesn't move its date and doesn't lower its production standard. We were given a fair bit of creative freedom as well, so esentially the only variable was what we could realistically build and what we had to cut without the client ever knowing we cut it. That kind of delivery is a different skill set to a six-month production. Faster decisions, less information, higher stakes per hour.
Identified what the brief actually needed versus what it asked for, then worked with senior leadership to lock scope before a single hour was spent building the wrong thing. On a three-week timeline there's no budget for pivots. Every day spent on a feature that gets cut is a day the delivered features didn't get. Made rapid prioritisation calls daily, kept the client updated on direction without exposing internal tradeoffs, and delivered a final product that hit every client-facing requirement.
As Scope Lead, my job was to make sure the team was always building the right thing while catching feature creep before it costs us an arm and a leg. On a three-week timeline, scope expansion doesn't announce itself. It arrives as "while we're in there we could also..." and quietly eats delivery margin. Ran regular check-ins to track what was being built against what was agreed, escalated decisions that needed senior input, and held the line on scope without killing the team's initiative. Everything that shipped was in the original plan. Everything that wasn't got cut early enough that it didn't matter.
Received the client's vauge creative vision and converted it into a specific, technically scoped build plan the team could execute against. On a project this short, vague requirements are a timeline killer, so the translation work happened fast and got locked early. The sea monster character's interaction design, display integration, and performance parameters all came out of that initial brief-to-specification process.
Scope decisions at speed feel clean in the moment and expensive in hindsight. A few calls I made early, things that seemed like safe cuts at the time ended up created small technical debts that had to be absorbed quietly later in the build. Nothing the client saw, but the team felt it. The lesson isn't "cut less." It's "document what you cut and why, immediately, so the team isn't absorbing invisible debt they don't understand.
Rapid delivery isn't just something you learn as you get more experience. It's a vital and strong communication skill. Keeping a client confident and aligned while making internal compromises they don't need to know about requires a very specific kind of honesty: transparent about progress, selective about detail. I got better at that on this project. Knowing what to surface and what to solve quietly is something you can only learn by doing it under real pressure.
A live-action mocap shoot only works if the technical layer is invisible. Directors and animators need to focus on performance, not pipeline. Additionally, we were working with alongside a company that uses Unity and custom characters. Since our pipeline and experience was with Unreal and Metahumans, we had to make strong adjustments rapidly so we could deliver and showcase that our company isn't limited to one engine. Just shy under two months coordinating the capture pipeline for Amsterdam 1652, in the end the job was to make sure nobody else had to "think about the plumbing".
Configured Persona3D's mocap studio to Backlight's exact technical specifications before shoot days began, closing the gap between two studios' pipelines so data could move between them without friction. Maintained system integrity across every live shoot, catching technical issues in real time rather than discovering them in post. No shoot day was lost to a preventable technical failure.
Tracked director and animator feedback take by take during live shoots, then organised, cleaned, and delivered the final motion capture data to the development team. Built and itterated a file and backup convention specific to this project's scale, which caught a data organisation issue before it reached the animation team and became a much more expensive problem to fix downstream. I also voulenteered to help our animation team cleanup and polish raw mocap data,. allowing us to keep the broader team's turnaround on schedule.
Persona3D's pipeline and expertise runs on Unreal and Metahumans. Backlight's build runs on Unity with custom characters. Rather than treat that as a blocker, adapted the capture and export process so our data came out in a format their Unity pipeline could actually use, without dramatically changing how we captured or rigged anything on our end. Proved the studio wasn't limited to a single engine on a live client project, which is a different kind of evidence than a slide in a sales deck.
Two studios speaking two different versions of "done." Backlight's pipeline expected data in a specific structure, and small assumptions on either side about what "ready" meant cost real time early on. Once we agreed on a shared file convention up front instead of discovering mismatches after delivery, the whole process got faster. I learned that pipeline coordination is mostly a communication problem wearing a technical costume.
Catching a data issue before delivery, rather than after, is the entire value of the role. Nobody notices good file management. They only notice bad file management, usually at the worst possible time. I built a habit on this project of treating every take like it had to survive being handed to someone with zero context, which is exactly what happens when data crosses from one studio's pipeline into another's.
Efteling's flagship 2024 attraction, the Danse Macabre got a major update in 2025. Myself and Persona3D were lucky enough to be part of that. We tackled the Ghostly Choir, a mocap-animated playback of stylized ghostly heads that reacted and acted within the going-ons of the ride. This was a deliverable that had to satisfy two clients who spoke completely different languages. Efteling's in brand and story, Mr.Beam's in their projection specs and pipeline. My job was to make sure the people from all three companies building them never had to guess which client's version of "done" they were working toward.
Managed Efteling and Mr.Beam simultaneously as a point of contact between them. One client thinking in creative vision and brand fidelity, the other in technical integration and projection constraints. Kept both sides moving without either one waiting on the other, and without our internal team ever having to reconcile conflicting instructions themselves. Two clients, two priorities, zero crossed wires.
I took Efteling's creative direction, combined with the demands and deliverables proposed by Mr.Beam and turned it into a production backlog the Persona3D team could actually execute against. A brief like "make it feel more unsettling" isn't a task. Converting that into specific, buildable, measurable work that our mocap animators and character artists could actually work with was done repeatedly across the delivery.
Supervised final asset delivery to ensure every character met Efteling's brand standard and Mr.Beam's technical integration requirements at the same time. Two separate bars, one deliverable. Caught mismatches between the two before they reached either client, which on a project with no room for a public misstep at a national attraction mattered more than it sounds.
Translating a creative note into a technical task sounds simple until you're doing it for a client who doesn't think in technical terms and won't. "More unsettling" is a real instruction and a completely unusable one until someone breaks it into lighting, timing, and motion decisions the team can build. I underestimated how much of my job was that translation, over and over, for weeks.
Working two clients at once taught me that alignment is a habit. The moment I stopped assuming both sides understood the same plan and started confirming it explicitly, small misunderstandings stopped turning into delivery risk. I'd rather over-communicate once than discover a mismatch after something's already built.
Metro Awakening had one hard rule: make this well-established, beloved franchise feel new in VR without making longtime fans feel like something was lost. I wasn't even the target audience going in. I'd never played a Metro game prior and wasn't really big into the FPS genre. Designing for a player I had to learn how to become and for a franchise I wasn't familiar with was the real brief beneath the brief.
Worked alongside the lead tech designer to develop the core locomotion of the player. Additionally designed and prototyped three key interactables, two of which (levers + health recovery) shipped in the final game. Built to survive VR's stricter physicality requirements. Anything a player can reach for and grab has to feel right in the hand, had to be understandable how to use by it's physical design while sticking to the franchise's look and feel. Each one went through multiple iteration passes before it earned its place in the build.
Analysed a set of recently released games at the team's request and used the findings to propose a unique selling point for the game. The feature itself was cut mid-production and didn't survive to final release. This happens on every project, but the analysis itself did its job: the team valued it enough to personally buy and play the games I'd researched in their own time, which told me the insight had landed even where the feature didn't.
Tested and reviewed programmers' custom code and Blueprint nodes before they reached the wider team, catching issues and suggesting improvements at the source rather than after they'd propagated through other people's work. Design and engineering rarely review each other's output this closely. Doing it caught problems earlier and cheaper than fixing them downstream.
Had never played a Metro game and wasn't a regular FPS player going in. Spent early weeks deliberately building the mindset of the actual target audience. What they expect from tension, pacing, and trust in this specific franchise, instead of designing from my own instincts. It worked well enough that I still play narrative FPS games now, after the project ended, for reasons that have nothing to do with the job.
Designing for a player I wasn't. My instincts as a designer are shaped by the genres I actually play, and FPS weren't one of them. I had to consciously set those instincts aside and build a new frame of reference from research, franchise history, and genre convention before I could trust my own design decisions on this project. That took longer than I expected, and I underestimated how much unlearning was part of the job
Good research and strong conclusions survives even when the feature built on it doesn't. The USP I proposed got cut, but the team's response to the analysis itself, enough that they went and played the games on their own time, taught me that the value of design research isn't only measured by what ships. Sometimes it's measured by whether it changed how the team thought, which is a harder thing to point at but just as real.
Designing VR locomotion esentially from scratch proved far more complex than expected. Rather than relying on Unreal's VR Template, I researched a wide range of locomotion methods, comfort options, and accessibility considerations before designing and implementing a modular movement system. Balancing technical constraints with player comfort gave me a much deeper appreciation for system design, iteration, and the importance of designing for diverse player needs from the outset.
Thankfully as a junior they didn't ask me to build locomotion from scratch, but rather assist the tech lead with building it. I was able to learn a lot and contribute by adding modularity to his core, refining certain bits of code and stress/playtesting to further refine the experience. This changed how I approach technical design. I now place greater emphasis on creating modular, extensible systems that are easy to iterate on for developers, configurable for different player needs, and future-proof to supporrt additional features down the road.
My first industry job, on a small team, which meant the job description on paper and the job in practice were two different things. Level design wasn't what I set out to specialise in. It's what the team needed at the time. So it's what I did for a large chunk of the time, and doing it well taught me more about adaptability than any project since.
I was assigned on level design as a core responsibility on a small team where roles shifted based on what the project actually required, not what anyone's title said. Built out sections of the open world with an eye toward pacing and player routing, learning the discipline on the job rather than coming in with it. Small teams don't have the luxury of narrow specialists. Neither did I.
The USP of this simulation game was the strong narrative, something uncommon for simgames. I worked closely with the narrative lead to design quests that wove and improved her story beats into the simulation gameplay. Balancing story pacing against the freeform, systems-driven expectations of the genre's core audience. Late in the project, I got to design a full skill tree and progression system from scratch, starting with paper prototypes before any implementation began, to validate the pacing and unlock structure before writing a single line of it into the engine. The system was cut for scope after I'd moved on to Vertigo Games, which happens more often than portfolios usually admit.
Worked directly alongside artists, engineers, and producers with far less separation between disciplines than a larger studio allows. For example, our core programmer was specialized with the Unity Engine, and often we would work together, sharing our knowledge to help establish this project in Unreal. Delivered design work to spec on a schedule that didn't bend, in an environment where picking up unfamiliar responsibilities wasn't optional, it was the job.
Being handed level design without having asked for it. I had to get good at it fast, on a live production, without the runway a specialist would have had. The version of me that finished this project was a meaningfully better and more versatile designer than the one who started it, and that only happened because the team's needs didn't care what I'd planned to specialise in.
Paper prototyping a system before touching the engine saved real time on the skill tree work, even though the feature never shipped. Validating pacing and structure on paper meant the parts of the design that were solid stayed solid, and the parts that weren't got caught before a single hour of implementation was spent on them. The feature getting cut for scope after I left doesn't change that the process behind it was right. Not every good decision survives to ship. That's not the same as it being the wrong decision.
The first live MetaHuman performance, establishing the technical pipeline later used across multiple future projects. Conceived, aquired funding, and led as Technical and Project Lead, Persona3D's flagship proof of concept. This event featured a custom fantasy character puppeteered in real time through motion capture. Built the production and technical pipelines from the ground up, creating reusable systems that became the foundation for future company productions. Delivered six live performances across two days at the United XR convention in Brussels, streamed from our motion capture studio in Baarn, Netherlands, with live audience interaction in every show. Wrote and secured the grant proposal that funded the project, culminating in the world's first public live Metahuman performance.
Served as Technical Coordinator and Scope Lead at Persona3D for Masters of Hardcore, one of the world's largest hardcore music events. Led technical planning and scope for a live Unreal Engine 5 Metahuman production, featuring a custom sea monster character puppeteered in real time through motion capture and displayed on massive LED screens alongside the live show. Delivered the project from client brief to live production in just over three weeks by making rapid scope and technical decisions, balancing quality, feasibility, and deadlines while keeping the client aligned throughout.
Served as Technical and Mocap Pipeline Coordinator at Persona3D for Amsterdam 1652, an XR/VR experience developed by Backlight for ENTR. Coordinated the end-to-end Unreal Engine 5 centered motion capture pipeline, configuring the studio to Backlight's specifications, maintaining technical integrity during live shoots, tracking director and animator feedback for each take, and organising, cleaning, and delivering final motion capture data to the development team. Also contributed animation cleanup to support production when capacity allowed.
Served as Tech Lead at Persona3D on a digital character delivery for Efteling's Danse Macabre. The Ghostly Choir deliverable consisted of projected digital characters built to Efteling's concept art, rigged with mocap data, and enhanced with exaggerated blendshapes, built in Unreal Engine 5 and integrated into the live attraction. Responsibilities spanned dual-client stakeholder management, translating vague creative briefs into specific, measurable, and technically achievable tasks for the internal team, and supervising final delivery to ensure all assets met both client's standards and pipelines.
Contributed to Metro Awakening as a Technical Designer, by designing and prototyping several key gameplay features. Built in Unreal Engine 5. AAA VR adaptation of one of gaming's most atmospheric franchises. The core design challenge was to translate the iconic feel of the Metro series into VR without losing its familiarity, tension, or player trust. The game shipped November 2024 across all major VR platforms and went on to receive multiple Game of the Year nominations, including Best VR/AR at The Game Awards and VR Game of the Year at the Steam Awards.
Worked as a Game Designer at Soedesco on Truck Driver: The American Dream. A narrative-driven open world simulation, built in Unreal Engine 4 shipping across console and PC. The core design challenge was integrating meaningful narrative and character progression into a genre traditionally defined by systems and freeform gameplay, making the game approachable and emotionally resonant without compromising what simulation fans expect.







