The Survivors
A team-built Roblox game where I served as lead engineer, turning scripts and UI from multiple contributors into one playable build.
Acted as the integration point for the whole team. Scripters and UI designers handed me their scripts and interface work, and I assembled them into a single working game while resolving conflicts and bugs.
- 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 playable build.
Role
I was the lead engineer. I built several of the game systems myself, then took on integration ownership: collecting scripts and UI from the rest of the team, wiring them together, fixing the bugs that surfaced at the handoffs, and keeping behavior predictable.
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 mechanics and integrated every scripter and UI designer contribution into one playable 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 the mainline, 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.