I've been getting a lot of questions about how to prepare a Construct project for porting.
While a lot of porting advice applies to games in general, there are some specifics for Construct and Chowdren that might be interesting to know about!
Compliance
All consoles have compliance rules that you need to follow.
Some of these are fairly straightforward to follow, such as
- Terminology rules.
- Rules about button icons and other platform-specific visuals.
Others require more work or tuning, such as
- Achievement requirements.
- Controller/user profile requirements.
- Audio level requirements.
In Construct projects, if Sprite objects are used to show button icons, you could use a separate animation for each platform.
If you use a Sprite Font to show icons in text, you could have a separate character for each button icon that you pick depending on the platform.
Chowdren-specific note:
Chowdren implements achievements by transforming achievement unlocks from the Steam4C2 or Greenworks plugin into platform-specific achievement unlocks.
Gamepad inputs are translated to inputs in the Gamepad plugin.
The controller layout is based on an Xbox controller, so you only need to make sure that your game works with an Xbox controller.
Plugins
Most plugins are not an issue, but there are a few things to be vary of:
- Native plugins (the ones bundled with Construct) are used a lot more than non-native plugins. For that reason, if you use a non-native plugin, you are much more likely to hit an ACE or feature which hasn't been implemented in Chowdren yet.
- Plugins which require online functionality are a large hassle for a few reasons, so if your game is not a multiplayer game, try to steer clear of those.
Chowdren-specific note:
The list of plugins that are supported (as of this post) are listed here:
gist.github.com/matpow2/a574e81933e916f1831d41d34a9b5a86
Plugins are implemented on a demand-driven basis, so you don't have to limit yourself to this list only.
Memory
Most pixelart games tend to use small images and require little memory for visuals.
Other games with e.g. handdrawn visuals use much larger images, so to fit such images in memory, images have to be resized, switched in and out dynamically, or texture compression needs to be used.
While the particular strategy to use is usually handled from the Chowdren-side, you can help reduce memory pressure by keeping your images as small as needed.
Audio
Construct supports audio effects through the Web Audio APIs, such as compression and distortion.
Chowdren supports some of these through its audio mixer implementation, but new effects tend to take some time to implement.
Consider applying effects offline in your DAW or by some other means.
Effects
For most projects, the use of effects is usually not a problem.
However, the use of layout or layer effect stacks with many effects can be a rendering bottleneck.
Try to achieve as much as you can using smaller effect stacks.
Chowdren-specific note:
Chowdren merges effect stacks together into 1 shader, and can render most effects that sample the background without an intermediate buffer.
This reduces the overhead of shaders by a great amount.
I've only seen 1 or 2 extreme cases where I've had to do a special implementation for a large effect stack.
Performance
Consoles typically have hardware which is slower than PC hardware.
This applies to both the CPU and GPU. On some platforms, the CPU is mostly the bottleneck, while on others, both the CPU and GPU is.
As a general guideline, if your game runs acceptably on middle to high-end phones, performance is a smaller concern.
Chowdren-specific note:
Chowdren compiles events to C++, and events are practically never a bottleneck.
I haven't worked on a Construct game which had a CPU-side bottleneck on Chowdren yet.
Also, feel free to make liberal use of functions and event variables!
In C3, both event variables and function parameters are explicitly typed, which makes for a straighforward conversion to C++.
Scripting
A JavaScript scripting feature has been introduced in Construct 3.
While this gives a lot of flexibility to developers, you may want to limit the APIs you use to a smaller subset.
If you need to use any non-trivial DOM or ECMAScript features, it may be good to plan ahead and examine how these features would work on non-PC platforms.
In essence, don't shy away from using scripting in C3, but make sure you understand which APIs you are using, and try to use an API subset in a consistent way throughout your project.
Chowdren-specific note:
We have created an experimental JavaScript to C++ compiler which we will be using for Construct 3 scripts.
This is more than 1.45x times faster than JIT-less V8 on game-oriented benchmarks.
While this is super exciting, I think this is a topic better suited for another post :)
Conclusion
I hope that gave a good overview of how to future-proof your project for porting.
If there are other subjects you would like to see covered, please let me know!