Vincent Schwier
Junior Gameplay Programmer — Unity & Unreal
I build gameplay systems with a strong focus on multiplayer fundamentals, clear state-driven logic, and production-ready code. I’ve shipped a co-op title on Steam as a solo developer.
Start with Undercover it contains the most relevant multiplayer engineering work.
Projects
I keep a broad range of finished projects, but the main focus is my shipped multiplayer title and the systems behind it.
Undercover
Online co-op game focused on communication and social deduction. Built with a server-driven event flow and shipped to Steam.
• Server-driven match flow using ServerRpc + ObserversRpc event-style transitions
• Steam lobby + matchmaking flow + session join/leave handling
• State-driven gameplay systems (round flow, meetings, win conditions)
• Custom Unity editor tools to speed up iteration
• 16,000+ lifetime units
Important lesson (security): early versions replicated too much sensitive game data to clients. If rebuilt, I would keep sensitive info (e.g. roles) server-side and send clients only what they need.
Interview-style breakdown
- Model: server-driven gameplay transitions; clients render UI/feedback.
- Sync approach: explicit “one source of truth” events via ServerRpc → ObserversRpc.
- No prediction: avoided correction complexity; would add selective prediction for low-risk feedback next time.
- Shipping realities: handling disconnects, edge cases, and patching real player issues.
Impact
- Shipped a complete online co-op experience as a solo developer.
- Improved stability by moving desync-prone UI/state changes to server-driven events.
- Reduced network spam by replacing frequent RPC patterns with event-style messaging.
Last Chance
Puzzle game built to explore modular Blueprint-based systems.
• Reusable interaction components
• Clean separation of gameplay logic
Benny’s Adventure
3D platformer focused on player movement and gameplay feel.
• Camera behavior & feedback
• Blueprint-driven core mechanics
Estania
Atmospheric exploration game with focus on pacing and storytelling.
• Audio-driven mood design
• Narrative pacing through gameplay
Additional Work
Other projects and jam work
Xenite Defender
Sci-fi tower defense: build defenses at night to protect xenite mining operations from enemy droid fleets.
• Enemy wave pacing + simple economy tuning
• Clean separation between placement, targeting, and wave logic
Book of Dreams
2D pixel-platformer built to strengthen gameplay fundamentals.
• Collision & enemy logic
• Game-feel tuning
Reboot Eden
5-day game jam project created under heavy time pressure.
• Team collaboration
• Complete gameplay loop delivery
Engineering Highlights
This section is intentionally technical. It’s based on real problems I hit while shipping a multiplayer title and how I solved them using a server-driven, event-based approach.
Authority model (and what I’d improve)
- Current (shipped): many gameplay-relevant values were replicated broadly to simplify early development.
- Why: reduced complexity and made iteration fast while building the full loop as a solo dev.
- Downside: not ideal for security (cheat clients can use extra knowledge).
- If rebuilt: keep sensitive data (roles) server-side and send clients only “need-to-know” presentation info.
Sync strategy: ServerRpc → ObserversRpc
- Goal: prevent clients entering different UI/gameplay states due to timing.
- Approach: clients request actions via ServerRpc; server validates and broadcasts a single event via ObserversRpc.
- Result: one authoritative trigger + payload → consistent screens and state across all clients.
Real bug story: Meeting screen desync
- Symptoms: meeting screens appeared inconsistently across players; sometimes player colors/UI info mismatched.
- Cause: clients could enter UI based on partial/local timing rather than a single authoritative transition.
- Fix: moved the transition to a server-driven event model: Meeting request via ServerRpc → server validates → broadcast payload via ObserversRpc (caller, deaths, screen type). Clients apply UI locally using that payload.
- Outcome: meeting flow became consistent across clients and desync-style UI bugs dropped significantly.
Disconnect handling (simple + robust)
- Host leaves: session ends and all players return to the menu/lobby flow.
- Client disconnect mid-round: treated like a death/removal; no mid-round rejoin.
- Why: avoids complex state reconstruction and keeps round rules deterministic.
Network optimization
- Issue: too many frequent updates/RPC calls created network spam and timing issues.
- Fix: keep only essential logic in Update; move most transitions to event-based messages.
- Effect: clearer network behavior, fewer messages, improved stability during busy moments.
If I rebuild Undercover
- Split larger scripts into smaller components with clearer responsibilities (maintainability).
- Redesign sensitive data handling (roles) to be server-only and “need-to-know” on clients.
- Add selective prediction for low-risk feedback (animations/UI) while keeping outcomes server-authoritative.
- Apply the networking strategies I learned earlier to reduce iteration cost and avoid early tech debt.
Skills
Gameplay & Systems
- Gameplay systems & state machines
- Networking fundamentals (client-server authority)
- Debugging, instrumentation, iteration speed
Tools
- Unity (C#), Unreal (Blueprints)
- FishNet, Steamworks
- Git / GitHub
- FMOD, Blender, Substance
About
I’m a game creation student and solo developer focused on finished, shippable projects. My main strength is building clear gameplay systems and applying multiplayer fundamentals in a production setting (shipping and supporting a Steam release). I’m currently looking for a junior gameplay role at an indie studio where I can contribute to gameplay systems, multiplayer features, and clean, maintainable code.
Contact
Best ways to reach me: