Little design help
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.
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.
Last edited on
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.
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.
closed account (j3Rz8vqX)
Reconsider your relations between players and bullets.
Player : uses : Bullet; not has - would be permanent.
Player (1:Many) Bullets.
The zone should have access to players, creatures and all other possible sprites/objects.
Player called for a bullet.
Zone creates bullet with a target.
Bullet hits target.
Zone deletes bullet.
Zone deletes target.
...
Player : uses : Bullet; not has - would be permanent.
Player (1:Many) Bullets.
The zone should have access to players, creatures and all other possible sprites/objects.
Player called for a bullet.
Zone creates bullet with a target.
Bullet hits target.
Zone deletes bullet.
Zone deletes target.
...
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
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
In my "world" class, should I have multiple vectors of different game objects?
Like one for the player bullets, one for monsters, one for objects, and then loop them all in different loops using iterators? Or should one vector hold everything and loop that?
Like one for the player bullets, one for monsters, one for objects, and then loop them all in different loops using iterators? Or should one vector hold everything and loop that?
| should I have multiple vectors of different game objects? |
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?
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?
closed account (j3Rz8vqX)
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.
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.
Last edited on
I was going to use two for loops that loop though each iterator in the "zone" object. Which is why I'm very confused on this topic.
Because I'd use a vector, and the vector would be a pointer of GameObject, the "zone" will only be able to view the members in the base GameObject class.
But every GameObject won't be using damage or health. And others will.
So do I bite the bullet and have some kinds of GameObjects not using half their data members? I feel like that's awful practice. But it seems like the easiest..
Because I'd use a vector, and the vector would be a pointer of GameObject, the "zone" will only be able to view the members in the base GameObject class.
But every GameObject won't be using damage or health. And others will.
So do I bite the bullet and have some kinds of GameObjects not using half their data members? I feel like that's awful practice. But it seems like the easiest..
closed account (j3Rz8vqX)
It is really up to you (You are the creator of your program).
(IMO):
A parallel vector that contains the address of all game objects will enable you to have a collection of objects by address.
The game objects can be held in unique vectors parallel to the resource manager; allowing them to maintain their identity - derived classes.
Drawing utilizes the resource managers (x,y); can access the objects with base type definitions.
Physics and behavior is done through the parallel vectors Players, Monsters, Bullets, and walls. (Hp, Move, ect..)
Again, it depends on your algorithm and the process pattern of your game loop.
I'd say make it works first.
[...Removed...]
Unless you're trying to reinvent/induce the wheel, you best look at someone else's algorithm and build up from there.
Improve the code, or use what you can and consider some* brute force, if necessary.
Complete what you originally designed! and if it is missing designs or not designed at all, redesign or design it first before implementing it.
Ask yourself what you must do to display all of your objects; object draw loop. What the game must do the proceed; object processing loop. And what will complete the game; game loop break/end.
There may be multiples of each loop to handle different patterns.
Good luck.
(IMO):
A parallel vector that contains the address of all game objects will enable you to have a collection of objects by address.
The game objects can be held in unique vectors parallel to the resource manager; allowing them to maintain their identity - derived classes.
Drawing utilizes the resource managers (x,y); can access the objects with base type definitions.
Physics and behavior is done through the parallel vectors Players, Monsters, Bullets, and walls. (Hp, Move, ect..)
Again, it depends on your algorithm and the process pattern of your game loop.
I'd say make it works first.
[...Removed...]
Unless you're trying to reinvent/induce the wheel, you best look at someone else's algorithm and build up from there.
Improve the code, or use what you can and consider some* brute force, if necessary.
Complete what you originally designed! and if it is missing designs or not designed at all, redesign or design it first before implementing it.
Ask yourself what you must do to display all of your objects; object draw loop. What the game must do the proceed; object processing loop. And what will complete the game; game loop break/end.
There may be multiples of each loop to handle different patterns.
Good luck.
That's really good advice. I think I've been to obsessed with "good design" that I haven't actually been able to create something I can actually play. I'll take your advice.
Topic archived. No new replies allowed.