Code Libraries

You know, there's a whole section of game coders that don't like coding games, but they like coding for games. What I mean by that is, their pleasure is in making libraries and tools to enable other game coders to do what they do.

This is something that's really obvious to see in GMod and Unity, and it's something we want to lean into in s&box.

So now you can make code libraries and share them on asset.party.

Asset.party is our Steam Workshop. It's where we publish assets and games, and it's now it's where we publish Code Libraries.

Why not just use Workshop? Well, it works a bit differently from how Workshop works. Asset Party is like one big filesystem of individual files, whereas workshop is like a big filesystem of zipped up files.

When you download from Workshop you download everything in that zip file, no matter if you already have some of those files. With asset.party each file is downloaded individually.. so if ten maps share the same materials - you only have to download and store them once.

There's a bunch of other flexibility we get by running our own system. For example, we can look at model and see how many other assets use it.

We can provide other usage stats to developers too. If you make a map, it's pretty cool to know which games it's being used on. It's even cooler to know how many people played it each day etc.

Workshop is a general system that has to provide a good service for as many different scenarios as possible, and it does that really well and has done it really well for 10 years.

For s&box, which is really UGC heavy, it makes sense for us to have our own system that we can completely tailor to ourselves.

Referencing a code library is as simple as adding the library to your Project Settings. After that, the library is automatically downloaded and referenced in your project's .csproj, meaning you can use the code just like it's code in your project.

When publishing, the library package is referenced like any other package, and will be downloaded alongside your game/addon/library.

When the packages are uploaded, we scan the assemblies using mono.cecil and extract the API. From that, we can automatically generate a documentation reference section for you.

This is useful to the author because you can go to the page and see what you've exposed. This, more often than not enables you to simplify your API by making types and members internal or private.

It's also incredibly useful to potential users of the library - because they can see exactly how to use it, or take one look at your naming scheme and avoid it altogether.

Of course, it'd be nice if people would document how to use their API.. and you can do that easily too.

When things get really desperate, you might want to let people see the source code. So the package pages now show the project's GitHub link too - if available.