Hi,
While Im only on chapter 4 so far my ultimate goal is to make a 2d side scrolling platformer, the current game that utilizes tilemap seems more of a top down Zelda type game. Will this give us the knowledge to translate into a 2d platformer?
@michaelangelo716 - If your 2d platformer uses tile maps, then yes it should. Instead of filling out the whole tile map, you will only fill out some of it and let the background (or tile maps further back if you are using parallax scrolling) show through.
You’ll be able to use the scrolling background concept from Zombie Conga to scroll the tile map nodes.
You’ll also learn how to use tile maps to put down obstacles and objects to pick up.
I hope you enjoy the book :].
1 Like
Hi @caroline,
I am very much enjoying this book so far! Ok I will definitely wait until I finish that chapter before with tile maps before I start exploring. However the zombie conga hasnt implemented the background scrolling yet, perhaps thats yet to come. Right now we are implementing the win/loss scenes.
Thanks for your feedback
page 126 “A scrolling background”
1 Like
Yes! thank you I had just not gotten there yet!
May I ask one more question?
Chapter 5 challenge asks us as a bonus to fix the speed increase that is seen in the enemy. I have a different working solution than the challenge solution. Well as far as I can tell it works great. Can anyone verify both are acceptable or the solution is better because x?
My Solution
let actionMove = SKAction.move(to:
CGPoint(x: cameraRect.minX,
y: enemy.position.y),
duration: 2.0)
Book Solution
let actionMove =
SKAction.moveBy(x: -(size.width + enemy.size.width), y: 0, duration: 2.0)
That’s correct, almost. Instead of cameraRect.minX for the x-position to move to, you want cameraRect.minX - enemy.size.width/2. That way the enemy will go completely offscreen. The move-to approach and move-by approach are two ways of achieving the same effect, and both are acceptable.
If you want to work out the maths of it, you can verify that the enemy will end up in the same spot by subtracting the move-by amount from the starting x-position. There are a lot of variables here, but breaking down cameraRect, you get:
(cameraNode.position.x - size.width/2 + (size.width - playableRect.width)/2 + playableRect.width + enemy.size.width/2) - (size.width + enemy.size.width)
which simplifies to:
cameraNode.position.x + playableRect.width/2 - size.width - enemy.size.width/2
Swapping size.width with playableRect.width, which are the same thing, you get:
cameraNode.position.x - playableRect.width/2 - enemy.size.width/2
which is the same as:
cameraRect.minX - enemy.size.width/2
That was more math than I expected! But it checks out, assuming I didn’t make a mistake.
Depending on the game you are making, sometimes it may make more sense to use a move-by action over a move-to, or vice-versa. For example, if you had enemies spawn with a random x-position as well and always wanted them to run to the same spot, it would be easier to use a move-to. But if you always want enemies to move the same distance no matter where they start from, you’d probably use a move-by.
Or if one just makes more sense to you math-wise, that might be the way to go.
Actually, given that the camera is moving and it takes a bit of time for the old lady to get across the screen, cameraRect.minX probably works fine to get her all the way to the other side.
But if you want her to move the same speed as with the Book Solution, you should use cameraRect.minX - enemy.size.width/2.