I know it feels bad when someone pours cold water over your project that you have probably spent quite a bit of time on, but the thing is you aren't the first person to have this happen, and certainly won't be the last.
The changes I suggested weren't that bad - you can cut & paste a lot of them, and I really think it would be worth your while. The stuff you learn here can be applied to any larger program you might do in the future.
Wouldn't you rather learn to design & organise properly? You might find that your problems go away when you do this.
ok I'll try to change everything but i'll need some help here and there. Once im guided through something its easier for me to understand. Also I stopped using using namespace std; and just did a search and replace and put the std:: in front of everything that belongs to the std namespace. what else do i need to do? make Trex and raptor their own classes? why is that thoug? i thought it was easier to make a generic class that every dinosaur could inherit from because theres going to be like 10 more in the future.
what else do i need to do? make Trex and raptor their own classes? why is that thoug? i thought it was easier to make a generic class that every dinosaur could inherit from because theres going to be like 10 more in the future.
You do make a generic dinosaur class, and put in it all the functions & variables that are common to all the dinosaurs. Then you derive whatever other dinosaurs from it - that way they can be their own objects, with their own data & behaviour.
At the moment your trex & raptor are just functions.
You don't have to put std:: before everything - you can do this for frequently used things:
1 2 3 4 5 6 7
Have a read through what I said in the other thread, with regard to classes for the Shop, the Application (for saving &loading stuff). Also about what goes into .h and .cpp files.
Hope all goes well - look forward to seeing how you go.
It's nearly 11:30PM here in Melbourne, Australia - so it will be morning here before I reply again.
I wonder how many times the same static array is deleted here?
I think I advised against using dynamic allocation (after someone recommended it). Don't try it unless you know what you're doing.
If I recall from other threads, this array is never used anyway as the values are all hard coded in the attack function.
Your issue may be here.
I changed some value and now everything works fine for some reason, very weird. But anyways thanks for the help. I have another problem I have an arena and its supposed to load the players ammo count and stuff but it loads whats pre defined in the player class and not from the file, if i view my backpack it displays the ammo and stats correctly that were loaded from the file but it wont do it in the arena for some reason. why is that? the code is too long for this site so its here on pastebin
I don't know whether you had any boring teachers, who made boring statements like "You should design you application before you start coding it". It seems to me that you are now finding out the hard way why that is so.
Some more thoughts about how you can go about reorganising you project:
1. Start a new project - so you can keep your existing one.
2. Use the class wizard (does your IDE have one?) to make new classes, so it creates the .h & .cpp files for you - and learn how to get it to create function stubs in the .cpp file automatically. I name my classes with a leading C - among other things, it makes it easier to name objects - this is important to know beforehand because it affects the names of your class files. I also name member variables with a leading m_ , this also has advantages.
3. Copy & Paste the things you are going to keep, from the old project to your new one.
Now to think about Object Oriented design. It is not as easy as what people think - there are a number things to consider. I think of it like this:
1. Decide what objects you need, and what attributes (member variables) they need. A big concept is encapsulation - things to do with an object go in that objects class.
2. Decide on what relationships they need (inheritance for now). There are 3 types:
- "IS A" implies inheritance. A CTrex "IS A" CDinosaur;
- "HAS A" implies composition (An object contains another object) - the CBackPack has objects in it;
- "USES A" implies that an object is a parameter for a function. E.g. void Attack(CRaptor *Raptor)
3. Decide on how the various objects are going to interact with each other. This gives clues as to what functions (private, protected or public) are needed for each class, including access to member variables (private or protected only). Only provide what is necessary and don't have getters & setters.
4. Try to push functions & member variables as high up the tree as possible. Generalising the parameters helps with this - make use of polymorphism by making the parameters pointers to a base class.
5. Think about how the virtual functions are going to work - Pure virtual for interfaces, virtual functions for those that may not need to be redefined.
So for the objects (classes) I think you need. Obvious ones are CPlayer, CDinosaur, CTrex, CRaptor.
Also (not so obvious) CActor, CEnemy, CMainApp (for Loading & saving to files, menus etc), CGamePlay, CShop, CResource, CWeapon, CPistol, CRifle, CShotGun, CAmmo, CMediPack, CMoney, CBackPack, CStats
Right now, you are probably thinking that I have massively complicated the situation. On the contrary - your existing code is way too simplified, with a lot of things mixed together, and that is the cause of your problems IMO. Einstein said: "Things should be simple, simple as possible, but no simpler". A lot of people trip over the last part which really means that one has to have just enough complexity to deal with the complexity of the situation - making things too simple makes it worse.
With MediPacks & Ammo it is important to realise that that a player can have them, but might use them later. You could probably get away with having a MediPackCount variable which is decreased while the health is increased. However if this was a Board game where resources are lying around (to be acquired at some stage), then all the resources need to be objects as well.
With Ammo, you might get away with Name & Damage members, and use code to set values & decide how they are used, but it might be easier to make all 3 of them classes as well, because you can use constructors to set their various values, and the type helps decide how they are used.
One of the consequences of good encapsulation is that you should have fairly minimal code in your main.cpp file. There is a bit of a rule of thumb about the length of functions - they should fit onto 1 page (80 LOC say) - if they don't then one is not using enough functions.
So there is a fair bit of stuff to think about - can you decide what the inheritance trees are going to look like for the classes I mentioned above?