John Sensebe’s Portfolio

A portfolio for John Sensebe, software engineer.

How I Work

Approach: Deterministic Systems, Clear Architecture, Practical R&D

Strengths: Problem Solving, Cross‑Disciplinary Engineering, Maintainable Code, Team Support

Overview

My engineering approach is shaped by years of building complex simulation trainers, VR experiences, and game prototypes. I specialize in solving problems that span multiple systems — animation, navigation, UI, input, state machines, and procedural logic — and I focus on designing solutions that are deterministic, maintainable, and easy for other engineers to extend.

I’m often the engineer teams rely on when a problem doesn’t fit neatly into one category, or when a feature requires coordination across several subsystems. I work best in environments where accuracy matters, where systems must behave predictably, and where the engineering challenges are not fully defined at the start.

Core Principles

1. Deterministic Behavior

Whether I’m building a simulation trainer or a game system, I prioritize deterministic behavior. This ensures:

Determinism is especially important in multi‑trainee simulation environments, where even small inconsistencies can cascade into larger issues.

2. Build Systems That Are Easy to Extend

I design systems with clarity and maintainability in mind. My goal is to make it easy for other engineers — especially junior engineers — to build on top of my work without needing constant guidance.

This means:

Several of my systems have been extended by other engineers with minimal assistance, including the 688i trainer and EMALS.

3. R&D First, Production Second

For complex features, I start with rapid prototyping. I build small, focused experiments to validate ideas before committing to full production.

Examples include:

These prototypes help teams understand what’s possible, reduce risk, and provide a clear roadmap for production.

4. Solve Problems Across Subsystems

Many of the challenges I’ve faced required solutions that span multiple Unity subsystems. I’m comfortable working across:

This cross‑disciplinary approach allows me to design systems that work cohesively rather than as isolated components.

5. Understand the User Workflow

Whether the user is a trainee, a VR player, or an operator, I design systems around how people actually interact with them.

This includes:

In simulation trainers, this often means working closely with SMEs and written procedures to ensure accuracy and usability.

6. Communicate Clearly

I believe engineering clarity extends beyond code. I communicate design decisions, constraints, and implementation details in a way that helps teams move forward confidently.

This includes:

Clear communication keeps projects aligned and reduces friction between disciplines.

7. If You Do It Twice, You’ll Likely Do It Again

This rule guides how I structure code. One instance of a routine can stay in the class where it was written, but once I find myself copying that routine elsewhere, it’s time to separate it out — whether into a standalone function, a new class, or a shared parent class. This prevents ad‑hoc or copy‑and‑paste solutions and gives the entire team a reliable, reusable tool.

Problem‑Solving Style

Analytical

I break problems down into smaller parts, identify constraints, and design solutions that address the root cause rather than the symptoms.

Practical

I choose solutions that balance correctness, maintainability, and production realities. I avoid over‑engineering and focus on what the project actually needs.

Iterative

I refine systems through testing, feedback, and incremental improvements. R&D prototypes often evolve into production systems.

Collaborative

I work closely with SMEs, artists, designers, and other engineers to ensure systems behave correctly and integrate smoothly.

What I Bring to a Team

Representative Projects

← Back to Home

© 2026 John Sensebe — Gameplay & Simulation Engineer