Skip to content

Developing and Setting Up IDEs

Quintillus edited this page Apr 13, 2024 · 22 revisions

We recommend starting with the C7 Development VM, where much of the initial setup is already done for you.

Although C7 uses Godot, an estimated 90% of the development is in C#, either using Godot libraries through code, or writing non-Godot-related code such as loading files or AI code. Thus, having a good C# development environment set up is essential.

The team has tried out three different IDE setups, each of which have their advantages and disadvantages. This post is being expanded to explain how to get started with each, and why you might choose one or another.

The tl;dr of the below is that if you have a Rider license, it is recommended as the best all-around IDE. If you don't, we recommend starting with VS Code.

Required Items, Regardless of IDE

First, you'll need to install the .NET SDK, version 6.0 or higher.

Then you'll will need to download the Godot Editor, which is available here. Be sure to download the Mono version (C# support) of the latest stable 3.x release. Either 64-bit or 32-bit will work, and contrary to Godot's website, the 32-bit version does work on 64-bit Windows.

Technically you can do all your work in the Godot Editor, but its C# editing and refactoring capabilities are poor, so it's recommended that you choose a more full-fledged C# IDE as well. You will use the Godot Editor for tasks such as wiring up Godot events on the front end and creating UI elements, but that is a small minority of the work.

Godot Editor

For any work done directly in Godot, you will need to use the Godot Editor. You can also build, run, and debug from the Editor.

The first time you check out C7 you will need to add it to Godot. From the Project Manager click Import and select the location of C7/project.godot. Then open Editor > Editor Settings... > Mono > Builds (this will only be available in the Mono version) and make sure Build Tool is set to dotnet CLI. Now back on the main screen, expand the MSBuild tab at the bottom and select Build or the play button at the top right.

C# IDEs

Visual Studio Code

Once VSCode is installed, open the "Prototype" folder to which you downloaded this repository.

Next, you'll need to install a few plugins from the marketplace:

  1. C# for Visual Studio Code. This gives you syntax highlighting, IntelliSense, Find References, and other nice IDE-like features for C#.
  2. C# Tools for Godot. This gives you the ability to launch C7 from VS Code, and lets you debug it.

It should be possible to follow this guide to set up debugging, but we've had mixed experiences with that, so we're still figuring out exactly what the steps are.

Code formatting

Finally, set up code formatting. For Visual Studio Code, formatting is done with OmniSharp and configured by the .editorconfig file. In order to configure OmniSharp, do the following:

  1. In your home directory, create ~/.omnisharp/omnisharp.json with the following contents
{
  "RoslynExtensionsOptions": {
    "enableAnalyzersSupport": true,
  },
  "FormattingOptions": {
    "enableEditorConfigSupport": true,
  }
}
  1. Add the following options to your VS Code settings.json (either workspace settings or your user level settings)
"omnisharp.enableMsBuildLoadProjectsOnDemand": true,
"omnisharp.enableEditorConfigSupport": true,
"omnisharp.enableRoslynAnalyzers": true,
  1. Optionally but recommended, add this option to your VS Code settings.json to enable formatting on save
"[csharp]": {
  "editor.formatOnSave": true,
}

Troubleshooting

  • Linting or IntelliSense are completely broken
    • try adding "omnisharp.useGlobalMono": "always" to settings.json
    • you may need to rebuild the entire project through the Godot IDE

JetBrains Rider

Rider is arguably the best IDE for developing with C# and Godot. It has strong C# support, including refactoring, and supports debugging Godot projects with very little manual setup. Rider (and other JetBrains products) also have, IMO, the best Git merge resolution tool in the industry.

Once Rider is installed, go to the Plugins area, and install the "Godot Support" plugin (the GDScript plugin is not required, nor is the Godot Theme plugin). This will let you run Godot projects from Rider, and even better it will auto-detect the correct configuration so long as Godot is also installed.

If you want to debug with Rider, you'll also need to install DotTrace, which is JetBrains' C# profiler/debugger.

The downside is that Rider and DotTrace are commercial products, and if you are just trying out C7, it's probably not worth the cost. But there is a 30-day free trial for both Rider and DotTrace, which is enough time to try out Rider and C7 development. You can download Rider here.

Once you have Rider and DotTrace installed, open C7.sln, which lives in the C7 folder of the Prototype repository.

Then, set your Run/Debug configurations to be equivalent to the following, making sure the paths are correct locally. These will likely default to the correct values:

