I am making my next horror game and i don't want to repeat mistakes i did in last one. I want you to look at Liar Masks on Steam, and just by seeing the store page tell me would you have be interested in buying it or not. If not then why....

It's a humble request from a dev, please be honest...

I am making my next horror game and i don't want to repeat mistakes i did in last one. I want you to look at Liar Masks on Steam, it's already released, and just by seeing the store page tell me would you have be interested in buying it or not. If not then why....

It's a humble request from a dev, please be honest...

Game Blueprints

Suppose you are playing GTA5 or minecraft, we will learn everything with their example.

1. GameUserSettings:

When you open gta5/minecraft and if you have selected frame rate to maximum 60 last time when you exited the game, it will still be locked at 60FPS.
Saves .ini file for your game, this .ini files executes at the very first to set windowed mode, vsync and framerate cape like settings. In your options menu you can allow the player to set them directly through this class and UE handles it automatically.
It can be done through game save manually but that does not make sense.

1. GameSave:

Last time you completed a mission of gta or found diamonds in minecraft, when you come back next time, they are still there.
Gamesave allows you to save variables that you can use while loading the game level next time. For replication of minecraft worlds or GTA5 save slots there are inputs called slot-name while saving the game.

1. GameInstance:

You selected online mode in gta and wow rockstar opened story mode, this does not happen because gameinstance is there to pass variables between levels. If you have a variable that you don’t want to save but keep it until the game is on you put it here. Gameinstance only persists through a game cycle, after its variables go to default.

1. Level:

In gta 5 there are 2 major levels, one is the main menu another one is the city where we f around. For different slots or different worlds of minecraft there are not different levels, there’s just one WORLD level notch made and he brings variables from save game to make it look like the game you left last time.
Levels are hard to explain but as you progress you know what it is.

1. Animation Sequences:

These are created through sequencer and the timeline window. These are cut scenes of a gta game.

1. GameMode:

This is what tells a level that when a player clicks play, which character to use, which controller to use, which hud class (UI) to use. It's setted through the world settings tab.

1. PlayerController:

You have a superhero game where you can become iron man and spider man. The player controller defines what’s in common, usually we put the logic of looking around in the level with mouse input, as both spidy and tony can look around. Apart from that we put pause menus, inventory (if both share the same inventory) and showing mouse cursor or hiding it when we’re navigating through UI or playing the game.
For a multiplayer game every player playing only has one controller, for a co-op game every physical player playing has exactly one controller. For a real human being playing a level there’s exactly one Player Controller.

1. Pawn/Character:

A level can be controlled through a pawn or a character, character is a child blueprint of pawn with more modules such as Movements.
We design 2 different characters for iron-man and spider man as they both have different sorts of gameplay. Gta’s michel franklin and travor are children of the same character blueprint, this line you might not be able to digest yet if you’re new in ue5. But let me clear, gta5’s all three character walk drive shoot the same way, making 3 different character classes would be a waste of time and memory. Instead you created one master character that can walk, shoot, talk, drive and made children of this blueprint so that you can give them a different body (skeletal mesh), different voice, and different superpowers (like slowing the time or so).

1. HUD class:

I don’t use it, it basically allows you to build that UI of map, gun switching and the main hud we see while playing the game. We usually do it with character and controller class.

1. GameState:

In an online game you see some variables are common for everyone, like players alive of PUBG/FORTNITE. It’s here, we put all the logic of global rules like in PUBG new state you can make an enemy your teammate after knocking him out, that logic relies here, all the teams logic and so on.

1. PlayerState:

The simplest explanation is if you have kept inventory turned off in minecraft when you die, inventory items drop in the world, which you do with player state. If keep inventory is on then you save inventory in game save. Although in real minecraft in both cases inventory is saved in gamesave. In the player state you put variables that you want to set default when the player dies.

1. Spectator Class:

In fornite and pubg when waiting for revival you can roam around freely in the world, no collision nothing whatsoever, just a flying camera and controls. You put logic like the spectator class should not be able to see/hear other than his teammates as in case they can tell the location of enemies through flying to their teammates.

>This is a part from unreal engine notes i have recently started to write. Feel free to correct me, i can be wrong at some places, fee free to add on things. I would love to add that to my notes

Game Blueprints

Suppose you are playing GTA5 or minecraft, we will learn everything with their example.

1. GameUserSettings:

When you open gta5/minecraft and if you have selected frame rate to maximum 60 last time when you exited the game, it will still be locked at 60FPS.
Saves .ini file for your game, this .ini files executes at the very first to set windowed mode, vsync and framerate cape like settings. In your options menu you can allow the player to set them directly through this class and UE handles it automatically.
It can be done through game save manually but that does not make sense.

1. GameSave:

Last time you completed a mission of gta or found diamonds in minecraft, when you come back next time, they are still there.
Gamesave allows you to save variables that you can use while loading the game level next time. For replication of minecraft worlds or GTA5 save slots there are inputs called slot-name while saving the game.

• Saving game first time:

https://preview.redd.it/9goprsn8fhih1.png?width=1112&format=png&auto=webp&s=4c03b30489112aa763efc7c84a4f6a290269bdf0

• Getting a saves variable from a slot:

https://preview.redd.it/or40run8fhih1.png?width=1017&format=png&auto=webp&s=cd5f28ece074482a1536c18bbf0aef0041e2fb4c

• Saving a variable to slot:

https://preview.redd.it/xhlkbrp8fhih1.png?width=1209&format=png&auto=webp&s=b8e65850af6e4cff174d29564a8bae9c5f61956b

1. GameInstance:

You selected online mode in gta and wow rockstar opened story mode, this does not happen because gameinstance is there to pass variables between levels. If you have a variable that you don’t want to save but keep it until the game is on you put it here. Gameinstance only persists through a game cycle, after its variables go to default.

1. Level:

In gta 5 there are 2 major levels, one is the main menu another one is the city where we f around. For different slots or different worlds of minecraft there are not different levels, there’s just one WORLD level notch made and he brings variables from save game to make it look like the game you left last time.
Levels are hard to explain but as you progress you know what it is.

1. Animation Sequences:

These are created through sequencer and the timeline window. These are cut scenes of a gta game.

1. GameMode:

This is what tells a level that when a player clicks play, which character to use, which controller to use, which hud class (UI) to use. It's setted through the world settings tab.

1. PlayerController:

You have a superhero game where you can become iron man and spider man. The player controller defines what’s in common, usually we put the logic of looking around in the level with mouse input, as both spidy and tony can look around. Apart from that we put pause menus, inventory (if both share the same inventory) and showing mouse cursor or hiding it when we’re navigating through UI or playing the game.
For a multiplayer game every player playing only has one controller, for a co-op game every physical player playing has exactly one controller. For a real human being playing a level there’s exactly one Player Controller.

1. Pawn/Character:

A level can be controlled through a pawn or a character, character is a child blueprint of pawn with more modules such as Movements.
We design 2 different characters for iron-man and spider man as they both have different sorts of gameplay. Gta’s michel franklin and travor are children of the same character blueprint, this line you might not be able to digest yet if you’re new in ue5. But let me clear, gta5’s all three character walk drive shoot the same way, making 3 different character classes would be a waste of time and memory. Instead you created one master character that can walk, shoot, talk, drive and made children of this blueprint so that you can give them a different body (skeletal mesh), different voice, and different superpowers (like slowing the time or so).

1. HUD class:

I don’t use it, it basically allows you to build that UI of map, gun switching and the main hud we see while playing the game. We usually do it with character and controller class.

1. GameState:

In an online game you see some variables are common for everyone, like players alive of PUBG/FORTNITE. It’s here, we put all the logic of global rules like in PUBG new state you can make an enemy your teammate after knocking him out, that logic relies here, all the teams logic and so on.

