Here is my game prototype.

The code of the camera feature in this 2D game is achieved by having offsetting the object's positions depending on what arrow key was pressed from the user.

These objects(2 objects right now in the game ie: block and background image) are able to move by adding a KeyListener interface and overriding their keyPressed method with my own logic.

The problem is I need to do this for every object that appears on screen except for the character Spiderman in the future as well.

Any ideas on a better or an ideal code design to achieve the same effect in my 2D game? The game is coded in Java.

On a side note: I have a idea for a code design for the camera but the camera needs to know which object are on screen and offset their position by a certain amount when the user presses a key. Seems like I am overcomplicated the feature by coming up with this idea.

P.S. Is a camera feature even suppose to have access to the objects appearing on the screen of the game? Is that the camera job even suppose to have access to a list of game objects in the game?

The camera should have its own coordinates. These coordinates will determine where the screen is currently positioned in the game area. When you render an object on screen, you do so in relation to the camera's coordinates. Just subtract the camera's coordinates from the object's coordinates to determine where it should be drawn on screen.

In other words, the object's render function needs to know about the camera. The camera doesn't need to know about each object.

It seems like you're having a similar issue to the gentleman in this thread - I posted a few posts there about making the objects have "global" (relative to the map) positions, and then calculating the "local" (relative to the camera) positions on-the-fly when drawing the objects.

The camera should have its own coordinates. These coordinates will determine where the screen is currently positioned in the game area. When you render an object on screen, you do so in relation to the camera's coordinates. Just subtract the camera's coordinates from the object's coordinates to determine where it should be drawn on screen.

In other words, the object's render function needs to know about the camera. The camera doesn't need to know about each object.

Interesting! I never thought about adding an extra parameter from the Camera object to the draw method.

Thanks for the feedback!

It seems like you're having a similar issue to the gentleman in this thread - I posted a few posts there about making the objects have "global" (relative to the map) positions, and then calculating the "local" (relative to the camera) positions on-the-fly when drawing the objects.

Wouldn't adding a global variable or a constant in Java violate encapsulation of an object?

I do like your posts on that thread. A Great example and ideas! Thanks!

Global means "world space" in that context, it would be a property of the camera object (world space position) used to render the scene.

Oh I see. So it is more of a convenience.

Global means "world space" in that context, it would be a property of the camera object (world space position) used to render the scene.

Oh I see. So it is more of a convenience.

No, the word 'global' here means different than the word 'global' as a global variable. It's not a "convenience", it's not a global variable at all.

By "global" I am talking about a concept of measurement. Pretend I didn't use the word "global" at all, because I'm not using the word "global" like you think.

A microwave in pretend kitchen is located with an X coordinate of 5 feet and a Y of 2 feet, relative to the refrigerator.

But that very same microwave, without moving at all, is also located at a X coordinate of 22 feet, and a Y coordinate of 12 feet, relative to the TV in the living room.

The same object, in the same place, has different coordinates depending on what it is "relative to", it is a different distance from the "origin" that you are measuring it against.

If you tell a computer to draw something, it's going to draw it relative to the screen. Your graphics API requires coordinates relative to the screen to draw things.

Instead of moving hundreds of objects when you really want your character and the camera to move, store all your objects (and the position of your character and the position of your camera) in "global" coordinates. By "global" I mean world-space instead of screen-space.

Don't measure your microwave's coordinates relative to your TV or relative to the refrigerator - choose one specific point in the world (0,0) - the world "origin" - and measure the coordinates of every object, and the player, and the camera, relative to that origin-point.

Because your graphics API still needs to draw objects in screen-space, but your objects are stored in world-space, then whenever you are ready to draw you do a quick calculation to convert the coordinates between one space and another space (the calculations are explained in the other thread).

Here, here's a different thread where I tried explaining it a different way, and drew overly complicated charts. Maybe that might help. Or maybe I just suck at explaining this.

If you tell a computer to draw something, it's going to draw it relative to the screen. Your graphics API requires coordinates relative to the screen to draw things.

Instead of moving hundreds of objects when you really want your character and the camera to move, store all your objects (and the position of your character and the position of your camera) in "global" coordinates. By "global" I mean world-space instead of screen-space.

Don't measure your microwave's coordinates relative to your TV or relative to the refrigerator - choose one specific point in the world (0,0) - the world "origin" - and measure the coordinates of every object, and the player, and the camera, relative to that origin-point.



Because your graphics API still needs to draw objects in screen-space, but your objects are stored in world-space, then whenever you are ready to draw you do a quick calculation to convert the coordinates between one space and another space (the calculations are explained in the other thread).

Is the world always the origin? Something like this: Given Point as a object that has two parameters x and y.

Point world = Point(0,0);

I do like the above example and the another thread you posted! I do feel like I understand it more than yesterday. I'm going to give myself a good night sleep again over this concept.