Mike
@mike.q5games.com
Aspiring solo game developer. I will some day actually finish and publish a game!
Primarily a coder, some design skills, absolutely no art skills.
Primarily a coder, some design skills, absolutely no art skills.
I would use strings if they are easier for you.
But I think standard is usually a unique int for the ID and a string called Name which isn't necessarily unique. That's useful for a "findChild("Text")" kind of situation, when all your buttons have a child object called Text.
But I think standard is usually a unique int for the ID and a string called Name which isn't necessarily unique. That's useful for a "findChild("Text")" kind of situation, when all your buttons have a child object called Text.
January 2, 2025 at 6:27 AM
I would use strings if they are easier for you.
But I think standard is usually a unique int for the ID and a string called Name which isn't necessarily unique. That's useful for a "findChild("Text")" kind of situation, when all your buttons have a child object called Text.
But I think standard is usually a unique int for the ID and a string called Name which isn't necessarily unique. That's useful for a "findChild("Text")" kind of situation, when all your buttons have a child object called Text.
Been there! Hope you all feel better soon!
December 9, 2024 at 12:19 AM
Been there! Hope you all feel better soon!
Oh, that's actually working okay. Both (0,0) and (32,32) are on the (1,1) plane, so both result in zero distance from the plane. However they will map to different draw points on the screen (I assume you use y + z), so not an overlap.
Try something different, like (64,32).
Try something different, like (64,32).
December 2, 2024 at 3:33 AM
Oh, that's actually working okay. Both (0,0) and (32,32) are on the (1,1) plane, so both result in zero distance from the plane. However they will map to different draw points on the screen (I assume you use y + z), so not an overlap.
Try something different, like (64,32).
Try something different, like (64,32).
Then your objects are overlapping each other, and you need to figure out what that means for the game. I would check for that separately from my draw loop and prevent it from happening unless one object is a pickup or similar (in which case I would draw the pickup above the character).
December 1, 2024 at 4:35 PM
Then your objects are overlapping each other, and you need to figure out what that means for the game. I would check for that separately from my draw loop and prevent it from happening unless one object is a pickup or similar (in which case I would draw the pickup above the character).
Oh, yes, both y and z matter. In the formulas I gave, the vector quantities are written (y,z).
November 27, 2024 at 5:34 PM
Oh, yes, both y and z matter. In the formulas I gave, the vector quantities are written (y,z).
If you want to turn the camera a little to get a more 3d look (like showing the sides of buildings), then you are in for a world of hurt graphics-wise and should probably just use a 3d game engine.
November 27, 2024 at 4:16 PM
If you want to turn the camera a little to get a more 3d look (like showing the sides of buildings), then you are in for a world of hurt graphics-wise and should probably just use a 3d game engine.
I'm assuming you don't allow platforms to intersect each other in game world coordinates. If you do, then you'll need to decide what that means for drawing. Otherwise, their game x and the camera x are the same, so if they don't overlap in game they don't overlap on screen.
November 27, 2024 at 4:14 PM
I'm assuming you don't allow platforms to intersect each other in game world coordinates. If you do, then you'll need to decide what that means for drawing. Otherwise, their game x and the camera x are the same, so if they don't overlap in game they don't overlap on screen.
Do you mean x? You need to consider it for collisions, but you don't need to do any special math there - if any x point overlaps, then you can run the math on just the y and z.
When drawing platforms, ignore x in the ordering - just draw everything in the bottom back first, for example.
When drawing platforms, ignore x in the ordering - just draw everything in the bottom back first, for example.
November 27, 2024 at 4:12 PM
Do you mean x? You need to consider it for collisions, but you don't need to do any special math there - if any x point overlaps, then you can run the math on just the y and z.
When drawing platforms, ignore x in the ordering - just draw everything in the bottom back first, for example.
When drawing platforms, ignore x in the ordering - just draw everything in the bottom back first, for example.
Sorry one point of clarity if your z's go negative - we are looking for the "farthest forward" object (where forward means go into the screen / up when you draw it, in my example positive z) instead of "farthest away" - but if you just don't worry about negative z's it will work out anyway.
November 26, 2024 at 8:00 PM
Sorry one point of clarity if your z's go negative - we are looking for the "farthest forward" object (where forward means go into the screen / up when you draw it, in my example positive z) instead of "farthest away" - but if you just don't worry about negative z's it will work out anyway.
That is, starting at the lowest y, draw the farthest z first, then move forward in z. Once you're done, move up in y. The challenge is to figure out when to insert the character (or other special world items) in that process.
November 26, 2024 at 7:54 PM
That is, starting at the lowest y, draw the farthest z first, then move forward in z. Once you're done, move up in y. The challenge is to figure out when to insert the character (or other special world items) in that process.
Note that I wouldn't bother with collision checking your platforms, because if you build your world carefully enough (use the same height for each platform, build tall ones out of many platforms) you can just draw them in the right order mechanically.
November 26, 2024 at 7:51 PM
Note that I wouldn't bother with collision checking your platforms, because if you build your world carefully enough (use the same height for each platform, build tall ones out of many platforms) you can just draw them in the right order mechanically.
You might end up with negative z values, but that's still okay - the smaller one (more negative) is still in front of the larger one (less negative), so no logic change to the program.
November 26, 2024 at 7:50 PM
You might end up with negative z values, but that's still okay - the smaller one (more negative) is still in front of the larger one (less negative), so no logic change to the program.
There shouldn't be a problem with that scenario - if two sprites don't overlap you don't do any check at all (it doesn't actually matter which you draw first because the output will be the same). And a collision off screen is fine, just do the computation at the point they would collide.
November 26, 2024 at 7:48 PM
There shouldn't be a problem with that scenario - if two sprites don't overlap you don't do any check at all (it doesn't actually matter which you draw first because the output will be the same). And a collision off screen is fine, just do the computation at the point they would collide.
One quick thing that you might notice - the character's waist is technically closer to the camera than the character's leg. This makes sense because the camera is tilted down, but we draw the character straight up on the screen. This difference is where that "leaning back" look of 2.5d is from.
November 26, 2024 at 6:16 PM
One quick thing that you might notice - the character's waist is technically closer to the camera than the character's leg. This makes sense because the camera is tilted down, but we draw the character straight up on the screen. This difference is where that "leaning back" look of 2.5d is from.
And we can run the same math for the intersection between the top of the box at (80,60) and the leg of the character at (65,90).
Which gives us vectors of (-8,16) for the box and (-23,46) for the character. So we would draw the character before the box.
Which gives us vectors of (-8,16) for the box and (-23,46) for the character. So we would draw the character before the box.
November 26, 2024 at 6:14 PM
And we can run the same math for the intersection between the top of the box at (80,60) and the leg of the character at (65,90).
Which gives us vectors of (-8,16) for the box and (-23,46) for the character. So we would draw the character before the box.
Which gives us vectors of (-8,16) for the box and (-23,46) for the character. So we would draw the character before the box.
Since both vectors are multiples of the perpendicular vector (-1,2), it suffices to just compare the z coordinates, telling us that the character is closer to the camera than the platform.
Which means we would draw the platform *before* we draw the character.
Which means we would draw the platform *before* we draw the character.
November 26, 2024 at 6:12 PM
Since both vectors are multiples of the perpendicular vector (-1,2), it suffices to just compare the z coordinates, telling us that the character is closer to the camera than the platform.
Which means we would draw the platform *before* we draw the character.
Which means we would draw the platform *before* we draw the character.
And the character gives:
(75,90) - (75 * 2 + 90 * 1) / (2*2+1*1)*(2,1) = (-21,42)
(75,90) - (75 * 2 + 90 * 1) / (2*2+1*1)*(2,1) = (-21,42)
November 26, 2024 at 6:11 PM
And the character gives:
(75,90) - (75 * 2 + 90 * 1) / (2*2+1*1)*(2,1) = (-21,42)
(75,90) - (75 * 2 + 90 * 1) / (2*2+1*1)*(2,1) = (-21,42)
And that's where we run the formula from before (remembering our camera plane is (2,1)):
u - (u dot v)/(v dot v)*v
For the platform that's:
(60,120) - (60 * 2 + 120 * 1) / (2*2+1*1)*(2,1) = (-36,72)
u - (u dot v)/(v dot v)*v
For the platform that's:
(60,120) - (60 * 2 + 120 * 1) / (2*2+1*1)*(2,1) = (-36,72)
November 26, 2024 at 6:11 PM
And that's where we run the formula from before (remembering our camera plane is (2,1)):
u - (u dot v)/(v dot v)*v
For the platform that's:
(60,120) - (60 * 2 + 120 * 1) / (2*2+1*1)*(2,1) = (-36,72)
u - (u dot v)/(v dot v)*v
For the platform that's:
(60,120) - (60 * 2 + 120 * 1) / (2*2+1*1)*(2,1) = (-36,72)
We already know how big the platform is: 20 high, 120 deep, so we can just add those to its world position (40,0) to get the top of the sprite: (60,120).
Character is also easy, just the world position (60,90) + up 15, to give us: (75,90).
So which of those two points is closer to the camera?
Character is also easy, just the world position (60,90) + up 15, to give us: (75,90).
So which of those two points is closer to the camera?
November 26, 2024 at 6:03 PM
We already know how big the platform is: 20 high, 120 deep, so we can just add those to its world position (40,0) to get the top of the sprite: (60,120).
Character is also easy, just the world position (60,90) + up 15, to give us: (75,90).
So which of those two points is closer to the camera?
Character is also easy, just the world position (60,90) + up 15, to give us: (75,90).
So which of those two points is closer to the camera?
Lets start with purple, and get the world position of each object at that intersection.
This happens at the top of the platform, which means it's at y = 120. Which tells us it is 15 up on the character (the character bottom is at 105).
This happens at the top of the platform, which means it's at y = 120. Which tells us it is 15 up on the character (the character bottom is at 105).
November 26, 2024 at 6:01 PM
Lets start with purple, and get the world position of each object at that intersection.
This happens at the top of the platform, which means it's at y = 120. Which tells us it is 15 up on the character (the character bottom is at 105).
This happens at the top of the platform, which means it's at y = 120. Which tells us it is 15 up on the character (the character bottom is at 105).