Disappointed over bad communications!!!

> 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.

Trying to debug someone elses work is frustrating at best, especially if its undocumented

Functions and event sheet includes spread out over multitudes of layouts, hidden by groups, and events that are only describable as non linear.

The phrase "help me help you" comes to mind.

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.

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.

You are talking like they would still be a garage devs. I believe they are more then enough capable to finance couple more workers.

You are talking like they would still be a garage devs. I believe they are more then enough capable to finance couple more workers.

From what I've read, Ashley is the only one who works full time on C2/C3. Tom is dealing with the Arcarde and some ppl help them running their business.

And, to be honest, this is a good setting for a smaller company.

> 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.

>

You are talking like they would still be a garage devs. I believe they are more then enough capable to finance couple more workers.

They, uh, have -

GREAT! Best news in ages, i hope he/she is a code wizard, doesn't need sleep, and has great idea's !

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.

Juryiel

i must say that Ashley does a decent job at debuging.

I my self reported several bugs and only one proven to be an actual bug... rest was my not understanding of C2 logic.

I can understand frustration when you develop huge project and cant easy pinpoint where things had gone wrong... but actualy making sample capx helps you a lot in teaching proces so dont be lazy, help them to help you.

For me is far more frustrating fact that Scirra clearly states all possible exports you can imagine and then, later on, you realize cunning deception that its in fact some 3rd party half ass tool that dont works decent... any you just wasted several months of work just to realize that.... and now you can either wait and hope that someone outthere will evetualy fix that or switch to some other tool and start all over again.

[...] 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. [...]

Don't get me wrong, Juryiel. I agree with you. I just wanted to point that everything has its price. (In either way)

On the other hand, Unity is not a good example here (from my point of view). The only thing C2 and Unity have in comon, is that one can use the tools for making games. It's like Wordpad vs. Word. Both do the job.

Unity has a way bigger ecosystem and the productions behind are huge! That makes it also profitable for smaller companies to develop addons and such. And believe me: Unity Technologies started small as well (2003?, 3 guys in Denmark who have failed with their game first)

At the end, Scirra decided to hire a new developer as they understood they growth. To bad that Playtech has aquired YoYo Games and not Scirra. Maybe Ashley should look for some external funding to gain the momentum of this success - and that's what we're talking about: success. More and more poeple use Construct 2, do bigger productions or more complex titles. Now Scirra has to deal with it

they should [...] be [...] 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.

Depending on the size of the user base, this is usually unrealistic, unfortunately, even for very large companies.

When a bug is suspected, it is part of the job of the user to demonstrate what the bug is, and therefore narrow things down in order to demonstrate the problem for someone more technical to investigate the issue efficiently. Support teams or communities can help guide the investigation, but in the end a proper bug report that actually demonstrates the bug in the simplest possible scenario has to be submitted.

That's what QA teams do internally in game studios, they try to understand as much as possible about a possible bug (esp. how to trigger it) before demonstrating the problem to the most relevant programmer. And that's exactly how it happens when dealing with big companies as well, like Microsoft, Sony, Nvidia, Apple, etc. When you find what you suspect might be a bug in the latest xbox sdk or a recent nvidia driver update, which does happen on a very regular basis btw, you don't send your whole project asking for someone to investigate. You recreate a simpler project to isolate the bug and send a test case for review.

The user knows its projects, he's the only one to know what to remove and what to keep to reproduce the bug ; if he doesn't, the user doesn't know enough about its own project. When it takes a few hours or days for the user to recreate the bug in a simpler project, it would take weeks or months for any external developer or support team to start to understand what a decent size project is all about. If the suspected bug is about sprite animation, you don't want the support team to thrall through dozens of thousands of events or lines of code that have nothing to do with sprite animation (controls, audio, effects, levels, physics, etc.). If, for example, a sprite doesn't animate as expected when some specific physics properties are applied to it, that's what the bug report should be about, not "something doesn't work in my project" (just exaggerating but I'm sure Ashley must receive quite a lot of similar complains)

The main "problem" with C2 is that it's almost too easy and/or flexible to use, therefore it is possible for people with very limited technical knowledge to create quite complex things. Which is great - nevertheless, it also means that a very large majority of the "suspected bugs" are just misuses of the product

[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?

Perhaps one of the differences is that Construct 2 users are often either inexperienced or non-technical, and are prone to seeing their own mistakes as C2 bugs, or just making vague bug reports which are impossible to follow up on. It's conceivable that the higher technical requirements for using Unity mean that the majority of their bug reports are high quality reports which really are bugs, whereas it is definitely the case that a significant proportion of C2 bug reports are not bugs or not actionable reports. This would mean Unity can afford to make the odd exception to invest in testing and debugging only to find it was a user's mistake, but we cannot, since it happens too often.

Well, I spend a couple of weeks now in this forums (reading) and - surprise - even with reading thru all the blame here - I decided to support C2 and to buy a license, even If I don't need it for the moment - the free version works fine for me as a beginner (well, I even had to buy a new Parallels license for my Mac just because of C2)

And if I would need 3D, I would buy Unity. And if I would have to do mega big production with 400 levels I might go native and not using C3 - or Stencyl or GameMaker - which have been clearly designed for casual games, platformers and such. If you really need proper physics and high FPS and shaders and console-support, you should really think about the tool you have chosen.

Just my 2 cents.

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.

If you want to compare things, go all the way.

In your example, the toolkit you refer to is a third-part developed tool that is built upon Unity's main framework. In C2's framework, that is equal to third-part addons developers (like Q3D plugin). That is not C2 itself, and is far from the same complexity as far as support goes.

It is "easier" for them to check if it is a bug of their own plugin indeed, since the global framework does give debugging tools, as well as the already general present debugging tools in browsers. Also, the toolkit/addon has a smaller scope and it relies on the assumption that the main framework does what it is supposed to do.

An addon is a modular smaller part of code that is "separate" from the main framework, and works in relation with that one.

Unity team is bigger than Scirra's, so they have more resources they can devote to "support" and as Ashley mentioned possibly look further into any project/bug report.

And let's consider any user sends their 300+ events project with barely any structure or comments for review to Scirra.

After taking time to figure out what the project is supposed to do, how it was made, it happens that it is a user mistake, that is time that was wasted for everybody, except the project's owner who got someone to freely fix a mistake of theirs for them.

Nice for Unity if they can afford that. I understand though that a small structure like Scirra can't afford it. Don't you ?

> [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