It's a start.

What else do you have? I'm thinking you'll need a bit more to make your game more playable for a period of time longer than a few seconds. It needs certain challenges and ways to progress through the experience. Stuff that maintains the interest of the player and keeps them engaged.

Choose whatever you can manage. Construct 2 can upscale it. It's important to work with whatever is comfortable for you, because you'll most likely build a better game that way. That's my advice anyways. It's probably more important to choose a common screen aspect ratio than to worry about the resolution if you're going to worry about such things. The resolution doesn't determine whether the game is good or bad.

With Construct 2 you can finish games, but with Unity you get unfinished games.

R0J0hound ,

maybe use instance.SetHotspot(p)

for the start point, and a couple variables for the end point(or maybe use an imagepoint for the end point?).

renderer.Line(a, b, color) for drawing the line in the editor.

seems like a way, unless I don't understand what those are for. You probably know better than me.

Okay, cool.

As for lines. I remember using them mainly for constructing a level(tracing around tiles in a tile map procedurally, combining lines that extend from each other so that there aren't unnecessary lines. I forget if I also put them into cells/groups to lower the amount of collision checks, I forget if chipmunk does that sort of thing).. There's probably a lot of uses for them besides that though. I think being able to position the ends of the lines accurately is important. I'm not sure how that would be done if it's just another collisions shape type for an object- unless you put some visual way of showing the line in the editor, and options to edit it? I imagine most people would want to specific where a line starts and ends.

I don't think there is another way besides making a condition for each object with a solid behavior. Hence using a family is best option.

One thing to note, if you have multiple objects with a behavior, and then add those objects to a family, you won't be able to use actions from those behaviors if you're referencing the family. You'd have to add the behavior to the family instead. Same for instance variables I think.

So if you plan on using lots of objects that share the same behavior, might be better to add the behavior to the family rather than the objects. Same goes for instance variables.

R0J0hound , it doesn't work with tilemaps. I just tested it using a tilemap, and it seems to be using the bounding box of the whole tilemap instead of the polygon that the tiles construct. Even if I switch the option to polygon, it still doesn't collide correctly.

Box2d works correctly with tilemaps, so it would be best if chipmunk also worked with tilemaps. Any plans on implementing this?

edit: also wondering if you'll be adding support for lines.

edit2: been trying to use it, but adding forces to objects seems to mess things up. their points seem to become displaced and move all over inaccurate from the object.. weird... :\</p>

Because if you have say Object A that needs to collide with Object B, but not Object C. You would disable collisions between A and C, allowing A to collide with B.

If you just disabled the physics behavior of A, then A wouldn't collide with B.

Edit.. also, perhaps C should collide with B as well.. You wouldn't be able to just disable Object C.

I will definitely try this out next time I require physics in a project. I remember using chipmunk in the past, and it was really great, so I'm excited to see this for construct 2!

Apparently there is a fix that will be in chromium 41, allowing dynamic loading of libudev on linux.

based on this page: http://www.chromium.org/developers/calendar

Seems chromium 41 is set to release Jan. 12th..

Node-webkit currently uses chromium 38, and I'm unsure when node-webkit will be updated to use chromium 41. Hopefully the sooner the better, for linux users at least.

trailer looks smooth to me. Nice work! This seems like a cool use of C2- I'll have to try this sort of thing out sometime.

I think newt was suggesting that C2 allows users to easily produce engine issues(if there are any) since C2 makes it easier to work with it. And because of this, users don't see initially the fact it is an engine issue because users interact with C2, not the engine directly. When something goes wrong, their immediate focus is on C2- with what they have their hands on.