diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 030b439f..63359976 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -3,24 +3,30 @@
So you want to contribute to Colobot: Gold Edition? That's awesome! Before you start, read this page, it contains a lot of useful information on how to do so.
## General information
+
Before you start, read more about technical details of the project. They can be found in:
* [Developer README](README-dev.md)
-* [Doxygen documentation](http://compiled.colobot.info/job/colobot/job/colobot/job/dev/Doxygen/)
-* [Game Design Document](http://compiled.colobot.info/job/colobot/job/colobot-misc/job/master/lastSuccessfulBuild/artifact/Colobot_Gold_Edition-Game_Design_Document.pdf)
+* [Doxygen documentation (doc)](https://github.com/colobot/colobot/actions)
+* [Working with translations](https://github.com/colobot/colobot/wiki/Working-with-translations)
+* [Working with models](https://github.com/colobot/colobot/wiki/Working-with-Colobot:-Gold-Edition-models)
+* [Common issues](https://github.com/colobot/colobot/wiki/Common-Issues)
## Before you start coding
+
* If you want to fix a bug, please first check the related [issue on GitHub's bug tracker](https://github.com/colobot/colobot/issues). If there isn't one, make it.
-* If you want to add a new feature or make any change to gameplay, please first discuss it either [on the forums](http://colobot.info/forum) or in the related issue on GitHub. When your issue gets *accepted* label, that means that your suggestion got accepted and is waiting for somebody to work on it. Always wait for your suggestion to be accepted before you start writing any code.
+* If you want to add a new feature or make any change to gameplay, please first discuss it either [on Discord](https://discord.gg/56Fm9kb) or in the related issue on GitHub. When your issue gets *accepted* label, that means that your suggestion got accepted and is waiting for somebody to work on it. Always wait for your suggestion to be accepted before you start writing any code.
* Before you start, check *"Assignee"* field in the issue and read the comments to see if nobody else is working on the same issue. If somebody is assigned to it, but there was no activity for a long time, you can take it over. Also, please post a comment on the issue that you want to help us, so other people don't waste time working at that issue in the same time.
## Coding style
+
When writing code, please adhere to the following rules:
* Indent with spaces, 1 indentation level = 4 spaces. Unix line endings. And don't leave whitespace at the end of lines. Thank you.
* Put braces in new lines.
Like that:
+
```c++
if (a == b)
{
@@ -31,7 +37,9 @@ Like that:
// ...
}
```
+
NOT like that:
+
```c++
if (a == b) {
// ...
@@ -39,11 +47,14 @@ NOT like that:
// ...
}
```
+
You may omit braces if there is only one line in block:
+
```c++
if (a == b)
doStuff();
```
+
* Name functions beginning with upper case, e.g. `FooBar()`
* Name classes beginning with C, e.g. `class CSomeClass`
* Name accessors like so: `SetValue()` and `GetValue()`
@@ -70,6 +81,7 @@ We also have an automated tool for checking the code style. See [colobot-lint re
If your pull request breaks the coding style, you will have to fix it before it gets merged.
## Commiting rules
+
Please adhere to the following rules:
* Commits should have meaningful descriptions.
* Commits should not break the build nor tests.
@@ -77,9 +89,11 @@ Please adhere to the following rules:
* Merges to *master* branch must be discussed beforehand and should include fully finished features if possible.
## Submitting pull requests
+
After you finish working on your issue and want your code to be merged into the main repository, you should submit a **pull request**. Go to [this page](https://github.com/colobot/colobot/pulls) and select "New pull request". All pull requests should ALWAYS be submitted to the *dev* branch. After your PR gets reviewed by our development team, it will be merged to *dev* branch, and on the next release - to the *master* branch.
If you need more help, see [GitHub's help page on Pull Requests](https://help.github.com/articles/using-pull-requests/).
## Need help?
-Ask on our official Freenode channel (#colobot @ irc.freenode.net) or on our [forums](http://colobot.info/forum/). We're here to help :)
+
+Ask on our [Discord server](https://discord.gg/56Fm9kb) or [GitHub Discussions](https://github.com/colobot/colobot/discussions). We're here to help :)
diff --git a/README-dev.md b/README-dev.md
index cb5f1fa1..deb3d8a6 100644
--- a/README-dev.md
+++ b/README-dev.md
@@ -1,20 +1,25 @@
# README for developers
+
This file contains a ton of information useful for development of the game
## Repository setup
+
All the repositories related to Colobot can be found on our GitHub organization page: https://github.com/colobot
### Main code repository
+
This is the repository you are currently in.
This repository contains all the source files of Colobot, along with some 3rd party libraries, testing framework and build files for CMake.
### Data repository
+
The data repository is available at: https://github.com/colobot/colobot-data
This repository contains the data files necessary to run the game. These are level files, textures, models, sounds, music, help files, translations, etc. It contains many binary files, and so, it may grow up to considerable size. If that becomes a problem, we may remove some old revisions of binary files to free up space.
### Branch setup
+
Current setup is as follows:
* branch **master** - will always contain the best-playable version of the project so that new users could download and compile the project without problems. This branch is not intended for actual development but an integration branch for more "public" releases. The changes should be pulled from general development branch - *dev*. This branch will also have tags at certain commits to denote releases.
@@ -23,11 +28,13 @@ Current setup is as follows:
Other **dev-*** branches may be created as needed, for work on major rewriting, or focusing on a set of features.
## 3rd party libraries
+
3rd party libraries are bundled in `lib/`. They are provided for ease of use since the standard packages are rare in OS distributions.
In case of GTest and GMock, CMake tries to detect if they are available in the system. If so, the system-provided versions will be used.
## CMake build system
+
The build system is as follows:
* `CMakeLists.txt` - definition of project, list of required packages, build type setup, general compiler options and reference to src subdirectory,
@@ -59,6 +66,7 @@ Note that the recommended way of building the project is to use separate build d
```
## Tests organization
+
Tests are kept in `test/` directory which includes:
* `test/cbot` - CBOT interpreter for test purposes,
@@ -67,6 +75,7 @@ Tests are kept in `test/` directory which includes:
Each test directory contains own `CMakeLists.txt` specifying targets. Note however that the only targets added as automated tests in CMake are in `test/unit` directory. The other targets are used as development support tools, not automated tests.
Tests can be enabled or disabled using CMake option TESTS (OFF by default). To run the automated tests (you must be in the build directory):
+
```
./colobot_ut
# or:
@@ -75,25 +84,26 @@ Tests can be enabled or disabled using CMake option TESTS (OFF by default). To r
ctest -V .
```
-For unit testing, we use Google Test framework (http://code.google.com/p/googletest/) and for mocking objects and function calls, GMock library (http://code.google.com/p/gmock/).
+We use [Google Test](https://github.com/google/googletest) for unit testing and [Hippomocks](https://github.com/dascandy/hippomocks) for mocking objects and function calls.
-Note that currently, there are very few well-tested parts of code. It is quite impossible to write unit tests for all the code we have but we should test as much code as possible, if not at unit level, then at module level. Hence the test environments and code snippets that enable us to test parts of code without actually running the full-fledged game.
+Note that currently there are very few well-tested parts of code. It is quite impossible to write unit tests for all the code we have but we should test as much code as possible, if not at unit level, then at module level. Hence the test environments and code snippets that enable us to test parts of code without actually running the full-fledged game.
## CI and automated builds
-Our team is not large, but since compiling the whole project is lengthy and requires some knowledge, we use some automated services to facilitate the development.
-Currently we use Jenkins server hosted at http://compiled.colobot.info/ to run tests and provide compiled game binaries.
+Currently we use [GitHub Actions](https://github.com/colobot/colobot/actions) to run tests and provide compiled game binaries.
Testers are encouraged to use these packages to test the game and report any problems.
## Code documentation
-[Doxygen](http://www.stack.nl/~dimitri/doxygen/) is used as the documentation tool.
-The documentation is extracted from comment blocks in code by running `make doc`. The resulting HTML files are available in ''doc/'' inside the build directory. Generated documentation files '''will not''' be included in the repository. The idea is that anyone can generate the documentation at any time, in his local copy. Our Jenkins also builds documentation after every commit, see http://compiled.colobot.info/job/colobot/job/colobot/job/dev/Doxygen/
+[Doxygen](https://www.doxygen.nl/index.html) is used as the documentation tool.
+
+The documentation is extracted from comment blocks in code by running `make doc`. The resulting HTML files are available in ''doc/'' inside the build directory. Generated documentation files '''will not''' be included in the repository. The idea is that anyone can generate the documentation at any time, in his local copy. GitHub Actions also builds documentation after every commit, see https://github.com/colobot/colobot/actions
Diagram generation (class inheritance, include dependencies, etc.) is disabled for now to speed up the generation process but you can of course enable it in your local copy.
Currently, only a few classes and structs are documented properly. If you can, please expand the documentation wherever possible.
## Coding rules
+
Please refer to the [CONTRIBUTING.md](CONTRIBUTING.md#coding-style) file.
diff --git a/README.md b/README.md
index 4bb5e62a..56f5d17a 100644
--- a/README.md
+++ b/README.md
@@ -1,47 +1,56 @@
-# Colobot: Gold Edition
+
-Welcome to the Colobot: Gold Edition project code repository
+