Ruskul's Forum Posts

  • troublesum - well.... ya, but couldn't that same info be used to run an intellesense? I mean, when coding, you can always write non functional code. The way expressions are currently filled out already runs in a smart way... , so I don't see why it couldn't be done for the rest of the ACEs. If that in turn allowed for actually being able to code functions instead of using the function object,a and so on (loops, methods, etc) that would be really awesome.

    But uh the above code needs fixed anyway, based on what I was thinking... I forgot overlapping is a system condition... done

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

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

  • nice!

  • I think it would be cool if all the text could do classical gameboy animations (you know, how the text types itself, and characters can wobble and so on)

  • I want to something like this as a possibility...

    If (system.IsOverlapping(someObject, someotherObject))

    someobject.X = 42;

    camera.setposition(someobject.position);

    //you get the idea

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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