1. PlayerState:

The simplest explanation is if you have kept inventory turned off in minecraft when you die, inventory items drop in the world, which you do with player state. If keep inventory is on then you save inventory in game save. Although in real minecraft in both cases inventory is saved in gamesave. In the player state you put variables that you want to set default when the player dies.

1. Spectator Class:

In fornite and pubg when waiting for revival you can roam around freely in the world, no collision nothing whatsoever, just a flying camera and controls. You put logic like the spectator class should not be able to see/hear other than his teammates as in case they can tell the location of enemies through flying to their teammates.

>This is a part from unreal engine notes i have recently started to write. Feel free to correct me, i can be wrong at some places, fee free to add on things. I would love to add that to my notes

Hello guys, I have developed 3 indie horror games on steam (all failures). I hated/disowned them at first (hated saying 'I developed these') but someone said me, if these would have worked would you still hate them and i said NO. It finally convinced me that failed games does not mean you hate them. I just have started building my portfolio and a linkdin profile. I want to develop games for my lifetime now and deliver 100 failed games but something i am proud of.

Please have a look at it (in comments). give suggestion/feedback you have.

https://preview.redd.it/kktlzdv5j6ih1.png?width=1919&format=png&auto=webp&s=115e38b682b98f5675d15227de8fd2e1044c5a7e

You get a call from one of your friend, You wanted him to search something cool to play when bored. You live in middle of a forest in a manor, and he gives you dare to play "one man's hide and seek"

You find doll, scissors and rice and start the game. Here comes the core loop, you put salt water in your mouth and you have a glass of salt water in your hand as well. Now you need to find the doll and spit the water on her + the water from the glass to end the game.

If you speak irl water from your mouth spills, if you run fast water from your glass spills. Here is one more issue, when you have water in mouth the doll teleports far from you, if you don't end game in 15 minutes you are going to die anyway, so you spill water by speaking out loud in mid knowingly so she chases you and put water again in your mouth at perfect time to spit on her and end the game.

THIS IS THE GAME I AM DEVELOPING IN UNREAL ENGINE RN, IT'S A SMALL GAME, WOULD YOU PLAY THIS (IF YOU PLAY HORROR VIDEO GAMES)

Sorry for asking it here i don't have enough karma for unrealengine sub, and ue4 sub is dead.

So umg navigation system like default keys up down left right and enter or controller left joystick, unreal have a default way to make kinda navigate through them and yk press A on controller to click that button and stuff

But it feels to broken to me, am i just not using it correctly or most people replace it with their own?

NIAGARA

Niagara Emitters:

Niagara emitters as the name suggests are single emitters that can emit particles of one kind. Multiple Niagara emitters can be combined to create a good VFX effect.

• Niagara emitters can have their own time or global time for example time of the niagara system that owns them.
• A Niagara emitter can be an asset on its own if you want to reuse it, and it can directly sit on a Niagara system as well.

Emitter Stack:

1. Sim target: it is the simulation target, whether the CPU or the GPU should solve the particles. Use cpu when “you need particles to give output like where they hit”, “a few 1000 particles only”. Use gpu when “you do not require particles to calculate their hit locations, dumb particles”, “can solve millions of the particles”. -GPU sim particles can still receive information from blueprints, it just can’t output information.
2. Calculate Bounds Mode: How the bounds should be calculated, if you see your particles disappearing when slightly looked away, it’s the culprit here. Fixed bounds are easy on performance.
3. Local/World Space: Local space particles move with the emitter and do not leave a trail whereas the world space particles do so.
4. Determinism: whether the randomness be truly random or based on a seed number provided.
5. Interpolated Spawning: spawn particles in between if a particle is moving with a faster speed, like a bullet trail can leave dots.
6. Event handlers: See Below...

>

It allows non vfx artists to tweak variables to get desired effects. Any variable can be set as emitter summary by right clicking on parameter and “show in summary”

1. Emitter Stage

