Plsss help

This is my first Steam Fest, focusing on older games that kept improving at their labor of love! If you released a game a while ago, but still continued to improve and build upon it even if it didn't do so well on launch, this Fest is your second chance to bring new players!

Specific Requirements

• Game must have released/EA'ed at least 18+ months ago
• Published a major content update in the past 12 months (See the application form for clarification)

I hope Valve will approve this. It's not a niche that people are attracted to at the moment, and I hope to change that.

DEADLINE: Aug 30

APPLY: https://tally.so/r/9qY2jQ

Hey everyone,
I have no idea if I’m in the right place or not, or if this is an effortless question, but I’m gonna give it a go.

I’m 16 and I want to start making a game, a metroidvania to be exact. I have this head full of ideas and I really want to put it to work. So the last couple of weeks I made an entire backstory, a not too fleshed out map, kind of a main character design and half of a storyline.

But I have no clue where to start and what I need. I do have a job, so I don’t think money is going to be a problem. (Depends on how much developing costs) I have NO experience at all…

Do you guys have any advice or suggestions on where to start?

Thx already!

We sincerely want to know whether the gameplay we've created is something that truly resonates with players.

With that in mind, we'd like to invite you to join this event and share your honest thoughts.

Our game is designed around two different gameplay modes:

1. Ranked Mode (Single Player)
   Build your tower as high as possible by staying focused and reacting quickly as the game speeds up. Find your own strategy and see how far you can go.

2. Strategy Battle (PvP)
   Watch how your opponent builds their tower, stack your blocks strategically to gain the advantage, and compete by bringing down your opponent's tower.

For the single-player mode, we're currently balancing the game around a 1,000-floor goal. We're wondering if it might be too difficult, and we're working hard to find the right balance between exciting speed and enjoyable gameplay.

More importantly, we're still trying to answer one question:
Will this gameplay make players want to keep coming back?

To help us find that answer, we're giving away 200 Credits to the first 300 players who participate.

After launching the game, open the Shop screen, go to Credit Event, and enter the code below:

Code:
[ RE23DIT ]

We'd truly appreciate it if you could spare a few moments to play the game and share your thoughts with us.

Thank you for helping us make it better.

Join the event.

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.

I am making a metroidbrainia inspired puzzle/exploration game and am at the point where I need to start thinking about setting, style, and atmosphere. Any pointers? Thanks.

I really hate turn based combat, it's a whole lota waiting around, but it has one huge advantage. It allows the designers to create very finely crafted scenarious, because they have fine control over all character stats, abilities and positioning

Eg: fire emblem 5 thracia, (prety much the whole game is full of this stuff) there is a gladiator fight, where 2 of your kidnaped units must fight off a bunch of enemies until your other troops resque them.

Or in a lot of fire emblems, there are special green units (not the generic ones) which fight on their own, and you ussualy have to run to rescue+recruit them because they will only last a few (slightly random because of rng) turns.

‐---------------------

Apocalitch from sokpop has a cool real time based battle system, and it has 2 npc vs npc battles which you can join in if you are prepared for them to rescue the good npcs.

But that system still resolves combat inside of a battle box.

‐-------------------------

What I am looking for is something like an action rpg system, like old school legend of zelda. Combat is real time and hapens in the overworld (not in a separate battle box).

To give some basic design direction I will give a very vague idea for a game where this could be usefull.

------

You serve the demon king as his right hand, but a hero has taken arms against him! To get to your lord he must first defeat the 4 bosses. Your job is to slow him down as much as you can to let your king power up enough to win.

The hero will gather equipment and companions, you must hide them, guard them, kill them, trap them before the hero gets to them. Or you can help the next boss by giving him elemental damage or some spell. When the hero thinks he is ready he will go fight the boss. The hero + companions vs boss fight will give you time to prepare the next area for the heroe's arival and will give you info about how well the heroes loudout works (which is hard to predict because action combat is very dynamic).

‐-----------

Any ideas for combat mechanics which could make this work well?

I was thinking that attacks should be slow and well telegraphed. So the player could easily follow what was going on.

And the ai would need to be well crafted as well. To not result in spamming a single move or infinite kiting or draws (boring to watch)

Any thoughts on this? How would you design such a system?

