Bump

Anyone use the Google Play plugin who can help?

Apparently all I can seem to do is log in, not submit any scores / achievements, etc.

The game is in 'Ready to Publish' (but not published) stage in the google play dev console.

I log in with my tester accounts to try to submit scores or retrieve various information, none of that works, even though the plugin reports it as successful (the success trigger triggers)

I've added the correct client ID, App ID, and Secret

For credentials in the dev console, I have both localhost and localhost:50000 in both the 'origins' and the 'redirect' boxes. I'm trying to use the preview obviously to do the testing which is why I have those.

I wait for the plugin to finish loading before anything else happens (all other events are in a disabled group that only becomes enabled when Is Loaded returns true)

Anyone who has successfully used the GooglePlay plugin and can help would be appreciated

I'm trying to set up google play services. I followed the tutorial, and I'm able to successfully log in users, but there's an issue with changing users. I'll try to explain:

1. If you're not logged in at all, and you click the login button, it will pop up the google login window and this will work fine.

2. if you've logged in before, it will automatically log you in.

Ok so far so good

3. If you click log-out C2 seems to think it worked, but then, if I click log-in button again to try to change users, the login window that pops up is either blank (in IE) or quickly auto-closes (Chrome).

4. Even after logging out, if I refresh the game preview, it will auto log-in as the person who logged in last

How can I get the log-out function to work so that new users may log in? The ONLY way I have found to do it so far is to go to a different google website and logout from there, then and only then can a user change in my game.

If any additional info is required let me know.

The Ejecta thing seems promising (ugh I have no mac ) for iOS since scirra will have some control over improving it since it's open source. Maybe something will come of that. I'll check on it in a few months see how it's doing.

Looks like my collection of monkey-related paraphernalia will not be growing... this time

It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

It's clearly a matter of degree. The more pieces out of your control the more problems especially at the level of exporters where controlling them would give a lot more power in even implementing workarounds for other peoples' bugs including some driver bugs etc. Obviously you will never have 100% of the control, but you can have quite a bit more by controlling export. But even so, the main problem with third parties is, as I said, that they don't make us a priority since we are not their customers. If NVidia gives bad drivers for cards users paid them for, those users will go there to complain and NVidia will respond in some way. Going to Ludei does not seem to have this same effect, especially since I didn't give them any money. I'm sure there's other intermediates that don't respond to users but may respond to developers etc. So maybe that's what you guys should do instead, work with these third parties more closely. I do think that in the very very very long term there will likely be some tool that is robust enough. But that is just so uncertain that putting effort in C2 right now doesn't seem worthwhile, since there is no idea of when it will come. In the end, I don't know, you have a lot of theoretical arguments and reasoning but in practice things don't seem to be working out anywhere near at the level of C2's competition and I think that's really what people care about. Maybe this will change.

Anyway the new game I'm playing now is to see whether I finish my larger unity project before C2 export is in a state where I would feel proud to put out my games

This is now fixed on my device. Also I guess maybe having medium precision shaders as an option could be good for performance?

> I've already completed both a game AND its sequel ... I need to first be able to reliably export my games to my target platforms.

>

> Scirra ... are aware of the state of mobile games with C2 ...So it is clearly willfully misleading.

>

Yes, the current state of mobile games with C2 is bad, I'm not denying it. But exporters don't help you either! Making feature-compatible native exporters for android AND iOS would take a long time, so you would have to seat on your games for at least another few years! Also, by the time those years pass, the devices in the market will already be powerful enough to run your games, so the exporter would probably be redundant.

Now, I'm assuming you already tried to optimize your game and even sent a capx to Ashley for guidance, and those things didn't work. If so, right now your best bet is to hope intel exporter works better, or that C2 integrates with Ejecta, and that ejecta somehow solves your problems.

There are no quick solutions to your problem. You are right to be angry that mobile sucks (but to be honest, threads complaining about performance are nothing new, why did you insist on making mobile games when the whole board consistently complains that mobile is broken?)

I'm still finding workarounds to things to get my game to work and have largely moved on to my larger Unity project until an undetermined time, for now. The particular game is not the issue because these are small autorunner test games mostly based on the autorunner template and therefore SHOULD work (but don't) since the meat of the games is mostly made by Scirra themselves. The problem is, if I can't get these games to work right there is no way I can get a larger project to work right. In essence, these test-games demonstrate that C2 is useless to me for putting out games right now so I do not invest more time with it at the moment. I understand that there are no quick solutions, but I disagree with the problem. I think the problem is one of 1st vs 3rd party. The problem is that scirra doesn't control their own exporters, so no matter what the quality of their product as far as C2 goes, the resulting game quality depends on other parties, and many of those parties don't care about my game because I am not their main target customer (e.g. Ludei). So I think 1st party solutions are necessary, even if it takes long, effort has to be started sometime, or if not, at least official partnerships between Scirra and third parties have to happen. Scirra has to do something to ensure quality since they are the only party who has any responsibility towards me (as I am their direct customer, I am not google Chrome's customer). If it's not started now we'll be in the same boat a year from now.

