Disappointed over bad communications!!!

Again, I had a problem with choppiness of platform behaviour, but after switching to PlatformPlus, issue was gone. It was as simple as that.

So now it's turned into attacks on both personnel and product support!

#I'mashamed

So now it's turned into attacks on both personnel and product support!

#I'mashamed

I don't really like the word "attacks". Its like you are implying something.

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 think the goalposts just moved: we were talking about physics running at 1 FPS, which is a severe performance issue that is really obvious and does not take any particular skill to demonstrate. Now people are talking about jank, which lately has been more to do with Chrome's frame scheduling, which is unrelated to the physics engine. So if I'm right, that's not actually a physics issue.

Ashley

I see you mention "we" here and there on occasion in reference in work needing to be done on Scirra's behalf ... but not to nag or anything, isn't it just you atm ?

I mean, we hardly ever see Tom .. which is supposedly busy with the new arcade/site for over a year.

That is taking some serious time, perhaps have him develop some fully deploy-able games for all platforms instead and outsource the web development.

Because you, Ashley, read/post, write blogs, bug check, develop, give email/forum support, and keep your tech knowledge up to date ....

You seem to be running the show alone. (not meant negatively)

How is 'getting the new help' coming along ?

You have a couple very capable moderators here, would it not it be an idea to look at them for some paid assistance on professional level ?

Even if it was for official forum support, capx file checking etc ... some of these things can take up enormous amounts of time.

Things like, primarily bug checking, case studies with games with lag/jank/overall performance issues, etc, all the things the developer really should not be doing. They (hired moderators/new function) could be the front line, (first line) for most of these problems, and if they filtered through it, recognizing a problem being more then a users mistaken logic ... then they could pass it to you ... I am guessing that could free up at least 1 day a week on your development time.

Ashley

I see you mention "we" here and there on occasion in reference in work needing to be done on Scirra's behalf ... but not to nag or anything, isn't it just you atm ?

I mean, we hardly ever see Tom .. which is supposedly busy with the new arcade/site for over a year.

That is taking some serious time, perhaps have him develop some fully deploy-able games for all platforms instead and outsource the web development.

Because you, Ashley, read/post, write blogs, bug check, develop, give email/forum support, and keep your tech knowledge up to date ....

You seem to be running the show alone. (not meant negatively)

How is 'getting the new help' coming along ?

You have a couple very capable moderators here, would it not it be an idea to look at them for some paid assistance on professional level ?

Even if it was for official forum support, capx file checking etc ... some of these things can take up enormous amounts of time.

Things like, primarily bug checking, case studies with games with lag/jank/overall performance issues, etc, all the things the developer really should not be doing. They (hired moderators/new function) could be the front line, (first line) for most of these problems, and if they filtered through it, recognizing a problem being more then a users mistaken logic ... then they could pass it to you ... I am guessing that could free up at least 1 day a week on your development time.

Scirra has been growing slowly for a while. We're just not making public announcements about it as we go along, but maybe we should. We have people helping with support, software development, business development, and more. There's also a whole raft of stuff you never see from your side like figuring out how the tax arrangements work for the third party sales in the Store, or managing the increasing number of education subscriptions, or optimising the database caching so the site can scale with the increasing number of visitors, much of which I have little involvement in so I can focus on the technical stuff. But none of that changes what a reasonable bug report is!

FWIW Tom is actively working on the new Arcade now - a ton of stuff has meant it's been put off way longer than we originally hoped (ranging from prioritising the new Store with third-party content, to customer-invisible things like adapting to the new EU tax laws). But I think he's full-steam-ahead on that now and I'm hopeful we can have the new Arcade running within a month or two.

We're not coding in our bedrooms any more! Things have come a long way

[quote:1js2senf]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.

Already having expressed my disappointment in how bugs reports are handled. I do however understand that you would like a Capx to test out things when bugs are reported.

However regardless of them adding a capx, the impression you get when bug reports are handled, is that its more a matter of getting them closed than looking into the report it self.