• Spawn: Runs once when the emitter starts its loop.
• Update: Run every single frame that the emitter is "active."
• Example Modules:
  • Spawn Rate: "Spit out 50 particles every second."
  • Spawn Burst Instantaneous: "Spit out 10 particles right now at the start."
  • Emitter State: Decides if this specific emitter loops or runs once.

2. Particle Stage

• Spawn: Runs once when the particle is spawned.
• Update: Run every single frame for every single particle.
• Example Spawn Modules:
  • Initialize Particle: Sets the starting color, size, and lifetime
  • Add Velocity
• Example Update Modules:
  • Gravity Force
  • Solve Forces and Velocity: It actually does the math to move the particle based on the forces applied to it.

>

Multiple event handlers can be added from the properties panel, it's not there by default.
Example: Suppose a firework rocket goes up in the sky, when it dies we need to tell another emitter to spawn a burst of fireworks in the sky.
So we add the Generate Death event in the rocket’s update particle stage. Click + stage at the end of properties tab and add an event handler stage in the burst emitter, here we select rocket -> Death event. This stage now works like an execution stage when the death of a particle will happen in the rocket emitter. In this stage we add a module for the same event (death in this example) “receive death event”.

1. Death event: generated when particle dies
2. Location event: returns location of each particle
3. Collision event: generated when particle collides.

>

1. Sprite Renderer:

• Material of sprite can be changed here.
• Particle color nodes in the material graph are used to use the particle color in the material so changing the color parameter in the niagara affects custom material.
• The sprite pivot can be changed, which helps in rotation around the pivot.
• SubUV: subuv is a way to cut down the material into parts, choosing 10x10 will make 100 frames of the material uv’s we have. In the particle update stage, Animate SubUV module can be added to animate the SubUV frames.
• CutOut: It’s like a bounding box for each sprite, depending on how big area the sprite takes, we can decrease it by giving it a texture and choosing its alpha. For example a circle sprite will have a box bounding box by default, but if we pass its texture here and choose alpha, it will be like a circle now.
• Bindings: We can change the color of the sprite through the color parameter (particle namespace), but if we want some other parameter to affect it we can actually directly bind that variable to the color of the sprite. Till now we were doing

(particle namespace) color == (user namespace) MyColor
But now we do
Color (sprite renderer) == (user namespace) MyColor

• Sorting: More the sorting, the higher z-order the sprite render uses and displays over the sprite renderer with a lower sorting. Just like z-order in the CSS or layers in photoshop.

1. Mesh Renderer:

• Mesh can be changed here, multiple meshes are allowed at once.
• Material of the meshes can be changed here as well.
• More attributes related to mesh are in the Initialize Particles module’s Mesh attributes section.

1. Ribbon Renderer:

• Ribbon is a line between all the particles in the order they are spawned.
• The material of this ribbon can be changed.
• Ribbons can be in different shapes like planner, bi-planner or tube.

1. Light Renderer:

Attaches a light with each particle, intensity and other properties can be edited.

1. Component Renderer:

Render other particle systems, skeletal meshes and much more.

>

1. Emitter State Module: Sits in emitter update stage, it helps configuring emitter life cycle and the scalability. Scalability is like culling.
2. Initialize Particles Module: Sits in the particle spawn stage, it helps give particles size, color, lifetime, position etc.

Sprite UV mode: this setting changes the way sprite looks on screen, we can flip sprite in x or y direction with it. For example a sprite written ‘p’ can be flipped on x to look like q on y to look like b and on both to look like d.

1. Particle State Module: when particle  Age > Lifetime it tells the engine to kill the particle to save performance.
2. Sprite renderer: Default renderer

Niagara System:

The Niagara system contains multiple emitters, it can be placed in the world, its variables can be edited in blueprints.

System Stack:

>

1. Warmup time: Given in seconds, the system calculates for example 2 seconds of emitters and starts ahead. For example an already burning fire when the game starts at 0s.
2. System Fixed Bounds: force all emitters inside to be fixed bounds.

