Bug Reporting for Games with Split-Screen

Split-screen, where two or more players share one machine and screen with the display divided into separate views, each rendering the game from a different player perspective, is a beloved local-multiplayer feature and a distinctive source of bugs. Rendering multiple views at once multiplies the rendering load, the UI must scale to the smaller split viewports, and bugs can be per-view, appearing in one player view but not another. Setting up bug reporting for a game with split-screen means capturing the split configuration and per-view state behind these split-specific bugs, since the same game in split-screen behaves differently from single-screen.

Split-screen multiplies the rendering and the bugs

Split-screen renders multiple views of the game at once on one machine, dividing the screen into separate viewports, each showing the game from a different player perspective, so the machine renders the game two, three, or four times simultaneously. This multiplied rendering is the source of the distinctive split-screen bugs: the rendering load is multiplied, stressing performance far more than single-screen, the UI must scale to the smaller split viewports, and bugs can be per-view, occurring in one player view but not the others.

These split-specific bugs do not appear in single-screen, since they come from the multiple simultaneous views: a performance problem from the multiplied rendering load, a UI that does not scale to the smaller viewport, a per-view rendering or logic bug, a split-configuration issue. The same game behaves differently in split-screen because it is rendering and managing multiple views. Understanding that split-screen multiplies the rendering and the bugs, with performance, UI-scaling, and per-view bugs from the simultaneous views, frames the bug tracking: capture the split configuration and the per-view state behind a split-screen bug, since the bugs are specific to the multi-view rendering.

Capture the split configuration

The core context for a split-screen bug is the split configuration, how many players and how the screen is split, two-player horizontal or vertical, three or four-player, the viewport layout, since a split-screen bug depends on the configuration and a bug may appear at a particular player count or split layout. Capture the split configuration when a bug is reported, the player count and the split layout.

A report of a split-screen bug becomes diagnosable when you know the split configuration, since a UI or performance bug may be specific to a player count, the four-player split being more demanding and more cramped than two-player, or a split layout, the vertical split differing from horizontal. The split configuration determines the rendering load and the viewport sizes, which shape the bugs. Capturing the split configuration is the foundation, providing the player count and viewport layout that determine the split-screen situation, against which the performance, UI-scaling, and per-view bugs, which depend on the configuration, can be diagnosed and reproduced by setting up the same split.

Capture the per-view state

Split-screen bugs can be per-view, occurring in one player view but not the others, since each view renders the game from a different perspective with its own state, so capture the per-view state when a per-view bug is reported, which view had the bug and the state of that view, the player perspective, what was being rendered, since the bug is specific to that view. A report that something was wrong in one player view becomes diagnosable when you can see which view and its state.

Per-view bugs are distinctive to split-screen, since the multiple views each have their own rendering and state and a bug can affect one and not another, a rendering glitch in one viewport, a UI issue in one player view, a per-view logic bug, which requires knowing which view and its state to diagnose. Capture the per-view context, the view, the perspective, the view-specific state, so a per-view bug is localized to the affected view. Capturing the per-view state covers the per-view dimension of split-screen bugs, where the bugs specific to one of the multiple views live, alongside the split configuration that sets up the multi-view rendering, together capturing the split-screen situation where these bugs occur.

Watch performance and UI scaling

The multiplied rendering load is the defining split-screen performance concern, since rendering the game multiple times at once is far more demanding than single-screen, and performance can fall apart in split-screen, especially at higher player counts where the game renders three or four times, like the scale-performance bugs of any demanding rendering but multiplied by the views. Capture the performance state and the split configuration when a performance bug is reported, since a split-screen performance problem depends on the player count and the load.

And watch the UI scaling, since the UI must scale to the smaller split viewports, and UI bugs in split-screen are common, a UI that is too large or cramped in the smaller viewport, text unreadable, elements cut off or overlapping, like the aspect-ratio and resolution UI bugs but applied to the split viewports. Capture the UI and viewport context for these. Watching performance, for the multiplied-rendering bugs, and UI scaling, for the smaller-viewport UI bugs, covers the two defining split-screen concerns, the performance under the multiplied load and the UI in the split viewports, where the genre characteristic bugs concentrate, alongside the per-view bugs.

Setting it up with Bugnet

Add an in-game report option and attach the split configuration, the player count, the per-view state, and the performance and UI context as custom fields, with a screenshot. Bugnet stores them so a split-screen bug arrives with the split-and-view context needed to reproduce a performance, UI-scaling, or per-view bug by setting up the same split configuration, which a single-screen test would never reveal.

Group identical reports into occurrence counts, watching whether bugs cluster at particular player counts or split configurations. Because split-screen multiplies the rendering and creates performance, UI, and per-view bugs that single-screen does not have, the captured split-and-view context is what lets you reproduce these split-specific bugs in the configuration they occur, keeping the split-screen experience working across the player counts and split layouts players use, which is essential for a local-multiplayer feature whose bugs are invisible until you test and capture the actual split-screen configurations.

Test the split-screen configurations

Because split-screen bugs are specific to the multi-view configurations and invisible in single-screen, test the split-screen configurations, every player count and split layout you support, since the performance, UI, and per-view bugs only appear in the actual split-screen, and a game tested only in single-screen will have split-screen bugs. Test two, three, and four-player splits if you support them, since the higher player counts are more demanding and more cramped, where the bugs concentrate.

Test the performance at the highest player count, since that is where the multiplied rendering load is greatest and performance most at risk, and the UI in the smallest viewports, since that is where the UI scaling is most stressed, much like testing the extremes of any configuration. Pair the split-screen testing with your captured reports, which surface the split-specific bugs players hit in the configurations you did not fully test. Together they keep the split-screen working across the player counts and layouts, ensuring the performance, UI, and per-view rendering hold up in the multi-view split-screen that the genre offers, which single-screen testing would never verify.

Split-screen multiplies the rendering into per-view, performance, and UI bugs single-screen never shows. Capture the split config and the views.