Fiptubat: Character Models

Finally, some character models!

The new character models in the Editor. Right of the screen is a human one; to the left is a patrol bot, and a turret in the background.


The human models are based off WW1-era infrantry, such as these Vickers gunners. They were supposed to have helmets, but that seems to clip with the camera, so I’ve hidden them for now. I may add them back for NPCs to distinguish them from the player-controlled units, and I would like to add some slightly different skins.

The animations are adapted from Kubold’s Pistol AnimSet Pro asset. Integrating this took about two weeks, and along the way I ran into a hilarious rigging bug (shown below). However, it was well worth the price.

I'm pretty sure arms shouldn't look like this...

Player-controlled units still have a few issues:

  • When moving, they’re supposed to point their gun at the ground, but the camera controls override that. I’m not an expert with guns, but that doesn’t strike me as good firearm safety. NPCs obey this fine.
  • The camera movements are influenced by the animations, which makes aiming a little harder. I’ve also had to remove the crosshairs graphic.
  • When climbing, the camera occasionally clips through the scenery. I suppose I could just remove climbing entirely…


These are based off the Swiss MG-11, a derivative of the Maxim gun, converted into a heavy emplaced raygun. If you look closely, you can see handles on the back. I’m not going to implement this, but the idea is that in-universe this would allow them to be manually operated when remote control (inevitably) fails. I’ve also ditched their scan animation entirely. Now they only move/rotate when a target is confirmed.

Patrol Bots

After redesigning the turrets, I decided that a similar aesthetic for the patrol bots made sense. In this case, a Maxim-esque gun with fixed traverse: the gun aims by rotating the body towards the target, with vertical aiming controlled via animation. They’re supposed to visibly hover while moving, but that doesn’t seem to work when they’re aiming. I suspect that’s really a configuration issue with the animator.

Next steps

  1. Add an extraction vehicle. I bought another asset that I’d like to use here.
  2. Expand the level. I was originally going to add a new one,

As usual, you can find it here.

How NOT to calculate lighting for stealth games

My original stealth system for Spamocalypse was based around the navigation system. Each Node has a variable for illumination, which is calculated using raycasts and then baked in. For point, area and spot lights, this is inversely proportional to the distance from that light; for the sun/moon, the value of the sun’s intensity is just added without any processing. When an NPC or the player is trying to check if they can be seen at a player, they query the NavigationMesh to get the closest Node, and then check the illumination of that Node.

What’s the problem?
This is expensive! As I covered in previous post, this causes a performance impact. However, the fix I made for that causes another issue while trying to calculate the effect that street lamps would have on the lighting. They had absolutely no effect – it was possible to stand underneath one, and the NPCs would simply ignore you if there were no other lights around. I suppose I could have rewritten that as a “Refuge In Audacity” thing, where the spammers wouldn’t see you because they wouldn’t believe someone would stand under a street lamp in full view of them…but that’s another game, I think.

The street lamps I have are essentially a long, narrow box which acts as a parent for a point light. When the light was casting rays to check a line of sight to different nodes, it just hit the inside of the collider. So, the next thing I tried was disabling the parent collider for those lights, but I ended up accidentally disabling other scenery colliders. When some other point lights were casting rays around themselves, they ended up hitting points that were outside the navigation mesh, which caused the BuildNavMesh class to throw an exception.

WTF was I thinking?
I just didn’t know of any better way to do this. My first thought was to try using Unity’s LightProbes, but I started Spamocalypse the free version of Unity 4.6, and they weren’t available to free users at the time. I also don’t know if the API for LightProbes allows the intensity to be retrieved as a float, which is what I was looking for. I also had some experience at trying to generate a pathfinding system for my Master’s thesis, so I decided to give that a try, as I knew the general concept would work.

