Ruskul's Forum Posts

  • for example, if you can choose a color of the event, make a special link to another event, or comment the subevent can be easly to understand the projects... and when you make 10 different event sheets start to be difficult...

    YES! This * 1000+ I tend to use a prolific number of event sheets, but bigger projects just don't work as smoothly.

    Ribis - I understand it is quite easy to make a Mario "Like" game. But I am unconvinced you "cloned" it; A clone is an exact functional copy. A perfect cloning would even include common glitches that occured as a result of how collisions were detected and resolved.

    I am quite certain, given your diddy kong country example, that you did a great job on the super mario world game. But I won't budge on what I said. You CAN"T make a mario CLONE without a custom collision system.

    So far, it seems that people have taken my statement as a sign of ignorance, that I don't know how to use construct. This is far from the truth. I personally have made the mario 3 collision system, both using the sdk and using events. We are talking 1000s of events. The platformer behavior cannot be used to clone mario. It resolves collisions all wrong and lacks the right tools to handle proper resolution.

    Can it be used to make a mario like game? YES. yes yes yes. But it cannot be used to clone mario.

    Now to beat a dead horse further to death... for those who missed my original point: Becuase it (contruct 2) can't even clone a simple old game using behaviors, my point is that it can't be used to make ceartain new game ideas. A point that is painfully clear to me as I have yet to be able to make a game and not also have to make my own collision detection/and or response methods. This is way to cumbersome to do with events. Enter the SDK which is the weakest component of construct 2. Enter my final point, if you are using c2 and the sdk, why not use unity? It has a much better code oriented environment. Why use construct 2 at all? I have my reasons of course, but

  • newt - The run-time function to test an overlap between two polygons always gets passed offset parameters for x and y. When you test overlap it just sends 0 and 0 for offset x and y. Those offsets get added to the quads points regardless of whether they are 0 or not. Basically an offset test is the same as a regular test as far as the runtime goes.

  • Could we get an official explanation as to why this is the case? Is it simply an outlier based on scalability? Optimising is already hard enough without being forced to consider methods that seem illogical - it hurts my poor non-programmer brain

    I think the biggest moral of the story is to:

    1. Never optimize unless there is a reason. Code should be reasonable and readable. If you find you are not meeting your performance goals and benchmarks, then identify areas of performance bottle necking.

    2. When optimizing, never make assumptions. In many cases, for whatever reason, an certain way of coding may seem easier to humans but slows the computer down. Most tests like the one I made can be set up in a blank project in a few minutes. At that point, it's setting up an experiment. make sure you follow good science.

    Most of the time you really needn't worry about this sort of thing though, and it can become a productivity bottleneck pretty quickly. Remember, part of making a game efficient is doing so efficiently and optimizing can be a waste of time where it is not needed.

  • newt - The condition Is "player overlapping enemy", is 400% faster than "is Enemy Overlapping player "

    Good call on bringing that one up. I just tested using the same conditions and all (10,000 enemies). The results make sense, I think. In the case of the "is Enemy overlapping player", I believe the collision detection runs out and fetches the objects within the grid the enemy is occupying. For each enemy object, which increases overhead. In the case of the player overlapping enemy case, Since there is only one player, it only has to go through this process once. Keep in mind, my explanation is complete conjecture as I don't have access to how broad and narrow phase collision detection works in construct. I'm just going of what I know about collision detection in general.

    The cool thing is that the SOL is the same regardless of the order of operations.

    My conclusion is that when testing overlaps, use the object that you believe to be fewer of... IE is player overlapping bullets, rather than the other way around.

  • Hey everyone,

    Lets say you have a player object and 10,000 enemies. The player is red. All but one enemy is red. If the enemy is red it can hurt the player.

    If an enemy is red and overlaps the player, then the player dies.

    But in what order should you check? You could first compare variables, or you could compare collisions.

    If you compare colors first, you narrow the sellected enemies down to 1. That means you only run around 60 collision checks per second. Not bad right?

    If you compare is ghost overlapping player first, you have to have thousands of collision checks... and then check the few that returned if they are the right color. That sounds bad right?

    Well, as it turns out, testing for collisions first in this case is the most efficient thing to do. It is twice as efficient as doing it the other way. It's always a good idea to make little tests and compare the results side by side if you are having performance problems. The simple order of conditions can change alot, and often times our initial assumptions can be wrong. When you compare collisions first you have an advantage in that most of the work is occurring at a lower, very optimized level. Collision detection in construct has been optimized in significant ways including a broad phase check that eliminates most objects before even getting to the actual overlap test. However, comparing the variables at the event level has the additional overhead of the event system, and is more or less brute forcing its way to victory.

    Most games of course, wouldn't need 10,000 enemies at once. and of course there are things you could do quite easilly to reduce the variable check and collision check, simply by replacing the red ghost with a different object when it turns red and then checking against that object instead of all the ghosts...

    Anyway, I thought it was an interesting test and shared.

    Anyone else have any surprising results, or oh duh moments in the realm of c2 development?

  • NotionGames - that is a shame. I wanted to release a game on the wii but I haven't bought the dev kit yet. I was kinda hoping to release on steam and then move to wii in funds permitted. I suppose the high res stuff could be a problem.

  • NotionGames

    Good job! Love the game. Did you get it to wiiU? If I may, the game is fairly typical in the "platforming" sense. I mean that, your need for platforming mechanics was fully solved and contained within the behavior. Anything else you needed could be added on top. That is perfect as a use case. There is no reason why you can't get the platform behavior to work in many projects. But if you have a low level problem with something the platformer behavior does, it renders the whole behavior useless to a project. You can't correct what the behavior does with collision detection or resolution... and so on.

  • ...this denies the point of the behaviors. Instead of using and setting something what is ready to go in few seconds you are reinventing the wheel by creating entire behavior in events just to be able to set one thing.

    If you really want you can modify the behavior to suit your needs, but then it creates two more issues.

    1. You should not modify original plug/beh because at some point someone might do some optimization or bug fixing and your changes will disappear

    2. You can duplicate it, but then you need to keep track of the original plug/beh on every release just to see if nothing has changed. And you are ending up with two almost identical plugins that needlessly makes a mess in plug/beh list...

    This.

  • > ....to say you couldn't create your own physics with events is not true.

    >

    Your earlier point about making Mario with platform behaviour was valid, and I haven't tried so it could not only be possible but relatively easy to do now I think about it.

    No , no , no. You can't. It's impossible. Read the posts I wrote one or two above this one. Mario is so basic and yet it can not be made using the platform behavior, simply because of the fact that mario uses point based collision detection rather than SAT, Also, because the platformer behavior modifies the velocity of an object without the users consent, certain collision responses that occur in mario are impossible. You can make the behavior via events, but it is a terrible idea to do so without coding some of your own supplementary collision detection plugins and behaviors.

    as for physics... My project using physics permanently got moved to unity.

  • > snip

    >

    I agree with all this. Got to say, reading about some problems make me feel like I live in a different universe or something. I can vibe with the sentiment that C2 feels limited because of certain assumptions about what users need and what they don't. The recent parallax discussion for instance springs to mind. But I don't see why we couldn't recreate Mario, or any kind of platformer gameplay we like, with the platform and solid behaviours and some events to supplement them.

    It's actually because the way the platformer handles collision detection and response, that you can't clone mario. Iv'e been repeating myself multiple times in defense of the "you can't clone mario" argument with behaviors. You need a custom system for handling mario and his collisions. Trust me, I am not simply talking on conjecture but on actual experience. I event scripted a mario clone and I coded one via the sdk. In the future I may share this project, but I don't want to deal with people trying to figure out how to use them.

    In many cases you can get away with the platform behavior. but the moment you need a low level control, you are up the creek. For example: if you need collision grouping, things are impossible with the behavior atm. If you wanted to altercate the way collision response takes place on slopes... well... now you are in the behavior itself recoding it. You can't fix the way a behavior works in events. Try adding kinematic bodies to physics using events. lol. You can add in 10 minutes though, via code, but it is impossible through events

  • I think it's more like...leave behaviors alone and give us more options to make what we need when we need it, using events. What Newt said is actually how Stencyl works lol.

    This!

  • I don't really get this talk about all these behaviour limitations? If my project needs something and a behaviour can be used then I use it. If there is no behaviour that suits my needs I make my own logic with the event system. What is the problem?

    I don't think anyone was getting at behaviors as being a problem. It is the weakness of the event system in creating extensible, manageable, abstract systems to be used in multiple projects.

    If you need raycasting you can make your own with the event system. If the platform behaviour doesn't work for you, then make your own or tweak it.

    Ya, I think several of us did that. But events are a dumb way to go about creating raycasting. It is already a cpu hog and running it through events would be sort of short sighted. Programing behaviors is not as fast in construct as it is in unity. Because the end path in construct for an advanced developer usually involves creating their own plugins and behaviors it makes sense to be somewhere else as Colludium said. You have lost the advantages of construct at that point.

    People seems to think that you are limited to only use the behaviours for the whole game. I only use a few and mostly do my own with events and functions that can be reused. I also work in Unity and Unreal Engine and you can download behaviours there as well but just like in C2 they might not suit your project and you simply make your own. So stop thinking that behaviours is a limitation. It's just a tool you can use if they suit your needs. I'm not saying that C2 doesn't have limitations. I'm just saying that behaviours isn't a limitation.

    I couldn't agree more. But the limitations of event system don't make some extensions economically plausible if time is a resource... back to the sdk!

    Saying that you can't make a Super Mario clone in C2 is not true. It is actually pretty easy to make with behaviours and custom events and if you know what you're doing you would be able to make an exact clone of mario in no time compared to other engines like unity.

    Go back and read the comment that was made in this regard. It wasn't that you CAN'T make mario in c2, it was that you can't make a mario clone using the platform behavior. Making an entire system to handle and resolve collisions, provide the backbone to all platforming characters (mario, goomba, etc), and so on, is an endeavor best attempted via the sdk in construct: not the event system. I know. I have made a framework to handle the above in c2 events and in code, and I can assure you I know how, I know what I am doing, and I speak from experience. Unity provides a better environment for coding and would be a better place to be if your development is code centric. Which given the above, probably should be if you don't like wasting time. I also am going to make the claim that you may know what your doing in construct but you don't in unity if you think you can event script a basic system like collision detection in construct faster than in unity. In the end, the coded system will also be better, as code allows for scope, among other more important things.

    Just to put things in perspective, I have given the code to fix several bugs in the box2d physics system, which I have read the entirety of and understand. I have made my own box2d behavior that includes several missing features in the vanilla behavior. I have created several of my own retro collision detection systems, and reverse engineered mario 3 collision basics using frame by frame analysts. I have taught children's classes on programing, ... blah blah blah... obviously this is the internet

    "If you knew what you were doing..." ... You could make the cone mario in code much faster than in c2 events. Also, on a trivial note, Mario's position can only be stored and changed by a minimum of 1/4 pixels. This is important if you want to make an "exact" clone.

    I think this remake of Donkey Kong by Ribis in C2 is alot more complicated than a simple mario game and it shows what you can do by combining behaviours with custom events.

    Subscribe to Construct videos now

    I never played DKC so I can't readily compare this clone for specidic details. This is an awesome example of what can be achieved using c2, but nowhere could I find the author stating he didn't use the sdk to help him make this.

    You may be surprised to know, but there isn't really anything going on in DKC that makes it significantly complicated than mario 3, at a core level. I am making this claim based on only what I can see in the demo. Sure the snes could handle more x,y, and z, but the basics concepts of how x, y and z are handled and resolved didn't change much from the nes to the snes.

    So people who are saying that you can't make unique games with C2 are just not experienced enough. If you think outside the box and stop relying on behaviours and use the power of the event system instead you can create almost anything.

    Uh... I don't recall anyone saying you can't make a game in construct. And I also think that that Tokinsom amongst others simply stated the problems with using a behavior to get the results you want. Obviously they understand you can't simply use behaviors and expect unique results.

    "Almost anything" I am sure doesn't include the missing features of physics behavior, projection angles, or how about this: your own broad and narrow phase collision detection algorithms. Ya, you know why, because you would be crazy to attempt to write that in events. You have to code, because it is more reasonable.

    And many people say that C2 isn't capable of making big hit games because there are so few good C2 games on the market. The truth is in fact that C2 attracts people without experience and most games released are to be honest pretty bad and the overall quality is really low. But the engine itself is capable of doing almost anything if you use it the right way but as any other engine it has its strengths and its weaknesses.

    Did anyone even mention this on this forum yet? But you are right. C2 can make amazing stuff, if you use it right. Using it right, at a low level, involves programing <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • newt - I think that is what is kindof being hinted at. You can't make one behavior fit every need. There are a few platformer behaviors in unity that, rather than being one behavior they are a multitude of behaviors. You add a single manager behavior that coordinates the sub behaviors. Things like wall run, and jump, can then be added. Duck, slide, roll, jump, climb ladder, drop through, get surface angle, run, and so on are then added to the object. Each has its own parameters and what not.

    The basic manager only has stuff like collision detection (no resolution) and keeps track of state and whatnot. In a way, when you extend the platform behavior via events, you are doing much the same thing. The problem is is that the basic platformer already does more than it should and can't have things turned off. It is also missing some low level features that enable much more advanced derivatives of it (like being able to chose how collision response works, being able to ray trace, and so on)

  • Tokinsom - ...I'm definitely interested in addressing this in the long-term with C3. However I can tell you getting a bulletproof movement with no difficult edge cases is extremely difficult even as an experienced developer working with a traditional programming language. Implementing movements in events and leaving it for the user to fix to their purposes probably just shifts this difficult problem to the user, which may be suitable for expert users, but probably is not much help to the majority of less-than-expert users.

    However (mostly aimed at other posts in this thread) I don't think it's fair to say that the behaviors are useless if they don't serve your purposes or they are missing your favourite feature request - as far as I can tell, they are very useful for the majority of users, and we frequently hear positive feedback about how effective the behaviors are for many users.

    I just wanted to say that the behaviors are indeed, not useless. But they are what they are and don't offer much beyond that if that makes sense. Its the lack of control at a finer level that I find "lacking". And I wholly understand your point about the whole average user vs expert user. But I think there could somehow be a way to accommodate both. I think the platform behavior is great for busting out a simple, normal platform game. Shoot, there is even gravity flipping available which is less than a common use case would need. So in that way, isn't the beginner- intermediate user base satisfied?

    I'm not wanting, more behavior options but rather access to more basic things. An advanced tookit, similar to what can be found in other engines, with good access in the sdk and in the event sheet is what I want... and it is important that they can be accessed seamlessly in both places. Things like ray tracing and surface normal info, Collision detection that yields more information, collision masks, bitmasking, polygon overlap area, point based collisions, and so on.

    The most that construct 2 offers at a low level is push out of solid, but that is it. You can access it as a custom movement behavior, or you can access it in the sdk, but that is the end of the tools for collisions.

    And as pointed out, it seems likely there amongst the advanced users there is more demand for the tools to make a platform behavior than simply a behavior that handles platforming, right? And I think this can be extended beyond the platformer behavior issue and apply to the rest of construct.

    High level tools can only go so far, if you can't modify them at a low level. Low level tools would enable much more possibilities and those are the types of things I want most in a game engine. Many of the behaviors work well in the way they are intended to, and they make good jump off points. But at some point one needs to delve deeper to make something unique.

    I also think I understand that either way, this is a difficult issue. Construct 2 needs to be accessible for the beginner (I use it to teach 3rd graders how to program). But it would make sense to offer more expert options.

    But ultimately construct is your project and not mine and I am glad you made it!

  • (insert list of problems with platform behavior)

    You nailed it. and this is like you said, just off the top of your head.