I have not published a MonoGame built game, but have published to stream.
I would suggest reading info in this document.
https://partner.steamgames.com/doc/features/common_redist
At minimum, since MonoGame 3.8.1.303 (current version) is net6.0, users will need the .Net 6.0 Runtime distributable.
I may have spoke too soon. I just checked and they do not have the .NET 6.0 Redistributable as a selection, which is concerning and weird, but it is what steam is
So you may have to look into including it in an install script. More information on doing this can be found in this document
https://partner.steamgames.com/doc/sdk/installscripts
Unfortunately, I wish I could be of more help here
Edit: Adding the edit here that I’ve posted in the developer forums to have the current .NET 6.0 redistributable included since it is the current LTS release of .NET. Unsure if they’ll actually add it, but maybe
So you no longer need to distribute XNA? Just .NET 6? Actually .NET 7 is the latest.
NET 7 is the latest, but it’s not the current LTS (Long Term Support) version.
NET 8 coming later this year will be the next LTS version. Only even numbered versions are LTS.
Current MonoGame 3.8.1 uses NET 6 (even though you can manually change this to net7 in your csproj).
So, I did an LDJam recently-ish and had a streamer on twitch download and play the game. When they did, the only requirement they needed other than the files included from the build was that they had to manually install the .NET 6.0 runtime redistributable.
This would be the same case for any MonoGame game built using current MonoGame version. The end-user just needs the .NET 6.0 Runtime Redistributable. Everything else needed is included in the build directory that you’ll publish to steam as your game.
I’ve sent this to Steam support. Will they upgrade? I dunno. Maybe they’ll send me a work around. I’ll let you know either way. Interesting that there’s an XNA 4.0 option. I didn’t know that MonoGame requirements switched from XNA to .NET.
I don’t think MonoGame ever “required” XNA, except for early on when it may have been used for certain things like content building. But that was years ago.
You don’t actually need to have end users install .NET themselves. If you follow the instructions for packaging here in the docs, by building your publish build via command line like this (for Windows, for instance):
dotnet publish -c Release -r win-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained
This creates a publish build that’s put into a folder called “publish” within the Release binary folder. With this, no installation of .NET by the end user is necessary. The build is self-contained, meaning all of the .NET DLLs are packaged with it. This does increase the size of the game installation somewhat (by a bit over 100 MB), but it’s convenient. It’s what I do for my game Nonozle, which I’ve published on Steam.
Make sure not to just copy the contents of your games Debug binary folder when distributing your game, as those binaries are unoptimized.
If your game is targeting DesktopGL and not WindowsDX, you may also be able to use .NET’s trimming function for self-contained apps, which only includes .NET DLLs that your app actually uses, reducing the size of the installation folder. I haven’t tested this myself with DesktopGL, though, and I’m pretty sure it doesn’t work with WindowsDX because that has a reliance on Windows Forms which, unless something has recently changed, is incompatible with the trim function.
HopefulToad, don’t go away! I’m going to need you!
Just got a reply from Steam Support basically saying, “yeah, maybe we’ll set up .NET 6 redistributable, but don’t hold your breath.” So, it looks like everything is going to have to be done via the install scripts.
My installation is going to be a PITA and I’m feeling overwhelmed. There are basically two products:
-
The General Staff: Black Powder Battle Designer Bundle (which contains 3 different programs + a launcher; all written in WPF). Link to store and videos.
-
General Staff: Black Powder (the actual game written in MonoGame). Link to store and videos.
On top of that we need to do the following folders and file copies:
-
Create a folder in User/AppData/Local/GeneralStaff and then a bunch of sub-folders in there
-
Copy a bunch of files into various folders inside the AppData folder (above)
-
Copy a bunch of fonts over to the Fonts directory (these are for the Army, Map & Scenario Editors which are actually written in WPF, not MonoGame so they don’t have compiled fonts).
Do you think you could help with that? Could I pay you something? Obviously, give you Steam keys for the games. I’m busy trying to finish up the actual game. If you want, email me Ezra[at]RiverviewAI.com
No need to pay me anything, but I’ll try to help if I can. It sounds like your game distribution is going to be more complicated than mine, since I just have the game with no other external editor tools or anything like that.
I haven’t published a WPF app, so I don’t actually know the standard procedure for that. But publishing a MonoGame game is pretty simple:
-
Create a publish build of your game using the command line text I mentioned earlier.
- Open up the command prompt.
- Navigate to the base folder of your project.
or
- If you’re using Visual Studio, just open your project then open the terminal (View > Terminal).
next
- Build the publish build of your game.
dotnet publish -c Release -r win-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained - If it’s not copied over automatically, copy your game’s content files to the “publish” folder that was created.
- Now your game should be self-contained within that folder and ready to run. This is the folder that you’ll upload as a build to Steam.
When you publish in this way, the app is self-contained and no install scripts are necessary.
Edit: I forgot to mention: if you build the game from your documents folder where it is likely stored, there could be privacy concerns, because the project paths are sort of built into the app and could reveal to end users your computer user name and some of your computer directory layout. You may not be concerned about this, but I personally didn’t want to reveal my computer user name, so I moved my projects to an anonymous directory in C: called “Code”. I’ve heard that it’s better to have a dedicated machine for building your app rather than using your development machine, but I don’t quite understand why. I haven’t run into any issues building the game on my own development PC.
Have you perused the Steamworks documentation? If not, you’ve got some homework to do. There’s a lot of useful information in those docs, and a lot of it is explained better than I could do. But for basic uploading to Steam, you can use the SteamPipeGUI tool (only available on Windows). This is what I use. Before you can upload the game, you’ll have to have your game’s depot(s) configured.
Creating folders using .NET is easy. Just call Directory.CreateDirectory(/*directory path*/); That’ll create the directory if it hasn’t been created already and do nothing otherwise. Unless I’m misunderstanding what you mean?
Edit: Also, I would use Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData). This will give you the AppData\Local folder without you having to hard-code it.
I use Steamworks.NET to integrate Steamworks into my game. This can get complicated, but there are various examples of how to do things scattered about the internet. @BlizzCrafter has created an example repo and uploaded it to Github. Here’s a post about it. That could be helpful.
I just use Steamworks for a few things: achievement support, basic ownership checking, and Steam Auto-cloud. Use of Steamworks is technically optional, but you’ll probably find most players expect certain features in games published on Steam, like achievements and cloud saving.
I found a Microsoft docs page about deploying WPF apps.
Here’s a screen cap of what’s going on in User/AppData/Local/GeneralStaff/BlackPowder:
So, as you can see there are a LOT of folders and inside those folders are all kinds of files. Some are created at runtime, some are needed before first use. I don’t want to create them from the WPF launcher app (or whatever), I need to create them as part of the actual installation and then fill them up with the required files. Then, I need to copy a bunch of fonts over to the Fonts folder. Last, we can throw all the apps (the three editors done in WPF, plus the Launcher (shown below) and, eventually, the actual game (done in MonoGame) into the ‘main game’ folder.
The launcher:
So, as you can see there’s a lot of stuff being copied around to specific places. Oh, and installing .NET 7. The only thing that I want to use Steam for is handling the money and the downloads. I don’t even care if people illegally copy my work. I’ve been around long enough to know that if somebody steals your work, they weren’t going to buy it anyway.
In that case, if you don’t want to just check if the folders exist when the game first launches and populate them then if they don’t, you’ll have to do install script shenanigans, which I unfortunately don’t have any experience with.
Are you wanting to install the actual game itself into AppData? If so, I don’t think that’s recommended. With Steam, games are installed into the library folder, which defaults to “C:\Program Files (x86)\Steam\steamapps\common”. AppData should contain settings and other files that are going to be modified after installation.
No, definitely not installing the game or the editors or the launcher in AppData. They would be in their own folder: General Staff: Black Powder.
AppData will contain settings and other files that are going to be modified after installation. Absolutely. No executables in there.
Last night I was thinking the same thing as you: let’s just do the set up from the Launcher? Okay, but then we would have to download a ton of files from Steam to put into those folders. I just want a one click and it’s done install. It’s not very big, either.
Here’s what needs to go where:
- /User/AppData/Local/GeneralStaff/BlackPowder/
- /Armies/
- A number of .xml army files that we are including
- /Backgrounds/
- A number of .bmp background files that we are including
- /Game/
- /Loader/
- FilePaths.txt ß Initially missing
- /Maps/
- A number of .zip map files that we are including
- /Scenarios/
- A number of .xml map files that we are including
- Settings.xml
- /Armies/
- “C:\Program Files (x86)\Steam\steamapps\common”RiverviewAI/GeneralStaff/BlackPowder/
- GCBP.exe
- /ArmyEditor/
- GSBPArmyEditor.exe
- /MapEditor/
- GSBPMapEditor.exe
- /ScenarioEditor/
- GSBPScenarioEditor.exe
- /Replay/
- DLLs???
- Fonts
- Various licensed Victorian fonts need to dropped in the Fonts folder
PLUS: .NET check and install
I’m not sure I understand. All of the files that you want to go into AppData, if they aren’t simply being generated by one of your executables at runtime, would need to be downloaded via Steam at the time of installation, where they would have to have a place somewhere in steamapps\common\your game. If you don’t want them to simply stay in your steamapps folder, perhaps you could include them with your game as a compressed .ZIP file. Then, when the end user first runs your launcher, it could detect that AppData hasn’t been populated yet, extract the AppData files and populate them. Or they could just be included with your game uncompressed and copied directly to AppData on first launch of the launcher.
As for fonts, you’re wanting to copy fonts directly to the Windows system font folder? That would mean that, for instance, users would then be able to use those fonts in Microsoft Word. Do the font licenses allow for that kind of redistribution with your game? Font licensing is tricky enough for me that I avoided it entirely by creating my own bitmap fonts and bitmap font rendering system.
That is exactly what I was thinking the other night. So, if you’re thinking the same thing, it’s a good idea?
Also, RE: Fonts. Yes, I did work out a licensing deal with the font maker (Walden Fonts) and I’m paying them a license of a $1 an install. I think, in the end, they will be very happy.
Well, it’s worth giving it a try, unless you can think of reasons why it wouldn’t work.
That’s cool. Pretty nifty fonts. Though since it says it’s solely for use in the General Staff Wargaming System, I’d be hesistant to copy those fonts directly to users’ system font folders, because then the users could access the fonts using other programs, which they aren’t licensed for. You should be able to just include or embed the fonts with your game and your WPF apps without having to copy them to Windows\Fonts. See, for instance, this Stack Overflow question: c# - How to include external font in WPF application without installing it - Stack Overflow
Also…
(obligatory I am not a lawyer and this is not legal advice)
Just want to add a comment real quick that while doing a self contained build does solve the issue of the end user needing the runtime installed, steam really should add the current .NET LTS version as a redistributeable and would be the better option for end users in general.
If every net6.0 game published to steam is a self contained build, then thats a lot of repeated included dlls even when trimmed across the spectrum for all net6.0 based games and apps.
Absoltuly use self contained as a solution right now, just wanted to say, again, steam really should just add the redistributable, but thats on them.
I, of course, sent a ticket to Steam Support about this and got, “Thanks for reaching out. I will pass along this request, although I can’t confirm when it will be added.” In other words, don’t hold your breath on this.
In general, it seems that Steam is built for Unity and Unreal built games. I’m just using them as a store and to collect money and handle downloads. I wish the download part was easier.
Thanks! I’m going to see about this alternative to installing the fonts. Walden Fonts wasn’t worried (basically, the demographics of my target audience (wargamers) aren’t big on pirating software and fonts). But, this will make distribution easier.
My WPF expert (this guy really knows it inside and out) says that we can’t embed the fonts because it can cause a memory leak. I don’t know the details, so I’m just going to accept what he said.
I think I’m going to move forward with the plan to do all the folder creation and copying from the Launcher on the first run.
I’m just going to mark this as the solution because that’s the approach I’m going to use.