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.
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.
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.
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.
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 =).