It's fun to fire across such a long distance. You should post it again when there's something to shoot at.

There is definitely a less tedious way to make the events for it, though - instead of creating a sub-event for each state it could be in (anim frame = 2 then set speed 60, anim frame = 3 then set speed 70, etc), you can just create one event that takes the animation frame into account (set speed to 50 + anim frame * 4).

Similar for the charge-up bar - instead of using an animation you could use a sprite, then resize it to the right width depending on how charged up it is.

Here's how it would work:

http://files.getdropbox.com/u/906550/Co ... stions.cap

I wouldn't recommend using Python unless you're already really skilled with it. As I understand it, Python's kind of an afterthought for Construct - you can definitely do everything without it (and probably should).

You can do a lot with loops and families once you get to know them them. Here's a fairly amazing example one of the developers posted a while back:

http://files.getdropbox.com/u/906550/Co ... locks2.cap

...or if by scripting, you meant using Python: yes, you can do all of that without Python.

I think the 'heap of mini-games' idea could work really well. Just imagine the insane stuff this community would come up with!

It'd be a great way to show off the features of Construct, since different games could showcase different areas. Also, it'd avoid a lot of the problems associated with collaborative projects: different artistic directions, the need for coordination of different project areas, project bloat leading to collapse, etc.

Well... I made a little iso engine that seemed to deal with the Z order problem okay.

You just have a layer for each depth, and then order objects within each layer by their Y position. It's really limiting if you want to have completely variable heights (like how X and Y coordinates are continuous), but if you just want simple floors, it seems to work reasonably okay.

(I think there are probably at least six better ways to do it, but if you want to look at the engine, you can. This one only solves the problem for the character, but I was able to make one that updated all the terrain as needed, using a similar method.

http://dl.getdropbox.com/u/906550/iso%20demo.cap

I hated this engine so much that I scrapped it and started over, hoping to make something based on a built-in map editor. But nothing to show for that yet.)

I'm pretty sure there's no way to tell what individual particles are doing, so you can't tell when one leaves the layout.

But changing the timescale can be done based on how long you'd expect it to take to fill the screen, so you can just set timescale to 20 at the start of the layout, then to 1 when timer = 15 seconds, or something like that.

Regarding the effects - yeah, I see what you mean! I'd never noticed that before. It only seems to happen with some effects: "Outline" or "Greyscale" apply correctly, but "Soften" works for one instance of the particle object and breaks the others.

Looks good, runs fast, and I think it'd make great snow, also! But it takes such a long time to get established.

Tried making a situation where the timescale was really high for the first few seconds (to quickly set up the starfield at the start). That sort of worked, but the particle object seems to act strangely at very high timescales.

(I guess I'll submit to tracker, if it's not a known issue or a side effect of the way particles are handled.)

Thanks for posting this! I wouldn't have thought of rolling my own Windows-style windows. Looks modern.

Thanks! Now I can stop using appalling hotspot based orbits.

Like Max said - you could create a bullet sprite the same width as your beam, facing in the same direction, and just make it, say, 200 pixels long. Then you could give it the Bullet behaviour, make it Instant Hit, and set the speed to 200.

Instant Hit just keeps looping in the same tick until it hits something, so it'd strike the target immediately. If it traveled 10,000 pixels at the size and speed I said above, I guess that'd be, what, 50 loops? Should be no problem for the CPU.

Definitely, Inkscape seems to be the best of the free vector apps.

If anyone hasn't heard of it yet, I'd also recommend PaintDotNet for raster work - it's good for small-scale stuff, when you can't be bothered loading Photoshop or the GIMP and wading through a bazillion options.

Thanks Roracle, that's handy!

That reminds me - I'm not sure if I've linked to this before, but Lost Garden have some nice prototyping graphics. You wouldn't want to use it for a full game (because the over-cuteness would rot your eyeballs), but it's good for testing ideas.

http://lostgarden.com/2007/05/dancs-mir ... -game.html

Just started playing this today. Definitely an inspiration.

The game is so damn accessible, too. There's no menu screen when you start: you're told how to walk, and you start walking. You're shown the controls as you need them, in a fairly understated way. (Eg, the first time you're rewinding a long time/distance, it fades in the keys you need to change playback speed, shown near your character.) There's no HUD, lives, inventory, any of that stuff. You don't need to manage saves.