WIP: Wednesday Thursday

I’ve been working on a few items, the most recent of which has been lootable chests that have open and close animations and audio.  The animations and audio part are not something I have a lot of experience with, but the chest is thankfully fairly simple.

Right now I’ve defined a very specific Chest Controller, though I suspect I will transform this into a Usable Object Controller that will take an enum of it’s usability type (for environmental objects) like open/close, on/off, pick or gather (for reagents) and the like.  The video above is super simple, and is still a WIP.

Currently, the player will interact simultaneously with every interactable object within a radius.  The next step is to raycast or use a hidden collider to find the object most centered in front of the player and prevent interactions with objects behind the player.

It’s a start.

Work in Progress – 2017/10/17

A lot of core work on the project has been done over the past couple of weeks – and by core I mean behind the scenes.  Yeah, I say that a lot and rarely have something new to show, and this is one of those times.

However, as an independent developer, that’s how a lot of this process goes. I fixed the helium filled GelCube issue, and they seem to be functioning fairly well on their NavMesh.  Part of this was competing systems causing race conditions.  I toyed with the idea of using physics to drive them, disabling some of the Unity AI stuff, but that led me into a rabbit hole that I wasn’t in the mood to contend with.  Instead, I resolved the conflicts and they are now pathing along as they should.

I also added a physics material for them.  They’re made out of ice, and should slide around a bit more than other GelCubes and mobs in the game.  I’m also testing a fun bit where they may have items from their biome shoved inside them…  I mean, they’re likely to pick things up as they move about and grow, right?  I’m hoping this is a small detail that is cool in the long run.  We shall see.

I’ve started setting realistic masses for Rigidbodies as well.  The player has a mass of 81kg, and a full sized GelCube has a mass of 5444kg (who knew they were so heavy, but it does make sense).

Otherwise it’s been more boring: some maintenance to remove old assets that are no longer in play, some scripting for torches, creating static materials from SBSARs now that I have the walls and floors in a good place.  Oh, and modifying the Dungeon Architect DungeonRuntimeNavigation.cs file to support multiple meshes for multiple agents.  If you use DA and are interested, you can grab that here.

DungeonRuntimeNavigation Inspector
DungeonRuntimeNavigation Inspector

Basically you use an int[] to specify the NavAgentIDs that all your mobs will use and it builds all of their meshes and navigation data at the same time.  I know I’m not the only one who wondered for a while why I couldn’t use other NavMeshAgents in my Unity project.

How To See Your Player… Making Walls Transparent

Over the past several months working on the Dungeon theme for Labyrintheer, I’ve changed my camera angle several times.  I keep moving it higher to prevent walls and such from occluding the player, but I’m never happy with such an oblique view.  So, over the past few days I’ve been looking at options to make walls transparent when they are between the player and the camera.

Some solutions simply disable the geometry.  This isn’t acceptable for my game, and I suspect for many.  You could accidentally walk backwards out of the playable area, or an errant AI could take a bad turn during it’s pathing and fall off the world.  Plus, disabling geometry just doesn’t seem like an elegant solution.  My primary goal (and I’m still working on it) is to use a shader for this directly, though that seems like it has some major pitfalls (how do you tell a shader about an object other than the one that it’s drawing?).

So, for now I’m cheating with a very small amount of code and an extra material for objects that I want to hide.

Basically, I’ve duplicated the four wall materials I have, and the duplicate materials use transparency with an alpha value of 100.

My player controller script now calculates it’s distance from the camera every frame (though I think this might be able to be done once in Awake() since the distance should be fairly static), like this:

     void Update ()
     {
         GetInput();
         ProcessInput();
 
         distanceSquared = (transform.position - Camera.main.transform.position).sqrMagnitude;
     }
 
     public float Dist()
     {
         return distanceSquared
     }

Then created a script to go on the walls (or any object that needs to be transparent to prevent occlusion), as such:

TransMaterialSwap.cs

 using UnityEngine;
 
 public class TransMaterialSwap : MonoBehaviour {
 
     public Material _original;
     public Material _transparent;
     private GameObject player;
     private playerController pC;
     private Renderer rend;
 
     void Start()
     {
         player = GameObject.FindWithTag("Player");
         pC = player.GetComponent<playerController>();
         rend = this.GetComponent<Renderer>();
     }
 
     void Update()
     {
         if ((transform.position - Camera.main.transform.position).sqrMagnitude < pC.Dist())
         {
             rend.material = _transparent;
         }
         else
         {
             rend.material = _original;
         }
     }
 }

In the inspector I set both the original material and the transparent material.  If the object is between the camera and the player, it switches the object’s material to the transparent material.  It looks like this:

There are a few issues here.  First, I still need to profile this to see if the solution gives my runtime performance a hit.  I don’t suspect it’ll be TOO bad, but it doesn’t hurt to check, especially with larger maps.  I may look into options to only run the check if the object is visible to the camera rather than always checking on Update(), every frame for every wall.  The other issue is that by making it transparent, light comes through.  I’m not sure how big an issue this will be – it’ll require some play testing.  But it may be an issue in some situations.

Lastly, as I said, I really do want to attempt this in a shader.  I figure it’s a good method to learn shader programming, even if exactly what I want isn’t possible.