[Dev] Godot / Mono Synchronization Thread

I am every-so-slowly learning bits and pieces of the whole .NET/Mono/SDK/Nuget/whatevs development world. Something finally clicked for me, and for the first time I was able to successfully compile the C7 project .sln without using Godot.

I wasn't able to do that before, but before typing on about how I did it, I just tried a different way that I expected to fail, and it worked. So...I am again confused.

Well, I'll talk through my revelation, anyway: The compiler tools need a particular SDK, and in our case it seems to be the Godot.NET.Sdk/3.3.0 . I had previously tried fetching that with Nuget, but I recall failing to get the dotnet command to build the project from the cli.

But the nuget command is part of Mono, so my apparent epiphany was to use the mono nuget & msbuild tools to compile, and that worked. I thought I found a new thing. But then after starting this post I tried dotnet restore and dotnet build, and that worked, too, so I'm not sure why I had trouble before but it works now. Maybe it has something to do with the Visual-Studio-friendly changes? Just a wild guess.

Anyway, the real-world relevance of this is that I am confident we can do unit testing now, because if we can build from the cli then we can unit test from the cli.

Also, I'm a bit less confused about how Mono/.NET and Godot are working together.

As far as exporting/deploying I don't think this changes anything for us. I see no gain to avoiding Godot's export functionality only to try to compile and package things up ourselves. I just wanted the ability to run unit tests, and we seem to be there.

I guess another thing is that I'm now really, really, really confused about which bits of which SDK are used in compilation, and how much if any that differs between the dotnet cli, the mono cli tools, Visual Studio, and Godot's export command (which can use either dotnet's cli or mono cli tools).
 
Very interesting. MonoGame is like this, although I can't really compare it to Godot as Godot is a whole game engines and MonoGame is mostly a graphics framework. `dotnet new mgdesktopgl` and `dotnet run` and you have a cornflower blue starter "game" window. (I'm starting to understand why former clone attempts went with XNA or MonoGame instead of a game engine, but I am *NOT* suggesting we change course for C7. But also Godot probably wasn't a thing then and other game engines were inappropriate to the task.)

When I first read the idea I thought "nah, they aren't going to do that. Their core audience wants and needs the editor entrypoint." But they seem to be serious about making this happen which is really good for us code-first types.
 
Terminology question from someone who's never worked with a game engine prior to Godot on C7: What exactly is the difference between a game engine and a graphics framework? Or perhaps better stated, what do you need to add to a graphics framework to wind up being a game engine?

I've used graphics libraries, and probably graphics frameworks. JavaFX is probably a graphics framework. But while you can write games with it, I don't think many would call it a game engine. If the editor were the only difference though, then a decent Java IDE + JavaFX would be a game engine, which I'm pretty sure isn't the case either. Is it additional frameworks for handling common game-related tasks such as events that makes something a game engine?

Basically I'm trying to better understand the tradeoffs of using a game engine versus a graphics framework, say XNA or MonoGame. On the one hand it seems like it makes sense to use a game engine to build a game, but on the other hand I'm not sure what we're really gaining from it beyond the graphics framework part of it. There's the scene editor, but JavaFX also has a drag-and-drop scene editor, and it isn't a game engine. I like Godot, but it's the graphics framework part of it that I can point to and say "that's why I like it."
 
I'm kind of exploring the space myself, so what I say isn't necessarily right. To me a game engine may have things like physics engines with collision detection, scene handlers, animation structures, and so on.

A framework to me has graphics functions but not necessarily the other stuff. MonoGame in particular doesn't even seem to have primitives (lines, circles, rectangles, etc.)! The native way to draw a line is to make a one-pixel texture, stretch it, and rotate it, coder-mathed. That kind of blew my mind in a bad way at first, but then I realized I'm not going to be using a lot of primitives in any of the final product; it's all tossing textures onto the screen, and MonoGame does that fine as far as I can tell so far. (Not that I've done any original coding myself; just copy/paste or meatspace copy/paste because YouTube.)

I am starting to see some very familiar patterns among the things I've tried so far, though. Godot, Love2D, and MonoGame are all designed with init, value-update, and draw-screen entry point functions (with varying names but serving very similar purposes). Godot and Love2D are the launch programs whereas MonoGame has your project as the launch program, but the template basically creates a game instance and then everything is called from there, so it's really kind of the same thing where your code is at the beck and call of the third-party main thread.

Another difference that I don't fully understand yet is that you have to precompile assets with a separate tool for MonoGame/XNA. I see now this is apparently related to why Godot leaves .import junk around when you pull in a PNG or something. I think Godot is doing the same thing but hiding the sausage-making from us.

I was going to try to do actually do something myself with MonoGame today but got diverted trying to turn Bumpy Road into a visual novel. A completely silly thing to do, but I wanted to play with the Ink dialogue system–natively C# but has a Lua port–and use it with a game engine. And also to see if I can figure out...why? Why are visual novels?
 
I saw that. I haven't dug in closely, but 4.0 seems like it's farther off than I believed a few months ago, and it seems like 3.4 and 3.5 are largely backports of new 4.0 features along with some bugfixes. Glad we didn't try to go with 4.0 from the start.

On a different note re: my recent post above, I had some additional input on what some people think differentiates a "game engine" from other stuff: an editor.

That makes sense to me. You can do a lot in the Godot editor without coding a thing, but in my other favored engines Love2d and MonoGame (actually I haven't really done anything with the latter yet), everything is code. Which is why I like them.
 
So for the folks on Mac/Linux... are you using Mono or .NET Core Runtime?

I ask as @Flintlock has opened PR #72, which attempts to fix case sensitivity problems on Linux (and presumably Mac) when run with the .NET Core Runtime instead of Mono (Mono, like Windows, is case-insensitive). The goal being that when someone adds "someFiraxisGraphic.pcx" to load more graphics, but it turns out that Firaxis named it ".Pcx" or ".PCX", it won't cause the game to stop working on Linux/Mac with .NET Core Runtime anymore.

Which makes sense, as the PCX files are spectacularly inconsistent in their capitalization, especially of the file extension, so it's really hard to avoid committing it with incorrect capitalization occasionally if you are developing with a case-insensitive file system. Unfortunately, as-proposed the PR breaks C7 on Windows (not sure about Mono) due to using forward slashes on all systems in its check. I also wonder whether it will add a decent amount of overhead with its directory traversal to check for case insensitive matches.

So it got me wondering, what are the rest of the Linux/Mac folks running on, Mono or .NET Core Runtime? It seems like it might make sense to standardize on Mono if it solves case sensitivity problems automatically, at least if there aren't any other downsides. But not being on Mac/Linux myself (rare Bionic Beaver testing aside), I don't recall what the relative merits of each approach are. Still, if they behave differently in some areas, it may be worth saying, "we're supporting one but not the other".
 
Case sensitivity sounds like a good target for automated testing.

I have both Mono and .NET Core installed, but I keep learning I am really confused as to which is getting used. My Godot is set to "MSBuild (Mono)" in Editor Settings -> Mono -> Builds, but I don't think I explicitly set it that way.
 
WildWeazel said:
(I mean, I'd like for Godot to use .NET 6 on principle, but not to break from the supported environment.)
Click to expand...
But wait there's more! I just got around to reading the 4.0 alpha announcement and found this nugget near the end:
There are a number of other features and important fixes in the pipeline for Godot 4, which are still being finalized and will be included in future alpha releases. Notably, C# support is undergoing a port to .NET 6, which is why Mono builds are not included in this alpha.
Click to expand...
:banana:
 
I think I saw that Mono support for Godot 4.x will arrive with 4.1.

I see .NET 6 still supports Windows 8, so I'll be able to continue developing for the project if we do switch to it. It drops support for Windows 7 without Extended Security Updates (i.e. paid updates for those with corporate licenses), though (source). From my experience developing tools for Civ3, we probably have a higher-than-typical amount of Windows 7 users.

I've been too busy with a non-CFC project to pay too much attention to C7 lately, though. I see we're still at 6 PRs... I was hoping that would have fallen to 4 by now, since two are approved for merging (mine requires the popup one to be merged first, and some changes, before it can be merged).
 
You know, I had never thought about the target system having to support the framework. I guess I'm used to Unity where IL2CPP can build a target-native executable, but that's not an option here. So framework compatibility is an important factor to consider. That raises another question to investigate though: are our potential users running obsolete systems for Civ3, or are they sticking with Civ3 in part because they have obsolete systems? Or more to the point, what systems would they choose to play C7?
 
You must log in or register to reply here.

Similar threads

Quintillus
[Dev] Potential Starting Quests for New Developers
Replies
5
Views
1K
Kyriakos
Kyriakos
Quintillus
[Dev] [Audio] Audio Thread
Replies
11
Views
457
Vuldacon
Vuldacon
Quintillus
[Dev] Early 0.2 "Carthage" Progress Thread
2
Replies
30
Views
900
Puppeteer
Puppeteer
Quintillus
[Dev] 0.0 "Aztec" Progress Thread
2 3 4
Replies
69
Views
2K
Puppeteer
Puppeteer
WildWeazel
Dev Diary 0: Introducing "C7" Godot Prototype
Replies
9
Views
543
Puppeteer
Puppeteer
Top Bottom