Just an organisational point - do not put implementation code (the function definitions) into header files.
Put your class declaration into the header file, and your code for the function definitions into a .cpp file.
When I use my IDE, it automatically puts the class declaration into the header file and I can get it to create function stubs in the .cpp file.
Also Dinosaur should be a class of it's own with TRex & other classes inheriting from it. That way a Trex and other dinosaurs can be an objects of their own, rather than being a function inside a dinosaur object.
If you do this you can start to take advantage of OOP ideas - like inheritance & polymorphism.
Finally, by now I think you should get out of the habit of usingnamespace std;. Either put std:: before each std namespace thing or have using std::cout; as example, for each std thing. I do a mixture - I use the first one for things that appear infrequently, and the second for things that are used all the time.
If you can make all these changes - then we will see if you still have problems.
Lines 53 onwards should be in player.cpp. You have player function definitions in main.cpp - maybe these should be in there own class named after the application - maybe Arena or something? Same story class declaration inn arena.h and function definitions in arena.cpp. The player class (and any other class you want to save stuff) should have a WriteToFile function. The Arena class could have a save function that calls the WriteToFile function for each class you want to save. See below for how the WriteToFile function might work.
Similarly, Lines 31 onwards should be in dinosaur.cpp.
As I mentioned earlier, trex & velociraptor should be classes of their own and inherit from dinosaur. Put common functions & variables into the dinosaur class, then only have specialised things in trex & velociraptor. Make the dinosaur constructor protected thereby preventing you from creating a dinosaur object, meaning you can only create trexes and velociraptors - or any other class derived from dinosaur.
Now for your member functions. Try to avoid having a get & set function for each member variable. If you provide a public get / set function for each member variable - you may as well make all the member variables public !!!
Instead, try to think about how things would work realistically. You can make use of the constructor to set values initially when the object is created. Provide functions that output a number of things. Remember that class functions have direct access to member variables, so player::WriteToFile can do it's stuff without the need for all the get functions.
The function name store could be construed as confusing - does it store something? Really you should have a Shop class.
Thanks for the reply and the feedback, i fixed the problem almost right after i made the post but im going to look into everything you mentioned and fix them but for right now the game is functional :D