I think the composition sounds too "melancholic" right now. You say he markets energy drinks and extreme sports, something slighty uplifting, powerful, in-your-face would fit better. Also the mixing and tone of the different tracks is not optimal it all sounds very muddy.
Did you record guitar and bass directly to interface or with a microphone? I'd suggest to bypass the amp completely - at least for now - and just plug it straight into the interface and use a software solution instead. You will get a much more defined sound that way.
You don't need to translate to the player position. Use a special camera that is located at the origin and draw the 1st person model there too.
Most games also clear the z buffer before drawing the hand model and set the projection matrix near/far values very close to the camera to get more precision and prevent the gun from sticking into walls and objects.
You can even experiment with the projection's fov, sometimes it looks good to choose a different fov for the 1st person model.
Why not hold it in your hand? How would you suggest using it?
I had some problems where the H1 would record a lot of low frequency rumble when moving, even though I tried to hold my hand perfectly still. In hindsight that may have been the "sock contraption" scraping against the microphone cage though.
I'll see if I can upload the recorded sounds to dropbox or something.
EDIT: Unfortunately I don't seem to have the raw sources on this computer. Most samples are edited in some way. Ambience and waterfall have layered noise.
EDIT2: I'm not sure if I am supposed to upload these.
In c++ you can not test if a raw pointer actually points to allocated memory. You have to keep track of that yourself. I guess the problem you were experiencing was double-deleting memory. One solution is to set the pointer to null immediately after deleting it, if you plan on reusing it later.
However, you should also look into the standard library containers and smart pointers. (std::vector, std::list, std::shared_ptr, std::weak_ptr, etc.) They are the basics of modern, idiomatic c++ and in many cases eliminate the need to manually manage your memory.
Logically I would assume that it is more likely that it will take longer than 1/120th of second to compute 1/120th of simulation time than it would be to compute 1/60th in under 1/60th of a second. Then why am I observing a more responsive simulation virtually free of stutter? What do most people use as their timestep?
It's not really clear from your description what kind of stutter there was before. How many frames per second are you rendering? If your physics update rate is less than your rendering rate there will be some stutter unless you employ interpolation to hide the discrete physics updates. Which will introduce some latency itself.
As for what most people use as their timestep: It really depends. If you have a really simple simulation with slow moving, big objects you can get away with a much bigger timestep than you would use for complex simulations involving stiff springs, like in a car suspension for example.
What I really hated about DayZ apart from the bugs was the zombie behaviour. Those spatic, zig-zagging, hawk-eyed sprinters... really killed it for me.
I'd like to see some more complex behaviour. Different types of zombies, with fast and aware types being the exception.
"I am legend" types would be pretty cool, you know, thoses that only come out in the dark.
Some kind of alliance system with base building, safe-zones, pvp.
Honestly, to me it sounds like you are overanalyzing the "problem". I never encountered anything along those lines that was really noticeable and without seeing this myself I can't imagine what the problem actually looks like. Are you sure the wrong motion isn't caused by something else?
I usually tend to design more in terms of state and transformations.
Think about what structure can represent each valid configuration of your game unambiguously. Then think about which are valid transformations on that data and which actor has the authority to do these.
This should lead to a nice code structure will well defined operations where classes control the integrity of the game state.
EDIT: I realized this sounds pretty vague. Maybe it is because that's the way one should design regardless of language. I guess the TL;DR version would be: Don't think of OOP as a philosophy that forces you to program a certain way. Rather, think of it as a tool set that enables you to more efficiently implement a sensible design.