>

See below in parameters section

>

1. System Stage

• Spawn: Runs once when the effect is first created in the world.
• Update: Runs every single frame for the whole system.
• Example Modules:
  • System State
  • User Parameters

>

1. System State Module: Sets niagara system time, loop duration.

Parameters:

>

In the details panel for every module there are some properties. After every property there’s a down arrow that allows us to - 

1. Lerp it or set in random range or take from a curve
2. Make it new system, emitter, particle or user parameter
3. Use its value from a user parameter

>

There are 2 ways a parameter can be setted. The first one is by dragging the parameter from the parameters tab and dropping it to the suitable execution stages (where it can be set).
Another way is to add a “Set new or existing parameter directly” module in any stage. The details panel of the module will give all possible parameters that can be setted from the execution stage the module is in. In the details panel there’s an option to make new ones as well.

>

There are 2 ways a parameter can be created. One is by clicking the plus sign in front of the namespace (system, emitter, particle, user) in the Parameters tab. Another one is to click the drop down in front of any property (for example lifetime in initialize particle module) and click “Read from new emitter/particle/system/user parameter”

>

Blueprint readable.
User parameters can be made from the user parameters tab. These parameters can be edited in the details panel when dragged into the world, or through blueprints.
User parameters can be bound to properties of modules like the lifetime property of initialise particles module.

• Read/Get Value

1. All stage modules like one in system update, or emitter spawn or particle update can read User parameters.
2. We already have discussed setting a parameter.

• Write/Set Value

1. User parameters can be written from blueprints.
2. They can be written from the details panel in the world, when a system is dragged into the scene.
3. They can be written from the User Parameters tab in the niagara system.
4. No stage in the system can write a user parameter.

• System Parameters:

These parameters can be accessed from any emitter in the system. For example if we want 2 emitters to have the same spawn rate it can be made a system parameter. Click on the down arrow and ‘read from a new system parameter’

• Read/Get Value
• System parameters can be read from all stages, particle, emitter and system
• Write/Set Value 
• System parameters can only be set from the system update or system spawn stage.

>

Used anywhere in the same emitter, created the same way as the system parameter.

• Read/Get Value
• Emitter parameters can be read from particle, emitter stages only.
• Write/Set Value 
• Emitter parameters can only be set from the emitter update or emitter spawn stage.
• Transient Parameters:

Used in between while the math is done, none of our business. Gets destroyed after the math completes.

>

When we edit the lifetime for the initialize particles module in the details panel, the engine stores the values as particle parameters. It’s different for each and every particle in the emitter.
Most of the time particle parameters are not created, but whenever created they are different for each particle.

• Read/Get Value
• Particle parameters can be read from particle stages in the emitter it belongs to only.
• Write/Set Value 
• Particle parameters can only be set from the particle update or particle spawn stage.

Times:

1. Timeline Duration:

Timeline Duration is just for visualization. Duration can be changed by dragging the timeline bars.

1. Particle Lifetime:

Particle lifetime tells how much a particle, a dot, lives after spawning.

1. System Time:

System time tells how long a niagara system runs. For example a 5 seconds and looping infinite particle system will loop indefinitely and will reset all emitters within every 5 seconds.

1. Emitter Time:

Different for each emitters (emitters can choose to use system time as well), emitter time tells how long an emitter stays.

NIAGARA MODULES

>

Almost all spawn modules belong to the Emitter Update stage in Niagara. Spawn burst can be put into the Emitter spawn stage if in need.

1. Spawn Burst Instantaneous:

Spawns a specific number of particles at once.

1. Spawn Rate:

Spawns specified number of particles once per second

1. Spawn per Unit:

Spawns particles based upon distance. Per unit (cm).

1. Spawn per Frame:

Self explanatory…

• Velocity Module

Add Velocity: Sets particle speed and direction.
Even if the emitter is not set to Local Space, rotating the Niagara Component in the level will still rotate the velocity direction by default.
To prevent this and lock velocity direction to world space, set Rotation Coordinate Space to World/Global in the Add Velocity module details.

