Rewrite the game object to store 1st layer data in a non-stupid way

[BruceJohnJennerLawso]

Almost anything would work better than the current setup, which has the data in a list, accessed by index (hurls)

Simplest option could be to create variables in the object that store each piece of data, but that doesnt really deal with the issue of having individual game stats conditionally accessible (ie when shots are available, or shots per period breakdown is available)

A more sophisticated way of doing this could be to create a 2D dictionary, ie something like
{"tierI": {"Date":"01/11/61", "Venue":"Maple Leaf Gardens", "Home":{"Team Name": "Toronto Maple Leafs", "Team Score":3}, "Visitor":{"Team Name": "Montreal Canadiens", "Team Score":2}, "link":"http://www.flyershistory.com/cgi-bin/poboxscore.cgi?H19610029"}}

that can be used to access conditional data with a try catch block catching KeyError exceptions as a standard way of indicating that a piece of data is not available.

The actual code will probably look somewhat different, given that watMu teams dont have home and away teams, maybe a "ThisTeam", & "ThatTeam" sort of thing instead of "Home" & "Visitor", but the general concept is the same.

This idea could be considered a general solution to #94, since it should be possible to query a game by stat name

However, it probably should be considered that catching exceptions as a standard will probably not work well because of how slow exception catching is from a performance perspective. A better solution will probably be to build a list of available keys from the dictionary, then precheck the list before querying, something like

isStatAvailable("statname")
getStat("statname")

this could also be used to do some screwy optimization, ie when calling stats at tier II and above, the call returning that stat first checks to see if the value is stored in the dict (unless a refresh flag is true), if it is in the dict, it just returns whatevers in the dict, if not, it calculates whatever its supposed to calculate, then stores that value in the dict to reduce runtime. Might improve speed & responsiveness quite a bit.