mod.io

The product

mod.io lets game developers of any size add user-generated content (UGC) to their games, providing hosting, user profiles, subscriptions, moderation tools, and file delivery. Its REST API is the foundation. Official Unity and Unreal plugins, a C/C++ SDK, and a GameMaker integration sit on top of it. The Unreal plugin wraps the SDK in C++ and Blueprint interfaces and supports the most recent engine versions.

The developer problem

A studio meets mod.io through whichever layer fits its engine, so a single REST API has to make sense from C#, C++, Blueprint, and GameMaker. Each of those has its own idioms, and a sample written for one rarely carries over to another. The Unreal plugin also supports more than one engine version at a time, so every guide and sample has to say which version it was tested on and stay correct as new releases arrive. When plugin docs drift from the API underneath them, a studio loses time working out which of the two is wrong.

My focus

• Unity plugin features. I’d work in C# on the Unity plugin and check each feature against the REST API behavior it relies on before calling it done.
• Sample projects. I’d build small Unity and Unreal projects that each run a single flow end to end, such as subscribing to a mod and receiving its files, and run them in the engine before writing the guide.
• Blueprint coverage. I’d map how each SDK call surfaces in the Unreal plugin’s C++ and Blueprint interfaces, so designers and programmers each know where to start.
• API and SDK docs. I’d label every Unreal guide with the engine version it was tested on, and link REST API reference pages to the plugin calls that wrap them.

Why it fits my experience

• At Meta my developer documentation work spans Unity, Unreal Engine, and Horizon Studio, and I build the sample projects before documenting them, because a procedure that has not been run in the actual engine is a guess.
• At Meta I also maintain versioned documentation across concurrent SDK versions, including deprecation notices and upgrade paths for developers who cannot move to the latest release immediately.
• At Mitutoyo I worked primarily in C# on the .NET Framework, and I wrote the internal developer documentation and integration guides for the device APIs used by OEM partners.