If you've got two tables and there are about 60-70 rows, it's all going to be in memory extremely easily. Is it actually causing you any pain at all? I can't see how this would be a problem, unless you're either getting a vast number of hits, or you're running your database and site on a tiny, tiny machine.
Some information could be stored in the session. Non-volatile things like user name, player/character name, etc... That's not going to change very often. But things like current score, gold/credits available, etc.. which change frequently and should be kept consistent would most likely have to be pulled from the database each time. Consider what happens if they open two browser windows and do some shopping in each. Both load up saying you've got 500 gold available and both could potentially purchase something for 499 gold at the same time.
But, it comes down to what's faster, really. Do some benchmarking and see if pulling 60-70 bits of data from the database for each hit is faster/slow than pulling a mix of database/session data.
A single query per page is actually really good - a more complicated site/application will include multiple requests. If the information isn't always required, you could include right at the beginning of every page:
$require_lookup=false;
Or true - depending on if the info needs to be loaded this time. This spares the lookup on the pags when it isn't needed (presumably some pages are outside the game - the help page for example).
Storing that data in sessions, assuming they're file based (you can get database base sessions too, which will have you right back where you started) will simply move the memory constraints from the database to the file-system. Ultimately if your application is going to become popular, you'll be separating the database server from the PHP server - maybe even using multiple PHP servers - which will mean a file based session system will no longer work.
Stick with what you've got - it'll work fine for now.