In-game defect reporting
It is common that reported defects lack valuable information, such as logs or screenshots. You can always collect and automatically attach these elements when you implement in-game defect reporting. This is what I added to the engine, so it was not necessary to even open JIRA in your browser.
JIRA API is based on JSON messages. We create the issue (The Jira Cloud platform REST API) and then add its attachments in a loop (The Jira Cloud platform REST API). Communication is based on the curl library and utilizes our internal job system to prevent blocking the main thread.
Each defect has two types of data:
- Provided by the user
- Title
- Description
- Reproduction steps
- Component
- Severity
- Collected automatically
- Screenshot – collected just before triggering defect reporting UI (either via hotkey or our ‘Escape menu’)
- Logs – both client and (automatically downloaded) server logs
- Profiling metrics
When a defect is created, you get a pop-up with a button to open a JIRA ticket in a web browser. Otherwise, you will see a pop-up with the exact response from JIRA (development-only feature, so we present the same JSON message returned).
There are two additional aspects that you should consider:
- Granting access to your JIRA API requires extra care – you do not want all your data in JIRA to leak.
- Our security team decided to use a functional account for it, so it is quick to revoke the access (a new binary is needed to restore the functionality). The drawback of this approach is that all defects are reported ‘by the same user’, so we have an additional prompt to write the reporter’s name.
- This functionality collects and saves a large amount of internal data on disk – should be compiled out for the shipping version.
To conclude, creating simple in-game defect reporting for JIRA is relatively quick and easy. You may spend most of the time on its security and adding more data to it.