> [Scirra should] determine whether their products do indeed have bugs without placing a lot of that burden on customers...

>

> Unity devs... often provide steps for me to check if something is a bug in the product

>

So it's OK for the Unity devs to send you steps to check if something is really a bug, but not us?

If you get some report with steps (e.g. Here are the steps I used to reproduce, here is my full capx), it is absolutely ok if the response / instructions are you saying that you can't reproduce with those steps and asking for additional information, asking them ot try things like trying disabling of a behavior or function, adding or removing some event, running a profiler, etc. In other words guidance on performing the debugging. - e.g. actually trying to figure out if the specific issue is a bug through knowledge of what parts of the engine may be causing the behavior. Devs of the tool often have a much better sense than users about that. One example I want to point to is an issue I had with one of Rojo's plugins. I spent a bunch of time trying to figure out what was going on, reported my attempt after failing in his thread, and a simple "Oh, this plugin runs after all of the event sheets are processed" by him helped me to solve the issue. The issue was obviously not a bug but it was not easy to determine without being prompted to that highly relevant bit of information. These are the types of prompts / instructions that are actually useful, and may not really require a ton of (or any in this case) investment in looking through someone's code / events etc.

It's not ok if it's "I don't really care how trivial or complicated your specific situation may be to check, can you re-code a new project from scratch anyway, that only has the minimal necessary parts to reproduce the bug?" which seems to be the current policy.

I don't think it's that you have inexperienced users (e.g. some of the other tools I mention are aimed at inexperienced users as well), I think you generally have too many users for the dev team size, low priority on support vs adding features or focusing on C3, trying to provide equivalent support for both paid and free users, or perhaps there are more issues that arise with C2 more frequently given how disjointed it is with its dependence on any number of constantly changing technologies. It may take more time to determine a C2 issue given that last point so maybe that's why support is how it is. I don't really know and I guess as a user it isn't really my job to figure out the reason, only the result and situation. I'm not really interested in an excuse as to why C2 support is worse.

And maybe there are other products out there with equivalent or worse support than C2. Maybe I've been lucky until now to only buy things with good support (haven't used Gamemaker much or whatever, maybe that one is bad). In that case if that's the level that Scirra aims to or is capable to perform at, then so be it. Just don't be surprised if people opt for different tools and post their experiences of frustration on the forums

tl;dr

> Of course Maybe something worth for them to invest in.

>

If you expect more (or "better") support and Scirra hiring ppl to support you and your projects, then you have to expect higher product prices (of course, one has to cover the cost). But if the product gets pricey, you start complain on the price, because the product hadn't changed that much? (look at GameMaker, up to 800 USD!)

I like the idea of asking some of the mods here to contribute, either pro bono or for some bucks and the reputation. Might help to filter out the real C2 problems.

On the contrary, support for C2 is abysmal, it's not at all close to anything I've experienced before. It's not an issue to support me but their own products. They should have a vested interest in figuring out if something is a bug in their product or not WITHOUT depending on a customer like me to produce some tech demo to expose it. As I said they should not be trying to fix MY bugs but trying to determine whether their products do indeed have bugs without placing a lot of that burden on customers to create these example projects and reports.

