I am working on a tilemap based game in cocos2d in which the player moves in four directions and I have used four images for the movement of player for example left,right,top and down. My problem is that when my background map change its position or move to other position then my sprite does not change its position. Can anyone tell me how to move a sprite with the movement of background.
Use a CCNode to contain both the background and the sprites for your players. Instead of moving the background, move that node.
There are a couple of ways to handle tilemap based games, and neither of them are very convenient. One way is to leave your character in the center of the screen at all times and move the background underneath it. If your character moves 'right', you simply slide the background to the left, and vice versa. This will give the illusion that the character moves around the map, when in reality it remains centered. Under this paradigm you must remember to convert all detection / collisions into the world's space, and not just the screen space. If you don't convert everything, then your 'range' of collision / detection is limited to the size of the screen.
The second method is to pan the camera over the world. You still keep the character in the middle of the screen, but it actually moves around in the world, and the camera follows. This makes the most intuitive sense to me because it allows you to view the game world as you see the real world. It is also much easier to deal with collisions because the position of the character and the world 'just work' and don't have to be converted. The downside here is that Cocos2D doesn't make it easy to use CCCamera, and the documentation is a little thin in that respect.
In your particular case, it sounds like you have a CCLayer problem. If your character is inside the layer you are moving, it will indeed remain in the same place relative to the map (as you are describing). Instead, float the character in a different layer on top of the map.
You could use a scrolling Parallex and then add the sprite onto the same layer as the background. They will move together.
Related
I am just a beginner in game developing. Right now I am developing a game using Apple's Sprite kit and found out that the best way to position nodes on the scene is to provide percentages of width and height of the window boundaries as it makes sure all the nodes maintain their positions almost regardless of change in device display size. Using pixels to position nodes is not a peculiar idea as with the change in device display size of iPhone, nodes are either cut off or the scene squeezes leaving empty space around the scene boundary. I have watched how Apple recommend using scene editor but my issue is, using scene editor it allows you to position nodes by choosing pixels and not relative to to scene width or height. Am I making a mistake in understanding the scene editor capability. If I position all my nodes using scene editor as its saves a lot of time, how can I avoid problem with different iPhone sizes. I appreciate your help.
This is an age old problem, from all media formats.
You must decide, personally, what your favourite and most desirable target device is, and then make choices best for both it, and your creative process.
After making that decision you'll have to make your own decisions on how compromised you become on other devices, or how much you compromise your creative and production processes to benefit other device sizes and aspect ratios.
It's a balancing act.
And I strongly suggest favouring your favourite device and putting off all consideration of adaptation to other devices until after you've made something great.
Others will disagree.
Suppose there there is a scene as follows:
There is a scene with the same size as the frame of the device. The scene has a red ball, which is able to move throughout the 'world'. This world is defined by black and white areas, where the ball is ONLY able to move in the area that is white. Here is a picture to help explain:
Parts of the black area can be erased, as if the user is drawing with white color over the scene. This would mean that the area in which the ball can be moved is constantly changing. Now, how would one go about implementing a physicsBody for the an edge between the white and black areas?
I tried redefining the physicsBody every time it is changed, but once the shape becomes complex enough, this isn't a viable solution at all. I tried creating a two-dimensional array of 'boxes' that are invisible and specify whether most of the area within each box is white or black, and if the ball touched a box that was black, it would be pushed back. However, this required heavy rendering and iterating over the array too much. Since my original array contained boxes a little bigger than a pixel, I tried making these boxes bigger to smooth the motion a little, but this eventually caused part of the ball to be stopped by white areas and appear to be inside the black area. This was undesired, since the user could feel invisible barriers that they seemed to be hitting.
I tried searching for other methods to implement this 'destructible terrain' type scene, but the solutions that I found and tried were using other game engines. To further clarify, I am using Objective-C and Apple's SpriteKit framework; and I am not looking for a detailed class full of code, but rather some pseudo-code or implementation ideas that would lead me to a solution.
Thank you.
If your deployment target is iOS 8, this may be what you're looking for...
+ bodyWithTexture:alphaThreshold:size:
Here's a description from Apple's documentation
Creates a physics body from the contents of a texture. Only texels
that exceed a certain transparency value are included in the physics
body.
where a texel is a texture element. You will need to convert an image to the texture before creating the SKPhysicsBody.
I'm not sure if it will allow for a hole in the middle like your drawing. If not, I suspect you can connect two physics bodies, a left half and a right half, to form the hole.
I want to make a game in which sprites fall from the sky and stack up on the floor, however when there is a lot of layers the camera will move up so you can continue playing. After a while more and more rows of sprites will become invisible as the camera moves up. I want to delete these unused sprite-nodes to keep the performance as good as possible. But when I delete the nodes at the bottom of the stack, won't the entire thing collapse? Or should I detect when the bottom row is unused and then turn off physics for the row above it so it wont fall down and won't affect the rows above it or something of that nature.
I haven't actually made any code yet, I just wanna have a good idea of what I'm doing before I start the wrong way.
Yeah I totally agree, you would really have to be clever about it. Well setting the background image coordinates and looping the background for a "continuous scroll effect" would be Step NO.1 Then using particle physics or actually rendering Nodes would be Step NO.2 The tricky part like you said would be getting the ones below the scene to be destroyed, but I think that if you try and set boundaries, and maybe an if statement that runs the destruction of the particles below the boundaries. So the particles fall down slowly pile up but as the scene scrolls upwards the particles will be destroyed when the their anchor point goes below the x,y boundaries you set and thus keeping those still visible in the scene alive... That would be my way of going about it.
I got a tiled map and I want to make lava lakes. I wish to have some kind of lava texture image on the background looping diagonally slowly. I could make it with four 960x640 images and move all of them diagonally etc. But when I do, a black/white line appears between each...
... and someone suggested me "CCParallax". I have never used it and am not sure if it really can achieve the effect I am seeking.
Also note that as the player moves on the map, the parallax will need to simulate that as well etc.
So my question is, what would you do for this effect? Four looping images or "CCParallax"?
CCParallaxNode is pretty limited because you can't specify endless parallax scrolling without modifying the class. It also doesn't quite fit your use case.
Using four 960x640 images is wasteful. Just to make some lakes underneath the background this is overkill and will negatively affect performance.
The solution depends a bit on how big the lakes are. For example, if these are just 1 or 3x3 tiles in size you could add a textured sprite underneath each lake. If on the other hand your tilemap consists mostly of a few narrow pathways while the rest is lava lakes, then you need a different approach.
You might want to try GL_REPEAT to repeat a single sprite's texture over a defined area. That allows you to use a relatively small texture, for example 64x64, that will be repeated over the rectangle you specified.
You can then modify the sprite's position each frame to scroll the texture. Every time the sprite has moved 64 pixels in horizontal or vertical direction, you subtract 64 pixels (sprite.contentSize.width) from the sprite's position to reset it back to its original state. That means the sprite will never move further than 64 pixels from its initial position in any direction but you still get smooth scrolling.
For a university term project, I'm working on a graphical roguelike (I'm aware of the contradiction in terms :P) that uses an isometric display. What I'm trying to figure out is, since drawing all the tiles is stupidly expensive and unnecessary, I'm wanting to figure out a relatively fast algorithm to determine which tiles should be drawn to fit within an NxMpx window, given that the tile graphics are XxYpx.
I'm not doing smooth scrolling for this, so that's not an issue. I'm also not worried about being perfect - a little unnecessary draw is fine, I just don't want to draw a huge amount of unnecessary tiles that won't show up in-game.
You need to think about two concepts: Screen space and world space. These are very important in 3d engines, but they apply to all but the very simplest games. In the isometric engine your world-space is a 2d array of tiles.
So you are looking first of all at a way to covert between these two co-ordinate spaces. Once you've done that, it'll be obvious that screen space maps onto the world as a rectange that's turned at 45 degrees. You can determine a formula for that, but it's only important if you are trying to determine which part of the world space is visible so you only simulate monsters in that area (an efficiency necessary on 8 bit consoles, probably not on a modern PC!). When it comes to actual rendering you don't really need to determine this visible region of the world, because it's implicit in the way you render the tiles onto the screen:-
You work out which tile location is at the top-left of the screen, call this O (for origin) - that's going to be a fixed offset from your point of interest, usually the player, that you want to keep in the centre of the screen.
Once you have that you paint the tiles in the top row of the screen, stepping +1X and -1Y in world space for each tile (if you are looking north-east).
Then you paint the row below. That is offset minus one half a tile width in screen space and starts at O -1X in world space.
You repeat steps 2 and 3, modifying your starting position in world space by -1 in X and Y from what you used in the previous stage 2 until you reach the top of the screen.
Other tips:-
Obviously you don't draw any tiles that are outside the map. You might also, depending on game design, not draw any tiles outside a particular room the player is in.
There's not just floor tiles to draw, theres also players, monsters, scenary, etc. The rule is you draw everything in a paricular world location in the same pass. That way objects closest to the 'camera' will obscure stuff behind them (which is why you start drawing at the top of the screen).
Also, you don't just have floor tiles in most iso engines, you would also have furniture and wall segments. You might designate areas of the map as belonging to a particular room, when the focus is on that room (because the player is in it for example), you don't draw the wall segments for the side of the room closest to the camera.
Anyway, that's enough to be getting on with, hope it's helpful and your project goes well.