• Forces

Gravity, drag, vortex force and curl noise modules.

• Collision Module

Enables collision. Particles.HasCollided boolean returns true on the frame collision occurs.

>

1. Shape Location Module

• Spawns particles on or inside geometric shapes (Sphere, Box, Cylinder, Ring, Torus, Cone).
• Lots of tweakable parameters: surface-only spawning, axis constraints, radius distributions, and custom curve graphs for precise spawning.

1. Static Mesh Location Module

Spawns particles directly on the surfaces, vertices, or faces of a Static Mesh.

Hello, feel free to tell me if i'm wrong at any place. It's not something that will make you a VFX artist but surely the 80% knowledge required to start with niagara in 20% of time. Rest is just practice and tweaking variables or trying out things. I have full ue5 notes that i add to google docs as i progress, If you want to make additions please please do, i'll be happy to have you.

NIAGARA

Niagara Emitters:

Niagara emitters as the name suggests are single emitters that can emit particles of one kind. Multiple Niagara emitters can be combined to create a good VFX effect.

• Niagara emitters can have their own time or global time for example time of the niagara system that owns them.
• A Niagara emitter can be an asset on its own if you want to reuse it, and it can directly sit on a Niagara system as well.

Emitter Stack:

https://preview.redd.it/9fzlvjid0ohh1.png?width=383&format=png&auto=webp&s=69691e0e6cf591c24fa0071e6363db48d706ec0a

>

1. Sim target: it is the simulation target, whether the CPU or the GPU should solve the particles. Use cpu when “you need particles to give output like where they hit”, “a few 1000 particles only”. Use gpu when “you do not require particles to calculate their hit locations, dumb particles”, “can solve millions of the particles”. -GPU sim particles can still receive information from blueprints, it just can’t output information.
2. Calculate Bounds Mode: How the bounds should be calculated, if you see your particles disappearing when slightly looked away, it’s the culprit here. Fixed bounds are easy on performance.
3. Local/World Space: Local space particles move with the emitter and do not leave a trail whereas the world space particles do so.
4. Determinism: whether the randomness be truly random or based on a seed number provided.
5. Interpolated Spawning: spawn particles in between if a particle is moving with a faster speed, like a bullet trail can leave dots.
6. Event handlers: See Below...

>

It allows non vfx artists to tweak variables to get desired effects. Any variable can be set as emitter summary by right clicking on parameter and “show in summary”

>

https://preview.redd.it/3z0yrhsg0ohh1.png?width=319&format=png&auto=webp&s=2ec79a826cb333f84293a4b1aa398156fb8d8ba2

1. Emitter Stage

• Spawn: Runs once when the emitter starts its loop.
• Update: Run every single frame that the emitter is "active."
• Example Modules:
  • Spawn Rate: "Spit out 50 particles every second."
  • Spawn Burst Instantaneous: "Spit out 10 particles right now at the start."
  • Emitter State: Decides if this specific emitter loops or runs once.

2. Particle Stage

• Spawn: Runs once when the particle is spawned.
• Update: Run every single frame for every single particle.
• Example Spawn Modules:
  • Initialize Particle: Sets the starting color, size, and lifetime
  • Add Velocity
• Example Update Modules:
  • Gravity Force
  • Solve Forces and Velocity: It actually does the math to move the particle based on the forces applied to it.

>

Multiple event handlers can be added from the properties panel, it's not there by default.
Example: Suppose a firework rocket goes up in the sky, when it dies we need to tell another emitter to spawn a burst of fireworks in the sky.
So we add the Generate Death event in the rocket’s update particle stage. Click + stage at the end of properties tab and add an event handler stage in the burst emitter, here we select rocket -> Death event. This stage now works like an execution stage when the death of a particle will happen in the rocket emitter. In this stage we add a module for the same event (death in this example) “receive death event”.

