Well you are welcome to your opinion but before Clickteam was even around there were game engines packing coding into easily called routines that are events.

Trying to claim one is the grandfather is pretty ridiculous in my opinion. They are all extensions of BASIC and MS-DOS and other languages.

Basic and dos did not have an event sheet.

You seem to not be getting my point about visual programming at all - nobody claims that clickteam invented game engines or programming languages.

http://media.moddb.com/images/engines/1 ... 86_003.png

this is the event sheet in klik and play

• the left column is conditions, the right is actions

it also has the event editor

http://www.clickteam.com/creation_mater ... /sshot_(17).Png

You add them to cells by right clicking and selecting items - just like construct

this was created long before construct, but construct perfected it with the event sheet - by adding sub events and replacing the tick marks with event editor type cells. Scirra also added proper functions that take parameters in place of fusion 2.5's limited fastloops.

Clickteam has now made it so you can switch to event sheet mode in fusion 3 - similar to construct's. Also added sub events and functions that can take parameters

http://www.clickteam.com/wp-content/upl ... ntList.gif

http://www.clickteam.com/wp-content/upl ... Toggle.gif

http://www.clickteam.com/wp-content/upl ... 52x264.png

They have remade the entire fusion engine from scratch to modernize it

They have also added some tricks to code reusal that remind me of how godot handles scene inheritance

A little history of game design software:

Early game creation systems such as Broderbund's The Arcade Machine (1982), Pinball Construction Set (1983), ASCII's War Game Construction

...

https://en.wikipedia.org/wiki/Game_creation_system

Clickteam created the event sheet - visual programming via an event sheet - they did it in the 90ies with Klik and Play.

Reusable objects that populate the event sheet

>

> I assume he meant Fusion 3.

>

>

>

I wouldn't say Fusion is the grandfather of 2D game engines sorry.

It's not the grandfather of 2d game engine, but it is the grandfather of the event sheet that construct is using - and visual programming in general

Heck, ashley even wrote plugins for it prior to creating construct.

Clickteam devs got upset when construct came out- with the obvious similarities. They got really butthurt and still are. This time around they are coming out with an editor and engine that takes care of all of the reasons people moved away from fusion to use construct .They have even stated on their forum that they will later this year reveal news about fusion3 that will make construct users happy. So you can see that they know about construct and are actively competing

Out of the three Godot is the one that is actually most powerful, but it is also the one that requires more investment of time to learn.

With the changes Juan added to gdscript, the language has become piss easy though- you can make a platformer movement with animations and input in about 40-50 lines of code.Godot devs don't give a crap about any of the other 2 engines, they just keep adding and fixing stuff

We can talk about it, but things will be most obvious when all three are out and about.

I believe that all three will be successful in their own way - construct3 may be driving away some users due to the licensing and the cloud, but in the process it will acquire new users that like that kinda stuff

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

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.