I'm interested in creating a 2D sidescrolling game with map design based on convex vectors instead of tiles (See "Type #4" in this article). This will be a challenge for me, and I have a few questions.

My first issue is with level design. The way I see it I'll need to do the following:

1. Design each level as a series of convex shapes for collision, overlaid with an image.

2. Save each convex shape as an array of points.

This would be very tedious, are there any map editors available that already do something like this?

My second question has to do with moving the player up and down slopes:

Collision detection and response should be no problem, but I'm not 100% sure about how a player would move up and down a slope. Currently, I would do it like this:

1. Determine if player collides with a polygon.

2. Determine between which two points of the polygon the player is colliding.

3. Modify player's Y-value based on the slope of that line segment.

Am I on the right track, or is there a better way to do this?

Would love any insight or links to articles on the topic. Thanks guys!

I'm not aware of any that do this. Its a bit unclear to me; are you wanting to do tile-based graphics with vector-based collision (a combination of #2 and #4), or free-form graphics with vector-based collision (just #4, like Braid)?

There are few, if any, map editors for games with free-form graphics as far as I know of. But actually a decent substitute, at least for laying out the map, would be to use a 3D modelling program constrained to a plane (or perhaps a few planes, for parallax). You can layout axis-aligned textured quads for the main background, and then instances of other "decorative" objects with arbitrary scale/rotation. The "models" for the background and decorative objects would just be textured quads, or I suppose other shapes as appropriate. You could even layout the collision data as a collection of line segments, where each collection is again a model. You'd just need to parse out which models are for rendering and which are for collision when you load the map file. You probably want to transform the 3D modelling file into a better format for distribution anyways, so you can do this step then, but its an implementation detail. Some collision data might have other uses -- for example, a lantern on a wall may not collide with entities, but it still might need a hit-box so that you can smash it for power-ups. You'll need a way to sort that too. Typically each model in a 3D scene file has a unique ID, so you can use it as a key or encode it to have different meanings.

If you want Tiles + vector collision, then you probably need to write a simple tool that displays the map and allows you to define the collision segments, or alternatively, each tile can have predefined collision boundaries and they can be automatically linked to neighboring tiles (you'll still need a tool to define them in the first place). Another option is to create a tool that exports your tile-based map as a 3D-scene (each tile is a textured quad model, these arranged in a grid to form the map), and then you can use a workflow like I described before to define collision and whatnot. You can also have your conversion tool export "default" collision data as I described at the beginning of this paragraph, so that it can be modified in the 3D modeler,

If you do not have access to high-end, often expensive, 3D modelling tools like Max or Maya, Blender is very powerful if not as polished as the others, or you could try Google Sketch-up for something a little lighter weight. If you're familiar with Ruby, Sketch-up offers a scripting interface that you might even be able to use to import tile-based maps so that you can manipulate them.