Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I don't think this is about class design. Your classes are fine; it's the algorithms that need work.</p> <blockquote> <p>They need to be updated a lot, get destroyed/created a lot and generally require much updating.</p> </blockquote> <p>Instead of destroying every projectile, consider putting it into a dead projectile list. Then, when you need to create a new one, instead of allocating a fresh object, pull one from the the dead-list and reinitialise it. This is often quicker as you save on memory management calls.</p> <p>As for updating, you need to update everything that changes - there's no way around that really.</p> <blockquote> <p>Every frame all active projectiles get checked for collision with other objects.</p> </blockquote> <p>Firstly - if you check every object against every other then each pair of objects gets compared twice. You can get away with half that number of checks by only comparing the objects that come later in the update list.</p> <pre><code>#Bad for obj1 in all_objects: for obj2 in all_objects: if obj1 hit obj2: resolve_collision #Good for obj1 in all_objects: for obj2 in all_objects_after_obj1: if obj1 hit obj2: resolve_collision </code></pre> <p>How to implement 'all_objects_after_obj1' is language specific, but if you have an array or other random access structure holding your objects, you can just start the indexing from 1 after obj1.</p> <p>Secondly, the hit check itself can be slow. Make sure you're not performing complex mathematics to check the collision when a simpler option would do. And if the world is big, a spatial database scheme can help, eg. a grid map or quadtree, to cut down the number of objects to check potential collisions against. But that is often awkward and a lot of work for little gain in a small game.</p> <blockquote> <p>Both steps seem like they could definitely need improvement.</p> </blockquote> <p>They only 'seem'? Profile the app and see where the slow parts are. It's rarely a good idea to guess at performance, because modern languages and hardware can be surprising.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload