Automatic vs. Relative mechanics

Automatic vs. Relative mechanics

In recent years I have become much more aware of the implications of bad design and in effect a lot of efficiency problems that co-inside with these errors. A couple of examples that I have created, stem from:

- Spawning multiple new objects in succession. Which has a great call cost on the processor, which reduces frame rate and creates lag. With some reflection on my previously made questionnaire, some if not most, do not appreciate this as it deters them from continuing, due to the worry of experiencing it again.

- Having mechanics running on tick / on looping timers. Again although you aren't spawning a new object, the mechanic is checking every frame for some verification. Rather than having a failsafe where if the player would leave an "interact area" on that particular mechanic, it would stop checking until the player has re-entered the area. Similar to 'On component Begin Overlap / End Overlap' that you can find as a native node within the UE4 engine.

Although only recently, I have figured out a way in which I can create a system that supports both relative and automatic mechanics. As I have found it is a requirement when creating some systems that it is imperative that some of your mechanics do need, to run on frame, but more importantly we also have to make sure that this doesn't affect our users experience, by creating lag or any unforeseen bugs.

As I have written previously about how I managed to handle timers within UE4, by using them to create timed switches, I realised that if I am able to turn these timers into my automatic system. By creating a new collision I then used the same 'On/End Overlap' to pause and play the timer in order for the mechanic to be turned on and off autonomously, which in practice has certainly improved performance, before the problem happens.

An example of this problem happening/being resolved - from my own project, we can see in the video above that after the player enters the collision the object will trace constantly until the volume is then exited, but if you continue, you can see it in full effect when multiple objects are tracing for the character, now imagine if this was increasing exponentially it could potentially have a massive call on your processor which in turn could cause the game to freeze/lag. Now this was enhanced so that you can see the effect, but as designers we are also required, to put in these clamps and parameters in order to avoid anything unnecessary so that our user can experience our projects to the fullest.

So it is certainly wise, when constructing with timers to be aware that in order to keep our call count down, that you are able to un/pause them in order to keep ouy games running smoothly.