There's no standardized way.

Different devices have different rumble capabilities and limitations.

The most common is with two DC motors with an unbalanced load each, one being weighted heavier than the other and with no precise speed control.

At the minimum you have on/off control over them and can do some limited PWM power control but not exact speed control. You don't know what the speed and the resulting vibration will actually be. Different controllers have different motors and weights that will run at different speeds for the same setting.

The motors have to spin up first and require full power for a bit of time then can be PWM to a lower setting. The spin up delay greatly limits the responsiveness.

The controllers are often updated once per frame giving you roughly 20Hz to 100Hz update frequency. This limits the resolution of your PWM control as you don't want the motors to stall at the lowest setting. And you don't know how low the end user controller's motors can go before stalling (stopping) so you need a good safety margin.

Some system requirements put further limit on what you can do with them.

Mobile devices usually only have 1 vibration motor and PWM may not be possible due to the low inertia from the size of the weight and slow update rate. The system may filter it further to prevent abuse or maybe even damage (power driver transistor limits and induction spikes) or just a really slow GPIO subsystem.

On mobile you may be limited or want to limit yourself to "vibrate for roughly X*50 milliseconds" without PWM.

Some newer devices and controllers have a solenoid driven like a speaker by a low sample rate audio wave. These give you more control but are completely different from the more common controllers.

Because of all these differences you may want to abstract the vibration system to play a limited number of high-level macro-effects by name in a shoot-and-forget fashion: PlayVibration(player, "Got Loot");, PlayVibration(player, "Heavy Fall");, StopAllVibrationFor(player);, ...

Then you will have to create low-level vibration effects and vibration control code adapted to each platforms individually.

There's no standardised way.

Different devices have different rumble capabilities and limitations.

The vast majority of devices don't support actual "force feedback" (eg: A steering wheel that when hitting a curb/pothole would allow the programmer to push back to a specific angle) but just rumble in some uncontrolled/arbitrary direction.

So most of the Force Feedback features mentioned on MSDN/DirectX and other APIs have never really materialised in practice on the user market or have such poor and/or non-portable implementations of the "smart" controls (envelope, repeat, etc) as to be so unusable that in practice developers are often forced to just use the ON/OFF controls directly with their own effect implementation.

More advanced devices that allow servo-controlled force feedback need custom APIs as generic input APIs don't support the necessary parameters (exact angles, exact forces, limits, etc).

Adding emerging technologies like VR feeling-gloves into the mix make those generic APIs are even more lacking.

The most common implementation is with two DC motors with an unbalanced load each, one being weighted heavier than the other and with no precise speed control.

At the minimum you have on/off control over them and can do some limited PWM power control but not exact speed control. You don't know what the speed and the resulting vibration will actually be. Different controllers have different motors and weights that will run at different speeds for the same setting.

The motors have to spin up first and require full power for a bit of time then can be PWM to a lower setting. The spin up delay greatly limits the responsiveness.

The controllers are often updated once per frame giving you roughly 20Hz to 100Hz update frequency. This limits the resolution of your PWM control as you don't want the motors to stall at the lowest setting. And you don't know how low the end user controller's motors can go before stalling (stopping) so you need a good safety margin.

Some system requirements put further limit on what you can do with them.

Mobile devices usually only have 1 vibration motor and PWM may not be possible due to the low inertia from the size of the weight and slow update rate. The system may filter it further to prevent abuse or maybe even damage (power driver transistor limits and induction spikes) or just a really slow GPIO subsystem.

On mobile you may be limited or want to limit yourself to "vibrate for roughly X*50 milliseconds" without PWM.

Some newer devices and controllers have a solenoid driven like a speaker by a low sample rate audio wave. These give you more control but are completely different from the more common controllers.

Because of all these differences you may want to abstract the vibration system to play a limited number of high-level macro-effects by name in a shoot-and-forget fashion: PlayVibration(player, "Got Loot");, PlayVibration(player, "Heavy Fall");, StopAllVibrationFor(player);, ...

Then you will have to create low-level vibration effects and vibration control code adapted to each platforms individually.

Even for a music game calling one-shot PlayVibration for every beat is easier to manage and control when factoring in pausing the game and the issues of re-syncing a would-be-smart periodic effect generator.

While devices with an actual solenoid-driven rumble can be treated like an audio device and use audio APIs due to battery concerns this may run afoul of the system's regulations if the solenoid is constantly powered/active. "Power Level 0" may not be the same as "Solenoid Off" so even then special care is needed.