Reporting the detected bugs in a detailed format along with debug the logs or crash logs is critical to help the game developers squash the bugs quickly. This process of finding and exterminating bugs is known as debugging. A bug can be something very small and simple like messing with your input to game breaking, progress halting, complex monstrosities.
Quality assurance or QA testing is done on any and every product before it ships particularly to find big, game breaking bugs and find a fix for them before the game reaches the player’s hands, however, sometimes, some minor or even major bugs go under the radar and wreak havoc on players. No worries, nothing a patch or hotfix can’t fix! That’s the problem though, in order to work on that patch the developers must first understand the origin point of the bug then look for ways to fix said bug. This is easier said than done because a simple, minute error in a line of code somewhere can cause major complications. A player may see a message pop up on their game saying “sorry the game is not responding” or “sorry we cannot connect to the servers on this device” or even stumble onto a quest or mechanic that just halts their progress. All of these problems can be caused by bugs and once they are reported by said player they become part of the log back at HQ.
You see, bugs are a common occurrence. No product ships in a bug free, perfect state, it simply cannot, so getting a bug report shouldn’t be a disheartening tale rather a prevalent solution should always be fingertips away. In most cases the devs themselves are aware of certain issues and are already working on a hotfix coming in a matter of days but, in a way, the players are truly the ultimate QA testers as they are able to find ways around and exploit the game mechanics through extensive playtime which in turn results in more and more bugs being discovered, a luxury developers don’t have while working under tight deadlines.
So, what happens is every time a bug is found and reported it gets added into the debug log. Why is that important you may be wondering? Quite simply, it’s because having all the problems logged into one place, new and old, helps with the debugging process as the developers can simply check said log for familiar, new or recurring problems. Sometimes, despite the bug being in front of your very eyes, it becomes impossible to find. The developers might know what’s going on but cannot find a reason as to why it is happening, this causes a lot of panic, havoc and R&D behind the scenes. In cases like these having a log with entries from the past and a handful of potential pain points that needs addressing comes in extremely handy as it becomes easy to pinpoint the source directly and find a working fix for it. Again, once we know what the problem is we can make a case for it in JIRA and fix that problem in no time.
For Android, you can collect these logs by using ADB(Android Debug Bridge). You just need to go to your phone settings> About phone> Tap the build number 7 times> Go back to your settings> Developer options and then enable USB debugging. Once that’s out of the way you can download the SDK(Software Development Kit) on your PC and go to work on collecting and squashing said bugs. On iOS devices you can use tools like Xcode or even iTunes itself by plugging your iPhone in and using the dev kit.
Debugging, for a developer is the next step towards making their game perfect and collecting logs is not only important for accounting the problems faced throughout the history of said game but also helps with finding solutions to problems quicker and can help you along for your next project and can also help other developers attempting to make the same kind of game. Debugging logs when kept, maintained, understood and acted upon can help the industry as a whole and not just a single developer.
For this last part, let’s get technical! We have discussed what debugging is, what logs are and what the importance of said logs are. Now, let’s take a look at the process of how the logs are collected and get into the nitty gritty of the process.
For my android developers the process goes something like this:
- On your android phone do this – Settings> About Phone> Tap Build Number 7 times> Go Back to Settings> Developer Options> Enable USB Debugging.
- Download Android SDK Platform Tools ZIP File for Windows
- Extract it all to an easily accessible folder like – C:\platform-tools
- Open Windows Explorer and browse to where you took out all the contents of this ZIP file Open up a Command Prompt from the same directory as this ADB binary. To do this, hold shift and right click within the folder then click, “open command window here” option. Connect your android device to the computer with a USB cable. Change USB mode to file transfer (MTP) mode.
- In the command prompt window, enter the following to launch ADB daemon – adb devices Now click on always allow USB Debugging access on your phone
- Re-enter the command from step 6, if everything went smooth you should see your device’s serial number in the command prompt
- And voila! Now you can run ADB commands on your phone.
With that out of the way, by following these steps you can collect logs and build your own database.
- First make sure that the developer options are enabled on your android phone, to do that go to settings, go to About Device and then tap 7 times on the build number, this will give you developer options in the settings menu.
- Now enable USB Debugging on your device by going to the newly found Developer Options. Also make sure that the phone is not locked and is active for the duration of your log collection process.
- Now start your windows PC, and if you have not already then download Android SDK (Software Development Kit) and install it.
- This program will launch automatically, so now select and install Android Platform Tools. Now, Connect your android phone to your PC with a USB cable.
- Now open a new command prompt session, change its working directory to the path where Android SDK is installed {cd[path where Android SDK resides]/platform-tools}. Now, you will have to run this command –
- adb.exe kill-server
- Next, run the command to list the devices that are connected to your PC. Note the device id of your device
- adb.exe devices
- Now, Run – adb.exe logcat -v threadtime [device id > C:\android-debug.log] – here you will have to enter the device id that you got from the previous step in place of [device id]
- Perform any action on your android phone. In order to stop the adb process, press Ctrl + C on the command prompt window
- The debug data can be viewed from (c:\android-debug.log file).
Here’s another super quick way to start collecting those logs for my Android developers:
- Clear previous logs
- adb logcat -c
- Run the application and then find the PID
- adb shell pidof -s <<gamepath>>
- Run ADB on cmd
- Start adb logcat—pid=<value>
- Replace the value found from step 3 and collect all the logs in file.txt
- adb logcat –pid=<value> >file.txt
If your device does not recognize your phone, try these steps –
- Unplug and replug the phone
- Enable Verify apps over USB option (Settings>System>Developer Options>Debugging).
- See if the device notification bar displays the message USB debugging connected Select Revoke USB debugging authorizations to revoke the access to every computer you had previously authorized (Settings>System>Developer Options>Debugging).
Don’t worry! I haven’t forgotten about my iOS developers! There’s 2 ways for iOS devs to get to log collection –
The first one involves using Xcode:
- Plug phone into iMac then unlock it
- Open Xcode
- Click on Windows>Device and Simulators
- Click on your device from left menu
- Click on console to see the real time logs
- There are 2 tabs called All Messages and Errors on the top left, click All Messages Click Clear
- Reproduce your issue
- Scroll up in console to stop autoscroll
- Copy paste the logs in TextEdit, upload it to Dropbox
- Unplug the device to stop logging process
- Click on View Device Logs to get a list of crash logs
- Email yourself the log as attachment
The second method is through using iTunes:
- Plug set into PC and run iTunes
- Click the device and sync
- Open file explorer & type %appdata% into the search bar
- Navigate to Apple computer>Logs>Crash Reporter>Mobile Device and click the device you got the crash on
- File path would be –
- C:\Users\User\AppData\Local\Packages\AppleInc.iTunes_nzyj5cx40ttqa\LocalCache\Roaming\ AppleComputer\Logs\CrashReporter\MobileDevice\
- Locate the .crash file
- Maybe instead of a .crash file you would see a Jetsam Event…ips – this file shows you are out of memory, so attach to the bug since this could be useful if there is no .crash file.
And there you have it! A short, simple and sweet way of learning about debugging, logs and how said logs are collected! Hope you had a blast learning about the log collection methods. Please note, above steps may change with each major OS update from the first parties and we’ll try to cover that one too in our future articles!
