Hi and welcome to the Wwise community!
To answer your first question directly: Yes, those two functions are conceptually similar, but they operate within different architectures.
Your FMOD example, FmodComponent->SetParameter(), sets a parameter on a specific event instance.
Your Wwise example, UAkGameplayStatics::SetRTPCValue(), sets a "Game Sync" value on a Game Object.
This distinction “Event Instance vs. Game Object” is one important difference you'll need to learn:
In FMOD, you generally set parameters on an event instance or globally. For example, MyPistolShotInstance->setParameterByName("Reverb", 0.8f);. This value is "local" to that one instance of the gunshot.
In Wwise, you rarely deal directly with “event instances”. Instead, you set values on Game Objects.
A Game Object is essentially a “property container” representing something in your game (a player, an enemy, a car, etc.). It holds all the current audio-related values for that entity.
When you post an event in Wwise, you must post it on a Game Object:
AK::SoundEngine::PostEvent("Play_Gunshot", MyPlayerGameObject);
Wwise then looks at MyPlayerGameObject, checks all its values, and posts the Play_Gunshot event using those values.
This is why your Unreal code looks like this:
UAkGameplayStatics::SetRTPCValue(nullptr, HealthValue, 0, this, "Health");
In this context, this (your Actor) is the Game Object. You are telling Wwise: "Update the Health value inside the property collection for this specific Actor."
The advantage of this is that the value persists (while the game object is registered). Any future event posted on this (like a "Player_Grunt_Pain" sound) will automatically read this new "Health" value without you having to set it again. In FMOD, you'd have to set that "Health" parameter on the new grunt instance all over again.
For more information see:
What are Game Objects? https://www.audiokinetic.com/en/library/2024.1.9_8920/?source=WwiseFundamentalApproach&id=what_are_game_objects
So you're definitely right that an RTPC is like an FMOD Parameter, but it's only one piece of the puzzle.
Wwise divides this concept into a broader system called Game Syncs:
RTPCs (Real-Time Parameter Controls): These are your floats. Exactly like FMOD Parameters, they are for continuous values like Health, Speed, Distance, or Stealth_Level.
Switches: These are for mutually exclusive, discrete states. This is what you'd use FMOD Labeled Parameters for. Examples: Surface_Type (Wood, Metal, Dirt), Weapon_Type (Pistol, Shotgun, Rifle), Room_Size (Small, Medium, Large).
States: These are global, systemic changes that affect many things at once. Examples: Game_State (Stealth, Combat, Menu), Player_Condition (Alive, Dead, Ethereal) etc..
See also:
What are Game Syncs? https://www.audiokinetic.com/en/library/2024.1.9_8920/?source=WwiseFundamentalApproach&id=what_are_game_syncs
Regarding your second Switch Container question, giving you a footsteps surfaces example:
In FMOD, to handle footstep surfaces, you'd create a "Surface" parameter. You'd then have Multi instruments on a parameter sheet and you will select the correct instrument with a parameter value.
In Wwise, you create a Switch Group called "Surface_Type" with Switches for "Wood," "Metal," and "Dirt." Then, you create a Switch Container and drag/assign your objects into the corresponding Switch slots (which may be Random Containers).
Now, the code is setting a clear, descriptive Switch:
AK::SoundEngine::SetSwitch("Surface_Type", "Metal", MyPlayerGameObject);
When you call PostEvent("Play_Footstep", MyPlayerGameObject), Wwise automatically plays the correct Object based on the current Switch value (Metal in this case, supposing Play_Footstep has a Play Action that targets the Switch Container).
A few more architectural differences worth noting:
Events are Logic, not Sounds: In FMOD, an Event is the sound. In Wwise, an Event is a set of actions (e.g., "Play Sound X," "Set Switch Y," "Stop Music Z"). It's a different way of thinking, but it's incredibly powerful and scalable. You're moving from "telling a sound what to do" to "describing the state of the world" and letting the sound engine figure it out.
Built-in Curves: Each RTPC in Wwise includes a curve editor. You can visually map game values to sound properties (like Volume or LPF).
You can save Attenuations, RTPC Curves, or Effect settings as reusable ShareSets, changing one updates all assets using it.
Since you are working in Unreal, I recommend checking out:
- Wwise Gyms on GitHub: Audiokinetic/Gyms
- Wwise Audio Lab sample in the Audiokinetic Launcher
These contain practical, engine-integrated examples of Wwise functionality (like RTPCs, Switches, and more).