Production Analysis: Technical Considerations

During the production of Dead Time, I had to take into account multiple technical considerations and encountered numerous challenges during the production process; one of the largest challenges was making sure the game worked on a variety of user’s machines, and as such I had to make a compromise between visual quality and optimization. Thankfully, Unity provides plenty of guidance in their online manual, but I am aware of many techniques to maximise compatibility and performance, which I will provide an overview of below. The two most significant areas for optimisation were the graphics and the programming behind the game.



The general aim when it comes to graphics is to set a target for what kind of visual style and fidelity you want to achieve, then get as close to that target as you can whilst being as efficient with texture resolution, polygon count (the number of ‘surfaces’ or ‘faces’ that make up the 3D shape of each object) and the methods with which you light your levels, amongst other aspects; again, unity provides valuable documentation on this subject, and game artists should be aware of the performance thresholds and commonly held methodology behind the art of different types of games – for example, when 3D modelling one should minimise the number of polygons on background objects (saving performance) as they are less likely to be seen in detail, while adding enough polygons to more significant objects such as characters. As my game’s target platform is the web, I must keep file sizes down so that my game can be loaded in a reasonable amount of time, but also provide graphical settings (practically an expectation nowadays) so that people with less powerful machines can tone down the visual detail and achieve a desirable framerate. Thankfully, even the mid-range computers nowadays are powerful enough to display many thousands of polygons and handle intensive post-processing effects, making my job as an artist more forgiving, but in turn provides more artistic freedom.



As with graphics, ensuring that one’s programming is optimised comes with experience and the knowledge of how to build as efficient a system as possible – that is, ensuring that the purpose of one’s programming is met as fast as possible and with the smallest possible memory footprint – instead of art, with which one must compromise, the aim of programming is to instead solve a problem with the simplest solution. Following this mindset, I have used fundamental methods such as ‘caching’ – when you store data, for example a reference to another object’s variables, in a new variable to then use, instead of retrieving that data every time you want to use it, forcing the need to have to find the object every time to access its variables. Other methods include coroutines – in comparison to the update method which runs every frame (conventionally 30-60 times a second) coroutines can be made to run as frequently or infrequently as is needed, making them much less impactful upon performance. There are many solutions to one problem, but the aim of programming is to provide the most efficient solution, which is a consideration I have taken into account when programming my game.