The Engineering of Starweave
[p]![]()
[/p][p]It is the start of our second week of launch developer logs, and today's is technical! For our full launch schedule, check out our Steam page below:[/p][p][/p][p][dynamiclink][/dynamiclink][/p][hr][/hr][p][/p][p]Hi! [/p][p]I’m Sammy, the Engineering Lead for Starweave. In practice, I worked at the intersection of engineering and production—partnering closely with design, art, and narrative to assess feasibility, scope, and technical risk. A big part of my role was helping the team decide not just whether we could build something, but whether we should, given the project’s state and codebase, while also mentoring junior engineers along the way.[/p][p][/p][previewyoutube][/previewyoutube][p][/p][p]What challenges did you face with the production of Starweave?[/p][p][/p][p]Designing the game in a modular way. Even though Design laid out the sequences in a modular way, this posed many more challenges and required more custom implementation than expected! The system engineering build ended up modular, but we hadn’t really accounted for much of the actual labor required to implement each sequence, so that was hard to plan for at first.
[/p][p]Workflows and pipeline. We didn’t have as many tools built out as bigger teams at bigger studios typically have, like tools for narrative designers to implement content independently of engineering support. We wrote some custom tools in order to facilitate that process and reduce cross-team dependencies, but they were definitely jank and tailored to our situation!
[/p][p]Clear design requirements. We had a pretty awkward situation where engineering implemented something, but design later pointed out that it wasn’t functioning correctly. It had been like that in the builds for a while, and something must have gotten lost in communication for it not to be brought up for so long. I think if we were to do it again, clear design requirements, as well as a scheduled meeting with all relevant designers and engineers in the same room to review requirements together, would have helped.[/p][p][/p][p]![]()
[/p][p]How do you stay organized on a project like this?[/p][p][/p][p]Strong communication! For my part, I was largely working with Design, Usability and Narrative (I had a partner engineering lead who handled most of the Art and Tech Art Implementation and tracking). We stayed aligned with all other disciplines through regular communication with other leads, our engineering syncs, and reviewing git commits.
[/p][p]We also established cadences that worked particularly well for engineering, such as our weekly builds. Every Monday, I’d create new Windows and Mac builds, and at least one engineer and I would play through at least 30 minutes of the build, if not the whole build, and I’d write detailed patch notes to deliver to usability. These helped us match specific content, bugs, etc., to specific builds and gave me and other leads a rough idea of the state of the build.
[/p][p]Also, ClickUp, Docs and Spreadsheets, Spreadsheets galore![/p][p][/p][p]![]()
[/p][p]What does “engineering” for games look like? What’s an average day for you?[/p][p][/p][p]On Starweave, my day probably looked a lot less like what people imagine when they think of an engineer. I actually wrote very little code on the project. Instead, my focus was on ensuring the engineering team had what they needed to succeed and that our technical direction remained aligned with the project’s scope and goals.
[/p][p]A typical day would start with reviewing the latest build, checking recent commits, and assessing how new changes impacted performance, stability, or production timelines. From there, a lot of my time was spent in conversation—meeting with design, art, and narrative to understand their needs, evaluating technical feasibility, and translating those discussions into clear, actionable work for engineers.
[/p][p]I see engineering leadership as creating clarity. That means identifying risks early, helping the team make smart tradeoffs, and smoothing over friction between technical and non-technical disciplines. My role was less about programming features myself and more about building the structure and communication that allowed the team to ship them effectively.[/p][p][/p][p]![]()
[/p][p]If you could revisit the project now, what would you change?
[/p][p]Building out more robust tooling and clearer workflows and handoffs! I think a lot of our workflows ended up being manual labor that could have, and should have, been automated.
[/p][p]Having clearer conversations! I would say something I learned from Starweave is the concept that “everyone cares about something different”. A lot of documentation that ended up on engineering’s doorstep for implementation was incredible for design, but I think it was missing a layer of translation to turn it into clear engineering requirements. I wish I’d been more persistent about gathering design into a meeting and working through their design documentation with them into clear engineering requirements. This would allow for clearer visibility into edge cases and architecting a clean system. Towards the end of the project, we were fixing many unanticipated edge cases that led to a lot of spaghetti code.
[/p][p]I’d also love to go back and rearchitect parts of the system that would’ve allowed more flexibility for big design changes. As we were preparing to publish the game, we had ideas for a segmented action queue that would allow players to do a movement and an action each turn. Due to the strict setup of our original combat system, it wasn’t possible to implement, and it would’ve required significant engineering effort. But the change would’ve been cool, and I think players would’ve really liked it! I wish we could go back, do a health pass on that code, and implement some of these design changes. [/p][p][/p][p]Are there any projects you’ve worked on since then that you want to shout out?[/p][p]
Definitely The Wind and the Wisp! I took a lot of lessons from Starweave into that project, both the processes that worked and the things we could’ve improved. Without Starweave, The Wind and the Wisp would not have shipped on time![/p][p][/p][previewyoutube][/previewyoutube][p][/p][hr][/hr][p][c]Sammy is the Engineering Lead for Starweave. She earned her BFA and MFA in Game Design at New York University and the University of Southern California, respectively, where she met Rachel Geng. She has led teams to ship Indie titles, including [/c]The Wind and the Wisp[c].[/c][/p][p][c]Sammy is the Engineering Lead for Starweave. She earned her BFA in Game Design from New York University and her MFA from the University of Southern California, where she met Rachel Geng, who first pitched the idea for Starweave.[/c][/p][p][c]With a background in engineering and a growing focus on production, Sammy works at the intersection of technical and creative disciplines—helping teams navigate feasibility, scope, and collaboration across art, design, and code. She has led teams to ship indie titles, including The Wind and the Wisp, and has given talks at Northeastern University and Uppsala University on The Wind and the Wisp and creative production. [/c][/p][p][c]She is especially interested in how games can communicate unspoken feelings, bring people together, and help us feel less alone in the world. Outside of development, she enjoys hiking and exploring random topics for niche powerpoint nights. [/c][/p]
[/p][p]Workflows and pipeline. We didn’t have as many tools built out as bigger teams at bigger studios typically have, like tools for narrative designers to implement content independently of engineering support. We wrote some custom tools in order to facilitate that process and reduce cross-team dependencies, but they were definitely jank and tailored to our situation!
[/p][p]Clear design requirements. We had a pretty awkward situation where engineering implemented something, but design later pointed out that it wasn’t functioning correctly. It had been like that in the builds for a while, and something must have gotten lost in communication for it not to be brought up for so long. I think if we were to do it again, clear design requirements, as well as a scheduled meeting with all relevant designers and engineers in the same room to review requirements together, would have helped.[/p][p][/p][p]
[/p][p]We also established cadences that worked particularly well for engineering, such as our weekly builds. Every Monday, I’d create new Windows and Mac builds, and at least one engineer and I would play through at least 30 minutes of the build, if not the whole build, and I’d write detailed patch notes to deliver to usability. These helped us match specific content, bugs, etc., to specific builds and gave me and other leads a rough idea of the state of the build.
[/p][p]Also, ClickUp, Docs and Spreadsheets, Spreadsheets galore![/p][p][/p][p]
[/p][p]A typical day would start with reviewing the latest build, checking recent commits, and assessing how new changes impacted performance, stability, or production timelines. From there, a lot of my time was spent in conversation—meeting with design, art, and narrative to understand their needs, evaluating technical feasibility, and translating those discussions into clear, actionable work for engineers.
[/p][p]I see engineering leadership as creating clarity. That means identifying risks early, helping the team make smart tradeoffs, and smoothing over friction between technical and non-technical disciplines. My role was less about programming features myself and more about building the structure and communication that allowed the team to ship them effectively.[/p][p][/p][p]
[/p][p]Building out more robust tooling and clearer workflows and handoffs! I think a lot of our workflows ended up being manual labor that could have, and should have, been automated.
[/p][p]Having clearer conversations! I would say something I learned from Starweave is the concept that “everyone cares about something different”. A lot of documentation that ended up on engineering’s doorstep for implementation was incredible for design, but I think it was missing a layer of translation to turn it into clear engineering requirements. I wish I’d been more persistent about gathering design into a meeting and working through their design documentation with them into clear engineering requirements. This would allow for clearer visibility into edge cases and architecting a clean system. Towards the end of the project, we were fixing many unanticipated edge cases that led to a lot of spaghetti code.
[/p][p]I’d also love to go back and rearchitect parts of the system that would’ve allowed more flexibility for big design changes. As we were preparing to publish the game, we had ideas for a segmented action queue that would allow players to do a movement and an action each turn. Due to the strict setup of our original combat system, it wasn’t possible to implement, and it would’ve required significant engineering effort. But the change would’ve been cool, and I think players would’ve really liked it! I wish we could go back, do a health pass on that code, and implement some of these design changes. [/p][p][/p][p]Are there any projects you’ve worked on since then that you want to shout out?[/p][p]
Definitely The Wind and the Wisp! I took a lot of lessons from Starweave into that project, both the processes that worked and the things we could’ve improved. Without Starweave, The Wind and the Wisp would not have shipped on time![/p][p][/p][previewyoutube][/previewyoutube][p][/p][hr][/hr][p][c]Sammy is the Engineering Lead for Starweave. She earned her BFA and MFA in Game Design at New York University and the University of Southern California, respectively, where she met Rachel Geng. She has led teams to ship Indie titles, including [/c]The Wind and the Wisp[c].[/c][/p][p][c]Sammy is the Engineering Lead for Starweave. She earned her BFA in Game Design from New York University and her MFA from the University of Southern California, where she met Rachel Geng, who first pitched the idea for Starweave.[/c][/p][p][c]With a background in engineering and a growing focus on production, Sammy works at the intersection of technical and creative disciplines—helping teams navigate feasibility, scope, and collaboration across art, design, and code. She has led teams to ship indie titles, including The Wind and the Wisp, and has given talks at Northeastern University and Uppsala University on The Wind and the Wisp and creative production. [/c][/p][p][c]She is especially interested in how games can communicate unspoken feelings, bring people together, and help us feel less alone in the world. Outside of development, she enjoys hiking and exploring random topics for niche powerpoint nights. [/c][/p]