Class design for weapons in a game?

I enjoy making games and now for the first time try myself out on mobile devices. There, performance is of course a much bigger issue than on a nice PC and I find myself particularly struggling with weapon (or rather projectile) class design. They need to be updated a lot, get destroyed/created a lot and genera开发者_如何学编程lly require much updating.

At the moment I do it the obvious way, I create a projectile object each time I fire and destroy it on impact. Every frame all active projectiles get checked for collision with other objects. Both steps seem like they could definitely need improvement. Are there common ways on how to handle such objects effectively?

In general I am looking for advice on how to do clean and performant class design, my googling skills were weak on this one so far.

I will gladly take any advice on this subject.

When you have lots of objects being created and destroyed in a short timespan, a common approach is to have a pool of instances already allocated that you simply reinitialise. Only if the pool is empty do you allocate new instances. Apple do this with MapKit and table views, among others. Studying those interfaces will probably serve you well.

I don't think this is about class design. Your classes are fine; it's the algorithms that need work.

They need to be updated a lot, get destroyed/created a lot and generally require much updating.

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.

As for updating, you need to update everything that changes - there's no way around that really.

Every frame all active projectiles get checked for collision with other objects.

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.

#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

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.

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.

Both steps seem like they could definitely need improvement.

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.

As Jim wrote you can create a pool of objects and manage them. If you looking a specific design pattern there is Flyweight .Hope it will help you.