Beckett Sequel Proposal
Beckett Sequel Proposal
This is a proposal for a new phase of work between Endless Foundation and Ink & Switch, developing better collaboration tools for Godot. We’ll recap where we’ve come so far, and why continued investment in the work could be valuable.
We started working together after hearing about the challenges faced by educators teaching git in the classroom. Our goal was to make an initial prototype of an approach to collaboration in Godot which would avoid some of the frictions of git, while still preserving valuable collaboration patterns like asynchronous branching.
Over the past 9 months we’ve built a prototype—a plugin for Godot which provides live and asynchronous collaboration on games, with diffing and branching built into the editor. You can see our last report for a demo and an overview of what it does.
We have some early positive signals. Justin and Will feel that the functionality in the plugin is on track to deliver value in educational contexts—both patching over existing frictions, and enabling new pedagogical patterns. We’ve run several test runs with indie developers in the Godot community who were very enthusiastic.
However, there are still open questions and challenges. We haven’t tested it in the classroom yet—our first pilot is planned for August with KIPP NYC—and we know that we’ll need to iterate on the design in response to what we learn there. Also, while we’ve made huge strides in plugin stability and performance, adding a new collaboration system to an existing game engine is a difficult technical challenge that will require continued investment. We need to do more work to make it really robust.
Meanwhile, the context within Endless has also changed since we started. The focus on Threadbare has introduced larger, more complex games than earlier exercises like Moddable Platformer, as well as larger-scale collaboration patterns.
We propose a 6-9 month project continuing to invest in the plugin, with several goals:
Our primary goal is to serve learners in the Endless program, which has evolved significantly since we began this work. Initially, students worked individually on separate games like Moddable Platformer. Now the program centers on collaborative projects where students contribute levels to shared games like Threadbare. This shift brings new challenges: coordinating work across larger teams, managing long-term collaboration, and handling merges as multiple contributors make simultaneous changes.
Currently, students use a Git-based workflow. At the beginning of the program, students are split into teams, and each team receives their own fork of the main Threadbare repository. Within their team’s fork, students create separate branches to work in parallel. Once a student completes a task, they create a pull request on their team’s fork to merge back to the team’s main branch. When the team reaches a milestone, they create a pull request against the original Threadbare repository to upstream their changes. This approach has several problems:
Significant class time is consumed by repository setup and teaching students the difference between the main repository and their team’s fork. GitHub contributes to that confusion — when a student creates a pull request, GitHub defaults to targeting the original repository rather than their team’s fork. If the student doesn’t realize this, they create upstream PRs instead of merging changes back to their own project.
The pull request workflow feels overly formal for internal team development. While formal reviews make sense when upstreaming to the main game, forcing students to use pull requests adds a lot of friction. The main reason why the program encourages PRs for team collaboration is to prevent students from breaking the game. If concurrent changes could be merged automatically and it was easier to recover from a broken state of the game, maybe such a formal process might not be necessary. Potentially PRs could encourage students to reflect more about their changes. Unfortunately GitHub presents the changes as text files which are hard to understand, so students mostly merge their changes without reviewing them.
To support students working on their project, the program has mentors that can help out during the lesson. The problem is that even for the mentors Git is new and they don’t have deep knowledge to conduct meaningful reviews, defaulting to merging without proper review. If reviews were more accessible, mentors could focus on game feedback rather than the complexities of Git.
The collaboration plugin we’ve been building for Godot is well suited to solve these problems by providing a lighter weight collaboration experience for the within-team collaboration part of the Threadbare workflow. We envision students on the same team collaborating with one another in real-time or on asynchronous branches, without needing to use Git or GitHub at all. This would support informal collaboration and peer review, without the formalities and complexities of Git and pull requests.
This informal within-team workflow could fit naturally together with the existing GitHub workflow for submitting changes back to the global Threadbare project. When a team wants to submit their work upstream, they could do so in a formal pull request process to the Endless repository, which would remain the source of truth for Threadbare. The existing GitHub workflow makes sense for this less frequent and more formal collaboration workflow.
Our plan would be to provide a seamless experience for moving back and forth between these two collaboration experiences for lightweight within-team collaboration and more formal workflows for upstreaming work. (Because both Git and our plugin work by editing files on the filesystem, we are optimistic this is achievable.) Our hypothesis is that separating these two workflows more would remove a lot of confusion that students are currently encountering from using Git for both, and would let the more informal collaboration among students live in a more appropriate tool.
At the end of this project, our goal is:
We envision a similar scope and budget to the previous project: 6-9 months, and x$.
Given that the project is better defined this time, we don’t need a part-time pre-infusion phase. The entire project time would be dedicated to executing on known problems, and iteratively testing. (It’s still helpful to have up to 9 months of time because testing with students can be a scheduling bottleneck).
The team would remain Paul Sonnentag as project lead (part-time) and Nikita Zatkovich as Godot engineer (full-time), and would likely add one extra person to help with engineering and/or design work.
Right now our plugin is mostly suitable for small projects and short-term collaborations like the moddable platformer where each student works on their own to create their own version of a level over a few sessions. If we want to support collaborations where multiple students work together on a larger game like the Threadbare project, we need both additional collaboration tools and we need to work on the infrastructure of the plugin to improve the stability and reliability so it can scale to larger projects.
We haven’t designed a good workflow yet for how to set up the project and how to share a project with other people. Right now this is very manual: when you add the plugin to a new project it generates a file with a project id. If you want to share your project with someone else you either need to share the project id and the other person has to set the project id manually, or you share the whole project as a zip file. Instead we want a workflow where an instructor can easily share a URL to a project and students can directly import it into Godot.
Beyond making the onboarding easier, another question is: once you have your project set up with our plugin, how does it interface with the existing world? We think that at least in the medium-term GitHub will be an important part of the workflow for running classes with Threadbare. So we need a way that you can push the changes you make in the plugin to GitHub. For example, we could add a PR feature that allows students to create a PR from within Godot so the changes can then be reviewed on GitHub.
Integrating with Git would make it also less risky for indie devs to adopt the plugin. Git could serve as the long-term backup of the history so if at some point the plugin doesn’t yet support a more advanced workflow, you can always switch back to Git.
Most of the learners we work with do not have English as their first language. Currently we have them using GitHub, which (to our surprise) is not translated! By contrast, Godot itself has pretty good translations for the languages our learners use (primarily Spanish). If the necessary infrastructure were added to the Patchwork addon for it to be translated, we could provide & maintain a Spanish translation in-house.
Our Godot plugin currently uses Automerge’s Rust libraries, but there’s a compatibility problem: the Rust version can’t talk to the web version of Automerge. This limits our ability to experiment with Godot on the web and integrate with the rest of the Patchwork system.
The Automerge team is working on “Beelay,” a new system that will solve this by unifying both versions. Once we can switch to Beelay, we’ll get two major benefits:
Beelay is still in early development. We need to coordinate with the Automerge team to understand their timeline and plan our transition accordingly. This work will likely happen toward the end of our project when Beelay is more stable.
Currently the Patchwork GDExtension must be used together with a patched build of the editor. While not a blocker for testing the tool with learners, it does add another point of end-user confusion during setup (and regular use) and may preclude certain institutions from being able to access the tool. If the changes necessary to support the Patchwork addon are now understood and relatively stable, then now may be a good time to submit these upstream so that the Patchwork GDExtension can be used with an unmodified build of the editor, and we could potentially have it present in the Threadbare Git repository (or perhaps in snapshots we publish) for ease of setup. This would, of course, help the “Onboarding & Export” goal, but the Godot release cycle means that we can’t expect this to be part of a stable Godot release during this batch of work. The goal should be to have the plugin be usable against the latest build of the development branch of Godot.
Currently, the plugin handles small projects and simple edits well, but struggles with the complexity of larger collaborative projects like Threadbare. We’ve identified several specific issues that need fixing:
These are just the issues we know about. Testing with real Threadbare-scale projects will likely reveal additional bugs that only surface with more complex collaborative workflows. We’ll need to build a tight feedback loop between testing and bug fixes to make the plugin robust enough for classroom use with Threadbare.
Performance becomes a problem as projects get bigger. When we tested with projects the size of Threadbare, switching between different versions of the work takes too long and interrupts students’ flow. We need to figure out what’s slowing things down:
Our goal is to make branch switching take less than 5 seconds in Threadbare-sized projects, so students can collaborate smoothly without waiting around.
In order to make the plugin maintainable in the long run, we need to set up some automated tests. The goal is not to create an exhaustive test suite. Instead we should be opportunistic and find a way to create a few tests for the core workflows of the plugin.
In addition to all of these basic improvements, we have a stretch goal of exploring web browser support for Godot and our collaboration experience. The goal would be a zero-install experience for collaborating on games. This could mean running the entire Godot editor in the browser, or it could mean a lighter experience that would serve as a replacement for GitHub specialized to the needs of collaborating on Godot games.
This is an area with tremendous opportunity, but also a lot of technical risk and uncertainty. We would prioritize it secondary to the rest of the improvements listed above and would start with some small explorations to see if there’s anything viable to do here.
Each of the collaboration features listed above could be a whole project on its own. We believe it’s important to improve all areas of the plugin so we’ll strictly timebox each feature to 1 month. We might not get to implement everything in each feature bucket, but strict timeboxing will ensure that we improve the plugin on all the dimensions we care about.
In between feature work we want to spend 1 month on improving support for Threadbare. This will touch all the infrastructure topics: scene file support, large assets, unit tests and upstreaming changes to Godot. As we work more on making Threadbare work, we will learn more about what the issues are. Based on how hard that is, we can adjust the split between features work and infrastructure work.
The only larger infrastructure work that needs uninterrupted focus is “Switching to the new sync protocol”. We need to coordinate this work with the Automerge team. Probably we will work on this towards the end of the project when the new sync protocol is more mature.
Here is how a potential project plan could look:
We can also consider ways of engaging the broader Godot community, both to ensure that our work is proving valuable outside of the educational context, and to gather attention that could help with ongoing open source maintenance. Some ideas:
Sponsor a game jam: Organize our own or partner with existing organizers, sponsor prizes, create clear setup documentation, provide support during the event, and collect feedback afterward.
Fund indie developer scholarships: Provide $500-1000/month for 3 months to 2-3 active indie developers, meeting biweekly for interviews about their collaboration experiences. Financial incentives would motivate more serious testing of our tool.