Let's talk about game design, how is this even going to work? How do I make a game where you play in git? I can write a user story that looks like this:

As a player, when playing LGTM, I would like to end up learning git and GitHub

This user story tells us what we're doing, but it's a bit open ended. There are lots of options about how we do this, so we should come up with a set of core principles that will help us make design decisions

Core Design Principles

Originally when brainstorming this game, I was thinking about all sorts of ideas like having an open-world 2D game where the player's character could walk around in, and chat to NPCs and collect missions. But as I thought about this, I realized I was straying further and further from the whole point: teaching git. Yeah, I can plan to make a 2D RPG in which the player happens to have to go and do some tasks using git at some point, but I think this vastly complicates the game, and significantly reduces the chances that I'm actually going to complete this. It would be cool. I just fear if I let the scope get out of control like that, this project will never be finished.

Ultimately, the game should be designed around teaching the player git and GitHub. For example, the list of things could look like this:

• Committing files
• Branching
• Merging
• Looking at commit history
• Resolving merge conflicts
• Pull requests

And furthermore, the game should teach the player to do these things in the same environment they might use later for their own projects or jobs, so typically: a text editor, a git client, and the GitHub website. We might write a high level user story like:

As a player, when playing LTGM, I want to be able to solve tasks presented to me using a text editor, a git client, and the GitHub website.

I think this establishes our core design principles of the game: it does not involve 2D maps for the player to walk around, or fake terminal to pretend to be a git session (as some other git games do), it only involves the tools a developer normally uses.

If I can stick to this, then I don't have to worry about all the complexities of graphical user interface design! This is good news as it's not my strong point.

With that core principle in mind, I think the major game components can be split into two parts:

1. The Narrative. Where tasks will be described and given to the player
2. The Task. The actual task the player has to complete, and in doing so, learn git and GitHub

Let's break down the requirements:

The Narrative

We need to be able to explain to the player what the task is, and what we need them to do. Our core principles suggest that we can't use anything other than git, GitHub, or a text editor to do this. I think it makes most sense to make use of one of the GitHub features that a programmer might get a task from in the real world: GitHub Issues, Projects, and Pull Requests

Issues

Each repository on GitHub has an Issues Page. It's up to companies and individual project maintainers to decide how to use their Issues page, but it's common to use it for reporting bugs, where a user or another programmer on the team spots a bug, and writes a description of the bug here, so that whoever is to fix it can see the details they need. It's also common for feature requests to be posted here.

We can therefore use it for describing to the player what their task is. It could even be written like a bug report, or feature request, to make it similar to how people use it in the real world.

Interestingly, Dev.to has an embed for issues:

Projects

GitHub also has a kanban-style Projects page. Again, it's up to project maintainers how they want to use this page, but unlike Issues, management of this Projects page is usually done by the project maintainers; there's usually not an expectation for people outside the project to go in and mess around with the project boards.

However, my concern for using GitHub projects is that it goes too far into project management flows, which aren't strictly a git issue. While plenty of software development projects use a kanban, is this really something we should focus on teaching? I feel using Projects, even though it does use GitHub, is somewhat of a tangential feature.

On the other hand, using a kanban does give users a more game-like view of tasks, for example, we can use it to display the status of various tasks in the event that we allow the player to have multiple open tasks at once.

Pull Requests

Pull Requests are probably the most common thing a programmer has to deal with outside day-to-day committing and pushing. It's usually when a colleague wants to merge some code, they will raise a Pull Request to ask another programmer to review there code before making the merge. I think this is another good option.

My concern for using Pull Requests is that while it's good for tasks where a merge is needed, not every task may involve it. So perhaps we shouldn't use this for every task, and only the ones that require a merge first.

Conclusion

In conclusion, it seems that GitHub Issues are the strongest contender for how to provide players with their tasks. It's already inherently a list of tasks, and each task can be marked as Done (Closed), so it already strongly resembles a quest list, something I hope players will intuitively understand.

Each Issues ticket can contain a lot of text that tells the user what is needed of them, and since Issues tickets can hold a comments thread, we're not limited to drily explain what is needed, and instead can present tasks in a more interesting way: in dialogue form. We can have two NPCs chatting back and forth, and let the player read their conversation as they would in a regular video game. This does not conflict with our design principles, and in fact matches quite well, as a programmer might really have to read through discussions happening in Issues tickets as part of their work.

The other options remain options that we can use, but would not be the primary way of delivering the narrative to the player.

In the next post, I'll explore the design ideas around The Task