coding vs events

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.

As you said, it's not the events that make C2 fast, but the behaviors. I can click 2 things and have a platformer engine ready to go for example. Click 2 more things and all my objects now have physics. Etc. You can do this stuff with unity with assets but obviously each of those costs money so it's hard to experiment ahead of time.

I do think event-sheets are much slower for me than programming.

I think the most important thing is if you feel comfortable with the engine of choice. Sure, both Unity and C2 have a lot of technical pros & cons (i use both, too) but more important is in which environment you feel more at home and this everybody has to decide on his own. I think you can also make bigger projects with C2, you just need to organize yourself better, with this i mean re-use eventsheets, use families, groups, custom folders and also comment your code. This helps me a lot. Special the structuring and reusing of event sheets can make life much more easy.

It sounds like you have a work flow that works great for you. Being a Construct 2 and Unity user myself, I can agree with a lot of what you are saying. There is power in coding that is lacking in a visual event system like C2s. I have also written games in C++, C# with XNA and straight Java (both PC and Android). I would definitely choose most of these over C2 for a large scale game project.

However, In defense of C2, for most current games that are built for the web or mobile devices, C2 is considerably faster than coding. For example, my son wanted to build a tower defense game and I had not built one myself in C2 yet. I decided to throw one together so I would have some understanding of how to help him. It only took me about 2 hours to have a near feature complete tower defense game working even without starting with the template. That is a really impressive build time for any engine for a game type that is new to a user.

Also, there are a lot of C2 users that are afraid (yeah, I said it, AFRAID) to try to learn to code because it seems so complex to them. A graphical event system can really ease a persons mind removing the stress of learning the tool so they can get their ideas into a playable product. I think this is the greatest strength of C2. People are at ease while learning it.

While it is far from the best or most powerful tool, it really has proven itself to a strong contender in the 2d game engine industry.

Two words, sin tax.

I would have just broke whatever I was doing if it was code.

In C2 not so much.

Being a Unity developer and C2. I know where ruskal comes from. However I do disagree on other points.

• Scirra doesn't promote no Programming. Scirra promotes no traditional coding required. I don't know why people still make this mistake.

• yep var creation is way better on programming. However a counter argument variables are objects through the system. So there are no remaining vars, or mistyped vars.

• C2 strengths are the behaviors and the API Scirra created and can get running so much faster.

-C2 biggest weakness is the SDK. first I make this clear. the SDK is NOT hard or difficult. The SDK is clunky, not clean and has scoping issues. Also features of Plugin and Behaviours are not shared. If the SDK were lean, clean and mean. Then I think the SDK would be a lot more useful and count as ruskals programming.

-I agree with ruskal. C2 should mostly act as an interaction of behaviours. Once lots of events are needed to handle basic processing, then it's too much. Should be created as a Plugin/behaviour. however do to C2 clunky SDK where you want to mix behaviour interaction. it's just bleah.

• C2 can do large projects. I see no difference from Unity or C2 when it comes to 2d game development. export is another matter.

• no syntax errors. I cannot express that having this issue removed increases productivity by a lot.

-Unity programming is not faster than C2 programming. However Unity scene editing is faster than C2 scene editing. The inspector and the robust options for vars and how they are presented just offer so much.

Will agree on the fact events could be handled in a better way (just having a way to actually do a behavior like interaction in events would fit all my complains), as events are not really great to have the "black box" C2 logic (aka when you simply hide out how things work, to concentrate on what they do and use them).

I never used he SDK (nor needed it really), so i cannot tell much about it, but third party plugins are really messy to use and install sometimes.

the "can't code because you just do not want to try to overcome yourself" is only matters of opinion, sure, I could code in lines of code, it is not hard (even though syntaxes errors are really boring), I just dislike it a lot, and I think the worst thing that could happen to C2 (or C3) would be to have a way to type code in it (to type events, however, would be fine, as long as both ways are translatable in an automatic way from one to another inside the editor, that is fine by me), events are a nice thing to use, yet flexible, improving them would be better than ditching them or giving an alternative that would make them irrelevant.

just my two cents.

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.

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.

— - 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".

— 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.

There is some true points in this, but you can not generalize. For some people code might be easier to maintain, for others the C2 way is more clear and manageable. And if you talk about really big projects, they can become a mess in pure javascript or another framework like phaser (for we stay in the html5 content) very fast, too. Only because for you code is more easy, doesn't mean it must be for all people. (And i code long time in all kinds of languages, so i know the other side). Anyway, i think C2 is perfect for small and middle projects, but an experienced developer also can handle big projects with it. Everything has it's pros & cons, some things are more hard to do in C2, others are lightning fast to set up, and like i said before, everybody need to find out on his own what he/she prefer.

And really, comparing unity to c2 isn't really fair. This is like comparing Photoshop to Paint.net. C2 is more for the solo indie developer or small teams, that can make big projects with it in their scale, and Unity is used by the big players and teams with 20 or more people (not saying one man can not use it to make his dream game).

— 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.

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. 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? 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.

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