Project Breach #2 - "Combat, New visuals & Pawn UI"

 Project Breach #2
"Combat, New visuals, Pawn UI"

Combat

The new combat system has been one of the more detailed & complex of any I've written before, and it's all fully adjustable by mods.

Combat/Ranged

I added ranged combat which includes anything that uses projectiles. This is guns sure but also with mods you could make it anything. Crossbow, Taser, Magic staff, anything that uses a projectile.

To make sure the combat was all working correctly, I made multiple gun types.

(GIF playback is slightly slow so actual gameplay is approximately 10~20% faster)

AK47 (Assault Rifle)

FN Minimi (LMG)

M4A1 (Assault Rifle)

M1911 (Pistol)

MAC-11 (SMG)

Mossberg 590 (Shotgun)

For fully automatic weapons I found that burst fire (Where the pawn shoots X times, waits, then does it again) has been the best for balancing. For example, with an AK47 pawns will shoot 3 times, wait, then do it again. Along with this system is a "Continued shots" accuracy variable, which lets me make so the first shot of a burst is more accurate than all the shots afterward. I think this is more realistic and simulates how one might react with a continuously fired weapon.

Along with this, pawns have ammo and they can run out. In the mod file it is adjustable if the weapon uses ammo whatsoever. How much a pawn can hold of each ammo type is adjustable in the ammo file. How much a weapon can hold per mag is adjustable in the weapon file.

Here's what a weapon file looks like:

Here's what an ammo file looks like:

