2D stuff position best practice

Started by
7 comments, last by C 9 years, 1 month ago

Hi there!

I'm doing a 2D game with libGDX and I wonder what's the best practice to positioning elements on the screen. I mean, should I use pixels to set a position for the element(sprite, image, etc...) or a relative positioning? Since libGDX implements Viewports you can define your dimensions and you just work inside your "limits" you established, but I don't know which option I should chose.

Advertisement
Probably neither.

The game world is likely represented in memory in your own map format. Start with that. Then you render a view of that data that is offset based on the logical viewport for your game.

For instance, it doesn't matter if your game world has a (0,0) origin in the middle of the map, or if the origin is close to the start of the level, or near the end of the level, at the top, at the bottom, or somewhere else. From the player what matters is that their view of the world is centered around their character, and that the view stays basically centered around their character as they move around the world.
Depends a lot on what you're trying to do.

Advice would differ from a game that has a static view and doesn't scroll at all to say a 2d rpg that has infinite maps that load in chunks around some arbitrary origin point.

There isn't some magic method to it.

Probably neither.

The game world is likely represented in memory in your own map format. Start with that. Then you render a view of that data that is offset based on the logical viewport for your game.

For instance, it doesn't matter if your game world has a (0,0) origin in the middle of the map, or if the origin is close to the start of the level, or near the end of the level, at the top, at the bottom, or somewhere else. From the player what matters is that their view of the world is centered around their character, and that the view stays basically centered around their character as they move around the world.

I think I understand you, but I did this question because I made a background for testing and the road of the background has 135px of height, so I think is better positioning my player at 135px on the y-axis. As you can see in the image, the gray pattern is the ground:

S30r8VK.png

I did this question because I made a background for testing and the road of the background has 135px of height, so I think is better positioning my player at 135px on the y-axis.

As frob was trying to tell you, pixels are not your units of measurement.

Pixels are used to measure things on the screen, which is completely separate from where things are in the game world.

This should be obvious when you consider that the camera can go up and down, and then suddenly, “I should put my player at 135 pixels,” has no meaning. Plus different resolutions. If the player’s screen doubles in size, the ground should be 270 pixels tall.

It clearly does not make sense to keep track of the player’s position (or any other objects’ positions) in pixels.

You have a game world on a static coordinate plane set.

Separately you have a camera with its own width, height, X, and Y. A scaling factor would be derived to indicate the ratio between your desired size and the actual size.

You convert from the game coordinate to the screen coordinates every frame.

All game logic takes place in the game world (not the screen world) using fixed predetermined sizes etc. There is just a conversion for rendering. That is all.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

I did this question because I made a background for testing and the road of the background has 135px of height, so I think is better positioning my player at 135px on the y-axis.

As frob was trying to tell you, pixels are not your units of measurement.

Pixels are used to measure things on the screen, which is completely separate from where things are in the game world.

This should be obvious when you consider that the camera can go up and down, and then suddenly, “I should put my player at 135 pixels,” has no meaning. Plus different resolutions. If the player’s screen doubles in size, the ground should be 270 pixels tall.

It clearly does not make sense to keep track of the player’s position (or any other objects’ positions) in pixels.

You have a game world on a static coordinate plane set.

Separately you have a camera with its own width, height, X, and Y. A scaling factor would be derived to indicate the ratio between your desired size and the actual size.

You convert from the game coordinate to the screen coordinates every frame.

All game logic takes place in the game world (not the screen world) using fixed predetermined sizes etc. There is just a conversion for rendering. That is all.

L. Spiro

Yes! I realized that a few minutes when I did the last quote. I mixed the pixel and the position unit because I'm doing my background in Photoshop and the ground are 135px in the software so in the game programming I'm basing the units with the pixels of the image, if you understand me.

Reformulating my question, I just wonder if it's good practice positioning my elements on the screen with arbitrary units or using relative positions (if there's another technic to use).

You use “arbitrary” in a way that makes it sound like a pejorative.
Whatever unit you decide to use for your game world is arbitrary. It only matters that it is consistent and can provide a consistent conversion to and from screen space.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid


Reformulating my question, I just wonder if it's good practice positioning my elements on the screen with arbitrary units or using relative positions (if there's another technic to use).

Yes, with arbitrary units, where arbitrary units means something like "tile grid locations".

Pixels means nothing.

You can put your items anywhere and they have absolutely zero relationship to pixels. In 3D games they often establish a unit similar to the real world, 1 unit = 1 meter. Other times, 1 unit = height of characters. Or you can have 1 unit = 1 foot, or 1 unit = 1 cm. These units make sure everything has the same scale within the game, but they have nothing to do with how it is displayed to the user. A user can be playing on a high resolution 4K monitor or on a 320x200 phone, those pixel sizes mean absolutely nothing to the game world sizes.

Similarly in 2D, your object sizes and their locations have absolutely zero relationship to pixels. You may decide that a character is 2 blocks tall, that the character can jump 5 blocks up, and build your world accordingly. You may decide to place your objects in a grid of blocks, and characters can walk at sub-block locations at (for instance) 255 sub-locations horizontally and vertically. You may decide some other scale for your games altogether. Then you may choose to render blocks as 64x64 pixels, or 90x90 pixels, or 16x16 pixels. The pixels have no direct relationship with the game world.

The exact scale you use for your game is up to you. It can be basically whatever you want as long as it is self consistent. Obviously you'll want to keep those "whatever you want" to be somewhat sane relative to computer power, such as not computing planets with an atomic scale, but keep them inside a compute-friendly range of under a million or so, and you'll be fine with just about anything.


You use “arbitrary” in a way that makes it sound like a pejorative.

It wasn't my intention, sorry. It's just a form for say where I can put those elements.


Yes, with arbitrary units, where arbitrary units means something like "tile grid locations".

Yes, this.

Thanks for the answers, helped me a lot!

This topic is closed to new replies.

Advertisement