Some of this will duplicate things that've already been said.

Out of curiosity, are you using a perspective or orthogonal projection? I'll assume orthogonal (which seems most appropriate if it's purely 2D), but you mentioned a camera position with a non-zero z value, so I wasn't sure.

The first thing I'd do is ask these two questions:

- What you want your units to be (e.g. meters, etc.).

- The minimum distance in these units you want to be visible in the x and y directions at all times (aside from zooming or whatever).

Barring possible practical limitations, both of these are entirely up to you. For example, for a game with human-sized characters, you might want the units to be meters, and be able to see at least a 10-meter-by-10-meter square at all times. For a city-building game, you might want the units to be kilometers, and be able to see at least a 20-km-by-20-km square at all times. Of course the code doesn't care what the units are - that's just conceptual. The minimim required visible size is what's important here.

Whatever your desired minimum game size is will give you your desired aspect ratio (width / height). Obviously the window aspect ratio won't necessarily be the same as the desired game aspect ratio, so you'll probably have extra space to fill along one of the axes. For example, your minimim desired size might be 10x10, but you might have to fill 15x10 (which is basically an art and design problem).

So we can start to collect some data:

- Desired game size (e.g. 10x10).
- Desired game aspect ratio (desired game width / desired game height).
- Window size (e.g. 1024x768).
- Window aspect ratio (window width / window height).

The next thing is to compute the actual game size. It should have the same aspect ratio as the window, while ensuring that at minimum, the desired game size is visible. This post is getting long, so I'll skip over the details, but computing this reduces to some simple arithmetic.

Finally, you render everything in your desired units. Assuming orthographic, set up an orthographic projection with width and height equal to the actual game width and height. The view transform can be identity, or it can have a translation if the game scrolls, etc.

There's also the matter of choosing appropriate art sizes, but that's a separate issue.

Personally I think this topic can be a little confusing. I doubt what I described above is sufficient to put together an implementation from, but maybe along with the other information provided in this thread it'll give you some ideas.

33 minutes ago, Zakwayda said:

Some of this will duplicate things that've already been said.

Out of curiosity, are you using a perspective or orthogonal projection? I'll assume orthogonal (which seems most appropriate if it's purely 2D), but you mentioned a camera position with a non-zero z value, so I wasn't sure.

Zakwayda, many thanks to you) I had it absolutely out of my head, the thought about orthographic projection :D. I was using the perspective one in 2D game for real :D. OK, I've already beheld the difference. Here, one unit is a pixel (right?), so now I can treat units how ever I want, afterwards just changing them with respect to the window size. I will conduct further experiments with this later, but now, I hope, the key's been found

I hope that helps point you toward a solution. I'm not sure what you meant by one unit being a pixel, so I'll just clarify that an orthographic transform is independent of pixel resolution. For example, the window could have dimensions of 1024x786, while the orthographic projection could have dimensions of 8x6. The only thing that must match is aspect ratio, assuming you want to avoid stretching/distortion.

Regardless, you are correct that you can treat units however you want

1 hour ago, Zakwayda said:

I hope that helps point you toward a solution. I'm not sure what you meant by one unit being a pixel, so I'll just clarify that an orthographic transform is independent of pixel resolution. For example, the window could have dimensions of 1024x786, while the orthographic projection could have dimensions of 8x6. The only thing that must match is aspect ratio, assuming you want to avoid stretching/distortion.

Regardless, you are correct that you can treat units however you want

Ah, there are various parameters of projection... What I meant that time was that if the size parameters of projection are the same with the window size, a unit square ('unit' in the sense of scaling from my code snippet) will have the sides of 1 pixel. Though, as you said, those size parameters might be anything, but for now I'm not interested in other options

1 minute ago, master_clown said:

Ah, there are various parameters of projection... What I meant that time was that if the size parameters of projection are the same with the window size, a unit square ('unit' in the sense of scaling from my code snippet) will have the sides of 1 pixel. Though, as you said, those size parameters might be anything, but for now I'm not interested in other options

I see. Yeah, if the projection size is the same as the window size, then it's 1 unit = 1 pixel, more or less (assuming no additional transforms that alter that).

That said, using a different size for your projection allows you to decouple game units from pixel units, which is often what's desired. But, maybe that's not what you're after.

Going back to your original post:

Quote

The resolution of the screen may change, so fixed coordinates and sizes are inappropriate (or not?). Maybe then I should set numbers relatively the width and height of the screen?

This is just my opinion, but I would say that using fixed coordinates and sizes is not inappropriate, and that you shouldn't size or position things based on the screen dimensions unless you have particular reasons for doing so. If you have reasons you want to do everything based on screen size, then sure, do so. Just be aware that you don't have to do it that way.

11 hours ago, Zakwayda said:

If you have reasons you want to do everything based on screen size, then sure, do so. Just be aware that you don't have to do it that way.

My goal is to fix the game field in some position, so that when the screen size is changed, it only expanded/shrinked, but did not go anywhere else. How should I process this? Maybe I will use fixed coordinates indeed, but when it comes to transforming, those coordinates would be transformed with respect to the screen size?

3 hours ago, master_clown said:

My goal is to fix the game field in some position, so that when the screen size is changed, it only expanded/shrinked, but did not go anywhere else. How should I process this? Maybe I will use fixed coordinates indeed, but when it comes to transforming, those coordinates would be transformed with respect to the screen size?

Sorry if I'm being slow to catch on here, but are you saying that if the user expands the window you want them to see more of the game world, and if the user shrinks the window you want them to see less of the game world? Or do you want it so that if the user expands/shrinks the window, they see roughly the same amount of the game world, but everything gets bigger/smaller?

1 hour ago, Zakwayda said:

Sorry if I'm being slow to catch on here, but are you saying that if the user expands the window you want them to see more of the game world, and if the user shrinks the window you want them to see less of the game world? Or do you want it so that if the user expands/shrinks the window, they see roughly the same amount of the game world, but everything gets bigger/smaller?

The latter. For now there's no need to spend time on this question, until I experiment it myself. Probably, ortho projection solves everything