• Advertisement
Sign in to follow this  

OOP design with 2D game

This topic is 3313 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a problem with my OOP design for a 2D game. I have a screen object that holds the 2D list of images in the form of tiles and their location etc. The screen is made up of 2D images like grass,brick ,blank for air etc. I have an object for main player including a method to detect if the object collides into any tile on the screen. The problem is passing information from the screen object to the main player object to test for collisions. I can pass information via main program but that involves passing a whole lot of data . If I work out what tiles to pass then i need to calculate where i will move then get tiles to test and then if a collision roll back my intended movements which will require in my player object a method for moving and a method for collision for intended move and it is getting messy.

Share this post


Link to post
Share on other sites
Advertisement
I'm not entirely sure on what you are asking here. But, it would be more helpful if you provided some codes or something-rather.

From what I gathered, it appears you have your main function and the player function? Something that may make it easier for you is to create a Tile class, and give it properties such as whether or not people can walk on it, or anything of that sort. That would shorten down the programming quite a bit for you, and would keep your code nice and managed. This would also allow for you to easily expand onto your tiles, and make them that damage people and everything of that sort.

That's all I could tell you until you provide more information on what you are trying to do :)

Share this post


Link to post
Share on other sites
we simply have 2 classes . one class needs to access a large data structure from the other class. Using the main program as a middle man makes it messy.

i can either

1- make the information i want public for all classes but that means havin a large 2D array in global memory.
0
2- have 2 methods for collisions where I have 1 for getting new value to move, and another to test collision . IN main program I can get tiles to test for collision based on where i want to move and then send these tiles to main
character class.

Share this post


Link to post
Share on other sites
You aren't understanding the point here. You are doing everything in main it seems, which is very messy. You need to create the move functions and everything under the Player class, and then have them do the detection haha, for example:

class Player
{
private:

public:
bool Move(int x, int y);
}

bool Player::Move(int x, int y)
{
checkCollision();
}


[Edited by - dalindeck on December 28, 2008 8:04:27 PM]

Share this post


Link to post
Share on other sites
Why not have the following classes:

Player: contains the player's stats and world coordinates.
World: contains information about the entire world (contains an array of tile indicies which can be retrieved given a world coordinate).
Screen: used to render what the player can see.

Then you can do something like this:


if(move_up)
{
m_player.Move(m_world, NORTH);
}


And the Player::Move() method can use the world reference to check for collisions. Then for drawing:


m_screen.Draw(m_world, m_player);


And the Screen::Draw() method can use the player's world coordinates to draw what the player can see at any given time.

Your "main program" will need to act as the middle man. That's its purpose.

Share this post


Link to post
Share on other sites
Should collisions be handled by the player object at all? I always figured it was something to be left to a physics section.

Share this post


Link to post
Share on other sites
It can be, but I would think that you could have the CheckCollision() called in the Move function, so that it is all contained in that function. The collision may be in a physics class, or something like that, but the call to the check shouldn't be called in main if that makes any sense.

Share this post


Link to post
Share on other sites
you are not understanding what i am asking here.

the main program doesn't handle collisions .
the player program does and to detect collisions I need to know what background tile to test against.

getting the background tile to the player collisions is messy since both are in classes.

Share this post


Link to post
Share on other sites
Create a class for tiles, and give them a property, that would be the easiest way to do things, for example:

class Tile
{
private:
bool isSolid;
public:
bool CanPass(Tile &tile);
};


Something like that, I think I did the function wrong, but the same general idea applies. It is the easiest thing I can see you doing.

Share this post


Link to post
Share on other sites
on something with such a small scale I think you're thinking way too much about this, combine everything into one class.


class object
{
float pos_x;
float pos_y;
float width;
float height;

sprite;

void Init();
void Update();
void Display();
void Free();
};



Then just use a seperate function that will except 2 objects, check if they're colliding and pass back a struct containing data about the collision.

if you really need to seperate things you might be looking into a seperate physics engine, and incorporating a sorta "Model View Controler" design, wich you can google.

Share this post


Link to post
Share on other sites
I am sure this has been said, but as someone said earlier your player class should not do any collision control. In good OOP your player should not need to know anything more then it has to, if it has an inventory it should not "know" what is in it, the inventory class should know what is in it and the player should be able to choose based on what the inventory class lets it (just an example).
For yours the "world" class should hold a instance of your player class. As well you might want to make it so that for a simple game you have a 4 x 4 grid that looks like this
ttrt
mtrt
rrrt
mmmt
In that if your system sees a t and shows a tree, a r and shows a road, and a m shows a mountain. If a P is there it would show the player, this would be a very basic demonstration. However as said above if your world holds an instance of your player and your player holds the location of itself, then it can simply send that information (through something like player.getCoords(); that sends an array (2 values) that are its location, check if it can move to the next location and if it can then do so, if not don't let it.
I would not do what the person above me suggests, keeping your player class and tile class separate is actually better OOP, as well it allows you to add multiple players into your "game" if you wanted to instead.
But your player "program" should not do collision detection. That is because in OOP each class should only know what it needs to know.
Sorry for the large amounts of redundancy

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement