The magazine analogy is just wrong. Once your magazine is out of date, you can't put it on the shelf and go grab a newer copy at no cost, with the only drawback being that the new magazine politely asks you to pay for it every time you open it.

It's not unusual for developers to include a limited amount of updates when you buy a license, that's all this is. Imagine that the next version of C2 (30) is a major realease. Now, if Ashley and co can manage a new release once a month, that makes 24 updates over 2 years- easily more than one major version upgrade in a traditional model. If you wanted to buy a licence to own the software under a traditional model, you would stop receiving updates halfway through that process.

Oh, and gamemaker is �25, not $25, last time I checked.

EDIT: Seems that YYG practice a bit of regional pricing.$25 or �25 depending on your location.

Just some food for thought, a little analysis on the various methods used to monetise game engines:

• GameMaker: Feature limited free version, �25 for pro version. No subscription or profit sharing. New versions are infrequent and usually incur an upgrade fee. YoyoGames are now acting as publishers of iOS and Android games made by their community, bringing in another revenue stream.
• Unity3D:Feature limited free version, $1500 for pro, additional modules for iOS, Android, etc. starting at $400. Free version has a branded splash screen on exported games. Web player available, as well as exe export. Also, Unity just announce support for 3D accelerated Flash export. New major version at least once a year, not sure about upgrade fees.
• 3DRad: Unusual model. Free version available, at least 6 months behind current version. Recent donators (last 30 days) get access to the latest development version. The forum has a bidding area where the developer proposes features and users can put cash towards them in support. Features that raise the required funds are given priority. Current dev version - 7.15; current public version - 6.50. Releases used to be monthly, but appear to have been slowed down recently, perhaps because the jump from v6 to v7 is quite significant.
• CoronaSDK: Free to download and develop with, games can be tested in the simulator, purchase an annual subscription to publish on iOS or Android ($199 for one, $349 for both). Subscribing also gives access to daily builds of the software and premium resources. Updates to the main app seem to be incremental, about every 3-4 months.

There are probably errors, and there are plenty more options to consider. If anyone wants to add anything, reply below and I'll amend this post.

I voted for behaviours, on the basis that the behaviour system will allow other people to start extending the functionality of C2. Quite a few of the old behaviours had their source files released, so the code is there to start porting them to C2. I wouldn't expect every behaviour to be done as part of Ashley's work, just the main system and a sample implementation, as some others mentioned (although, custom movement might be the most useful, something simpler might be better in the short term).

This might interest you:

I noticed the same problem myself, and the only solution was to use the custom movement behaviour. The events are as straight forward, but you have more overall control.

Personally, I think uploads should be a sub forum of 'Tutorials', called 'Example CAP Uploads' or something like that.

There are so many threads on the Uploads board, proper tutorials would soon be swamped by a multitude of small demos, examples, support requests, etc. I really like the fact that only proper tutorials tend to end up on the Tutorials board.

And while you're at it, why not rename 'Tutorials' to 'Learning Construct' - that way it makes more sense to have a mixture of tutorials, tech demo, examples, etc.

My proposal for the forum layout:

Construct forums

Help & Support using Construct

Construct Discussion

Learning Construct

• Example CAP Uploads

Addons

• In Development

General

Your Creations

Open Topic

Developers

Construct Engineering

Looks awesome. Will download as soon as I get the chance.

Watching your videos about it now - i get the impression you are supposed to move objects using the keyboard. If that's the case, can I recommend you add handles for moving, rotating and scaling, so that editing can be done more visually?

Just out of curiosity, madster - did you benchmark these changes? And did it make any different to performance?

binary cap files have got to go. They're bad for team projects, bad for version control, they get corrupted and you lose everything.

Instead, let's switch to a project folder and xml based solution. This is actually something I've given a lot of thought to, based on my experiences with Unity and the way they implement projects. My thoughts:

• A root project folder containing a ".capx" file that describes the project using xml.
• sub folders for graphics, music, sounds, objects, layouts, events, effects, plugins, data.
• store as much as possible in xml files - object definitions, event sheets, layouts, etc.
• if you want to share a project, let C2 package it into a special zip file (.capz?), and then have C2 unpack it automatically on the end user's machine.
• integrate C2 with SVN or Git - allow users to enter their GitHub credentials and automatically sync their projects from within C2 (wild idea, i know).
• for BC, allow it to open binary cap files and parse them into xml projects.
• allow plugin files to be frozen in projects, so you can share without others needing the plugin (side benefit- if you open a capz file and it contains a plugin you don't have, C2 could ask if you want to add it)

some nice replies in response to the spammer though.

Anyone else notice the spammy ad links in this guy's sig?

I'm guessing they were added in later once the original post had a few replies.

I voted Android, because I have one myself, but I think if you can abstract out the runtime and renderer components, turn it in to a sort of virtual machine that plays construct files, you can make it so C2 can export to all sorts of platforms. Obviously, PC is going to be the number one, but my vote goes to Android as first alternative.

How about something like this:

+ System: Is global variable 'EnemyBatch' Greater than 0

+ System: Every 1000 milliseconds

-> System: Create object Enemy on layer 1 at (random(DisplayWidth), random(DisplayHeight))

-> System: Subtract 1 from global variable 'EnemyBatch'

Works like this: as long as EnemyBatch is more than 0, it will repeat once every second. Spawn an enemy, decrement EnemyBatch. Tested and working nicely.