Need Basic Efficiency Advice

I'm planning a 3D Top Down Strategy Game to build on my own. My hope is that this will be able to run with ease on relatively slow computers . I've been doing a lot of research on efficient development and am here now to get a few more ideas. ( I am using the lite version of Unity )

I'll try to keep this short.

Things I know ( Please feel free to comment and aid me on these too. ) :

>I should create low poly models.

>Create textures with the smallest dimensions possible.


What to Question:

>How do animations effect performance and how can I lower the requirements? (This is where I have the least experience so as much info as possible would be great *low poly models*)

>What effect do Normal Maps have on texture size and performance?

>Should I use particle systems or use code as much as possible to do basic effects?


The big question here and why I posted this in the scripting section is what are the big don'ts and do's of scripting for maximum performance that you watch out for? ( Just a link or two to some other helpful threads would be great here. )

I'd also love to hear some advice on shortcuts you guys take that would too help maximize performance. Things that you notice people usually won't pay much attention to or criticize.

ANYTHING HELPS -> HUGE THANKS!

 

One more thing!

I need some info on the use of ray-casts and triggers - on topic of performance of course, Thanks!

 

For animations, use as few bones as you can get away with.

Normal maps are extra textures, and using them also means using a more expensive shader. So your texture memory usage will double, and drawing those pixels will be more expensive - though that might not mean anything practical, you'll have to test.

Regarding particle systems or code... what do you mean? What's an example?

What do you need to know about the performance of ray casts and triggers?

You seem really worried about performance. My advice is two-fold. First, don't worry about it unless it's a problem. Don't spend more time fixing things that aren't problems, it just makes life harder. Secondly, spend dedicated time learning about how both computers (CPUs, memory and GPUs) and game engines work. This will help you make informed decisions about how to increase performance before it becomes a problem and without making your life harder. Optimising a game isn't just about making code that executes more quickly, it's also about making the development itself more efficient.

 

An example of a situation to use a particle emitter or code would be creating a river by scripting texture movement, or creating a particle effect to move them for me as played.

I would like to know if I would be better off using a ray-cast over a trigger. For a ray-cast I would have to access another script upon contact, and a trigger has it's own function for initiating lines of code.

Thanks for the advice after your initial answer, that's what I enjoy reading the most. And as sad as it is for my age, I ordered a book and am currently learning about rasterization and every collegiate math involved in 3D development and how they react with the computer itself. That's my dedication! I also just read about 4.6 and the new GUI, which I can't wait for! I guess this gives me more time texture, model, and study.

Also, is it just me or did the forums change? How do I quote people o.0

 

With ray casting the problem is that they need colliders, and bringing a lot of colliders will slow down your game.

With "Reply" hyperlink.

 

oh... Thanks!

 

But they're different effects, so performance probably isn't the first consideration there.

Same deal still goes for ray casts vs. triggers, too. What's easier to use, a hammer or a saw? It depends what you're trying to achieve, and you typically wouldn't find a job where there's a sane choice between the two.

I've never had a problem with collider count in a scene. However, there are pretty serious performance gotchas with physics stuff, so you should look into that when designing your game's technical implementation. It's really a matter of exactly what my extra advice covered - learn how it works and you'll get good results, or don't and you'll end up fighting with it. But don't worry about doing things less-than-optimally to begin with. Getting stuff finished is more important than getting it perfect.

 

Also, performance isn't a linear scale. It's always got to be taken in the context of the system in which you are performing a given task. For instance, you might be picking between CPU, GPU or memory hungry solutions to a problem. Which one is "cheaper"? Well, that depends entirely on how you're using your other resources at the time - saving CPU time by eating up memory might make perfect sense in one case and might be an unworkable showstopper in another.

Start off by making things work and learning how they work. Only when you understand that can you learn how to make them work better.

 

Well, there isn't ever going to be a general list of 'Things to do to Optimise', or if there was, it would be huge and not useful.

Optimisation is going to be pretty specific to the situation you find yourself in, and is something you should be considering while developing, rather than planning for. (though certainly not leaving until last!)

The trick is to look at each feature as you are about to implement it, then consider optimisation.

I won't go into specific examples as there are enough of them around for you to easily find, but I'd advise just getting stuck in and considering optimisation when deciding 'How am I going to implement this particular feature?'

Having an actual lowest spec target system in mind which is available to test on can also be a useful tool for figuring out what you can do where.