If that costs them more money they absolutely should charge more for C2, or alternatively devote some development time that would normally go to new features toward support. So far though just to give you a comparison I've spent $0 on unity and $45 on the toolkit I'm using for it and have yet to be forced to create a minimalist project or else have my bug report dismissed by either the toolkit dev (one-man team, less customers than Scirra I'd imagine though) or Unity devs. Instead they investigate it, often provide steps for me to check if something is a bug in the product, and if that fails they check to see if their product indeed has a bug. Both the small-time dev of the toolkit and the big-time devs of Unity have correctly disbursed their resources so that support of this type is available. I don't see why Scirra has failed in that department but no, it is not the case that it has to be this way. In my experience Scirra is the outlier with substandard support, not the rule.

Also by providing great support, the toolkit dev has earned my repeat business (e.g. looking to commission the toolkit creator for additional features just as an excuse to give him more money for his great product and support, and will also be picking up a new product he's putting out soon). On the other hand, probably would not ever buy another Scirra product again even though C2 is a great tool, due to horrible support.

And if Scirra needs to charge more to be able to hire people to minimally determine if their product actually has bugs they should absolutely do so. Selling buggy software and then making it the job of the user to identify the bugs and create elaborate reports or tech demos is in no way acceptable. Better methods are already employed by any number of companies. The small-time dev of the toolkit I use in Unity for example sets a couple of hours aside every day for this purpose, and will once in a while take a week off development of new features to catch up on issues. I'm sure it slows down development of new features compared to not providing support, but it's well worth it.

> Not sure what Microsoft does for Visual C++. On the other hand, I've sent my project to Unity before and while they don't debug your project, they replicate the steps you provide in your project, and determine if the bug is your fault or not. And I don't have pro. They also recommend a minimal project but won't just dismiss it if you don't do that.

>

The Unity team has 200+ people, it's like comparing China to Sweden

Of course Maybe something worth for them to invest in.

Not sure what Microsoft does for Visual C++. On the other hand, I've sent my project to Unity before and while they don't debug your project, they replicate the steps you provide in your project, and determine if the bug is your fault or not. And I don't have pro. They also recommend a minimal project but won't just dismiss it if you don't do that.

The bug report guidelines are there to help you too! They exist because bug reports that don't follow them are generally completely useless, and we cannot do anything to help you. People very often do things like report a bug which is nothing but a screenshot of an error message. There is usually nothing at all we can do about that. I actually want to help, but bug reports which don't provide the necessary information are impossible to do anything about. It's also common that users blame the wrong thing in their bug reports, e.g. that audio is broken but really some other bug was breaking an event that played audio, so I need the actual .capx project to investigate what is really going on since if I dutifully went off looking for problems in audio I wouldn't find anything and the bug would not be fixed. I know it can be tricky to follow the guidelines, but it's important to be able to actually resolve the problem. It's also very common that bug reports turn out to just be mistakes in events, and the engine was working correctly. It's very costly to developer time to spend several days picking through someone's 1000-event project, only to find their events are wrong and the engine was working correctly all along. We simply cannot afford to be doing that over and over again with every bug report, since we'd simply never have time to actually fix all the issues that are reported, let alone develop new features that other people are asking for. So the minimal project requirement is important to prove the problem is not in your own project logic. Performance bugs can be an exception to this since it depends on the full project; I have several in my email inbox at the moment which I will investigate in due course.

I agree that you need guidelines for bugs but I think Scirra treats this as an open-source type of project instead of a paid software. Even if a 'bug' is an error in my part I expect support for a product I paid for to help me resolve it without having to re-code some tech demo or dismiss the issue altogether. Usually the way other companies do it is that if steps to reproduce are provided they'll try those steps in that project and see if it's something simple. Other times they'll have some profiling or debugging tool or instruction for the customer. So if the Bug forum isn't the right place for this, then a Scirra Support Forum should open and issues that don't follow the Bug format can be looked at there. As I said, usually when I buy a software package and I run into a problem with it, there is some support that helps me figure that out without a huge investment of rebuilding something from scratch, or at least specifically prompting with the steps useful to the developer to figure out waht's going on, e.g. "have you tried X, Y or Z?", which ends up determining if it's a bug or of if there's some other solution. So yeah I guess as purely bug submission the strict guideline can be good, but only if there's some alternative to solve issues with the product in general. Looking at people's projects is unfortunately part of what providing support for this type of software means. At least all other packages like this I've owned if the developer can't figure out the issue from my description, they do ask for and look into my specific project to figure out what's wrong. Maybe it's time to start beefing up Support in forums and personnel, at least for customers who bought the product, which can cut down on the number of support requests Good to hear that you're growing as a company though!

Juryiel it's not just experience. I usually don't have time to just sit down and write out all the tests involved in both comparing versions and creating a detailed bug report.

My game has been something I have been working with on the side, and this issue has only really come up in devices that are less powerful than my laptop. So of course if after 6 hours of work I export and only see ugly pauses in my game, I need to move on to homework or whathaveyou.

I will get something together as soon as I can. My plan is to simply export for web in r202, and then r195 - both the same exact project. And neither of them use anything implemented in between so I shouldn't have issues there. This should be the quickest way to get something visible available.

Edit: also, just to clarify, I keep saying this isn't a slowdown, but tiny obvious moments of lag that don't make the game unplayable, rather, frustrating.

I mean hell, otherwise physics area great!!!!! It's simply this one issue. That's it. Performance is AOK otherwise.

I agree, I think Ashely makes it very hard to actually bug report stuff. I think as a user, I'm not going to sit and blindly try to replicate a problem in some blank capx from scratch, or generate some tech demo illustrating some problem with C2 / HTML5, especially when it could be due to things interacting, but Ashely won't look at stuff otherwise, and is generally dismissive of bug reports without an extremely large amount of work done by the user. It's actually really strange to me especially when the number of complaints about similar things is so large. I think the profiler type thing would maybe help us provide Ashely with evidence without having to rebuild various things from scratch, and may help us to better isolate the problems. With that said I have given up on submitting any bug report, I am not here to put all my effort to beta test C2 and develop tech demos to emphasize bugs, especially considering how easily and readily they are dismissed without investigating. C2 really is the worst in terms of support I have ever experienced in a paid software package. I think the team is just too small for the number of customers they have I guess.

Again, this is very frustrating, I still have no evidence at all of any slowdown with the Physics behavior. Mozilla have done benchmarks of the asm.js version that show it performs within 1.5x of native performance. Until I see evidence to back up claims that physics is slow, I can only assume you are either using physics so intensively that a native engine would struggle, or that really something else is the problem.

Some people blame the Platform behavior for being slow too. Likewise, I have no evidence of this.

I think there is a tendency to blame things for being slow without really understanding what is happening. If you think something is slow, use measurements to demonstrate, and share your results and the .capx you used.

Not using any of these behaviors and not sure if they are slow etc, but in general you're asking a bunch of beginners to figure out what is going wrong, which I think it's tough in many cases. Maybe have a process where you instruct them on using the profiler (give a case-specific example for each complaint?) to determine if a particular behavior is indeed the issue. The profiler itself may need to be more robust, e.g. to break down the top events that are using most processing time, so something liek 20 % on A, 10% on X, 5% on Y, 5% on Z, and 60% on everything else, with the ability to expand the 'everything else' category. This might make it easier for people to optimize their games and isolate true issues vs perceived ones. I'm not sure how possible this is with C2 but I know coding some intensive simulations in MATLAB the profiler that lists each operation line-by-line and % of computing time it takes to be invaluable in isolating these issues.

Best thing to do is to just use C2 for only desktop games in spite of what may have been indicated by Scirra in regards to mobile export / performance. You will be happier The wait on these technologies that don't really care about gaming (e.g. chromium) is not bound to make you happy any time soon.

In fact I'd bet that it's extremely likely that C2 will be deprecated / abandoned for C3 by Scirra way before web technology is developed enough for C2 to put out reliable mobile games. At least at the rate we're going now. I imagine C2 will stop being developed so will eventually fall out of compatibility with the always-evolving web tech. But C2 is still a great tool for 2D desktop games, so focus your energies on that. It's kind of a shame but it is what it is.

As you said, it's not the events that make C2 fast, but the behaviors. I can click 2 things and have a platformer engine ready to go for example. Click 2 more things and all my objects now have physics. Etc. You can do this stuff with unity with assets but obviously each of those costs money so it's hard to experiment ahead of time.

I do think event-sheets are much slower for me than programming.

To me it seems that the issues with C2 performance are related to HTML5 implementations. IE seems to actually run my games super smooth, but chrome seems to do worse, even thought they're all pretty simple, and even when Chrome says 60fps, it doesn't 'feel' quite as buttery smooth as running it in IE. C2 is also the easiest to develop with if you're not a programmer (and even if you are for simple things it's quite easy). It has very nice built-in behaviors that will do a lot of the work for you.

So if you want to go with an HTML5 game, probably C2 is your best bet. But as I said before, HTML5 to Android / iOS can have a variety of results. For example, in my case there are documented Chrome bugs that Google doesn't care to fix for years (as gaming is not their top priority, instead they focus most of their efforts on making Chrome secure), making some aspects of my game's polish not possible. The reason the state of Chrome matters is because the main export option to android has been (at least until recently) Intel XDK which is based on Chrome. There are other options like CocoonJS, this was abandoned for a while and did not support native AdMob ads but now ludei seems to have updated his C2 plugin, so I'll probably give that a try soon. It seems like it may be a good option again ,but i can't speak to it just yet, and it is not officially supported by Scirra (although it was in the past and may be again in the future, the technologies C2 depends on and supports seem to be in a state of constant flux, although again, Intel XDK seems to have gotten the most focus as of late). Results seem to vary wildly by each game, on which export option works the best, which to me is just another way to say that mobile export is 'unstable'. It works, sometimes well, sometimes poorly, and you won't know ahead of time which. Another issue to consider is that Intel XDK adds about 40mb of useless browser engine (since it's based on Chrome) unrelated to your game. So your game will have an extra 40mb in size than using a different export option, meaning you may run into the google play / iOS store file size limit more easily.