Just because a bug is closed or a bug report is not filled out as you would like them, doesn't mean that it have been solved. Its of great frustration to put together a bug report trying to highlight and explain exactly how and what is going on. To just see it being moved to the closed section as if that would solve it. In a lot of cases (speaking for my self), if the way to recreate the problem is to do 3-4 steps which takes less than a minute to do. Why should the bug report be closed? Even when a screenshot is applied showing that the capx doesn't contain anything other than a single event.

In other cases bugs are not as simple as they can be or would make sense if reported on there own, because they depend on each other. But again these are just moved to closed bugs section, because the bugs shouldn't be like that. Only one bug per report.

But if some actions lead to something else which causes the bug, and you as user don't know where things go wrong, you report it as you have experienced it. And if you during you test notice other things, then it makes perfect sense to report that as well, because how should you as user know whether that is relevant for the bug or not? But to you it might seem like a different issue, which I don't blame you for, but that doesn't mean that I know it and that I intentionally try to add as many bugs to one report as humanly possible, to just make things as complicated for you as possible.

The whole workflow of you just closing bug reports, could be compared to two people speaking on the phone.

Person 1: Expresses a problem

Person 2: I don't agree, its because you are not doing it correctly.

Person 1: But......(Person 2 hangs up.)

I think the general way that you handle bug reports are very ineffective. Instead of just closing them, it would be a lot better approach I think. To add a system of how you handle them, in the sense:

1. If you don't understand the problem / can recreate it.

Don't assume that the problem is solved by moving it to the closed section.

2. Write a reply to the person:

a. Based on your description in the report, Im not able to recreate the problem. Can you apply a Capx?, if there is none

b. I checked you capx and weren't able to recreate the issue you are referring to. <Ask for more information if possible>

c. I don't understand your description (Not all people speak English), can you try to elaborate the problem?

3. Finally

Don't close the reports as if it was solved or not relevant. Instead maybe wait 4-7 days and if the person making the report haven't answers to your comment then close it. People making these reports, simply write what they experience, not specifically where in the C2 code things are going wrong.

If you under no circumstances can recreate the problem, leave the bug report open to see if others might report something similar and write that you simply can't recreate it, but you will keep an eye on it and the person making it should as well or close it, but at least tell the person that you cant recreate it, after gathering as much information as possible. Following the 3 steps above.

And I fully agree that in a lot of cases I would also assume that some bug reports are due to bad code, but in that case simply ask them to provide a capx, if the problem or description in the bug report doesn't explain how to recreate it correctly or it is a more advance description etc. People adding bug reports doesn't do it to annoy you, but to help you. But the impression you get is that you would rather that people didn't based on the way you do it now, and that's sad I think

Scirra has been growing slowly for a while. We're just not making public announcements about it as we go along, but maybe we should. We have people helping with support, software development, business development, and more. There's also a whole raft of stuff you never see from your side like figuring out how the tax arrangements work for the third party sales in the Store, or managing the increasing number of education subscriptions, or optimising the database caching so the site can scale with the increasing number of visitors, much of which I have little involvement in so I can focus on the technical stuff. But none of that changes what a reasonable bug report is!

FWIW Tom is actively working on the new Arcade now - a ton of stuff has meant it's been put off way longer than we originally hoped (ranging from prioritising the new Store with third-party content, to customer-invisible things like adapting to the new EU tax laws). But I think he's full-steam-ahead on that now and I'm hopeful we can have the new Arcade running within a month or two.

We're not coding in our bedrooms any more! Things have come a long way

Haha, I would imagine you actually started out that way ;P

I have heard 'the Arcade is coming' for a while now, so I'll believe it when I see it

In any case. More information through the forum/facebook/etc regarding growth and participants in Scirra's path to a business success would definitely improve transparency of Scirra's going on's.

You mention you have people helping with support, I am guessing none of these handle bugs reports or perform case studies / test cases with potential problems and workings ?

Seeing as I generally see you replying to things hinting at performance/bug/engine problems.

Take some of the replies in this thread for instance, at one point you ask/point out lack of for material with possible performance related issues; then someone sends you some as a reply, and you mention that it will take a few weeks before you would have time to look sorry, I lol-ed

I meant with these kinds of things. One of the things you would do is start checking the capx ...

You could have passed those files the same day to someone who knows what he or she is doing, and if they conclude the same as the complaint (not logic issue), I bet you would instantly want to know what the actual cause was/is, so you can work on it in your code.

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!

