— summed this up very nicely.

jbr190 ... ... your argument is flawed. Just because you are using code to make your game, doesn't mean you have to make everything ground up. .. and what, you think you are smarter than the guys who made fez, aquaria, starbound, super meat boy, spelunky, dustforce, and braid? The only game in that list that you can make in construct without coding is... ... ... none of them, you can get close, and make less polished approximations.. . Also, the only time event scripting is faster than straight up programming the SAME exact thing is when a non-classical-coder-programmer tries to compare the two and concludes event sheets are faster. Don't get me wrong, I'm a visual kind of guy and prefer event sheets, but I won't try and say they are faster. As to this statement: "I come up with crazy ideas and there is always somehow a way to add them in C2." I can safely say you may think your ideas are crazy, but they aren't pushing any envelopes (mechanically speaking)... No offense, but construct 2 is only good at implementing typical games (mechanically speaking) unless you delve into the sdk (traditional code!). There is no way, for one thing, you could get anywhere close to adding collision detection and resolution for a physics system using events sheets. That would end up like a redstone computer in minecraft, lol.

And behind all of what you do in construct is an amazing programmer in a traditional code environment. You can just as easily stand on the shoulders of giants regardless of whether you choose to program in visual event editors or traditional code. But currently, in general, the coding environment usually affords more power and flexibility. Once you know it inside and out, it's faster too. In the end, I like event sheets because I can stay focused easier and don't get lost in a sea of text, but they still are weaker. That may change. I am sure someday we will have a grand visual coder with all the power of lower level languages... but the advantages of an event sheet. anyway...

— - Sorry, I noticed that English wasn't your first language after the last post (or assumed... you speak Portuguese as the first language? ) Sorry I assumed English was your first language, it wasn't fair of me to pursue the argument as intensely as I was.

But I really don't want to change the event editor unless those changes keep in spirit with c2. Construct is a real gem, among the many pebbles that are other game engines.

rexrainbow - Yep. It just isn't clear what issues are being addressed. Though the talk about making plugins via events is super cool sounding!

— Games - ...I see you like to have opinions. Me too... but I like to be able to discuss why I hold those opinions. What's my point? please refer to the above posts. My point(s) have already been stated. You have failed to address any of them except to basically disagree without evidence as to why.

"I only just wonder what is your point? If you prefer writing code, then you are free to use a framework, where you can code. I mean, the point about C2 IS the event system." - — Games

My point: "construct 2 is faster to create objects add behaviors, and get a project up and running. Those benefits outweigh the downsides in a simple project, but as the size and complexity of the project increases, the cons outweigh the pros."

My Preference: " I would prefer to use visual scripting, like c2, because I have a much easier time simply glancing and knowing whats going on"... However... refer to above quote.

"Sure, there are things to improve and that could be made better in future releases, but if you put too much in it then all the philosophy of C2 is getting lost...why should C2 turn into some Unity 2?" - — Games

Obviously there are always things that can be improved, but the likelihood of something improving without some good discussions about it... well, that's why I made this post. I don't see how improving the workflow and efficiency of construct will destroy the philosophy of construct. I also don't see how this will turn it into unity. Nice slippery slope.

"Because Unity we already have and it's ready to use. C2 is meant for easy, rapid & uncomplicated game making and you can make big projects with it, but sure it must be in a relation to the engine." - — Games

Above, you state that, "the point about C2 IS the event system." However, you also say c2 is meant to allow "easy, rapid & uncomplicated game making". I think they are both part of the c2 "philosophy", but that the event system currently gets in the way of "easy, rapid & uncomplicated game making" when a games size exceeds basic arcade style games. The actual engine behind construct can support way more than the event sheet can support. In respect to " easy, rapid & uncomplicated game making" I am suggesting these things be discussed.

"I like what people trying to do and to achieve, but a complex RTS or MMO is maybe not in the scope of C2, but a great arcade adventure like Metroid or a Zelda like adventure game is possible for sure & games like this are really huge projects for the most people here. " - — Games

I agree, I have the utmost respect for the c2 community and what they are achieving. However, the original mario is simpler than metroid or zelda... and it is "possible" to make it... but please refer to the above post. There is no way on God's green earth you can make either metroid or zelda or mario without either 1.) using the sdk and CODING... or 2.) using event sheets way beyond the practicle point (you know, where you are trying to do collision detection and resolution )... At this point there still isn't a good way (fast, easy, uncomplicated) to handle dialogues in Construct without using the sdk, which is super important in a game like zelda. Programing it is... easy.

1.) coding is currently faster (objectively speaking) than using the event sheet to do the same thing (assuming you know how). The event sheet also has a performance loss.

