I am making a game using cocos2d and box2d that basically consists of a ball rolling down an infinite hill. My current approach consists of using CCFollow to create the scrolling effect, while iterating through a series of four background images to create continuity. I want the ball to bounce of the hill, so I considered making the hill from two b2Body objects that alternate one another. But this requires manually moving the bodies, which seems to make keeping track of the placement of the corresponding sprite somewhat confusing. Should the hill images even be sprites? Is there a better approach that makes this easier?
Related
I'm self learning C++ and playing around 2D tile mapping.
I have been reading through this scrolling post here, which is based on this tiling tutorial.
Using the above tutorial and some help from the Pearson, Computer Graphics with OpenGL book I have written a small program that draws a 40x40 tiled world and a Sprite (also a tile).
In terms of drawing/render order, the map(or world) itself is that back layer and the Sprite is the forward most (or top) layer. I'm assuming that's a good way of doing it as its easier for 2 tiles to interact than a tile and a custom sprite or rectangle. Is that correct?
I have implemented a Keyhandling() function that lets you move the map inside the viewport using the keyboards arrow keys. I have a variable called offsetx, offsety that when a key is pressed increases or decreases. Depending on whether I assign the variable to the map or sprite, I can more one or the other in any direction on the screen.
Neither seems to work very well, so I assigned the variables to both (map and sprite) but with positive values for the sprite, and negative for the map. So upon a key press, this allows my Sprite to move in one direction whilst the map moves in the opposite direction.
My problem is, the sprite soon moves enough to leave the window and not enough to bring the more of the map into the scene. (The window only shows about 1/8th of the tiles at any one time).
I've been thinking all day, and I think an efficient/effective way to solve this issue would be to fix the sprite to the centre of the screen and when a key is pressed the map moves around... I'm unsure how to implement this though.
Would that be a good way? Or is it expected to move the viewport or camera too?
You don't want to move everything relative to the Sprite whenever your character moves. Consider a more complicated world where you also have other things on the map, eg other sprites. It's simplest to keep the map fixed, and move each sprite relative to the map, (if it's a movable sprite). It just doesn't make much sense to move everything in the world whenever your character moves around in the world.
If you want to render your world with your character always at the center, that's perfectly fine. The best thing to do is move the camera. This also allows you to zoom your camera in/out, rotate the camera, etc. with very little hassle in keeping track of all the objects in the world.
Be careful with your usage of the word "viewport". It means a very specific thing in OpenGL. (ie, look at the function glViewport). If your book uses it differently, that's fine. I'm just pointing this out because it's not 100% clear to me what you mean by it.
Im using Level Helper and SpriteHelper to create my sprites, images, levels and more importantly animations and physics.
Note, by physics i mean the debugdraw you can see on the simulator that is used for collision detection.
I created a swimmer and added physics to this. Done the code so the physics follows the swimmer around the pool as they move. I have now come to animate the swimmer, make the legs kick etc. Now when i load my game and only the first sprite of the animation is the outline for the physics. So i can see the legs kicking on the swimmer but the debugdraw mesh of the physics doesn't animate as well. Now this is not really a problem until for example my swimmer loses their legs (weird game i know). I change the animation to now a swimmer with no legs but again the physics mesh still shows the legs. So any collisions with stuff still happens where the legs were but they shouldnt. This make sense?
Is there a way to update the physics on the new animation or do i need to remove my whole swimmer and draw a new one?
Any help at all would be great. Thanks
This makes sense, since your sprite uses the same box2d mesh in both states. If you want to have a different collision behavior after altering your Sprite, you should assign another (smaller) mesh body.
Note that even in cocos2d side, your sprite still has the same container box with the new animation.
In order to keep using the SpriteHelper functionality you might want to create 2 different sprite-body sets: one with the full body, then after the "accident" replace it with the legless sprite.
Now, gameplay-wise, my opinion is that there shouldn't be any collision for the legs anyway. since they are moving, players will not find it weird to have them not colliding. You could use a mesh body with no legs and use it for both sprites. Except if you want to have different collisions as a gameplay feature (Like giving the player the choice to cut his legs in order to fit in a smaller cave etc)
One of the powerups in my game is a vortex that attracts all coins. I know I have any cocos2d's moveto/bezierto methods available, but I don't know how to make them have tangential and radial speed.
The extra difficulty is that the vortex center can change in every step, so all movement has to be readjusted.
One way to achieve this without a physics engine is to use the rotation around point algorithm.
That covers the rotation around the vortex center. Once an object is rotation around the vortex, all you need to do is to reduce that object's distance from the center by a certain amount every frame. That way it will continue to move inwards.
The only tricky part then is to get the object from its initial position being "sucked into" the vortex. There's going to be a lot of tweaking needed. With a physics engine, that part would come natural from the physics itself and it would always look right.
This is not guaranteed for the manual solution and definitely not for actions, which aren't designed to track moving targets. For example, if you change a move action every frame by replacing the existing one with a new one, your object won't move at all. Every time you do that, there's a 1-frame delay before the new action does its work.
I'm new to cocos2d so I am a bit confused by some things:
The term "child" keeps popping up. At
first I thought it was a subclass,
now I perceive to be a sort of
dynamic instance variable? Can
anyone explain this a bit better?
The class CCSpriteBatchNode is some kind of array of CCSprites
which calls a method that renders
the graphical part of its
elements/children from a sprite
sheet. Is my explanation somewhat
correct?
My book (learning cocos 2d a beginners guide) shows a design
setup where the CCSpriteBatchNode
has several objects as children. I'm
a bit confused because I'm used to
separating drawing classes from
logical classes, AKA "Separation of
concerns". Is this something cocos2d
doesn't abide by and we shouldn't
either?
Parent-child is just a relationship between CCNode and their subclasses in cocos2d. For example if you want a moon turning around the moving planet it is really hard to calculate the absolute path of the moon. But you can make it the child of a planet, and in this case its position, rotation and so on, will be relative to the planet's coordinates. So parent-child relationship is just grouping.
CCSpriteBatchNode is a parent to all its children, but the position of its children are relative to CCSpriteBatchNode parent. Such approach is used because BatchNode is rendering all its children at the same time. That is done to increase performance (no texture switching).
Batch rendering is faster. If your logic is good, CCSpriteBatchNode does not make it worse. For example, you can have a character with a body, arms and legs and you want to render it using BatchNode. You just add the body as a child to BatchNode, then add arms and legs as children to the body. Logic is kept, performance is increased.
I have been experimenting with the box2D sample project within cocos2D for the iPhone and am wondering if box2D is the appropriate engine to use to make a moving object "stick" to a stationary object when the moving object is finished moving in a certain direction.
Here is a simplification of what I am trying to achieve: I have MovingObject, a dynamic rigid body, that moves vertically against gravity when enough force is applied to it. As MovingObject moves, it may overlap a static object, StationaryObject. When gravity diminishes MovingObject's velocity to zero such that it is no longer moving, I would like to have MovingObject remain where it is ONLY if it overlaps StationaryObject. If the object's do not overlap, MovingObject should start to move back down towards the ground per the force of gravity. During that descent, if MovingObject at any time overlaps StationaryObject, it should stop its descent and remain in that location as if it is stuck on StationaryObject.
I am able to get MovingObject to move per the forces I am applying to it, but not really sure how to make it stop and stay there once it reaches the top of its ascent, assuming it is overlapping StationaryObject.
Currently, I am experimenting with simple square/box objects but eventually both MovingObject StationaryObject will be defined as very different complex polygon shapes.
Thanks in advance for any insights and/or suggestions for achieving this.
Sounds like you'll want to change the type of fixture used for "MovingObject" while it "ascending" and then change it when it is "descending" so that it reacts differently (to overlaps).
by "overlap" it sounds like you want to achieve something similar to "one sided platforms" in a platform game (ie; Mario Bros.) - I would recommend looking into the solutions for one-sided platforms for starters.