So what I'm seeing here is a little contradictory because innings aren't really directly an attribute of games, except indirectly. But maybe that's just me. I would personally suggest something more like a RunsScored table, and have it link back to a GamesHeader table, of some sort, so consider:
CREATE TABLE GamesHeader (
GameID INT IDENTITY(1,1),
HomeTeamID INT, --FK to teams table, naturally
AwayTeamID INT, --FK to teams table, naturally
FinalInningsCount BYTE, -- for faster reporting after the game is over
FinalHomeScore BYTE, -- for faster reporting after the game is over
FinalAwayScore BYTE, -- for faster reporting after the game is over
--Other attribs
)
CREATE TABLE RunsScored (
RunsScoredID BIGINT IDENTITY(1,1), -- for faster reverse traversal, possibly. May not be needed, this depends on your setup, as the normalization will show a composite key anyways
PlayerID INT, --FK to players table naturally
GameID INT, --FK to GamesHeader table naturally
Inning BYTE, --wait for the payoff
RunsEarned, --because you may want to track this by the player ... really the problem is that there's not a single naturalized setup for this, so you may be intersecting this table to another stats table elsewhere. idk, it depends on your model. I'm going for fairly simplistic atm. Wanted to demonstrate something else entirely, but this needs to be accounted for.
-- other attribs
)
SELECT MAX(r.Inning) FROM RunsScored r JOIN GamesHeader g ON g.GameID = r.GameID WHERE GameID = 'x'
That'll give you the maximum Inning played for a particular game, and you can further refine by PlayerID -> TeamID to figure out more details if you wanted to. What those might be I'm not sure.
I would probably actually refine that second table to not be RunsScored but something about AtBat because that's really what you're tracking. I just wanted to show how you could denormalize the inning away from the game table. I would tweak my model to flow like that, were this my project. HTH. YMMV.
Also note that I'm a TSQL guy, but I think the concepts expressed below work pretty well for explaining my concept. Language semantics probably won't line up.