...you have already the script to make your game, and the performance will be just a bad memory

lol so true, offten times there is no shortcut

I complain just the organization of the events, because it's easy to says "use groups, use different page, comment...etc) well, this works if you are make a easy logic of the game...if the player has a easy gameplay like (walk, jump) but when you make 600 events just for the player because of the gameplay, can be pretty hard... because a block of event take a lot of space, and the comment go in top or below... for that, I suggest to make a option like you can choose the color of the single event... will make easier to read the event just by eyes...I don't "feel" good when I'm working with a lot of event block, because I can't see my logic pretty well...

I agree, easy logic is easy to put in events, but complex events get very heavy, even with good organization.

wow this got big 0:

i will just add more examples of Unity stupid things

THE GODAWFUL!! Input manager!! oh sweet mother of bambi, the input system for Unity is a big BIG mess!! and cant be change in runtime, there are some input managers in the assets store, so be prepared to pay 30$ if you want your game to look professional

The community! i asked for help 3 times, none got a single answer, here in scirra, there will be atleast 1 answer

You have no idea how many days I spent working on base code trying to address this issue. I don't understand how a product of Unitys scale can have such a mind blowing problem. I made my fix to the problem. I then bought other peoples fixes to learn some more. In the end, it looks like most solutions are a mess of polling. But, Unity is about making money. I feel construct, given its intimate size, is much less about that. Unity doesn't need to address half the problems it has because it can make money off of other people doing the work and selling assets.

To be sure. The C2 community is by far much more helpful. People actually talk and share on these forums. Unity can involve alot of asking questions and not getting answers.

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.