Strange bug here - if you play a game, lose, then press enter, the next game is super easy. Either all the turrets are super-powered or the enemies only have 1HP. I just took out the boss with a single shot!

This one crashes for me every time I get to the 3 second delay message, or the move V message if I skip the delay. No useful error messages I'm afraid, just "unexpected error".

Well, I didn't, but I do now. It took me a while to figure out exactly what you meant. I had assumed there was an easier way to get there.

Anyway, that lengthy description was mainly just to make my point- that it would be awesome to have all those potential variables already available to us in a combo-box. I've been thinking it from the moment I started playing with this software- I've even spent time looking for it, because it seemed such a natural part of the software that I assumed I just hadn't found it yet!

Just a thought - wouldn't it make sense to turn the variable fields in ACEs into combo-boxes, pre-filled with some of the standard things we would put in them.

For example, the "Control is Down?" event has a text field to put in the control to check for, with a blank set of quotes to tell you to enter a string. Now, there may be occasions when I may want to put in an expression of some kind (I don't know if the would work because I haven't tried it), but 99% of the time I will want to put in one of the standard controls found in the Application properties.

Of course, I can't always remember exactly how they are written, so I usually go through this process: open up the new event window, realise I can't remember the variable name, close it, click on the layout tab, click on a blank area of the layout to open up the layout properties, click on the Application properties link, scroll down to the controls, commit "Jump" to memory, then go all the way back to the new event window and enter the control name.

Since the controls will no doubt be accessible somewhere in the code, why not just make it a combo-box and make everyone's work easier? The same is true for large number of the variable fields in ACEs, like references to image points, sprites, objects, resources.

I really think this could cut down on errors and speed up development time considerably.

Love to adaptive difficulty you've put in this - making it faster and harder to turn as it gets bigger, but also making it easier to get food at the same time.

Add a time limit to this, as in "get as big as you can in 5mins", and you have a game. Then you can add other things, like hazards (poison that makes you smaller), high scores, etc.

This could be way more than a tech demo.

I was looking for something like that, but I didn't expect it to be in a behaviour. Finding out if something is moving seems like a pretty standard thing to me. It should be in the standard list of conditions.

Plus, I wanted to spawn the tracks at a different rate depending on whether the tank is moving forwards, backwards, or turning (these things happen at different speeds).

I know it's not the most elegant system - I really did knock it out it 15mins. I'd love to see how other people solve the same problem.

I just made this little example, showing how to do simple tank movement that leaves tracks behind.

I used image points to place the track sprites.

Hope someone finds it useful.

Device name: NVIDIA GeForce 6150 LE

Pixel shader: 3

Estimated VRAM: 793 MB

Motion blur: Yes

This is my home PC. We have something significantly different in college. I'll check when I get the chance.

I mentioned this in a help thread, thought it wise to move the discussion here. Original link:

Currently, if you want collisions based on anything other than pixel perfect or full bounding box, you have to create another sprite to do the job and link the two together with an always event.

I propose two possible solutions to this problem:

Firstly, the ability to define custom bounding boxes that would be calculated relative to the hotspot. You would need variables for width, height, x-offset and y-offset, which could be added somewhere in the properties panel. For example, if the hotspot was in the centre of a 32*32 sprite, the bounding box could be defined as W:16, H:32, XO:-8, YO: -16, in order to place a tall, thin bounding box in the middle of the sprite.

Secondly, for more complex collisions, you could offer the ability to define a custom collision mask, editable in the image editor. This could function in the same way as the multiple animations found on a single sprite. If present, this mask would be used for collisions instead of the currently displayed sprite.

Any thoughts?

And honestly I don't think it's that hacky of a practice

Hack or not, you can't deny that setting up events and actions for games would be a heck of a lot easier if you had only one sprite to deal with per distinct in-game object. As it stands right now, you need two sprites for each object, with events and actions distributed between them.

I just feel it would be great if you could say "the bounding box for this sprite is W*H pixels in size, offset from the hotspot by XY pixels". Or better yet, the way there are several animations per sprite, it could be possible to have a special image called collision mask, which would override the pixel collisions of the animation frames.

Anyway, I didn't mean to hijack the thread. I'm going to open up a topic on this in the feature requests forum to continue discussing this.

Things like this would be much simpler if Construct allowed you to define custom bounding boxes for sprites, relative to the hotspot. Then there wouldn't be any need for linking animated sprites to hidden interactive hitbox objects.

In GameMaker, with sprites you can define precise collision detection (pixel perfect), custom bounding boxes, or you can even make a mask sprite that can be explicitly linked to the object for collision detection. It's a lot more flexible and robust in that regard. This invisible hitbox and visible sprite method just seems like a hack.

I've found that using the unfinished themes results in UI glitches with the Layout/Event Sheet areas. I did like the look of the Office 2007 themes, but those glitches just got annoying, so I've switched back.

Basically, every time I alternated between Layout and Event Sheet, or did any other changed that cause the area to rerender, the scrollbars would flash in a fixed position about 50% the size of the sub-window. Going back to the regular theme fixed it.