Object Oriented application problems in game development

Question

I'll be as direct as I can concerning this problem, because there must be something I'm totally missing coming from a structured programming background.

Say I have a Player class. This Player class does things like changing its position in a game world. I call this method warp() which takes a Position class instance as a parameter to modify the internal position of the Player. This makes total sense to me in OO terms because I'm asking the player "to do" something.

The issue comes when I need to do other things in addition to just modifying the players position. For example, say I need to send that warp event to other players in an online game. Should that code also be within Player's warp() method? If not, then I would imagine declaring some kind of secondary method within say the Server class like warpPlayer(player, position). Doing this seems to reduce everything a player does to itself as a series of getters and setters, or am I just wrong here? Is this something that's totally normal? I've read countless times that a class that exposes everything as a series of getters/setters indicates a pretty poor abstraction (being used as a data structure instead of a class).

The same problem comes when you need to persist data, saving it to a file. Since "saving" a player to a file is at a different level of abstraction than the Player class, does it make sense to have a save() method within the player class? If not, declaring it externally like savePlayer(player) means that the savePlayer method would need a way to get every piece of data it needs out of the Player class, which ends up exposing the entire private implementation of the class.

Because OOP is the design methodology most used today (I assume?), there's got to be something I'm missing concerning these issues. I've discussed it with my peers who also do light development, and they too have also had these exact same issues with OOP. Maybe it's just that structured programming background that keeps us from understanding the full benefits of OOP as something more than providing methods to set and get private data so that it's changed and retrieved from one place.

Thanks in advance, and hopefully I don't sound too much like an idiot. For those who really need to know the languages involved with this design, it's Java on the server side and ActionScript 3 on the client side.

Answer 1

I advise you not to fear the fact, that player will be a class of getters and setters. What is object anyway? It's compilation of attributes and behaviours. In fact the more simple your classes are, the more benefits of an OOP you'll get in the development process.

I would breakdown your tasks/features into classes like that:

Player:

• has hitpoints attribute
• has position attribute
• can walkTo(position), firing "walk" events
• can healUp(hitpoints)
• can takeDamage(hitpoints), firing "isHurt" event
• can be checked for still living, like isAlive() method

Fighter extends Player (you should be able to cast Player to Fighter, when it's needed) :

• has strength and other fighting params to calculate damage
• can attack() firing "attack" event

World keeps track of all players:

• listens to "walk" events (and prevents illegal movements)
• listents to "isHurt" events (and checks if they are still alive)

Battle handles battles between two fighters:

• constructor with two fighters as parameters (you only want to construct battle between players that are really fighting with each other)
• listens to "attack" events from both players, calculates damage, and executes takeDamage method of the defending player

PlayerPersister extends AbstractPersister:

• saves player's state in database
• restores player's state from database

Of course, you game's breakdown will be much more complicated, but i hope this helps you to start thinking of problems in "more OOP" way :)