Uhfgood Posted August 16, 2014 Share Posted August 16, 2014 Okay so, it looks like having my ship and asteroids go offscreen for a few seconds is a little disruptive to the gameplay in my asteroids game. I'm going to have to employ clones of my player and all of the active asteroids. I have a few questions regarding groups and so forth. 1) Can I substitute a group for a sprite, and then still have all the abilities that I do with the sprite? For instance moving them at the same time, and stuff like velocity and acceleration (and rotation more on that in a sec) 2) with regards to rotation, my sprite rotates around it's access because it's an asteroids game, now if I made a group of player sprites, if I set rotation on the group, what happens? Either they all spin according to some anchor, or each sprite in the group rotates or, nothing because maybe rotation doesn't work on groups at all? 3) What about memory and processor time? I can have up to 60 asteroids (if they're all small) on screen at once... now if perchance all 60 of them hit the corners, then that's 4 asteroid sprites for each asteroid on screen, which makes it 240 sprites -- would this take up too much memory, and would it be too processor intensive? This is the worst-case scenerio because there's probably no way each and every of the 60 little asteroids are going to hit the corners all at the same time. I might have some other questions soon, but can anyone clue me in? Thanks Keith Here is the game in question - https://dl.dropboxusercontent.com/u/32895233/sroids/index.html Link to comment Share on other sites More sharing options...
lewster32 Posted August 16, 2014 Share Posted August 16, 2014 1) No - a group has scale, rotation, x and y - you can't apply a body to it, so you don't get velocity. 2) The group rotates around its 0, 0 point by default (this can be changed with the pivot.x and pivot.y properties) and all sprites added to it will move around that point just as you'd expect. 3) Memory isn't usually a concern unless you have thousands and thousands of sprites. Assets are what eat up memory - sprites are just data. Lots of sprites will however use the CPU, and not just when colliding - every time you check for collisions the engine runs a series of routines to check whether a sprite can collide with its neighbours (at worst, each sprite checking every other sprite to see if it intersects, at best using a QuadTree to determine nearby sprites) and that's more intensive than the actual separation routine which is applied if objects are seen to be intersecting. It's hard to say but the examples show hundreds of sprites colliding pretty efficiently, so I think you'll be okay. Link to comment Share on other sites More sharing options...
Recommended Posts