plutonium-sdk-example: How Plutonium turns Call of Duty modding into a real SDK
A tiny C++ template swaps offset chasing for commands, callbacks, GSC hooks, and a build path that looks like normal software.
- Plutonium turns a brittle modding workflow into a small, legible SDK with commands, callbacks, GSC hooks, and scheduled work.
- The example repo is doing editorial work as much as technical work, because it teaches the shape of the platform instead of dumping raw APIs.
- `dllmain.cpp` is the center of gravity, but `premake5.lua` is part of the product because it makes the plugin reproducible and portable.
- The template matters because it replaces tribal knowledge with a stable extension surface that feels closer to normal software development.
The surprising part is not the code, it is the abstraction
The first thing `plutonium-sdk-example` changes is the reader’s mental model. A mod is no longer a pile of offsets, ad hoc hooks, and folklore. It becomes a plugin with a lifecycle, services, and clear entry points.
That is why this repo matters. It does not just show how to compile a DLL. It shows how Plutonium wants developers to think: register behavior, expose script functions, react to callbacks, and let the runtime handle the nasty parts.
Why Plutonium ships an example repo at all
An example repo is the right artifact for a scene like this because it teaches the expected shape of the work. The README is not only documentation. It is a living spec for how a plugin is supposed to feel once it is installed, loaded, and talking to the client.
This project contains source code that aims to demonstrate how to compile the example plugin shown in our documentation. In dllmain.cpp, you will see how every function exported by the SDK can be implemented in your plugin.
That framing is important. The example is not trying to be the most advanced plugin in the ecosystem. It is trying to make the first successful plugin boring in the best possible way.
dllmain.cpp is the whole playbook
The heart of the repo is `src/dllmain.cpp`. There, a `plugin_impl` class sets metadata, declares game support, and receives an `iinterface*` during `on_startup`. That pointer is the interesting bit. It opens the door to logging, GSC, callbacks, and the scheduler through one narrow surface.
That is a service locator pattern, but in a pragmatic plugin shape. It keeps the example readable while still showing how a real extension point works. The code also uses a global pointer so helper functions can reach those services, which is a trade-off, but an understandable one in a small template whose job is to teach the flow quickly.
The build system is part of the story
`premake5.lua` is not housekeeping. It is policy. The file sets up an x86 shared library with a static runtime and precompiled headers, which means the template is trying to remove setup variance before anybody writes mod logic.
That matters for a plugin ecosystem. If the build path is fragile, every new contributor starts by fighting the toolchain instead of learning the SDK. This repo gives them a clean project generator, a predictable Windows build, and a sensible default for shipping a DLL that can stand on its own machine.
The Plutonium team strongly recommends adopting Premake5 to expedite the development of your plugins. We have chosen Premake for its utilization of the simple yet powerful scripting language called Lua.
That recommendation is about more than convenience. It tells you the team values reproducibility, a small dependency surface, and a build workflow that feels familiar to C++ developers who do not want a custom toolchain just to say hello to the game.
What this replaces
The contrast is sharp. Old-school CoD modding often means manual offsets, patched addresses, and a constant risk that a small change will break a fragile assumption. Plutonium’s example template replaces that with named services and a lifecycle that looks like normal application code.
| Old-school CoD modding | Plutonium SDK example |
|---|---|
| Find offsets, patch addresses, hope the build survives | Generate a clean DLL project with Premake and a fixed target shape |
| Hand-rolled hooks and brittle glue | Commands, callbacks, GSC, and scheduler calls through the SDK |
| Manual thread juggling and a lot of caution | Work is routed through the scheduler and the right runtime context |
| Custom bridges written feature by feature | Expose C++ functions to GSC through the plugin interface |
| Tribal knowledge and forum archaeology | An example repo that teaches the expected mental model |
| Every update can break assumptions | Higher-level APIs reduce how much low-level breakage you own |
The broader lesson: SDKs can civilize a hobbyist scene
The deeper value of `plutonium-sdk-example` is not that it helps one plugin compile. It shows what happens when a community stops relying on hidden knowledge and starts building on a stable interface. New contributors can learn the shape of the system faster, and existing ones can spend more time shipping features instead of re-deriving the platform.
That is the quiet win. Good SDKs do not just expose functionality. They change the culture around a platform. They make extension feel like software engineering, not archaeology.