Release Candidate for Torque3D
by TheMartian · in Torque 3D Professional · 07/31/2009 (1:14 pm) · 86 replies
So we are at Beta 4 for Torque3D which is really cool. Definitely building up some excitement.
Now the meat of the question, is there a time frame you are shooting for to get to a Release Candidate for Torque3D?
(so in other words you have a ballpark ship date yet?)
Thanks!
Now the meat of the question, is there a time frame you are shooting for to get to a Release Candidate for Torque3D?
(so in other words you have a ballpark ship date yet?)
Thanks!
#2
07/31/2009 (6:30 pm)
@Hewster - I completely agree. Let it bake in the oven until it's ready. I personally don't care if it takes six more months, if that means the bugs are squashed and the performance increases. :) 
#3
If I let it happen, I'm sure we could be in Beta forever :) It's comfortable. It's safe. There's no end in sight for the kind of work we want to do on the product. Some things are just too big to do during a Beta stage where people are using the product.
The fact is that the product is already released and being used to create games. It's not feature complete, and it's not free of all known bugs. We're pretty close to feature stable, squashing bugs and making improvements daily, but as some point we have to ship. Again, we have to ship. It doesn't mean we'll stop the development cycles, but we have to get to a point where we can say "this is a feature rich, stable product that is suitable for the task it was designed for."
We could call the next build a release candidate, or even 1.0 and meet that threshold IMO. Part of the issue is that this community of Torque 3D developers won't really grow quickly until the Beta label is removed. That confidence has to be there. If we did the Google thing and left it in Beta for another year, or even 5-6 months, it would harm each and every user because fewer people would feel comfortable adopting it and we'd have lesser community activity, lesser community contribution.
On the flip side, I can see the advantage to extending the beta period for people who already own the product. Essentially, it ensures that more bugs will be fixed, more improvements will be made, and the guaranteed development commitment to the product is extended by as long as the product is in beta because there's some implicit promise of improvements to come. What I want to make sure everyone knows is that, whether we move to release candidate phase or release a 1.0 build sooner rather than later, that commitment is still there.
We're not going to stop working on Torque 3D after we hit the 1.0 mark, the 1.1 mark, or probably anytime in the next year +. At some point we'll want to take a longer development cycle to add things that we can't release as incremental improvements. Things that break backwards compatibility are good example. At that point, we'll want to introduce a new version, and that will probably coincide with a paid update. That's a long way away. We're not even looking at that this year. For the rest of this year, and a good part of next year, the vast majority of our effort will be on this product.
There's definitely more we want to do. We're not done. Not nearly. I can see taking another month, perhaps even 6 weeks before we release a 1.0 build. It will be stable. It will be feature complete. It will be as free of issues as we can possible make it in that time. So far the team has been pretty insanely efficient when it comes to that phase.
I'd love to hear more of this community's thoughts on the subject. You're our customers. Your faith in us is important and I don't want to make any hasty decisions if there is widespread dissent from you guys.
07/31/2009 (7:38 pm)
@Hewster / Jaimi: Since no product is ever released with "all known bugs squashed" do you think there's an appropriate compromise? Obviously bugs come in all shapes and sizes. We're usually looking at a level of stability that will support the very productive use of the tool for it's purpose. You could *almost* argue Beta 4 fits that requirement, but not quite. I generally agree with the "feature complete" requirement, but we're never really happy with Torque as "feature complete." Even after the 1.0 release, we're likely to take a hard look at stuff we couldn't fit into this cycle right away. Particles are a good example of this.If I let it happen, I'm sure we could be in Beta forever :) It's comfortable. It's safe. There's no end in sight for the kind of work we want to do on the product. Some things are just too big to do during a Beta stage where people are using the product.
The fact is that the product is already released and being used to create games. It's not feature complete, and it's not free of all known bugs. We're pretty close to feature stable, squashing bugs and making improvements daily, but as some point we have to ship. Again, we have to ship. It doesn't mean we'll stop the development cycles, but we have to get to a point where we can say "this is a feature rich, stable product that is suitable for the task it was designed for."
We could call the next build a release candidate, or even 1.0 and meet that threshold IMO. Part of the issue is that this community of Torque 3D developers won't really grow quickly until the Beta label is removed. That confidence has to be there. If we did the Google thing and left it in Beta for another year, or even 5-6 months, it would harm each and every user because fewer people would feel comfortable adopting it and we'd have lesser community activity, lesser community contribution.
On the flip side, I can see the advantage to extending the beta period for people who already own the product. Essentially, it ensures that more bugs will be fixed, more improvements will be made, and the guaranteed development commitment to the product is extended by as long as the product is in beta because there's some implicit promise of improvements to come. What I want to make sure everyone knows is that, whether we move to release candidate phase or release a 1.0 build sooner rather than later, that commitment is still there.
We're not going to stop working on Torque 3D after we hit the 1.0 mark, the 1.1 mark, or probably anytime in the next year +. At some point we'll want to take a longer development cycle to add things that we can't release as incremental improvements. Things that break backwards compatibility are good example. At that point, we'll want to introduce a new version, and that will probably coincide with a paid update. That's a long way away. We're not even looking at that this year. For the rest of this year, and a good part of next year, the vast majority of our effort will be on this product.
There's definitely more we want to do. We're not done. Not nearly. I can see taking another month, perhaps even 6 weeks before we release a 1.0 build. It will be stable. It will be feature complete. It will be as free of issues as we can possible make it in that time. So far the team has been pretty insanely efficient when it comes to that phase.
I'd love to hear more of this community's thoughts on the subject. You're our customers. Your faith in us is important and I don't want to make any hasty decisions if there is widespread dissent from you guys.
#4
The most obvious piece is a complete regression test. There has been so many code changes through the life of the product so far that there are features that may be broken that were never touched. So there needs to be a couple week period where it's nothing but testing all features, even those not touched in the changelogs.
In a beta I don't expect everything to be tested, it's fixed on a per issue basis and then merged. However this is known for causing creep where other issues surface. Beta testers are going great, but a couple weeks of no code change so everything can be tested before a release should really help determine if the release is ready. Essentially a code freeze for 2-3 weeks prior to release, roll all changes into a 1.1, and insure that 1.0 is solid.
Second, is insure that Mich and Andrew (Intern powah!) have the resources they need to get stable docs up for a large majority of the functionality.
Nothing is going to kill community adoption more than piecemail information that they have to assemble from beta forums and the beta community. Especially with the price increase community adoption is very important, as you stated it helps not only them but existing users as well. We all benefit from more people using the code, and many new Torque users are struggling with assembling basic art pipelines, and getting their engine setup for their game genre.
These are my thoughts.
07/31/2009 (7:53 pm)
Here's my feedback on two things that need to be addressed prior to a release, and are likely ongoing now.The most obvious piece is a complete regression test. There has been so many code changes through the life of the product so far that there are features that may be broken that were never touched. So there needs to be a couple week period where it's nothing but testing all features, even those not touched in the changelogs.
In a beta I don't expect everything to be tested, it's fixed on a per issue basis and then merged. However this is known for causing creep where other issues surface. Beta testers are going great, but a couple weeks of no code change so everything can be tested before a release should really help determine if the release is ready. Essentially a code freeze for 2-3 weeks prior to release, roll all changes into a 1.1, and insure that 1.0 is solid.
Second, is insure that Mich and Andrew (Intern powah!) have the resources they need to get stable docs up for a large majority of the functionality.
Nothing is going to kill community adoption more than piecemail information that they have to assemble from beta forums and the beta community. Especially with the price increase community adoption is very important, as you stated it helps not only them but existing users as well. We all benefit from more people using the code, and many new Torque users are struggling with assembling basic art pipelines, and getting their engine setup for their game genre.
These are my thoughts.
#5
When will all shaders be ported to Mac OpenGL ?
Will the Mac RC be released simultaneously with the Win version ? (I hope : I have a Mac, my main dev computer, and a PC with GMA950 integrated chipset, and so, until now, I can't test Advanced Lighting).
Will the final documentation be released for the RC ?
Nicolas Buquet
www.buquet-net.com/cv/
08/01/2009 (6:25 am)
When will Advanced Lighting be available on Mac ?When will all shaders be ported to Mac OpenGL ?
Will the Mac RC be released simultaneously with the Win version ? (I hope : I have a Mac, my main dev computer, and a PC with GMA950 integrated chipset, and so, until now, I can't test Advanced Lighting).
Will the final documentation be released for the RC ?
Nicolas Buquet
www.buquet-net.com/cv/
#6
Well you asked for an opinion, so I hope you don't mind that I give you one. Please take this in context - You have seen Post Beta 4, and I have not yet. Also - People who are intimately involved in the creation of the software tend to have a different view from the people who are trying to use it. Right now, you look at Beta 4 and say "it's almost ready". But I look at it, and say "It shows promise".
Bugs - I won't detail them, and I won't even discuss the big bugs as I'm assuming they will be fixed. But there is a predisposition to classify little bugs as "not a big deal" and release with them anyway. Usually because they're hard to fix, or it's assumed that they will affect few people. But for every bug that ships, each one adds up knocking out potential users and/or increasing the support overhead - which could be a nightmare for those of us who have only 1 or two people on a team.
Usability - We got to admit, this version is 100 times more usable than previous TGEA versions. But is it enough? Almost. Beyond the bugs, I think the only thing it is missing is a little better integration - for example, A) if you are in the shape editor, you should be ablt to directly go to the material editor for for the current shape without having to find it and reselect it. B) Making it more automatic and/or obvious to save the texture in the material editor, etc. Little things like that will save the end user a lot of time.
Right now you have a golden opportunity to correct market perception with this new release. The current perception of Torque - apart from us diehards who love it - is that it is buggy and very hard to use. I hope you are all concentrating on those bugs, and continue to concentrate on the little things that make it easy. You have increased the price considerably - along with that comes the assumption (on our parts) that the software will be much stronger.
And of course I agree completely with Brett Williams above.
PS - I hope someone is fixing the main forums page. For some of us, we can only see the "my products" group for the past few days.
08/01/2009 (8:48 am)
@Brett -Well you asked for an opinion, so I hope you don't mind that I give you one. Please take this in context - You have seen Post Beta 4, and I have not yet. Also - People who are intimately involved in the creation of the software tend to have a different view from the people who are trying to use it. Right now, you look at Beta 4 and say "it's almost ready". But I look at it, and say "It shows promise".
Bugs - I won't detail them, and I won't even discuss the big bugs as I'm assuming they will be fixed. But there is a predisposition to classify little bugs as "not a big deal" and release with them anyway. Usually because they're hard to fix, or it's assumed that they will affect few people. But for every bug that ships, each one adds up knocking out potential users and/or increasing the support overhead - which could be a nightmare for those of us who have only 1 or two people on a team.
Usability - We got to admit, this version is 100 times more usable than previous TGEA versions. But is it enough? Almost. Beyond the bugs, I think the only thing it is missing is a little better integration - for example, A) if you are in the shape editor, you should be ablt to directly go to the material editor for for the current shape without having to find it and reselect it. B) Making it more automatic and/or obvious to save the texture in the material editor, etc. Little things like that will save the end user a lot of time.
Right now you have a golden opportunity to correct market perception with this new release. The current perception of Torque - apart from us diehards who love it - is that it is buggy and very hard to use. I hope you are all concentrating on those bugs, and continue to concentrate on the little things that make it easy. You have increased the price considerably - along with that comes the assumption (on our parts) that the software will be much stronger.
And of course I agree completely with Brett Williams above.
PS - I hope someone is fixing the main forums page. For some of us, we can only see the "my products" group for the past few days.
#7
Torque 3D is a great project, but it is still quite a ways behind tgea in useability and fps. Lots of great things added, some things broken. With each release, there are tons of bug fixes (awesome job guys) but there are also things that are broken from the previous release. (it's to be expected. Tis why we have betas) At the current pace, I'd say its got a few more months work before it's even ready for RC status.
What i'd like to see is the same as everyone else here. Squash more bugs and fix the ones you've made squashing bugs. Optimise the engine more so the frame rates go back up. (not all of us have super computers) As for features, I'd say it's close to being feature complete. (if not there. I don't know all the features you wanted to get into this first release)
Overall, I'm happy with t3d. It's a nice engine. tgea is an easier engine to work with and fps is better.
That's really all I wanted to add. Ok, flame away. I have broad shoulders.
08/01/2009 (10:50 am)
Ok, I'm going to chime in here. Just don't blast me.Torque 3D is a great project, but it is still quite a ways behind tgea in useability and fps. Lots of great things added, some things broken. With each release, there are tons of bug fixes (awesome job guys) but there are also things that are broken from the previous release. (it's to be expected. Tis why we have betas) At the current pace, I'd say its got a few more months work before it's even ready for RC status.
What i'd like to see is the same as everyone else here. Squash more bugs and fix the ones you've made squashing bugs. Optimise the engine more so the frame rates go back up. (not all of us have super computers) As for features, I'd say it's close to being feature complete. (if not there. I don't know all the features you wanted to get into this first release)
Overall, I'm happy with t3d. It's a nice engine. tgea is an easier engine to work with and fps is better.
That's really all I wanted to add. Ok, flame away. I have broad shoulders.
#8
As for marketing I can't really say how this development model affects it but nothing hurts community support more then a mess of half completed features and regular crashes to desktop if you happen to push a button that is tied to something that's incomplete.
As of Beta 4 T3D is a pretty nice development platform and other then a few things which still don't do as you would expect them to it all works fairly well, so it wouldn't be a bad time for a code freeze to focus on fixing the bugs unless there's some major "got-to-have" feature planned for the next beta. Code freeze is also a good time for documentation which has always been a little lacking in many areas of the other GG engines.
EDIT: I should probably do more then speed read previous posts. I'm basically just reiterating what Brett Williams posted.
08/01/2009 (11:14 am)
It's worrying that GG doesn't even have a general timeline for a release candidate. This usually leads to feature creep and once you start adding in more features you find more bugs related to those features and then want even more. If a release candidate hasn't been decided upon there should at least be a number of features that must be considered necessary for a release candidate, and then once those features are all in the engine should be entering a code freeze phase where nothing is added other then bug fixes. Once it has been determined that the engine is stable enough to leave code freeze then there's no reason you can't add more features as long as the other stuff isn't touched without very good reason, but by the end of the first code freeze that should be a good time for a release candidate as it could be considered feature complete and stable even if the plan is to add more features later.As for marketing I can't really say how this development model affects it but nothing hurts community support more then a mess of half completed features and regular crashes to desktop if you happen to push a button that is tied to something that's incomplete.
As of Beta 4 T3D is a pretty nice development platform and other then a few things which still don't do as you would expect them to it all works fairly well, so it wouldn't be a bad time for a code freeze to focus on fixing the bugs unless there's some major "got-to-have" feature planned for the next beta. Code freeze is also a good time for documentation which has always been a little lacking in many areas of the other GG engines.
EDIT: I should probably do more then speed read previous posts. I'm basically just reiterating what Brett Williams posted.
#9
Well I for one am glad GG is employing programmers instead of prognosticators. ;)
I feel Brett S. laid out the different sides to it quite well. I would rather it gets released when everything is ready and not have something rushed out just to meet some arbitrary deadline. e.g. did it help MS or anyone else to have Vista pushed out when it was?
08/01/2009 (12:13 pm)
Quote:It's worrying that GG doesn't even have a general timeline for a release candidate.
Well I for one am glad GG is employing programmers instead of prognosticators. ;)
I feel Brett S. laid out the different sides to it quite well. I would rather it gets released when everything is ready and not have something rushed out just to meet some arbitrary deadline. e.g. did it help MS or anyone else to have Vista pushed out when it was?
#10
Oh and now that you have made the MAC platform it really need to be up to snuff. before 1.0. If that mean hold off on a 1.0 for a month or so I'm fine with that. it just mean that the windows/ and tools people have more time for QA before launch.
Oh yeah and the Docs. Must be 100% complete before 1.0
08/01/2009 (12:23 pm)
I gotta say it is hard to say without seeing what has been fixed since Beta 4. But since All I have to go on is Beta for I would say that there is at least 3+ month of hard work left. It is really hard to say without knowing what has been fixed post Beta 4 though. But beta 4 is nowhere near ready in my book. There do seem to be a lot of small bugs. From the tools that I deal with in my option The biggest thing is smoothing out the works-flow as mentioned above. Get a bunch of art interns in there and make the use all of the art tools for about 2 weeks straight and get the opinion of ARTIST. Honestly the opinion of a programmer mean squat when it comes to this stuff. Shipping a program for art generation because the programer or developer thinks that it is ready and Technically feature complete is a recipe for disaster. If things are shipped in any for close to what beta 4 currently is. You are just going to repeat the TSE/TGEA mistake all over again.Oh and now that you have made the MAC platform it really need to be up to snuff. before 1.0. If that mean hold off on a 1.0 for a month or so I'm fine with that. it just mean that the windows/ and tools people have more time for QA before launch.
Oh yeah and the Docs. Must be 100% complete before 1.0
#11
I had to look that one up, thank The Great Magnet for dictionary.com!
08/01/2009 (12:36 pm)
Quote:
prognosticators
I had to look that one up, thank The Great Magnet for dictionary.com!
#12
1. Documentation
2. More documentation
3. Advanced documentation
08/01/2009 (12:37 pm)
If we have these 3 features T3D will be light years above previous Torque engines. Because with these 3 features enhancements/bug fixes can be offered by the community.Here they are:1. Documentation
2. More documentation
3. Advanced documentation
#13
Actually I've just had a look at the new "proposed/placeholder" docs and this is very much the right track ... with a few extra tutorials thrown in - I've seen a forum mention that Mr.Perry's embondaged underling (intern) is hard at work on further things tut related.
08/01/2009 (12:49 pm)
I think Scott favours documentation ... ;)Actually I've just had a look at the new "proposed/placeholder" docs and this is very much the right track ... with a few extra tutorials thrown in - I've seen a forum mention that Mr.Perry's embondaged underling (intern) is hard at work on further things tut related.
#14
Would you guys feel better about feature clamping the product now and focusing on usability / polish / etc for the next 4-6 weeks. We can't spend 3 months on that kind of thing, but we're aware of some "last 5%" issues that we definitely want to address. If we did feature clamp now, it would just mean that we'd spin up a new branch (1.1) where we could continue adding some of the features we want to finish. Obviously this would be a free update and we might even be releasing betas there right after the 1.0 release.
@Nicolas: A Mac RC will almost certainly lag the Windows RC. A lot of the issues we are fighting I'll place squarely on Apple's door. It's just a much more difficult platform to develop a game engine for, especially one that's pushing next-gen rendering techniques. There are things you just can't do.
There's a reason why you don't see Gamebryo, CryEngine, Unreal, Hero, BigWorld, Vicious, Vision, or any other AAA engine supporting OSX : / If this were a windows-only product, it would have shipped months ago. More on that later. We're not dropping Mac support. There's no chance of that, but feature parity just might not be possible for things like Advanced Lighting in 1.0. We're going to try, and I'm confident that what we deliver will be the best game engine ever available for the Mac, but doing Crysis-style graphics might not be achievable.
08/01/2009 (12:56 pm)
Great feedback guys, keep it coming. Would you guys feel better about feature clamping the product now and focusing on usability / polish / etc for the next 4-6 weeks. We can't spend 3 months on that kind of thing, but we're aware of some "last 5%" issues that we definitely want to address. If we did feature clamp now, it would just mean that we'd spin up a new branch (1.1) where we could continue adding some of the features we want to finish. Obviously this would be a free update and we might even be releasing betas there right after the 1.0 release.
@Nicolas: A Mac RC will almost certainly lag the Windows RC. A lot of the issues we are fighting I'll place squarely on Apple's door. It's just a much more difficult platform to develop a game engine for, especially one that's pushing next-gen rendering techniques. There are things you just can't do.
There's a reason why you don't see Gamebryo, CryEngine, Unreal, Hero, BigWorld, Vicious, Vision, or any other AAA engine supporting OSX : / If this were a windows-only product, it would have shipped months ago. More on that later. We're not dropping Mac support. There's no chance of that, but feature parity just might not be possible for things like Advanced Lighting in 1.0. We're going to try, and I'm confident that what we deliver will be the best game engine ever available for the Mac, but doing Crysis-style graphics might not be achievable.
#15
I was under the impression that what was "in" or "listed as in but not working yet" (a few things in the editors that aren't hooked up yet) is pretty much on view - not all working as advertised, but on view. What is in looks great, and needs tweaking - hence feedback in beta forums...
Win user obviously, not trendy enough for a Mac.
edited for typo-hell
08/01/2009 (1:14 pm)
I suppose "Feature Clamp" ... kinda depends on what would get cut/delayed from RC.I was under the impression that what was "in" or "listed as in but not working yet" (a few things in the editors that aren't hooked up yet) is pretty much on view - not all working as advertised, but on view. What is in looks great, and needs tweaking - hence feedback in beta forums...
Win user obviously, not trendy enough for a Mac.
edited for typo-hell
#16
It depends on the features you are looking to add. If they are good features that add significant value to the product then I say keep it coming. "Feature creep" is a negative only if it is adding fluff to something just to justify a higher cost etc.
Would it be possible for you to give us an idea of the features that are planned but haven't made it in yet?
08/01/2009 (1:16 pm)
Quote:Would you guys feel better about feature clamping the product now...
It depends on the features you are looking to add. If they are good features that add significant value to the product then I say keep it coming. "Feature creep" is a negative only if it is adding fluff to something just to justify a higher cost etc.
Would it be possible for you to give us an idea of the features that are planned but haven't made it in yet?
#17
This is truly a new feature for GG ;)
I would say, finish up whatever is being worked on for beta 5 (or RC1 as it
was called ) and lets start 'polishing'.
The one major thing I'm looking for is the lighting stuff Pat Wilson was / is
working on (point light shadows and better integration of lightmaps ie PureLight) for me that is a must for 1.0.
I would also like to see grade A tutorials for things like exporting
new characters / objects from the major 3D apps.
(Max, Maya, LightWave, Houdini, Blender, XSI, Milkshape)
Also GG sponsored exporter plugins for the major 3d Apps ^^
What I'm trying to say is it needs to be 'simple' for any new torquer to
buy T3D, and get his / her content into the engine with the minimum of
stress & forum / web searching.
While your reading, could I also ask for a 3DS Max2010 dts exporter
plugin... pleeease :)
Again, thanks for listening,
Hewster
PS - I hope someone is fixing the main forums page. For some of us, we can only see the "my products" group for the past few days.
08/01/2009 (1:16 pm)
@Brett Seyler, Thank-you for listening, and taking our opinions seriously..This is truly a new feature for GG ;)
I would say, finish up whatever is being worked on for beta 5 (or RC1 as it
was called ) and lets start 'polishing'.
The one major thing I'm looking for is the lighting stuff Pat Wilson was / is
working on (point light shadows and better integration of lightmaps ie PureLight) for me that is a must for 1.0.
I would also like to see grade A tutorials for things like exporting
new characters / objects from the major 3D apps.
(Max, Maya, LightWave, Houdini, Blender, XSI, Milkshape)
Also GG sponsored exporter plugins for the major 3d Apps ^^
What I'm trying to say is it needs to be 'simple' for any new torquer to
buy T3D, and get his / her content into the engine with the minimum of
stress & forum / web searching.
While your reading, could I also ask for a 3DS Max2010 dts exporter
plugin... pleeease :)
Again, thanks for listening,
Hewster
PS - I hope someone is fixing the main forums page. For some of us, we can only see the "my products" group for the past few days.
#18
08/01/2009 (1:20 pm)
Oh, and terrain 'set empty' would be very high on my list for 1.0 too :)
#19
@Bryan: We certainly do have internal timelines and targets tied to specific features. Considerations have been made and are still being made to adjust the feature spec, almost universally upward. There are definitely a bunch of options. Like I mentioned above, the OSX stuff can be a pain, and is definitely slowing us down in areas. That said, what you see in Beta 4 is not complete. There are a few new features and a lot of features improvements coming in the next build (imminent).
We're looking at the next build very seriously as feature complete for a 1.0 release. We think this could be stable, polished, and very bug free by the end of August. Obviously, help from you guys would go a long way in that final leg. We'd continue to have some development targeted at 1.1 features and that could be ready to go for testing / beta release probably as soon as September / October.
A polished 1.0 release with the current feature spec, sooner rather than later, would go a long way to giving people who haven't adopted Torque 3D yet confidence that they could do so. We'd have more people using the product and more people producing great resources for it.
Those of you who have purchased Torque 3D already (everyone reading this forum), would have the assurance of knowing that more is coming, post 1.0 and quickly. In fact, I'd even be okay sharing our dev road map with you guys provided is stayed here, and it wasn't treated immaturely as a promise to deliver down to the last detail.
Though we plan thoroughly, in detail, each development cycle, things change and you have to adapt. Not having that flexibility because of some rigid commitment to publicized plans is what drives people like me into Apple-style disclosure...you get nothing, no information, until we're ready to release. As a consumer, I don't like that. When it's a set of tools I'm depending on using professionally, I really don't like that. Apple could save developers all kinds of headache if they'd share more in advance (or at all). They'd have better apps for their platform and better adoption because of it.
Maybe off on too much of a tangent there, so let me reel it in. I want you guys to be *ecstatic* about Torque 3D when we're ready to release. I want you to feel, genuinely, like it's something worth evangelizing yourselves and I want you to evangelize it yourselves. I want you to believe in the product, where we're going with it and in how incredible this team building it is. I'm amazed watching how fast these guys are moving Torque forward. There's real momentum that I've never seen before here and I'd hate to see it squandered because we were too timid to set a feature break point and cycle properly on polish enough take the beta label off.
That might sound like I'm arguing for more time, not less. What I'm actually arguing for is patience and understanding in those places where the feature set feels a little incomplete (especially on OSX), enthusiasm and appreciation for those places where we've really overdelivered (lighting / rendering / tools), and your help in getting through the polish / stability cycle so we can share this with a wider audience.
If you guys are on board with that, I promise you'll be happy with what we deliver in future (post-1.0, free update) cycles.
08/01/2009 (1:33 pm)
@Hewster: Quote:Oh, and terrain 'set empty' would be very high on my list for 1.0 too :)We've got you covered there :)
@Bryan: We certainly do have internal timelines and targets tied to specific features. Considerations have been made and are still being made to adjust the feature spec, almost universally upward. There are definitely a bunch of options. Like I mentioned above, the OSX stuff can be a pain, and is definitely slowing us down in areas. That said, what you see in Beta 4 is not complete. There are a few new features and a lot of features improvements coming in the next build (imminent).
We're looking at the next build very seriously as feature complete for a 1.0 release. We think this could be stable, polished, and very bug free by the end of August. Obviously, help from you guys would go a long way in that final leg. We'd continue to have some development targeted at 1.1 features and that could be ready to go for testing / beta release probably as soon as September / October.
A polished 1.0 release with the current feature spec, sooner rather than later, would go a long way to giving people who haven't adopted Torque 3D yet confidence that they could do so. We'd have more people using the product and more people producing great resources for it.
Those of you who have purchased Torque 3D already (everyone reading this forum), would have the assurance of knowing that more is coming, post 1.0 and quickly. In fact, I'd even be okay sharing our dev road map with you guys provided is stayed here, and it wasn't treated immaturely as a promise to deliver down to the last detail.
Though we plan thoroughly, in detail, each development cycle, things change and you have to adapt. Not having that flexibility because of some rigid commitment to publicized plans is what drives people like me into Apple-style disclosure...you get nothing, no information, until we're ready to release. As a consumer, I don't like that. When it's a set of tools I'm depending on using professionally, I really don't like that. Apple could save developers all kinds of headache if they'd share more in advance (or at all). They'd have better apps for their platform and better adoption because of it.
Maybe off on too much of a tangent there, so let me reel it in. I want you guys to be *ecstatic* about Torque 3D when we're ready to release. I want you to feel, genuinely, like it's something worth evangelizing yourselves and I want you to evangelize it yourselves. I want you to believe in the product, where we're going with it and in how incredible this team building it is. I'm amazed watching how fast these guys are moving Torque forward. There's real momentum that I've never seen before here and I'd hate to see it squandered because we were too timid to set a feature break point and cycle properly on polish enough take the beta label off.
That might sound like I'm arguing for more time, not less. What I'm actually arguing for is patience and understanding in those places where the feature set feels a little incomplete (especially on OSX), enthusiasm and appreciation for those places where we've really overdelivered (lighting / rendering / tools), and your help in getting through the polish / stability cycle so we can share this with a wider audience.
If you guys are on board with that, I promise you'll be happy with what we deliver in future (post-1.0, free update) cycles.
#20
me thinks
add the features that you planned to add, you have reasons, I'm sure, to add them. then Feature Clamp.
release that build as beta 5, no more features added after that point.
RC1 should follow, with no extra features added, but with bug fixes applied from the previous beta releases.
at this point, our job is to try and "break" the build, push it, try to make it crash, and reporting those bugs
RC2 should follow that, with more bug fixes that where found during RC1, and a general all round optimization/polish.
Realease 1.0 should follow that.
then everybody at GG should go on a well deserved vacation for a few days
EDIT: Brett posted while I was typing this post, so he has things covered
08/01/2009 (1:44 pm)
@Brett Seyler,me thinks
add the features that you planned to add, you have reasons, I'm sure, to add them. then Feature Clamp.
release that build as beta 5, no more features added after that point.
RC1 should follow, with no extra features added, but with bug fixes applied from the previous beta releases.
at this point, our job is to try and "break" the build, push it, try to make it crash, and reporting those bugs
RC2 should follow that, with more bug fixes that where found during RC1, and a general all round optimization/polish.
Realease 1.0 should follow that.
then everybody at GG should go on a well deserved vacation for a few days
EDIT: Brett posted while I was typing this post, so he has things covered
Torque Owner Hewster
Hewsoft
is it time for a RC.
In other words, you release betas until testers are no longer reporting
and bugs / unwanted 'features'. RC1 would normally be the same as the
latest beta, simply re-released and named RC1.
I also think, until a product is feature complete, it should be called an
alpha.
I for one am quite happy for the devs to take their time releasing 1.0,
and from a business point of view I think it would be a grave error
to release before its ready (all reviews on version 1.0 will follow T3D for
ever, even if initial issues were worked out).
So I explore GG not to push the devs to release too early.
The betas are coming along nicely, I know it may look bad to get to
beta 9, 10 or 11, but it is preferable to releasing before its ready :)
All just my opinion of course.