[2021] May 2021 Development Update

Anecdotes from the past month of gamedev.

It feels like this month flew by! Looking back on the various completed work does not line up with how busy it seemed. Here are some of the more interesting points.

Kuwait

Refactoring weather to support sandstorms for Kuwait started late last year, and I was quite slow to finish it as the update notes or Animatic and NSTM can attest. We can also thank this for the recently added lightning strikes. They were fun, but very loud to develop, and the first newly new vanilla feature in some time.

Animatic and NSTM prepared several mythical effects for the map. Unfortunately they were not released because there is not a good system yet for non-unboxed mythicals. I had intended to do a feature for purchasable tools or crafting the Kuwait mythicals, but there are more side effects than may be apparent:

Non-preset mythical cosmetics will require some extra per-item data. This affects display cases, storage, mannequins, the character itself, etc. Unfortunately the current entanglement of netcode with savedata makes this difficult to change, so I hope to resolve it after savedata gets a rewrite.

Server List Moderation

I had not been planning to do the recent monetization rule changes. They sort of popped out of the blue. For anyone curious here is the forum thread: RFC: Banning Purchase of Individual In-Game Items

While gathering feedback I experimented further with Unreal mod support. More details on this below and in the previous blog post. Then all of the feedback proposed changes, namely a monetization filter, server info screen links, and tools for moderating the server list have been implemented.

Unturned Cleanup

There are a variety of long-term cleanup goals on the roadmap like Asset Consolidation. Following an error related to audio file consolidation it occurred to me to port over some of the Jenkins editor code from Unturned II. Slowly but surely the project is becoming more sanity-friendly.

Blender Preferences

To simplify switching between Blender versions I decided to setup all my preferences from a python script. One step I found particularly useful was generating export presets. Automatically writing files to the scripts/presets/operator/export_scene.fbx folder will add them to the FBX exporter presets menu. This helps when manually exporting switching back and forth between Unity and Unreal.

Unturned II Unreal Modding Compatibility

As mentioned in the previous blog post, I was curious to experiment with modding compatibility between source builds of the engine and launcher "Rocket" builds. (Not to be confused with RocketMod) This would have the benefit of enabling mod support early without getting permission to distribute a custom engine fork.

I did get it working in a hobby project with this setup:

1. Replace Build.version with rocket Build.version. This keeps the changelist and buildid compatible between source and rocket. Theoretically buildid could be overridden as part of packaging the mod project, but the module manifest APIs are not public as of 4.26. With some effort the changelist could be overridden during ResavePackages, but that would require custom changes to the BuildSettings module.
2. Create a UAT project for the game with a BuildCommand for packaging the mod editor.
3. In the build command copy all of the relevant project files to a temporary directory. Here we can exclude any files that cannot be redistributed, for example licensed audio.
4. From the build command run ResavePackages on the copied project to reset any references to excluded assets.
5. From the build command run Cook on the copied project with the CreateReleaseVersion switch. This is used when packaging DLC (mods) to determine which assets are already included in the base game. Epic recommends doing this for the non-mod project, but I think it makes more sense to do on the copied project because this way there are no references to excluded assets, and the mod cannot reference assets which do not exist in the mod project anyway.
6. From the build command run DerivedDataCache with -Fill -DDC=CreatePak -ProjectOnly to prefill the derived data cache so the project is quick to open for modders. Again this must be done on the copied project because presence of certain files will change the DDC keys.
7. From the build command re-gather the project files, including DDC and releases now, and copy them to a final directory to exclude all of the temporary files created by running the commandlets.
8. Finally in the build command resave the .uproject file with the target engine association.

This mod project can then be opened in a rocket build of the engine, and packaged mods are still compatible with the source shipping build. Epic's plugin mentions a source build is required to package mods, but you can use BuildCookRun in rocket instead. For example here is my test command line:

FString CommandLine = FString::Printf(
	TEXT("BuildCookRun -Project=\"%s\" -DLCName=%s -BasedOnReleaseVersion=Vanilla -SkipBuild -Cook -Stage -Pak -DLCIncludeEngineContent -TargetPlatform=Win64 -ClientConfig=Shipping -Manifests"),
	*FPaths::GetProjectFilePath(),
	*InPluginName);

One downside is that the mod project binaries need to be compatible with rocket engine binaries. This is fine as long as there are no major engine changes in the source custom fork. I think the trade-off is worth it. A source build is necessary for a variety of reasons e.g. dedicated servers, tweaking hardcoded constants (like the SigningIdentity as of 4.26), but I think I over-complicated things with some of the changes for Unturned II like anim subgraphs that are now better supported by Epic.

Next I think I will start porting the project to a more vanilla source build, and make the mod project available for rocket once it is "playable". I did also submit by first engine pull request for a simple bug which got accepted (yay!), and hope to continue with some other PRs, but the stakes feel so much higher than modifying my own local build. Based on the forum feedback to the previous blog post it seems this revision to mod support and base building are a good refocusing of development.

Part of me wants to give the project files a better code name, and this would be a good opportunity. Something about U4_* prefixing everything bugs me because it has the number and underscore. Unturned in Unity is just called Unturned, but it would be confusing to just call this Unturned as well. I kind of like the name "Theseus" as in the Ship of Theseus because so many parts of Unturned II have been rebuilt already, but the naming in code like STheseusWidget or ATheseusActor might look too much like "the seus".

The post May 2021 Development Update appeared first on SDG Blog.