The Problem with Sub-Classing
January 21st, 2009
Yesterday I got all of the non-gameplay related layout changes implemented for 2-player mode. It looks pretty good. I managed to make everything fit on the screen and look good, so I’m happy about that. Today I’m starting to implement the gameplay-side changes that are required, but I’ve run into a dilemma around how to set up the code.
Warning: coding discussion to follow…
This is the way my game is structured at an extremely high level (lots of classes missing from this diagram, but this gives you a general idea of how things work):
Dapple - High Level Classes
Right now all of the information about whose turn it is (in a two player mode) is stored within the GameState class. It stores the users’ scores, levels, etc, and it knows whose turn it is, and who plays next. The problem I’m running into is with the Board.
Right now the board knows nothing about which player is playing. It’s responsible for all of the logic that handles making matches and searching the board for possible matches. For the most part, it doesn’t care about which player is playing…except that now it needs to. In my 2-player mode, both players play on the same board, but each on their own half of the board. This means that all the searching algorithms now need to take into account which side of the board to search, which means they need to know whose turn it is.
This seems pretty straightforward except that the end-of-turn code flow also needs to completely change. When a player ends his/her turn, instead of checking to see if there are any moves left, I need to check if there any moves left for the opponent.
What I’m trying to decide is whether I should sub-class Board into TwoPlayerBoard, or whether to embed the logic inside Board’s functions. Both have benefits and drawbacks. By sub-classing it allows me to keep the two-player logic separate. It means cleaner code for all game modes. However, it also means that any logic bugs in the board would potentially need to be fixed in two classes instead of one. By embedding the logic in the Board it means I only have to maintain one class, but all of a sudden I have all these conditionals in the code for “if (2 player mode) do this, else do this”, which makes things harder to follow.
I think what I need to do is go through all the functions in Board and see which ones need to change for 2 player mode. If it’s less than 1/3 of them, I’ll subclass. If it’s more, I’ll embed the logic.
Phew, I’m glad we figured that out.
Owen
Why do you use one board. Why not have two boards side by side. All of your board logic doesn’t have to change as it still searches just one board. Then, for your end of game logic, you pass the board in, just flip them. Pass in a different board to determine end of game.
That’s quite an interesting idea, but not sure it’ll work. The problem is both players play on the same board. So if I make a move on my turn, pieces from your half of the board fall into my half. Then as one player takes the lead, the dividing line shifts between the players. I suppose it could be done with a master board and two child boards, but that seems messy…
I discovered once I started reading through the code that I don’t have to make that many code changes to the board. Much of where I thought I’d have to write conditionals can be alleviated by passing the current player into a function instead. Since single player games always use Player 1, this works out for all game mode types.
Ah, so Meteos style two player. Then, yea, 2 boards wouldn’t work so well.
More like Lumines, but yeah.