Will expand on this later on website, but easy ability to add/remove/reassign seats. For schools, they can also generate temporary access tokens for classes so students don't need accounts and to have seats assigned directly to.

Is there any further explanation on this anywhere on the site? We're looking at the logistics for purchasing licenses for a school.

Normally I write extremely long posts, but I will try to be [more] brief with this one (EDIT: well I failed at making it short =/).

-------

The developer's concerns are valid. The pay-once model creates a less predictable revenue stream, making it harder for the developer to make hiring decisions.

It is also harder to balance knowing how much time to spend on creating new features for the existing major version, bug-fixes, and updates, versus how much time to spend on a new major release. If your internal projected major release date is off from your anticipated revenue, then it could dramatically harm the company's chance of success.

Shorterning the major release schedule to one year (as with The Foundry's Modo or Adobe Creative Suite), doesn't solve the problem, but instead magnifies the issue where the developer has to work on "showy" features, deprioritizing ones that make the core more functional and efficient.

This all generates anxiety for the developer, who wants to focus on making a clean, solid product.

-------

However, the customer's concerns are also valid. All the points the community has been making about ownership, even if a false sense of it, are important and should not be ignored. This plays very much into customer psychology.

There is no coincidence that 99 out of the top 100 daily grossing iPhone games are all free to play (the 1 premium one being Minecraft). This paradox works because they employ monetization models that very much understand the customer.

I believe the developer knew very well that this subscription/rental model was going to be unpopular, and I commend them for being up front with it by making it effectively the first thing they announced this year, as it would quickly become the elephant in the room.

To me, it sounds like the developer knows customers don't prefer it, but are hoping that it won't make enough of a difference to dramatically hurt the revenue. It also sounds like they are hopeful they can make a change to bring the plane back up if it starts to dive noticeably.

-------

I personally do not believe it is necessary to "wait and see" when we very well understand the problem and customer psychology, and can find a solution that is better for both customers and the developer.

In other words, perpetual licenses "protect" the customer and rental/subscription models "protect" the developer. There was a great GDC talk about the idea of protecting the customer, revenue, and developer here: http://gdcvault.com/play/1024183/DON-T-CHANGE-A-THING . There are measures that can be taken that protect both the customer and the developer, which in turn protects the revenue.

To do this, the company should figure out the sources of customer anxiety, and then capitalize on methods that relieve this customer anxiety. Here are a couple examples:

1. Customers hate paying shipping (or "postage & handling" as it used to be called). They feel like this is a sneaky hidden price that jumps out at you after you are already hooked.

To solve this, companies just make the price even more hidden by tucking it into the price. We know by research that a customer is willing to spend an even greater total amount if they see "free shipping" than a price + shipping. E.g. a customer is more like to pay $14.99 free shipping than $8.99 + $5 shipping.

2. Many who buy plane tickets are afraid that they may have to cancel their flight, and thus lose lots of money. Customers absolutely hate the feeling of wasting money.

Companies can then exploit that anxiety by figuring out how often customers actually do cancel flights, and then create a flight insurance option, charging well over that amount multiplied by the standard ticket price.

The whole insurance industry is based on customers paying for peace of mind, paying away their anxiety.

-------

Scirra's customers aren't bluffing when they imply they are willing to spend more than they would otherwise in order to eliminate their customer anxiety caused by rental/subscription pricing schemes.

No matter if you do annually, monthly, daily, or hourly payment intervals, it inspires a sense of pressure for subscribers to use the software, or else they are "wasting" money. I don't feel I need to elaborate on all the concerns the community has raised. This thread and others are rife with it.

The solution:

There are all sorts of interesting freemium ideas that could do very well to build the customer base, boost PR, and give the "whales" an opportunity to spend crazy amounts of money on Construct. Unfortunately, there isn't much time to revamp Scirra's systems to support some of the more effective ideas.

Due to time constraints, among other reasons, I believe the best solution right now is to keep the $99/year subscription/rental system already in place, and add a boring 'ole perpetual option/rent-to-own system.

Customers are different, and also myopic when it comes to finances and statistics. Some customers will only buy movies, paying 5 times more than the rental price, even if they watch them each an average of 1.5 times, and never resell them. Some customers pay for expensive cell phone plans which give them "free" upgrades on phone hardware every 6 months (way faster than they would otherwise), so long as they return their phone each time; and some would only buy phones (with either contract rent-to-own or bought outright), feeling they now "own" their phone they'll usually never use again or sell. Either way, the company can exploit them while making them feel satisfied.

I digress. Scirra can predict generally how many years they expect or even hope customers to subscribe each, and when they plan to release the next major version (if they plan to do so). They can then set the rent-to-own timeline to be further out from their hopeful customer retention, and even potentially in line with a distant, projected next major release.

For example, say you can foresee technology and development trends changing enough by 2022 (5 years from now), that you could see it as an opportunity to deploy Construct 4 by around then, employing the development overhaul necessary to meet the new trends.

The maximum Scirra would reasonably get from a single customer would be $500 from Construct 3 before Construct 4. Say Scirra then did a $500 pay outright, and five-year rent-to-own feature (where, any customer who subscribes at $99 per year for 5 years gets to own it perpetually).

If there was an option to continue subscribing for C3 or subscribe to C4, then it would be naive to think any significant number of customers would continue subscribing for C3 when C4 was out. I'd imagine Scirra would likely allow C4 subscribers to use C3 "for free".

All that being the case, the only way Scirra would miss out on a customer (and thus any revenue) would be if there are any customers who are so utterly shocked by seeing a $500 sticker price (which itself could be less advertised) that they would turn away, despite being willing to pay $99/year.

Any other customer of any kind would be at worst, be even with their currently proposedd model (in all practically significant scenarios).

Any customer buying outright would be a net gain in revenue if they bought in 2018 or later, for all practical predictions.

Any customer continuing to subscribe in part due to the rent-to-own dangling carrot would only positively affect net revenue even if they did make it to the end and "owned" C3.

Protect the developer: the revenue would be more consistent than C2 and most definitely greater than with a no-compromise subscription system. The developer can focus on making the engine greater, by their vision, without stressing as much about gimmicky bells and whistle features each year, or stressing about maintaining bug fixes across different minor versions (as with the "keep your most recently paid version" model).

Protect the customer: they aren't "wasting" their money by letting months go by without using the software, since they are "working toward" owning it. Open a revenue stream for those who want to "collect" tools, or the many others who are psychologically deterred by losing their sense of "ownership" in the many different ways it manifests.

--------

My prediction

I'm guessing that Scirra felt that they couldn't have increased the price from $169 (or whatever it was) to $500 between C2 and C3 without an even larger uproar and potential loss of revenue than migrating to a subscription/rental system. They would have only been able to increase the price to something like $300. I'm guessing they felt this target revenue was something they could achieve more easily per customer with a subscription service, despite any outcry.

My prediction is that they are going to "watch and see" what happens this first year, and what happens when they raise the price from $50 to $99 for the C2 owners, to get an idea of the market and how customers respond to the rental/sub model.

I also predict that a different company or two will see this as an opportunity to poach a lot of Scirra's customer base, as Serif has been doing suddenly and very successfully with their Affinity Photo and Designer product line against the 'untouchable' Adobe's customers (note the "No subscription. Just $49.99" emphasis on the front page of Affinity's products).

That pressure, along with [what I anticipate to be] a disappointing subscriber base to Scirra in a year and a half, they will be in a tricky position where they feel they need to either make the free version less free, as other companies have mostly unsuccessfully attempted, or to pivot their pricing model in a way that doesn't show weakness, as customers can smell that from a mile away (Scirra has even implied that as being part of the reason they don't do Humble sales). By weakness, I mean implying a concession that they were over-zealous with their price change from C2 to C3.

In that difficult position, I anticipate Scirra will pivot in an insignificant way to attract more subscribers (and even less likely to bring back ones who have "moved on", old C2 users or not). Meanwhile, I predict they will be considering selling the company as YoYo Games did to a private gambling company, or to a larger company who would possibly open source it. Godot for example is free and open source but is sponsored by companies like Mozilla and Microsoft. I doubt the latter scenario (open-source) would happen.

--------

There's not much material value in any of my predictions, so I apologize for getting carried away there.

I do strongly believe that there are good opportunities to benefit everyone, and that they don't need to be delayed, as they do not require much work to implement (a blog post + a couple of additional web pages/sections and form options).

Thank you to anyone who read this.

cjbruce First of all, it's a bit peculiar that you create a new thread titled "A Teacher's View", about a day after I created a thread titled "An Educator's Perspective" (). Was it too much to reply to my thread?

Secondly, I believe your thread is a tiny bit misleading. It's one thing to use Construct to develop material, and a different thing altogether to use Construct to teach material. I believe a more accurate title should have been "A Successful Developer's View: ..." MPPlantOfficial's point rings true here. Directly or not, he points out that you're a single person, so obviously it's easy to say it's a bargain.

For example, an entry-level electronics online class of ours successfully deployed a whole bunch of interactive circuit testing and building simulation apps developed using Construct 2. A C2 license was purchased for each developer, and it was a "bargain" because of how many students have successfully used the exported apps. No brainer. Not the same as teaching with Construct.

PS: our town passed a referendum that granted the public school corporation millions of additional dollars in property tax revenue. They used around $2 million of it to buy each student in each of the public high schools in the area iPads for use in the classroom and at home. After a couple years of unanimous animosity from the teachers and the students, they discarded all the iPads at a catastrophic loss. They then switched to paying huge amounts of money to buy each student 2-in-1 Windows laptops. I haven't heard how that is going.

Tom I'm glad to hear you guys aren't considering time limitations. I went into more detail about free version considerations from the context of academia here if you haven't looked at it: .

mammoth Of course sub events count against the event count, otherwise you would just have a single root "every tick" event and make your whole game as sub events of that.

mammoth

At first I assumed your ulterior motive for requesting free trial versus limited events was because the format for your udemy guides involved making game projects higher than 100 events. But then I looked at your udemy page and by looking over the games you are training students to make, they would in no way warrant even 30 events, let alone 100. So now I'm puzzled.

For all the reasons already named in this thread, a free trial is total deal-breaker for my teaching purposes. I'm guessing that other institutions employing semester schedules (read: 16 weeks) would think twice about teaching Construct as well.

From a personal stand-point, I understand the logic behind free trials, but I disregard free trials whenever I see them. I would rather just watch YouTube videos of the software being used or read comparisons to software on message boards. I often like to download software and try it briefly, putting it on the back burner until I get another chunk of free time to keep trying it, and that can be weeks or months later. I imagine I'm not the only one, especially if I were a student trying out many different engines at the same time over the course of several months.

Like one of the major problems with software subscriptions, free trials create a sense of pressure in the user to use it "or else." This tension leads to a dissonant user experience. The "or else" should feel positive, not negative, when incentivizing paying for the full version.

As a short background, since 2013, I've taught around 300 students Construct 2 in workshops and semesters that were each no shorter than 40 hours of class time. My Construct 2 use has spread to other parts of the institution, where it is taught in other classes and even used to build instructional simulations in online classes. The tool was originally chosen for a few reasons, the primary one being that its event sheets were among the most intuitive gameplay building tools at the time (and still).

Construct 3 appears to be around the corner, and even though Construct 2 more than suffices for our needs, there is a persistent pressure from students and elsewhere that we should be using the newest version of all of our tools. This puts us in a curious position where if Construct 3 does not meet our needs, then we may feel compelled to abandon Construct all together, even if Construct 2 is better than any alternatives.

The shift to browser-based

Putting Construct in the browser is cautiously good news for us. One of the major challenges we have had is supporting students who prefer to use Mac computers.

To solve this problem, Construct 2 is installed in an online Windows virtual machine service available to all our students. This means that students can log in to the online service using Macs, Chromebooks, and even iPads to use Construct 2 streamed from supercomputers running instances of Windows. This solution actually works almost seamlessly. The only issues are that there is occasionally a rendering bug with TiledBackground objects and passing files between the service and the local drive can be tricky to set up.

Having Construct (i.e. Construct 3) in the browser would make the student experience and troubleshooting much more consistent. In fact, the WADE game engine, which runs in the browser, was chosen as the primary teaching tool in one of our classes partially because it being in the browser simplifies logistics.

However, browser-based game engines in the classroom have other caveats, which can be deal-breakers. We can break this down to assessment and privacy.

Assessment: to grade student work, the student must have a relatively painless way to download his or her project files, and the instructor must have a relatively painless way to open those project files. Sending a link to an online project does not count, because the instructor must be able to verify that the assignment was completed by the due date. Otherwise, it would be unfair if some students could keep working on their projects while their peers' projects were already graded.

Wimi5 is a game engine we were heavily considering for one of our classes, but ultimately decided against it mostly because there appears to be no way to download project files. I'm pleased to see that Construct 3 should hopefully not have this problem, assuming the free version does not bar the user from downloading project files.

Privacy: to ensure standards of academic honesty are secured, the free version of the game engine must allow projects to be private. Otherwise, fellow students could find the link to other student projects and plagiarize at best, or sabotage at worst.

PlayCanvas is a game engine that was being considered for a class, but the idea was dropped because the free version did not permit private projects. To my knowledge, information about the free version of Construct 3 is not yet public knowledge. We are hoping that the free version does not limit users to publicly viewable projects.

Free version limitations

We have been using the free version of Construct 2 in our classes, where students who want to continue their projects outside of class often purchase personal licenses to continue expanding. In addition to the baseline requisite where Scirra continues to permit academic institutions to use the free version in the classroom, there are other free version considerations.

For us, the 100 event, 4 layer, no Z-order bar, no object families limitations have worked fine. If Scirra is considering other means of limiting the free version, then here are the common ways companies limit the free version and what it would mean to us.

Free trial: 30-day free trial, or any other form of limiting the amount of time a user may evaluate the product will absolutely not work for us for many reasons, not the least of which is that semesters are more than a month long.

Splash screen: watermarks, splash screens, and branded loading screens would be fine for us. If student prototypes are too "embarrassing" to show on their portfolios with splash screens, then they can pay for a license. However, a splash screen could make us think twice if it appears every time we test a game, and it stays visible for 5 seconds or more. This is because in teaching material we often try to quickly show differences between various options and mechanics for demonstration purposes.

File limitations: FL Studio free prevents the user from saving progress, and Reason free prevents users from opening projects. Any saving, loading, importing, or exporting limitations are most certainly deal-breakers for us. The only example I can think of quickly is limiting export targets. If the free version can only export to web, then that limitation would work for us.

Commercial use: since this is all for educational purposes, barring free version users from selling their exported projects is entirely fine with us.

Privacy: as mentioned above, preventing free version users from having private projects is a no go for us.

Feature limitations: as mentioned above, the Construct 2 feature limitations work fine for us. If Scirra adds more feature limitations, then we'd have to evaluate each case by case. For example, if there was an object instance limit of 20, then this would be a deal-breaker. If there was a behavior limitation of no more than 2 or maybe even 1 per object, then this would probably be fine for us. If layout size was limited to 2048x2048, then this would maybe be fine for us too. Again, we'd have to consider each.

Subscription Model

Assuming we are permitted to continue using the free version in the classroom, this won't affect us as directly.

However, students and even instructors who may want to use Construct 3 outside of the academic setting can influence to some degree whether or not we use it. As an extreme example, if the free version was fine, but the personal edition was $10,000, then we would probably not use Construct 3, because it would be considered ridiculous for anyone trying to apply their Construct knowledge outside of class. That said, when I announced to my class of ~45 that Construct 3 was going subscription-based, a universal and fortissimous moan erupted. I believe Scirra expected this, otherwise they would not have planned their release strategy as they have.

We were considering the $370 per year academic institution site license for the sake of our longer senior project series of classes, but the $40 per year per concurrent seat revision has stymied that idea. Since there are cases where we could have over 40 concurrent users, we wouldn't be able to justify the over 4-fold increase in price, especially since most seniors choose to use Unity or Unreal for their capstone projects. This also further fortifies our likelihood of abandoning Construct if Scirra ceases to allow the free version being used in the classroom.

Programming

You may have not expected this section. I won't dilute this with any other feature requests, because none of them are anywhere as useful to me as the ability to teach programming more directly.

One of the core classes in our program is an introductory game programming class. Construct 2 is used in the first few weeks to convey basic game engine concepts, such as sprites, state management, instances, and so on, while simultaneously plain JavaScript is taught to get the students used to core programming fundamentals and syntax. The class then transitions to teaching programming in a different game engine utilizing scripting, converging what the students learned about plain programming and game engine concepts from Construct.

The class has been taught three separate semesters with extremely positive reception, ranking at or above the department average in all categories. I've wondered how it would be interesting if only one game engine could be used across the semester—a game engine that possesses both intuitive visual scripting and also a programming option. The Construct 2 SDK was considered, but not only is the learning curve too steep for the transition, but programming with it is disjointed from the editor. There are a few game engines that have both visual scripting and programming support, but none seem to be quite there with either or both forms of gameplay scripting.

The identity problem: Some claim that students switch to engines like Unity because if they fail to produce a game, they at least obtained programming knowledge applicable to other engines or even computing fields. I've overseen enough students and met enough game developers that I'm fairly certain it is actually much more an identity problem with the engine.

There's a certain amount of embarrassment students carry when they say they are making a game with a visual scripting engine such as Construct 2, even if they are design students. Engines are no longer a means to an ends, but rather the ends themselves. It's gotten bad enough that students would rather not finish a game being made in a programming engine, than to suffer the embarrassment of completing a game in an engine made for "babies". Appearances are practically everything to undergraduate students, at least in my part of the world.

Even among non-students I meet at the GDC do I feel the heavy shame in another dev who confesses they are making a game in Game Maker. Construct 2 at my institution and elsewhere is perceived as merely a prototyping tool, because it isn't "serious" enough for professional developers, not even because of a lack of features or performance.

There is no quick way to change an engine's reputation, let alone the perception of an entire category of engines. However, creating some form of manual scripting integration can make ground toward shifting perception. For my institution at least, it could enable upperclassmen to consider it as a "legitimate" game engine for their capstone projects. I for one would like Construct to graduate from being merely a teaching tool.

Other improvements

I have used Construct 2 in the classroom for a very long time, and could produce an exhaustive list of the little rough unintuitive edges of Construct 2 which cause blips of confusion in the student's cognitive stream of learning the engine. However, I'd save that for a different post if I get around to it.

I apologize for the length of this post. I hope at least one of you read it =).

