Sprint 5 is content, content, content! With enough framework in place to produce simple quests, my aim for Sprint 5 is get fully underway with content generation. So I'm not even putting together tickets for this one.

Faye @JavaScriptCoff1 has also offered to help with the writing, so hopefully we can put together a killer story.

GitHub storytelling

The ultimate aim of LGTM is to teach git and GitHub, but there are also plenty of good resources and tutorials that do this already, why is LGTM different? My feeling is that a lot of those existing tutorials are hard to relate to and very dry and theoretical. Fine if you know what you want from git and just need the technical details, but lacks the emotional investment in it for those who don't fully know what they want. And that makes it difficult to learn or stick with a course.

Therefore I feel LGTM should contain a fictional narrative to engage the audience while they do tasks on git. This also meshes with my desire as a hobbyist gamedev, to tell a story (the whole reason. So now I have to consider...what story do I tell?

There's a few technical limitations to consider: git and GitHub's comment system allows for a type of story-telling in the form of character dialogue: a character can speak to you, the player, or to each other over the comments system. But I don't want the player to have to imagine themselves "in-world", where similar interactive fiction games has the player imagine themselves as a character inside a world, exploring it, and directly having a conversation with other characters. I want the player to play as themselves, sitting in front of a computer, having a chat over GitHub about git-related tasks, that happen to have a backstory in the game's lore.

There's also unlikely to be a place to send too many images, or any non-dialogue narration, as that would run against how git/GitHubare used normally. But, what I can do is have "found journal" storytelling, where I can leave small amounts of text and world-building in the form of journals that someone might store in their git repo for the players to find.

Setting

When it comes to world setting, I think it may become too contrived to fit using git into the lore of a high-fantasy world, and may require too much investment from the player to explore this world. I want to keep the game setting and the tasks the player is involved in to one in which it is believable that git would be used, as fundamentally we must teach git, and teach git in a way that allows the player to relate what they're doing to similar real-world tasks.

This means the setting would be relatively contemporary, on Earth, and in a situation where computers and git could be used, though we have some leeway in what kind of information is on git - perhaps notes and to-do lists, though not the typical thing you'd find on git, isn't too much of a stretch of the imagination.

The Plot

My initial thoughts for driving the plot is some kind of peril (global? local?) it's tried and tested, and also the approach that Uplink took, a game that I draw a lot of inspiration from. The player starts out helping out these characters with various git tasks, and then gets pulled into a larger plot. Although I did write code for branching storyline, I think it's best if the player can't pick sides (makes it easier to write), and instead works together with the characters to prevent some global/local catastrophe.

I think perhaps the emphasis should be more on the characters, and less on the plot that's happening in the background, since the game being heavily dialogue-based, it'll be easier to write about the characters responding to the events of the plot rather than than writing about those events directly, so maybe it's easier for players to engage with the characters than the events.

Chapters

Since I currently only have the game mechanics for Type 1 quests, and not yet Type 2 or 3, I think what I could do is write a Chapter 1 of the story which is still self-contained enough, but open-ended for future chapters. That way I can aim to release Chapter 1 of LGTM sooner, rather than have to wait to implement and write out the whole thing.

Example

Here's an example of possibly the first quest. I've blanked out the player input. Here I'm testing what happens when you give the wrong value - the characters have a set of randomized responses for when you get answers wrong.

This sprint, the task will be to lay out the skeleton of this writing, something I'm not familiar with, so I won't be setting tasks for the sprint other than "figure out how to start writing". Though I may do a bit of code tidyup. Expect there to be fewer devlog updates during this sprint.