Because everything is in c#, including our backend, we can scan the assets at any time using the excellent VRF library. This allows us to extract information from the assets without republishing.

Using this right now we can show things like triangle counts and draw calls. In the future, we'll show more information and hopefully have some system that will show warnings if triangle counts are insane etc...

All of this works with Materials too.

We've worked hard to remove as much friction as possible from the process of publishing an asset. To publish, you just select the asset and press this button.

Then just run through the wizard..

It's been important for us to dogfood this process. Our artists are using it for everything, and we have a healthy feedback cycle on what we can improve.  It's our policy to 'deliver' assets to asset.party now, rather than our repository.

All of the assets that bakscratch used to create this map are on asset.party.

All the required assets are automatically downloaded when opening a map - if you don't already have them downloaded.. 

This means that when a team member opens the map in Hammer, they'll have everything they need. 

When you publish a model, we automatically render a video of it., which is then published alongside.

This video is automatically processed on the backend, and we end up with a bunch of different sizes and aspects.. which allow us to do things like this...

Using models from the cloud is just as easy as using them from disk. If anything, it's much easier to use them from the cloud.

There's no subscribing, no downloading, no installing. - all you do is use the model. Everything else is invisible magic.

Here's an example of dragging into Hammer from the Asset Browser...

Here's an example of dragging into Hammer from Chrome...

Here's an example using the popup asset browser...

We originally started building a base set of assets to ship with the game. The idea was that the game would come with a bunch of models and materials for mappers etc to use as a base.

As asset.party developed we decided that this is the wrong way to go about it.  It'd be messy and fragmented. Our content should be present in the same way as all other content. We should be using the same systems as everyone else.

But you might want to load a model from code. Well, that's easy too.

var entity = new ModelEntity(); entity.Model = Cloud.Model( "facepunch.wooden_crate" );

That's how easy it is. You can even use the Url..

var entity = new ModelEntity(); entity.Model = Cloud.Model( "https://asset.party/facepunch/traffic_cone" );

When you publish your game, the model is included just like it was a part of your game. The model will be downloaded automatically when people play your game.

Our goal is to find ways to do things different, better. 

This strategy works  for us because there's a finite amount of data we would want to ship with the game itself. We anticipate many different game types in many different styles.

It also works great because if we create and add a model and no-one uses it, no-one has it sitting on their hard drive, wasting space.