Welcome to the first talk of the day of the gaming and VR at their room, beyond
git, a collaborative version control for Gadot with Paul Zonetta.
Yeah, thanks for having me.
Hi, my name is Paul Zonettaq, and today I want to talk about version control beyond
git, and I want to share some of the work we've been doing around better collaboration
tools for Gadot Editor.
I'm part of a research lab called Ingrid Switch, and the work I'm presenting here
is a has been a collaboration together with my colleagues, Lilith Duncan, Nikita
Hashtag Kuj and Shafri Lilith.
This project was commissioned by the enters foundation.
They are a non-profit, with a goal to teach students useful skills through game development.
And they specifically picked the Gadot Ancient because they didn't just want to teach
a toy version of game development, they wanted students to learn real tools that actual
professionals are using to build games.
Continuing on the goal of making real games, they started a new project called threat
there.
And the idea behind threat there is to build this RPG style game, and as the students go
through the course, they can form teams and make their own level and contribute that
back to the main game.
So the idea is that you have to like rich world that evolves as students contribute new
levels to this game.
And they came to us with this question of how can we make it easier for students to collaborate
on games.
So to figure this out, let's see what this looks like right now.
So imagine your student you are excited about making your first game, but first of all,
you need to learn Git.
And what this looks like, you need to go first of all to the terminal.
And that's probably the first time that they are doing this, and initially the terminal
can be very intimidating.
You have to speak blank, screen, no obvious buttons, and now you need to learn all these
cryptic commands.
But they have some tutorial, they push through, they start by cloning the repo, and now
they're in Gido, and they can start working on the game.
And what's interesting about how enters teachers' game development is that they are starting
with already working game.
So here you have an example of platform approach act, and the students can start by doing
simple edits, like moving platforms around.
So they don't need to learn a lot of stuff upfront, they immediately can do interesting
things.
So the student might start by doing something simple, like making this level a little bit
more interesting by moving the platforms around.
But now they want to share it with their friends.
So what they need to do is they need to go back to the terminal, they need to enter a bunch
more commands, like commit all their changes, and they're finally done, and now they run
get push, and they get this error.
Somebody else has modified the level, and now they basically screw it, like they can't
really, it's really the kind of stack.
And in practice what endless what they've learned is that teaching students to like fix
merge conflicts is just too complicated.
So in the end, what they teach students is to avoid merge conflicts at all costs, basically
they should talk to each other only once students should touch a single file at a time.
So they still need to go through all this hassle of Git, but in the end they don't really
get many benefits out of it.
And games, in particular, are challenging with Git, because you're not just versioning code,
you have other things like scene files, for example, which are these like highly
visual and structured artifacts, but Git can only version text, so you end up representing
these as text files.
So when you're looking at a diff, you're not seeing what changes in the scene, you're
looking at a text file, and you have to pass back, like how does this relate to changes
in the scene.
And what's even worse, if you get a merge conflict, this means actually you're seeing
files broken now.
So you need to go into a text editor, fix all the merge conflicts, and only once
you've done that you can load it in the GitHub.
So what are, like, outside of games, how are students collaborating today?
One tool that students are probably very familiar with is something like Google Docs, which
is much more approachable.
You have real-time collaboration, it's really easy to share document with other people,
changes are automatically saved, so it would be nice to have some of these features
for game development as well.
So our goal is to build a new collaborative environment that builds on the strength of
both of these tools.
Right now, endless are using Git, because they need a collaboration tool that works
on code.
But this means they're also now locked into this very formal way of working with, like,
explicit commits, with branches, and merging changes.
Sometimes it would be nice to work more in a Google Doc style, especially in the beginning
when students are making simple changes, like moving platforms around or adding points
of what would be really nice if they could just jam together on a level, and like changes
are a think and real-time.
But you wouldn't always want to be in Google Docs mode.
Like one thing that's really nice about Git are branches, like you can just break your
own branch, work in private on some changes or on a new feature, and once you're happy
with your changes, you can review them and merge them back into Git.
But actually in practice, students are not really experiencing this power of Git.
And the reason for that is that beyond code, we also need great support for scene files.
Like merging scenes should be easy, you should be able to see changes in the scene instead
of a text file.
And of course also, we should support other assets, like images in audio and so on.
So here is what we've built in our tool.
So here you can see the Gado editor.
On the left here we have the scene hierarchy, there are some coins, some platforms, and various
other game objects.
I have here this main panel where I can inspect elements and move them around.
And what our plugin adds is this version control tab here.
So you can see right now I'm checked out on the main branch, and I can also see a history
of recent edits.
And as a student, I might start by creating my own branch.
And now you can see the history is empty because I haven't made any changes on this branch.
And it's really nice that I was able to do all these things like viewing what branch
I'm on and checking out in the new branch, just directly in the editor, I didn't have
to go to any external tool.
So maybe next, I want to move around these platforms.
And once I save these changes, you can see that every time I save it, all the magic
it creates a new snapshot of the game.
And if I open up this panel if you below, I can see a list of all the changes that I made
in the game.
And this is using the native UI of Gedou to show me the before and after value.
And if I hover over these change nodes, it also highlights this in the scene where this
changed happened.
So this is really important that I can both see the context where it changed happened,
and also the details of what's specifically changed.
This is especially useful if I'm making non-wishable changes.
For example, if I go into the player here and if I go into the player here and I
crank up the speed and save it, now I can see here that the speed changed from default
value to 730.
And this is otherwise a change that's really easy to miss if you're just looking at the
scene file.
So now that I'm happy with my changes, I can just click here on merge.
And this brings me into a merge preview where I can see how these changes will look once
I'm much and back into main.
So I can click here on merge.
And now I'm back into main.
And you can also see in the history I have here this entry for the merge, and I can see
what changes I've made.
So this is kind of the happy path, but what happens if another student and parallel
why we were marching in these changes, they made some changes as well.
They added some coins to the scene.
What happens now if they want to merge them?
So we click merge here as well.
And now we can see the level looks a little bit messed up.
There are some all-app between the coins and the platforms.
But what's nice is that at least I can load the scene and look at it.
So our principle is that it's better to have level that might not work as intended,
but at least I can see how it works and can make changes to it.
So here in a merge preview I can also make changes.
So I can fix this and align the coins with the platforms.
And once I'm happy with these changes I can save and merge them into main.
And now I have both these changes combined, the move platforms and the added coins.
So this is how you can work together on branches, but we also support life thinking.
So here you can see in the background I have a second version of the added or running.
And whenever I make a change here and save it you can see it automatically sinks to the other side.
And this also works the other way around.
This obviously is not quite like Google Doc style live collaboration.
The limitation here is mostly the Gedou editor.
It wasn't like designed with collaboration in mind.
So like the only point where we can like think is when all the files are saved.
But we already found this to be quite useful if you're pairing, especially if you're together
like on a Zoom call for example, that you can like take turns and easily like make progress together on a game.
So we started this exploration with the question of how can we make it easier for students to collaborate on games.
But beyond that specific use case we have a broader version, we want to make it easier for every person to collaborate on every document.
And we call this version universal version control.
We've already seen with that games are actually they have quite broad requirements for collaboration tools.
And that's not just the challenge for students.
This is also something that people in the game industry is tricky for them.
You have different specialists like artists and developers both with their own set of tools.
But in the end they need to collaborate together on the same project.
And this is not unique to games.
For example, if you think about researchers writing scientific papers, a scientific paper is not just a text document.
It might contain graphs and charts that are generated by some script that's based on some data.
So it would be nice to version all these things together in a single environment.
And even if you're just a single person working in a single medium,
version control tools could be really powerful if they were more flexible.
You could think of a musician working on a new track.
Like initially they want to work very loosely.
They have some ideas, they want to sketch something out.
But like as they are making progress and like holding in on a final version it would be really nice if they could
like easily compare different versions like what has changed between them to figure out what they actually want.
So what we want is universal version control that works for every person, not just programmers.
Every document, not just code and every workflow, not just from a software development.
And we already explored some of these use case in an online browser based collaboration platform that we call patchwork.
And patchwork we have things like every document you can create a branch of by default.
We have application specific diff.
Like here you can see a diff for a spreadsheet or a drawing.
We have history that's automatically generated, but you can also manually annotate it.
And we've explored provenance for generated artifacts in scientific papers.
So to build these new kind of collaboration tools we needed some new infrastructure.
And that's why we've built auto merge, which is an open source library to store and think version documents.
In some sense, auto merge is very similar to Git.
By default it works locally without a server, but you can optionally think your changes.
Either peer to peer or you can think it through a sample server.
But there are some differences to Git.
So first of all, it works on structured and binary data, not just text.
This is really important if you want to version any kind of application.
So like in auto merge you can represent most applications as a document.
And the second thing is that auto merge has much more granular commits.
Because we also want to model things like Google Doc or like real-time collaboration.
So in this case each keystroke is an individual commit.
And then later you can still introduce more formable workflows where you can like group these together
and like annotate them into like meaningful units if you want to, but you don't have to.
And another thing that's different is that changes merge by default.
So for example, if you have a conflict like two people concurrently change the same field to a different value.
Auto merge by default takes one of these versions.
But this doesn't mean you can still do, you can still work with merge conflicts.
We don't throw this information away.
You can ask for like what are conflicts in this document.
And then the application can decide to like surface this to the user to like manually let and take
between like version A and B in.
Yeah, so this has just been like a brief overview of auto merge.
All most of the stuff I've been talking about in this talk is already open source.
If you want you can check out our plugin on GitHub.
It's still under heavy development right now think of it more as alpha software.
Like a few free to experiment it with and try to use it in your game.
But I wouldn't recommend using it for anything critical yet.
And if you want to learn more about auto merge, there is an upcoming talk by my colleagues,
which is going more into technical details.
And finally, I want to also thank Antlers who are funded all this work on the GitHub plugin.
You should also check out their projects if you want to learn more about how they are teaching game development to kids.
That's it for me now.
Let me know if you have any questions.
All right, we have some time for questions.
And you're all right.
Hello, thank you for the talk.
So you said there are maybe sync conflicts because you have to save the scene before change our applied.
Maybe maybe you're doing it already, can you force auto saving like every five seconds to have
more life thing?
Yeah, the problem is that whenever you save it kind of like blocks the whole editor.
So that's like why it's not a great like we want to give the user the control like when kind of like this happens.
All right, yeah, my question.
What do you do with conflicts? It can't be merged automatically like two objects that are by boots moved around?
Yeah, so like the way we represent scene files is that we store it as fracture data.
So basically like each node has an idea and then references each children.
So like we can always like merge things together, but like of course this doesn't necessarily mean that this is like a meaningful
scene like basically we can combine like all the changes of like nodes that were added and like properties that were changed.
But like if like semantically it still might these like changes might be like income in compatible.
So like there's not that much we can do about it.
Yeah, but I mean like if you change the same property of the same notes.
I hear right, so like in that case we automatically pick like one version and like one thing that we do not doing right now is like exposing this conflict.
Like under the hood be like the Texas conflict and like what we want to work on next is to give the user like a way that they can see like
Here is like value A or value B like choose between one of them.
All right, by the way, if the next presentation is in the room, please kind of come over.
Good question about the conflicts as well.
So if you have this conflict that you automatically resolve, have you thought about any characteristics to maybe
detect if you can do something smarter like for example peak value that makes more sense.
Yeah, I like it to succeed something like that yeah, that's a great way that's a great question.
So right now, we're still working on like making this plug and more like stable so we can like use it in class so we can use it more in class rooms.
We haven't like deeply explored yet like what happens if you like actually like use this in more heavy context, but yeah
Like thinking about like what are heuristics to like resolve much conflicts that's definitely like a great question that we want to explore.
All right, we have some time for my questions.
Is good though the only
current showcase there is of auto merge or is there also other ones like from music or like it is correct?
Yeah, so like what we have we don't have anything yet from music, which I think would be cool to do.
Like patchwork is like the other project we've been doing so in patchwork we have like version markdown document.
We have done like versioning a lot of tech documents and also like we you can easily build like
smaller tools like we also have like a drawing editor yeah.
All right, one last question.
Can you talk a little bit about the results in the classroom was it well accepted?
Yeah, so basically get us like super like you've seen how like difficult experiences with kids so like just having something where you can like
automatically merge is already huge. We haven't right now we are still like in development mode.
So like in a couple of months we want to bring this like back into the classrooms.
But so far what we've heard from teachers is that they are like we want to have this tool right now.
Like we don't even care about like having better UX we just like if you have if just like what you have right now
would be working like more stable. We would use this immediately. So that's why we are right now focusing on like
better engineering and like making this work more solidly.
All right and we have unfortunately out of time. Thank you.