Another bunch of suggestions for Construct 3:

• Include Nape Physics engine beside Box2D
• Vector graphic objects beside sprites - Like in flash, with outlines, points and curves... Also shape-tween between key frames could add a lot.
• Some kind of Timeline - it could help to add cutscenes, intro animations, and much more without using too much code.
• Layers in image editor
• Possibility to add multiple object types (Text, Spriter, Particles... ) in one family, and of course when you addressing the family, you only could call mutual actions of those types (Set angle, set opacity, etc...) and family behaviors...
• Add option to add JavaScript code in "Add action" section, in a simple text editor, instead of in Browser>executeJS in a small window by using lots of escape characters (because all the text should be in quotes).

I second

• Better tweening support (as in your timeline suggestion). Could even just have a tween behavior, such as LunArrays plugin.
• Better container or object parenting system.
• JavaScript eventsheet action.

This bug makes C2 very frustrating with a 4K screen. I don't want to force 1080p each time I want to use C2, and 100% scaling on a 15" screen is not for human eyes.

It looks like there are more and more 4K screens on the market at this size.

1. Please create a sub-forum for Construct 3 so that we can take our excitement there =P.

2. Please create a pre-order crowd-funding page. You don't even have to create a dolled-up Kickstarter kind of page for it, because you'd probably get hundreds of orders from your fans even with a GeoCities-looking page. Just add a slide and page to the construct3.com site. That extra cash couldn't hurt for your dev, could it?

