Well, the best idea would be to drop your useless ID column and then set GAMECODE as your primary key.
Adding an auto_increment as a primary key is kind of a "last resort" when there is no other good candidate. Since you stated that GAMECODE must be unique, then clearly it is the perfect choice for a primary key.
In any case, whether primary key or unique key, if you try to insert another record with the same GAMECODE value, you *will* get an error. Trap that error in your (assumed) PHP code, and presto. You are there.
There are many reasons NOT to have multiple tables with the same structure and many reasons to combine them into one table.
Think about it: If you need multiple tables only because of one feature ("compatibility") then simply add one column to your single table (named "compatibility" or whatever makes sense to you) and now you have all the benefits of multiple tables plus the huge benefit of a unified table.
Let's just take one "for instance":
Find me all games of any kind of compatibility, etc., with the word "TREK" in their name and that have "UK" in their region name.
If you had separate tables, you would have to search *ALL* the tables for that information. (Either one at a time or in a huge UNION query.) With a single table, you make one simple query on one table and you are done.
And *PLEASE* don't fall victim to that old "But I'll have too many entries in such a big table" plaint. MySQL can QUITE EASILY handle *MILLIONS* of records in a single table without batting an eye.
By the way, if your GAMECODE does *NOT* imply a particular "compatibilty" and you want to have games with the same GAMECODE but differing COMPATIBILITY values, the answer is easy: Make a *COMBINED* PRIMARY KEY, consisting of both those columns.