-
-
Notifications
You must be signed in to change notification settings - Fork 67
How to be Developer (For CK3)
If you're a new developer, read step by step to the Guidelines section. We explain how to set the mod and how we work on GitHub. The Guidelines have information about working in different fields of the mod and can be read along the way (during working).
- Be active in the dev chats so we can give feedback and help you!
- Pick Tasks so we're always busy and progressing!
- Create Tasks for yourself and others. If you have a vision of the mod, it's very welcome!
- Pick Task or Create Task for yourself
- Open Branch
- Work-work
- Open Pull Request
- Request review from
CK3 Testers
- Get approval
- Merge the PR
- Repeat
First, to understand how GitHub works, I would recommend reading This.
GitHub Desktop is the easiest program to do it. It has a nice user-friendly interface but lacks some pro-features like conflicting resolving. The desktop is a good choice if you add/fix texts or do small changes. Just don't forget to click Pull origin and Push origin when you can. How to install it and download the mod is explained Here (if you have already done it, ignore).
Read These Basics to understand how to open and switch branches, commit. If you work on localization only this will be enough.
If you're familiar with another git client, we don't mind if you use yours instead.
We sort all our tasks as the Issues. You can use labels to find and sort tasks in your fields. Here you can read the Label List.
Images
If you're a new developer or looking for an easy task, we encourage you to sort issues with the good first issue
label. Here's the Alternative Link.
If you're a developer, you're free to open new issues you want to do in the future. It's a very useful tool!
Images
If something isn't clear or you want to speak about the issue, you can use the comment section on each issue.
Images
Finally, once you feel you want to work on this issue, assign yourself by clicking the Assigners and finding you in the list.
Images
We separate features from each other on things called Branches. So once you take some task, you can open a new branch for it or switch to an existing one.
We now have an enforced Naming Scheme
Once you feel like your branch is done, find it in the Branch List, open a Pull Request, write the changelog (it should be short and detailed enough), request reviews from the CK3 Testers
, assign yourself and relevant labels, and create the PR.
Images
Ping CK3 Tester in the ck3-testing
channel of our Discord to notify the testers we have a new PR to test.
As of 17/09/2024 we now have an enforced naming scheme for all branches!
It is as follows: feat/<type>/<name>
for features or fix/<type>/<name>
for fixes. It is case insensitive.
Type is one of the following:
mixed
for branches containing more than one type
code
for code (both PDX Script and Shaders unrelated to the other categories)
2D
for 2D art
3D
for 3D art
map
for map
char
for character design
l10n
(short for localization) for translation
magic
for magic branches
A branch where you have added a bunch of Stormwind human character DNAs might therefor be named feat/char/new-stormwind-dna
Before starting work, I would recommend you to read the guidelines for your field. It has the information you will need.
- Github and General Guidelines, guidelines explaining how to search files and commit to GitHub.
- Coder Guidelines, your main guidelines.
- Model Guidelines, a bunch of sources on how to make the models for Paradox games. If something isn't clear, feel free to ask the team!
- 2D Artist Guidelines, a collection of sources, tips, and styles for 2D Artists.
- Map Guidelines, a compilation of guides and tools for the map modding.
- How To Assign DNAs (Portraits) To Characters, a full guide about creating DNAs for our characters.
- Ethnicity Guidelines, a full guide about creating new ethnicity used to define how our races look.
- Localization Guidelines, guidelines explaining how the localization works and how we work with it.
-
How to be Tester, sometimes we ask you to review (proofread) localization. In such cases, you act as a tester who review only
.yml
files.
If you're a developer who works on big features, you better know all GitHub's tools. I would recommend reading these guides: