The Survivors
A team-built Roblox game where I served as lead engineer, turning systems from multiple scripters and UI designers into one coherent build.
Acted as the integration point for the whole team. Scripters and UI designers handed me their systems and products, and I assembled them into a single working game, resolving conflicts and bugs along the way.
- Role
- Lead Engineer
- Team size
- Team build
- Updated
- 2026-06-12
Overview
What the project is and why it mattered.
The Survivors was a team-built Roblox game and my first real experience leading engineering on a multi-person project. Beyond building some of the core systems myself, my main job was making everything fit: every script, mechanic, and interface the team produced passed through me before it became part of the game.
Role
Lead engineer and integration owner
Team
Multiple scripters and UI designers contributing systems
Craft
Systems building, debugging, coherence
Problem
A team of independent scripters and UI designers produces work in different styles, with different assumptions, on different timelines. Without one person responsible for integration, those pieces drift into conflicts, duplicated logic, and bugs that no individual contributor owns. The project needed an engineering lead who could absorb that work and ship one coherent build.
Role
I was the lead engineer. I built several of the game systems myself, then took on integration ownership: collecting systems and UI from the rest of the team, wiring them together, fixing the bugs that surfaced at the seams, and keeping behavior consistent across the whole experience.
Build details
Stack, constraints, and decisions.
Stack
Constraints
- Contributions arrived from multiple scripters and UI designers with different coding styles and assumptions, and all of it had to coexist in one place.
- Integration bugs rarely belonged to a single contributor, so ownership of cross-system issues defaulted to me.
- The game had to stay playable while new systems landed, which meant integrating incrementally instead of in big risky merges.
Decisions made
Own the mainline
Rather than letting everyone wire their own work into the game, every system and UI product came through me. One integration point meant conflicts were caught by the person with the most context on the whole build.
Make coherence a deliverable
Consistent behavior across mechanics mattered as much as the mechanics themselves, so I treated normalizing interactions, naming, and state handling as real engineering work, not cleanup.
Fix bugs at the seams
Most defects appeared where two contributors' systems met. I prioritized debugging those handoffs over polishing individual features, because that was where the game actually broke.
Outcome
What came out of it.
Outcome
- Built core game systems and integrated every scripter and UI designer contribution into one playable, coherent build.
- Served as the de facto technical decision-maker for how systems connected and behaved.
- Maintained a working game through continuous integration of new team contributions.
Lessons
- Leading engineering on a team is mostly communication: understanding what someone built, what they assumed, and what will break when it meets everything else.
- Integration is a skill of its own. Reading and reconciling other people's code taught me more than writing my own systems did.
- A team moves faster when one person owns coherence, even if that person writes less feature code as a result.
Next
- Development is paused. I stepped away in 2025 to focus on web development, software development, and pursuing cybersecurity.
Keep browsing
Keep moving through the archive or reach out if you want to talk through similar work.