September 2025
With the conclusion of Phase 3, we’re bringing this round of funding to a close. Thanks to your support we’ve been able to work closely with the Endless team to learn how your young learners struggle with existing tools, to develop an approach that is both more accessible and more powerful, and to field-test it with youth and teachers in a real classroom. We’re pleased to say that feedback from our field trial was positive enough that our school-based partners are planning to use our Patchwork for Godot plugin again during the school year… as long as we can fix a few bugs.
We’ve enjoyed working on this project with you. The Endless Team have been supportive partners and we’ve been pleased to see that the collaboration approaches we pioneered in formal writing contexts with professional academics can be successfully translated to game development for less experienced youth.
Shortly behind this Phase 3 report we’ll send over the proposal for the next round of partnership. Now that we have demonstrated promise in the approach we would like to both focus on scaling the system to be more robust and easier to adopt, to continue integrating feedback from users, and to continue exploring more ways we can harness this novel approach to provide new classroom and community collaboration opportunities.
We partnered with a charter school in NYC that was running a two-week game design camp to pilot test our plugin.
The class consisted of approximately 15 students who were generally advanced, with many having some programming background. Two experienced teachers led the class. We monitored the sessions remotely for three days during the first week and received regular feedback from the teachers beyond.
What went well: The teachers told us that the branching/merging features in Patchwork are helpful for 1) enabling students to safely experiment, and to 2) collaborate more with one another. The students were able to create branches in Patchwork to organize their work, and seemed to understand the core concepts.
What could be improved: Stability and reliability prevented the tool from reaching its full potential. The teachers’ key feedback was: “prioritize stability over any changes to functionality and then this will be great for us.”
Overall, this test validated that the basic concepts of Patchwork are promising for helping students collaborate better, but more work is needed to solidify the plugin into something really solid for classroom use.
The teachers described branches as a way to try ideas and easily revert to known working states. (This seems like a helpful way to frame the value of branches going forward.) Both teachers and students appeared comfortable with the branching concept, including multiple layers of branches. The nesting branches UI seemed to work very well for communicating hierarchical branches.
All students successfully created branches off the main branch for their own work and then made sub-branches to explore further experiments.
Students created impressive projects! While this doesn’t directly validate the plugin’s effectiveness, it demonstrates Godot’s potential as a creative platform for students.
Students mostly worked solo on their individual games, with no direct collaboration on shared projects yet. However, teachers encouraged collaboration outside of Godot by having students write tutorials for new techniques they discovered. For example, one student figured out how to implement power-ups and shared this knowledge with classmates, resulting in half the class incorporating his implementation into their games.
During class sessions, Geoffrey, Paul, and Will remotely monitored student progress. When students encountered problems, they could approach the streaming laptop, enabling us to examine their branch and guide them through solutions.
We encountered various bugs, ranging from minor glitches that resolved with a reload to project corruption during merge operations. The sync server generally performed well, though it occasionally required restarts.
We traced most of the project corruption bugs to a single issue with Windows file paths. We deployed a fixed version after the first week. Unfortunately, both Geoffrey and Paul were unavailable to provide support during the second week, so we advised the teachers to go back to regular Godot for the second week.
In the second week, more students joined the class. The teachers decided to have new students use regular Godot without the plugin. Students with existing projects continued working with the plugin but avoided merging or switching branches. Unfortunately, they couldn’t update to the new version we shipped because the original bug had created invalid projects that were incompatible with the updated version.
The teachers were generally enthusiastic about the plugin’s benefits and fully understood the value of branching. They are excited to use the plugin in the upcoming school year once we have resolved the issues that emerged during the test run.
During the course of the week, we heard lots of ideas for plugin use cases from both teachers and students. Some of these validated ideas we’d had before, while some were new ideas we hadn’t thought of yet.
A few use cases are already well supported by our current feature set:
Remote support: We were able to provide live tech support over a call by opening students’ branches to see their work in real-time. The ability to view their project state was valuable for troubleshooting. We encountered some technical issues that prevented us from editing collaboratively or playing their games, but these will be solved in future iterations.
Class presentations: Instead of students connecting individual laptops to present their games in front of the class, they can switch to their branch on a shared classroom device for seamless demonstrations and discussion.
Home access: Students can continue working on projects from home rather than being limited to weekly class time on school laptops, enabling motivated students to build more ambitious projects. (Working from home shouldn’t be mandatory because some students don’t have computers at home.)
Beyond this, there are a couple more ambitious use cases which we think could also be supported by the plugin, but would require some more work to flesh out:
Game sharing: Students want to easily share completed games with friends and parents. Currently, they must manually export the game and upload it to a web server or share a binary file. The plugin could provide a share link for each branch that allows anyone to directly play the game in any browser.
Peer tutorials: Teachers encourage peer learning through Google Docs tutorials with screenshots. Instead, we could support this use case directly in the plugin. Students could share features as branches that other students can merge into their own games. They could also create interactive tutorials that directly modify game objects rather than relying on static documentation.
Users need the ability to revert to any prior version In the current plugin you can only revert to a prior version if you remembered to create a new branch before starting your work. This limits the usefulness of the history, because frequently students wanted to return to a prior version but they hadn’t made a branch first.
Presence features would help with live tech support During the class we were able to help students with their questions. We could check out their branch and see what they have been doing.
However, this is not enough to fully walk the student through a solution. Beyond updating state, it’s also important to point at parts of the editor to explain where they need to go to make an edit. The plugin currently has no way to show that in the editor, so we had to tediously describe where the student has to click.
If the plugin had more features like a shared mouse cursor or some way to point at parts of the editor UI, we think that could help with demonstrating and teaching how to use the editor in a shared session.
We need a user account system. To keep our prototype simple, we implemented an extremely minimal username system which assumes that the same student uses the same computer day to day. However, this adds extra work for teachers. It would be easier to manage a class over multiple days if students could log in on any computer and retrieve their work. A fuller user account system would also help prevent students from vandalizing each other’s work. We do need to make sure that it remains easy to create accounts and log in to reduce friction in the classroom.
We learned some useful things about deploying the Patchwork plugin into a school environment.
Shipping binaries is a lot of manual work: The IT team from KIPP NYC was very supportive; nonetheless, it required extensive back-and-forth communication to deploy new versions. Even though they had some automation in place, they still had to manually boot up all the laptops whenever we wanted to deploy updates to ensure the installation completed successfully. Our setup is particularly complex because we need to ship both a fork of Godot and the plugin. If we could upstream our changes to Godot, that would simplify deployment significantly. This experience also highlights the value of being able to run applications in the browser. If we could run Godot in the browser, that would be transformative.
Cross platform support is difficult: Godot is built as a cross-platform application, but since we also add native code, we have to deal with platform-specific problems. So far we’ve been mostly developing on Mac and testing on Windows occasionally. This led to us missing a critical Windows-specific bug. As a learning from the user test, Nikita is now switching to Windows as her main development platform to notice issues with Windows more immediately.
Establishing consistent processes is important: Things should stay the same for the IT team to make deploys seamless. This was sometimes difficult because as we were testing with the IT team, we evolved our process to build things more automatically. Unfortunately, we didn’t have our own certificate, so there was still some manual work required. Ideally we would automate everything, but if that’s not possible, having a fixed checklist is still valuable.
We need more realistic testing Our previous testing focused primarily on simple edits like moving platforms or adding some assets, while students in the actual classroom were performing more complex operations such as modifying scripts and adding new animations or replacing sprites. Going forward, we need to conduct more comprehensive testing with Justin and Will, who have deeper knowledge about Godot, to better stress test the system. We should establish a more rigorous protocol with a checklist of what should be tested to ensure we catch potential issues before deployment.
This pilot test validated that the core ideas of Patchwork could help students experiment more safely and collaborate more ergonomically, without needing to learn complicated git concepts. It also showed that we have more work to do on stability in order to fully realize the potential.
Our next step is to focus on stability and the highest priority issues raised in the pilot, to make progress toward a smooth classroom experience.
We have another test scheduled with KIPP NYC on October 17th. We have agreed that until then we will ship an MVP version:
Stable merging & branch switching We’ll continue to test the plugin ourselves and simulate more real usage by Will and Justin trying to collaborate on real things.
Revert to previous version In order to be more resilient to both bugs and mistakes from students we need granular revert. Every time the user saves we create a new version—this should be the granularity of revert. Teachers can then encourage students to save often so they can always revert.
Import existing projects The class flow starts with normal Godot and then switches to using the plugin, so we need a way to import existing projects.
Beyond these basics if there is more time, other features we are thinking about:
Our field trial has helped us focus our attention on some important problems to solve and we are consuming our modest remaining project budget to ensure engineering continuity and prepare for the next round of upcoming classroom trials.
Thanks for giving us this opportunity to work with you and your community. We hope our collaboration has been as satisfying for Endless at it has for us, and are eager to continue our partnership to bring these ideas to a broader audience.