The reason I insisted on mobile is for a few reasons. CC is good for desktop, I don't need to use anything else. If I want something more than CC, there is Unity. The fact that CC exists largely allows me to not care too much about the money I spent on C2, I try to think of it instead more as a donation toward CC, which deserves it. Another reason for mobile is that I had tried CC and seen that Ashley is a great developer and very knowledgeable. His expertise gave his defense of C2's state more weight in my eyes rather than other users who complained. People complain all the time for all sorts of things, and it's hard to know if those complaints are valid, especially when Ashley, whose work and knowledge is proven to me, posts disagreements about how things are the users' fault. He's been getting a lot of push lately so he's been more willing to admit shortcomings especially in this high profile thread, but that was not the case for a while. The third reason is largely, again, because I trusted the people behind Scirra, I gave their 'sales pitch' page more trust than I guess I should have had. I should, in retrospect, have done more homework. Unfortunately that was not possible because mobile export is not testable on the free version. I think in retrospect, given my bias to trust Ashley's expertise, I think the only thing that would have convinced me that the users were right and Ashley was just overselling the state of mobile would have been those videos Arima posted earlier comparing C2's performance. It's a shame I didn't find those ahead of time.

In any case I don't see why it matters. Clearly many mobile users seem to agree that they were mislead about C2 capabilities and that should be enough to conclude that it was not somehow just me misinterpreting the message Scirra was putting out. Therefore my specific reasons for picking up C2 for mobile development are not relevant.

Whoah, it's not like that! If I really cared only about myself, I would be pressuring Scirra to add more application-making features, since that's my primary source of income.

What I'm advocating are features that help EVERYONE, not just mobile users:

• Better/more integrated tilemap object
• more/better modularity features such as widgets and nested objects
• ability to run construct apps without draw calls - for server-side programming in multiplayer, so you won't have to code your server in a different language - this would make small MMOs possible within construct, for instance.
• better ajax support
• collaborative design capabilities (two people working simultaneously on the same game)
• an IDE SDK
• converting the editor to open web tech and opening it's source code (for the IDE only, again I'm not talking about the game engine or the exporter)
• who knows, maybe even an exporter SDK, so people like

  tomsstudio can try making their own native exporters

But how are these features useful to everyone? I've already completed both a game AND its sequel (by completed I mean they work on desktop) but I've been sitting on them for a while now because mobile export is not working well. How exactly does anything on your list help me or others like me? The issue is, all the things you ask for are extras in the face of basic functionality lacking from mobile users especially on iOS. Those things are all good, but before they become useful to me in any way I need to first be able to reliably export my games to my target platforms.

As far as whether what Scirra is doing is 'malicious', I'm not sure if that's how I would describe it, but it is certainly willful. They are aware of the state of mobile games with C2, yet rather than making it clear they choose to only say positive things about it. My guess is because doing otherwise will cost them customers. So it is clearly willfully misleading.

If you guys want to pressure Ashley to focus on mobile exporters, then I am within my rights as a buyer to pressure Ashley to NOT focus on mobile and keep his current strategy of a pure-HTML5 product. When this product started (and when I purchased my license) it was all about the desktop, so when business decisions start impacting the quality for me (and make no mistake, if Ashley were to focus on native exporters, the desktop side would suffer), I have to speak.

You have a lot of opinions about how what you want is whant really matters which largely makes those opinions irrelevant to many C2 users. I don't want to pressure Ashley into doing anything other than what C2 claims it can do, regardless of my own uses for it. If he doesn't have the team size to support those things maybe it would behoove Scirra to stop implying those things are supported. C2 and mobile is not ready, and the fact that there isn't a huge 'Beta' or even 'Alpha' tag when they advertise that means that Scirra is misleading us. Scirra can't have it both ways, where they tell paying customers their product can do something but it really can't. They should support both mobile and desktop because that's what they claim. They should not support only desktop but proceed to collect money from mobile game designers by promising a mobile game design product and then funneling that into only improving desktop game quality while mobile game quality is, at this point, unworkable in most cases.

You're thinking about this only from Scirra's perspective and your own perspective, but not from the perspective of small design teams with small budgets who blow their budget on C2 due to misleading promises of mobile support only to find that they can't actually make their games. C2 is not CC, where Ashley is making it for free. Ashley is selling us a product and making claims about that product. The options are to either stop making those claims or to fulfill those claims for all customers. Anything else is not acceptable, nor do you get special preference because C2 originally started with desktop support.

Ok, will do.

I have since stopped using the toon shader (I only use shaders to mockup stuff that I later put directly into the art), but I can run some tests and figure it out, I think the browser was definitely a version of Chrome, and the device may have been the HTC One X on Sprint but I'm less sure on the device.

Relates to this maybe:

https://code.google.com/p/chromium/issu ... ?id=245755

essentially sounds like a bug in the drivers that allows chrome to detect available precision correctly, or maybe some other problem causing Chrome's detection to fail.

There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

The appeal is that once the task is done it will be under Scirra's control. When it's 3rd party control and that 3rd party doesn't make C2 a priority there will always be serious issues cropping up, like the recent and sudden drop of support for XP and Vista. It just makes it difficult to justify using C2 on anything other than just messing around. People will try it, buy it even, find out it isn't a serious platform, and move on. If you were to track your users I would imagine you would find that this is a common pattern. Why not hire someone, do a kickstarter or something, so that it doesn't hold you up? I would be more than happy to donate toward development of exporting tools that are quality controlled by Scirra. I imagine many of your customers would be as well.