Programming: Difference between revisions
Hhyyrylainen (talk | contribs) (→Resources: link to the devbuilds page) |
Hhyyrylainen (talk | contribs) (→Resources: fix project link) |
||
Line 19: | Line 19: | ||
* [[How_to_Help#Programming_2|Learning programming links on the wiki]] | * [[How_to_Help#Programming_2|Learning programming links on the wiki]] | ||
* [[Workflow|The Thrive Workflow]] for a really important look at how work is done | * [[Workflow|The Thrive Workflow]] for a really important look at how work is done | ||
* [https://github.com/orgs/Revolutionary-Games/projects/ | * [https://github.com/orgs/Revolutionary-Games/projects/8 Short term planning board] | ||
* [[Release_Roadmap|Longer term feature backlog]] | * [[Release_Roadmap|Longer term feature backlog]] | ||
* [https://github.com/Revolutionary-Games/Thrive Thrive on Github] | * [https://github.com/Revolutionary-Games/Thrive Thrive on Github] |
Latest revision as of 07:15, 7 August 2024
The Programming Team is the backbone of Thrive, and actively works to expand, maintain, and improve the game. Programming is vital for Thrive's development, as without programmers Thrive would merely be a neat concept to this day. If you are interested in becoming a part of this team, it is imperative that you are able to compile thrive. The most important thing is to read the setup instructions.
Activities
There are various ways programmers help develop Thrive.
- Analyze bug reports in order to identify issues.
- Fix bugs and errors in software.
- Introduce new features and mechanics to the game.
- Communicate with players to recognize potential issues.
- Coordinate with other programmers within one project.
Resources
This section lists some of the most important resources for programmers:
- Learning programming links on the wiki
- The Thrive Workflow for a really important look at how work is done
- Short term planning board
- Longer term feature backlog
- Thrive on Github
- Thrive compiling setup instructions
- Other docs in the source code
- Launcher on Github
- Testing Checklist for a list of things related to functionality that you should test when making pull requests.
- How to make DevBuilds for a workflow related to BOTDs
- Styleguide
General Requirements
Programmers must be able to understand, read, write, and modify code written in the C# coding language. They must also be familiar with how to utilize GitHub in order to properly import changes to the game.
- Ability to understand and write in C#, and to make effective changes to the game.
- Ability to coordinate with other programmers as well as understand and modify code written by others.
- Knowledge of how to use GitHub.
See the category for more pages.
New Volunteer Guidelines
As a new volunteer it is advisable to start off my working on easy issues or issues that are tagged good first issues. Once you gain more familiarity with the codebase and working on Thrive, you can then start working on the harder issues. Also remember that if you get stuck you should ask for help. And please do not take pull request reviews personally; everyone makes mistakes when programming. With reviews our goal is to keep the quality of the Thrive code up because we will be working on the game for a really long time.
Please make sure you are familiar with our workflow.
The following sections cover some common areas of development that should be helpful when getting started.
Active Development
Most of the time there's a milestone on Github which has some suggested bugs and new features that would be nice to get done first. You can use them as a guide on what to work on next, or you can pick something from the issue backlog or roadmap.
When starting working on an issue please assign it to yourself and move it to the in progress column on the planning board. If you are not a team member yet, you can ask on the Github issue to be assigned the issue.
If you can no longer work on an issue or cannot make progress for a long time (more than a month) you should unassign the issue from yourself and move the planning board card to the stuck column.
General Advice
- Don't be afraid to argue against change requests in a PR if you think your way is actually better and not just a matter of opinion. But always follow the styleguide.
- When there are conflicting opinions on how some feature should work, try to get as many people in the discussion as possible to reach a good conclusion, or refer to the more experienced programmers. In the worst case a PR may need discussions on the development forums with other teams also involved to come to a conclusion.
- New features or major changes completely out of the blue will probably have pretty painful reviews. You should start off doing things that have already open issues about them. This skips the step of you having to justify why your changes are even necessary.