Written by: Agustinus Agri Ardyan
Edited by: Monic Andyani

Game  update is one of the ways to keep our gaming experience smooth — that’s  just how important it is. The challenge is that the size of the game  update today can go up to GBs, especially when we talk about AAA games.  While this is not a problem for some countries with high internet speed  like Singapore and Baltic countries, it’s not quite the same for the  rest of the world. In that case, one of the solutions is to reduce the  update size. So how do you do that?

To  reduce the update size for a game or application, we reuse bytes from  old files. This concept is implemented in AccelByte’s BuildInfo, and as a  result, BuildInfo V2 was born. Think of it like we recycle the old file  and require users to download only the necessary parts from remote to  patch the old files to the latest version. Previously in BuildInfo V1,  we had an updated algorithm to chunk each file into smaller chunks. For a  small number of users updating simultaneously, I think the performance  is alright and everyone is happy.

However,  when the number of users rose high, the server load increases  significantly. We make it so that in every game update request, the  BuildInfo service will compare every chunk from the user’s version with  the latest version and then respond by returning only chunks that don’t  match. This process is called diffing. However,  there is no guarantee that the update size will be smaller than the  competitors’ nor that the update size will be in a small amount. In a  case, the V1 update size is two times bigger than the one on Steam.

To  figure out a way for an efficient update, our team did some research by  implementing several algorithms. We were thinking to use the  widely-known Rsync algorithm initially, however, we found out that Rsync  is one of the main causes why our server load is severely heavy, we  decided to switch to Zsync (Kudos to the team Rafi, Stradley, and  Windio!).

There  are several open-sourced MIT-licensed library for Zsync available in  public. After a thorough examination of those libraries, we need to make  sure that it doesn’t implement another proprietary library or any  licensed library that might hinder us to fully alter and use it  commercially. The next step is to alter some of the code in it and  adjust it accordingly so that it will suit our case. In this case, we  add a splitter feature to make things run smoother and I also created a  wrapper and removed some unused features, so that it is easier to be  integrated to the Launcher.

To  ensure that everything will run without fail, I helped the Quality  Assurance team by creating a script to check the download size of game  update via BuildInfo V2. I personally believe that the script is helpful  for the QA team to use as a tool to cross-check and to ensure that the  download size in the Launcher is correct. I also assisted the Launcher  team to integrate the new build into their code. I will not claim a full  credit here since I am not working alone, I am grateful that the teams  are backing up one another. For instance, just right after I finished  the integration task, it turns out there are some defects along the way,  and the Launcher team is there to help me to fix the issue.

The  technology that we use is similar to BuildUtil, which is Golang. What’s  nice about Golang is that it gives us a future maintenance advantage,  since there are a lot of our engineers that are able to speak Golang.  Can I confidently say that the technology we use is good? Well, good is a  word with a broad meaning, since every algorithm or any tech has its  own tradeoff. The BuildInfo V2 tradeoff is that it will take more time  before downloading, especially when there are lots of files because it  needs to calculate which bytes to reuse and which ones to be downloaded.  However, it’s very effective to reduce update size as much as possible  to solve the current issue. In the future, we plan to make it even  faster and more efficient by using a faster hash generator combined with  another algorithm and/or something else.

Every  project has its own obstacles. As for this project, the integration  process to our Launcher was one of the toughest obstacles that the team  managed to tackle. Our Launcher is an Electron application written in  Typescript, and while it’s good for front-end tasks general purpose,  it’s not meant for intensive computation. We spent a good amount of time  trying to implement the algorithm using Typescript and finally conclude  that we need to use another way because it was too slow.

To  solve it, we went through a series of research. After browsing for some  NodeAPI documentations, we decided to build it as an executable  instead, so that the Launcher can call it by using one of the NodeAPIs.  Other than making it as an executable, I also preserve the code that is  exported to the DLL to be used for our upcoming MiniLauncher.

I  was surprised that the BuildInfo V2 is able to save so much by reusing  the existing bytes from the old file. When our QA Team released a report  for one of the AAA games we handle, they said that our update is 7GB  smaller compared to the Steam updater. I genuinely thought that I had a  bug, even one of our QA raised his eyebrow when he acknowledged the size  difference. Only after the QA tested it by pressing Play on the  Launcher, and is sure that the game was working as expected, I felt  relieved and was also super excited at the same time. The same story  happened with another game we tested, The Steam updater calculated 1.3GB  of update size while our Launcher required only about 450MB!


It’s awesome what he can do, don’t you think? Got any question? Or wanting to learn about our technologies at AccelByte?

Stay tuned!