I must agree with Joe that while some tasks are simple enough, if you are blowing through tasks within an hour, they are either not giving you anything hard or you are missing out on key steps. It could be a combination of both, but if you are doing testing to ensure there is no bugs, that can take a while for even the most simple of tests.
It isn't just going through the game and saying yes, if you play correctly this works. It's about doing it not correctly too. Finding ways to break the game. Can I walk into that rock and hide while shooting people while others can't shoot me? If I press the jump button 4 times really quickly do I get stuck floating and are able to sky walk? What if I launch a rocket at the ground with me standing in the corner, can I push myself through the boundaries of the game?
They might or might not have list of specific things to do, but one thing you don't want to do is only test to see if it works doing it correctly. People who intend to exploit the game won't be doing things correctly and it is up to the people who test it to provide feedback on any exploits to maintain the integrity of the application.
I would slow down in your testing and really try to break what ever it is they give you. Even if testing the jump button may or may not be a part of the test instructions, you could sit there and test jumping around and if you find something just mention that while you were testing the xxxx situations you provided, I also noticed that when I jumped... X happens. They are going to tell you that they either know about it, that the jump hasn't been completely programmed yet, or that they will look into it and thank you for mentioning it.
One of the biggest things in the IT world is your ability to take the task and run with it. It is not like homework where you get a set of 10 math problems, you complete 10 math problems, and you get 10 more. That's just busy work. Spend the time going in detail, spend the extra minute exploring something. Your job as a tester is to break things and think differently from the person who wrote the application. Think like the user, think like a hacker. If you think like the programmer then you only repeat what he assumes is correct since you will follow the same logic and may be less likely to find issues.