So let's say I have a player class that shoots bullets. I store the bullets in a vector. And then let's say I make all these cool little functions that let the player shoot the bullets, delete the bullets when they get off the screen, etc. but when time comes for the bullets to actually DO something besides move (hit a creature or something), it can't, because the vector is owned by the player class and can't see the rest of the program.
I can think of two ways to fix this:
1. have another class own the vector of bullets and let it handle all the bullet updates/deteles, and only have the player return when it wants to shoot.
2. add the creatues into the player class and have the creatues loop and update all in the player class so it can see the vector of bullets.
Obviously the second one would be horrible, but I needed a second choice..
So what's the best way? If number 1 is on track, can you kind of show me the best way to do it? for example, do I have a class handle ONLY the bullet interactions with other things? or should the class handle EVERYTHING combat related?
I'm using SFML, so this is graphical. Thanks a lot.
Idea for player to own bullets is terrible. Why would it even know about bullets after he shoots them?
Best thing would be creating class which will handle all collisions in your code: between bullets and walls, between bullets and characters, between characters and enviroment. Another way to handle that is to use message dispatching (telling everyone "HI, I'm here, anybody colliding with me?") and resolving collision through double dispatch.
The best way is to have as less dependecies as possible.
So yes: 1.
This other class is a "world" class. That class makes an object move according its energy(speed) and direction, but also reduces the speed and let it fall to the ground according to friction and gravity.
So lets say your hero jumps with the energy of 10, but your gravity is also 10. Then the hero can jump only 1 unit (whatever that unit is: pixel, block, etc)
When an object (bullet) hits another object (enemy) it's another situation. The object that was hit acts according to the energy that the hitting object has (and maybe the size).
So no, you don't need another class that handles the interaction. The object that was hit needs to process the resulting action
should I have multiple vectors of different game objects?
No, that world class cares only whether an object moves or not. Hence all you monsters, bullets and what not inherit from a class that has the basic traits the "world" class needs to move the objects and not to forget the collision detection.
What happens to the objects when the collide is up to the objects itself.
Instead of "world" you may name that class 'scene' or 'level'. That class can do more. For instance measuring the distance between the hero and the monsters. If the distance is too short the monster hunt the hero.
You can accomplish it as you provide each object a virtual update function. In this overriden update function the monsters call the measuring function.
So what about game objects that are very different from each other? For example, a derived class from GameObject called Wall wouldn't need a damage or health value like another derived class called Player or Monster.
Is it good practice to add all of that to the top parent class even though a lot of the derived classes won't ever use them?
And I have another question. Let's say I have a variable called damage. Should I make it public so other objects can directly use the damage variable to hurt itself (like if the player shoots a monster, it would be in the monster's update:
health -= GameObjects[i].damage;
or should it be private and use a function to return its data?
Open ended ideas. It will greatly vary dependent on your processing and algorithm.
When considering relation:
Predetermine who will handle the values of the objects.
Is damage handled by the object viewing everyone? AKA the zone.
Or is it handle independently by each unit?
If by each unit, you would want each unit to have their own.
Zone can ask users and monsters for their damage and hp; so it would probably be better in every individual object.
Having a parallel container holding damage would be kind of silly.
Same applies to health and the other sort.
The difference between bullet and damage is that bullets is an actual sprite; that may navigate the map or has a destruction timer outside of the other sprite objects. And the timer is called from the main game loop; also associating with two or more objects; the caller and the target - it needs a scope equivalent to player and monsters.