While messing with surface properties I was struggling to make things bouncy. If I wanted to make a ball super bouncy I could increase the elasticity, but if it hit something else that was bouncy it would fire off at a million miles an hour.

I managed to tweak the way the elasticity property works to make things work how we want. I don't know whether this is physically accurate, but it lets us make bouncy shit.

As you can see, with 100% elasticity it's never going to stop bouncing. Not really realistic, but it's there if you need it, and doesn't really spazz out.

There's a lot of times in code you need to check whether you're in water and do something different. For this reason I wanted to get this done as soon as possible so we didn't have to go around changing a ton of code after we added it.

Physics stuff has to interact with water differently, some stuff has to float, some stuff has to sink, all the movement needs to be dampened. 

Bullets need to hit the surface of the water and carry on travelling. Bullets usually act differently underwater.

Players need to move differently underwater. They need to be able to swim. Their view needs a bunch of post processing and fog, the sound output needs to be more muffled.

Source2 doesn't have any of this stuff so we're starting from scratch. I got the important stuff done this month. There's still a lot of stuff to do but I didn't want to spend a whole month making perfect water.

For performance reasons decals were kind of hard coded and kind of hard to make work in the moddable way we wanted. This month I came up with a way to make them a bit more modular and worked out the API to place them.

So now decals are defined as loose files, like materials. They can have multiple textures and you can define obvious shit like their size and rotation etc.

I got basic car physics working. It works by tracing down at the wheels and applying spring forces for the suspension. I can then apply forces to the body to drive it around. I ported over the modular car assets from rust. It's not perfect but it's an attempt of many. This is all in C# at the addon level so you'll be able to make your own vehicle physics.

Flying drone from Rust, just applying forces to the rigid body, super simple.

There's no nice way right now to pilot vehicles so that's something we're going to work on.

A bound a bunch of noise functions and I wanted to see what they did, so I made a quick entity to visualize it. This is pretty useless to everyone but it looked cool so here it is.

I did some exploratory work with the NavMesh stuff, making sure we can use it. Good news is - we can. 

The majority of the nav pathing stuff is tied to the c++ engine npc ai entity base, which we don't want to use, but the nav mesh stuff is mostly abstracted. This works for our approach, since we want to bind the bare basics and code as much as possible in c#.

Surface properties let us define which particles should spawn when a bullet hits a certain surface.

The three things above are Custom Assets. You can define these things yourself.

Here's sound.asset.

It's a fgd file which defines the data structure. This makes it so you can create and edit stuff in the asset editor.

Then in your addon code you create a matching class like this:

And you're done. You can use them like any other asset and they're hotloaded automatically.

They get integrated in the Source 2 asset system too, so it all feels like a part of the engine.

This started off as an editor for just decals, but I figured that this data is generic and lightweight enough that we should treat it that way and try to make one editor that works for a bunch of stuff.. that way any effort that goes into improving that one editor improves the workflow of a ton of things.. so it's more likely to happen.

Similar to Decals, sounds were stored in a modder unfriendly way. They're now loose .sound files and are editable in the same way.

We've got some work to do to make this UI less shitty, but you get the idea. You can create and edit them while the game is running and they're hot-loaded as you'd expect.

These sounds also show up all over the editor too, so when you have to select a sound in Hammer or ModelDoc - they're there.

It's not perfect but it's a plausible solution for players, artists don't have to worry about configuring this.

Surface properties were also stored in a bit of a modder unfriendly way. They had a awesome editor but they were all defined in one big file. Which isn't great for us.

So now we define surface properties in loose .surface files, like this.

When you do a trace in game you'll get the surface hit, which will give you all the information above. For example, to play a footstep sound

DoFootstep is an extension and lives in addon code. We put it in addon code so you can see what it does and do something else if you don't like it.

I used hammer quite a bit this week and I could feel all the old pathways in my brain get reconnected as I started to use hotkeys I never consciously remembered. 

I ran into a few problems (mostly fixing stuff that I broke) but I added a couple of new things.

Our C# entities can now get key values from the map. To do this you just mark one of your properties with [HammerProp], and it'll automatically get set when the entity is created by the map.

That'd be useless without adding your addon's entities to Hammer though.. so now you can put a fgd in your addon's config/ folder and your custom entity definitions will be available!

The tools are a huge step up from Source1 but I'm sure there are lots more QOL improvements we can add to make them even better. 

Here's some changes that made our lives easier this month.

I've been working through a deathmatch gamemode, adding new weapons and working out what else needs to be done. The end goal for this is to be playable to be a good test for the whole gamemode addon system.

I've got the code on Github. I'm trying to develop it as a regular developer, to find and fix any rough edges with that process.

For every one thing I manage to cross of my list, I find 3 more to add to it. But it's making good progress, even though the deathmatch mode itself doesn't seem to be moving forward, it's moving everything else forward around it.

It feels like it's been a short month, doesn't feel like I got a lot done. But when I think that a month ago we had no surface properties, no footsteps, no impact effects, no physics sounds, no water.. it feels pretty productive.

It'd be really useful to get a Level Designer or two. I love messing about with Hammer, and I could easily lose a week messing about with it.. but it'd be even better to pay someone to lose a week for me. If you have experience in Source and ideally Source 2 - please apply for a job. We're flexible - remote work, part time, talk to us.

We only have one animator at Facepunch. If you're an animator and especially if you've animated in source/source2 and understand the difference between a world model and a view model - please apply for a job. We're flexible - remote work, part time, talk to us.

We could probably give dev access to a few modders now. The main thing stopping me is that right now I'm really enjoying the pace and working on what needs to get worked on. 

I worry that if we invite people there's gonna be a shift of priorities and I'm going to have to rush and half arse a bunch of stuff to cater for it. Lets see though.

See you next month ?