Construct 3 icon

Construct 3

Documentation

Best practices

Published 8 Aug, 2017
879 words
~4-6 mins

Back up regularly!

Neither the hardware nor software in your computer is perfect. Computers fail and software can crash. Back up your projects to protect yourself from losing work. It is essential to also maintain off-site backups. If all your backups are in the same computer or saved to disks all in the same building, catastrophic events like fire, floods, theft or simultaneous hardware failure can cause you to lose all your work and backups together.

Cloud Save is a good way to save your work where it is safe in case of disaster. However it is wise to keep secondary backups anyway, in case you lose access to your account, or the service has an outage or even shuts down.

This advice is not specific to Construct. It is vital to adopt this practice for any work on a computer which is important to you. Do not wait until you've lost work before starting to do this. People lose work regularly from having poor backup practices. Don't be one of them!

Test on multiple platforms, browsers and devices

It is essential to test your game works as intended in a range of different systems. While Construct 3 games are based on the HTML5 standard which in theory is implemented the same on all platforms, in practice there are variations between browsers and devices (e.g. in performance, features, text rendering, etc). You should install a range of browsers on every device you have available and test with them all to ensure your game will work well for everyone. Remote Preview Paid plans only can help with this, especially since you can get anyone in the world to help test with their devices. You may also need to make test exports to check how your project works as published, since app containers like Cordova (for Android and iOS) can have differences too.

Support touchscreen devices

Many users now browse the web with touchscreen devices. If at all possible, you should design your game to also support touch input. Often you can simply use the Touch plugin instead of the Mouse plugin.

Recommended file formats

You may wish to prepare artwork and audio in other software before importing to Construct. These are the formats we recommend.

Images

Use 32-bit PNG (Portable Network Graphics) while preparing images. Be sure to select 32-bit if you are given a choice; the 8-bit or lower versions will degrade quality. 32-bit PNGs are lossless and fully support alpha-channel transparency. Note some images such as Microsoft Paint do not support PNG transparency. Use may need to use a different editor instead, such as Paint.NET on Windows.

You can choose different export formats like JPEG inside Construct to reduce the size of your finished project. However when importing you should still stick to 32-bit PNGs if possible, and leave Construct to recompress them when exporting. Construct does a lot of optimisation on export for you. It is unlikely that any third party tools or services will be able to beat Construct's existing lossless optimisations, unless they degrade the image quality. Remember there is no point optimising images before importing them to Construct since it stores them in projects as 32-bit PNGs with default compression settings; they are only optimised on export.

Audio

Use 16-bit PCM WAV while preparing audio. These are typically .wav files, but note that not all .wav files are 16-bit PCM. Importing a 16-bit PCM .wav file to Construct will automatically encode it to WebM Opus. PCM WAV files are lossless, ensuring there is no quality degradation while you prepare your audio files. Allowing Construct to perform the encoding ensures the encoding is only done once (so there is no unnecessary degradation), and that the correct format is used for support across a wide range of platforms.

Security

Never enter usernames or passwords in to events. These will be visible in plain text in the exported Javascript, and malicious users will very quickly be able to take control of the account. If you need to connect to something like a database, write a server-side script that talks to the database, then connect to the URL of the server.

Performance

Always test on the target device from the start, especially for mobile devices. Your computer could be several times faster than your mobile device, and something which runs fast on your computer may be unplayably slow on the mobile device. Testing regularly on such devices also allows you to quickly spot any changes which have a big performance impact and revise it to be faster. Don't fall in to the trap of making an entire game before running it on mobile, realising that it's slow, and then having a very difficult job working out why. It is far easier to test as you go along. There are many more best practices to avoid poor performance - for more information see the section on Performance Tips.

Memory use

Some designers are tempted to design entire levels from lots of large image tiles. This method should be avoided since it is extremely wasteful with memory, and is not used by any professional game designers. The subject is discussed in detail in the blog post Remember not to waste your memory. See also the section on Memory usage.