Ruskul's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • bladedpenguin - Yeah. You are getting on to something. Physics needs raycasting, the base system class needs raycasting, and the overlap methods needs updating to be a little more situationally robust. (you should tell ashley as I am sure he has heard it enough from me, lol)

    I have read the source code for both box2d (which is the code runs the physics behavior) and as much of the core classes that runs construct 2 as I can. Changing the physics behavior is perfectly possible. It would be quite easy to add raycasting (most box2d features are easy to add). But you can't mod the system files for construct, so you would have to create a different behavior to handle raycasting vs. solids. This can be done fairly easily as the algorithms for raycasting are easy to find on google.

    But, the biggest problem with all of this is the fact that the tile map generates collision polys in a smart manner. For example: if you have a bunch of square collision tiles, the tilemap will group those up and make it so it uses as few collision shapes as possible. This is awsome for optimization, but this means when you hit a poly, and that poly is a large one that makes up an entire group of tiles, finding the tile still requires some mucking about.

    This actually becomes a sort of dichotomy between performance and a particular function. Does this all make sense? I am saying that the solution to this problem is going to be, somewhat more nuanced than it appears at first look.

  • lol That comment made my day

  • Ashley - As far as I can tell, contactedge.get_next() is only supposed to go through the contacts connected to the body in question. if you use contact.next(), that will go through all contacts in the world. But without using box2d.getpointer() the loop will run forever and contactEdge.get_next() keeps returning empty b2 contact edges.

    I edited the code to count how many times the loop is running... It runs only as many times as there are physics contacts affected the body. So it looks like it is running as it should.

  • Okay, I wasn't sere if there was anything in the error report that would tell you what was wrong. On the plus side, nothing seemed to be wrong other than the error message.

  • Also... I find that it is easier to get technical advice on the unity forums. Construct 2 has a super nice community, but 9/10s of us here don't know a switch from a loop... which is important if you decide to go the sdk route or have deeper problems with c2 than the average user.

    Also, javascript. I don't like javascript. Games don't like javascript. But if you go the sdk route you get all the fun that comes with it. I would take c# or c++ anyday of the week over javascript... yet, here I am with javascript. I figure everyone needs something to keep them passionate though; and I loathe loosely typed javascript...

  • newt - a better implemented work around to be sure but still using overlap... which is part of the problem. It won't work with physics.

  • If you want to get into a discussion about whats better for what, that all comes down to preference in the end. I prefer working in c2 because I can make things so fast. But, I prefer unity because I can do more. I also think given the amount of games released on unity... you get the idea.

    I would classify both the binding of issac and Mario as fairly straight forward games, and yes, you could make exact clones. However, here is the thing; You are going to need to write your own collision detection and resolution code to get an exact mario clone. Which brings us to some of the problems with construct. Because there is no way to edit, modify, or otherwise mangle the inner workings of construct to suit your designs, you have to make everything work as custom behaviors, plugins, or through the event sheet. I like c2, but when it comes to something like this, I would much rather sit down in an environment that is as flexible as possible. Coding collision response in events would suck. Using the sdk isn't as well documented as scripting in unity. Also, unity offers a better environment for that type of development. On the other hand... If you make it using the sdk, you will have constructs editor side speed when you are done. But then you may have to concern yourself over janking in NW.

    If contstruct 2 offered an IDE and everything was component based, and physics was better integrated as part of the engine... I would choose construct 2 100% of the time. But right now I flop back and forth between the two.

    The major letdown of construct is that it lacks true ObjectOrientedness which is the major problem with it. Using Unity, you can blast apart any problem needing inheritance, scalability, or virtual functions and the like... if you can code. In construct, since families can't inherit from families, and functions are kind of awkward, you lose the speed advantages.

    The best example I have is a game Framework I worked on in which I had dozens of characters who could either be controlled by an ai or player. The characters were all as different as in smashbrothers (and as equally the same) and required multiple FSMs. Using families, and passing around UIDs in functions at a high level of abstraction makes c2 lose its charm. It took me two weeks get things to start working, but I had to sacrifice alot of future flexibility. Unity, on the other hand took much less time, as I could simply write abstract scripts how I wanted.

    For small things, I use c2. For convoluted projects, I use Unity. I hope this changes in c3, which it may.

  • newt - you can't use else after a trigger

  • This is the type of thing more people need to learn the sdk for. I applaud your first behavior.

    I made a behavior simply to quickly add a few common instance variables to objects that I did in every project. It saves a load of time in the long run. Health is a great idea.

  • There seems to be a flood of responses going on here, but I didn't notice some important info on first glance.

    Nobody here seemed to mention the problem c2 currently has with work flow scalability. Creating a robust frame work for a large game that leaves you with plenty of options can be a chore with c2. It's not to say you can't do it, but lets say you wanted to create smashbrothers... Creating a multi state machine that each compound character can use is going to be funnn fun fun , and way more complicated than just cracking out the code and coding.

    I am an artist btw, but if you can use logic, then you can code. I recommend c2 for quick dev of prototypes, an indispensable tool for making small games, but a headache for organizing large projects. The work flow simply decreases as the needs of the game become more flexible.

    Also, if you plan on pushing a unique idea, construct 2 may impose a number of limitations of which there are too many to list... but its not uncommon on the forums to be told you just can't do x,y, or z due to x, y, or , z.

    But alas, the only way you may discover these things and if they pertain to you is to start working. Construct 2 is a great tool, and you can try out alot with the free version. Make something then see what you think. Make the same thing in Unity, and see what you think. In the end I recomend both. c2 for speed, unity for sophistication. and if you want, there is always the sdk, but lets clear something up right away, you can't make "everything" with the sdk. There are limitations there as well.. .. But lets face it, you can't make everything on one thing, that's why there are all the other things... It also depends on how much "out of the box functionality you want" . Construct 2 has a ton of pure awsomeness from the get go, but it may be a little more difficult to expand that via the sdk than in, say, unity or unreal.

    Sorry to muddy the water.

  • — - Either I don't understand what you mean or we are on separate problems. This is how I essentially create an end state for collisions:

    OnCollision

    ------------- this.collided = true

    NotIsOverlapping

    ------------- if (this.collided = true) then this.EndCollision = true

    If EndCollision & triggerOnce

    ------------- // Do Stuff

    ------------- // this.EndCollision = false

    As far as I can tell you need two state tracking variables and the use of IsOverlapping. But as I stated in the OP IsOverlapping doesn't work with physics enabled objects (a separate problem needing addressing). Meaning the workaround now requires sensor objects. potentially doubling the amount of active objects in a scene. Seeing as construct lacks scaleability in the compound object department, I can't see as adding another object to the list as being very desirable.

    Essentially, I said workaround exists but problem with workaround exists... which is why the workaround is not a suitable sub for the existence of a new trigger.

  • Hey everyone,

    The title says it all. It is easy enough to create a workaround to not having this trigger, but it would be faster and more suitable to have it included in construct. As it is, the work around will not work for physics objects without creating an extra sensor object.