If you want something that isn't based on HTML5, which is likely to run your game better on mobile platforms in spite of what Scirra / Scirra loyalists may say, there are better options, with my favorite being Unity + some toolkit appropriate for your game-type. There are actually quite a few Unity toolkits that can do a lot of heavy lifting so that you don't have to do much coding, but this will probably end up costing you somewhat more than C2 as each is tailored to a specific game-type, so you may need more than one if you want to work with different genres.

Overall, C2 is a good value for the money it costs, so you should buy it anyway. But I would not try to make a production-quality mobile game with it, nor a production-quality game with it on any platform that involves substantial amount of work. Part of the reason is because support on bugs is lacking since it depends on 3rd party technologies that are still in alpha, beta, or other development stage, meaning that Scirra cannot fix those bugs and will often redirect you to said 3rd parties. However, 3rd parties often don't care about the bugs as high priority, leaving you stuck. This in turn means that making a game that requires a lot of time is very risky since your work can be wasted. C2 is great for smaller/simpler games or web games though, and for putting together a quick prototype of various gameplay mechanics to see how they work together before making them into production on a different tool.

If mobile is your main goal I would probably not. None of the export options are great at the moment, and critically, depend on 3rd party wrappers, so often times bugs cannot be fixed by Scirra until 3rd parties get around to it. Often this is not a priority for them so you could be waiting for a long time. I would at a minimum wait until Crosswalk / CocoonJS and the rest improve significantly.

Hmm I also think I found an issue with the Pin behavior. When I use the pin behavior and pin object B to object A, if i move object A the pinned object is delayed it seems (again, comparing side-by-side of the same exact thing with or without the paster). Is there some way to fix that?