Next T3D 1.1 release?
by Edward Smith · in Torque 3D Professional · 05/12/2010 (4:17 pm) · 104 replies
Are there any updates as to the eta on the next release?
About the author
Currently working on a WW2 FPS game.
#82
Thank you for taking your weekend time to post this overview. (+1)
05/29/2010 (7:39 pm)
I am fully satisfied with that agenda, and can not think of anything more the fellow participants of this thread have not already covered. Thank you for taking your weekend time to post this overview. (+1)
#83
Question: You are leveraging Winqual for the Binary version, aren't you ?
I know for a fact that its been instrumental to me in improving percieved & actual quality in consumer products.
06/01/2010 (1:08 am)
@ericQuestion: You are leveraging Winqual for the Binary version, aren't you ?
I know for a fact that its been instrumental to me in improving percieved & actual quality in consumer products.
#84
Don't want to keep you from your normal job, but one thing that crossed my mind a few times when there was a new update. What happened to me is that I completely had to rebuild my levels when there was a new update/release (maybe it was my fault, but still...) or had some unexpected side effects because fields had changed or added or we had to use inverted values at flickering lights (as Steve YorkshireRifles Acaster had noticed somewhere around here). For me it was part of the T3D learning curve, but at this moment I have a few levels in my game that are near completion, I don't want to rebuild it again when there is a new update.
Now my suggestion/question: Is it possible to add a tool to convert a mission file so that everything (datablocks etc.) is according to this new release. Or have some documents explaining the changes so we can add them manually to the mission files.
Be aware that this is not a complain, I know how difficult it is to build an engine (tried it myself a few years ago) and have and keep everybody satisfied. Keep up the good work.
06/01/2010 (2:36 am)
@Eric:Don't want to keep you from your normal job, but one thing that crossed my mind a few times when there was a new update. What happened to me is that I completely had to rebuild my levels when there was a new update/release (maybe it was my fault, but still...) or had some unexpected side effects because fields had changed or added or we had to use inverted values at flickering lights (as Steve YorkshireRifles Acaster had noticed somewhere around here). For me it was part of the T3D learning curve, but at this moment I have a few levels in my game that are near completion, I don't want to rebuild it again when there is a new update.
Now my suggestion/question: Is it possible to add a tool to convert a mission file so that everything (datablocks etc.) is according to this new release. Or have some documents explaining the changes so we can add them manually to the mission files.
Be aware that this is not a complain, I know how difficult it is to build an engine (tried it myself a few years ago) and have and keep everybody satisfied. Keep up the good work.
#85
I would like a to see a proper ticketing system that is accessible by paying customers. I am sure that the forums have worked fine in the past but I find it convoluted and disorganized for proper bug/suggestion tracking.
When I come across something that I believe to be a bug or even something I think would be a great addition to the engine it is a major undertaking to try and find things on these forums to find some simple answers such as:
A) Has it been submitted yet? Is there a ticket number I can subscribe to see if any additional answers come along instead of manually tracking it?
B) If it has been submitted has it been resolved? Does it have a work around? Has it been declined due to inability to reproduce thus allowing others to give more feedback? Does this bug related to the current version? Is there an ETA on when it might get fixed (i.e. T3D 1.2).
For a GREAT example of how a proper ticketing system should work that is amazingly functional I'd like to point you to DevExpress. Here is a link to one of their bug reports, I show this example to show how they explain "by design" issues that some believe to be bugs.
devexpress.com/Support/Center/p/B147755.aspx?searchtext=&p=T4|P1|22
However, with all of this said if I am somehow missing out on an amazing ability to look at the actual ticket numbers that I see sometimes posted and do real searches and such let me know.
06/01/2010 (6:51 am)
I know this has been brought up a few times, but I'd like to make sure it gets proper consideration since it seems like Eric is taking real note of this thread.I would like a to see a proper ticketing system that is accessible by paying customers. I am sure that the forums have worked fine in the past but I find it convoluted and disorganized for proper bug/suggestion tracking.
When I come across something that I believe to be a bug or even something I think would be a great addition to the engine it is a major undertaking to try and find things on these forums to find some simple answers such as:
A) Has it been submitted yet? Is there a ticket number I can subscribe to see if any additional answers come along instead of manually tracking it?
B) If it has been submitted has it been resolved? Does it have a work around? Has it been declined due to inability to reproduce thus allowing others to give more feedback? Does this bug related to the current version? Is there an ETA on when it might get fixed (i.e. T3D 1.2).
For a GREAT example of how a proper ticketing system should work that is amazingly functional I'd like to point you to DevExpress. Here is a link to one of their bug reports, I show this example to show how they explain "by design" issues that some believe to be bugs.
devexpress.com/Support/Center/p/B147755.aspx?searchtext=&p=T4|P1|22
However, with all of this said if I am somehow missing out on an amazing ability to look at the actual ticket numbers that I see sometimes posted and do real searches and such let me know.
#87
I really love Torque3D. The tool, and the team behind it, are moving in exactly the direction I wish TGE had gone. Even in its current state, it's infinitely more intuitive for me. There are a few usability gripes and bugs I've run into that others have already commented on, but that's to be expected on something clearly labeled beta. I see the QA lab is already on the move here in the forms, that's a really great sign.
Keep up the great work, and thanks for listening and responding to the community this go-around! Even us lowly lurkers really appreciate it.
06/01/2010 (8:05 am)
I've been a Torque licensee for a number of years (TGE, TSE/TGEA and T3D), and I feel the need to put in my two cents, since everyone is clearly listening.I really love Torque3D. The tool, and the team behind it, are moving in exactly the direction I wish TGE had gone. Even in its current state, it's infinitely more intuitive for me. There are a few usability gripes and bugs I've run into that others have already commented on, but that's to be expected on something clearly labeled beta. I see the QA lab is already on the move here in the forms, that's a really great sign.
Keep up the great work, and thanks for listening and responding to the community this go-around! Even us lowly lurkers really appreciate it.
#88
The fact that you have more than one product for 2D games says exactly the opposite.
Why in the hell are there 3 products for doing 2D games? This is why other engines are eating your lunch! Unity is one engine that works on just about everything. "or at least soon will"
Epic has announced that they have unreal running on both Android and iPhone.
Again one engine multiple targets.
on the subject of GG getting crucified for not delivering on things and being silent. I have been here pretty much since this place opened the doors and I have to say I remember the exact product that did this....
"Constructor"!!
I think that thing went almost a year without hearing outta GG on its status. it was something that was supposed to be ready in a couple months then with no explanation everything went quite and a year or 2 went by. Then when you guys did come out to talk it was usually Stephen "hot-Head" Zepp who should have never been allowed to talk to customers.
Then you guys sold TSE then TGEA. every time doing a little bit of work and then going quite and then unveiling a new product. I mean honestly what would you expect everyone to think?
If you paid a construction company to build you a house then they threw up the framework and then disappeared for a 6 months to a year then you see a big sign down the street where said company has just spent a but load building the "house of the future" and trying to sell it to people how would you feel?
This is the Reputation that GG has gotten.
"DISCLAIMER - I HAVE NO PROOF OF WHAT I"M ABOUT TO SAY! IT IS NOT FACT! IT IS SIMPLY MY OPINION"
The impression of GG's development model seems to be to build something to a point to where you can hype it and sell some license "mainly EA users". Then take that money and make another product Hype it get it to a point where you can demo it and then Sell some Licenses "again prolly mostly EA users" then take that money and start a new product....
Is anyone seeing a pattern here?
GG should only make 2 products
T3D
&
T2D
why can this not be done? why is it that all of these other companies can do it but you guys cant? Last I heard there were close to 75 people at GG. This was a while back not sure whether it is bigger or smaller now. This dwarfs the team at Unity and is about on par with Epic.
so this begs the question?:
WTF?
06/01/2010 (2:58 pm)
Michael Perry Said:Quote:iTorque development has contributed improvements to the other engines. A decent number of optimizations and bug fixes fro iTorque 2D went into TGB 1.7.5, so it's actually a strong counter to your suggestion. It's evidence that convergence of the engines has already been taking place for a while.
The fact that you have more than one product for 2D games says exactly the opposite.
Why in the hell are there 3 products for doing 2D games? This is why other engines are eating your lunch! Unity is one engine that works on just about everything. "or at least soon will"
Epic has announced that they have unreal running on both Android and iPhone.
Again one engine multiple targets.
on the subject of GG getting crucified for not delivering on things and being silent. I have been here pretty much since this place opened the doors and I have to say I remember the exact product that did this....
"Constructor"!!
I think that thing went almost a year without hearing outta GG on its status. it was something that was supposed to be ready in a couple months then with no explanation everything went quite and a year or 2 went by. Then when you guys did come out to talk it was usually Stephen "hot-Head" Zepp who should have never been allowed to talk to customers.
Then you guys sold TSE then TGEA. every time doing a little bit of work and then going quite and then unveiling a new product. I mean honestly what would you expect everyone to think?
If you paid a construction company to build you a house then they threw up the framework and then disappeared for a 6 months to a year then you see a big sign down the street where said company has just spent a but load building the "house of the future" and trying to sell it to people how would you feel?
This is the Reputation that GG has gotten.
"DISCLAIMER - I HAVE NO PROOF OF WHAT I"M ABOUT TO SAY! IT IS NOT FACT! IT IS SIMPLY MY OPINION"
The impression of GG's development model seems to be to build something to a point to where you can hype it and sell some license "mainly EA users". Then take that money and make another product Hype it get it to a point where you can demo it and then Sell some Licenses "again prolly mostly EA users" then take that money and start a new product....
Is anyone seeing a pattern here?
GG should only make 2 products
T3D
&
T2D
why can this not be done? why is it that all of these other companies can do it but you guys cant? Last I heard there were close to 75 people at GG. This was a while back not sure whether it is bigger or smaller now. This dwarfs the team at Unity and is about on par with Epic.
so this begs the question?:
WTF?
#89
Being this thread is of a slightly different nature, and it is also finally taking the turn for improvements instead of complaints, i would rather not see it derailed onto another tangent.
06/01/2010 (3:46 pm)
@James Brad Barnette; If you were to start another thread along your line of thought(s) i would be more then pleased to debate some of your ideas. Others have made hint along your same sentiment, so your not alone in this idea. Being this thread is of a slightly different nature, and it is also finally taking the turn for improvements instead of complaints, i would rather not see it derailed onto another tangent.
#90
Have you also noticed that an extremely large amount of the work being done on the engines are from contractors? What are the employee's doing all day? It seems like you could drop 90% of the staff and hire Sickhead and we would still have Torque3D's mediocre deferred renderer and everything else. Please nobody freak out at the last statement I made. I know this isn't reality, but maybe not too far off.
I agree with you that they have WAY too many engines. I disagree with you though as I don't think T2D should be around any longer. As soon as GarageGames can prove they can manage a single engine, then maybe it'll be time to branch out.
06/01/2010 (4:38 pm)
@James Brad Barnett - I share your same opinion on offering EA releases and then starting the new engine that will change the world. Also, how much they learned from the mistakes of their last failed engine and this time it will be different. I'm fully expecting a Torque3D Advanced or Torque3D Next Gen announcement within the year. Have you also noticed that an extremely large amount of the work being done on the engines are from contractors? What are the employee's doing all day? It seems like you could drop 90% of the staff and hire Sickhead and we would still have Torque3D's mediocre deferred renderer and everything else. Please nobody freak out at the last statement I made. I know this isn't reality, but maybe not too far off.
I agree with you that they have WAY too many engines. I disagree with you though as I don't think T2D should be around any longer. As soon as GarageGames can prove they can manage a single engine, then maybe it'll be time to branch out.
#91
Also I think everything has pretty much been covered here and the guys have heard us so maybe we should let them do their jobs now instead of finding more ways to flame them.
06/01/2010 (10:04 pm)
This has gone way off topic, we need to get faster releases, more updates and better QA for T3D 1.1 series engine and not debate the torque business strategy.Also I think everything has pretty much been covered here and the guys have heard us so maybe we should let them do their jobs now instead of finding more ways to flame them.
#92
06/01/2010 (11:03 pm)
@Chris - Exactly. Everyone has spoken. Eric has taken things on board, now it's a waiting game and give them the space they need to shine. Things are already starting to improve and you can tell that from the forums, as long as this continues the ranting will stop.
#93
idk,
I think if you can't handle the truth, then I say; don't bother reading it but don't stop others from writing/saying it.
James, Caylo, Jon and others have made some great posts and if it wasn't for them expressing their thoughts..then those issues may go un-noticed and left alone only to occur again at a later time.
- Besides, how is Eric to fix something about which he is uninformed ?
I'm sure Eric would like to know any serious issues with past business choices of GG especially when they have negatively affected GG's reputation. - Eric may not change anything you mention and he may not even agree with what you say, ..but having him as an informed as possible can only be a benefit to us all. Information is key.
..and remember, please use discretion if you choose to write. Thanks.
06/02/2010 (12:07 am)
[ breaking my silence on this thread for a post :P ]idk,
I think if you can't handle the truth, then I say; don't bother reading it but don't stop others from writing/saying it.
James, Caylo, Jon and others have made some great posts and if it wasn't for them expressing their thoughts..then those issues may go un-noticed and left alone only to occur again at a later time.
- Besides, how is Eric to fix something about which he is uninformed ?
I'm sure Eric would like to know any serious issues with past business choices of GG especially when they have negatively affected GG's reputation. - Eric may not change anything you mention and he may not even agree with what you say, ..but having him as an informed as possible can only be a benefit to us all. Information is key.
..and remember, please use discretion if you choose to write. Thanks.
#94
06/02/2010 (12:29 am)
Think there's enough on this thread to fill up a jug or three let alone a cup. People have been silent for a long time, some people just don't bother or sit on the side, the knowledgable get on and fix what they can if they are good enough and the rest, like me (the people who have been here from the start) with frustration build-up have had their say, and I agree if Eric doesn't know by now the history of GG - people are doing a good job about getting him up-to-date, and I'm sure he is well informed already of the past and what needs to be done for the future. These posts may have just altered his timelines/priorities a bit. If you feel you need to vent your frustrations further then I'm sure they will listen some more, but the points have been made, no point fueling it any further.
#95
A few times wording have been used that is just shy of the shadows of being insulting, in this thread and many others, and many more to come. It is easy to misinterpret the meaning of written open forum communication, especially when you know nothing about the author. It is equally simple to use one wrong word or phrase and bring down hate like righteous fire from heaven, without even meaning.
The above off topic thread posts have some valid points and are obviously issues on some peoples minds. Please take them to a new thread for discussion, so as not to have them lost in a thread about a totally separate subject.
This is the subject of this thread
From Eric Preisz in post #81
EDIT: This post was edited for the protection of the members of Sealab 2021, may they rest in peace.
06/02/2010 (1:40 am)
A rant is a speech or text that does not present a calm rational argument.A few times wording have been used that is just shy of the shadows of being insulting, in this thread and many others, and many more to come. It is easy to misinterpret the meaning of written open forum communication, especially when you know nothing about the author. It is equally simple to use one wrong word or phrase and bring down hate like righteous fire from heaven, without even meaning.
The above off topic thread posts have some valid points and are obviously issues on some peoples minds. Please take them to a new thread for discussion, so as not to have them lost in a thread about a totally separate subject.
This is the subject of this thread
From Eric Preisz in post #81
Quote:
Here’s my overview:
Frustration – Many in this thread have lots of different frustrations. Some of them go back 5 or 6 years. Others, extend back to plans before the buyout, and most are regarding expectations set regarding Torque 3D and release frequency, bugs, or communication. In fully acknowledging the frustration, I’m hopeful that we can move this thread to a discussion about fixing as many issues as possible regarding rather than dwelling on them or encouraging mob mentality that adds noise to our developing solutions.
Issue #1 – Can we get vague dates on when Torque 3D 1.1 will ship?
Issue #2 – Better expectation management ( less hype that could be interpreted as promises )
Issue #3 – More frequent updates. What will you do to return fixed bugs to the community faster?
Issue #4 – Better communication. It would be nice for us to not have to post questions like this thread to get answers on big topics.
From what I’ve read, that seems to cover the thread at a high-level. Feel free to point out other big topics from the thread above if you think I’m glaring over something big.
------------------------------------------------------------------------
Lastly, I did notice some issues reported at a high level in this thread. I’d like to get some more detail or a link if possible so that I can make sure that they are being tracked.
Edward Smith points out a T3D bug on “save” in comment (#32)
Cai references bugs that were fixed TGEA that aren’t fixed in T3D (#34)
Marc references that T3D has “will backfire ceavats” (#68)
Do you guys have any more info you could help us with? Perhaps a link? We are fixing a lot of bugs, but if you have something that we don’t know about it, I’d like to get it into the pipeline. If there are some reasons why we aren’t/can’t fix the issue in the near term, I’d like to let you know why.
EDIT: This post was edited for the protection of the members of Sealab 2021, may they rest in peace.
#97
Yes. We are expecting a July release for 1.1 final. We have an 8 out of 10 confidence in this since it is dependent on the results of the beta that we are currently bug fixing. So far we have around 100 or 150 bug fixes completed. Unfortunately, our bug tracking system database and reported forums bugs needed some major clean-up. Scott’s team has gone through almost all of the forums bugs and logged them into Jira and they are well on their way to confirmed what has or hasn’t been fixed. We are testing the 1.1 Beta 2 installers now, but we expect that we will be building more installers as more bugs are fixing. We don’t expect a release candidate to be in QA for another couple of weeks.
Issue #2 – Better expectation management ( less hype that could be interpreted as promises )
This is finished. I don’t think you will find any evidence of me overpromising. The short term gains aren’t worth the long term issues it causes. A lot of what we are doing right now is focused on long term improvements. In fact, as some of you have pointed out, some of our long term fixes do cause resource conflicts with short term issues, but we are doing our best with both.
Issue #3 – More frequent updates. What will you do to return fixed bugs to the community faster?
This is the absolute hardest for me to answer with any new information. So I’m going to re-iterate some of the things we’ve already said in more detail and in this single location.
Some of the recent challenges we have are systemic problems that we’ve gone a long way to address:
Less Bugs – The quickest bug fixed is the bug that never got released to the public. Bugs that are fixed later cost more than the bugs fixed earlier. Less “expensive bugs” fixed means more resources for fixing other bugs. During development we have the ability to do a multiple, non-released, QA rounds. Our QA staff is around 7-10 people right now (some of them are graduate students). This will help us define our release dates better because we will have a better understanding of the current state of software’s stability.
Rolling Focus Updates – We have already discussed the concept of focus sprints for Torque 3D. Those will start after 1.1 release and be roughly 4-6 weeks in duration. We had a list of things that we are interested in working on but we also want your feedback. The focus sprints can include things such as usability and bug-fixing. We will work with you to define these sprints.
QA – Having the QA team means that they are more efficient. In the past we had one person for QA and he left in October ( we started building the QA lab in February after I started ). This will shorten release times because devs who were working on QA in the past are now able to move to new tasks in parallel to QA.
Convergence – We are working on the process of sharing more code across our projects. Doing so will make one fix automatically show up in the other code bases. Having multiple branches is very expensive and wastes resources.
Dropping Unused Features – We are going to be more aggressive at culling old code that requires maintenance on our part.
More Minor QA Releases – We will be replicating the Torque 3D beta process for other engines. We are also considering replicating the focus sprints if they are popular and work well.
Issue #4 – Better communication. It would be nice for us to not have to post questions like this thread to get answers on big topics.
Another systemic problem we had was that we didn’t have a good structure for representatives of products. We now have single points of authority/accountability for all of our projects. These single points will be making periodic posts to reach out to you, solicit feedback, and provide highlights of the prior month. We are going to start with monthly posts to see if that is a reasonable pace for both the community and us.
We will also continue pod casts and IRC hour to reach out to you in other ways.
TorqueX – We had one person working on Torque. Now we have 7. TorqueX bugs are being squashed as we speak.
iTorque – Michael Perry is going to adjust his schedule accordingly to make sure that we are updating you more regularly.
Just so everyone knows, those points of authority/accountability are:
Torque 3D – Matt Fairfax
Torque X – Derek Bronson
iTorque – Michael Perry
TGB – Eric Preisz ( temp )
Lastly, I’d like to commit to not having so much time between releases like we are doing with this round of Torque 3D. With the move to Las Vegas behind us and the disruption of a new leader I’m confident we can keep a cadence that includes more frequent updates.
06/04/2010 (3:39 pm)
Issue #1 – Can we get vague dates on when Torque 3D 1.1 will ship?Yes. We are expecting a July release for 1.1 final. We have an 8 out of 10 confidence in this since it is dependent on the results of the beta that we are currently bug fixing. So far we have around 100 or 150 bug fixes completed. Unfortunately, our bug tracking system database and reported forums bugs needed some major clean-up. Scott’s team has gone through almost all of the forums bugs and logged them into Jira and they are well on their way to confirmed what has or hasn’t been fixed. We are testing the 1.1 Beta 2 installers now, but we expect that we will be building more installers as more bugs are fixing. We don’t expect a release candidate to be in QA for another couple of weeks.
Issue #2 – Better expectation management ( less hype that could be interpreted as promises )
This is finished. I don’t think you will find any evidence of me overpromising. The short term gains aren’t worth the long term issues it causes. A lot of what we are doing right now is focused on long term improvements. In fact, as some of you have pointed out, some of our long term fixes do cause resource conflicts with short term issues, but we are doing our best with both.
Issue #3 – More frequent updates. What will you do to return fixed bugs to the community faster?
This is the absolute hardest for me to answer with any new information. So I’m going to re-iterate some of the things we’ve already said in more detail and in this single location.
Some of the recent challenges we have are systemic problems that we’ve gone a long way to address:
Less Bugs – The quickest bug fixed is the bug that never got released to the public. Bugs that are fixed later cost more than the bugs fixed earlier. Less “expensive bugs” fixed means more resources for fixing other bugs. During development we have the ability to do a multiple, non-released, QA rounds. Our QA staff is around 7-10 people right now (some of them are graduate students). This will help us define our release dates better because we will have a better understanding of the current state of software’s stability.
Rolling Focus Updates – We have already discussed the concept of focus sprints for Torque 3D. Those will start after 1.1 release and be roughly 4-6 weeks in duration. We had a list of things that we are interested in working on but we also want your feedback. The focus sprints can include things such as usability and bug-fixing. We will work with you to define these sprints.
QA – Having the QA team means that they are more efficient. In the past we had one person for QA and he left in October ( we started building the QA lab in February after I started ). This will shorten release times because devs who were working on QA in the past are now able to move to new tasks in parallel to QA.
Convergence – We are working on the process of sharing more code across our projects. Doing so will make one fix automatically show up in the other code bases. Having multiple branches is very expensive and wastes resources.
Dropping Unused Features – We are going to be more aggressive at culling old code that requires maintenance on our part.
More Minor QA Releases – We will be replicating the Torque 3D beta process for other engines. We are also considering replicating the focus sprints if they are popular and work well.
Issue #4 – Better communication. It would be nice for us to not have to post questions like this thread to get answers on big topics.
Another systemic problem we had was that we didn’t have a good structure for representatives of products. We now have single points of authority/accountability for all of our projects. These single points will be making periodic posts to reach out to you, solicit feedback, and provide highlights of the prior month. We are going to start with monthly posts to see if that is a reasonable pace for both the community and us.
We will also continue pod casts and IRC hour to reach out to you in other ways.
TorqueX – We had one person working on Torque. Now we have 7. TorqueX bugs are being squashed as we speak.
iTorque – Michael Perry is going to adjust his schedule accordingly to make sure that we are updating you more regularly.
Just so everyone knows, those points of authority/accountability are:
Torque 3D – Matt Fairfax
Torque X – Derek Bronson
iTorque – Michael Perry
TGB – Eric Preisz ( temp )
Lastly, I’d like to commit to not having so much time between releases like we are doing with this round of Torque 3D. With the move to Las Vegas behind us and the disruption of a new leader I’m confident we can keep a cadence that includes more frequent updates.
#98
This sounds to me as some sort of 'product backlog', that you will use to chop up for the sprints. Will this be posted pre or post 1.1 launch, so you can get feedback as to what 'the other side' considers must/should/could/would haves ?
06/05/2010 (12:22 am)
Quote:We had a list of things that we are interested in working on but we also want your feedback. The focus sprints can include things such as usability and bug-fixing. We will work with you to define these sprints.
This sounds to me as some sort of 'product backlog', that you will use to chop up for the sprints. Will this be posted pre or post 1.1 launch, so you can get feedback as to what 'the other side' considers must/should/could/would haves ?
#99
Anyway... Regarding Issue 3, and more specifically the issue of how to make sure the bugs users have found are being addressed in a timely manner:
As I've seen the QA team moving through the forums and tagging various posts, it occurred to me that this could lead to a more effective solution than simply deploying more frequent updates to the community as I had originally proposed. The real issue being addressed is the potential for bugs to exist "in limbo" for periods of time, with no official way of knowing whether it's being addressed in addition to long cycles between test versions.
In the system used for the 1.0 Beta, when a bug doesn't get any official confirmation or status updates it becomes very unclear if/when it will be addressed. Sometimes a dev will log the thread for their internal tracking system or post something more specific, and other times it ends up being a guessing game.
The best solution I can imagine is exactly what Scott was talking about: If we had some overall bug-tracking system visible to the community, it would be easy to check if a reported issue has been acknowledged and what its status is. I don't see this central bug index as a community-editable system so much as a community-viewable window into what the Dev and QA teams are aware of. It was discussed that opening the "true" tracking system to the community would flood it, and I agree, which is why I'm talking about read-only access.
A section of this system which took community submissions could also be desirable, however there should always be a Devs-only section for confirmed issues. I have no idea which tracking system you guys are using, but it seems like it could be viable to set up a lower "class" of issue, ie a "community-submitted issue" which only appears in the "community" section until it is moved by a Dev/QA member to "official QA issue" class after being confirmed. In reality, I see 3 "levels" of issue that would exist on entirely separate "pages" of the system (but within the same system):
-Community: submitted by the community, these issues are totally unconfirmed and can be added-to by other community members. This section could get messy, but that's to be expected.
-QA: The issue has been upgraded by the QA team into something they feel is worth looking into, or was originally added by them.
-Dev: The issue has been upgraded by high-level QA or the Dev Team into an issue that programmers need to address. Basically this means the issue has been confirmed however there is no fix available. Basically whatever the rules for the current Dev bug tracker system are.
Optimally all 3 levels are viewable by everyone (everyone with a valid T3D Pro license), however only "Community" level issues can be edited by non-QA/Dev's. If the 3 "tiers" of the same issue could be linked to each other, that's even better. IE, the system would understand that issues "C-248," "Q-248," and "D-248" are all the same issue, allowing everyone to quickly refer back and forth between the info created on the issue by each "level" of user (and allowing the community to continue to add info once the issue has been upgraded, but still only within the community section of the tracker).
My explanation is probably fairly unclear and winding (possibly also repetitive), so sorry about that, but hopefully the idea comes through. It's a filtering multi-tier bug tracker that allows only 1 database to contain different levels of data on an issue and allows the users to view only what they want to (info from Dev team, QA team, community, or all of the above). This system lets the community participate directly in the "official" bug tracking system without actually flooding it, as their notes/additions/submissions can simply be filtered out. I realize there may be some internal security/leak concerns with allowing the community even read-only access to Dev-level bug tracking, but I didn't want to get even more complicated at this point.
Far-too-specific ideas aside, some kind of system for making it clear what issues are being addressed aside from relying on seeing a very vague "logged as" post from a Dev/QA user would essentially solve the issue in my eyes.
RE: The move & leadership changes: I'm probably not the only one who keeps forgetting that both of these events happened in the middle of 1.1 development. All things considered, the disruption seems to have been minimal. =)
This is already too long, so I'm going to stop there and let everyone else make their points.
06/06/2010 (4:24 pm)
@Eric: That seems like a pretty comprehensive list of the issues we've been talking about. Thanks for taking the time to jump into this discussion.Anyway... Regarding Issue 3, and more specifically the issue of how to make sure the bugs users have found are being addressed in a timely manner:
As I've seen the QA team moving through the forums and tagging various posts, it occurred to me that this could lead to a more effective solution than simply deploying more frequent updates to the community as I had originally proposed. The real issue being addressed is the potential for bugs to exist "in limbo" for periods of time, with no official way of knowing whether it's being addressed in addition to long cycles between test versions.
In the system used for the 1.0 Beta, when a bug doesn't get any official confirmation or status updates it becomes very unclear if/when it will be addressed. Sometimes a dev will log the thread for their internal tracking system or post something more specific, and other times it ends up being a guessing game.
The best solution I can imagine is exactly what Scott was talking about: If we had some overall bug-tracking system visible to the community, it would be easy to check if a reported issue has been acknowledged and what its status is. I don't see this central bug index as a community-editable system so much as a community-viewable window into what the Dev and QA teams are aware of. It was discussed that opening the "true" tracking system to the community would flood it, and I agree, which is why I'm talking about read-only access.
A section of this system which took community submissions could also be desirable, however there should always be a Devs-only section for confirmed issues. I have no idea which tracking system you guys are using, but it seems like it could be viable to set up a lower "class" of issue, ie a "community-submitted issue" which only appears in the "community" section until it is moved by a Dev/QA member to "official QA issue" class after being confirmed. In reality, I see 3 "levels" of issue that would exist on entirely separate "pages" of the system (but within the same system):
-Community: submitted by the community, these issues are totally unconfirmed and can be added-to by other community members. This section could get messy, but that's to be expected.
-QA: The issue has been upgraded by the QA team into something they feel is worth looking into, or was originally added by them.
-Dev: The issue has been upgraded by high-level QA or the Dev Team into an issue that programmers need to address. Basically this means the issue has been confirmed however there is no fix available. Basically whatever the rules for the current Dev bug tracker system are.
Optimally all 3 levels are viewable by everyone (everyone with a valid T3D Pro license), however only "Community" level issues can be edited by non-QA/Dev's. If the 3 "tiers" of the same issue could be linked to each other, that's even better. IE, the system would understand that issues "C-248," "Q-248," and "D-248" are all the same issue, allowing everyone to quickly refer back and forth between the info created on the issue by each "level" of user (and allowing the community to continue to add info once the issue has been upgraded, but still only within the community section of the tracker).
My explanation is probably fairly unclear and winding (possibly also repetitive), so sorry about that, but hopefully the idea comes through. It's a filtering multi-tier bug tracker that allows only 1 database to contain different levels of data on an issue and allows the users to view only what they want to (info from Dev team, QA team, community, or all of the above). This system lets the community participate directly in the "official" bug tracking system without actually flooding it, as their notes/additions/submissions can simply be filtered out. I realize there may be some internal security/leak concerns with allowing the community even read-only access to Dev-level bug tracking, but I didn't want to get even more complicated at this point.
Far-too-specific ideas aside, some kind of system for making it clear what issues are being addressed aside from relying on seeing a very vague "logged as" post from a Dev/QA user would essentially solve the issue in my eyes.
RE: The move & leadership changes: I'm probably not the only one who keeps forgetting that both of these events happened in the middle of 1.1 development. All things considered, the disruption seems to have been minimal. =)
This is already too long, so I'm going to stop there and let everyone else make their points.
#100
Knowing a bug has been checked in is nice but doesn't tell us much. Having a page with status info would be much more useful.
06/10/2010 (5:04 am)
Seconded (or Thirded+) for the public bug tracking system.Knowing a bug has been checked in is nice but doesn't tell us much. Having a page with status info would be much more useful.
Employee Eric Preisz
GarageGames
I just re-read the thread; this time taking notes. Going through these threads takes a lot of time and I’d hate for each of the Torque Devs and QA to spend 8 hours combined reading this thread if I can summerize the issues for them.
So what I’d like to do is harvest all the actionable items in this thread, ask for your clarification on my perspectives and interpretations, and follow-up next week with as many answers and plans as possible.
I have a two day, quarterly offsite meeting next Wednesday and Thursday so chances are that I won’t be able to respond until Friday. Monday is a holiday and I would like to take Tuesday to review some of my thoughts with some of the guys before submitting a response to these really important topics.
Here’s my overview:
Frustration – Many in this thread have lots of different frustrations. Some of them go back 5 or 6 years. Others, extend back to plans before the buyout, and most are regarding expectations set regarding Torque 3D and release frequency, bugs, or communication. In fully acknowledging the frustration, I’m hopeful that we can move this thread to a discussion about fixing as many issues as possible regarding rather than dwelling on them or encouraging mob mentality that adds noise to our developing solutions.
Issue #1 – Can we get vague dates on when Torque 3D 1.1 will ship?
Issue #2 – Better expectation management ( less hype that could be interpreted as promises )
Issue #3 – More frequent updates. What will you do to return fixed bugs to the community faster?
Issue #4 – Better communication. It would be nice for us to not have to post questions like this thread to get answers on big topics.
From what I’ve read, that seems to cover the thread at a high-level. Feel free to point out other big topics from the thread above if you think I’m glaring over something big.
------------------------------------------------------------------------
Lastly, I did notice some issues reported at a high level in this thread. I’d like to get some more detail or a link if possible so that I can make sure that they are being tracked.
Edward Smith points out a T3D bug on “save” in comment (#32)
Cai references bugs that were fixed TGEA that aren’t fixed in T3D (#34)
Marc references that T3D has “will backfire ceavats” (#68)
Do you guys have any more info you could help us with? Perhaps a link? We are fixing a lot of bugs, but if you have something that we don’t know about it, I’d like to get it into the pipeline. If there are some reasons why we aren’t/can’t fix the issue in the near term, I’d like to let you know why.