CODEWITHSUNDEEP
c++class
Draksis
Draksis

Reputation: 167

Implementing Similar Classes

I am new to C++ programming, and I am making Pong in Visual C++. My game will have two game modes, multiplayer and singleplayer. Right now, I am planning on having a separate class for the singleplayer paddles and the multiplayer paddles. (So I'll have PaddleMP RpaddleMP, LpaddleMP; and PaddleSP RpaddleSP, LpaddleSP;, where the R and L represent the right and left paddles respectively). However, the code for the multiplayer paddle and singleplayer paddle will be very similar. Would it be better to use one class for them both and simply have an initializer function that allows me to pick whether it is a singleplayer or multiplayer paddle, or should I just make a new class for both?

Upvotes: 1

Views: 143

Answers (5)

Jerry Coffin
Jerry Coffin

Reputation: 490148

IMO, you have two problems here. First, I think the names you've chosen (single player vs. multiplayer) are poor. Second, I think the paddle itself should be independent of the input that moves the paddle.

Therefore, there should really only be one paddle type. You can tell it to move up or down and it'll move the direction you've told it, but the paddle itself knows nothing about the source of the movement command(s).

Then I'd have something that creates/sends the input to the paddle. It seems to me that rather than single player vs. multi-player the relevant distinction here is between a player input and an AI input.

So, we have a player input that reads relevant data from the mouse, keyboard, joystick, etc., and turns it into the relevant commands to send to the paddle. We also have an AI input that produces similar commands, but based on its own computation rather than input from the user.

This is where you want the inheritance -- the AI input and the player input both inherit from generic input type that can produce commands. Depending on your taste, you might not want an actual player input either -- rather, you might have a keyboard input, joystick input and mouse input separate from each other. This will, for example, probably make it a bit easier if you decide to add support for something like a multi-touch screen, which will probably be at least somewhat different from any of the above (but still follow the same protocol/implement the same interface).

Upvotes: 2

Nick
Nick

Reputation: 5805

From an Object Oriented standpoint it makes no sense to cram multiplayer or single-player data within a Paddle class. A Paddle class should only describe behaviour that is specific to a paddle, e.g. size, movement, and what have you.

The way one or more paddles are used should be defined in a separate class, potentially within a Behavior class, such as whether a paddle's position should depend on another paddle's position. You should probably have a MultiplayerBehavior and a SinglePlayerBehavior

And ultimately, you could have the code that glues these two, i.e. a set of Paddle instances and a particular Behavior. This could be the Setup class, that aggregates these two.

Upvotes: 1

Stack Overflow is garbage
Stack Overflow is garbage

Reputation: 247999

A paddle is a paddle, regardless of where you place it, and regardless of who controls it.

The controls (AI or human controlled) should not be part of the paddle, and thus, should not influence the paddle class.

And likewise, it's a pretty poor paddle if you need to rewrite the class in order to place it at the other end of the screen

Upvotes: 6

Grigor Gevorgyan
Grigor Gevorgyan

Reputation: 6853

Well, I think that the most suitable decision for you will be to create an abstract base class Paddle, which will have all common code for all kinds of paddles, and then derive multiplayer and singleplayer paddles from it. Your hierarchy could look like this:

class Paddle {};
class PaddleMP : public Paddle {};
class PaddleSP : public Paddle {};

The same way you can derive RpaddleMP and LpaddleMP from PaddleMP, and RpaddleSP and LpaddleSP from PaddleSP. If such approach seems new to you, I suggest you reading some more about inheritance in C++.

Upvotes: 0

sparkymat
sparkymat

Reputation: 10028

This will largely depend on what sort of code goes into the classes. Depending on this, you can either:

  • Use the same class, and pass the details while initializing (if they are very similar in nature with large portions of shared code)
  • Write a base class which implements the shared code, and derive classes for specific functionalities

In most cases, the latter would be the one that makes more sense.

Upvotes: 3

Related Questions