# How do game designers create vibration patterns?

I am curious about creating and implementing vibration patterns for console controllers (for the PS4 controller, if it makes a difference).

There is a delay and motor speed parameter right? But also we can fade from left motor to right, or make them work together....

Is there a standardized way to create those patterns?

For example I thought about creating them with stereo wav audio in an audio editor and reading the wav file in my code to convert them to delays and speeds.

How is this done in the gaming industry?

• I have seen rumble systems driven through the game's audio pipeline, so you may be on track there. I can't speak from personal experience about the details though — whether there was a specific rumble track or if rumble was inferred from sound effect volume, or if the connection was purely to trigger sounds & rumbles through a consistent interface while they used entirely separate source data formats. Jul 12 '17 at 21:09
• You don't have that precise control over the rumble. Also, in a DualShock, the left rumbler is heavy and the right one is light, so you get low frequency from the one on the left. (I might have the left/right backward, but you get the idea).
– Almo
Sep 19 '17 at 18:02
• @Almo What about Nintendo's HD rumble system. You surely have some form of control over that Sep 19 '17 at 19:30
• Which would reveal the question to be too broad. I don't actually know about their system.
– Almo
Sep 19 '17 at 20:38
• @DMGregory The audio engines I'm aware of that handle rumble/haptics just use the same triggers, envelopes, etc - not audio waveforms. Like Almo says, you don't really have that level of control at the API level. I can't imagine Nintendo's system is much different - you wouldn't want to have to update any rumble system at such a high frequency where actual audio data was a good choice. Sep 21 '17 at 20:05

The PS4 dualshock controller has 1 byte values for the left and right rumble packs, so this basically works like 8 bit music.

Most of these are behind an NDA, so it's very hard to get any information about this (even the information above was hard to get, I only figured it out from a third party SDK for node.js). These are the informations I pieced together:

The process is literally like making 1 byte stereo music (and it's supposedly made by a music artist). It involves connecting a PS4 controller to the computer and using a program to create the rumble patterns. They make one based on guessing, then run it, then tweak it and repeat these steps until the pattern feels good.

Some of the rumbles are generated programatically (like when a car goes off the road), but these are usually either a simple function (like sinus) or a constant value similar to how phones do it. Even the most complex effects consist of multiplying a normalized rumble pattern by the strength you want.

The PS4 SDK also comes with some predefined patterns. Some examples are: a sawtooth pattern (constantly increasing, then going from 255 to 0), a sinus wave and triangles (it increases to 255 linearly, then back down to 0 linearly).

I couldn't find any details about other controllers (especially Switch's HD rumble, not even the patent describes how that works). But they're probably using a similar approach with more precise rumble packs.

### Sources:

• I found this article a while back which lays out the report structure for communicating back and forth to the controller, including the byte offsets of the rumble channels and the flag controlling them. It might be the most comprehensive available on the public Internet, without access to Sony's own documentation & APIs. Sep 20 '17 at 10:54
• @DMGregory Would you mind if I'd add that to a sources section? Sep 20 '17 at 11:13
• Please do. :) I shared it hoping to be of use. Sep 20 '17 at 11:15

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.

From André LaMothe in Tricks of the Windows Game Programming Gurus:

Programming these devices is very complex. Not only is a good understanding of force, spring, and motion needed, but the devices and the forces events, or effects, have a very close relationship to musical notes. That is, they can have an envelope that modulates the forces as they are applied to the various motors and actuators on the joystick. Thus, values like rate, frequency, timing, and so on all play a role in using and programming force feedback.

While that text is rather old, a quick search through the MSDN for force feedback shows the concepts mentioned haven't changed much; here's a summary of topics covered in their Basic Concepts of Force Feedback:

• Constant force: A steady force in a single direction
• Ramp force: A force that steadily increases or decreases in magnitude.
• Periodic effect: A force that pulsates according to a defined wave pattern.
• Condition: A reaction to motion or position along an axis.
• Envelope: An envelope defines an attack value and a fade value, which modify the beginning and ending magnitude of the effect.
• Offset: Defines the amount by which the waveform is shifted up or down from the base level.
• Scale: A single gain value can be applied to all effects for a device.

In terms of the PS4, the only thing I turned up was some Unreal Engine 4 documentation, which states:

These (identifiers) will be mapped according to the platform specific implementation. For example, the PS4 only listens to the XXX_LARGE channels and ignores the rest, while the XBox One could map the XXX_LARGE to the handle motors and XXX_SMALL to the trigger motors. And iOS can map LEFT_SMALL to its single motor.

As Stephane Hockenhull's answer indicates, each platform is different. And as suggested in the GDSE chat it's possible the details for PS4 force feedback API are NDA restricted.