I agree that a plugin/effect manager would be nice to have, like a built in store of plugins, with changelogs and all that, but that could also work with official plugins, after all, it would make updating C3 less often while still have the top notch.

I've got a layout where I put the sprite pieces to my bosses of my game in. The sprite pieces have a few frames each. I make sure that they work well with the boss and then once that's done I cut and paste them to what I call the BossPiecesLayout, just so I feel organized. Every boss that I cut and paste the pieces into the layout, Memory Use Increases by about 4mb. Why is this? How concerned should I be? What will this do?

If by increase by 4mb you mean the "memory use" indicator at the bottom increases, then I think it tells you that basically the layout that in theory uses the most memory will be using that much, if said layout is just a "dummy" layout with all bosses in (seems like it as it increases when this layout increases), then it is not as concerning as said layout won't be used in game.

Still can be a bother as the indicator kind of lose its purpose.

Well, to be fair, all C2 does is basically webapps, those can be wrapped up inside something like crosswalks (so if google was banning every single wrapped website, they would ban every single game that are given as apk made with C2), but you could also simply wrap a website inside crosswalks itself if you wanted to (that is what the clay games app does, it is just clay.io wrapped up

https://play.google.com/store/apps/deta ... clay&hl=fr

http://clay.io/

.)

So I guess you could it too.

However I am agaisnt the fact of wrapping a website inside an app, if the website is correctly set up there is no need, but as far as I know it seems to be just me so..

Last time I checked, there were no limitations on the number of layout, the main issue that could cause is the fact that a lot of layouts can sometimes be a pain to manage (a layout is not a level, it can be a menu, multiple levels, it all comes down on how you use them)

— if it is the reason why safari is faster, as there can be a lot of things that can be slow from the browser side even before or after the compilation.

Also safari I think runs only on iphones, which are defined, with hardwares fully known by the browser vendor, which is also the OS vendor, far less compatibility issues have to be worked around, and since compatibility is always put before execution speed, there may or may not be things that are not as fast as they could on android browsers' side just to make sure it works correctly.

As far as personnal licenses go, you can use them on every computer you want as long as you are the only one using it, I would suggest either getting the license on a private usb key and placing it in your documents folder under your session, or simply set C2 so it looks for it inside the usb key

(One thing that can be done is to install C2 on said usb drive, and placing the license inside for convenience)

You can also I think get back a copy of your license from the store if you need (unsure if it still works that way as, well, the store was not the same when I got mine).

I would say the editor overhaul is much, much needed.

Also, not being native is not the only issue, some things in C2 are just not good enough (keep in mind that a game can have some crappy optimised parts and still run perfectly, a game engine not so much, as each quirk will be present in every single game and if someone is to rely on them well..):

-AFAIK, the collision system is not perfect, ok, they used collision cells to make it "useable in larger worlds" but this is still a potential issue and bottleneck (I know, is overllaping is faster, but it is still not as good as it could be)

-events runs on a single core, and other parts of the engine do, I know it might not be a big deal but I think some progress could be done regarding that (as I think big limitations can be implied with a multicore system)

-the physic engine is simply not as complete as it could have been as far as I could gather, also, it is totally framerate dependant by default, try on a 120Hz monitor and the simulation will be twice as fast, I understand the logic behind that though (this may be the only case where locking the framerate to a value is a valid choice)

-something doesn't work? Welp, too bad that thing could potentially break projects, won't fix

-Users would rather rely on using events directly rather than using the plugins, if we are to reinvent the wheel, might as well go with another engine

-third party plugins and official plugins are not treated equal, third party plugins are updated by hand, official plugins updates are tied with the engine (a quick analogy with IE updates being tied with windows updates in the past is enough to show how bad it is), also, needing to update third party plugins by hand rather than having basically a way to open C2, check a plugin store list, see which one can be updated and the changelog that goes with it (official ones too) would make using third party plugins a breeze I think (and believe me, some third party plugins are nice).

More related to the exporters now:

-well, this one is a big one : limitations are not consistent, they simply aren't, two differents hardware can work the opposite way we would expect them to, just by virtue of blacklisting, we can turn blacklisting off ? Hurray, but then the device simply does not support webgl and just displays a black screen, what then (my netbook will not support webgl, ok it is outdated but still, if your plan it to make simple games, it will even fail in that regard)? Or if the blacklist fails (AFAiK, I cannot turn webgl back on chrome on my galaxy tab 3, not that chrome was a good android browser experience anyway for me, but still that is a problem)

-kinda related to the first one, games are not future proof, they are not dependant on browser features only, if one browser decides than it is over for platform X, then it is over for it, end of the line (I know nw.js and the likes can be a partial solution to that, but let's be honest a second, why people wanting to make a browser game exclusively would want their users to download an executable, it is even worse than downloading a plugin).

We will always rely on third parties, yes

We will probably won't benefit from having native exporters due to the amount of time needed to polish it, probably

We can rely on browser vendors to keep things working in the long run C2 wise, absolutely not, They simply don't care enough for that, I would not be surprised to hear that chromium guys are only testing the most games related features on chromebooks, also mobile web browsers have issues that simply breaks games (the slow decoding chrome issue alone can render your game a painfull experience on mobile, we also had the time when a beta webaudio api was used in C2, and broken by chrome to the point it was unplayable), that doesn't mean we cannot do anything great inside a webbrowser (..well from an economic standpoint there is currently no point in doing that but I am staying in the non commercial kind of things) but we need to be sure they won't screw us with one change, or to be able to face it without issues.

As for unity, for a native experience it is good, but from a webbrowser one I would be curious to see if it is worth it (not with the web player plugin obviously)

I think at one time early adopters only could have both licenses, I do not know if they provide that service for everyone having a license (pretty sure they don't but email them).

Last time I saw the multiplayer exemple, it was working across devices (I was on chrome on a android tab, and others were on PC, the controls however were not designed for mobile so I could not do a lot inside the game and see if everything responded correctly without lag).

An advice for your players to make sure they are over a nice network could be useful, as mobile networks cannot be reliable in some situations, while a personnal Wifi network to access the internet can be fast even on mobile.

I think I saw that only when the browser window was maximised before requesting fullscreen, if it is windowed normally (resizable) it goes fullscreen, I am not sure why could be the cause for it, as I think it was fixed in the past.

I guess the number of changes suggested and the precision of them can make the difference between the two, however that is a weird question still as I don't think it is a case we can resume simply, like if tommorow every car became a automatic car you just ask for the destination, what defines a driver or even a taxi driver then, hard to say..

In that case, the term developer could still apply if the person see what the IA does and suggests changes I guess.