Greetings to all! Anyone knows how to determine the minimum or recommended system requirements/specs for a game in unreal engine? Assuming you have finished the development part and you 're ready to start packaging… I mean, how an indie dev is supposed to do this? Thanks in advance for any responses…
Greetings Dimer85!
We see that this is your first time posting in our forums! 
We gladly welcome you to the Unreal Engine community! Thank you so much for posting your question. I’ve included a link below that should help you determine the system requirements.
Thank you so much for being an important part of our growing community! Happy Creating and Good Luck on your project!
Bro that’s not what he meant… he meant the packaged game, not ue
Hello there! Thank you for your warm welcome!
As @anonymous_user_f27400311 points out, I’m talking about the specs about the game someone is making in the UE, not the UE itself…
1 Like
As far as i know from previous questions i read on the forums, there is no easy way of doing this.
Best method is still to find different types of hardware ranging from low to high end and test the packaged project on them. Add some console variables to the packaged project to see fps etc to determine recommended spec’s.
Optimization practices are always a must, no matter the engine you use. You need to know the focus of the platform you are aiming your game towards. Is your game to be played on a broad amount of computers in general like laptops, or only on hi-end desktop machines? Those are things to consider and will influence the way you develop your game and how it will be received by most.
For instance, if you want max support, bundle all your textures as 1024x1024 if you want a mix of quality look and still be safe that it will run smooth even on old laptops. If you want to shot for the stars of hi-res but still be optimized, never go beyond 2048x2048 for textures.
You will also need to know what a LOD is. There will be an instance in which the objects are too far away from the players to focus precisely, then their models and textures are swapped with an object with less polygons and a lighter texture, usually a 512x512. Those are to fill. That also counts as good optimization practices.
Also the amount of dynamic lights and static lights will influence a ton. If there are objects that are not meant to move about, their shadows and lights needs to be baked. That means the shadow they cast is permanent “toasted” onto the surface of the object and the objects onto which the shadows are casted. That also saves on resources. Making games with full dynamic lights even for objects that aren’t meant to move from the spot nor be interacted with the player nor the general environment lights count as bad optimization practices.
As for dynamic lights, it is a good practice to “clone” a single light multiple times than “duplicating” several instances of it. Way too small lights are prone to cause shadow and light artifacts, and duplicating instances of lights makes the computer to choke on itself. A single light instance cloned several times is much better because it is treated as a single light but pouring its light on different places (good for streetlights, corridors with a single type of light, etc). You also need to learn this difference between “cloning” and “duplicating” lights. This also works for objects too. A forest made with 100 cloned trees will render faster than one made of 100 duplicated trees, as each of these duplicated trees are treated as different objects and it adds up to the queue of processes being juggled by the computer upon entering a new map of your game (NO MATTER IF THE OBJECT POSSES THE SAME POLY COUNT AND SHARES THE SAME TEXTURE – I can’t stress this enough, cloning and duplicating are not the same, though perhaps the terminology in UE might be different but they point to the same concept; it’s not the same to have 1 single instance of an object working on 100 places and having 100 instances of a single object on 100 different places).
What else? Level streaming is a good way of rendering only the area the player immediately sees and not the areas hidden behind doors, walls and other objects that block the view of the player. When a player enters indoors and there is no window to watch stuff outdoors, stream that level to unload upon closing the doors behind. The area outdoors would be despawned to save computer resources and the new area indoors will fully load seamlessly without the outdoors exerting its pressure on the computer.
Also the number of entities running about the area will influence. If the game is going to be a multiplayer, you need to study about how to set those up. If it is a single player and the player will interact with NPCs and other hostile mobs and pickups, you need to render just the ones in their immediate area and avoid to clutter the place with too many dynamic objects, specially if they have physics. A rule of thumb is to despawn the models behind walls but not their presence (as if making the model invisible but not their collider as that it can still interact with the stage like still being pinged on an enemy-radar for the player HUD). Despawning ephemeral objects like bullet caskets and the like is also a common practice. The player – though they might LOVE to see the carnage left in their wake – must not see every 1000 enemy corpses and 1000000000000 bullets they have spent. Despawn those accordingly, by either fading them away in all the creative manners you might see fit for the theme of your game.
Many other smol details of optimization. With UE5 it seems we can go “overboard” with those old optimization customs, but I do still recommend to develop the game as always, with optimization for all platforms always in mind. It is not a matter of “what spec should I do!” but more like “I should develop following all the rules of thumb for great optimization!”.
Or that is what I learnt after pouring hours and hours on different game development design courses and the like… Take it or run away fast from me. I’m dangerous.
1 Like