Checklist for Release

Questions
#1

This is a question to those who have released a Defold game. I’m preparing for my first release and wondering if anybody has a “release checklist” or suggestions on:

  • Anything to double check (run scripts through linter, etc).
  • Post-development tasks (custom manifest trimming unused engine components, etc).
  • Other little things (app icon, etc).
2 Likes
#2

Which platforms are you releasing on?

1 Like
#3

I never released any paid game, only free and mainly HTML5, but for me it’s worth checking the game on different displays and in different resolutions - not only to verify V-Sync and speed of your game on different screens, but also - GUI and/or view scaling. You usually work on one or two display at best, so you usually adjust your GUI to be perfect on your screen. It’s worth noting, that sometimes it looks totally differently on smaller screens or different aspect ratio. It depends on a selected projection function a bit. Most of the fixes I remember to be making immediately after release were regarding such issues :smiley:

I sometimes see games, especially on Nintendo Switch that even long time after release have display issues, when playing on my TV (with some parts of interface even outside the screen), but looks suited to the built-in display.

Also, when I was releasing a MacOS demo of my Witchcrafter, many times actual users reported to me there were problems with it (I don’t have any Apple device to check it, but people to whom I was sending the demo were using it)

2 Likes
#4

To start, I would like to support Windows, Mac, and Linux since I have access to all three. Specifically Ubuntu, but I don’t know if the distro matters.

To be honest I don’t know if it is worth supporting Linux because most of the games I see released on Steam are Windows or Mac.

#5

For me, Linux (which includes Steam Deck), narrowly beats Mac sales. However they each represent about 3% of total sales.

3 Likes
#6

A couple of things that pop up for desktop releases:

People like their window size to be saved.

Keyboard shortcuts, e.g. adding support for Alt+F4 or toggling fullscreen.

5 Likes
#7

Linux (which includes Steam Deck)

Forgot about this! And I have a Steam Deck. Oops.

adding support for Alt+F4 or toggling fullscreen.

Developing on Windows, I have support for F11 fullscreen toggle. Since I’ve never used a Mac (but have one sitting on my shelf for development purposes in the future), I didn’t think of standard expectations with their keyboard. Thanks.

1 Like
#8

Another thing to consider is gamepad support and making sure your game handles connected and disconnected gamepads while playing. Especially disconnects due to running out of battery in the gamepad. Make sure you pause the game and pop up a gamepad selection screen or similar. Especially important if you also plan to release on consoles in the future.

Localization is another important thing to make sure you’ve covered before release. EFIGS at a minimum. Possibly more depending on where you plan to release the game.

App icon! Very important on mobile and web (poki.com for instance). You need to make sure your game stands out from the competition and the icon is often your first point of contact with potential players.

6 Likes
#9

Good point about pausing on disconnected gamepad. Steam will expect you to pause the game too when the overlay is brought up. Here’s how I do that:

		--overlay pausing
		local overlay_enabled = "GameOverlayActivated_t"
		steamworks.set_listener(function(self, event, data)
			if event == overlay_enabled then
				--pause stuff
			end
		end)

I would make sure to generate and capture error logs, so that users can send them to you. I use Err for that.

5 Likes
#10

For steam release, should also have a good understanding for the rules surrounding graphical asset capsules in the Steam Store.

some of the latest changes can be found here:

This one is worth noting if you do have localization for your game and text in your graphical assets.

∙ Must localize any text

  • Any text included on a graphical asset MUST be localized into at least the same set of languages supported by the game.
3 Likes
#11

This is true, however I would note that it doesn’t apply to the title, unless you choose to localise that.

This is my capsule for all languages:
image

And these are the languages I support:
image

It probably refers to things such as updating your graphical assets with temporary things like “New content!”. This is pretty hardcore, you can probably do fine without it.

5 Likes
#12

Are there any good guides out there for adding localisation to your games? Do you need to hire a localisation team?

#13

I think you should, if you’re really serious about the game. It’s quite easy to spot machine translations. I can recommend “Level Up Translations” and “Local Soft”. Both companies have done a good job when we’ve used them.

For really basic one word translations you can get away with PolyGlot: PolyglotGamedev - Google Sheets

