I don't see how they remain afloat by doing such a scheme. Advertising?

I haven't actually checked the cap - not installed Construct on this new machine yet - but I can offer a few tips. It is best to try and start organizing your code as soon as possible, because it is only going to get much messier

What I generally do is create external event sheets for each feature - one for game menus, one for actor movement, one for AI, one for sound&music etc., you get the idea, just include them when needed.

Also, it is an idea to reuse an implementation as much as possible, make everything modular so that you can reuse them again. For example, instead of using different and complex sprites for actors, have a basic actor (sprite) that has all the basics, then base player and NPC on it. That way you have more control over them; moreover, you can hijack the control from player and manipulate the player character around, like in cutscenes! All you have to do is change a variable. You can even make enemies playable, too!

Don't be shy of event groups, either. When you have a feeling that the chunk of code you are making won't be used much, consider putting it into an event group. That way you can enable/disable it as needed, thus lowering the overhead (the runtime skips over disabled groups). Moreover, they make it easier to make sense out of the whole sheet! (Try saying that quickly. Heh.)

Use placeholders ('dolls') for everything until you have basic functionality, then polish it up! It's fine to keep things really simple at the start, first you want to make it actually work!

Split your project into different sub-projects - graphical interface, gameplay, story etc. and work on one at a time. Try not to mix them too much, or it will be difficult fixing a thing or couple.

Don't lose your sleep and time on the look and feel - placeholder graphics (programmer's art) are fine. Braid started that way, it looked **** ugly until its developer felt it was done and hired a pro artist. Look where Braid is at now! Basically, you want functionality first, art last! You can replace those colored boxes with state-of-the-art sprites later. Just remember any limitations (size, length of animations etc.).

Try to use finite state machine, too. Each object in the game should have a state, which says what the object is doing, like if "Player" is "Walking", "Walking and shooting" etc. - you can then have a separate event sheet pick those states up and play appropriate animations/sounds. Easier than throwing a bunch of events together and bloating the sheet up!

And, most importantly, don't give up. Even failures are good, because you always leave with experience! Your next project will be all the more smooth.

You probably should fix those DropBox download links - anything that starts with https:// doesn't work for the public, because it requires authorization (it is meant for users, not visitors). Use the public link

I like Dark Story for the style and Rich Adventure gave me a laugh! The rest are pretty good, too!

Thumbs up!

Then you have to store object properties globally (or externally, that works too). When you destroy an object in game, flag it as "DESTROYED" so that it won't be loaded again when you return to its layout.

I don't exist

Mipey - Slovenia

Or you can make your sprites white, then use the filter to change their color.

Though those engines were made with older Construct technology. Construct 99.x introduces new features, such as Z depth and sprite meshing, which should enable a powerful 3D engine. Brave souls needed to explore the new frontier.

Well, the idea is to check for obstacle before moving. Before you move right, check if there is a wall (overlap at offset by number of pixels that match the grid size), if there is, don't go there and check other directions.

I hope that helps!

+Does NOT overlap SOLID at (Grid size) pixels

Go ahead

Performance wise, Construct beats Game Maker and MMF by a large margin. You can test that easily.

Hmm. Wild guessing here, so don't sue me if it goes horribly wrong.

You'd need one large text field to display text and one text imput field. Store the text somewhere as lines (whole paragraphs, which would wrap automatically, anyway), then make a text scrolling engine that just adds and removes lines as requested, while keeping everything 'logged'. For that purpose, list object would be immensely useful (not the windows list thingy), but I guess you'll have to make an use of array or something else (hashtable), which means a lot of extra work.

For input, basically another text field. It would catch keys typed and type letters out - you'd have to do that manually with events, which is quite a bit of work again, but worth the experience - then submit the text to parser at a press of Enter key.

The parser would then use the text manipulator to search for strings, find key words, spit 'em out. Then you'd just compare them to the context, execute whichever actions are appropriate etc.; if it is not clear enough, spit an error message out or something along lines of "That is a silly thing to do!" or "Huh?".

So, yeah, you'd have to reinvent the wheel a few times. Such is Construct in its infancy - not many generic plugins that would simplify the work flow. For example, in this case you'd need a list object (to log text) and text input field for DX runtime (not app). That would save you hours of messing with events just to work a couple basic features out!

Oh, there is Timeline object, maybe you can make an use of it.