Note: This is for Godot 3.5. For Godot 4, it is the same configuration, but a ".NET Executable" configuration type, rather than "Start and Debug". For the Runtime on Godot 4, ".NET/.NET Core" works as expected

image

You can optionally rename the "Player" configuration, but it is the one you will want to launch. You should now be able to debug C7 from Rider.

For additional discussion of Rider, please see thread about it at CFC.

Troubleshooting

If Rider fails to load the projects, you most likely forgot to install .NET 6.0. If you did, make sure you restarted after installing it.

You may run into an error: [MSB4236] The SDK 'Microsoft.NET.Sdk' specified could not be found. D:\Development\Civ Related Projects\Prototype\C7Engine\C7Engine.csproj at (0:0) when you open C7.sln in Rider.

We believe the solution to this is in the "Build, Execution, Deployment" -> "Toolset and Build" section of the Rider settings, but need to do some comparisons of working and non-working installs to have any certainty of how to fix it.

Visual Studio 2019 Community Edition (No Longer Supported)

We no longer support VS 2019 as of May 2022. The files required to debug from VS2019 caused project cross-platform compilation problems due to relying on the old C# project structure and the Windows-only .NET 4.7 framework. We expect there to eventually be proper Godot support in Visual Studio 2022, which will fix this problem, but for now you should use VSCode or Rider.

If you want to experiment with VS2019, you will need to locally re-add the files in this old folder. Do not re-commit them, however, as they will break the project for others.

VS2019 instructions

It's important that you use Visual Studio 2019, as you cannot run/debug Godot from Visual Studio 2022 yet, and 2019 was the first version to be supported. The lack of 2022 support is due to changes made in Visual Studio, and Godot hopes to eventually support it, but for now 2019 is your friend.

In the Visual Studio Installer, open the Visual Studio Build Tools, and make sure that ".NET Desktop Build Tools", including ".NET Framework 4.7.1 development tools", are installed.

image

Then, go to Visual Studio 2019, and ensure that ".NET Desktop Development" (with .NET 4.7.1) and "Mobile Development with .NET" are installed, although you can uncheck the optional Android sub-component of the latter.

image

You'll also want to set up Visual Studio's whitespace configuration, specifically using tabs for indentation. This can be done via Tools -> Options, with this setting:

image

It may also be useful to turn on the "View Whitespace" option:

image

For additional questions, see the Visual Studio Community 2019 thread at CFC.

Command Line Development

Building the Project

The project can be built from the Godot editor or from the command line. It is important to note that, an initial build from the Godot editor is required (ie. when first cloning the project) in order to build from the command line. This is because building from the command line will only build and update C# scripts, but will not include changes made via the Godot editor. Similarly, the project should be built via the editor after making changes in the editor. When only doing C# development however, the project can be build by invoking either msbuild in the C7 folder. The msbuild documentation provides details on optional arguments including the -m flag which will build the project using multiple cores.

One caveat of msbuild is that it is provided by Visual Studio. If you do not have Visual Studio installed, you can also install the .NET SDK 6, and invoke the equivalent dotnet build command instead.

Running the Project

Running C7 can be done by invoking Godot from the command line. You must first add the folder where Godot is installed to your system path. Then, invoking godot in the C7 folder will run the application: cd C7 && godot MainMenu.tscn

Running xUnit Tests

In the project folder containing an xUnit project, run the command dotnet test --logger "console;verbosity=detailed". The --logger value ensures that the status and name of each test being run is logged to the console.

Adding Logs Locally

Please note that this will change after #259 is completed.

Logs are configured in the LogManager class, which is part of the C7 project. There is a section that explains how this works; the code looks like this:

		Log.Logger = new LoggerConfiguration()
			.WriteTo.GodotSink(formatter: consoleTemplate)
			.Filter.ByIncludingOnly("(@l = 'Fatal' OR @l = 'Error' OR @l = 'Warning' OR @l = 'Information')")	//suggested:  OR SourceContext like 'C7Engine.AI.%' (insert the namespace you need to debug)
			.MinimumLevel.Debug()
			.CreateLogger();

Above the code, you'll see details on how to configure it. By default, it is configured to show 'Information' level or higher logs, and also to show debug or higher logs for any namespace you add as an approved filter for all log levels to the Filter.ByIncludingOnly line.

You can configure this to show debug or verbose logs for only the module you are debugging, to show only warnings and higher for other modules but debug or higher for your module, or any number of other ways.

Please note that our knowledge of Serilog is evolving, so there may be more up-to-date comments about the recommended way to configure logs in LogManager than what you are reading here.