nimos100

"- That so many things requires workarounds to function is at least on my very top when it comes to C3, spending close to 70-85% of the time when using C2 creating weird workarounds are really not something that makes C2 shine."

Exemples? (not asking for a bug report, just what you had to work around so we understand the issue so someone could correct that, as workarounds are the opposite of good design)

Refeuh perhaps more stable functions for social integrations for web based games (I mean, the facebook plugin is outdated, there is a third party plugin but why keeping the one in the first place, depreciating it would be wise, or redoing it), web monetisation would also cut a lot of wrapping as some people seems to wrap their games just to monetise it.

My 2 cents obviously, but I think improvement on the web export and its advantages would be nice to have, as it is what C2 is doing best.

Early 2011, I would guess they were using construct classic too.

https://www.scirra.com/manual/126/system-expressions

"distance(x1, y1, x2, y2) Calculate distance between to points"

Two*

To make a game, it is far more important to know how to organize your ideas, concepts and thoughts rather than being a programming expert, without this you won't go far.

Then you need to know how to do things in said language, the basics (syntax, expressions, etc..), how to do a clean code, how to optimise it, etc..

But keep in mind that doing the implementation of the game is something that comes after knowing what you want, I see people asking "how to do this? To do that?" While they do not even know what they are even asking for, limitations are not something you should have in mind while designing the game, design the game as it should work in a perfect device, then see it with a more realistic eye, after all, we can see heroes of might and magic on a game boy color and it works just fine.

Some people seems to think that programming and designing is the same thing, it is not, remember that a clear document that defines the exact mechanics can be easily translated to code, don't adapt yourself to a language, adapt it to what you want to obtain.

First: every trigger does not count (apart from false trigger like on collision or on gamepad button pressed I think), they are not checked every tick, they just happen (it may be implemented to be a check but it is unlikely for things like on start of layout or on called function or even on created and on destroyed for exemple), so they are unlikely to slow anything down.

Then every event that is not a trigger will be checked by the order of the conditions, when one is false, the next ones will not be verified, so in reality most of your events should not be doing as much as you think they are, also just checking a good chunck of values (like some conditions that are easy) may be quicker than checking a small amount of collisions, so the overhead of the event existing by itself is not something that problematic.

For good measure, I suggest the following:

• think about the interactions before trying to implement them, if you do not know what you want to obtain exactly, your implementation can be dodgy, hard to read again, and not as clean and fast as it might be, if you know exactly, just implementing it can be a matter of seconds in some cases
• When something is prone to be repeted over and over, try to use a function to simplify things and make it easier to edit and use (for exemple, a function that will make a dialogue display appear, with the wanted dialogue), project files might be a nice idea to store a lot of dialogues inside texts files.

By better, I meant that when scirra and ludei tried to work together (I think it started before I joined the community), it just plain did not work, now however, most of the issues with canvas+ seems to be corrected, and the open source plugin works as far as I read.

I am not talking about the said official exporters, chrome is unreliable short term (they broke things too many times) and long term (preserving the aspect of the past of the web seems ro be something they rather not do), and so it should not be the solution someone uses.

Actually I always feel like no exporter should be officially supported, C2 does html5 and javascript, just let the community choose their preferred wrapper between all that exists and like natural selection the better ones will stand out.

I kind of see how it could be useful, I guess it is doable manually if you define the position of everything with equations relative with time on both axis, but it is troublesome (except if you are passionate with useless maths usage =p).

I did think about a way to record the sprite position every tick in an array, as well as the time, then just read it and interpolating between positions with time, never actually did it (every time I want to do it I am away from C2 somehow).

Historical issues of communication troubles between scirra and ludei

to be honest, it seems to be better that way.

amkp yep, in android 5 it is like this as far as I saw, but you then have the issue of the auto updating webview that breaks your game, whereas with crosswalk, the version will not auto update.

There is also the solution to post the game to the web if the auto updating is not an issue. Plus you don't take responsability for chromium specific bugs theorically, but it seems to not be a popular solution.

Every single collision check first verify if the bounding boxes are overlapping before doing the actual check, so I am unsure the result will work out that much with distance, even though a pick nearest before a collision seems to perform better (when it can be used).

Quicksand I think it is both, at 60 fps, the current chrome just does not render properly (the jank) and it is really annoying to look at it.

And below, on some circumstances, the controls become too unresponsive and so, the game becomes unfaIr.

Both issues are relative to chrome I think, but I could be mistaking.