coding vs events

Ruskul

That's why there would have C3.

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.

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

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

[attachment=0:3tqi4abn][/attachment:3tqi4abn]

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.

troublesum - other programmers comments make me happy

lol

//BECAUSE PROTOTYPE IS UGLY.

but I like what you have done here.

edit

troublesum - did you just add that png to the comment? I didn't notice that the first time I read your comment. Ya, ya, that makes it much cleaner, which was part of my beef. Documentation is lacking which makes it hard to get into the sdk (in the time consuming sense of the word), and the adding of aces makes adding simple stuff a bit tedious.

Ruskul - haha.. thanks... and prototype is ugly .. good god if there one thing i hate more its reading and working on object oriented code by developers that use prototype. I know its the standard but the Internet guys need to make method available that's cleaner and more intuitive.

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.

Ruskul - It is bad ... because it creates a dependency on other plugins that the user might not have and if those plugins get updated by Ashley the new changes might break your code or worse yours breaks the functionality of the existing plugin. That's why I wont release this plugin. I don't want to pollute the C2 ecosystem with a plugin that may become defective and not work in the future and some poor dev cant open his project in the future because of it.

I have some suggestions I would like to share actually, perhaps to know what people think:

-I stated before that I would like to be able to write behaviors in events, or more logically to add event sheets to objects themselves (I do not have to know how the runtime handle it behind the scenes), that would make manipulating AI and objects easier. Sure coding simple ennemies that go left and right, or even jump above pits are easy, but bosses are not something I want to do in events currently for exemple, and going through the SDK to make a behavior for it kind of break the point.

-commenting in the event system is currently ... pointless sometimes, sure too much comments kills the comments, but one single comment above an event sucks purely and simply, only useful to explain how to call a function in my case, sure, there is a rex plugin for that, but why this basic thing is not already there is beyond me.

-the current behaviors have to be fixed:

the 8 direction behavior respond weirdly to solid objects, "it does not seems like a bug to me", I saw zero complaints about the issues the behavior has, people just stop using it completely it seems when I ask, I will try to report another 8 direction bug later today while I think about it.

this bug exists, it may be fixed though, also the jump-thru plus a tilemap is unusable, not a big deal sure.

the physics box2d asm.js is not (yet) a full box 2D behavior, it lacks some basics it seems.

surely no bugs, but still odd ways for them to behave, I hope people get the point.

Aphrodite - To all points, I agree fully. Especially the first. ..."write behaviors in events, or more logically to add event sheets to objects themselves" Both are desperately needed. This is one of the reasons I find unity so much more useful when making larger games. In unity, you add a script (ie behavior) directly to an object. Everything you want that object to do is contained in the script(s) you put on it. ..

but implementing this might be quite hard. I haven't really thought about how inter object references and dependencies would work. In Unity, you have to have a pointer to another object or script to be able to access it, which doesn't seem easy or uncomplicated for most people not having coded.

As for behaviors... I really don't use any of the canned behaviors straight out of the box. First of all, it's hard to have that unique all your own feel when using another persons implementation. To get the most out of any behavior, you have to understand the behavior in and out. at that point, you don't really need the behavior and can write your own (depending on the time). I much prefer to role my own platformer code every time I make a new platformer prototype... But I am also a perfectionist and knowing specifically what is happening in a behavior is important to me... And ya, that 8 direction code is no good when interacting with solids.

troublesum - I new it was bad for those reasons, but making an ai in a behavior that uses physics sort of needs that dependency.