Next T3D 1.1 release?

#21

Quote:I think the tradition of releasing broken release after broken release is something that really needs to be fixed,

Many people would like that, I even think TP staff would like that!

Quote:I personally think that the constantly adding new shiny features, is the major contribution to the delays, and hopefully the new methodology outlined by Eric in recent posts will help address that particular issue and overall actually increase the number of 'stable and non broken' updates once we get past the transition hump.

Well, from what we have seen described so far, about this 'new methodology', it is NOT like...

Product vision
Plan all tasks (must have, should have, could have, would have)
Place them all in a product backlog
Project lead assigns elements from the product backlog into each sprint
Each ressource (worker) complete the assignments
Product backlog is completed
Product is done

But more like...
In each sprint 'we' plan to throw in stuff on the fly, stuff you guys can help define, so focus can be on those.

Quote:, but I'd honestly rather be getting frequent, broken updates than a couple of more polished betas.

As long as theres no defining on the product vision, and no deadline, and no product backlog, and no 'this is set in stone'. You (we) will get nothing but that.

After all these years, and a megaCorp takeover -it's still like every plate is carved in fresh wood and wrapped in fluff. It would be so awesome if the engines would simply be 'completed' in their current versions. According to their product backlogs, and with everything documented and defined in a whitepaper.

-that would be kickass development!

(and this is not a bitching about everything, but adressing actual methodology and definings in what I could do best with my improper English)

#22 Unless this new methodology works really really well. "Which I must say I'm really in doubt of" I think we are going to look to UDK for future projects. I would rather give up 25% royalty and have something that is stable and full featured than have the head-aches and half baked stuff that T3D is turning out to be. There are alot of cool things in T3D but at the new price the value is not there as the product currently stands.

Maybe I'm wrong but from the employee blogs that I read it still seems that there are still too many people in mission critical roles working on more than one product. It seems that there is still a lot of resource sharing with things like T2D, T3D and all of the ipad and iphone stuff.

The actual tools and engine teams at Epic are actually pretty small. Maybe even smaller than the team GG. Yet they manage to get releases of UDK with new well polished features out the door every month.

I think that one of the secrets to their success is that they tend to regularly strip out old and depreciated features. They are not worried about breaking Joe hobbyists game that he has been working on for 7-8 years and is never going to release.

The problem with the Torque crowd is that no one wants to let anything go. There is too much focus one making sure that that all of the Legacy TGE stuff works in T3D. There is so much of this engine that is in disarray going back almost a decade now.

there are soo many issues we are having in our project that we know are fixed in the next release that keeps getting pushed back.

GG you have an obligation to you customers to have a dependable release schedule. you could possibly have gotten away with thing before when the engine was $100 But at the current price level thing are unacceptable.

So take from this what you may, but unless things with this next release happen on time and as promised. Unless there is a marked improvement in the way things are handled at GG our current project will be our last to use Torque. If our company missed deadlines was as bad at meeting out obligations to our clients as GG we would all be out of jobs. I suggest that everyone in this community Think this over going forward and make you voices heard with you business. If GG doesn't listen and take it to heart and make serious changes. Well then they are not the only game in town like they once were not by a long shot. We can take out checkbooks elsewhere.

#23 This reminds me a lot of the Too Human incident. And that was UDK.

#24

Quote:there are so many issues we are having in our project that we know are fixed in the next release that keeps getting pushed back.

So far in T3D's lifetime all i have really been able to do is prototype art assets. Every time i start level design , script programing or poking around in the Cfiles; I run into busted stuff only to do website search here and find that It is a well known reported bug(with no official GG reply), or the bug should be fixed 'in the next beta'.

I am starting to fear that by the time T3D is stable and usable (as a GAME engine; not just a simple FPS engine) it is going to be old fashion and out of date.

In the last year+ that T3D have been alive and slowly evolving many of the OTHER game engines and even development tools that i work with have released a full new product version that 'work' and are stable. Why is it taking so darn long for T3D?

#25 @ Henry Todd:

I agree with a lot of things you said, shouldn't QA be us?? You can stick a bunch of people in a room and say find bugs. but they are not going to find the same bugs as the actual devs working on games and porting their project since 1.0 alpha. we had ran into a ton of bugs in the last release. QA should be active community members with active projects.

#26 Hey Guys, Matt Fairfax will be updating this thread soon.

@Stadi - QA is a combination of our internal team and the community. They work hand-in-hand. Internal QA will help us insure that there aren't any major breaks in a release. For example, we once had released a version where we broke dedicated servers by accident -I'd rather not have the community find a bug like that.

Scott, our lead for QA will be posting a blog today to help provide more details surrounding how our internal QA will better utilize the community. It doesn't do us any good if you guys report bugs and we don't have a path for getting them into our development pipeline. We've followed this process for our recent iPhone release and it worked very well for both sides.

Matt's post to follow...

#27 Hey guys and gals,
Ok...there are a lot of topics to discuss in this thread so let's dive into them:

Quote:I'd honestly rather be getting frequent, broken updates than a couple of more polished betas

This is about the 3rd or 4th time I have seen a debate in this community about whether or nor we should release more frequent "risky"/untested builds or if we should take the time to release only polished stable builds. In this thread the leaning is more towards rapidly released "risky" builds but the last time this came up more people were in favor of waiting for polished/stable releases.

I honestly think there is a middle ground where we do more frequent (but not necessarily "rapid") releases that have had some basic QA and are generally more polished than the last release. There will always be people on further ends of the two extremes ("I want Subversion access to every commit" vs "If it isn't stable, I'm not touching it") but I am a firm believer that catering to either end of the spectrum is ultimately a losing strategy.

As you may recall from my last Torque 3D blog, I have already outlined a "rolling update" strategy that will hopefully address this in the proper way and will offer up just the right amount of frequent stable releases.

Unfortunately, we need to get a few other things off our plate first (near term releases of TGB 1.7.5, Torque X, and iTorque) and reach a good starting point for those rolling updates (Torque 3D 1.1 Final) and it has taken us a little longer to wrap up those projects than we anticipated. We only have so much resources at hand and sometimes things need to have a higher priority.

There are several people hard at work on Torque 3D 1.1 Beta 2 at this very moment but we still have a little further to go.

Quote:I think we as a user base would like to get these eariler versions that haven't gone through huge amounts of Q & A and test them ourselves...I think we could find things that they couldn't

As Eric hit on...it is a combination of both QA and community. Shipping you a build where networking doesn't work or where the installer deletes your Desktop or where the Physics demo consistently hard locks your computer isn't going to do anyone any favors. At the very least, every release needs to go through a basic "smoke test" to make sure these kind of basic issues don't exist. That is why "just releasing" a build isn't a matter of pushing a button. Even a "safe" change still needs a bare minimum of two days of QA testing before we will let it into the wild.

However, as you alluded to, it would be near impossible for the QA department to give the underlying engine a proper working over. There are certain things that just won't come to light until you are actually doing game development against an engine. We absolutely need your help and feedback to find these kinds of issues.

Quote:I remember TGE/V12 used to allow us to have access to a newer version through CVS. (And they had an internal CVS also)

Quote:I too miss the days when we had CVS access so we could see the checkins, see what was going on, grab a fix that they checked in and integrate it into our own version if we wanted

I was there in those days. I was actually one of the developers actively committing to that CVS repository from the very beginning (even before ;). It worked at the time but it really hasn't been feasible for a long time. Let me explain =)

When we originally launch V12 (TGE), there was a single project with a single team completely dedicated to rapid and active development on that project. At that point the engine was very much an experts coders engine with virtually no tools. It required experience and knowledge to use and appealed largely only to that type of customer. We could put a live CVS server in front of that type of customer and they understood exactly how to use it and what it represented. In other words, they had the proper experience to manage their own expectations.