.....

If you under no circumstances can recreate the problem

.....

Closed bugs 4,055 Topics .....

If each would take just an half hour to do ... it would already take 253 8 hour work days to make them all ...

... and I was pleading for Ashley to get more dev time

Aside from all this ... I think a closed bug reporting environment, like Juryiel mentions, might be a good thing.

The whole recreating capx thing takes time ... and I am guessing quite a few people are reluctant to post their capx files as they ponder content might get stolen.

If people could use their own 'trimmed down' versions of their capx, I would think that the user would require far less time to make the files needed for a decent report, without fearing someone might steal images/audio/idea etc.

Trimming down is one thing, but creating a whole new capx can be very time consuming ....

Plus, trimming down could have the benefit of the user suddenly ending up with a working variant of his game, realizing its his or her own logic causing problems. But I think users would only post this if only Support are able to see their files, as they would definitely not take their material for personal use.

As an alternative, Scirra could set the resulting Capx upload in the bug section to be only viewable/downloadable by mods/admins

to give the users some privacy.

Yes, better support for people who paid for the software, easy to check by the medal icon of forum avatar.

But at same time, I want to see dev time.. It is simply needed that Scirra has a team of at least 6 people... I love Construct 2 and the concept and the site itself, it has a little sense of action (the contest and the badges) but I think that the copies/buyers/fans has outgrown the team size. I feel like Scirra still treat C2 as a tiny indie project (the small 1 developer 1 pr/website) but still business/paid license seriousness at same time. You can't have both.

I am not dissing the guys. Ashley and Tom are awesome! It is just the going way....

Having dealt with thousands of bug reports over a period of years, I have come to have the approach I do because it is by far the most efficient way of resolving issues. I have eventually realised that a significant part of the process of dealing with bug reports is teaching people how to write useful bug reports, allowing the reported problem to be solved as quickly and effectively as possible. Lots of beginners print screen an error message and report it, and it is literally impossible to do anything about it. Another very common case is they carefully write up a list of steps, but don't share their .capx. I follow the steps (which can sometimes take a while, especially if there are vague bits which I get past by trying different combinations of interpretations) and it turns out they forgot a step which the original .capx they used did, and was the real cause of the problem. If I had the .capx, I could have solved it immediately. This kind of thing is not useful to anybody: it wastes developer time, and makes it take longer to get user's issues fixed. Unceremoniously closing the issue is the quickest way to get people to respect the guidelines, which helps everybody.

Everything in the bug report guidelines is from this kind of thing happening again and again and again and again and again, until I draw the line and say I will outright reject any reports that do not follow the given requirement. And it still keeps happening. Yes, I can see that if you are a new user, you come along and spend some time carefully writing up a list of steps but don't provide a .capx, and then your report is immediately closed, you might think I'm being cruel or something, but experience has taught me there is about a 50% chance I'm not going to see the problem. Given there are over 4000 bug reports and they still come in fast, this can turn in to months of wasted developer time which could be spent on something more useful like developing new features, and the reporter could take some simple steps to help us help you effectively.

The bug report guidelines are the things you need to do for a software developer to usefully and quickly investigate your problem, so please take them seriously.

Also if you buy Microsoft Visual C++, I don't think you'd expect Microsoft support to help you debug your C++ apps for free - although they (or someone else) might offer a paid service for that - but they would address reasonable bug reports. Similarly I don't think it's fair to expect us to solve the event problems in your projects. When it comes to bug reports, as I've mentioned large projects are not even useful. In general, the larger the project, the less likely it is to be a useful bug report. If you can't reproduce the problem in a new empty project, it is probably not a bug (another point with years of experience behind it). This makes the copyright/not-sharing-my-work issue irrelevant, because I don't want you to send me your whole project anyway. (With one sole exception: performance profiling - but most bug reports aren't about that.) This is also industry standard. I would not expect Microsoft to fix a C++ compiler bug by sending them the entire Construct 2 source. They would require that I reproduce the problem in a minimal program before they could investigate. Then I also don't need to send the C2 source code anywhere, and they can fix the problem more quickly.

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.

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