   2D animated levels
  I've made a lot of little 2D games - scrolling shooters, worms clones and the like.  Mostly I have a static level with moving enemies, and a moving platform or two.  But I'd like to start adding the 'crazy' ... and I think having levels that "grow" is exactly the type of thing I'd love to add.  There are a few games around that do it, however PixelJunk Eden for then PS3 really shows it off nicely.  Check it out for an idea of what I'm on about:">Now I don't really want to copy their gameplay, or even art style but the idea of levels that grown and change sounds really interesting.  I just can't think of a good way to implement it.  To me it looks like they're using vector graphics, but I don't think the iphone really has the power to handle my own vector engine (especially since I'd write a bad one).  Also editing levels would be quite intensive, requiring a flash style editor with time lines and the like.  And then you have to run collision detection on it all.Anyone have any bright idea's for a nice way to do something like this?  Currently my only idea involves creating custom hard coded "blocks" you can place which you can activate to play, but that's going to be heavily time consuming and restrictive if I have to hand code each one.  Another draw back is that my level's kd-tree would be invalidated by the animating sections and need rebuilding.  Making them dynamic world objects avoids the level partitioning but it also avoids all the nice speed optimizations for object vs level collision detection.So all in all writing this post I seem to have written my own todo list: - Write crazy level editor with time-line and section animation editing - Re-write level partitioning to use some system that handles animating objects nicely (ie. not a KD tree) - Figure out a way to trigger the animations, probably based on player proximity or time.Thats only 3 things .... easy right? :P   
Quote:Original post by ptoTo me it looks like they're using vector graphics, but I don't think the iphone really has the power to handle my own vector engine (especially since I'd write a bad one).  Also editing levels would be quite intensive, requiring a flash style editor with time lines and the like.  And then you have to run collision detection on it all.You may want to try building a quick prototype first - if you hit performance limits soon, then you'll likely want to look for another approach, but if things are going fine, then it could be a viable solution.Personally, I'd look more towards a polygon-based system. That should allow pretty morphable levels too, while being easier for the collision-detection. You may be able to use a 3D modeling package for the levels (laying down polygons on a 2D plane), or you can build an editor interface right into your game. Building a custom editor is pretty time-consuming and hard to get right (undo/redo is quite tricky, especially if you try to cram it in as an after-thought).   ;  This would seem like an appropriate time to plug Growth Spurt. [grin]I cheated and had practically everything procudurally generated so each level is just a handful of params (controlling number of plants, average leaf size, etc.), if you were aiming for something more controlled I'd probably make some semi-procedural level elements (like individual plants of particular shapes) which you can then place in a level editor and tell them to grow towards a particular target. Maybe bolt on a scripting language so each level has a script  controlling the pace and triggering growth events and whatnot.   ;  @Captain P:  Very true that a full level editor is probably a bit much - if it was simply a polygon system that interpolated between key frame mesh's then using max/maya would defiantly be the way to go.So for argument's sake lets say its polygon based so collision detection can simply use the SAT code I have now.  Spatial partitioning is always the show stopper for me.  I've never dealt with dynamic levels befor.  From what I know we have:- Brute force:  Clearly out, with a decent number of enemies and level geometry it won't hold up.- KD-Tree/OctTree/Etc: Probably out.  The rebuild time is just too great.  With some fancy code you could make it only rebuild the branches with changing objects rather than the entire tree, but sooner or later your going to want the entire level to move and that will bring the whole thing down.- Uniform Grid: Could work - just memory.  Would be very easy to update as the level moves, however the iphone doesn't have alot of memory so - S&P: Sweep and Prune might be the way to go, I hear its pretty good for moving object.  Sort on each axis, then create a list of potentials.  I simply haven't ever implimented it personally so its a little bit of a black box - comments?- Anything else I don't know about ... comments welcomed.  Guess I might try writting a S&P demo see how it holds up.  Although any other suggestions are more than welcome.   ;  I suspect you'd get good results from a hybrid of the two - something like a uniform grid or quad tree, but with quite coarse leaves (which means that updating the tree is kept to a minimum, and memory overhead is much lower). Then use sweep and prune within the leaf nodes. That'd mean you're only really doing S&P on the local area rather than over the whole map, which for a big map should drastically cut down on the amount of objects you need to sort.   