2.) because you will need to rely on the sdk, for reasons stated in earlier posts, especially as a game gets more unique or complex or large (not just bigger levels), you will end up coding in coding in c2. But c2 is supposed to be about the event sheet!!!

3.) The sdk sucks.

1 & 2 & 3

Therefore:

C2 needs a better event sheet environment that can address problems raised in earlier posts...

and / or

C2 needs a better environment for coding...

But because it has neither, c2 is not suitable for large projects... as it is no longer easy, fast, and uncomplicated...

Colludium , Okay, I'll send the code in the next few days when I get time to do it. (probably tonight). Let me think on the joint/force/ stuff. I can't recall how box2d handles this. I know you can apply a force at anyposition though... (I think it is defined in local coordinates though).

Colludium - I can help you here. There is no problem that I have found in ams.js with kinematic bodies, so that should work great.

What I can do for you is send you the code needed for runtime and edittime. You can simply copy and paste it into the stock behavior, or you can copy the stock behavior, rename it something else so you get no conflicts, and then paste it. Each has it's pros and cons. (I can tell you if you don't know what they are).

I could also just do this myself and then pass you the behavior. You would just have to copy it to the correct file location.

I won't provide you with a property you can toggle in the editor, because... its complicated. Its not a problem to do, but if I do it in a meaningful way, you won't be able to have it with the stock behavior as it would break existing projects. If you don't care to incorporate this with an existing project, I can add the toggle but it takes more "work" and it's not as easy to add to subsequent releases of physics.

Any object that you want to be kinematic from the getgo, you simply do: OnStart of Layout - Physics: setBody Kinematic.

It may seem complex but I promise, its not. I used to use the workaround you mentioned but you are right, velocity and stuff doesn't work right. and then I realized, box2d is really straightforward to work with. The hard part of adding it is, knowing javascript and understanding the construct 2 sdk. I originally added it without understanding any of the last two, lol. I have since learned javascript (I still don't like it compared to the C languages) and the sdk, so hopefully I won't be adding a subtle bug (:

Let me know if you have any questions and the format you want the code in.