1. Death event: generated when particle dies
2. Location event: returns location of each particle
3. Collision event: generated when particle collides.

>

1. Sprite Renderer:

• Material of sprite can be changed here.
• Particle color nodes in the material graph are used to use the particle color in the material so changing the color parameter in the niagara affects custom material.
• The sprite pivot can be changed, which helps in rotation around the pivot.
• SubUV: subuv is a way to cut down the material into parts, choosing 10x10 will make 100 frames of the material uv’s we have. In the particle update stage, Animate SubUV module can be added to animate the SubUV frames.
• CutOut: It’s like a bounding box for each sprite, depending on how big area the sprite takes, we can decrease it by giving it a texture and choosing its alpha. For example a circle sprite will have a box bounding box by default, but if we pass its texture here and choose alpha, it will be like a circle now.
• Bindings: We can change the color of the sprite through the color parameter (particle namespace), but if we want some other parameter to affect it we can actually directly bind that variable to the color of the sprite. Till now we were doing

(particle namespace) color == (user namespace) MyColor
But now we do
Color (sprite renderer) == (user namespace) MyColor

• Sorting: More the sorting, the higher z-order the sprite render uses and displays over the sprite renderer with a lower sorting. Just like z-order in the CSS or layers in photoshop.

1. Mesh Renderer:

• Mesh can be changed here, multiple meshes are allowed at once.
• Material of the meshes can be changed here as well.
• More attributes related to mesh are in the Initialize Particles module’s Mesh attributes section.

1. Ribbon Renderer:

• Ribbon is a line between all the particles in the order they are spawned.
• The material of this ribbon can be changed.
• Ribbons can be in different shapes like planner, bi-planner or tube.

1. Light Renderer:

Attaches a light with each particle, intensity and other properties can be edited.

1. Component Renderer:

Render other particle systems, skeletal meshes and much more.

>

1. Emitter State Module: Sits in emitter update stage, it helps configuring emitter life cycle and the scalability. Scalability is like culling.
2. Initialize Particles Module: Sits in the particle spawn stage, it helps give particles size, color, lifetime, position etc.

Sprite UV mode: this setting changes the way sprite looks on screen, we can flip sprite in x or y direction with it. For example a sprite written ‘p’ can be flipped on x to look like q on y to look like b and on both to look like d.

1. Particle State Module: when particle  Age > Lifetime it tells the engine to kill the particle to save performance.
2. Sprite renderer: Default renderer

Niagara System:

The Niagara system contains multiple emitters, it can be placed in the world, its variables can be edited in blueprints.

System Stack:

https://preview.redd.it/ox3hi2sm0ohh1.png?width=336&format=png&auto=webp&s=6335b9d39abe720a0f9ca007f43ea7900c59d13a

>

1. Warmup time: Given in seconds, the system calculates for example 2 seconds of emitters and starts ahead. For example an already burning fire when the game starts at 0s.
2. System Fixed Bounds: force all emitters inside to be fixed bounds.

>

See below in parameters section

>

1. System Stage

• Spawn: Runs once when the effect is first created in the world.
• Update: Runs every single frame for the whole system.
• Example Modules:
  • System State
  • User Parameters

>

1. System State Module: Sets niagara system time, loop duration.

Parameters:

>

In the details panel for every module there are some properties. After every property there’s a down arrow that allows us to - 

1. Lerp it or set in random range or take from a curve
2. Make it new system, emitter, particle or user parameter
3. Use its value from a user parameter

>

There are 2 ways a parameter can be setted. The first one is by dragging the parameter from the parameters tab and dropping it to the suitable execution stages (where it can be set).
Another way is to add a “Set new or existing parameter directly” module in any stage. The details panel of the module will give all possible parameters that can be setted from the execution stage the module is in. In the details panel there’s an option to make new ones as well.

>

