Dev Update: Things Unity Doesn’t Like

While developing Ghostly Apparitions, specifically my push of new features this last month, I have learnt a few things that Unity did not seem to like me doing. These are things that are limitations of the default engine that, while maybe on the higher end there may be solutions, for now I have had to find workarounds for these quirks of the engine.

These are good to examine and stress test now, in the early stages, so I can note these down as thing to consider when working on the final design of Ghostly Apparitions systems.

Rigidbodys and Non-Convex Colliders

Ghostly Apparitions is currently going down a very physics driven route for it’s gameplay. Apparently between Unity 4 to 5, non-convex rigidbodies using mesh colliders have been removed as an option, eliminating easy to make holes and gaps in physic objects.

A workaround is using multiple colliders per special object, from separate parts, to remake the whole shape with the gaps, hole and indents needed, however I can’t say how efficient this is. This means I may have to find some alternatives in the future for things like cupboards, draws, bins and even the gaps under chairs. For now I will lean towards less gaps and holes in my games movable props and simply see how far using multiple colliders can take me.

Animation and Simulation

When animation is applied to any bone on a object it nullifies any physics driven movement on any other bone in its hierarchy. From my research with IKs there may be a way around this but without a special fix if you want, as I did in my example, a rigidbody driven door with animatable handles, it is simpler to have the handles be a separate rig childed to the door.

With that in mind I will probably make a base rig for all handle like objects in my game with a interchangeable mesh, since I will have to separate them from the doors anyway this will save time on setup.

Humanoid Rig, Ik Handles and Scaling Animation

The character models in my game are made for cartoon like expression and movement and have multiple parts in their rigs for classic squash and stretch animation. In the future I want the post 2017 AIs in Ghostly Apparitions to use IK handles to interact directly with props in game.

However Unity’s humanoid rig, it’s only built in route to IK handles, cancels out all scale driven animation in the entire rig. Luckily using some of the community built alternatives for Ik handles don’t seem to have this same quirk, so with a bit of research my specific animation needs should be fine, however I will not be able to use unity’s built in system.

While not much hopefully this may be useful for anyone who is doing similar work on the unity engine, as development continues I will be sure to post the specific solutions for any particularly problems I have as work goes on.

Dev Update: Things Unity Doesn’t Like

StealthAI_V4 – Plan


During version 4 I will be looking to add additional features during the patrols and in making sure it’s detection and investigation modes are working properly at all times. The specifics of this are:

  • Stationary patrollers.
  • Patrol schedules(for in syce routes between multiple patrollers).
  • The ability to hear the player if they are running nearby.
  • Different wait points and behaviours at waypoints, these include.
    • Specific facing direction when entering an idle waypoint.
    • Options to Look around or stand idle at idle waypoints.

In preparation I have researched for reference points for different architectures for scripting video game AIs. During this iteration I will be experimenting with these different methods while trying to put together a script that will work for the prototype.

StealthAI_V4 – Plan

Prototype 02 – Review


Prototype 002, above, now shows a very basic version of the game but with all essential features present, along with an actual example of a puzzle/challenge scenario. For the next prototype, prototype 003, I will aim to refine on the systems that need it, based on what I learnt from making this level, and then attempt to make a level that not only functions, but demonstrates, at the least, the basic starting points for the kind of situations and puzzles the design of my game will focus on.

Prototype 02 – Review

New Camera System Version 2 – Review


Multiple tracks can be used in the same area, or added in at a later date if a area needs revisions.

Features added to the new camera system are:

  • Groups
  • Updated camera Rig and spline tracker
  • Modifiers that can adjust the ease in and out values between the reference/player spline) and the camera splines
  • Various options for removing, and adding points in preexisting splines.


A example of a complex intersection

These new features now make the spline rig usable in bigger environments that have need of complex sets of tracks, rather than just one.

New Camera System Version 2 – Review

Prototype 002 – Miscellaneous Features, Carry and Basic door And Button

Robot Carry


A simple feature, and equivalent to the shadow entity’s push ability, the robot avatar can now carry objects back and forth.

Basic Door And Button

A basic button that, when detecting a valid trigger collider, sets an intermediate script, called “TiggerState” to true. A door script then references this immediate script and will set the door object as active or false appropriately.


I use an intermediate script for now because, during prototyping, it is convenient to have a script any kind of output or input script can communicate with and is useful for future additions.

Prototype 002 – Miscellaneous Features, Carry and Basic door And Button

Lighthouse AI V2 – Version 2 Review

While by no means perfect the AI patroller version 2 patrols, detects and chases when it should in my scene. Along with the aforementioned changes I also tweaked its vision cone a bit and it now works as a viable obstacle.

Profile performance


I have never used the profiler before in Unity and decided to check it out for my scene, I was surprised to find the AI was taking up the most memory space. After researching online I discovered this was due to how many Debug.Log events I had left in the code, once I commented them out the AI overhead went down. It’s a small thing but it’s good to know how i’m supposed to use debug.logs(sparingly), and I will make sure to clean them up in final codes in the future.

Lighthouse AI V2 – Version 2 Review

Toasty – Combining features


After getting all my prototyped features into one project, I must now work on changing them form self contained, isolated systems to interconnect and interactive ones. Alongside this I need to develop features that proof of concept was done, but practical features were not.

3rd Person Robot Avatar


When I initially did the animation for the robot avatar I attempted to make it seem weighty and slightly clumsy. Playing it now I seemed to have gone too far in that direction, it’s animations and scripting will need to be refined at some point in the future. Though while clunky it still works well enough to test with, I will leave reworking it to later in the project.

Shadow Movement


While how the shadow avatar would navigate changing surfaces was figured out in it’s prototype it lacks most of the features to make it a playable player avatar and will need the most new features added at this state. However most of the features it’s missing are relatively simple so it shouldn’t take too much time to complete.

AI Patroller


The AI brain seems to be stable, for now all it needs to  work with other features in the game is an intractable object to trigger it’s sound investigation function.

The Camera Rail


The camera system is perfectly functional for what I need it to do for now.

Room Editing Kits


As state earlier the room editing kits are considered low priority for now, they probably won’t be looked at until the other features of the game are have neared completion.

Toasty – Combining features