As a side note, pawns also receive an accuracy penalty for moving & for running (although you can't order pawns to run just yet). Here's what a pawn file looks like:

Combat/Surfaces

Game surfaces can now be defined (things like if a wall is wood, metal, etc.). In the future this will great for things like special impact & sound effects when a surface is hit by a projectile. But right now it's helpful because on projectile file you can define surface penetration. This means you can say that certain projectiles go through certain surfaces. You can even define the chance of the projectile going through, as well as if the projectile should get a damage penalty for doing so.

Here's what it looks like when I place a pawn in front of a wood wall, watch how all their bullets pass through it:

Now here's what it looks like to have a pawn behind that wood wall, watch how he takes less damage from the shots because they've passed through the wall:

Certain surfaces can also define if pawns can see through them or not. So for example this window is a wall with a surface type of 'glass'. Watch how when I order a pawn to walk past it, the two pawns see each other and begin to fire:

(Note that in the future, glass will shatter lol)

Here's what a game surface file looks like:

And here's how easy it is to change what surface type a wall is:

So with all of these systems in place, you can see combat can be pretty interesting!

New Visuals

You probably already noticed that this is a new map layout and that the map looks much nicer.

This is because I'd hired an artist to help create a few textures for me as a good starting place. I likely won't be able to afford to have an artist do most of the art in the project, so having a good place for me to start to do it myself is nice. The grass is just a placeholder.

You've also already seen in multiple screenshots that there's new pawn textures. A terrorist texture & a SWAT texture. These also aren't final, just something I made real fast for testing, but a good starting place.

The game is also now using some basic post processing which does nice things like slightly increase contrast & saturation as well as add bloom. It's not meant to completely change how things work, just add a nice layer of polish on top.

There's also a slight 'glow' to projectiles. This can be turned on & off in the projectile file with a variable called "Use Tracer Lighting". Here's what a projectile file looks like:

And finally, I've added blood to pawns. This system is meant to serve more of a gameplay purpose than a visual one. For the first 15 seconds that a pawn has taken damage they will leave blood whenever they move. This means that if you run away from a fight, you have to keep in mind that you'll leave a blood trail for the first 15 seconds. I can't wait to see what strategies develop as a result of this mechanic!

Pawn UI

Friendly pawns (Those you own & those on your team) now display how much health they have below them. This on its own is a nice touch but the system I'm more excited for is pawn dialogue.

Pawn dialogue is one of those ideas I just had randomly and was immediately excited to implement. It's text above the pawns head but I think it adds to the game overall. What I like about it is that it changes depending on the pawns circumstances.

So, if your pawn has been sitting around for awhile doing nothing he might give off a random bit of dialogue:

But if he's been injured, that dialogue might not be so friendly:

He'll also let you know that he's taken hits:

And when he's doing important actions:

(If you're wondering why you didn't see this in any of the previous GIFs/Screenshots, it's because I had it disabled for all of those so that you would see it here)

It's one of those mechanics you don't even think about when playing a game, but that can be great to communicate things to the player. I enjoyed working on it & coming up with things for the pawn to say. These dialogues only show for friendly pawns so that enemy pawns don't give away their position.

Other noteworthy changes

-Fixed bug where you could see an enemy pawn's orders if you have them selected

-Made so the interact menu shows the display name of whatever it is you're interacting with

-Converted entire project to use new ID system (unsigned integers instead of strings)

-Made new map because the new ID system broke old saves

Summary

Wow, this was a lot to cover! 22 images/gifs in total. But when you're adding such major systems like combat for the first time, it's to be expected. With combat now in place and especially with these new textures, the game is feeling a lot better than it did last week.

Right from the beginning of the project I've been working toward a list I call "Demo Essentials" which are the minimum number of things I want in the game in order to have a proper demo / beta test. From now on every update will include this list and how far I am into it.

And also for fun, I'm going to have a "Lines of code written" counter in every update so you can track how much programming has been done as the game goes on.

 Thanks for reading, feel free to leave a comment or some feedback, and I'll see you in the next one!

-Blake Gillman

(Join the Discord: https://discord.gg/ArEbAut)

Technical notes/extras for those interested

>Lines of code written:

17,049 lines / 204 scripts.

(For reference, the project was at 13,000 lines of code when I made the first blog post about it on March 9th)

>"Demo Essentials" checklist:

• 3~4 cover objects
• Breach charge that goes through wood
• (Done) Pawns
• (Done) Biome Editor
• Lobby UI
• Squad Customization
• (Done) Interactables System
• (Done) Health System
• (Done) Map Editor
• (Done) Ranged Weapons (LMG, SMG, Shotgun, Semi Rifle, Auto Rifle, Pistol)
• Melee Weapons (Knife, Baton)
• Map Entry Vehicle / Spawn
• Loading Screen
• Fog of War System
• Main Menu
• 1 decent map
• Player UI
• Most things have some sort of SFX

>Why change the ID system to use numbers instead of characters?

It was primarily a concern about data usage. Originally the project used strings (characters) for object ID's because I wanted it to be easy to avoid mod conflicts. The plan was an object would just have your mod name abbreviated followed by the objects actual name, such as "DEF/Tree A" (DEF for 'default'). The problem is that strings use up a lot of memory. This wasn't a problem at first for the project when it was just an engine that I didn't have any specific plans for, but when the game turned multiplayer and I started programming syncing things over the network I realized just how much more data on the server it'd end up using.

The formula for calculating how much memory a string will use is: 20 + (n/2) * 4 bytes.

Syncing the name "DEF/Tree A" would take up 40 bytes. Whereas syncing an unsigned integer uses 4 bytes. Literally 10x less memory. Now when it's just a measurement of bytes and not even kilobytes or megabytes you might think it doesn't make that much of a difference.

But take for example projectiles which players need to know what type of projectile was fired whenever one is created. Forget syncing any other data for a moment and assume all we need to do is sync the ID of the projectile. If it used up 40 bytes of data, and the gun has a 30 round clip, that means it'd take 1,200 bytes of data per magazine or 1.17kb of data. Now instead if we use an unsigned integer (number) which only uses 4 bytes of data, and we fire that same clip, it'd use only 120 bytes of data per magazine or 0.11kb of data. You can see now why this was worth doing for a multiplayer game.

The only downside to this new system is that mod developers will have a slightly harder time avoiding mod conflicts. To avoid conflicting ID's in my own system I start each new category at a different number. So weapons I make start at 800 and then go 801, 802, etc. Blocks start at 1, Ammo at 700, etc. So I recommend mod developers do a similar system but with a starting point. For example, 4,120,000. Then every weapon ID starts at 4,120,100. Every ammo at 4,120,200, etc. The good news is that an unsigned integer can support as high as 4 billion so there are plenty of places to start, and to move to if your mod conflicts with another.

>Health bar color distribution

I found blending between different colors depending on how much health a pawn had felt wrong. I don't know why, and this isn't very technical but instead of smoothly blending I found that snapping to colors based off of how much health the pawn had felt better. In my opinion, it gave a more immediate sense of what level of danger the pawn was in regarding its health. Ambiguity was created when blending "Is that more red or orange?" which was counter-productive to having a color indication.

The exact values are:

Green - greater than 60%

Yellow - 60% or lower

Orange - 42% or lower

Red - 23% or lower

This is controlled by an easily adjustable gradient: