a series of GamesIndustry.Biz Academy articles

In the last article, we talked about the “release candidate” and the work that goes into it, namely fine-tuning, technical compliance and bug-squashing. In this final article we will cover what comes next, when a build is almost ready to be released to the world.

Gold Master

For each platform, there comes a time when you must prepare for the dreaded process of submitting your game. The one process that is out of your control is when you finally upload and submit the final code.

You may have a few sleepless nights worrying about how many bugs have been reported or if the game failed even before it entered testing; and yes, this can happen!

A long time ago, in the early years of PlayStation, it was common for a publisher to put someone on a flight and fly them across the Atlantic to deliver a submission by hand as it was quicker than using a courier. Unfortunately for some, a few submissions failed even before they could enter testing due to disc mastering errors or even things like using the wrong type of pen when writing on the discs. A very expensive mistake to make.

Thankfully, these types of errors are history because everything is digital now, but that doesn’t mean similar errors don’t happen, because they do. The difference is that now it’s about version numbers or the wrong type of encryption being used. 

At Abstraction, we can and have submitted a client’s product to the platforms (Nintendo, PlayStation, Stadia, and Xbox) on their behalf because they might not have the experience, or because we can do it faster (they might be in another time-zone which could cause them to miss their actual submission date).

The first thing you need to do, before even delivering your game to the platforms, is to verify that your game is indeed ready for submission as a Gold Master. We always recommend that clients consider a pre-certification phase before the actual submission. This process can give very valuable feedback on a title, and whether a little more time needs to be spent fixing those pesky certification bugs that might slip through unnoticed.    

Each individual platform offers various pre-certification options, and Abstraction can advise clients on what to take advantage of and when.

Where do we start

One of the very first questions we ask a client is, “Have you submitted your Game Concept to x platform?” and in reply, we are often asked, “submitted a what concept?”

If you do not submit your game concept to the platform, you may encounter delays later in the development process, such as being licensed so you can gain access to Dev/Test kits, product information, and your release date. Avoid making this mistake and submit your game concept early!

After being given the greenlight by the platform, you will have access to their portals, documentation, etc. From here, you can start building up your game on their systems.  

It’s impossible to cover each of the platforms in this article, so we have written a brief guide on what you should do:

1. Submit your game concept early: The process always takes longer than you plan for. 
2. Age Ratings: get them early and update them if your content changes. It has been known for IARC (International Age Ratings Coalition) ratings to change retroactively and products to be taken off a digital storefront for a few weeks while issues are resolved.  
3. Plan for at least three (3) submissions, including an optional round if the platform offers it as a service.  
4. Use an external QA company to check your title for issues that might have been missed by your own QA team; it happens.  
5. Ask for waivers early if you believe your game may fall foul of a guideline. If you don’t ask, you won’t receive. 
6. Is the game using the correct terminology? You don’t want an Xbox controller appearing in a PlayStation game, and vice versa, now do you?  
7. Double and triple-check your submission documentation, verify that you have all the materials needed, and have answered all the questions.  
8. Check your packages: remember the story about disc mastering errors? Check your packages and verify the version numbers match against what you see on the platform portal.  
9. Has your marketing team done its job? Have they submitted all the necessary text, images, videos, pricing, and release date needed for the storefronts?  
10. Ready to upload? Make sure you have the correct build, supporting information such as achievements, trophies, save-game files. Check and recheck you have all of them.  
11. Upload and then submit your game to the platforms!  
12. Bug reports: bheck the portal every day for newly reported bugs, don’t leave it to the last day to feedback issues to the development team.  
13. Depending on the platform, expect your title to be in QA for a week or longer. 

As each platform uses a different submission process, we strongly advise you to read the documentation as to what you should do. Ideally, have someone else check everything after you have uploaded your title to make sure you have not missed something.  

If your game passes or fails, you should expect to get a report from the platform within their published SLAs (Service Level Agreements), which you can find on their portals. 

If you have passed, celebrate and wait for the game to be released. If you have failed, it’s not the end of the world. Rebook a slot for your resubmission as soon as possible. Don’t forget to increment your version number, fix the reported bugs, and go through the whole submission process again.

Post launch support and maintenance

Once the game has passed certification, and after it has been released, we will always provide post-launch support for a certain period of time to make sure that the release goes well and that any high priority issues discovered post-launch are fixed quickly. 

It is also becoming more common for games to continue getting content updates after their launch. Some games are updated at regular intervals, while others get new content through DLCs. There are also games that do both.  

Every content update can be seen as a mini adaptation as we need to make sure that the new content is adapted to the target platform just like the original game. The scope of this is usually a lot smaller than the original adaptation but adding new content to a released title comes with its own set of challenges.

Adaptations can diverge a lot from the original during the tailoring phase described in our previous article (here). This can introduce additional overhead when doing updates, as the changes in the original game will need to be merged into the adaptation. Some of this work can be automated, but it is not uncommon for some of the merging to be done manually. 

Content updates also increase the size of the game, which can cause the update to go beyond the limitations of the target platform, requiring further size optimizations or explicit permission from the platform holders to go beyond the limits - if that is technically possible. Another effect of more content can be increased loading times that will need to be addressed before the content can be released. ARK: Survival Evolved 

It is also very common that the complexity, added with the new updates, causes issues in areas that were fine during the release. An example would be the server browser in ARK: Survival Evolved. This was working fine during release, but when the number of servers was increased to multiple thousands, we had to make some custom UI optimizations to keep the server browser responsive.

A key component to any content update is the delivery method, commonly referred to as a patch. The difficulties and limitations of patching greatly vary between the different platforms and almost all of them have their own unique challenges.

The most common challenge with patching is the size of the patch. This can range from less than a gigabyte to no limitations. Further optimization of the game size can be a solution to this, however, not all limitations are hard limitations, and some can be lifted or extended after negotiating with the platform holder. For example, we have had exemptions from this limitation because the updates added new characters to the game. Another strategy that can be used in some scenarios is putting the new content on a separate server and downloading this content from within the game.

Below is a short story about reducing patch sizes. This happened some years ago, on a project for the PS Vita.

Kick and Fennick – PlayStation Vita

Keeping a patch size small is always a good goal to have. The smaller the patch, the less players have to download, which means they can quickly get back in the game. On the PlayStation Vita however, disk space was also a factor.

At the time memory cards were expensive and many players did not enjoy installing a patch that was (nearly) as big as the game itself since it would just eat up the available space on their beloved handheld. When Kick and Fennick was released, it became clear that some fixes were needed, mostly edits to levels to prevent players from getting stuck. So just edit the levels, export, and make a patch, right?

Sadly the changes caused a lot of the data to mutate, and the patch ended up nearly as big as the game itself. After some attempts to limit the mutations to the data chunks, we opted for a different approach. We added some code to one of the scripts that was present in every level that would perform the level corrections programmatically (move this wall there, remove this jump platform here, rotate that block there a bit, etc.) after it was loaded and just before we faded the level in. The end result was that the patch was a lot smaller, quick to download, and required a minimal amount of added disk space.

Closing words 

This concludes the final article in the “black art of platform conversion” series, and signals the end of the series itself. As such, we would like to close with some final tips and recommendations:

1. Make sure to request first-party backend access early on in the development. Depending on the set-up and platform, getting access can take a while, and you want to prevent this from becoming a blocking issue.  
2. Merge your changes made for the adaptation back to the main game branch regularly. Fixes like performance improvements and controller support will also benefit the original game. Having parity also helps to maintain all versions and prevents carrying out the same work over and over again (manual merges, bug fixes, etc.).  
3. Make sure to set up your automated builds and continuous integration pipelines early on in the development.   
4. Take multiplatform development into account from the beginning. Design your code in such a way that it is easy to add new platforms later.  
5. When using Unity or UE4, try and stay up to date with the latest version as much as possible. In bringing the game to another platform, recent versions of the engine are often required to match the latest first-party SDKs and use the newest engine improvements. Keeping up to date with the engine may be easier and more beneficial than reverse merging the latest versions at the end of development. 
6. When using UE4, try to modify the engine as little as possible. Changing the engine will make merging future versions more cumbersome.  
7. Use industry-proven plugins like Rewired, Photon, Bink, etc., instead of reinventing the wheel. They will save you time and money and already support most platforms out there.  
8. Save game support is usually quite a lot of work, and there are no plugins out there for this problem. Make sure to design your code in such a way (by abstracting the platform-specific bits) that it is easy to add new platforms later.
9. Make sure to take localization support into account from the beginning. This is not necessary on PC (although it is still recommended), but on console it is required to localize the game into several languages.

A lot of the points mentioned above - and in this document in general - can be addressed by working with the right team. This is what Abstraction offers as standard; by setting up proper communication and establishing a good flow (regular back-merges, etc) we ensure that all the boxes get ticked on time, and then double and triple-checked.

What we get out of this is a reputation that gives us the chance to work on exciting new games with a wide range of partners. What the client gets out of this is peace of mind, a game that feels right at home on any console, and an open door for future collaborations.

So that about does it for the Gold Master, and brings us to the end of our six-part series on platform conversions. If you stayed with us this long you probably understand that the road from platform A to platform B is rarely a straight line, and often requires changing directions mid-jump. Getting a game to run on multiple systems, and even across different generations of consoles, is rarely a walk in the park, and Abstraction does it by employing engineers who are at the top of their field and are not afraid to think outside the box.

As we have stated several times in our articles, we believe that every adaptation deserves to be considered as “the best way to play the game”, and thus we are always trying to squeeze as much as we can out of the target platform to enhance the already great games we work on – putting the gamer’s experience first. From improving framerates and loading times, to streamlining systems like matchmaking or even adding new modes, Abstraction is committed to delivering beyond what is asked, and making our adaptations unique, stable, and future-proofed.

If you have any feedback or questions then please do not hesitate to get in touch – we would love to help in any way we can!

Ralph Egas CEO Abstraction		Erik Bastianen CTO Abstraction		Wilco Schroo Lead Programmer

Coen Campman Lead Programmer		Wouter van Dongen Lead Programmer		Balász Török Lead Programmer

Mike van Mourik Programmer		Ross Martin Programmer		Mark Pittam QA Manager

Savvas Lampoudis Senior Game Designer