There are 2 ways a parameter can be created. One is by clicking the plus sign in front of the namespace (system, emitter, particle, user) in the Parameters tab. Another one is to click the drop down in front of any property (for example lifetime in initialize particle module) and click “Read from new emitter/particle/system/user parameter”

>

Blueprint readable.
User parameters can be made from the user parameters tab. These parameters can be edited in the details panel when dragged into the world, or through blueprints.
User parameters can be bound to properties of modules like the lifetime property of initialise particles module.

• Read/Get Value

1. All stage modules like one in system update, or emitter spawn or particle update can read User parameters.
2. We already have discussed setting a parameter.

• Write/Set Value

1. User parameters can be written from blueprints.
2. They can be written from the details panel in the world, when a system is dragged into the scene.
3. They can be written from the User Parameters tab in the niagara system.
4. No stage in the system can write a user parameter.

• System Parameters:

These parameters can be accessed from any emitter in the system. For example if we want 2 emitters to have the same spawn rate it can be made a system parameter. Click on the down arrow and ‘read from a new system parameter’

• Read/Get Value
• System parameters can be read from all stages, particle, emitter and system
• Write/Set Value 
• System parameters can only be set from the system update or system spawn stage.

>

Used anywhere in the same emitter, created the same way as the system parameter.

• Read/Get Value
• Emitter parameters can be read from particle, emitter stages only.
• Write/Set Value 
• Emitter parameters can only be set from the emitter update or emitter spawn stage.
• Transient Parameters:

Used in between while the math is done, none of our business. Gets destroyed after the math completes.

>

When we edit the lifetime for the initialize particles module in the details panel, the engine stores the values as particle parameters. It’s different for each and every particle in the emitter.
Most of the time particle parameters are not created, but whenever created they are different for each particle.

• Read/Get Value
• Particle parameters can be read from particle stages in the emitter it belongs to only.
• Write/Set Value 
• Particle parameters can only be set from the particle update or particle spawn stage.

Times:

1. Timeline Duration:

Timeline Duration is just for visualization. Duration can be changed by dragging the timeline bars.

1. Particle Lifetime:

Particle lifetime tells how much a particle, a dot, lives after spawning.

1. System Time:

System time tells how long a niagara system runs. For example a 5 seconds and looping infinite particle system will loop indefinitely and will reset all emitters within every 5 seconds.

1. Emitter Time:

Different for each emitters (emitters can choose to use system time as well), emitter time tells how long an emitter stays.

NIAGARA MODULES

>

Almost all spawn modules belong to the Emitter Update stage in Niagara. Spawn burst can be put into the Emitter spawn stage if in need.

1. Spawn Burst Instantaneous:

Spawns a specific number of particles at once.

1. Spawn Rate:

Spawns specified number of particles once per second

1. Spawn per Unit:

Spawns particles based upon distance. Per unit (cm).

1. Spawn per Frame:

Self explanatory…

• Velocity Module

Add Velocity: Sets particle speed and direction.
Even if the emitter is not set to Local Space, rotating the Niagara Component in the level will still rotate the velocity direction by default.
To prevent this and lock velocity direction to world space, set Rotation Coordinate Space to World/Global in the Add Velocity module details.

• Forces

Gravity, drag, vortex force and curl noise modules.

• Collision Module

Enables collision. Particles.HasCollided boolean returns true on the frame collision occurs.

>

1. Shape Location Module

• Spawns particles on or inside geometric shapes (Sphere, Box, Cylinder, Ring, Torus, Cone).
• Lots of tweakable parameters: surface-only spawning, axis constraints, radius distributions, and custom curve graphs for precise spawning.

1. Static Mesh Location Module

Spawns particles directly on the surfaces, vertices, or faces of a Static Mesh.

Hello, feel free to tell me if i'm wrong at any place. It's not something that will make you a VFX artist but surely the 80% knowledge required to start with niagara in 20% of time. Rest is just practice and tweaking variables or trying out things. I have full ue5 notes that i add to google docs as i progress, If you want to make additions please please do, i'll be happy to have you.