Aim Gods Custom Launcher / Patcher
Back in 2020, FinalMouse stumbled across our core software product Game Launcher Creator V2. They were at the time, developing a brand new game Aim Gods.
They wanted to use GLC V2 for their game launcher and update system for their upcoming game development. Whilst GLC V2 offered pretty much everything they needed, what they wanted was a more streamlined, faster and bespoke launcher and patching system for their awesome game development. It was a pleasure to work with them and here we showcase the how, where, when and why of developing a custom game launcher for FinalMouse.
Here at ByteBox Media, we are a software development company based in the UK. We are available to hire for software and game engine development. We have 20 years experience in the software and game development industry and we are constantly developing with new and emerging technologies to bring unique software solutions to the market.
FinalMouse are a company on a mission to provide the world with ultra-elite gaming mice, lightweight, super-responsive and longevity are the core parts of their gaming mice.
FinalMouse had been developing their own PC first person shooter game in celebration to showcase just how good their gaming mice really are. What better to showcase than a complete, custom game of their own?
During 2020, the FinalMouse lead developer Tim stumbled across Game Launcher Creator V2, our flagship product. After purchasing and reviewing GLC V2, Tim realised that even though the software provided what they needed, they wanted more. Tim proceeded to get in touch with us here regarding their project as it wasn’t far from completion.
Tim and FinalMouse decided after all the hard work and efforts put into their new game development, that it equally should have an awesome looking and working game launcher and patching system.
It wasn’t long before we were drawing up a design document, outlining exactly what FinalMouse were looking for in their custom launcher and patching system. We swiftly reviewed the design document, added, modified and improved on bits, sent back for review and the development job was started.
The development project was started around July 2020 and we worked pro-actively with Tim, their lead developer of their game on a daily basis through Discord.
Custom Launcher Development
FinalMouse knew they wanted a custom launcher developing as they had a particular way in mind they want it to work, which didn’t come as standard with GLC V2. Because this was a custom launcher we would start from complete scratch, in terms of source code. There were to be no shortcuts, as this was to be developed from the ground up.
Fortunately, because we have PLENTY of experience in launcher and patch development, it wasn’t like we were lost in the woods, if anything, we already knew were the correct paths were, because we have so much experience in this development sector.
We quickly set out the exciting part of any project, a clean sheet. Even though we had code-base from our existing developments from GLC, we wanted this to be a clean-sheet development, coded from the ground up, only catering to the exact specification of the design document we had drawn up.
The development was a Windows Desktop PC application and only Windows, no other platforms. On the strength of this, you have a great platform to develop for with plenty of options. The project was to go ahead using a combination of C++ and Fusion. This combination allowed us to develop C++ DLL extensions that could be packed and referenced into the final package easily and allowed for portability too.
FinalMouse wanted a flexible launcher design, meaning we wouldn’t “hard code” the graphics and visuals into place. We wanted FinalMouse to have as much freedom when it came to changing things at their end, as possible. They
There were many features to this launcher and patcher project, but here were the most important features to be implemented…
We wanted FinalMouse to have a dynamic design for their launcher and because they had their own Amazon S3 servers, it was an easy feat. The custom patcher would first of all check the server for a settings config file and download all the launcher images to be used.
This means when the launcher is run first, even before the splash screen, it downloads the splash screen image, then draws the window for the splash. This is a great feature, as it allows FinalMouse to change their splash screen image at any time on their server.
As the Splash Screen is displayed, the launcher reads the config file to see what image files need downloading for the design of the launcher itself. A highly optimized design means they can be downloaded to the users PC in a matter of 1-2 seconds and the launcher is ready to run.
Once the launcher assets are downloaded and load into memory, the launcher first does some hard checks on the user’s computer, such as checking the registry first, to see if the game has been installed with the official installer. If it has, the registry entries would exist. So then it checks the currently installed version number against the version available on the server. If an update is available, the patching system is launched.
If the installation registry entries are not found on the user’s computer, then the game is either not installed, the installation became corrupt or the user downloaded the launcher without the installation file.
In this instance, the launcher will proceed to download the installer from the official S3 bucket of FinalMouse and perform the game installation.
The core game files are not installed with the installer, they are installed by the patching system built into the launcher itself. This allows for a very small initial installation file to be distributed by FinalMouse (~60mb).
To ensure the user is always running the latest version *AND* they don’t have any corrupt files from their game installation, the launcher can perform a very quick file verification check at startup. The patching system will very quickly scan through all the game files and check if any of the data mismatches the actual game files. If it does, it can quickly download and patch those particular file(s).
It is a very streamlined process that works very quickly and allows the user to always have the correct game files installed and the latest version installed.
Due to Aim Gods being an online multiplayer game, it was utmost paramount that the client files matched the server files and all the client files remain untouched.
Custom patcher Development
FinalMouse needed a custom patching solution for their game updates. Some updates could be a simple 100kb update, some could be up to 4GB in changes, so they needed something dynamic.
AOPS – a patching system built-in to GLC V2 game launchers offers this solution, however, they needed a more streamlined and bespoke version of a patching system, they also needed power boosts such as much faster download speeds. Let’s take a look at how we achieved this.
Game Patch Integration
The patching system was to be “built-in” to the launcher. There would be no external windows, no external executables or scripts. So we had to code a brand new patching system from the ground up, alongside the launcher project and code-base.
The patch system we previously coded into GLC V2 (AOPS) was developed in 2019. It was a 32-bit, single-threaded development due to the linear nature of checking files on a file-by-file basis. It also runs on the GPU, single-threaded. The Aim Gods launcher needed something with a bit more oomph, so we did not take the same route we took when developing AOPS.
The patcher was to display the update status inside the launcher itself, so the user was never inundated with different windows or different pages. It seamlessly integrated into the same launcher window with the play buttons…
Everything you see in this launcher is customizable by FinalMouse without even having to touch the source codes or recompile the launcher. It’s a completely dynamic design so they can change the text strings, the font, font colors and much more all by tweaking a file on their webserver. This saves development time, re-compilations or being tied down to get us to do the changes, they can literally do it freely themselves.
The AOPS game patching system is coded as a 32-bit application using a single-thread running on the GPU. This is good enough for GLC V2 projects, as files are checked, verified and patched on a file-by-file basis anyway, but the Aim Gods launcher needed something with a bit more oomph!
With the application being 32-bit we had some constraints but the application needs to be a 32-bit application in order to ensure compatibility worldwide.
The first issue in using 32-bit architecture is CPU and Memory limitations. 2GB was always the limit but 32-bit applications can actually handle 4GB of RAM. We had to upgrade the routines we would normally use (for AOPS) to handle a 4GB download clean.
You maybe wondering, why would we only want to support 4GB of downloads? Well, 99% of webservers wouldn’t allow for anything bigger than 1Gb usually anyway. This is typically a server limitation, even when using nginx. We advised Tim over at FinalMouse to split their end-game file assets up into smaller files, rather than using one big asset file or larger ones. It also allows for quicker scans/patching anyway.
So the need for 4Gb+ downloads was not required, even if we used 64-bit.
The next hurdle we faced was multi-threading. By design, AOPS was using a single-thread approach. This was good enough for AOPS as it was scanning files on a 1-by-1 basis. However, the downloads are limited by the GPU as we run the launcher through a DirectX 9 runtime, so it allows most of the processing power to be utilised from the GPU. Much better option here than the CPU, in terms of AOPS that is.
For the Aim Gods patcher, 8mbps downloads were no good. They needed to be multi-threaded in order to unleash full, unlimited download speed. In order to achieve this, a lot of modification was required to the dynamic link libraries we used to achieve the downloads using GET.
In programming 2147483647 is the largest positive integer you can specify in 32-bit. This number was no good to us, internally we had to download more bits than 2147483647 and visually, we had to display bigger numbers than 2147483647 in text strings.
For example, 2147483647 bits is only 268MB.
But this is signed, we can still do unsigned which gives us the ability to use 4,294,967,295 as the biggest integer. We can also compute the math in a DLL and output a 32-bit representation to then display inside the patching system, simply by using division.
When you develop a software application, especially one that will be fit for public consumption, you need to ensure you develop for compatibility across the board.
The problem with developing in 2020/2021 is, there is a plethora of different machine setups and operating system setups *and* drivers.
Due to multi-threading the application, we decided to process the launcher and patcher via the CPU and not the GPU. This would ensure smooth and consistent results. The problems we could foresee would be issues with users using outdated video drivers and much more. This was solved by using the CPU for processing power instead of the GPU.
Throughout testing, we had our own internal team of testers with different setups, we had Tim with his computer setup and he had his own team of testers also.
Upon BETA testing pre-launch, everything was eventually refined and smoothened out so the launcher was compatible pretty much across the board.
When developing for Windows, even after 20 years, you still come across oddities when it’s a “new area”. During the BETA testing phase, we had one particular user who had his patcher looping the same file over and over. We scoured through the debug logs and source code, everything should work.
When we asked what country he was from, it was New Zealand. Immediately, I figured it must be something to do with his timezone, I had already exhausted all other options.
I wrote a test application that downloaded a test file, then timestamped it accordingly. I got this user to test it. The results came back conclusive, it was indeed because he was 13 hours in FRONT of UTC (or GMT).
It was here when I realised that Windows doesn’t just use a BIAS with a timezone offset. Upon researching, it contains a myriad of different offset configurations and all sorts. It certainly blew my mind.
Microsoft for some reason, use a BIAS (timezone). Then they have an ActiveBias (which is a timezone offset flag), then they also use a DayLight Bias. It was all very overwhelming and long-story-short, we figured out how to take the current UTC time and subtract/add the timzone bias accordingly.
This really isn’t as simple as it should be or seems, I can’t recall the finer details exactly but this had me stumped for at least a couple of days.
Eventually we managed to distribute this update to the testers and we got positive results confirmed.
The Final Say
FinalMouse really wanted to push the initial release of their flagship game development out of the door in time for Christmas 2020. We worked tirelessly with Tim throughout December to get the final touches complete and the final tests approved.
We made the deadline with a few days to spare and the game was successfully launched, 21st December 2020 with a huge launch campaign in place.
There were no reports of errors, YouTubers and Twitch Streamers were part of the launch campaign and everything went down very well. The launcher and patching system worked just as it should have done and everyone was happy with the result.
In the last 10-11 years we have developed numerous custom installers, launchers and patchers for many software and game companies. Every project is different and unique. The Aim Gods launcher and patching system was no different.
Even with all the experience we already had, we still found new mountains to climb, new challenges to face head-on and overcome. It was challenging but easily managed. It was a fantastic project to work on and we managed everything to the initial design documentation we drew up together with Tim.
We learnt some new techniques with our patching developments, we learnt a lot about upgrading a single-threaded 32-bit routine into a multi-threaded powerhouse. Typical for a client project, we were also reminded that developing good, working relationships with other development teams is paramount to success.
Tim was an ideal front-man for FinalMouse and he was the lead programmer for their game, Aim Gods. He was a blessing to work with because he knew what we were referring to when discussing milestones, issues we were facing and mountains we had to climb. He could empathise with us and vice versa.
It was a project I was more than happy to work on and I’m really glad I was a part of Aim Gods development, even if it was just the launcher and patching system.
Don’t forget, we are an active software development company who are available for hire for custom software solutions such as game launchers, game patching systems and custom installers.
We also do much, much more including game engine development and more. Please browse our website to see what we offer and you can contact us via email any time (or drop by our Discord server).
I would like to take this opportunity to personally thank a few people who were a part of this project or helped out in any way. Ash (FinalMouse) for the opportunity. Tim (FinalMouse) for the opportunity. These two gentlemen enabled me to develop the type of application I was strong in and enabled me to re-think some strategies and gain more knowledge after being presented with these hurdles.
I would also like to thank Yves Lamoureux. Yves provided unique insight into a lot of the 32-bit stuff and went above and beyond in adapting the download extensions to accommodate up to 4GB file downloads and also provided a way we could read filesizes over 2GB. Yves also provided an automatic way for us to utilise the Bias offsets from the registry, what Windows uses to calculate the actual offsets. His work is invaluable to me and allows me to achieve targets I’ve previously been unable to achieve. With Yves at the helm of Fusion 2.5’s framework and me pushing the boundaries of application development, it makes for some interesting results.
I would also like to thank Phi for his time and guidance. His GET/POST routines proved to be invaluable functions that allowed us to achieve a few targets.