Over the years after that initial launch we began to take on different projects and to create new products. Suddenly we had projects and code that we couldn't share with the general public (even paying public), either because it was illegal (like sharing Xbox developer code), impractical (shipping the source code to your game before it is released would pretty much gaurantee failure), or because the projects were not in a state where it made sense to share them and would have only hurt expectations and sales. We also began to slow down development on TGE because our resources were spread out and even though we were working on tons of stuff that was beneficial to both our customers (TGB) and to the company (Marble Blast), the only insight that people had was a slow down in the number of commits to the TGE repository. More development than ever was going into our products but it wasn't evident and that raised alarm and caused sales to dangerously slow down.

Around that point we had to move to an internal CVS server so that we could protect the private code. We also then had to start doing regular syncs/merges from our internal repository to the public one. As anyone who has had to do that kind of work can tell you, it can be tedious and very time consuming if everything doesn't go perfectly. Eventually it reached the point where we could only afford to do the syncs every couple of months at which time a lot of the issues you guys have been highlighting in this thread reared up (huge merges, lack of insight into individual bugs fixes, no visibility into what we were doing in the meantime, etc). We had also had a shift in our customer base as more and more inexperienced customers bought the product as a result of us making it more user friendly. Expectations became very difficult to manage and it became increasingly difficult to coach people through using CVS.

At that point we decided to make the shift to releasing more polished builds with actual installers and have been ever since.

Much of the problems we had then in regards to having a public repository still pretty much exists today. We have code that is illegal to share. We have projects that aren't ready to be seen. We have customers who would not be able to correctly manage their expectations of what they are getting no matter how much we messaged (you should see the stats on the appallingly low number of people who actually read our documentation).

The pure coder in me would love to give everyone Subversion access but it just isn't practical.

Quote:I do think more frequent versions could result in better overall community feedback and bug catching

Quote:Maybe GG should take smaller bite size pieces to improve and test and get into a rhythm or smaller faster releases instead of giant, hard to test, increments that take 6 months or longer to build and test

As I mentioned above and in my last Torque 3D blog this is exactly the type of development methodology that we are heading towards but we do need to finish up one last "giant, hard to test" release before we can move on.

Quote:Its then a nice commitment to us that your willing to set a date, focus on it, and stick to it

There are plenty of documentation about why setting a date "in stone" doesn't work when working in high risk, cutting edge software development so I won't go into the gory details but suffice it to say that unless we set the date so far out as to not be useful to you, it is pretty much impossible that we will always hit the date and, trust me, missing a release date is far worse for sales and expectation management than having a vague date. We literally have years of hard won experience in that area. We are constantly striving towards being able to communicate better release "windows" but it takes a lot of time and practice and is not always possible.

Quote:there are still too many people in mission critical roles working on more than one product

This is absolutely true.

One of my primary responsibilities as the Torque Technical Manager is to drive our technology towards convergence. We have already started the work needed to converge our product lines and technology bases and it is a major focus for us this year but we have a lot of work ahead of us and aren't ready to start talking about it.

#28 @Eric & Matt: Thank you for taking the time out of your busy schedules to write posts like this. It is much appreciated!

#29 Double what Kerry said and add this on top:

Now,..
Show Us The Money![/Jerry MaGuire]

#30 The solution to this is simple, stop developing so many engines at once! One great product is much better than having five mediocre ones.

TorqueX needs to just be dropped. I highly doubt it is bringing in that much money. I find it very unfair that I dropped $1000 and my releases are being pushed back due to development on TorqueX.

If Torque doesn't change drastically soon, our only choice will be Unity. :(

#31 And some of us don't even have options like that Jon, we've spent far too much money and time integrating features with Torque and AFX2 and just have a small number of issues needing addressed.

I also feel its unfair that we are looking at a one year update-to-update cycle. Being a software developer I understand whatever pays the bills gets attention believe me. And every time the latest and greatest new thing comes out on a new platform it will create a nice burst of cash.

Has the "one time license free update" model ever been the correct way to develop a game engine that is up to date and full of active development? I paid to update from TEGA to T3D because it was a big upgrade and I would pay for a update again if it was necessary.

I don't know what the answer is here and I hate to think of any doom and gloom stuff when I have so much invested banking on the next release being great and doing our final merge then releasing our beta. The absolute last thing we want to do is engine jump because it involves thousands of dollars of development for us beyond the cost of whatever engine we jump to and to be honest I have not seen another engine that delivers frequent stable updates any better than the GarageGames guys, for example V3D I think is going on 8 months on their beta7 which we seriously evaluated.

All I am saying is please fix as many bugs and stability issues as possible and give us the update when you can. I am sure there are others waiting to do a final merge for their game as well that feel the same way.

Sorry for the long post but it has been frustrating.

#32 I agree with Jon D, I hate hearing news about how there is x and y coming to some fancy thing I don't care about and other things non T3D. Though I have gotten used to the idea of T2D. It makes me wonder how balanced the development is to the paying customers.

I was happy going from TGE to TGEA. It was the shiny new toy, but didn't work very well until its last release. Which by then I was trying out the new shiny thing which sounded like it was the solution to everything.

By the way when is the next paid update?

Not to say that T3D, isn't nice, the new editors look great. I just hope the bugs get fixed, as I mentioned eariler I find the latest release very unstable. Especially when I click "save" which is rather counter productive and extremely hard to build up any energy to do work over and over.

I want to use the later releases because I heavily use forests in my game.

Anyway back on track. It would just be nice to get bug fixes released sooner. And there is so much talk about how T3D is going to be uber good with QA etc and well I'm rather pessimistic now. Maybe just say that it's going to be OK so we don't set our standards too high? Instead of talking about how great QA is and upcoming talks before the pudding is served?

#33 @Jon - I don't think anyone suggested that a Torque 3D update is getting pushed to the back burner because of TorqueX. There is some conflict due to bandwidth of QA, but Torque 3D work isn't being phased out in lieu of TorqueX.

I don't think droping TorqueX is a good solution either; Microsoft is making huge investments in XNA and many of their best native programmers have moved to XNA already. It's a bit to early to see the effects of Game Studio 4.0 but there is some great potential in the APIs future.

Our plan to reduce overhead caused from having such a broad product line is convergence of the different products so that our code management per person is greatly reduced. I realize I'm repeating myself here.

@Chris - We are actively fixing bugs. We will also be increasing the frequency of updates for Torque 3D after 1.1 is released.

@Edward - I've heard this concern in other places as well and there is validity to your concern. The QA team has gone a long way towards making us more efficient. Instead of having our devs search for and log bugs, we have five to eight people organzing the bugs so that devs can focus on fixing bugs rather than discovering, reproducing, and verifying.

Having said that, I don't think we've suggested anywhere that having new QA is going to produce perfect releases overnight. It's going to continue to evolve as QA develops more automation and we fix more and more of the bugs that the community reports. We think that the QA team is a huge step in the right direction.

#34 With regards to broken updates, one thing i would like to see would be that the new versions have ALL the working features of the old version. I mean, thats to be expected right ? After porting my project to 1.1b, i'm saddened to fine certain features which were working in TGEA, not working in 1.1b (needless to say before 1.1b, porting was a totaly no go). This has forced my to now end up developing on both T3D and TGEA, T3D in hopes that when everything is finally working fine, it will be easier to port, and TGEA because i still have to produce something while waiting...

TGEA was also more or less similar, with only the last few releases being having a more decent level of polish. Sadly, after those releases, it was dropped and T3D was introduced...

On a side note, I have preordered Unity 3, as a source of another alternative. UDK is free, and Big World has launched their Indie. I have tried all 3 (unity 2.61 or course, not 3) and in terms of stability and polish, i'm sad to say they are currently ahead of T3D.

I hope this will be resolved, once the code convergence is complete, and overheads have been reduced, as I still like T3D alot and see potential in it, sort of a diamond in the rough. Incidentally, I have some question with regards to the convergence of code base.

1) any estimates on when it might be done ? (Wishful thinking on my side trying to get a timeline :P )

2) What does this mean to us as users aside from "we will have more time to fix stuff so you will have more updates". What i mean is. What does the convergence in code of say T3D and T2D do for me ? Will i be getting some nice gui/2D features from T2D ? Will the legacy stuff (and the entire code in general... despite the "engine rewrite" of T3D, there is still tons of legacy code around...) finally be cleaned up (don't tell me you're converging all legacy code as well...) ? Or... *Shudders* "If you buy T2D for another grand, you can integrate it nicely with T3D !"

#35 Was not convergence of the code base all the big talk near a year ago, with the same 'speed up production' promises?

Have not I read this very same type of rhetoric from GG before?

Was i mistaken, seriously mistaken, when in the early days of T3D we(EA beta customers) were lead to believe we would be seeing new beta builds about every 2 weeks?

I have been seeing a rather ugly pattern of behavior trailing behind GG's many forgotten ugly game engines and now dead side projects. I dont think the TGEA people would have gotten TGEA1.8.2 if it were not for so many of us bitching about how crappy TGEA was, with its long standing bugs and ever shifting feature set.

A game engine is supposed to accelerate development time, not hamper it.

#36 @Cai - Currently our project schedule estimates suggest that we will have our first phase of convergence complete around the end of the year or the beginning of next year. It's a tough estimate to make and we are uncovering and solving many challenges right now that will help us build a more accurate estimate.

As for what it means for our customers, it's hard to say exactly -the development benefits; however, are vary clear and unobjectionable. The best I could suggest is that having a converged product would give us a lot of options and a more efficient team to meet your needs. I'm hesitant to comment more on a project that is that far out and of this complexity but we have a lot of internal ideas how to share this work with you that we can unveil with our associates and all developers as we get farther along.

@Caylo - Not sure if there are any words I can say to give you any satisfaction. All I can say is that we are working tirelessly to realistically scope and achive our goals. Seems to me like you are more interested in actions and not words. I assure you that we are on the same side in that regards.

This is the challenge we face. It's a difficult balance that we operate in -it's part of the job. On one hand, we are asked to divulve as much info as possible. Othe the other hand, we are accused of making false promises if we share information that doesn't come to fruition as originally planed. I'm not asking for pity. Again, it's part of the job and we love what we do even with the challenges.

#37 [before you read this, please understand I am making this post while being very calm. I ask everyone; Please do not twist my words to suit your case.]

"Our plan to reduce overhead caused from having such a broad product line is convergence of the different products so that our code management per person is greatly reduced. I realize I'm repeating myself here."
- No offense Eric. But we've been hearing similar things since the early days of Brett Seyler. The TGEA/Juggernaut fiasco/junket comes to mind.

On a larger note for this topic;
We've been hearing promises for years now. I happen to dislike GG's business promises. I feel that GG's business-promises are a guise for GG business-tactics. -> What do I mean by that ? Here is an overly awesome-tastic example to help explain what I mean!!!!

Brett quoted Gerhard, in one of Brett's blogs created to hype T3D & boost sales;
"I am currently working on some AI and advanced shaders for Torque 3D which includes:
Screen Space shaders (Ambient Occlusion (SSAO), Bloom, Depth of field, Geometry smoothing. Motion blur)
GPU cloth dynamics.
GPU simulated water effects(these were dynamic ripples iirc).
GPU soft particles.
GPU soft/rigid body dynamics.
Dynamically destructible objects.
Computational intelligence algorithms for AI usage.
Multi-pass deferred CustomMaterial shaders."


Brett - posted - that - in - his - own - blog!!!
But, unless I am seriously in bizarro world, where are the features listed in bold?!

You see; We have been fed a decent amount of bullcrap on a shiny golden platter.

The irony behind all of this is;
Brett told us that it wasn't going to be like that, this time; development was not going to lack features or fall to half-baked 'workitude'..T3D was going to rock and be the pillar of awesome!

Oh how dumb we all are to have fallen for it once again.

#38 I'm with James on the matter of: Please focus on what we have now and drop legacy stuff thats not supported anyway. It costs you development time and it always has and always will fuck up something at the end of the day when it comes to efficient rendering or handling.

As GG is now offering the current and the previous versions for download, there is no reason not to do. People that use stuff that has been cut and don't want to port can always decide between backport fixes or upport the project.
Just ensure to have changelists for each versions (and potentially offer that in the download portal too) that point this kind of stuff out.

We don't need stuff that pretends to be there while its just a dead body from good or commonly not so good old days to "pretend easy upgradeability" from old engines. I doubt anyone has been helped by this fiction so far. At least I ended up pretty pissed on TGEA when I worked with stoneage terrains from TGE and the impact on performance also wasn't from the nice side. T3D in some areas still is suffering from those stone age stuff that hangs around and aside of causing rukus, isn't doing much good.


As for QA queue pushing back stuff: how about big qa and small qa: for betas that are meant to be taken appart by us anyway, a small qa should be fine (its not like you need X persons to do unit tests to guarantee that technical functionalities work). For the RCs and final release, the "big qa" then would be forked in.
I don't know how big you rate T3D on your own engines plan but from the way its promoted to us, a dedicated QA member to do ongoing QA on the beta to prevent such "major breaks" should definitely be an option and would ensure the required quality for a beta as well as preventing the major bombs.

That way the betas can happen on a usefull timescale. With betas taking basically months between versions we are no longer talking about betas but full minor releases. Betas for the same minor in normal world commonly means a release schedule of 2-3 weeks between versions normally and I think thats what GG should attempt to target at for T3D 1.1 too.


T3D has definitely gone a better way than TGEA when it comes to quality.
But its development although again being called the new flagship, is from our point of view stagnant and that although we are currently in a beta phase for a new minor which is more than just worrying I've to say.

#39 Hi Eric. I believe that the problems every developer here faces are promises, features, timelines that were made before the buyout are no longer current, changed or delayed. A shift in the timeline due to things being in the air for a while has also caused a knock on effect.

Individuals, Teams and Studios who have spent the last several years developing a game have either been forced to migrate over to T3D or have done it because it makes logical sense to keep up to date with the engine technology out there since the other engines (TGE/a) depending on your type of game are out of date.

This has obviously added frustration, anger and negativity, especially when time and money has been invested into projects that cannot be released until a certain level of production on the engine has been completed enough for it to be stable for a game release, and even then we will have to wait for middleware/bolt on's such as AFX2 to catch up before we can implement everything required. must admit, we are at BETA release with our game, but with bugs and performance issues which will hopefully be addressed in later engine BETAs.

I am releasing our updates a few weeks after each engine release and hope that the final release will not be a year down the line as I like other people need to make a return on the investment we've made with a stable product and soon! There is no turning back for me now, even if I wanted to switch engines it would cost me dearly. There seems to be several games that are close to BETA within the GG/TP community and it would be good to see these games shine, and be a flagship for the engine.

T3D rocks! and with a solid foundation in place as soon as possible only then will people be much more happier, even if it means shifting people from Instant Action over to Torque which seems to be getting lots of love and TLC at the moment, at the cost of slowing down Torque production? Maybe/Maybe not (it's not for me to say or know) but that is the impression it gives.

Everybody is hearing what you are saying, but the grain runs deep. As a new head of department, it's very difficult to crawl back what a company or team has lost in terms of past reputation because of what was wrong/lack of funding or resources - that resulted in saturation. (I've been there and it's not easy!) GG being taken over and re-organised was the best thing for it, and you're heading in the right direction. Just slower than what people had anticipated and being no fault of your own. If the buyout happend maybe a year before, things may have been different. But hey, lets not work on (What could have been), looking forward to the next releases. Keep at it.

#40 @Marc

Quote:
As for QA queue pushing back stuff: how about big qa and small qa: for betas that are meant to be taken appart by us anyway, a small qa should be fine

That's sort of what we're doing. I'll go into more detail about in my blog that's going up today, wasn't able to finish it yesterday like I had hoped, but the QA team and the community will be hammering away at the same build at almost the same time. When we receive the build it will go through some light testing and then will be released to the community.

Quote:
(its not like you need X persons to do unit tests to guarantee that technical functionalities work).

Quite the opposite actually. As Matt mentioned before, no one is done any favors if the engine implodes out of the box. If I were to task only one person with running through "smoke tests" to make sure that doesn't happen, then you guys wouldn't get your hands on Beta 2 for another month.