Note: This document at present is for only code contributors. We should expand it so that it covers reporting bugs, filing issues, and writing docs.
We have a Discord server to discuss Libplanet. There are some channels for purposes in the Libplanet category:
- #announcement: Maintainers announce events like our roadmap or local events.
- #users: Chat with game programmers who use Libplanet. Ask questions to use Libplanet for your games.
- #development: Chat with maintainers and contributors of Libplanet. Ask questions to hack Libplanet and to make a patch for it.
- #users-ko: The same purpose to #users, except you can speak Korean instead English here.
- #development-ko: The same purpose to #development, except you can speak Korean instead English here.
You need .NET Core SDK 3.1+ which provides the latest C# compiler and .NET VM.
Read and follow the instruction to install .NET Core SDK on
the .NET Core downloads page.
FYI if you use macOS and Homebrew you can install it by
brew cask install dotnet-sdk command.
Make sure that your .NET Core SDK is 3.1 or higher. You could show
the version you are using by
dotnet --info command.
Unless you already have your favorite setup, we recommend you to use Visual Studio Code. It is free, open source, and made by Microsoft, which made .NET as well. So Visual Studio Code has a first-party C# extension which works well together.
The following command installs dependencies (required library packages) and builds the entire Libplanet solution:
We use SonarAnalyzer to check our code quality but it takes longer to build. To skip the analyzer, you can use:
dotnet build -p:SkipSonar=true
The planetarium/libplanet repository on GitHub consists of several projects:
Libplanet: The main project, which contains the most of implementation code. When this is built into a NuGet package, it consists of two assemblies: Libplanet, and Libplanet.Stun, explained below.
IStoreimplementation built on RocksDB. As this depends on platform-dependent libraries (which is written in C/C++), this is distributed as a distinct NuGet package: Libplanet.RocksDBStore.
Libplanet.Analyzers: Roslyn Analyzer (i.e., lint) for game programmers who use Libplanet. This project is distributed as a distinct NuGet package: Libplanet.Analyzers.
Libplanet.Benchmarks: Performance benchmarks. See the Benchmarks section below.
Libplanet.Tests: Unit tests of the Libplanet project. See the Tests section below.
Libplanet.Stun.Tests: Unit tests of the Libplanet.Stun project.
Libplanet.RocksDBStore.Tests: Unit tests of the Libplanet.RocksDBStore project.
Libplanet.Analyzers.Tests: Unit tests of the Libplanet.Analyzers project.
We write as complete tests as possible to the corresponding implementation code. Going near to the code coverage 100% is one of our goals.
The Libplanet solution consists of several projects. Every project without .Tests suffix is an actual implementation. These are built to Libplanet*.dll assemblies and packed into one NuGet package.
Libplanet*.Tests is a test suite for the Libplanet*.dll assembly. All of them depend on Xunit, and every namespace and class in these corresponds to one in Libplanet* projects. If there's Libplanet.Foo.Bar class there also should be Libplanet.Foo.Bar.Tests to test it.
To build and run unit tests at a time with .NET Core execute the below command:
To run unit tests with .NET Framework:
nuget install xunit.runner.console -Version 2.4.1 msbuild /restore /p:TestsTargetFramework=net472 & (gci xunit.runner.console.*\tools\net472\xunit.console.exe | select -f 1) ` (gci *.Tests\bin\Debug\net472\*.Tests.dll)
Or with Mono:
nuget install xunit.runner.console msbuild /restore /p:TestsTargetFramework=net472 mono xunit.runner.console.*/tools/net472/xunit.console.exe \ *.Tests/bin/Debug/net472/*.Tests.dll
Some tests depend on a TURN server. If
TURN_SERVER_URL environment variable
is set (the value looks like
these tests also run. Otherwise, these tests are skipped.
Unity is one of our platforms we primarily target to support, so we've been testing Libplanet on the actual Unity runtime, and you could see whether it's passed on Azure Pipelines.
However, if it fails and it does not fail on other platforms but only Unity, you need to run Unity tests on your own machine so that you rapidily and repeatedly tinker things, make a try, and immediately get feedback from them.
Here's how to run Unity tests on your machine. We've made and used xunit-unity-runner to run Xunit tests on the actual Unity runtime, and our build jobs on Azure Pipelines also use this. This test runner is actually a Unity app, though it's not a game app. As of June 2019, there are executable binaries for Linux, macOS, and Windows. Its usage is simple. It's a CLI app that takes absolute paths to .NET assemblies (.dll) that consist of test classes (based on Xunit).
You can build these assemblies using
msbuild -r Mono or .NET Framework
You can't build them using
dotnet build command or
because the Unity runtime is not based on .NET Core but Mono,
which is compatible with .NET Framework 4.6.
Please be sure that Mono's bin directory is prior to .NET Core's one
(or it's okay too if .NET Core is not installed at all). Mono or .NET
msbuild could try to use .NET Core's version of several
utilities during build, and this could cause some errors.
The way to execute the runner binary depend on the platform. For details,
please read xunit-unity-runner's README. FYI you can use
option as well.
To sum up, the instruction is like below (the example is assuming Linux):
msbuild -r xunit-unity-runner/StandaloneLinux64 \ "`pwd`"/*.Tests/bin/Debug/net47/*.Tests.dll
Please follow the existing coding convention. We are already using several
static analyzers. They are automatically executed together with
and will warn you if there are any style errors.
You should also register Git hooks we commonly use:
git config core.hooksPath hooks
We highly recommend you to install an extension for EditorConfig in your favorite editor. Some recent editors have built-in support for EditorConfig, e.g., Rider (IntelliJ IDEA), Visual Studio. Many editors have an extension to support EditorConfig, e.g., Atom, Emacs, Vim, VS Code.
In order to track performance improvements or regressions, we maintain a set of benchmarks and continuously measure them in the CI. You can run benchmarks on your local environment too:
dotnet run -p Libplanet.Benchmarks -c Release -- -j short -f "*"
Note that there is
-j short; without this a whole set of benchmarks takes
quite a long time. This will print like below:
| Method | UnrollFactor | Mean | Error | StdDev | |--------------------- |------------- |----------:|-----------:|----------:| | MineBlockEmpty | 16 | 12.20 ms | 11.649 ms | 0.6385 ms | | MineBlockOneTran... | 1 | 14.54 ms | 3.602 ms | 0.1974 ms | | ... | ... | ... | ... | ... |
You can measure only part of benchmarks by
dotnet run -p Libplanet.Benchmarks -c Release -- -j short -f "*MineBlock*"
All benchmark code is placed under Libplanet.Benchmarks project. As our benchmarks are based on BenchmarkDotNet, please read their official docs for details.
Releasing a new version
Read the Releasing guide which dedicates to this topic.