Valve works with an asset system where your directory layout is like this:

mygame/game/mymod/<compiled content>

mygame/content/mymod/<uncompiled content>

So you have a game folder and a content folder. All uncompiled content goes in content, and is compiled and goes in game. This doesn't feel that logical to me, when creating addons etc. I want to keep the compiled and uncompiled shit in the same folder - I think that's what people using source control will want.

So I changed it to work like this

When you're making an addon you have a content folder. This is what you ship with your game, it contains all the compiled stuff.

Then you have a content_src folder - it contains all your source materials, your fbx files, your raw psd/tga/png textures.

Getting all this done meant I could port over some Tub/Rust assets to test it out.

Over the last couple of days I've been experimenting with skeletons and ragdolls. Binding up the ability to get and set their bones.

I was pleasantly surprised how easy it was to do. I don't know if the code is better or if I just understand more 15 years after GMod, but it feels great and performs great. It feels like I can do anything in this engine right now.

In all the time I worked on Source 1 I don't think I imported a model more than a couple of times. It was hard work. This is probably why GMod only has a handful of actual original models.

ModelDoc makes that all look stupid. With ModelDoc you can build a model by importing the raw fbx (of whatever) files, add animations (from fbx or whatever), add material groups, assign materials to each mesh, build LODs, define the physics hulls, the collision bounds, the body groups, ragdoll setup, add new bones, delete old bones, define hitboxes. And more importantly - you can do it all without editing a single text file or running bat files.

So when I started to explore this and see how many problems it solved for us I knew we had to change plans and use this system. It makes importing and setting models up a billion times easier than anything we could have done.

It does everything we wanted to do. You stick your fbx file there and it converts it to a vmdl. If you edit the fbx, it updates and hotloads the model in game automatically. If you edit the model in modeldoc, it hotload the model in game automatically. It ticks every box.

We tested out networking too - and am happy to report that it works.

It uses SteamNetworking now. This has the massively huge benefit that you can join servers via SteamId now.

Why is that a massive benefit? Because you don't need to reveal your IP address and you don't need to open your firewall.

You can just start a game and people will be able to join. Like it should be.

I wrote a camera system up. Here's the wiki page with some code. The idea is that all the information on how to set up a camera right before render is in the Camera class. 

You can make different camera classes for different view modes, for example a FirstPerson mode and a ThirdPerson mode. So switching camera mode is just a case of setting the player's Camera class to one of these modes.

The above demonstrates three camera modes. Third person, First Person and a DevCam mode (in which you can move around freely, even when paused). 

The code for the DevCam is here.

One month ago, at the end of the last blog, I'd just got the basics working. The game started and it showed some UI. There were lots of unknowns, lots of work ahead.

A lot of those unknowns are now knowns. A lot of progress has been made.

In Source 2 you don't even need a special entity. It's just a model.

I set this model to be ragdoll-able in 20 mins, I probably didn't do a great job but it's a working ragdoll.

I know I should be comparing Source 2 to Unity and UE, but I can't help it, look at how you set up a ragdoll in Source 1.

With this huge problem solved it was time to start stretching in the other direction.  Exposing stuff to the c# side so they could be used by gamemodes and addons.

Things like particle effects, traces, sound events, player models, health, dying, respawning, decals.

Animation is another huge leap forward for Source 2. No longer is the animation controller a 2,000 line cpp file with a ton of stuff you don't understand. 

Now it's a nice animgraph with parameters. 

And all your code needs to do is set those parameters. The anim-graph itself goes deeper than just blending between animation sequences. It can control a bunch of IK stuff and a bunch more stuff I don't understand yet.

Oh and guess what, you can edit your fbx animations while playing the game and it'll hotload and play the changed animations!

I'm purposefully trying not to paste code in this blog so check it out here.

I know this isn't what this is meant to be about, but I'm having so much fun with this right now. In the the last couple of weeks everything seems to have come together. Every morning I can't wait to get up and get back in this chair.

I might start doing blogs more regular, maybe every week like the old days.

I did a lot of work with player controllers. You can read more about what a player controller is via that wiki link. The TLDR is that it's what moves the player.

The default PlayerWalkController I've made I've kept it 1:1 with Source's Player Controller. I want it to feel exactly the same.

We didn't know what we were going to do about loading models and textures. I spent some time getting it so I could load materials from our own formats. The idea was that instead of using all Valve's formats, we'd load raw formats like png/tga/jpg for textures, fbx and whatever else for models. This is what we did in the UE version and we were comfortable with that.

Then I discovered ModelDoc and everything changed.