Thanks, bluemonk, this is what I need!
First:
Your document suggests that the benefit of tiling is to reduce memory usage
Haha, yeah, my document probably makes many silly/bold/false claims! It's (currently) not so well thought out!
Do you see how a tile-based map would simplify collision detection?
Well, with tileless, you still are in a sense making tiles, but they do not have to be square or of any particular size. Your "pallette" of artwork to design your level becomes a big collection of any pictures you can find.
Have a look at this video:
http://vimeo.com/2769377 to see what Ii mean. ...I can't explain it to well!
Are you going to have some kind of tree structure that quickly eliminates far-away objects from consideration in collision detection and drawing? (Is that how it's done these days?)
Yup, it's all in the algorithm! It's every bit as fast as tiles, perhaps faster, since you're (probably) not making millions of calls to draw little square images. ...Bigger artwork in the level equals less calls to the bitmap blaster. *(There's many variables involved really. So it's not safe to claim that a tileless system is faster, or slower, but they do have their moments. Suffice to say, they can get the job done. I have never heard one complaint about their speed, and I've been around them for a while now too.)
managing collision detection optimization... maybe that's the responsibility of the physics engine?
Yeah, as I mentioned in the doc, you draw out your collision polygons, then I just sorta "upload" those polygons to the physics engine, along with any physical properties (bounciness, etc). Then every crank of the main loop, I just query the physics engine about any collisions that have happened since last time. If there's a collision that requires a reaction (bounce), the physics engine (which would do all the math based on their weight, etc) will tell me what direction and what speed I should change them to. So for simple platforms, you draw poly's around your artwork, and just set it to a simple "you can't go there" type collision. Or perhaps it's a big rock, that would require a run to move the weight.
So yes, the physics engine is the boss of all the polygons in the game and it will tell us when collisions happen and how to respond.
...Sorry I'm just no dang good at explaining things!
I don't have enough time/skill to draw a million tiles' worth of different graphics, never mind how much memory it takes
Don't worry, it's still very tile friendly and aware. You can add tiles to the palette and set up a grid with snap - then it's business as usual.
What are the limitations of the physics engine
Not many! Did you catch the video?
http://www.youtube.com/watch?v=Oecv7Cg9lCcFor anyone who still can't get their head around this tileless idea, try downloading this editor:
http://www.gleed2d.de/#downloadIt's nice and small with no install program. You can be working with it in seconds. There's video tuts for it (
http://www.gleed2d.de/#media ) that can bring you up to speed in about 15-20 mins (just long enough to eat a bag of popcorn!). Then have a go at making a little pretend level and see if you like it (It's not the best, but it's easy to try out). This editor is actually written in XNA, so test it for speed too. I think you'll find the map rather zippy!
Thanks, again BlueMonk. Keep those questions and suggestions coming!