A C# approach to Godot file structure

Published: 2024-06-22

Tags: the-cyclical-chagringame-dev

So, I want to spend time again making this Godot game development thing to work. I wanted to study existing C# project structures, and that's not what I see in the default Godot project structure produced when making a C# project in it's launcher. I also have to point out, despite writing games in Unity, which is C#, I do not know what an actual C# project looks like outside of that.

So, I thought that a good starting point would be looking at osu!'s file structure. So, I've said like three time by now, the default Godot project follows the GDScript based project structure. It really makes testing the C# modules difficult. Following osu's project structure, I've refactored the Godot specific files into an internal project folder, and the core logic and tests for that in the future as a project on the same level as the Godot one.

During refactoring, my biggest hurdle was fighting against Godot's ID system. Godot identifies some resources based on their relative position in the project's root. This is problematic if I want to move my Godot files more inwards.

Some changes need to be made while Godot is closed, like changing core Godot metafiles. There are weird bugs like parts of the Godot editor being inaccessible if one of the properties in the metafile is pointing towards a non-existing asset. Unity's asset system might win over Godot with this respect, since Unity identifies all non-game assets and moving them around with those \*.import file is often enough. I have to refactor the metafiles, either in Godot's editor or manually to correct the file's new path.

Here's big Godot tip to myself and readers:

Always refactor in Godot's editor and not outside!

So, here's the before and after file structure:

Legends

  • + <= Folders
  • - <= Files

Original

Yam
 |- Yam.sln
 |- project.godot
 |+ Yam.Core
 |+ Yam.Core.Tests (not possible or tricky!)
 |+ Yam.Godot
 |+ Assets
 |+ Scenes

After

Yam
 |- Yam.sln
 |+ Yam.Core
 |  |- Yam.Core.csproj
 |+ Yam.Core.Tests (in the future)
 |  |- Yam.Core.Tests.csproj
 |+ Yam.Godot
    |+ Assets (General assets go here. Otherwise, they go in the Scenes folder)
    |+ Scenes (Godot specific files)
    |+ Scripts (script location; inspired by Unity's folder name)
    |- project.godot
    |- Yam.Godot.csproj

Adding Unit tests

I feel like an insane person for putting unit tests in game development. I don't think I've ever known anyone who makes games who made unit tests for their games! I'll try, though, since I'm writing complex logic that I'm comfortable just winging it along the way. I don't have the capacity to understand the project at all times, and the unit tests can help me figure out what each components do exactly.

I've learned from the past, reading about C# testing, that it does not work like Golang's nor React's, which are ones I'm familiar with. It works along like Java's (if I'm remembering it correctly) where the test project is external. There is more discipline to isolate parts of the package, and intelligently design them (or just expose everything to the public LOL). I have not seen if there are "friendly" scopes in C# like in C++ which allows testing projects to access parts of the code not usually open to other consuming/downstream projects.

But in latter searches, I figured out you can expose your internals (that sounds disgusting) to your test package like below:


<ItemGroup>
  <Folder Include="Rhythm\*"/>
  <InternalsVisibleTo Include="DynamicProxyGenAssembly2"/>
  <InternalsVisibleTo Include="Yam.Core.Test"/>
</ItemGroup>

You can see the entire csproj file at my Yam.Core.csproj. I was so confused about DynamicProxyGenAssembly2, thinking it was placeholder that I need to replace with my package Yam.Core.Test, but it was actually essential to allowing the unit testing frameworks to access the internal code. In this case, mine was xunit and Moq for mocking.

Related PRs

enfrtl
entlfr