5 Likes
#14

  • Android: you need to make sure to store the signing keys so that you can update your game.

  • Debugging: it is good if you save the debug symbols for each version of the gaem you upload.

  • Consoles: Store the complete bundles for each version, since you might need them if you want to patch the game (i.e. uploading bugfixes).

5 Likes
#15

Good point @JCash ! Also make sure to store the manifest.private.der and manifest.public.der files which are generated in the project root during the first bundle. These are the public and private signing keys for the game archive and archive manifest. You need these files in order to recreate a previous build of your game, for instance if you haven’t followed @Mathias_Westerdahl advice above! :slight_smile:

3 Likes
#16

Maybe we should compile these points into a list and publish it on the website somewhere? It seems very useful if I were to release a game

3 Likes
#17

Maybe I missed something, but here is my list.
Some of these points should be converted into tasks and implemented by default in templates/plists/default values and so on, but for now, I would recommend taking a look at these things.

All platforms

  1. Check counters for components in game.project. Using counters with values that are closer to the real count of components in collections with factories, will save the memory your game is using(See information about component max count optimizations)
  2. Similiar to the Node Count field in GUI components (each GUI has its own counter)
  3. Make sure you are using texture compression in your texture profile (see this manual). If you don’t know what to use try to start with this one as the default or a starting point for customizations:
  • mipmaps: false;
  • premultiply_alpha: true;
  • format: TEXTURE_FORMAT_RGBA;
  • compression_level: NORMAL;
  • compression_type: COMPRESSION_TYPE_BASIS_UASTC.

  1. Create and specify AppManifest for your game (see this manual). Exclude modules you don’t use in your game.

  2. Make sure you use the right Display settings (more info):

  • Most of the time you want to use High DPI;
  • For UpdateFrequency/Swap Interval/Vsync defaults most of the time the best fit.

  1. Resources in Bundle Resources copy/paste into the bundle folder as is. If you use images there, make sure you optimize the size and remove metadata. Also, it is up to you to make optimizations for the other file formats.

  2. Check this manual for performance optimizations.

  3. Check your bundle size report maybe you’ll find something you can improve.

  4. Size of your fonts will be smaller if you specify what symbols you gonna use from the fon and use them in Extra Characters instead of the All Chars checkbox.

  5. Make sure you save Symbols for each build you upload to a distribution platform. It will help you with crash symbolication in the future.

HTML5 specific

  1. Make sure you use minimal but enough for your game heap size. You can play a bit HTML5 version of the game in the most “heavy” level you have and then open inspector in the browser and write in the console: HEAP8.length / 1024 / 1024. Take this number add 10-15% and set it as Heap Size in your game.
  2. Make sure you handle the sound off when the user switches the browser tab or when you show ADS (if you use some html5 ADS framework).
  3. Don’t use too big a splash screen. Use webp version of the splash screen if it’s possible (this might help)
  4. It’s better to add a loading percentage number and some animated spinner on the loading screen. People need to be sure and see that loading is in progress.
  5. The Keyboard Show method doesn’t work in HTML5 because of the browser’s security policy. Make your in-game keyboard for input in HTML5 or use this trick.
  6. Check this checklist, most of the points are valid for any html5 game

iOS specific

  1. Make sure you specify Localizations in game.project. sys.get_info() will never return language which isn’t in this list.

Android specific

  1. Even if your game supports only landscape or only portrait, you may want a user to choose what size he should rotate the phone. In this case change the settings in your AndroidManifest.xml:
  • android:screenOrientation=“sensorLandscape”

or

  • android:screenOrientation=“userLandscape” (for API 18+)

(similiar for portrait “sensorPortrait” or “userPortrait”). I think we will do it by default in the next version together with NDK/Android SDK update.

2. Upload symbols to Google Play together with a bundle uploading:

  • Add to archive symbol-folders for both architectures YourProjectName.symbols/lib/arm64-v8a and YourProjectName.symbols/lib/armeabi-v7. So in the root of your archive should be two folders: arm64-v8a and armeabi-v7
  • Upload it
    Screenshot 2023-01-29 at 16.01.53
    Screenshot 2023-01-29 at 16.01.532426×426 47.2 KB

UPD: Android p1 implemented by Default in 1.4.3

17 Likes
#18

Ah, I was wondering about that field. Does this also go into the app bundle plist (or something) so Apple can list your supported languages?

#19

Exactly!

2 Likes