The organisation of gamemaker's interface and workflow is cleaner and better than Construct, IMO. You have sprites, objects and rooms - draw a sprite, assign it to an object, give the object actions and events, put it in a room, and hey presto - a game! Every component of the game is available in an organised tree structure on the left hand side - sprites, objects, rooms, fonts, sounds, backgrounds, timelines, paths and scripts.

Obviously, Construct's workflow is hugely different, but I still think it could benefit from a central library panel like some other programs (e.g. Adobe Flash). Right now, all the different parts are spread out all over the place, and you can't access all functions from all parts and modes of the UI.

Also, another thing that I think Construct could benefit from is the inclusion of a proper tilemap system. The current method combining sprites and tiled backgrounds (as found in Deadeye's platform school) still feels like a hack or a workaround for something that is quite a fundamental feature of many 2D games and engines. I don't know how it would fit in the current workflow, but I think it's something that should be added in some form.

I'm not using a sprite, I'm using a box. I want to position objects in relation to the box without needing to do any calculations based on its size. Rather than pre-calculating all of the x/y values, I just want to do 'box.x+2, box.y+2' and have the item spawn two pixels in from the top-left corner.

I'm using the 'System - create relative to object' action, but the pivot point is always in the centre and I need to spawn things relative to the corner. That's why I made this request.

Also, not in this case, but maybe in others, it may be necessary to rotate something not around the centre, like you can do in Flash.

Am I just trying to use the box object in a way it wasn't intended here?

Blank sub-events! Never thought of that!

Cheers, although I've just realised that it won't work anyway. The combo variable will increment whether it is the right key or not, so you could press up-down-up and it would still increment on the second up press. However, if I change the order of sub-events to go from last to first I think I can increment the variable on the sub-event and not have it cascade.

on Control "Move Up" pressed

compare global variable "Combo" to 1

-- do step 2 stuff

-- Add 1 to "Combo"

compare global variable "Combo" to 0

-- do step 1 stuff

-- Add 1 to "Combo"

So if Combo==0 it will skip the first sub-event, do the second one, then increment it by 1. If Combo==1 it will do the first sub-event but skip the second. This system has timers in it as well so there is a limited time to make the combo sequence.

Now, one more thing I need to add is making the combo reset if you press the wrong key. Would an else work at the end of this? If I was programming this I would use IFs, ELSE IFs and an ELSE, but I can't seem to get the ELSE condition working.

I'll try this tonight and see how it goes.

I want to execute an action for an event, but only after the sub-events. Is this possible? I can't seem to do it here.

I want it to work something like this:

On Control "Move Up" Pressed:

Compare Global Variable "Combo" to 0

-- Create Object at ... "Combo icon 1"

-- Start timer "ComboTimer" ... 250ms

Compare Global Variable "Combo" to 1

-- Stop timer "ComboTimer"

-- Create Object at ... "Combo icon 2"

-- Start timer "ComboTimer" ... 250ms

- Add 1 to Global Variable "Combo"

Sorry for the pseudo code, I don't have access to my files right now. Hopefully you can see what I'm trying to do. I know there is an exmple for doing double tap dashing, but this is supposed to be more of a generic combo system, where the combo variable increments following several different key presses - up-up-A to perform a powerful uppercut, for example. Try combo variable is supposed to track which stage of the control sequence has been reached. Obviously, I can't increment combo in the sub-events, because it will make it cascade through both sub-events.

Any suggestions for making this work, or am I going about it totally the wrong way?

I've come upon a situation where it would be really handy to be able to edit the pivot point on the box object. I don't necessarily mean precisely, just options like top-left, bottom-middle, etc. I need it for adding objects relative to the sides and corners, and for offsetting the rotation. I'm picturing something like the options you have in Flash when you create a new symbol, you have a 3*3 grid to select sides, corners and center.

I can't see any way to do this right now. If it's already possible, please someone enlighten me. Otherwise, I hope this feature can be added, not just for box objects, but for any object that displays on the screen.

That character after 'Yes' looks like a ^ rather than a ". Is it (a) a display bug, (b) intentionally typed, or (c) a typo?

Probably has absolutely nothing to do with your problem, but I just thought I'd mention it

Nice work on the checkpoints. That's an amazingly simple way of doing it.

You might want to make your movement TimeDelta based, as tower defence games can get pretty heavy on the processor when they progress (more enemes, more towers, more projectiles, more effects).

Keep it up!

Using a hidden collision object is the right way to go, so your character can still get hit (e.g. from behind) when he is attacking. Create a sprite that mimics the animation of the sword swing, but only contains the blade, call it sword mask and make it hidden.

Then, when you initiate the sword attack, spawn your sword mask using an image point to line it up correctly. You can set up collision events between the sword mask and members of the enemy family to do damage to the enemies, but you can still have the enemies hurt the samurai if they attack from behind. Then you just need to remove the sword mask when the samurai attack animation finishes.

Although, I should point out, this is completely untested.

#24 - Would 'Start Ignoring Input' do the job?

So, as soon as the cutscene is activited, the ignore input action is executed, then the end of the cutscene (e.g. Timeline) could activate input again. That way you could make the player ignore input, but still be able to press a control to skip/speed up the cutscene.

But there are at least some things, like controls, that could benefit from this. For example, in my tank tracks example I used the spawn command, which can spawn to an image point - surely Construct knows that the Tank object has two image points called 'lTrack' and 'rTrack'?

The problem is that, because everything is modal, and in some cases further modality within other modes, the benefit of the IDE over pure programming is lost somewhat, as we still need to remember exact spelling, cases, etc. of the objects and variables we are using. It's not a good thing if you have to cancel the current mode and go back to the mode where the information is held, is it?

Perhaps we could try listing which items can use some form of intellisense with relative ease. Also, the advantage of using a combobox for this is that people can still type it in directly if they want to. If we do populate the list with all layer names within the .cap (merging duplicates), they can pick from that list or write their own (before adding it to a layout).

What about negative values in the Random() function? Would Random(-10, 10) work?

Also, what would happen if you put a higher number first, i.e. Random(10, 1)?

Just curious.

How important is the August 2008 update? I mean, is it absolutely essential that Construct have it set as the minimum?

This is Adobe's version penetration for Flash Player:

http://www.adobe.com/products/player_ce ... ation.html

Version 10 is the latest and greatest, but if I was developing in Flash (which I have done in the past), I'd be aiming for version 9, at most. I wouldn't want to turn away users by making them download an update to their system before they could play my game.

Perhaps the same could be said for developing in DirectX. I'm won't claim to know anything about it, but couldn't the bar be set a little lower and still work to an acceptable level? What would be lost by requiring an earlier version of the DX runtime as a minimum spec?