It's a bug, use if left mouse is down + trigger once.

Oh, and don't use the layout object if you can avoid it. It's very buggy.

The bugs were so numerous that it was good we were working as a class... so most bugs only had to be tracked down once.

This is a good point. Construct has a lot of quirks/bugs that new users need to learn about before construct can be used smoothly. Perhaps someone should make a bug avoidance tutorial.

Many features seem to have been just tossed in without much testing. Or features are half-added and half-completed. I'm well-aware that this is open source and such, but Construct is still not at the point where it is useable as anything except the roughest of game prototypes. Or as an exercise in patience and using unstable software.

Even professional-level tools have bugs in them that need to be worked around, so at least it's a good skill to learn (not that I'm saying the developers shouldn't try to make it more stable).

We were also unable to merge our files.

As has been mentioned, that's an unfinished feature. Hopefully that'll be finished for 1.0.

From comments the teachers have mentioned, open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source.

The developers know about that and are going to fix it for construct 2.

It might be an idea to stop attempting to add new features and get the current features stabilized first.

They have actually gotten to that point. However, they have mentioned that they learned to code making construct, and therefore not only is the code in many places kind of a mess, the structure of the program doesn't allow for a lot of the necessary fixes. It would be faster to recode the thing from the ground up than to fix everything, so that's what they're going to do. It won't require a complete rewrite though so it should require less work than coding construct 1 did.

I'm aware we were using the 'unstable release' but it is not possible to use the stable release when all help, advice, and such only refers to the most recent unstable. And the first response to any question is 'be sure you are using the latest unstable!'

The term stable/unstable is a bit of a misnomer. Stable doesn't really mean that it's entirely stable - it means that it's stable enough, but there's not any new huge crazy bug in it anywhere so it's at least as safe enough to use as the previous one. I would vote that a lot of the time the unstable releases are as stable as the stable ones. I think they need to put a new label on them that's less confusing.

Also, I'm not sure if you saw it already, but you should read Ashley's post on the topic here:

More info: http://ubi-art.com/

What I find most intersting about it is during the presentation, the CEO said that they had made tools that not only were designed to make it as easy as possible for artists/nonprogrammers make games, but they wanted to make the tools available for everybody in the world to use.

Sounds kind of like construct.

Tips for working with ginormous games:

Split up large event sheets. They become too unworkable when there's too many events in a single sheet. Don't make a new event sheet for this - actually make layouts for the event sheets you want to include. The reason for this is an event sheet that isn't tied to a layout will list every object in the game in the expression editor, whereas an event sheet that's tied to a layout won't.

However, because it doesn't list objects from other layouts, you need to either paste instances of the objects you want to work with in the layout or temporarily make them global.

More benefits of doing it this way are that you don't have to copy and paste events as much anymore and you don't have too worry about any issues that could result from copying and pasting between .caps.

Thanks for the interest, but I'm not quite ready to reveal much about the game yet. I don't know when the game will be done, but I would like to have it done before starcraft 2 comes out.

It's simple enough that I don't think it'll derail the thread. You make one sprite and use 'load animation frame from file' to load from a jpg or png.

I've been working on a major game in construct for about a year and a half. It currently has about 5000 events and the game is about a hundred megabytes of data. Here's what I can tell you:

Construct is very, very close to ready for a major game, but what's holding it back from ready status is stuff that can be worked around. There are two things standing in the way:

1. Copying and pasting between .caps is an unfinished feature, and will mess up whatever .cap you paste to (copying and pasting within the same .cap is fine). Therefore, construct is currently only suitable for a game made by one programmer. If one person is coding the whole game, or at the very least only one person is working on it at a time, that's not an issue.

2. There's a memory leak involving the expression/picture editors and how many objects are in a layout. Every time the expression and picture editors are opened, construct will use more memory. Eventually, it will cause construct to crash. The length of time that it takes for construct to crash depends on how many objects are in a layout. This bug is probably going to go mostly unnoticed until you have about 100-200 objects in a layout. Then it gets really annoying. I've had to find ways around opening the expression editor in layouts with lots of objects whenever possible. If this one bug were fixed, then construct would be ready for a major game.

One way to combat this is to make objects be multipurpose when possible by defining different behaviors for the objects based upon variables, so one object can perform multiple tasks. This obviously doesn't work in all circumstances, but it does work for quite a few.

As for the speed of the editor, when you have lots of graphics, it takes longer to save, load and preview, but from what I've noticed, large background images seem to effect the saving/loading/previewing speed the most. I got around this by loading backgrounds at runtime instead of including them in the .cap. It makes it MUCH faster. Doing this reduced the amount of time it took to save, load and preview by about half, maybe more.

Having lots of events mainly makes opening the event editor and previewing take longer, it doesn't seem to affect saving speed much. My battle event sheet is about 2000 events and it takes about 30 seconds to open the first time, and about 10-15 seconds subsequent times.

Even with the issues I've mentioned, it's still doable. It just gets a little awkward trying to avoid opening the expression editor.

DUDE... awesome.

Hmm... I wonder if there's some way to automate this a bit more. What exactly does the event exporter do? Could it be made to export to java code that could then use that engine to plug in to?

Or... is there some way that upon exporting, the java engine could be used like the directx engine at runtime, merely using the java one instead? And does it matter if he's basically creating a new runtime?

Same answer as before. If you want the runtime to use anything other than the current version of DirectX nine, you'll have to code it yourself. I can't help you any more than that, otherwise I would've tried to have written a direct X 8 runtime myself!

You can get the source on sourceforge. http://construct.svn.sourceforge.net/viewvc/construct/

The only ways to get it to run without DirectX nine is either use the application runtime (which isn't really an option for games, as it has no graphics engine) or code a new runtime that uses something different like OpenGL, DirectX 8 or a software renderer.

Wow, that is a LOT of sprites. Be careful to watch your VRAM usage!

You can use the 'move at angle' action for this. Basically, find out what angle and what distance to move the created object when the base object is at angle zero, then add the main object's angle to the angle to move the created object.

Create sprite2 at sprite.x, sprite.y

move sprite2 at angle: initalamount+sprite.angle