Hi,
so I have the map I want to create in paint.net and on paper, but before I start creating it in UE4, do I need to worry about players choosing different graphic settings? Somebody told me I "need to decide on the desired minimum hardware to run the game".
So how does it work? Do I need to create a low quality world first? what then?
Please help me with this :)
You can change the graphics and performance settings on the fly in UE4 by changing various console variables from blueprint which start with "r."
A full list is here:
https://docs.unrealengine.com/latest/INT/Engine/Performance/Scalability/ScalabilityReference/index.html
Some of these work fine with any models and materials whilst others might need some careful thought.
As others said, make sure you understand how your engine of choice works before you strip back the paintwork...
Good luck!
Thanks for the link! I'll definitely take the time to read and understand everything!
Hi.
Welcome.
I think you're going a bit to quick. A 3d scene/ world consists of different 3d objects. You can either create or download them (for example in the unity store). A 3d engine, like UE4 can render your world, using a lot of different techniques and special effects. Depending on what effects you use, you might need better/ faster hardware. In the basis, the 3d world you create doesn't have to be different depending on how "high quality" you want to render it.
Based on your question (no offense), you might want to start with some basic tutorials or a book. Learning the basic principles of the magic world of 3d rendering and games ;)
Thanks! And yes, maybe im going a little too quick, but what I want to avoid is putting alot of time into something and after that, discovering i needed to do something before I Continued.
Thanks! And yes, maybe im going a little too quick, but what I want to avoid is putting alot of time into something and after that, discovering i needed to do something before I Continued.
Usual newbie mistake.
It is good to plan ahead and try to be as efficient as possible. That includes preventing running into an obvious dead end.... BUT:
At the stage you seem to be at, the last thing you need to be worried about is making mistakes or bad choices. You'll make them anyway. And that is good.
Because you know what? You most probably lack the knowledge needed to get beyond planning a map in paint.net anyway. Most probably, because you might be not doing this thing the first time, you didn't tell that. But then you wouldn't ask such a question....
Humans learn from making mistakes. Not from success.
When I was wee scrub when it comes to game dev, I read some good advice on a different forum on the wild wild web:
"Premature optimisation is the root of all evil" - care about building your game first, before caring about making it run fast on the target hardware.
There is no point in wasting time now to create efficient assets and optimal code if you don't even know if your game will get anywhere... did you already playtest a prototype? No? So you don't even know that what sounds good in theory is actually fun in practice. Are you really sure you get anywhere with the scope of your game before you run out of money, interest or time?
So why are you so concerned about how fast your game will run on the computer of a hypothetical player when there isn't even a game to begin with?
Clearly, there are some avenues to avoid, some pitfalls that even the best optimisation will not m ake it run on the old toasters some players out still expect your game to run on. Like choosing game mechanics that NEED an extreme rendering range, yet choosing a viewpoint that also asks for some detailed scenery. You can still compromise (like lower the graphical fidelity), you can still optimise (extreme LODing comes to mind), but at some point you might just lower the view range or increase the minimal system requirements.
But really, these are extreme choices, most things can be optimised LATER... not for free, it costs a lot of work and time to optimise things. But it does so even if you do it too early, yet in the first case you invest the time AFTER you made sure that the investment is actually a sound choice.
The last thing to note is: you should probably start with a simple prototype first anyway.... these usually use simple placeholder assets instead of the final version, and might not have all the graphical FX yet. You should get good performance there even with crappy prototype code and running on a toaster. Again, the idea is to not invest too much until you have proven your game idea to be fun.
TL;DR: just chuck graphical options aside for now, and worry about optimisation later on. Create a fun game running well on your hardware, and even if doesn't run as well on yours (you might have to work on a toaster yourself, IDK), only worry about it if its BAD (like "below 20 FPS" bad)...
You got a lot to learn... optimisation is one of the last things on that list, right before marketing and releaseing games.
Thanks! And yes, maybe im going a little too quick, but what I want to avoid is putting alot of time into something and after that, discovering i needed to do something before I Continued.
Usual newbie mistake.
It is good to plan ahead and try to be as efficient as possible. That includes preventing running into an obvious dead end.... BUT:
At the stage you seem to be at, the last thing you need to be worried about is making mistakes or bad choices. You'll make them anyway. And that is good.
Because you know what? You most probably lack the knowledge needed to get beyond planning a map in paint.net anyway. Most probably, because you might be not doing this thing the first time, you didn't tell that. But then you wouldn't ask such a question....
Humans learn from making mistakes. Not from success.
When I was wee scrub when it comes to game dev, I read some good advice on a different forum on the wild wild web:
"Premature optimisation is the root of all evil" - care about building your game first, before caring about making it run fast on the target hardware.
There is no point in wasting time now to create efficient assets and optimal code if you don't even know if your game will get anywhere... did you already playtest a prototype? No? So you don't even know that what sounds good in theory is actually fun in practice. Are you really sure you get anywhere with the scope of your game before you run out of money, interest or time?
So why are you so concerned about how fast your game will run on the computer of a hypothetical player when there isn't even a game to begin with?
Clearly, there are some avenues to avoid, some pitfalls that even the best optimisation will not m ake it run on the old toasters some players out still expect your game to run on. Like choosing game mechanics that NEED an extreme rendering range, yet choosing a viewpoint that also asks for some detailed scenery. You can still compromise (like lower the graphical fidelity), you can still optimise (extreme LODing comes to mind), but at some point you might just lower the view range or increase the minimal system requirements.
But really, these are extreme choices, most things can be optimised LATER... not for free, it costs a lot of work and time to optimise things. But it does so even if you do it too early, yet in the first case you invest the time AFTER you made sure that the investment is actually a sound choice.
The last thing to note is: you should probably start with a simple prototype first anyway.... these usually use simple placeholder assets instead of the final version, and might not have all the graphical FX yet. You should get good performance there even with crappy prototype code and running on a toaster. Again, the idea is to not invest too much until you have proven your game idea to be fun.
TL;DR: just chuck graphical options aside for now, and worry about optimisation later on. Create a fun game running well on your hardware, and even if doesn't run as well on yours (you might have to work on a toaster yourself, IDK), only worry about it if its BAD (like "below 20 FPS" bad)...
You got a lot to learn... optimisation is one of the last things on that list, right before marketing and releaseing games.
Thanks alot for this very helpful answer. And yes, its obvious to me to first make a prototype. I started looking at this differently, in a good way. :)
