GC FSM still under review

GC FSM is still under review from the Unreal Marketplace team. The process is taking a bit longer than expected… I can’t really blame the guy that has been assigned to review my plugin, it’s the process itself that isn’t very seller-friendly, especially for newcomers. Here are my considerations, written as a list of advices, hoping to help anyone who is planning to publish a code plugin on the marketplace (including my future self).

Most important advice

Be patient. I mean, very patient. It took four days for someone to be assigned to handle my submission. It might be that I was unlucky to have submitted while Unreal 4.19 was being released, though. The good thing is that once a reviewer has been assigned, you always interact with him. I’ve seen review processes where you get to talk to multiple people and you have to explain everything each time all over again because no one reads the previous conversations.

The difference in time zones hurt. Badly, especially if you live in Europe. Apparently, my reviewer works on my case only during the afternoon, so I have always received feedback late in the evening. Not only this is the most unfurtunate time for me to receive feedback, but I also have little time left to react before the reviewer’s end-of-day… This means that every change requested by the reviewer means you typically lose an entire working day.

By the way, the review seems to follow a checklist and every single step has to be validated before proceeding to the next step. This means, for example, that if there are problems with the metadata, the reviewer won’t even try to compile your code. If the reviewer reports a compilation error on Windows, you cannot be sure that you don’t have the same or other errors on some other platform, since those haven’t been tested yet… and so on.

Copyright and metadata

Check the copyright statements on all source files (including .build.cs files). They do check them and they require them to be correct.

Be sure the .uplugin file has a WhitelistPlatforms metadata for all modules included in your plugin and be sure that the list matches the list of supported platforms that you provided in the marketplace submission. They problem with this requirement is that the WhitelistPlatforms  is actually undocumented and there’s no exact match with the list of supported platforms on the Marketplace submission form… I lost two working days in back-and-forth communications to get the list correct, so I’m sharing it here: as for Unreal 4.19 the list of identifiers that can go in WhitelistPlatforms is the following: “Win64”, “Win32”, “Mac”, “Linux”, “PS4”, “XboxOne”, “Android”, “IOS” and “HTML5”. Well, that’s the list I receieved from my reviewer. I believe at least two platforms are missing, namely “TVOS” and “Switch”, so it might not be exhaustive, but it’s ok for what the submission process is concerned. By the way, the list of supported platforms on the Marketplace submission form is the following: Windows, Mac, PS4, iOS, Android, Xbox One, Oculus, SteamVR / HTC Vive, Gear VR, Linux, and HTML5. As you can see, Windows matches two identifiers (Win32/Win64), while the three VR platforms don’t match any. Apparently, they match their respective underlying OS identifiers.

Building

Do not trust building the plugin in Visual Studio. The method suggested by the documentation is to use the “Package” command in the Plugins windows of the Unreal Editor. That’s safer, but it will try to build the plugin for all the whitelisted platforms… and thus most probably fail at it, since you can’t build on most of them unless you are very resourceful and can afford a setup with all the necessary hardware and SDKs and use remote compilation.

Instead, do as the reviewer will do: compile your plugin with following command

call PATH_TO_UNREAL \Engine\Build\BatchFiles\RunUAT.bat BuildPlugin -Plugin=PATH_TO_UPLUGIN -Package=OUTPUT_DIR -TargetPlatforms=PLATFORMS

Where:

1. PATH_TO_UNREAL is the path to your installation of Unreal (with sources)
2. PATH_TO_UPLUGIN is the path to your .uplugin file
3. OUTPUT_DIR is a path to a directory that will receive the build. This directory shall not be in the same directory of the .uplugin file (nor any subdirectory)
4. PLATFORMS is the list of platforms separated by ‘+’ (e.g.: Win32+Win64+Android)

Be aware that your machine probably has files that won’t be present on the reviewer machine. This is because you most probably built the entire editor from the sources, therefore you will have a lot of compilation by-products in the Intermediate directories of your Engine folder. The reviewer machine will use a clean setup and won’t have any Intermediate file that is not the produced by the RunUAT command above. I learned this the hard way when my reviewer reported a linker error while compiling my plugin. There was a dependency between my plugin and file UE4Editor.lib. I was never bothered by that, because that file is built every time I launch the editor from Visual Studio, but the reviewer’s machine didn’t have it. It took me some investigation to understand that the dependency has been introduced inadvertently simply by mentioning the “Launch” Unreal module in my .build.cs file. Fortunately, I didn’t need that module.

In theory, if you want to target several platforms, you really should compile to all those platforms. However, if that is not possible, my advice is to test at least two different platforms. Since I work on Windows, in addition to Win32 and Win64, I also built for Android, because that’s the easier one to setup (hint: just install AndroidWorks, the installer is shipped with the Unreal sources in folder .\Engine\Extras\AndroidWorks). This is important since Windows will use the Microsoft C++ compiler, but Android will use the clang compiler. Despite your efforts to write good and portable C++, code that compiles with one compiler might not compile with the other. Be aware that there are a few warning messages that are disabled by the Unreal toolchain on the Microsoft compiler, so you won’t ever notice them, but are treated as errors on clang!