Game Editing > General Content Creation

[Unity] Fantasy asset pack prefabs

<< < (3/6) > >>

ratty redemption [RIP]:

one of main the reasons why i wanted to write my own trigger system, albeit using one of the built in unity physics functions, was to reduce the amount of function calls. especially to the target scripts.

although my trigger manager script does read and write a lot to it's data scripts, the latter only contain a few lines of code each. so in theory this system when finished could be faster than the unity built in function "on trigger stay", possibly also the "on trigger enter" and "on trigger exit".

in the 1st image we see my trigger data script for a lever object has been set to use "activation auto". which would normally be used for  doors that don't require manual activation, other than the player or npc's walking up to them. i was just testing using the lever, but it could have been any object that can be triggered.



keep in mind, the unity debug logs printed in the console window, do significantly slow down the game, so most of the time we'd have them disabled. with that being said there is only a couple of function calls from my trigger manager to my lever manager, and that was due to me moving the player in and out of the trigger volume, which the data script is attached to.

compare that to the much higher "fast update index" and "collider count" logs, which are keeping track of all the dynamic collider objects inside the trigger volumes. in this case just the player, but could be lots of objects inside several different volumes, which the manager cycles through when it does it's fast or slow update.

to clarify, this system acts like the built in "on trigger stay", except it only calls the target scripts once per "enter" and "exit".

in practice, if this was an auto activated door, it would open when the player walks up to it, ie enters a trigger volume. then the door would stay open until the player had left the trigger volume, on the other side.

my trigger data scripts can also be set to "use once" in which case the manager removes them from the game after the "enter" event, so frees up some memory and cpu.

the 2nd image is similar to the previous test, except the data script is set to manual activation. that can only call the target script when a player is inside the trigger volume and using a "activate" key input.



there is a short timer delay between those function calls so the player can't keep spamming the input. in the future, i might make the delay an inspector variable, so level designers can choose their own values. but for now having a delay of about 1 second seems to work well. if there was no delay, then there could be 30 or 60 functions calls a second to the target script if the player held down their activation key. which would be a waste of resources, and eventually slow down the game.

ratty redemption [RIP]:
these images show two of kat's lever models made in blender, and being animated in unity by my lever manager script. my inspector variable "end angle x" is used in the 2nd image to limit the range the lever can rotate, so it doesn't pass through it's base.

ratty redemption [RIP]:

after a lot of experimenting over the last couple of weeks, i've nearly finished the lever manager. the following post is related more to the code than level design...

1st image is the whole of my lever data script. these would be attached to each of the lever prefabs.



level designers could replace the meshes and textures with different versions if they wanted, as long as the prefabs followed the hierarchical structure of the ones that i'll be releasing, hopefully in the near future. alternatively coders could edit the scripts to suit their own designs.

lines 17-20 are what we're focusing on here, as they are used to store the reference to the prefab's pivot, the start and end rotations, as well as the target rotation. the latter toggles between start and end when the lever reaches the target rotation.

2nd image is part of my start function of the lever manager script. the various managers are attached to an empty game object in the root of the scene's hierarchy window. there is only one manager of each type.



lines 89-92 are assigning the initial values to the data script's variables. the most important, and difficult for me to figure out, was line 91. which is the end rotation.

to my surprise, that line didn't require at this stage, any reference to the pivot. instead it's using my inspector variable "end angle x", which defaults to 90 degrees. it also references the vertical "y" axis of the prefab parent, ie the lever base.

3rd image is part of the "fixed update" function (ie physics update) of the manager script.



line 126 is interpolating between the current rotation (taken from the pivot each frame) and the target rotation.

i was surprised by how high the "250" value ended up being, as that determines speed per second. normally i move or rotate objects with values between 5-25. i guess it has something to do with converting that value to degrees, but it's still weird looking. any less and it was moving too slow in my opinion.

that value could be exposed in the inspector for the lever designers, but for now i'm leaving it hard coded.

another thing which i'm still trying to comprehend, is the beginning of that line has "leverData.pivot.rotation = " which means it's not just storing the interpolated value in the data script, but also apparently applying it to the actual pivot, rather than a reference to it. i assume this has something to do with "reference types vs value types" although admittedly i'm not good at distinguishing the former.

in the past i would have done those separately. it was actually a typo that i wrote it like this, but it produced good results so i kept it.

...

a longer version of the lever manager script that i got working a couple of days ago, took a slightly different approach. in that instead of interpolating between start and end quaternions, i broke it down to interpolating a "current angle x" floating point variable, similar to the "end angle x" previously mentioned.

i then used a built in quaternion function to construct the current rotation from the "x, y, z" and applied that to the pivot.

the reason i had tried that was i wanted more control over each frame. so in effect constraining the "y" and "z" axis so there was no unwanted drift on them. turns out i didn't need to do that but it's good to know we can if need be.

in summery, it was a lot of hard work to get the levers to behave as i wanted, although i learned several very useful things in the process... there's even a couple of interpolate functions that i tested, that have acceleration and deceleration in their movement. in the end, i opted for a constant speed for these levers as that seemed more natural.

ratty redemption [RIP]:
forgot to mention, this type of code can also be used for tanks or turrets where the parent object is rotated in one direction and the child object faces another.

i'm currently working on the door manager, which will switch between sliding and rotating doors, depending on the door data scripts.

ratty redemption [RIP]:
this image shows a test room i built with 25 of kat's lever models. i didn't notice any drop in fps while they were moving, which surprised me.

take into consideration there is only one invisible trigger, and one real time light, which doesn't cast shadows. so this was really to test if the scripting and animating geometry was expensive.

if we had shadows on or more lights, it would slow down to some degree.

Navigation

[0] Message Index

[#] Next page

[*] Previous page