Prominent

Hmm... that's an interesting idea; I hadn't thought of that.

The advantages there would be 1. the students could make more ambitious and interesting projects (and most likely more entertaining for them); 2. the JS and programming syntax they'd be learning would not be confused with proprietary engine code. This means that their JS and programming knowledge could be more portable for other contexts.

My concern with this though is that the students are not technically doing any game programming in a Game Programming course. That might make it harder to get the idea past advisory committees, as well as easily disappointing a number of students I'd expect to be coming in with a few CS classes under their belt, looking to do "true" game programming. I would want to think of a way to address that (if you know programming, you are free to use the SDK? Nah, that could get hairy, quick).

I am in the process of setting up a 16 week college course introducing game programming. Here are the expectations:

1. No pre-requisites

2. The students will learn JavaScript, in the context of game development

3. The class has to be as non-intimidating as possible, as an attempt to attract and keep students who aren't sure about programming.

I have been brainstorming for a while now, and I am having trouble making these expectations compatible with each other. It is hard enough to illustrate the concepts behind game programming to one with no prior programming experience in a single semester, let alone make it a welcoming game-building experience.

A thought I had was to use Construct 2 events at the beginning of the class, concurrently teaching basic programming language constructs (variables, control structures, etc) in JavaScript. Then halfway through, I would transition to using JavaScript in Construct 2.

Of course, the problem is that I fear that Construct 2 may not support such a seamless transition. I know that Stencyl allows the developer to switch from the visual scripting view to code view on the fly, even permitting the developer to hypothetically write the whole game in HaXe (similar to JS). It would be awesome if Construct 2 had something comparable, something like a code view that eliminates as much peripheral boilerplate code as possible, leaving only an intuitive JS-syntax event, conditions, and actions sandbox. A best compromise could work.

Any suggestions?

How would I attach a revolute joint to two different instances of the same type?

This question also applies to many other actions where two different instances of the same type are on each side of the action, e.g. pinning same objects of same type, etc.

Thanks