Scalability and The Developer

Scalability is more than just graphics settings, it is about choosing a target platform and making decisions about art, gameplay, sound, AI, and any number of other systems, to fit that platform. For consoles, the platform is fixed, and this is more straightforward. However, for the PC, the number of different equipment combinations makes it impossible to focus on a single hardware specification.

This is where the Scalability options come into play, but even before they need tweaking, the individual developer can do a lot to make sure the application they are producing will run on their chosen minimum specification.

General

Different machines can have different performance/memory/quality characteristics such as:

• Hard drive size/latency/bandwidth
• Main memory size/latency/bandwidth, running 32bit instead of 64bit can limit this further
• CPU (one or more main processors, hyper-threading, SSE features, branch prediction)
• GPU (memory, Multi GPU, bandwidth, features, shared memory)
• Resolution (modern notebooks have high resolution displays but slow GPUs)

Graphics is generally the easiest to scale without affecting gameplay much. The players generally accept the concept of scalability but only very few actively go to the options menu and adjust them properly. Option screens are often overwhelming in quantity of options and full of intimidating names. Still, there are options to give the player control over a lot of decisions that are subjective and have tradeoffs:

• Frames per second
• Resolution
• Image quality
• Motion Blur
• Texture details
• Flickering (anti-aliasing)
• Battery life

Artists and Designers

Unreal Engine gives a lot of power into the hands of content creators and with that comes a responsibility. Performance and memory requirements are directly connected to content count and quality. This is a very complex problem:

• Content is often created without the target hardware.
• A complex matrix of hardware properties (low memory but fast, fast GPU but slow CPU).
• The engine code is still under development and optimized on needs driven by content.
• New hardware and drivers change the equation.
• Development time constraints limit optimization efforts.
• In order to make this manageable, it is best to have some good practices:
  • Plan and verify budgets (triangle/object/material/light count, texture/mesh/sound memory, ...).
  • Add scalability options to non-gameplay relevant content, test with lower and higher settings.
    • e.g. hide clutter objects on lower spec, use simpler material shading, object level of detail.
  • Restrict player abilities.
    • e.g. visibility blocker, cannot build arbitrary complex structures, limit destruction.
  • Understand performance characteristics.
    • e.g. many dynamic objects with many point lights, mesh particles vs. sprite particles.
  • Mix different components in similar ratios (some hardware might be only slow in some feature) bad: many objects simple material, few objects many lights with complex materials.
  • Understand in-engine profiling tools.

QA

A wide range of scalability costs more QA time. A few good practices can help:

• Document low/recommended/high spec.
• Test on a wide matrix (low/med/high GPU, low/high CPU, low/high memory).
• Define performance levels on reproducible scenes.
• Document and communicate changes over time.
• Disabling stuff is a powerful way to isolate a performance issue (e.g. show console command).
• If you run in lowest quality settings and something looks quite better than expected - it might miss a scalability setting (fixing this could mean more players can enjoy the game).
• Test usability of the scalability: report anything if you find it confusing and wrong.
• At any time the user interface should be readable and functional. Please test low resolution and lowest quality settings and look for unreadable fonts and elements outside of the screen.
• If some artifact only happen at some specific scalability level (e.g. only on "low") you can isolate the issue further (e.g. shadows are likely affected by "shadow quality") going down to the actual console variable setting (look into Scalability.ini file).
• Know how to quantify performance (stat fps, stat unit, ...), milliseconds are more useful than fps ("it became 10fps faster" is not meaningful but "it became 5ms faster" is).
• Some notebooks have multiple GPUs (e.g. Intel HD4000 integrated graphics to save battery and NVIDIA 580m for performance). By default, you want to run on the faster GPU but it is best to run test both (use the driver setting to change that). When running on battery, it might pick the slower one or even switches it at runtime.

Programmers

A player might have an advantage seeing the shadow of a player earlier or having a higher frame rate gives you a faster response time. Staying within the offered scalability settings is not cheating but some scalability settings could be abused to cheat. A console variable might offer a wider range of values than needed for the scalability or a combination of console variable settings can lead to problems. Some multiplayer games address that by giving control to the server administrator overriding problematic setting to offer all players the equal chances.

Example: Hiding in deep grass can be a good gameplay tactic. However, if grass is no longer rendered in larger view distances this can feel very unfair to the player trying to hide.

Ideally no scalability setting would affect gameplay.

Leads, Producers, and Managers

What managers/leads should know? Developing a game that needs to scale to a wide range of hardware is harder; it costs more time and QA efforts. A few good practices could help:

• Define a low Spec and a recommended Spec early in the project development.
• A good "auto" feature is important as most players never use the options menu. To get this feature right, you need a lot of iterations and testing.
• A smaller scalability range makes development easier (bad: High end PC to low end mobile).
• Having a second low Spec machine can help in every discipline (code, design, and art). When balancing tasks, it is generally better to optimize than to create more scalability.
• Performance is one part of scalability but it also can affect stability. E.g. If you run out of memory on a lower Spec, it might be best to grey out the high resolution texture option.
• Scalability on low end means more players can play the game. Scalability on high end means the game can look better, especially in screenshots and tests.