The backend part of handling the downloading of DLCs (games) is mostly done for ScummVM Cloud. In the context of DLC downloading, ScummVM Cloud refers to the hosted DLCs on ScummVM’s servers.
Let me first quickly iterate the overall lifecycle of downloading a DLC from ScummVM Cloud:
- Users request and retrieve the DLC list, which contains information about downloadable DLCs. This list will be cached until ScummVM is restarted.
- Users can select any DLC and press the Download button to add a download task to the queue. The download tasks in queue will be processed one by one.
- The DLCs are downloaded as .zip file in
dlcpath. - The .zip file is then extracted in a new directory inside
dlcpath, and after the extraction process, the .zip file is automatically deleted if possible. - An additional game entry is then automatically added to the ScummVM configuration file (scummvm.ini). These game entries will also have a special download key.
- The newly downloaded DLC is now available in the game list of the launcher, and users can now enjoy playing this DLC.
Initially, I implemented the greying out of the text for downloaded DLCs using an index (integer) based download key. Since I had already changed the DLC download key to a string, I have now adapted the code to work with a string. For each game entry in ScummVM’s configuration file with a download key, we find the corresponding game and mark them for greying out.
Also, there’s a simple way for greying out the text in a List widget. We just prepend \001C{alternate} in the string which we want to color grey. And that’s it.
From the first point of the lifecycle of a DLC above, you can see that we needed to send the HTTP request to the server only when the users requested it. This request is basically clicking on the button for browsing DLCs. Before, I was fetching the DLC list on the ScummVM launch. I have now shifted the call of the fetching process from scummvm_main() (on start) to the constructor of the DLC browsing dialog. We show the text: “Fetching DLCs…” while waiting for the list, and once we finish the fetching process, we send a command to our DLC browsing dialog (GUI) to redraw itself with the fetched DLC list. This DLC list is cached until ScummVM is closed and gets reused the next time we browse the DLCs.
The other thing I implemented was adding the game entry in ScummVM’s configuration file after the extraction process was completed. And after that, refresh the launcher’s game list right away. Initially, I was under the impression that I had to first detect the game and then add the entry. There’s an existing method already implemented that does both. This method executes after we select a game directory using “Add Game” button. After discussing with my mentors, we decided to go with adding the details that the ScummVM config file requires in the JSON response itself. Since we already know the details of what exact game we are providing, we don’t have to run the detection code and can just put the information in the JSON file. I have now temporarily shifted the hosting of the JSON server to my Firebase instance. I can add/edit information directly from the browser, and its web address will also remain the same. Once the entry is added to ScummVM’s configuration file, we refresh (rebuild) the launcher GUI.
Finally, I added a new path for storing DLCs called dlcspath. Before, I was using the iconspath. I had to set the path in each of the platform’s backends. I have currently set it to platforms based on SDL, like Linux, macOS, Windows, etc.
Here’s how the overall progress looks: