Thanks Geometrix that's awesome, this is how I envisaged ImagePoints working but obviously not! Sorry I'm new!

curv My pleasure :) I've only been using Construct for a few months so I know what it's like when you're just starting out. The thinking behind image points seems to be purely as pre-designated XY values for images, usually used for spawning new objects or when moving objects. So they're perfectly suited as particle spawn locations, for example. I've been using multiple image points extensively in my current project and they're a godsend.

Thanks for the capx that's exactly what I need. So is pinning the way to go for this or do I add a box to the actual image?

Yup, you'll need to pin the collision boxes to each image piece so that they follow along when the pipes are moved or rotated. Pinning is always relative to its location before it's pinned, so position it first, then pin it.

I'd suggest that you create a very small, invisible block that is stuck to each image point on each pipe object. Testing to see if they're facing each other then just becomes a matter of testing whether a block is overlapping another block.

capx, without the grid system implemented.

Ah, brilliant. Thanks — Silly oversight of mine :/

I've added those changes and re-uploaded the capx. Still here.

retrodude Here's a capx that I made for someone else who requested this same feature. It's not perfect (captured area seems to be offset for some reason, probably a silly one), but it has the basic idea that you want. capx

I'd suggest that you also take a look at R0J0hound's canvas plugin for more advanced drawing tools.

The way I see it, you have two options when the player is finished "drawing" the objects: either capture the canvas space with a screenshot (like in my capx), or capture the position/angle of the objects and recreate that fully in-game. The latter could make for some interesting custom animation if you use physics joints, but could also be very sprite-heavy, possibly to the point of slowing down the game.

If I understand you correctly, you want your car to behave like an articulated vehicle?

Like this?

Car behaviour will be fine for controlling the vehicle, but you need to assign both the car and the carriage to have physics behaviour, too. Don't forget to set world gravity to 0, and spend some time learning about physics behaviour to configure things like angular damping.

Assuming you don't want to make invisible the objects as they're touched, your best way to keep track of the current objective would be with instance variables.

Your link gives me a 404, so I'll approximate what I mean:

Create an instance variable for each sprite, a boolean called "target" or something. Set to false to begin with. Then, along with each touch condition, create another condition that the sprite's target must be true to perform the actions.

Now what you want to do is create the mechanism for altering that boolean as you go along. For each new objective, you should nominate the next target by changing its variable to true. Then, when that object is touched, set its variable to false, play the sound and set the next objective's variable to true.

I've included a very rough capx so you can see what I mean: capx

Unmerciful Give them a specified random range on the Y axis, like random(1,100) or whatever works in your layout.

Sorry, that was probably the wrong word to use. I just meant "set", but I was thinking along the lines of the nine predefined image points (bottom left, centre, etc.) as they correspond with the num pad, so in a way it is something that's selected.

The image points on your attack and player boxes were wonky.

Here's what I did:

1) Set your playerbox to mirror along with your character on turning left/right. This mirrors the imagepoints as well.

2) Created a new imagepoint for playerbox (imagepoint 1; you actually referenced it a few times without it ever being created) that was aligned on the ground and out a bit to the side.

3) Reset the attackbox origins to be at the center/bottom.

capx

What you want is the condition "Is overlapping another object".

The rule for conditions in C2 is those with green arrows are triggered only once when they occur, whereas those without arrows are triggered perpetually while that condition is true (you can also modify that with the system condition "Trigger once while true").

Welcome to the forums! I'm also pretty new here but am already finding it to be a very informative place.

You can use Pin at start of layout or on creation, but you first have to manually set the position and angle to match the player object (Pin is relative to its starting position). The alternative is to update the position of the player character to match that of the player box every tick.

Just FYI, what you want is for the user to control the boxes, not the animated character, then update the character to stay with the boxes. All controls should be assigned to the box for the most accurate collisions and controls, and animation changes should be assigned to the character.

capx

I suggest you to include in your game a detail level option and every eyecandy in a family ready to be destroyed at the start of layout when the option is set to low.

If you have some visual effects with objects created at runtime (and you'll likely have them in your game) put all the events in groups ready to be disabled.

This could be a good approach to make a visual appealing game on desktops without sacrificing smoothness on mobile.

Thanks, that's a good idea. I'm currently killing all particles if mobile is detected, but as I push for that balance between visual fidelity and playability later in development, that'll be an easy way to accommodate for low-spec mobile devices. If I have enough devices for testing then I might even be able to set three levels of visual effects that the user can toggle between.