— Games - true, but I am not talking purely preference here. I would prefer to use visual scripting, like c2, because I have a much easier time simply glancing and knowing whats going on... mostly because it has little pictures. I like little pictures. I wish I could comment my event sheet and code with little pictures doodled on the side (that's a really good idea - you should be able to assign a picture to a function and the call the function by associating that picture with it... hmmm)... but in the end I can't, and no matter which I prefer to work in, coding, for the specific reasons cited and more, is currently more powerful, and easier (ie... less work) to maintain at a large scale. It doesn't matter what you prefer, you STILL need to be organized, and someone who isn't will find spaghetti code a nightmare too. But honestly, coding is like writing a novel in a text editor, and event scripting is like writing a novel using those little refrigerator magnets. At first, the magnets are easy to use, but eventually you have to start hacking around because there are not enough canned words.

I can handle a large project in construct2... but no matter how you dice it, adding 20 variables still takes more time than coding. That isn't subjective or an opinion, that is fact. I prefer using c2. But I can't justify the time expenditure in a large(complex) project - especially when it comes to me having to also write my own behaviors, because the ones that come with really are no good in the "long" run. I am not generalizing. At the point you HAVE to use code, there is no reason to stay with c2 because it doesn't do you any favors in this department. (once again, sure, you can use an event sheet to do anything, if you are patient enough, but I challenge you to replicate box2d using events... sorry but, but I am not even sure if it would perform! - even replicating the collision detection in mario 3 would be horrendous and that is a cake walk in terms of logic and theory (and sorry, you can't use "push out of solid" either, because that has it's own limitations). Once you end up needing to code in the c2 environment, your preference for event sheets is moot. It doesn't even matter how slow or fast you are at this point because regardless, you are stuck coding (period). ...and (fact) unity has a better coding environment out of the box.

I want construct 2 to be better than what it is. It is fantastic for small projects, okay for middle projects, and tedious for large projects. It has given no concessions for advanced gamemakers... The event sheet needs to be more powerful, capable of being directly scripted, and most importantly, c2 needs to allow editor mods, talking between behaviors, etc... The fact that the platform behavior needs solid to work, that solid is hard coded into core system code, and that you can't touch that... anyway... As I said, this is about trying to objectively say, "C2 can be better, and here is why"...

And no, it's not an unfair comparison... its more akin to comparing ps to sai. Sai has some things going for it that still allow me to pick it over PS in some cases. C2 has some pros going for it that unity hasn't got. And nobody ever said unity was only for big players. I am a one man band, and once you grow past stock behaviors, unity is a better use of time. (which means unity is even more valuable for 1 guy doing everything) And then there is prefabs, which is a whole other story.

If you can do it easy in c2 it basically means it has already been done before (mechanically speaking, of course). Breaking new ground in c2 means using the sdk. If you are using the sdk, then you should probably reevaluate the value of that time and how it can be spent better elsewhere. Also, once I make a new script in unity, I could post it one the asset store if I choose, for free even! You can't really share events though... not like plug nplay style.

Colludium - is there any thing in particular that you need?

I found a bug in the ams.js version that I can't fix, I haven't heard back from from the original transcriber (c++ to ams.js) and am currently helpless to solve the issue. I actually was responsible for getting the code to fix the bug for friction contacts not being updated, which helped me learn alot about c2, box2d, and ams.js... I tried using box2dweb, but it is a very old version of box2d and lacks the ability to update contacts after changing friction. Long story short, I need some features I can't access in ams.js but I also need contact updating. Basically, neither physics behaviors allow me to do what I need.

Consequently, I searched for other javascript versions of box2d but the above choices are the best choices. Which means I am no longer using c2 to work on my main game project, I have switched over to unity, which already has the physics I need without having to muck about chasing bugs.

However, I would be happy to help get you what you need in physics if it is doable. I can say right now that I can't do preCollision or PostCollision checks in ams.js , and that I can't update contacts in box2dweb.

I can however do things like, make a body kinematic, add a prismatic joint, and so on. I could add collision filtering, but the disable collisions between two objects works in ams.js now by defualt. Also, Ashley may add some more features soon, who knows. He did say a year ago that he wouldn't until ams.js updated, which it is, so here we are.

— Games - to an extent I agree with you. Different tools for different folks. It just so happens that I really, really like construct too... But I disagree with what you say about just needed better organization in order to build bigger games. You do need good organization to make a big game no matter what platform you are using, and c2 can make a big game. But once your project could benefit from some solid oop, there is no way construct 2 can keep up with an engine that allows you to code. That isn't subjective either, that is fact (assuming of course, that you are fluent with code).

If I make a small game, construct 2 is faster, it just is more to the point, but without more robust ways of dealing with scalability, the moment a game gets into the middle land of being as complex as say mario 3 (which is still super doable in c2), coding becomes faster. I created a very nice framework in c2 to work with mutiple characters in SFM fashion. I abstracted away everything. Do you know clunky a project in c2 is at that point? It's terrible. An equivalent project in a code environment is much easier to manage. scope is super important too, and c2 lacks that beyond the variables.

If need be I can go to town with examples why c2 events are slower than coding, but all the examples don't matter in small games.

The case of structures encapsulating 20 properties, and needing to copy those structures, is a very fine case indeed to point out c2s flaws. While in code I can simply define the structure in one spot and copy it with one line of code, a c2 user would have to spend 5 minutes adding the variables, and then setting up a function to copy them. Whenever a new variable was needed they would have to remember to change the copy function as well. If this structure had 100 properties in it, it would start to reach the "omg just shoot me" every time you needed to work with it as a unit. This all is compounded by c2's lack of properties, which can easily be defined in code, whereas to get a property in c2 you need to create a function and call the function every time you want to get or set, but since the get and set won't be internal to the object you want to modify, a whole new can of worms emerges. C2 can become impossible very quickly. At the point you have this all worked out in c2, a programmer using code, would be well on past the next 5 tasks. Not only that, modifying or otherwise scaling something like this would be a breeze in code, but a nightmare of menial data entry in c2.

— - Agreed, your second paragraph, is to me, the primary draw of c2. It is clean and fast. For small things, I choose c2 everytime. I teach younger kids to program using construct2 and it is amazing how fast they can pick up things and then go to town with them. You can't do that with something like xna. For those who haven't learned to code, c2 offers a quick and easy way to bypass a solid month or two of "just learning the basics".

newt - lol ya... there is that whole mess. so many wtf moments. But I promise those are fewer and fewer as your experience coding grows. And that is where c2 has a definite speed advantage, but that advantage diminishes as coding knowledge grows.

However, I teach programing to kids using c2... and guess what? There is syntax in c2 as well... and the little munchkins do their finest job messing up every expression that comes there way. And they don't seem to know how to fix or whats wrong with it... so there still is a bit of a learning curve in c2. Having learned to program before coming to c2 allowed me to hit the ground running with very few problems, so I kind of took it for granted.

Aphrodite - don't get me wrong, I would never suggest ditching the event system - I just wish it also was scriptable as an api. For me, looking at pictures in boxes connecting to other boxes makes sense. The event system does this well, but it also is a hold up when you just 'need to code' so to speak. That moment where you know how everything is handled and there are no theoretical problems left; The only thing left to do is hammer out code. And when I need 20 variables and I need the ability to copy all 20 to various locations, events get heavy and time consuming, where as, in code you can simply encapsulate these variables in a struct and pass that around. An properties... c2 needs properties...

— - I don't think the sdk is hard, I agree, it is just clunky. Not fun to work with. I think that that is my major beef with c2. When I get to the, "I should just code this" point, I usually just say screw it and make it in unity, simply because it will take less time to script there than in construct. But ya, c2 comes with some nice stock behaviors, and they can be super fast, but once you have your own set of scripts in unity, the advantage becomes irrelevant.

again though, that's assuming the base behaviors are robust enough... which they are, only if the game is typical (in a mechanical sense). The physics behavior sucks, because it is lacking, and has no power. It offer no advanced abilities, and thats just not enough. The platformer behavior is one of the best I have ever encountered pre-stocked in an engine, but again, it isn't enough for me. There are little things about that make it, ultimately, a bad solution for all but once again, a very typical platformer (collision logic has alot to do with this). You can't even make a perfect mario clone with it. And the list goes on. Basically, If I want to use a behavior, I usually end up making my own custom version. That all aside, when I make web games and minigames for phone.... Construct is the way to go. I can make a complete game in a few hours as opposed to days, and that is AMAZING.

One question for you though: When I say big c2 can't make big games, I should define big. I don't mean to say that you can't have large levels, spanning a continets worth of content. I meant it more in an oop sense. Making a game like smash brother would require a lot of abstraction to avoid having to rewrite large swaths of logic. With c2 inability to have multiple inheritance, no interfaces, etc... Games that require abstraction can become a nightmare. Also the fact that, at that point your entire event sheet is filled with the defualt icon for families, events can become less readable than code because they lack the visual component. Also, pick uid becomes a pain times two. It is in this case that event scripting takes longer than codeing because it requires "more".

I like your list though. nice and succinct.

Hello everyone,

I really am only aiming to discuss 2d game development, that way we can compare apples to apples...

I use both unity and construct2. Why? because they each have strengths, and weaknesses.

Construct 2 has often been hailed as a tool whereby one can make games really, really fast... but honestly, unity is just as fast. If you are faster in construct 2 than unity, its because you haven't learned to code.

People also favor construct 2 as a no programming gamemaker... but this is stupid... if you can use logic (i.e your brain) then you can program. When you fill out the event sheet, you ARE programming. People look at programming like it is some sort of foreign language, but its not (unless you don't speak english, then it kinda is, but that's a different issue). Event editing may be faster upfront, because you can browse through all possible conditions and actions, but once you have learned to use an api, programing usually becomes faster than visual coding, simply because the coding interface is more simple. For example, to declare an instance variable in construct you have to go clicky clicky here and clicky clicky there, type in the variable name, select the type you want and then voila, you have yourself a variable. but what if you want many, or need to delete a bunch? You have to do all those clicky clickys for each thing you want to change. In a code environment, you simply type:

int someVariable; (c++ / c#)

var someVariable; (javascript)

dim someVariable as integer (visual basic)

and here is the funny thing, I play starcraft so my clicky clicky is really good, but honestly I just typed out a variable declaration in 3 languages faster than you could clicky clicky your way to one instance variable in c2 via event editor. But then the code environment has things like copy, paste, delete all selected text and so on. I can even declare variable in mass:

int x1, x2, x3, someotherint, yourmomsage, castlength, bouncyballs;

And this is just the tip of the ice berg. Coding is fast, once you learn. and if you already can make a game through events then you certainly can program. If you say you can't program then you are just a winy looser, with a bad attitude. Can't died in the corn patch. Can't never can because it decided it can't. I know we all have our strengths, but when you only go with your strengths, your weaknesses will never improve.

And this brings me to the reason why I still use unity... because it was designed to support scripting (i.e coding). Sure, I code the random behavior here and there for c2 but construct 2 wasn't designed around coding. The sdk in construct2 is kind of an after thought. This needs to change in C3.

c3 needs to have a robust coding environment in the same way unity does. Even gamemaker has this (construct2 is way better though, lol). Coding is more powerful and faster to use in the long run. It is more flexible and unless the event sheets can match the speed and utility of programing, I will always be using other tools that do allow this.

Construct 2 is great for making little phone games and browser games... but beyond that... it just gets to slow as the game scales. More often than not, I start a game, only to find out I literally can't do something in construct without a mess of events (which I can't use again in another project) or a custom plugin. At this point why would I use construct instead of unity? Unity has a better environment for this kind of development, I can easily reuse my scripts, and it performs better on all platforms...

So why do I use construct 2? Because, construct 2 is faster to create objects add behaviors, and get a project up and running. Those benefits outweigh the downsides in a simple project, but as the size and complexity of the project increases, the cons outweigh the pros. I also really like how quick Ashley fixes bugs. Unity on the other hand leaves bugs in the program for years. Their goal seems to be to be continually adding features even if some don't quite work as expected in all situations.