Hi there.
I’m currently trying to teach myself the Heaps framework. I’ve just about got my head around gamepad input and loading a tilemap. The thing I’m currently struggling with is scrolling the tilemap. I can see examples of how to move the camera around in a 3d scene ( s3d.camera.pos.set ) but I can’t seem to see anything about moving the camera in a 2d scene.
If someone could point me at a bit of example code or API documentation that’d be awesome.
Regards,
Patrick.
Hello! Camera in 2d scene could be implemented as an container for all objects on scene. When you move object which camera should follow, then you could move this container on scene in opposite direction (if char is moving left then camera should move right, etc.)
Here is most basic example of such 2d-camera in heaps: https://github.com/Beeblerox/Simplest-Heaps-Examples/tree/master/13_heaps_camera_scroll
There are plenty room to improve. For example, you’d like to add camera scrolling bounds, but this should give you basic idea
Hello,
Is the container a notion of Heaps, or just a matter of saying that the scene object should inherites the camera position ? I haven’t found «container» in Heaps API.
Thank you.
By Container i mean h2d.Sprite (or h2d.Object in new version) class, which can be a parent to another Drawable objects on the scene. Of course, you can use any other type of object with such functionality.
In my example Camera class inherits from h2d.Sprite. And all objects, which should scroll with camera movement are added to Camera as its children.
Thank you for that. That was immensely helpful. I’ve managed to adapt the Camera class from your example and I’m now getting the scrolling I’m after.
What is your opinion on using this to achieve a parallax scrolling effect? I’ve managed to achieve this by instantiating two cameras and giving them different movement speeds. This has given me the effect I was after. Just wondered if this was considered the “correct” way of doing it.
i guess this could be considered as “correct” way 
But to be 100% sure about it, i need to know if there are any other requirements for the camera system?
Size of the levels, for example, is one of the defining factors.
Game genre is also might be important. For example, my solution isn’t optimized for infinite runners at all (they usually process and render only part of the world in a different way).
The game itself is a platformer similar in style to something like Shinobi 3 on the Mega Drive. So fixed size levels. Probably each “scene” won’t be that large. Maybe up to 10 screens worth of scrolling before we’d load a new scene.
I’ve just been doing some experiments with detecting collisions between the player and the tilemap that I have loaded. What I’ve done is load a bounds object for every tile into an array when the level first starts. Then each frame I’m comparing the player bounds against each tile bounds. This is now allowing me to see which tiles the player is in contact with. Although it doesn’t feel particularly efficient it seems to be working. How would you approach collision detection in a 2d tilemap based game? Is there a “correct” way?
your way is very straightforward, but can be very perfomance intensive in cases of big levels.
i know couple of ways to optimize it a bit.
for example in case of tilemaps from flixel engine they don’t check againist every tile in tilemap, checks are being made only for those tiles which are in the viscinity of object they could collide with. This optimization is possible due to the fact that tiles in tilemap are placed in grid order (with the step equal to tile size), so you can easily find out which tiles to check againist.
the second way might be to divide your level in several separate tilemaps with the size of the game screen, so then you could check collision againist only those tilemaps that are displayed on screen. Plus you could make invisible (or remove from the scene completely) those tilemap chunks which are not visible on screen. This way you could save up some perfomance on rendering (but i’m not sure about it, this should be tested).
But there is no one universal “right” way to do platformer, every game could achieve its results in different ways, some of them could even ignore any optimization (due to small game world, or other factors). First, you should assemble a prototype of the game level and see how it performs, what are the most critical places which need to be optimized, and only then think how you could do it. Maybe you won’t need to use those optimizations at all 
Thanks for the advice again. I’m currently building a prototype like you described. Spent most of yesterday evening trying to get collision detection with the floor working properly. Was a lot harder than I was anticipating. Starting to understand why a lot of people just throw everything in a physics engine and let that sort it out.