Overview

It took me a while but, here I am… After reading my last (and first) post, I forgot to talk about the biggest problem i have to face during the development of “The Great Heist”: The Guard’s vision and Performance (Yeah… ¬¬). So, let’s begin.

The guards vision

The main issue when the guards where prototyped, giving the user a notion of where the guards where seeing and how far they were seeing (to stay away from their). At first, this wasn’t an issue because once they see the player, they start to run trying to catch the player. But that part of the game didn’t came together and the gameplay change to make more important avoiding them all time (if a guard sees the player, game over).

This create a new problem, “how can I show to the player where and how far the guards can see?”. Fortunately, Unreal Engine have a component so we can create dynamic meshes to solve this problem. The aproach made in this game was making use of Raycasts (or Tracing, more on that here and here) to draw a cone that can be use to represent the guard’s vision.

It’s not hard as it seems, I only need to create a base mesh for the cone, the origin is located at the center of the actor and adjusting how far they can seen, this cone is constructed in a fan way using the runtime procedural mesh, each end point in the cone is determined with Single trace. This also applies to the way the camera display it’s vision.

Performance Issues

Despite this way of draw the vision cone it’s handy, you must take into account th number of traces needed per cone (police and camera) active, and try to no have too many actors active or reduce a little the detail of the cone or the channels to trace against. At least for this game was just good enough.

And this solution was good for the police actors, but, why was used for the cameras too? The first aproach consisted in use a spot light and a invisible cone to detect the player. And it worked nice, with a good enough collision and a really nice and more “natural”, but the project change the target platform from PC to HTML5 (because it as going to be presented in a live event and this allowed me to share just an url in case more people wanted to play it), this came with more penalties, like a mobile rendering and no native binary (it have to be play it in a web browser).

No more than 4 dynamic lights at the same time

Since the renderer used by Unreal for the HTML5 platform it’s ES2, it comes with the limitation of no more than 4 dynamic spotlight sources active at the same time, this apparently applies even if they are not rendered in the screen, if more than 4 are active in the scene, “randomly” only 4 of them are visible. Also, they’re expensive to render, not as expensive compared to a point light, but still expensive.

For this reason the way the vision of cameras are presented were changed, this aproach was cheaper.

Movable vs Static

At some point during the creation of the only level in the game (I’m not a Game Designer xD), I notice that the frame rate of the game was started to decrease with no aparently reason (I didn’t have previous experience with 3D games) as the level came bigger.

In the end, as Epic explains here, there was a difference of how the lights/objects are calculated/threated. Having everything as movable it’s not a good idea, specially with unreal’s ES2 renderer (dynamic lighting was not too optimized), since turns all the lighting/shadows to be dynamic. A better aproach was to use pre-calculated lighting instead. I don’t think that i made use of everything that the engine offers, but this was my first attempt, maybe next time (volumetric volumes, lightmaping, ambient lighting, etc).

Blueprint nativization

Blueprints are awesome, can be used for fast prototiping and due their visual/node programming aproach, can be used by non-programers to implement gameplay code, dynamic actors/components and more. Heck, even if you wanted, you can make a full feature game. But there’s a catch, they’re “slow”. One solution can be converting blueprints to C++ classes and do all the heaving lifting there, but there’s another aproach that can be put to test before going full/partial Cpp… BLueprint nativization, and it’s easy to test it out, check it out here.

Also, here’s a little example of how Nativization (or cpp) can impact your game (it will always deppend of the way you implement features, be careful).

The video: BP vs Nativization vs Cpp