coding vs events

Discussion and feedback on Construct 2

Post » Sat Mar 14, 2015 6:10 pm

@Chupup 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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Sat Mar 14, 2015 6:51 pm

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).
B
11
S
2
Posts: 213
Reputation: 1,266

Post » Sat Mar 14, 2015 9:47 pm

@Chupup 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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Sat Mar 14, 2015 11:12 pm

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.
B
11
S
2
Posts: 213
Reputation: 1,266

Post » Sun Mar 15, 2015 1:16 am

@Chupup 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." - @Chupup 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?" - @Chupup 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." - @Chupup 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. " - @Chupup 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...
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Sun Mar 15, 2015 1:37 am

@ruskul

That's why there would have C3.
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Sun Mar 15, 2015 2:15 am

@ruskul: can be i don't take all your points, english is not my native language and can be i don't get all right what you said and also sometimes it's hard for me to express exactly what i want to say.
Anyway, i understand your issues. I just want to say C2 has a way it is and you can not push it too much in a direction without changing it too much and it's losing it's spirit and just gets another game engine, like hundreds already existing.
If they improve the api, so you can code better plugins or tweak the output to your liking, this is something i wish too. But please no changes for the event system! Because this is what makes C2 great.
That you can not making something like metroid without the sdk or coding is just not true. I am currently working on a platformer with some nice game mechanics and some bells & whistles & i don't use either the sdk nor some magic. And my event sheets don't overhelm me more, like when i work on c# code in VS or javascript in brackets. When i publish a preview everybody can have a look.
B
11
S
2
Posts: 213
Reputation: 1,266

Post » Sun Mar 15, 2015 5:49 am

@Chupup - 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!
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Sun Mar 15, 2015 6:37 am

@ruskul - I feel like saying the SDK sux is a bit unfair. I found it fairly easy to learn the API Ashley put in place and write my own plugins. I'm not a fan of the code format as it could have been cleaner but the functionality to do what you want is there. I have a personal plugin (unreleased) that joins the Multiplayer and Function plugins together so I can pass parameters and call functions on all/specific peers with a signal event action. That's pretty powerful functionality available in the API and there are tons more sophisticated plugins than that which are available on the forum. I might be a little biased because I am professional JavaScript developer and I can write it fluidly. But other than the code format its really easy to use.

I don't know if you know how to code in JavaScript but if you do and I in no way mean to put down your coding abilities but you should see how I rewrote the API from the template Ashley provides to be more clean and intuitive. I removed all prototype usage because its confusing as hell to follow. Check out the runtime.js file from my 2D Dictionary Plugin https://www.scirra.com/forum/plugin-table-2d-dictionary_t125862. If you use any kind of IDE with code folding (i use netbeans) you will see how much easier it is to read and use and might not think it sux.

You can see how much cleaner and easier it is to add Actions,Conditions,Expressions
sfsdf.png
You do not have the required permissions to view the files attached to this post.
B
20
S
7
G
1
Posts: 221
Reputation: 2,077

Post » Sun Mar 15, 2015 7:06 am

@troublesum - "I feel like saying the SDK sux is a bit unfair" - I agree. I should change that in the post. I don't think you being a literal pro at JS makes you biased, it gives your assessment authority.

I must admit that I have learned JavaScript on the fly through reading the c2 core source code and behaviors. I admit I am no pro in javascript, and much prefer C# or C++, consequently I make stupid mistakes and spend much more time mucking about simply because it isn't c++. That having been said, Most of what I meant by the sdk sucks, is that, it is poorly documented. My problems with javascript aside, the lack of documentation is what I find irritating. You have no choice but to read the core source files to find out what the difference between pretick, and postick are (plus the other two similarly named ones) When they are called, and on what objects they are called. The documentation mentions none of that. But at this point, I do understand it, and what happens, but I don't think the hurdle to get into the sdk was as low as it should be. Especially when compared to say, Unity,. C2 user manual is better than unity, but not if you want to script.

But I must read this plugin of yours. I would very much like to see the changes you made.

On a final note, I do remember that ashley told rexrainbow... or someone on the forums that it was a bad idea to call the aces of another behavior from within a behavior. none the less, It seems that this is quite normal amongst 3rd party devs, and I do it myself with no problems. But it is annoying that the documentation has next to nothing on the whole process of how c2 works internally.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: TheRealDannyyy and 5 guests