i am new on cocos2d, I have
int score;//default 0
I am increasing the score but when switch scene, score is going to be 0 again.
How can i keep the score when i switch the scene?
Sorry for my bad english.
Best Regards. Thanks for your advice.
You are storing a score in a scene - perhaps this would be better stored in a single location that all of your scenes can access? After all, your scene should be concerning itself with managing your views and user interaction rather than game logic.
There are many approaches for this: will there only be one game happening at once? If so, perhaps a singleton would be a good way to manage this data.
If not, you will need a reference to the score in each scene (that is to say, each scene would need a public variable that the previous scene can transfer the score value to before presenting).
NSUserDefaults is a good way to store simple global data, especially if you want to persist it across application launches.
Related
I need a similar asset changed on the screen with the same size, so, the best practice would be to change the texture of the sprite or make a new sprite and release the previous one? I see no difference on performance by now on my poker game I am making but I would like to know that maybe in the future implementing it on android would be a problem on performance, and so about the best practice on coding I don't see a mention of it on the documentation of cocos2d-x neither on the web. I really would like to know better what exactly goes on on both of the cases.
I would create a new Sprite each time.
I don't really think there will be any performance issues.
You could test the performance yourself on your desired target platform/s by doing a texture swap on a bunch of Sprites (100 or 1000 sprites) and then repeat the test with the same amounts of Sprite but creating them and releasing them.
I'm creating a game similar to this and I'm attemptin to figure out how to generate randomly sized enemy fishes. As far as I can tell, the sprites you create in SDL take on the size of the image you give them, but what I want to do is be able to specify a size for my image when the fish is created dynamically using random values for its size.
My assignment uses SDL and a framework given to us, so I can't import any fancy libraries.
Can anyone point me in the right direction with this?
What you are looking for is called scaling. You can check this tutorial to easily add the feature to your game. The suggested rotozoom can be found in SDL_gfx, available here.
If you are going this route and decided to write your own code for learning purpose, just keep in mind that manually scaling a SDL_Surface is expensive, so you should probably do it only when you're spawning the fish and store the surface for the lifetime of the fish.
Another option would be to make a 2D game using 3D graphics; basically you just stretch the triangles any way you want and the texture will adjust itself to fill it.
I just started using Cocos2D this week. While playing around with Box2d i was wondering if it was possible to move CCSprites with the help of CCActions and use box2ds collisiion detection feature to detect collision between those sprites..
I'm pretty sure this must be possible?
If you don't need real physics behavior, I'd highly recommend to "manually" deal with your collision logic. That said, for your scenario I would start with this approach.-
Create one body per sprite, and assign each sprite to the user data.
Your 'static' scenario would map to static bodies (i.e floor, platforms, etc...)
Your 'dynamic' sprites would map to dynamic bodies, which only fixture would be marked as sensor
You'd register a b2ContactListener to listen for the collisions.
As for the tricky part, you'd need to set in each iteration of the main loop, the position of each body to the position of each sprite (of course, translating pixels to meters), in order to avoid that they just behave as physics bodies. You could try just to not calling world->step, but not sure if contactListener would work then.
Hope it helps!
I am working on a simple 2D openGL project. It contains a main actor you can control with the keyboard arrows. I got that to work okay. What I am wanting is something that can help explain how to make another actor object follow the main actor. Maybe a tutorial on openGL. The three main things I need to learn are the actor following, collision detection, and some kind of way to create gravity. Any good books or tutorials to help get me in the right direction would be great.
You could use a physics library like Chipmunk Physics, which lets you attach springs and things between the two objects and detect when they hit each other and other things.
A pre-rolled library would be good, but the concepts you describe are ones you need to know if you are going to do any sort of game programming anyways:
A simple way to make one actor follow behind another is to have the lead actor store its position every time it moves. Feed these positions to a trailing actor with a delay of a few values - the longer the delay, the further behind they travel. Simple, but doesn't handle dynamic collision (other actors moving the block collision.)
Collision detection in 2D can simply be axis aligned (AA) bounding boxes. Search for this and you'll see the 4 ifs or so that are needed.
Gravity is just adding a fixed velocity (usually down) to every object every game loop. This is constant acceleration which is exactly how gravity works.
I was curious if anyone had any experience/knowledge about aim bots in online FPS games such as Counter-Strike. I am curious and would like to learn more about how the cursor knows how to lock on to an opposing player. Obviously if I wanted to cheat I could go download some cheats so this is more of a learning thing. What all is involved in it? Do they hook the users mouse/keyboard in order to move the cursor to the correct location? How does the cheat application know where exactly to point the cursor? The cheat app must be able to access data within the game application, how is that accomplished?
EDIT: to sids answer, how do people obtain those known memory locations to grab the data from? EDIT2: Lets say I find some values that I want at location 0xbbbbbbbb using a debug program or some other means. How do I now access and use the data stored at that location within the application since I don't own that memory, the game does. Or do I now have access to it since I have injected into the process and can just copy the memory at that address using memcpy or something?
Anyone else have anything to add? Trying to learn as much about this as possible!
Somewhere in the game memory is the X,Y, and Z location of each player. The game needs to know this information so it knows where to render the player's model and so forth (although you can limit how much the game client can know by only sending it player information for players in view).
An aimbot can scan known memory locations for this information and read it out, giving it access to two positions--the player's and the enemies. Subtracting the two positions (as vectors) gives the vector between the two and it's simple from there to calculate the angle from the player's current look vector to the desired angle vector.
By sending input directly to the game (this is trivial) and fine-tuning with some constants you can get it to aim automatically pretty quickly. The hardest part of the process is nailing down where the positions are stored in memory and adjusting for any dynamic data structure moving players around on you (such as frustum culling).
Note that these are harder to write when address randomization is used, although not impossible.
Edit: If you're wondering how a program can access other programs memory, the typical way to do it is through DLL injection.
Edit: Since this is still getting some hits there are more ways that aimbots work that are more popular now; namely overwriting (or patching in-place) the Direct3D or OpenGL DLL and examining the functions calls to draw geometry and inserting your own geometry (for things like wall-hacks) or getting the positions of the models for an aimbot.
Interesting question - not exactly your answer but I remember in the early days of Counter-Strike people used to replace their opengl32.dll with a botched one that would render polygons as transparent so they could see through the walls.
The hacks improved and got more annoying, and people got more creative. Now Valve/Steam seems to do a good job of removing them. Just a bit of warning if you're planning on playing with this stuff, Steam does scan for 'hacks' and if any are found, they'll ban you permanently
A lot of "Aim bots" aren't aim bots at all but trigger bots. They're background processes that wait until your reticule is actually over a target and fire automatically. This can be accomplished in a number of different ways but a lot of games make it easy by displaying the name of someone whenever your target goes over them or some other piece of data in memory that a trigger bot can pin point.
This way, you play by waving the mouse at your target and as soon as you mouse over them it will trigger a shot without your having to actually fire yourself.
They still have to be able to pinpoint that sort of stuff in memory and have the same sort of issues that truer "Aim bots" do.
Another method that has been used in the past is to reverse engineer the network packet formatting. A man-in-the-middle attack on the packet stream (which can be done on the same system the game runs on) can provide player positions and other useful related information. Forged packets can be sent to the server to move the player, shoot, or do all kinds of things depending on the game.
Check out the tutorial series by Fleep here. His fully commented C# source code can be downloaded here.
In a nutshell:
Find your player's x y z coordinates, cursor x y coordinates as well as all enemies x y z coordinates. Calculate the distance between you and the nearest enemy. You are now able to calculate the x y cursor coordinates needed in order to get auto aim.
Alternatively you can exclude enemies who are dead (health is 0) so in this case you also need to find the enemy's health address. Player-related data is usually close to each other in memory.
Again, check out the source code to see in detail how all of this works.
Edit: I know this offtopic, sorry But i thought this would help out the asker.
The thing the hacking industry haven't tried out, but which I've been experimenting with, is socket hijacking. It may sound a lot more than it actually is, but basically it uses the WinPCap drivers to hook into the process' Internet connections via TCP (Sockets), without even going near the process' offsets.
Then you will simply have to learn the way the TCP Signals are being transferred and store them into a hash-Table or a Multiplayer (Packet) class. Then after retrieving the information and overlay the information over the Window (not hooked), just transparent labels and 2D boxes over the screen of the windowed game.
I've been testing it on Call of Duty 4 and I have gotten the locations of 4 players via TCP, but also as Ron Warholic has said: all of the hacking methods won't work if a game developer wrote a game server to only output the players when the current user should see the player.
And after cut the transmission of that player's location as for the X Y Z and player will no longer be stored and not rendered there for stop the wallhack. And aimbots will in a way stall work but not efficiently. So anyway, if you are looking into making a wallhack, don't hook into the process, try to learn WinPCap and hook into the Internet signals. As for games, don't search for processes listing for Internet transmissions. If you need an example that utilizes this, go search Rust Radar that outputs the player's location on a map and also outputs other players around you that is being sent via Internet transmissions TCP and is not being hooked into the game.