Beckett - Project Proposal
Beckett - Project Proposal
Team:
Schedule:
We’ve heard from the team at Endless Learning that collaboration and version control are a huge pain point when teaching Godot in the classroom. Students must learn about files, command lines, and complex terminology before they can do any collaboration. This is not to say that version control isn’t important—it’s a critical tool and a valuable one for students to learn. But there should be a smoother on-ramp that allows students to initially collaborate with less friction, and that allows for more complex concepts to only be introduced as needed.
Even once users have learned to use it, Git still isn’t an ideal fit for game development in Godot. Merge conflicts are challenging to handle, because git only operates on text files, and has a confusing UI for addressing conflicts. The version control system isn’t closely integrated into the IDE, so concepts like branching and diffing feel separated from the core development process. It’s not easy to do things like review the history of a student project or comment on changes from directly within the IDE.
These challenges are acutely visible in the classroom setting, with younger students learning the basics of game development. But they also apply to the broader Godot community, especially smaller teams of indie devs and hobbyists.
We believe it’s possible to design a better version control system that:
So far, in the Preinfusion phase, we’ve sketched and implemented a variety of early prototype directions, and received several rounds of feedback from the team at Endless Learning. Based on that feedback, we’ve decided on a direction for our implementation phase.
We’ll start by integrating basic Automerge collaboration into the Godot editor, so users can collaborate on all aspects of a game asynchronously or in realtime, without needing to think about files or git. This simple foundation will already support use cases like collaboratively modding a game in small groups.
Then, we’ll layer on more sophisticated tools on top of this foundation to grow its capabilities: creating/merging branches, reviewing what’s changed on a branch, and previewing/addressing conflicts. These tools will support richer collaboration scenarios, like a group asynchronously collaborating on a project, or a teacher reviewing student work in a classroom setting.
Before explaining the project milestones, let’s briefly revisit the intended goals and scope of this project. We’ve previously discussed these with the Endless team, but it’s good to ensure we’re aligned.
During the implementation phase (roughly mid-January to early April), we will design and implement prototypes of a version control system for game development in Godot. Compared to the preinfusion phase, these prototypes will go more in depth - not just building a technical proof of concept, but also designing a good UX and making it solid enough to test with real users. We’ll build on our Patchwork platform which implements “universal version control” tools on top of the Automerge data sync library.
We’ll also test these research prototypes with the Endless team to learn about how they can support the classroom experience of learning game dev in Godot. Although we have reserved time for an evaluation period starting in April, we’ll also plan to do some preliminary testing during the implementation phase to get early input.
Two important notes about deliverables:
The deliverable of this project will be research prototypes, not production software. The software will be functional enough to support real usage and useful testing/feedback, but it won’t be designed for permanent ongoing use and maintenance. If the prototypes seem promising, we can discuss future avenues for developing them further.
We intend to produce work that is relevant not only to the needs of Endless Learning, but also to the broader Godot community. We’re confident that we can find plenty of overlap between the needs of students and the broader development community.
Here’s a sketch of how the project will progress. There are 3 initial milestones that build on each other. (These screenshots are very rough sketches to explain the ideas; they’re obviously not finished designs.)
est. 4 weeks
Before we can deeply explore the challenges of collaborating on games we need to nail down the basics: A solid implementation for syncing changes and basic branches so users can fork off to work in private and later merge back their changes. Beyond being a technical foundation we believe that this first milestone will be already useful for running a more solid version of the game jam we ran in the preinfusion. The scenario could look like this:
An instructor opens a moddable Godot project and with the Patchwork plugin they connect the project to be synced through Automerge. They then share an url to the project with the students. Each student can import the project and create a separate branch to jam on the game. The instructor can view the branch of each student and see their progress. Students can also checkout branches of other students to see what they have made.
This milestone will cover a solid implementation of syncing and basic branches. Unlike the prototype we’ve built in preinfusion, this implementation will support syncing all files of any Godot project (scene files, assets and code). We will also build some basic UI to setup sync for a project and import projects from an automerge URL. We might also need to implement some simple access control mechanism so that branches of other students are read-only. Our goal is not to design a real access control system, only build as much as is necessary to do a test run with real students.
During this initial phase, we don’t plan to add any features like presence, diff views, merge previews or handling merge conflicts. Technically it would be possible to use this version to build complete games since the whole project is synced, but we think it will be mostly suitable for modding games since it will lack a lot of features required for more serious work. For example, if conflicting changes are merged they will overide each other, which might lead to a broken game. We will dive into more advanced usecases in subsequent milestones.
est. 4 weeks
Just syncing changes and basic branches are not enough for a good collaboration experience. Users also need to be able to see what has changed on a branch and preview what will happen if they merge their branch. We want to think about these problem by solving the following scenario:
Students can split up into small teams, each working on a bigger project over a couple of weeks. Collaborating on a project requires more planning and coordination. First the students need to come up with a plan, breaking the project down into smaller tasks and sequencing them so they can be worked on in parallel. Students can create a branch for each task. After they’ve completed a task they can review their changes and preview what will happen if they merge them back into the main branch. If the main branch has changed in the meantime they might need to adapt their changes before they can merge them.
In this milestone we will focus on showing changes and merge previews for scene files and assets. Showing changes for code and handling merge conflicts in code will be part of the next milestone.
Sketch
Questions to explore:
est. 2-4 weeks
So far we’ve just merged code changes together and ignored all the problems this might lead to, like syntax errors or a broken game. In this milestone we want to focus on how to make collaboration on code actually good. We want to think about how to visualize code changes and handle conflicts to solve the following scenario:
Students can work on more complex projects that involve writing new code / modifying existing behavior. If two students modify the same line of code on separate branches this will be detected as a merge conflict. On a branch they can see a diff of their code changes and resolve conflicting lines of code.
Showing a code diff and allowing users to resolve merge conflicts requires that we extend the code editor of Godot. Unfortunately the built-in editor doesn’t have the required APIs for adding custom UI elements and annotations to build such an extension. It is also possible to use an external editor with Godot like VS Code which has a much richer extension API. The drawback is that using an external editor adds additional complexity and most Godot users (especially beginners) use the built-in editor.
We think that none the less we should build our prototype as a VSCode extension since it gives us more flexibility. This will allow us to think about how things should work rather than starting from the technically limited API and think what things are possible to build with that. The goal of this project is not to ship a production ready plugin; we want to figure out what the right interactions are for version control tools in Godot. A great outcome from builing a VSCode plugin would be if we find interactions that feel great and understand better what APIs Godot would need to implement so we could port them to the built-in editor.
Questions to explore:
There are many more topics and ideas we would like to explore but which are currently not in scope. If we finish the first 3 milestones faster than expected we might be able to pull in some of these themes:
Giving feedback
Branches are useful to work in parallel but they are also a useful to group a set of changes that users can share with others to get feedback on and discuss the changes.
Avoiding conflicts
Merge conflicts are complicated to resolve, so ideally we want to avoid them when possible. Games have the additional challenge that some asset types like 3D models or textures don’t have a way to easily combine changes from different versions. A popular mechanism in games to solve this is file locking so only one user can edit a file at a time.
Working with changes
Remix playground - students can mod a base game and split up their changes into meaningful change groups so aspects from different students can be combined to create new games
History
How do you visualize what’s happened on a game? eg, nice views of the change log, manually editing the changelog grouping; viewing history over multiple documents together. This is a deep area of exploration and it’s closely related to everything above, but we just don’t think we’ll have time to explore in depth.
Embedding Godot in Patchwork
In the long run we don’t want Godot to be just an isolated app. Building an integration for Godot should allow us to pull it into our web platform so we can use the existing Patchwok tools in Godot projects as well. Some example use cases this could enable:
Versioning design document + code together: - If both the Godot project and the design document lived in patchwork both could be versioned together. A new feature could make a change both to the design document and the project to implement it. Stats of entities from the desing document could be also referenced directly from the game instead of copying over these values manually.
Interactive tutorials: - Instructors could create a markdown document that walks students through how to mod a game in Godot in Patchwork. The document could embed a live running version of the game and parts of the godot editor like an individual property editor or an editable code snippet which they can use to mod the game from within the document. That way the user can gradually learn the individual concepts in the flow of the tutorial with out being overwhelmed
Editing the running game
We’ve lightly explored this in the game jam where one person could edit the game while the other person is playing it. How can you show the state of the running game in the editor?
A game that teaches student programing - one student programs the level to make it harder / easier while the other student is playing it