hey yall!

i need some advice regarding game engine choices.

here's my situation:

i am currently using monogame + c#, and its working quite well for me right now. i'm quite comfortable with the framework, and i can get things done easily with it. my only issue right now is publishing the game itself. publishing dotnet projects is quite finnicky for me, and i usually end up with huge output folders with 100+ dll's in them. i did some research on publishing as single files, and that fixed the dll issue, but the exe file is still pretty big for a tiny game in comparison to the build size using other engines/frameworks. can somebody help me out here? at this point, im not exactly sure if im looking to switch frameworks, or if i should just look for a solution to package my games better.

thanks!

[7:45 PM]

More info is really required to actually provide any guidance as there are so many prongs to how you could end up in this situation.

Due to the nature of C# you're always going to end up with oodles of DLLs for all of the libraries that you're using that aren't system. With something like Fody.Costura you can compact them all into your executable w/ compression (you have to turn it off on C++/CLI libraries though) at the price of making NGen laboriously slow if not done during install (affects build→debug cycle terribly, I've experienced 5-minute stalls due to Costura being naively enabled on debug builds for a while).

Might want to post a list of all the DLLs in case you've done something funny and you're pulling runtime assemblies into your stuff (instead of bundling the runtime into your installer like you're supposed to).

The other common cause of DLL bloat is the ecosystem nonsense NuGet has created. So you'll have SuperSocket but your use of SuperSocket is actually 6 different assemblies for specific functionality, I go through and pull those kinds of projects myself from git and amalgamate them to keep that garbage tapped down or I ILMerge them, in which case I NuGet pull them into an isolated project then ILMerge them and bring them into my project. Seriously though, NuGet is how you get into this situation in the first place and nuget really needs to add some capability to do these sort of compoundings on its' damn own.

The other solution is rely on fewer libraries and write narrow solutions that fit your exact problem instead of pulling in a gigantic Tween library of which you use 10% of. If you look at a lot of your library inclusions, you probably don't use a lot of what's there and can probably find a more compact JSON library, that doesn't have a lot of bloat for that silly JSON query language that pretends to be like XQuery but w/ the caveat that it is absolute garbage, that you don't even use.

If you're building installers there will also be compression there that will make a difference, some assemblies will compress by as much 1:4 IME. So transmission won't be as harsh as storage, usually.

What do you think is the problem?

People don't think “The game looks interesting but it has too many DLLs, so I won't play.”

People these days also don't balk at size, at least not typically. A game under a few hundred megabytes is often assumed to have very little content. Solid games get up around 5-20 gigabytes. AAA is often in ten times that. Go higher and the game has to be quite good, but still plenty of games can exceed 10 GB in a monthly update. (I am looking at you, Ark!) There are gaming CPUs with 128 MB of CPU cache on the chip, and more. If you have graphics and eye candy you need a dozen gigabytes of graphics before the GPU memory is bothered on premium machines.

Problems like slow loading times are issues you need to deal with, but it wasn't what you said was your problem. Make sure you are using the optimized shipping builds, strip out debug data in what you ship, and see if you have actual problems with the software.