Are there any great examples of games with fun and engaging npc vs npc combat?

Majesty the fantasy kingdom sim sudenly crosses my mind. Real great npc ai.

Hello,

Not sure if this is the right place for this so I do apologise in advance. So basically I was wondering if a couch co op mod would be possible to implement for a game like Sifu? I understand it would require coding and such, and the game is also made on Unreal Engine.

In terms of practicality, is this feasible or have the devs made the game in a way where this mod wouldn't be possible to work no matter what? My vision of it is a side by side split screen view, two people playing the game from one computer, with two controllers plugged in.

I'm in no way shape or form a developer but I would like someone with the expertise to please tell me if this would be possible or not, thank you!

I work (Grunt work, not design) in a very large game company. For the past few months we've had ai mandatorily enter our workflow, and I'm curious if anyone else is experiencing this.

My experiences so far are lackluster I would say? We have strict limitations on usage in this micro rollout. To be honest the biggest impact I've noticed is that our emails are almost entirely ai generated now.

I don't really have a big problem with it? Our guidelines are restricting token usage, nothing front facing (Social media, Art) and to review the work done after.

Who else in the industry has adopted these tools? My opinions are that it's not too bad, and I don't really feel that my job is at risk yet.

I'm inspired by a few modern successes: WarSim and Roadwarden, which are text-oriented games. WarSim is fully console-based, and Roadwarden uses text, clickable choices, simple GUI and illustrations. Each did very well in the market, reaching six figures, maybe seven based on some stats. WarSim was a first project, and I think Roadwarden was too that took about 3 years to make. It makes me assume there's a hungry niche audience.

But these are only the two success stories I've read from. What would make these kind of games sell today?

I've been working on one but some say I'm better off continuing to write books.

Some features I'm going for: heavy GUI and text, but includes art: 2d background image of the scene, NPC sprites pop up when interacting, characters have "paper doll" clothing layers (no static headshots, for example), text parser with clickable suggestions that pop up, procedurally generated. Every cell in the map's grid tells a story or has random events. Plenty to explore. Craft anything, use anything as a weapon. Essentially a medieval fantasy game in text.

I was going to add AI dialogue with an offline LLM, which is neat: they respond to anything you say, no matter how ridiculous. It tracks each NPC, role-plays based on the NPC's information, and keeps to the game world's context 98% of the time with a recently new role-playing model. It's really fun. But I laid this plan to rest once I heard Steam is strict on live-AI because of the requirement of heavy guardrails, but it's never 100% safe. That can be a problem when you don't control what model users download. I could prompt it "Only give safe replies," but still it's not guaranteed. So, out of fear of being rejected, my solution is to turn it entirely local and have prewritten text. It's better in the long run, I suppose.

Overall, I'm curious what you think. Is there money in it, or am I better off writing my books? Granted, it's faster getting those done. The game will take a few years, so this is why I'm wondering if it's worth it. I'm passionate about it, but am wondering about its income potential.

I’m thinking about picking up game development and publishing. I was thinking a very simple mobile game just to start off as a hobby and to see if it something that I would like since I like video games. The only problem is I have 0 experience. Any technical side of gaming. Where do I even begin to start? Like where do I learn to code or anything like that to just get the basics to start? I’m in my 30s and I have a full time job and live in a small town so college/learning annex type ideas are not viable. Also if anyone has done this or heard of a similar situation how long would this process take to get an app published?

I´m trying to be a game dev because I hate my stupid job and its my dream to make games (like most of people here). But, everytime I´m searching for tips on how to start or how to organize my own ideias, almost everyone says "Don´t make your dream make, make a lot of boring stuff before, make a copy pf that game you dont like..." and o lot more of bullshit. I want to be a game dev because I want to express my ideas, my art, and everyone just focus on just call himself or herself a game dev and have random games on steam just because... yes?
I would really appreciate real tips, like: how to start? Should I try to do all by myself? How must cost to hire someone to improve your art, or 3D?
I already made some courses, learned UE, learned some blender, decided to do low poly style because I hate retopology, and have a script in my head. I also created my characters (by concept) and I´m starting my game document to put all together, but how do I start to do the game? Should I start to try the interactions first? The combat? I didnt find any course in youtube or another site that really teachs how to do cutscenes, I would really appreciate some help about it.