Workflow

This page describes the workflows we use in Thrive development. Separate workflows are given for the design / ideas and for concrete implementation phases for clarity.

Ideas / Game Design

Thrive's idea workflow is our usual system for how ideas go from creation to implementation. For anyone new to the project, this explains the roles of our different websites and how they fit together to form the development cycle of making the game.

Obviously different situations will need different workflows, but sticking to this system for as many tasks as possible should give the best results.

Forum

We create and discuss new ideas on the forum. This could be something dev related, like "We need to replace the nuclei with disco balls", or it could be something organization related, like "We need to update the wiki page on the Microbe Editor." Sometimes though, ideas are obvious (like bugfixes) in which case we can skip this step.

Casual discussion on the developer Discord usually happens first, but when some important points are reached or a conclusion needs to be drawn, the discussion should be moved to the forums. This is because Discord information disappears really quickly and isn't visible to anyone outside the Discord.

GitHub

When we complete the discussion for a game feature or wiki change or something on the forums, we then create an issue on GitHub to track that task we want done. We can assign it to a person, give it tags to categorize it, assign it to a release version, link the forum discussion that spawned the idea, etc. Using the above example, we'd create an issue called "Replace nuclei with disco balls" or "Update wiki page on Microbe Editor".

• Directly game related issues
• Launcher related issues
• Project management and other issues

There are yet other repositories for the ThriveDevCenter and website related issues.

All issues need to be put on our main planning board. Graphics related tasks additionally need to be put on the specific graphics tasks board.

Wiki

Once an issue is complete, we create or update a wiki page for it if necessary. Using the above examples, in the first case we'd update the page on Organelles (or whichever page it is) and change all references of nucleus to disco ball. In the second case we wouldn't need to add or update a wiki page because the issue literally was to update a wiki page.

Discord

Discord then fills in the gaps between all these steps by being a quick and easy communication platform for questions like "Hey can you give me access to our Twitter page?". And also serves as a place to casually discuss about new ideas before discussing them on the forums.

Discord can also be used to initially brainstorm an idea before posting on the forums or as a quick way to get feedback on changes.

Graphics Work

This workflow defines how graphics tasks (sounds also go through the same process) go from having been planned (see the idea workflow above) to being put in the game.

1. A graphics artist picks a task from the graphics tasks board or is suggested something on the developer Discord to work on.
2. The relevant issue is moved in the planning board to the in progress column and the issue is assigned to the relevant person on GitHub to show who is working on it. If you don't have enough permissions please ask on the issue for another team member to do this.
3. The artist does an initial draft of the new / changed assets while taking the Visual Style Guide into account, or the equivalent for their asset type.
4. The artist posts images / sounds of the WIP asset to the developer Discord for other developers to comment on. The asset is iterated until it is deemed good enough. Not all comments have to be resolved, some problems we can live with, and some people's eye for graphics may be prioritized.
5. The finished asset is exported in a form usable in Godot and uploaded to the relevant subfolder here (please read the README.txt file in the folder if you haven't already) for a programmer to take and put in the game. Note that if no programmer notices this, then someone should remind the programming team that there is a pending asset. A Github issue should be opened about putting the asset in the game if there isn't one already.
6. A raw version of the finished asset (usually the .blend file) needs to be uploaded to a subfolder here. This ensures that when inevitably we need changes to the asset, they will be easy as possible to make. We've spent a lot of duplicate effort on recreating assets from scratch...
7. The art issue can now be considered done / edited to just be about the programming side of putting the asset in the game,

If an asset doesn't get finished in a long time the person working on it should be first contacted a couple of times to ask if they are going to finish the work. If it still doesn't get finished in a reasonable amount of time the issue should be unassigned from the previous person and moved out of the in progress column to show that it is no longer actively being worked on.

The workflow is now complete from the artist's point of view and just requires a programmer to finish it. It's not really recommended for an artist to try to use git as it can be a very complex and frustrating experience. But we won't stop if you really want to learn.

Programming Work

This workflow is how programming tasks go from start to finish.

1. When any concrete change to the game is found to be required a new issue for it is created in the relevant repository (most likely the Thrive repo) with relevant tags and it is also added to the planning board.
2. Programmers looking for work can check the planning board to see what is important / scheduled to be worked on next, or alternatively the Thrive milestones. It's also possible to just browse the issues lists in our repositories to potentially find something interesting (maybe even the ThriveDevCenter repo if you want to give web development a go).
3. Once a task is started it should be put in the in progress column in the planning board and have the person working on it assigned to the issue. Note that if you are not a member of our GitHub organization yet, please ask on the issue and some team member will assign you. You qualify to be invited to the GitHub organization once you are an official member of the team and you have contributed one accepted pull request.
4. If an in-progress issue gets abandoned it should be moved to the stuck / help needed column and have the assigned person unmarked.
5. When work on an issue is finished / there's something to show and get feedback on a pull request is opened for it. Please see the info in the repo as it is much more comprehensive here on how PRs are done: CONTRIBUTING.md also if you are working from a fork (you haven't yet been added to the GitHub organization to create feature branches in the main repo) also see the important Fork Workflow page. All opened PRs should be also put on the planning board to be visible to everyone looking at what is being currently done.
6. A non-finished PR should be opened in a draft state. When a PR is ready to be looked at it should be marked as non-draft (ready for review), tagged "review" and the relevant issue it is about should be included in the next release milestone (along with the PR) if it is likely the PR is going to make it into the release before the feature freeze starts (unless the PR is an important small bug fix).
7. All automatic continuous integration (CI) checks and builds should pass before human review is done. This is to save a ton of human reviewer time as they can focus on more important things rather than notice things like bad indentation, missing null checks and incorrectly named variables.
8. A PR in reviewable state will be looked at (hopefully) by multiple programmers who can comment on bugs and style related problems with the PR. Also the testing or game design teams can be requested to have a look to make sure that the change doesn't break anything in the game or doesn't mess up the game balance. The design team is especially important to consult if the original issue didn't have a ton of details or if it is foreseeable that the PR changes game balance a lot. Not all comments have to be resolved, some things are a matter of taste but all major usability, crashing / very unexpected behaviour bugs, badly impacted game balance related problems need to be addressed.
9. After the PR has an approving review and the CI workflows pass, the PR can be squash merged (see our styleguide for why this is done and for situations where squash merging is not used). Testing or game design reviews are welcome, but not required for non-major changes. Programming leads may merge their PRs even without review from other members, as other programming team members are rarely available to review multiple PRs per week. But they should give regular chances (for example by waiting a day or two for non-time-critical PRs) for their work to be reviewed.
10. After merging the task is done. It should be still checked that all the issues the PR was supposed to close are actually closed and that they are in the latest milestone so that it can be seen what is going into the release.

For combined tasks that require both assets and programming separate issues can be created for the art and programming sides. The programming work shouldn't be started too early as it might get stuck for a long time waiting for the graphics assets as it can be pretty random when we have artists available.

For a purely graphics task, when the graphics are done a programmer should take the finished assets that were uploaded by the artist and make a PR from them (as using git is difficult).

There's a separate page about how to make BOTDs.