Jump to content
  • Advertisement

ferrous

Member
  • Content count

    1128
  • Joined

  • Last visited

Community Reputation

6159 Excellent

1 Follower

About ferrous

  • Rank
    Contributor

Personal Information

  • Role
    Writer
  • Interests
    Education

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What's the scenario you're describing here? A turret on a moving object trying to hit another moving object?
  2. ferrous

    Action points or not?

    Yeah, but then you force the player to figure out whether a weapon that costs 56 AP to fire is better than the weapon that costs 59 AP to fire. And the thing is, the difference is really negligible at that point. Unless you get a gun that costs < 50 AP to fire. Which would then be the better gun, unless its 48 vs 47 again. It's forcing the player to make a mostly busybody calculation in their head, as the granularity isn't really bringing anything meaningful to the table. You could try other ways to distinguish weapons than by how much AP it costs to fire them. Accuracy, ammo capacity, burst fire, damage, jam chance, etc. Though I think you should revisit your initial premise, why do you want to have a large variety of weapons that are the same caliber? Why do you want nine pistols that are all 9mm?
  3. Hmm. Inheritance in Unity is usually a sign you're heading down a bad path. Are you sure that shouldn't be a separate component? I think your clone is wrong too. You should Instantiate a new prefab and then copy the members, if you're actually trying to create a new object. Then StartCoroutine would work on it, and you wouldn't need the pickupmanager. (and it will probably prevent any future errors with trying to use a Monobehavior that isn't hooked up to Unity properly) Yeah, I could see update and check being slower, it probably has to load the whole Monobehavior into the cache, then unload it, because it can't tell that it's going to early out in the update method. So looping over 1000 monobehaviors all doing Update checks like that is painful, compared to a coroutine, which has time intrinsic to the coroutine itself, so it iterates over a much smaller object. Your priority queue method would also eliminate that loading of multiple monobehaviors.
  4. ferrous

    Get rotation angle from normalized 2D vector

    For shaders, yes, you will need to learn a shader language. Though they are fairly straightforward to learn, certainly less complex than any higher level language like C++ or Java. However, I wouldn't worry about tackling it until you're ready, you seem to have enough on your plate. If you end up bottlenecked for speed, then most certainly dive in and give it a try though.
  5. ferrous

    Get rotation angle from normalized 2D vector

    32 bit windows XP? It's kind of admirable you're targeting that, but that encompasses 0.22% of all Steam Users. You can pretty safely target higher OS versions at this point. (Other than that, I agree that fastest trig function is the one you don't call, and use the vector instead of the angle when you can) EDIT2: As this is for rendering, you could do all your work in shaders, which will be faster still. Maybe treat each sphere/circle/node of your worms as an instance and utilize instancing to rotate them in the vertex shader.
  6. I hate random flee chances. Have you considered a non random version? Something like the opponent always gets one free attack, but the player gets away. Or the player can always flee, but the option isn't available until after X turns -- could even make that level dependent, so against a weak opponent, X is 0, while a equal or harder opponent, X is 1 or 2 turns.
  7. Two things that tend to help a lot when trying to find the source of errors: 1) Debug.Log(), for example, if you printed out who was colliding with what, you might see what was causing the overflow. 2) Set some breakpoints, and attach a debugger. The latter, especially, is a very important skill to develop.
  8. Just a guess off the top of my head, but you've probably got a circular collision going on. Like, you are probably checking for collision against the very brick that is exploding, which causes a chain reaction of: Hit a brick-->do explosion --> oh we hit a brick --> lets explode -->oh we hit a break -->lets explode ..etc. The easy way to do this, is to instantiate the explosion and destroy the brick, then have the explosion have the script that does the overlap call in its update, which gets called on the frame after the brick is destroyed. (It also has a nice separation of concerns, bricks only do brick things, explosions do explosions.)
  9. ferrous

    Unity, how to deal with large amount of projectiles.

    Have a growing pool. Have the poolsize start at 150, but if you hit that cap, add 10 to the pool, etc. It's not all that different than what List<> and std::vector do under the hood. You can also shrink the pool by checking every so often, and seeing if you no longer nearing the current max poolsize, and freeing the excess. In unity, with an arcade shooter, one could also do Physics.OverlapCapsule, so one wouldn't have to sacrifice the bullets size.
  10. ferrous

    Unity, how to deal with large amount of projectiles.

    yeah, that is a common thing, the sphere is relatively expensive to render of the default primitives. there is a lo poly primitive asset pack, or you can make your own.
  11. ferrous

    Unity, how to deal with large amount of projectiles.

    Things that make projectiles slow: 1. Having them on a layer that intersects itself, they should be on their own layer that doesn't self intersect. If player bullets can intersect enemy bullets, then use two layers -- but they should still not self intersect. 2. Have them using a expensive collision primitive. Use a sphere or a circle. 3. Using an expensive to render mesh / sprite 4. Not using object pools, and instantiating a new projectile every time one is fired. Those are the usual gotchas. Failing those, I'd profile it and see. The built in unity profiler is easy to use. edit: One last one, if you have increased your physics rate, or messed with solver iterations
  12. ferrous

    Generate unique ID per user

    Use the device's mac address? If the user changes hardware, yeah, it'll change, but that's not super often.
  13. So, I didn't get as much time as I wanted on this, and I'm late to the party. But here's my missile command challenge: http://joshv.itburns.net/MissileCommand/ Works best in Firefox, takes a while to load in Chrome...and Edge, well it runs like crap on that. I didn't get a chance to add sound, unfortunately.
  14. So, I didn't get as much time as I wanted on this, and I'm late to the party. But here's my missile command challenge: http://joshv.itburns.net/MissileCommand/ Works best in Firefox, takes a while to load in Chrome...and Edge, well it runs like crap on that. I didn't get a chance to add sound, unfortunately.
  15. ferrous

    Missile Command, Part 1

    Okay, I lied, life happened, not sure I'll make the January deadline (not that it matters all that much, I suppose). I'll still try to get a link and some screenshots up when I get a chance.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!