|
I know this question is probably very redundant, but please hear me out. So I'm working on space adventure game with heavy combat elements with intentions of expanding it with role playing elements as I go. I'm a graphic designer with strong knowledge on programming with Javascript from my time spent in web design and I have been learning the ropes of Unity. Introductions said and done, here is my question: I'm trying to understand some of the pros and cons, along with the finer details of methods used for lasers, bullets, and so on.
So finally, here is what I am looking for specifically:
Any help will be GREATLY appreciated. I'm building it for computer, so I'm not trying to cram this onto an iPhone, though I'd still like to try and keep it optimized.
(comments are locked)
|
|
Well, this is a bit of a huge question. I'll try to address it point by point! Assuming you have a single script which you set up in the inspector for different kinds of projectiles (despite how horrendously unrealistic slow lasers are, but that doesn't matter), your script needs to have the following-
Now, it's kind of a 2-stage thing, since both the gun and the projectile play their own parts in this. You should be able to set up the gun so that it can shoot any kind of projectile which meets certain criteria, and set up the projectile so that it meets some common interface or standard. Exactly how you do this is up to you- you have quite a few different options. The gun needs to know a few things-
Given this information, I would then do something like this to acutally do the shot- This will instantiate a prefab, and then send a message to the newly-created object telling it what direction to move in. Now, this message can be implemented any way you like- so you could have a rigidbody-controlled projectile, in which you would just set its velocity to the shootVector, or you could be using a transform.Translate-controlled one, which case you would do something different. Now, the collision detection thing is another thing you need to look out for- to avoid the 'bullet through paper' problem, you need to do more than just rely on Rigidbody physics to manage everything for you. The way I do this, is using Physics.Linecast between the object's previous location, and its current location. As for the optimisation problem, I wouldn't recommend adding lights to lots and lots of projectiles, but you can do that on key ones to draw the eye to them. Depending on the shader, you can do self-illuminated glowing textures, or particles- but in the end it really just comes down to testing. See how many bullets you can manage! Thanks for the quick reply man, I'm definitely grateful! I've been pulling my hair out trying to find a straight answer to this. I'm still getting into working with physics casters, but I'm sure I can find some more tutorials for that. As for the projectiles and performance, instantiating lots of these projectile game objects and then destroying them after, say... 10 seconds, won't gum up the frame rate or performance correct? Or will this approach eventually add up and kill my frame rate in the end? It also sounds as if I could skip having a rigid body all together if the collision is being detected by linecast. Also, do each of these projectile objects need to have a visible mesh of some kind in them? Or can an empty game object be assigned all of the components necessary? Granted a billboard plane likely counts as a mesh even though it only has 1 face, if I go that route. Somewhat related/unrelated question: Would it also be wise to pool the particles effects and move/call them to position of the collision rather than just instantiate new objects each time? I apologize if these questions are overly trivial.
Nov 08 '11 at 08:03 AM
NickehG
No, there's absolutely nothing to say the bullets have to have meshes on them (or in fact be visible at all, but you want your game to not be unendingly frustrating to play). Your idea with pooling the particle effects is a good one- you can do very clever things with moving particle effects around and emitting particles at specific points. I've never gone down that route personally, but I can see it working quite nicely. You can assemble gameObjects at runtime, if you feel like it, using AddComponent- prefabs only really exist for convenience. Don't apologise for your questions - for one thing, they're far less trivial than some of the questions we get here, and for another, you seem to be aware of the fact that seemingly simple concepts can have complex implementations, which is something a lot of people fundamentally don't seem to understand...
Nov 08 '11 at 08:13 AM
syclamoth
(comments are locked)
|
