This is interesting, though I find it hard to imagine in action. Is this meant as a general tutorial or visualization of any git repo in a Minecraft-y world, or is it also tracking the state and changes to such a world? It seems like the former, though the latter might be cool to see, and closer to the “track changes” kind of connection with players. I worry it’ll be something like the Library in the game Hack ‘n’ Slash, which contains the game’s own source code, a neat idea but awkward in execution. (Or the branching, time-travelling save state system, similarly.)
Self-indulgent aside, it reminded me of my favorite bit to quote from Johan Georg Raeder’s 1984 thesis Programming in Pictures (pp79-80):
What real-world metaphors can fit programming? To get a feeling for how immense our initial search space is, let us amuse ourselves with a few possibilities. Is a program like a road with intersections and forks where we have to make decisions depending on our current errand, and with roadside inns where we can spend computation time or, if we are careless, completely overflow our stack? Or shall we abolish the ‘meta-view’ and, instead of seeing the program from the sky, put the programmer inside the program by presenting a view of a tunnel he/she can drive through? At each intersection one might have to throw dice or make guesses to introduce some of the challenge, fantasy and curiosity found in computer games. Perhaps we should rather present programs as physical, three-dimensional objects that we can turn around and view from different angles and in different light so as to reveal the various facets of their structure.
A Git tutorial mode where an in-game character walks the player through about 15 levels, and each level focuses on one or more Git concepts/commands. It basically starts from scratch in an empty repo and builds up the respective concepts as you initialize the repo, create files, stage and commit them. Then you build on that to eventually create multiple branches, perform merges, rebases, resets, reverts, and all the common Git operations. The game responds in real time to operations that change the content in the Git repo, but it’s in a linear, happy-path in this mode since it’s meant to be done in a specific way according to the tutorial.
The second mode is more freeform and more likely suited for folks who already have some level of Git experience. It renders your current repo in the game world, so folks who somewhat know what they are doing can get a much more concrete idea of how Git works. You can do a whole bunch of things from within the game world, like write/edit code, simulate and run any Git command, explain difficult code with AI, and as mentioned before all operations are immediately reflected in the world.
I feel that one of the best concepts that Devlands communicates is how branches (and all refs) are just pointers to commits. I find that people really struggle to get that, since conceptually a branch is so clearly evocative of a series of commits, not just a pointer to the first one.
For example, if I explain Git to someone as: “Git is a version control system that lets developers track their code changes and collaborate with others.” I get a bored and glazed look every time.
…Okay? Sometimes, learning is boring. Some new things are slog. Cybersecurity training at work sucks but we all do it and we mostly learn from it. Using metaphors about M$ Word and placing blocks in Minecraft won’t ever substitute for using Git.
Sure, sometimes it is. Cybersecurity training is a great example man I hate that stuff and click through as fast as possible without absorbing much. Maybe you enjoy that more than I do.
As for Git specifically, I never said anything about Git itself being boring - my point was more about the terminology that we use to communicate (esp technical terms that seem comfortable to us) and how it translates into the audience’s ability to digest that info.
I don’t think it’s too controversial to say however that Git learning is typically confusing for most new users (not necessarily boring) - there are just a lot of abstract concepts. I think this is also supported by the many experienced devs in this parallel thread on hackernews who have used the same 3 commands for 10 years, although I’m sure they would argue that they just never wanted to learn more than the bare minimum they needed for their workflows, which to me is a little sad.
Anyway, each person is free to use or not use whatever tools/methods they choose, so my goal was just to offer a gamified alternative for whoever finds value in it.
This is interesting, though I find it hard to imagine in action. Is this meant as a general tutorial or visualization of any git repo in a Minecraft-y world, or is it also tracking the state and changes to such a world? It seems like the former, though the latter might be cool to see, and closer to the “track changes” kind of connection with players. I worry it’ll be something like the Library in the game Hack ‘n’ Slash, which contains the game’s own source code, a neat idea but awkward in execution. (Or the branching, time-travelling save state system, similarly.)
Self-indulgent aside, it reminded me of my favorite bit to quote from Johan Georg Raeder’s 1984 thesis Programming in Pictures (pp79-80):
Thanks for the thoughtful comment!
So it currently runs in 2 modes:
A Git tutorial mode where an in-game character walks the player through about 15 levels, and each level focuses on one or more Git concepts/commands. It basically starts from scratch in an empty repo and builds up the respective concepts as you initialize the repo, create files, stage and commit them. Then you build on that to eventually create multiple branches, perform merges, rebases, resets, reverts, and all the common Git operations. The game responds in real time to operations that change the content in the Git repo, but it’s in a linear, happy-path in this mode since it’s meant to be done in a specific way according to the tutorial.
The second mode is more freeform and more likely suited for folks who already have some level of Git experience. It renders your current repo in the game world, so folks who somewhat know what they are doing can get a much more concrete idea of how Git works. You can do a whole bunch of things from within the game world, like write/edit code, simulate and run any Git command, explain difficult code with AI, and as mentioned before all operations are immediately reflected in the world.
I feel that one of the best concepts that Devlands communicates is how branches (and all refs) are just pointers to commits. I find that people really struggle to get that, since conceptually a branch is so clearly evocative of a series of commits, not just a pointer to the first one.
…Okay? Sometimes, learning is boring. Some new things are slog. Cybersecurity training at work sucks but we all do it and we mostly learn from it. Using metaphors about M$ Word and placing blocks in Minecraft won’t ever substitute for using Git.
why can’t learning be fun?
Sure, sometimes it is. Cybersecurity training is a great example man I hate that stuff and click through as fast as possible without absorbing much. Maybe you enjoy that more than I do.
As for Git specifically, I never said anything about Git itself being boring - my point was more about the terminology that we use to communicate (esp technical terms that seem comfortable to us) and how it translates into the audience’s ability to digest that info.
I don’t think it’s too controversial to say however that Git learning is typically confusing for most new users (not necessarily boring) - there are just a lot of abstract concepts. I think this is also supported by the many experienced devs in this parallel thread on hackernews who have used the same 3 commands for 10 years, although I’m sure they would argue that they just never wanted to learn more than the bare minimum they needed for their workflows, which to me is a little sad.
Anyway, each person is free to use or not use whatever tools/methods they choose, so my goal was just to offer a gamified alternative for whoever finds value in it.