Splitting up tables with similar structures since they contain unrelated data? (huge numbers)
Your issues are probably less about performance, assuming reasonable equipment and a good indexing structure, and more about other impacts that you face.  

Approach 1 means some additional programming complexity to deal with filtering rows in each table to restrict access to a single gameworld. It also means that if you need to restore a gameworld, you would have to (a) restore all gameworlds (since they are in the same database) or (b) restore the one database to a recovery database and then script the appropriate gameworld data from Recovery to your Gameworlds database.

Approach 2 means that you need to be able to manage schema changes across many databases.  This can be done by scripting as needed.  It is also easier to choose to have different schemas for some gameworlds, but that adds management overhead.  However, if a a single gameworld crashes, you can restore the latest good backup(s) and get it going again.  

Some years ago some Microsoft folks wrote up their take on Multi-Tenanted databases.  See: http://msdn.microsoft.com/en-us/library/aa479086.aspx

Having more tables should not, in itself, cause performance problems within the size range you describe.  

Choosing your approach should take into account leveraging your strengths so that you have a system you (and your project members) can readily manage.