The actual solution
After looking around the Unity forums, I’ve created a physics-based solution that uses trigger colliders and raycasts. Each spot, area and point light has a trigger collider attached, which tracks instances of a CalculateLight component that are inside the collider. If the light has a “line of sight” to that CalculateLight, the light contributes to it’s total intensity. The amount contributed is the intensity of the light, divided by the distance between the light and the object it’s tracking, and at the moment is clamped to a maximum of 1.
There is only ever 1 directional light in a scene, so the Sun component handles this. It has a list of CalculateLight components, and tracks each of them using FixedUpdate. It basically casts a ray to check if the object can be seen, and toggles whether or not it “visible” to the sun/moon. If a CalculateLight component suddenly is in the sun, it’s total intensity is immediately increased by the intensity of the sun, and stays that way until the character can no longer be seen.

Does it work?
Yes, it does. I haven’t done a full test over the City Inbound level yet, but it doesn’t take as long to calculate, and it actually works in real-time – so, I could possibly use this for things like spotlights or torches in future projects. I will update this with the full test results.

Spamocalypse: Respawn mechanism and NPC models

Another update to Spamocalypse. This time, I’ve added a respawn mechanism for the spammers. They will respawn after a 30 second delay, which will remain constant across all difficulties.

My experience of stealth games has mainly been shaped by Thief and Thief 2. In those games, killing people is discouraged – in fact, on expert difficulty killing people is forbidden. On the lower difficulties, it is generally allowed (though Thief 2 has a few missions where it has to be kept to a minimum for the sake of the plot), but it is discouraged by the fact that you have to hide bodies, and that does include removing their blood stains. I don’t have those in Spamocalypse, so I’ve added the respawn mechanism as an alternative to that.

What happens is that when an enemy is killed, the Level Manager will wait thirty seconds and respawn them in the same spot. If this happens too often, they will be come suspicious and start searching around them. The criteria for “too often” will depend on the NPC type – spambots require about 20 deaths to realise that something is wrong, regular spammers will cop on at about 5 deaths, and Moderators will realise this after 3 deaths. In the meantime, other NPCs who find their corpse will trigger an alert.

I also have some NPC models! These haven’t gone into a build yet, as I’ve only just finished the Moderator. However, they are textured and, after following this tutorial, they are animated.

The Spambot/Dumbbot is the stupidest weapon available to the Word of Turscar. It trundles around blaring out Turscarite propaganda (i.e. spamming loudly) and launching cans of spam at anyone who gets in the way. They were designed to be mass-produced and deployed en masse for assaults on target Sites, and have not been programmed to account for Sockpuppet during their sales attempts.

Not very bright, but it doesn't need to be. This is what I imagine spambots look like.
Not very bright, but it doesn’t need to be. This is what I imagine spambots look like.

These two show a regular spammer, which is really just a zombie that vomits spam. Excessive exposure to spam may result in conversion. They can use whatever humanity they have left to identify a Sockpuppet, and will search nearby when they recognise one.

If they’re idle, it’s because they need to take a break. Hence the preference for bots during attacks.

Spammer1 Attacking
Achoo! It’s supposed to be vomiting spam rather than sneezing, but I haven’t got that far yet.

The Order of the Hammer of Moderation is an order that is pledged to protect Sites from Turscarites, Trolls and other degenerates of the Nett. Any Moderator (or Hammerite) that is caught by the Turscarites can expect a long, slow and painful process of conversion. When the process is finished, they are no longer human, and serve the Word of Turscar with the same fanaticism with which they once opposed it. They still retain their abilities, including that of tracing a Sockpuppet’s launch position.

I did originally plan to give them a muzzle-loading air rifle for ranged attacks, or possibly a wheel-lock pistol like in Dishonored, but I decided that would take too much time. Instead, I just went with the hammer.

I art bored, brethren.
Guard duty art tedious, brethren.

To arms, brethren!
To arms, brethren!

So, my artwork isn’t great at the moment. However, the regular spammer and the moderator are the first two humanoid characters I’ve ever animated, so I think they can be excused. 3D modelling of characters was the last major development hurdle for Spamocalypse…at least, until the bugs and Gremlins turn up.