blurymind's Forum Posts

  • Scirra has an engine that does have advantages over other engines. The editor is incredibly intuitive and it is a great entry point for anyone who wants to learn programming theory.

    Its event sheet is probably the best implementation of visual scripting in an engine at the moment.

    I do like the awesome new features in construct3 editor that are revealed.

    That said, we should not stop ourselves from discussing the pros and cons of other existing engines.

    Let us not close our eyes at what awesome stuff is out there!

    When people start talking about godot for example, I will say what features it has and wish construct3 gets, but also note the downside that can be potentially a stopper for many users here - the need to learn the scripting language and read the api reference - regardless of how easy that actually is. I also noted that its approach to visual programming (which is optional) is bad imo. That spaghetti node stuff is only good for state machines.

    I think it's actually good if people talk about other engines, because that gives developers example material and input that might be valuable. Some plugin contributor might see a discussion about another game engine and say- hey I bet I can make an addon for construct that adds that!

    It is however against the forum rules to directly promote moving to another game engine. That would get the thread locked

    To chip in the discussion of performance on mobile - engines that compile native apk do not need wrappers, so the html5 export in them is not really targeted to be put in a wrapper. The developers would just export a native apk/exe without a wrapper- thus get a better performant game that has a smaller file size and none of the problems of the wrapper one. The html5 export is then strictly for targeting web browsers- games hosted on websites. That is still very useful if you want to put out a demo with zero setup requirements.

  • blurymind

    I am currently teaching myself Godot, and Godot's basic architecture using nodes is - dare I say it? - beautiful. The concept is very well thought out, and ideal for game development. Not only that, the one thing missing for me in Construct 2 is the lack of a decent "animate all" timeline. Godot has it. And so many other things.

    Also, I just love how I can use Blender to animate 2d puppets, and the IK and animations are directly supported in Godot. And render 3d models to 2d sprites. Wonderful.

    It might be one of the best 2d engines out there currently - but visual scripting is not part of it (yet). They are working on it, though. It's stunning that Godot is open source and free. But you are correct: Godot's language is easy to pick up.

    I am unsure whether Scirra's decision to switch to a browser-based editor and completely rewrite it was such a good idea, but we'll see what we'll see. I keep saying I won't be part of it, because I am still terribly disappointed about their decision to go rental-only, and it really is a crying shame. I'd rather have preferred real improvements to the editor of Construct, such as a built-in animate-all timeline with graph editor control.

    Luckily, with all the (free) alternatives currently available to 2d game developers, I certainly am not worrying about the future. Frustrated by the Scirra's rental model, though.

    Godot 3 is coming on the horizon too you know - an alpha will be available in april <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing">

    Juan (main dev) has been simplifying gdscript even more there - adopting ideas from game maker's gml, but still keeping the compatibility. The feature that most people are most excited about is the modern rewrite of the 3d rendering engine. I am personally excited about the inclusion of a spine2d like animation editing in godot3- with 2d mesh deformation.

    Imagine spine2d being included in the editor- for free.

    Right now gotod can already animate - right in the editor. However it only supports cutout animation. If construct3 had a built in animation editor with 2d mesh deformation support - I might buy that license. <img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Surprised">

    Godot has visual scripting approach that is optional and is loosely based on the design of blueprints in Unreal. I personally do not like it and prefer to use gdscript, but that will perhaps start to change as they improve it.

    But to improve it, people need to use it and submit feedback and reports to godot's github tracker!

    I wanted to mention it in regards of ashley's bold statement that construct has more features because it exports just to the web. <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing"> That is simply not true. Construct has a good visual scripting event sheet and a nice editor. But it is beaten in features by many other popular game engines (obviously unity and unreal there too, but also game maker) and all of those export to native.

    Godot is quickly becoming popular, but as said before - you have to sit down and learn some python if you are serious about learning gdscipt. Gdscript looks very much like python.

    Coursera actually has an excellent free course here:

    https://www.coursera.org/learn/python

    It is the best introduction to scripting that you will ever get imo and very quick to complete.

    Godot's documentation and tutorials are also abundant.

    In any case, I would love to see python like scripting in construct3 for plugins, but it looks like it will be using javascript.

    I love python's syntax because it is clean and simple. Java script blows up in your face if you miss a bracket somewhere and has got some weird and annoying caveats, but am trying to learn it as well..

    btw today clickteam announced that Fusion 3 will not only export to native platforms, but it will also be able to export to html5

    http://www.clickteam.com/fusion-3-devel ... ?f3id=8904

    They are taking the approach that godot is using for exporting native code games to html5- using emscripten

    [quote:3f6scvia]Emscripten is a source-to-source compiler that takes something called LLVM bitcode and spits out javascript. Basically it allows us to compile Fusion 3 made games into javascript based games/apps with relatively little effort and with very high performance.

    Won’t C++ compiled to Javascript be slow?

    Not really. Emscripten compiles to a subset of Javascript called “asm.js”. It is basically fully valid javascript but since only a specific subset of it is ever used it allows the browser to do some very aggressive optimizations on the code and even on-the-fly compile the code to native code for the platform you are running it on. This means that even though your game/app will go through a Javascript step it will “just be a phase” so to speak.

    Pleople will still have the option to export to native android,win,linux,mac,ios - so no need for wrappers. If you however just want a web app/game - html5 is available. A lot of the other big game engines seem to be using emscripten for html5 export - Unreal and Unity included!

    To put some light on the name of this thread - you should not be worried about the future. We have never before had it so good in terms of choice and quality of game engines. There is something for everyone <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    The future is incredibly bright!

  • I never said C3 must go opensource after those "5 years", only that it could go to normal license, provided that Scirra has moved on to new versions for main income, so to say?

    It is normal for old versions (and there's newer versions) to get cheaper so this might be the way for subscription software that get old and replaced with newer versions, these could get new type of license..

    But yeah, it is really up to Scirra this whole thing.

    If it goes normal license, the developer is still maintaining it.

    Open source means that the community is invited to commit code to the project, fork it, add new features and bug fixes. That takes some work off the shoulders of the developer, however you still need to have someone who knows the engine well to review the incoming patches. That is another thing open source projects can't succeed without - a maintainer/lead

    There is a clone of construct that is open source called gdevelop, but it has only two semi active developers. Being open source doesn't guarantee big community contributions and that project has seen very slow progress over the years, regardless of some of it's recent success on kickstarter and porting to native android. It has much less features than construct and its editor is still somewhat more unstable/clunky on some platforms.

    The very actively and feature full game engines tend to be the ones that used to be proprietary for years and used in industry, but have been open sourced- like Unreal and Godot for example. Their dev scene is very very active and a lot of experienced devs actively contributing to those engines. Why they decide to go with godot over something like gdevelop? They probably like the code base better and dont care much about the visual programming part.

    After learning some gdscript, I have to say that once you figure out how to read the api reference and have learned a bit of basic python, scripting in godot is pretty much easier than even visual scripting in construct2- as it is more predictable. It however requires more investment and patience. Godot has many nodes, or premade behavior/game objects you can use - just like construct2. It has actually much more built in functionality in the runtime than construct2 and clickteam put together. You can even parent objects to other objects - even parent scenes to other scenes. I believe clickteam is going for that design approach for fusion3 as well. It is incredibly powerful and flexible. But to use that stuff, you have to learn what the magic words are and how to address nodes. That means actually reading the api doc.

    With unreal you have blueprints and literally connect nodes, but I hate that kind of approach to visual programming. It just wastes so much empty space and can turn into spaghetti. Construct's event sheet is much more elegant. Unreal however is a better engine that supports more platforms natively and again leads in features - especially if you wanna make a 3d game, but dont wanna write code

    When you are doing visual scripting - be it construct, fusion, stencyl, unreal or some other engine - you are still programming. I would actually argue that construct2 is a great way to get your toes dipped in the stuff - because it can help you learn some fundamental concepts such as variable scopes and functions. They apply to most programming languages you will learn in the future. So my point is- dont be afraid of writing code. try to learn it anyways

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • With open source, basically the people who use it have full access to it. If there is something they don't like in it (such as DRM or limitations imposed by design), they can disable it.

    If there is a feature missing, they develop and add it, or hire someone to develop it.

    Open source projects such as blender and krita have been incredibly successful recently.

    The blender foundation is doing quite well at the moment - and is able to hire quite a few full time developers even.

    But they have worked to get there, creating a foundation and running it. Simply releasing the source code is not enough to make a project succesful or get it to point where it is making lot's of money.

    Tom

    Take Unreal as an example if you will. Unreal 4 is open source, it's free to use and it's huge. The developers made it open source, because that way they allow devs to get in there and help them make it better- contributing code, learning the code so they can fix bugs. But they are still charging for the engine businesses. If you are selling a game that was made with it - Epic takes 5% of your profits. That is their moto

    [quote:33q27jvn]Pay a 5% royalty on games and applications you release. We succeed when you succeed.

    https://www.unrealengine.com/what-is-unreal-engine-4

    Being open source does not necessarily mean that the engine dev makes no money. On the contrary, if they know how to play their cards, they make a lot of money and have developers and users maintain it for free for them.

    But as said before, you can't just release the source code and expect it to thrive. You need a well documented code that new devs would be thrilled to contribute to. You need some funding to make it popular- by doing actual projects with the engine- that advertise it's capabilities.

    Godot devs are also a games company, they have been using their own engine on many games, on many platforms (consoles including)

    https://okamgames.com/

    The blender foundation has been doing open projects every year- to both push the limits of blender and advertise it.

    Recently gdevelop dev made a very successful kickstarter game ( http://compilgames.net/#bub-game ) - both to get some funding for his engine, but also to push it to the limits. In order to get a better performance for the game, he had to move his entire core to cocos2d - allowing him to export to native android for that game.

    krita devs also have been relying on kickstarter campaigns every year for funding:

    https://www.kickstarter.com/projects/kr ... rt-awesome

    That way they managed to add animation features and now vector features as well.

    The successful open source projects are active projects, being run by a foundation with set goals and healthy communities. There is constantly something made by their community and devs. The devs are the community. If the project dies, that means that there is probably not enough interest in it. Construct never had a problem with that - it has always had a huge amount of interest.

    I know it's not likely that it will ever go open source, but I just want to point out that even microsoft is going open source with a lot of things nowadays. They have been doing so, because they see that it is good for their business

    One thing that could be considered is releasing a part of it as open source, but putting in optional web services that are not free.

    This is what Amazon did exactly. They bought the cry engine, added their web services to it and open sourced it - called it lumberyard.

    https://aws.amazon.com/lumberyard/

    Their goal is not to sell the engine, but sell their service! The engine being open source and free is the lure. Developers like open source, because it is flexible. They can tailor it to their project better. A company that is really interested in selling web services and has something special to offer to devs gives access to the engine for free and sells the services around that. Isn't that what Unity is doing as well?

    Even King has released their engine for free (but not open source):

    http://www.defold.com/

    With them I am not sure what the deal is. I think that they are interested in becoming an indie games publisher, however the indie community has not much trust for them atm because of court cases they had for the "saga" name with an indie guy. King claims that they are making it free with no attachments in order to get more people to test and use it - help them make it better.

  • If scirra drops support for it one day, you will simply not be able to use the editor on any of your game projects- even if you want to pay.

    The dependency on chrome is another factor altogether

  • We all know of the incredible community made plugins here- a lot of which free.

    rexrainbow has created and supported many very useful addons. He had to write his own plugin manager and repository - because scirra does not have one.

    We also have the scirra store, but that is in no way integrated with the actual editor.

    -Will Construct 3 have an official built in plugin manager, one that gets plugins from a repository and imports them to the game project in one click?

    • Will scirra have a process through which users can upload and update free and non free plugins to scirra repository (will scirra have quality control)?
    • Will all the current construct 2 plugins be compatible with construct3?
    • Will construct2 users have access to plugins written for contruct 3?

    A question to Tom and Ashley

  • What about having a basic plugin manager in construct3 - and a repository for the excellent work of REX and other contributors here.

    Is Ashley willing to officially support those plugins?

  • > However, remember that there is also an offline version which will continue to work.

    >

    Scirra still has to confirm this. Right now they said that you won't be able to edit your projects after your subscription ended. I think that goes for the offline versions as well.

    That should be enough of a reason not to buy into it. It makes the investment very shaky

  • Software comes, and software goes. There are no guarantees that software will be supported long term.

    However, a rental model does have the disadvantage that if the company goes under, or decides to discontinue a product, developers run the risk to be stone-walled in the middle of a project.

    Point in case: Adobe announced a couple of weeks ago that Director development and support will be ending sometime in March. Existing rentals ("subscriptions") will be cut off at that time as well.

    Developers on the Adobe Director forum are not happy about this (understatement) - for example, one developer is in the middle of a project, and it will take him longer than March to finish. Others have projects done for clients (museums, for example) that must be maintained and updated after the March date.

    Unfortunately, those developers who rented the software seem to be out of luck. They contacted Adobe, and asked for some lenience. But they will lose access to Director and with it lose access to their projects sometime this year.

    Director first entered the market in 1985(!). The oldest surviving 'multimedia' producer is now dead. There are no guarantees for software survival. But Director users with a perpetual license may continue to use the software to open their older projects - renters ("subscribers") are at a distinct disadvantage in these type of situations.

    I agree with Rayek on this one!

    That paid subscription model - quite on the contrary guarantees that one day you will no longer be able to open your game project. History has shown us many times - users being left out to dry

    It does not in any way help your project or you. It's there simply to lock you on continued payment, regardless if you actually make money from the game engine or not or need to update it for new features.

    I would be ok if the rent payments were so that the engine gets new features. But they really aren't - the developer can then continue charging you simply for using the software. Once they have enough users locked to that model, they will no longer worry about meeting any feature requests - as pressure on their side to improve the software so people buy the update is gone.

    One day when they decide to drop support for the software, even if you want to pay rent- you will be locked out of the house - with all of your stuff still in it.

  • I have a galaxy note 10.1 , however wont be using c3 due to the licensing type

  • Good question

    A performance comparison is in order - sooner or later.

    XDK/nodejs VS construct3 exporter

    > The problem is the payment model and the investment it asks for- doesn't justify a html5 only game engine. Even stencyl - which is very similar in pricing and target audience (perhaps inspiring scirra) can compile to native games and can still export in the free version to one of the targets

    >

    Construct 2 has so many more features than a lot of these other tools, that I'd actually struggle to make a comprehensive list of them all. This is made possible by the fact we use HTML5. It makes cross-platform support a breeze and lots of sophisticated features like networking, audio and video support are provided by the browser. Some tools don't even have form controls out of the box! When comparing to other tools with different technologies, I think it's important to take in to account the actual feature sets supported. Sure, you can pick a tool which has native export for example, but how many features will you lose or gain?

    I think you will have quite a lot of trouble making a list that justifies that extraordinary claim of it having much more features

    Just looking at the number of games made by construct2 on the market - or any other pure html5 game engine alone should be proof enough to anyone that it is certainly not a popular choice of serious game developers. Most games on the market are native code. Even the mobile stuff.

    the only reason you make the engine purely html5 is so that you don't have to do as much work creating exporters and supporting them. less work for the game engine dev, but not for the game dev using the engine.

    Most of the community on this forum has been unhappy by how poor the export to apk/exe is - how inconsistent the game plays after you package it with a web browser in the apk, how much more extra space it takes being bundled with a browser

    Meanwhile other game engines - some of which free - offer much more features than construct2 + native exporters +html5 export.

    Godot for example is excellent and has you beat on features and architecture for free - but you gotta learn its scripting language/api. Let's not even mention Unity3d and Unreal. Whats the point even.

    The only advantage of construct is the event sheet that makes it look like no programming skills are required. This is the honeypot that attracts new users as it lowers the entry point bar to non programmers.

    I think you know that very well, as your focus with construct3 was the editor- wasn't it? make it more userfriendly, forget about new API functionality or improvements in the actual runtime. Perhaps some of the weekly updates will prove me wrong - but so far scirra has made it's focus clear - user friendly editor

    With that subscription fee model, you are essentially raising that bar back up there on the hobbyists

    Please share with us why people should rent construct3 for a year, instead of downloading the unlimited events+flash export free editor of stencyl- developing a game in that instead, and finally buying a sub from stencyl when they are very invested not only in the engine there, but also in the game they have been developing in it.

    A free editor with no event sheet limitation and at least one export option for testing is something that will get hobbyists invested in the engine, the more developed their project - the more invested. That will then get them to pay for a subscription/exporters.

    The sub fee announcement prior to demonstrating value was like proposing an engagement ring on a first date. Hey, they are plenty of other fish in the sea - also being so pushy is not attractive on a first date

    And if my aim is to make money with games, then 99/year is downright laughably cheap!

    That's my two cents.

    Has anyone on here actually made money from games they created in it? I would love to have a look at some statistics of users who use it as a hobby vs users who make money by selling a game they made in it.

    You say it's cheap, but most people, even those who can stomach going rental are pleading for a lower price for first year, more free features or a one time payment offer combined with rent. In the end we can be cynical and say - well yeah- of course they will.

    I dare to say that I can afford paying a rent for it, but still think that it ain't worth it. I just don't use it often enough to justify paying yearly and I guess I will use it even less now.

    The problem is not the price. The problem is the payment model and the investment it asks for- doesn't justify a html5 only game engine. Even stencyl - which is very similar in pricing and target audience (perhaps inspiring scirra) can compile to native games and can still export in the free version to one of the targets- without silly event sheet limitations or network limitations

  • The exporters are not built in though, they are on a server

    That is actually the very opposite of what this petition thread is requesting.

    I guess when people say "built in", they dont care about where the feature is (the cloud), what they really mean to desire is an exporter that was made specifically for construct - even if it was made with the same technology that they have been already using on their construct2's built-in exporters - only NOT built-in c3

    The irony of what is requested, how the request is met and the community's reaction just amazes me

    I guess in the end the whole point is to make the export process a one click effort

    The subscription fee payment model seems to be the single biggest major issue that people have with Construct3.

    Scirra will not know if it will have a positive or negative impact on it's revenue until the first year after release. In the end it is really up to the users to make or break the jump by voting with their wallets.

    We have done our best to voice our concerns in a civilized way. Best of luck to Scirra. They are damn talented, but so controversial some times