bpar476 / gitgood Goto Github PK

All of the "Trigger" scripts and interactions need to be tested as its currently quite delicate. Adding to the test suite will add confidence that new changes don't break existing implementations.

The current README does not present much to developers. We need full lists of development environment requirements, running and building instructions, testing instructions contribution and issue reporting guidelines etc.

The current tutorial is too long and overwhelming for players. They don't get much time to practice and reflect on each new mechanic as they learn it. If we stretch out the tutorial so they have more time with each mechanic then perhaps it would be easier to learn. Additionally, this means we can break up the dialogue and try and there will be more time to relate this to actual version control

Remote repositories are important concepts in git/distributed version control. A good analogy for a remote repository is a universe "back up" that is stored in some sort of special container. These containers can exist anywhere but most known containers are held in the Time Guardians headquarters: The Hub. It's not clear what kind of mechanics this concept would create but at the very least they should be there at a conceptual level in the game.

There needs to be some way for the player to visualise the commit tree. Ideally, we can use some sort of graph drawing tool to show the true structure.

"As a player, I want to be able to see the commit structure of this level, so that I can understand my history and orient myself"

This might be too large for one PR so try to implement it incrementally.

Acceptance Criteria:

• Can visualise the commit tree with a graph
• Can identify the current commit
• The interface overlays the level with some transparency
• Hovering over a commit renders a preview of it in the level
• There is a list of branches
• Commit chains of branches are identifiable
• You can checkout new branches from the branch list
• You can checkout individual commits

Here is a graphing library for Unity. However, perhaps there are alternatives (or maybe even a home-made library) that would be better.

Currently, the application can't build when there is an assembly definition for the test configuration. It messes with the scopes of all sorts of things and prevents the build from succeeding. I'm sure there is some way to manage this so that we can build without having to delete all the tests and assembly definitions (then undeleting them with git).

Currently, versionable objects just get a green outline when they are "selected". This isn't easy to notice if you aren't looking for it. Additionally, it doesn't indicate to the player what it means at all. There's got to be a better way to do this.

Adding keyboard shortcuts to common actions that are currently only available in the UI would make it easier for users to move quickly through the game once they are confident with the mechanics.

Level 1 is a level design that we made as a place for the player to practice skills from the tutorial. See a mock-up here Level 1. Also see the candidate story here Story Design (WIP)

The current dialogues are a bit barebones. Their appearance could be improved so that there is a stronger theme. Lets move away from mono grey and find something that is a bit more engaging but still easy on the eyes.

At the moment a small text box appears when an automatic commit occurs. This is easily missed. The goal of the automatic commit is to enforce certain play paths so that the player doesn't lock themselves out of progression. This could be improved by changing the way automatic commits are communicated or some other novel solution for ensuring players can't make cause a level to be unbeatable.

Example scenario: Player creates a commit in room 1, moves through the door to room 2; door between rooms closes indefinitely. Player resets to the previous commit. Room 2 is now unaccessible.

The VersionManager script is very big and handles a lot of stuff. For maintainability purposes, it would probably be better to break it up into multiple managers that are composed by one main manager. e.g. branch manager, visualisation manager. Additionally, while we are in there we should identify unnecessary method overloads and remove them as they make the control flow difficult to follow.

There is a framework for BinaryVersionable already in the codebase and I believe the doors etc. implement it. However, the player orientation should also be version controlled like this. This is better because the commit preview will match the state that will actually be set and it also may be important if the direction the player is facing becomes part of a puzzle.

A font that looks like something you'd see on a command line would help to build the theme of the game and engage players. Players should really feel like time-traveling hackers.