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.
#2
Yeah SEAL Team was great, shame no one ever seemed to build on it. And now in my opinion first person shooters that are meant to be realistic are more like "on the rails shooters".
05/12/2010 (5:45 pm)
Well just some vague date could be nice.Yeah SEAL Team was great, shame no one ever seemed to build on it. And now in my opinion first person shooters that are meant to be realistic are more like "on the rails shooters".
#3
05/12/2010 (5:54 pm)
In my opinion, Game engines are very complex. The employee blogs should have an idea when the next one is ready. Other then that any prototyping you should be able to port so do not worry to much about it.
#4
05/12/2010 (5:57 pm)
Well at the moment I'm using pre 1.01 due to I find it more stable when using the editors and particularly when I save my work. So I'm hoping for a 1.1 release which is stable enough for me to work with.
#5
--------------
I agree wholeheartedly. I even reinstalled the old "Armed Assault" over the weekend for remembrance of how war simulators work -- incredibly frustrating but still rather interesting - a more fun version would be nice, something like a midway point between the anality (is that even a real word?) or ArmA/OFP and the accessibility of CoD (older CoD -- haven't played MW2 ... didn't like the looky/feely of it ... plus no servers).
Also Armed Assault, the environment, it's look and feel ... really reminds me of a T3D environment.
-----------
I've found 1.1b1 to be quite stable ... + forest editor ... with a few additional bugfixes that got posted in the forums (but the wait time on opening editors has been driving me nuts!).
05/12/2010 (6:02 pm)
Blog quote from mid-april - it counts as vague ... so this month ... maybe ...Quote:
Without pinning us down to a specific release date, I will say that I expect that we will be able to ship it in the next month or so.
--------------
Quote:
And now in my opinion first person shooters that are meant to be realistic are more like "on the rails shooters".
I agree wholeheartedly. I even reinstalled the old "Armed Assault" over the weekend for remembrance of how war simulators work -- incredibly frustrating but still rather interesting - a more fun version would be nice, something like a midway point between the anality (is that even a real word?) or ArmA/OFP and the accessibility of CoD (older CoD -- haven't played MW2 ... didn't like the looky/feely of it ... plus no servers).
Also Armed Assault, the environment, it's look and feel ... really reminds me of a T3D environment.
-----------
I've found 1.1b1 to be quite stable ... + forest editor ... with a few additional bugfixes that got posted in the forums (but the wait time on opening editors has been driving me nuts!).
#6
Though yes, a slightly more fun version of it would be good. Mainly around movement.
I really don't like been able to fly aircraft and tanks in games. Except if say your class is a tank driver or pilot. But yet your just some grunt and jump in a helicopter...
I blame consoles for this fall in quality of games. I think the height of PC games was around 2001. Which was still gameplay is important and we started to get good Graphics. Now gameplay is dropped and we have generic titles.
Anyway...
Thanks Steve for the vague timeline. :-)
By the way Steve your game looks fun.
05/12/2010 (10:35 pm)
Yeah Armed Assault was good, and with its multiplayer too. But not enough people online.Though yes, a slightly more fun version of it would be good. Mainly around movement.
I really don't like been able to fly aircraft and tanks in games. Except if say your class is a tank driver or pilot. But yet your just some grunt and jump in a helicopter...
I blame consoles for this fall in quality of games. I think the height of PC games was around 2001. Which was still gameplay is important and we started to get good Graphics. Now gameplay is dropped and we have generic titles.
Anyway...
Thanks Steve for the vague timeline. :-)
By the way Steve your game looks fun.
#7
That fella needs some Ritalin ...
05/13/2010 (12:04 pm)
Quote:Post #2
And now in my opinion first person shooters that are meant to be realistic are more like "on the rails shooters
Quote:From Gamasutra:
Epic Games design director Cliff Bleszinski "gets on his soapbox" to discuss why "those 30 seconds that you do over and over" make a great FPS.
That fella needs some Ritalin ...
#8
It's surprising his been around for ages and made a few of my favorite games, Jazz Jackrabbit, Tyrian and Unreal. But then he seemed to drop off with pretty basic titles that didn't really advance games.
Like Unreal II :-O
05/13/2010 (5:37 pm)
haha nice quote.It's surprising his been around for ages and made a few of my favorite games, Jazz Jackrabbit, Tyrian and Unreal. But then he seemed to drop off with pretty basic titles that didn't really advance games.
Like Unreal II :-O
#9
I personally liked the path of the original T3D beta than this long cycle going on right now. I realize that B2 has apparently gone in for internal QA and that whatever we get will likely be more polished than what we've seen before, but I'd honestly rather be getting frequent, broken updates than a couple of more polished betas. 1.1B1 is too flaky for my tastes, so beyond the time I spend testing simply for the sake of testing and with an expectation of a serious delay before fixes to its new problems appear, I've pulled back to 1.1a. I realize the betas don't exist specifically so that I can play with the latest updates, but I do think more frequent versions could result in better overall community feedback and bug catching. If there's some concern about users being discouraged by exposure to "broken" versions, they could be more blatantly labeled as "dangerous radioactive test version for crazy thrillseekers only." In reality the concerns are probably more related to the manpower used in packaging, releasing, and taking feedback on each version.
Anyway, I have my complaints but I trust that the team has determined that this is the most effective way for them to keep things moving on 1.1, and I look forward to it, whenever it appears.
05/18/2010 (10:15 am)
I was never really a huge fan of the guy's work, but I have to admit that he knows how to do the thing he does. His games aren't really my style, but for the crowd that likes "30 seconds of repeated action," he's clearly giving them a great 30 seconds or they wouldn't keep coming back. And arguments about repetition and scale aside, the concept of refining a game to its "fun core" is a great point in any genre. CliffyB's erratic and potentially ADHD behavior aside...I personally liked the path of the original T3D beta than this long cycle going on right now. I realize that B2 has apparently gone in for internal QA and that whatever we get will likely be more polished than what we've seen before, but I'd honestly rather be getting frequent, broken updates than a couple of more polished betas. 1.1B1 is too flaky for my tastes, so beyond the time I spend testing simply for the sake of testing and with an expectation of a serious delay before fixes to its new problems appear, I've pulled back to 1.1a. I realize the betas don't exist specifically so that I can play with the latest updates, but I do think more frequent versions could result in better overall community feedback and bug catching. If there's some concern about users being discouraged by exposure to "broken" versions, they could be more blatantly labeled as "dangerous radioactive test version for crazy thrillseekers only." In reality the concerns are probably more related to the manpower used in packaging, releasing, and taking feedback on each version.
Anyway, I have my complaints but I trust that the team has determined that this is the most effective way for them to keep things moving on 1.1, and I look forward to it, whenever it appears.
#10
Cl*ffyB focuses on looks over FUNdamentals. I dislike those types of games.
05/18/2010 (10:58 am)
good post Henry.Cl*ffyB focuses on looks over FUNdamentals. I dislike those types of games.
#11
I nearly choked on my ale laughing! :)
05/18/2010 (1:11 pm)
Quote:
users being discouraged by exposure to "broken" versions, they could be more blatantly labeled as "dangerous radioactive test version for crazy thrillseekers only.
I nearly choked on my ale laughing! :)
#12
I don't know the full Q & A process. But we are in fact using the engine and building on it. I think we could find things that they couldn't? And thus if our input could be given during the Q & A process somewhat maybe we could improve the release and also get more frequent versions which may have fixed some nasty bug which everyone wants fixed to be able to use the new version.
I remember TGE/V12 used to allow us to have access to a newer version through CVS. (And they had an internal CVS also)
Maybe we could have releases, stable builds and nightly builds(well lets make this weekly)?
On CliffyB I read a bit on him from gamesauce.org
05/18/2010 (4:04 pm)
True, I hope the Q & A process improves releases but still 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 don't know the full Q & A process. But we are in fact using the engine and building on it. I think we could find things that they couldn't? And thus if our input could be given during the Q & A process somewhat maybe we could improve the release and also get more frequent versions which may have fixed some nasty bug which everyone wants fixed to be able to use the new version.
I remember TGE/V12 used to allow us to have access to a newer version through CVS. (And they had an internal CVS also)
Maybe we could have releases, stable builds and nightly builds(well lets make this weekly)?
On CliffyB I read a bit on him from gamesauce.org
Quote:
Steve: You want epic? I don’t know if anybody here
was at GDC in 2002, but there had been a lot
of smack-talk between Valve and Epic about
Soul Calibur. It ended up with a very public
challenge issued by Robin Walker from Valve
to Cliffy B. and his boy—they were going to
have it out on the floor of GDC after hours.
So we all came down there with the Dreamcast,
and we conned the people from Gamespy
into letting us use their big screen TVs. We
were early, so we set up and just started playing
around while we waited for Cliffy and his
team. Robin, who was sort of uncannily, unnaturally,
I-sold-my-soul-to-the-devil good
at this game, was just taking on all comers.
He played for ten minutes, then twelve, then
thirty, forty, fifty minutes without losing a
match. He took on, like, sixty people in a
row and lost just one match. About forty-five
minutes into this hour-long thing, Cliffy
and his boys showed up. This was during the
Cliffy B. pimp phase—with the large collar
and the hat and everything. So he is there
with his boys and kind of fingering his chains
at the back of this huge crowd now. He and
his posse start coming in towards us, and he’s
getting closer and closer. After he’s watched
about twenty-five straight wins, we’re like,
“Hey, you ready yet Cliff?” And we turn
around and they’ve all gone. Just left.
#13
But believe me im so sick of waiting on GG to finish what they hype, if this next build is not equal to the lip service we keep getting rammed up our external acoustic meatus, im asking for a refund and moving onto something more dependable from someone more professional.
05/18/2010 (4:54 pm)
So far all i have seen from this new QA process is an even slower GG production cycle. I hope im very wrong and when we do finally have the next T3D, no one can find anything to complain about, and everyone is so happy rainbows burst forth from our assets. But believe me im so sick of waiting on GG to finish what they hype, if this next build is not equal to the lip service we keep getting rammed up our external acoustic meatus, im asking for a refund and moving onto something more dependable from someone more professional.
#15
With that said however I would very much like it if GarageGames (Torquepowered) would adopt the method of other projects and provide access to both a stable and nightly build category of the engine. Thus we get polished Q&A releases and bleeding edge (I think I might have fixed this today at work so I'm committing it to the nightly build) versions that people can use and merge on their own.
05/19/2010 (5:02 am)
Just to chime in on a dead horse probably but I love that Q&A is being taken seriously, and good Q&A can defiantly slow down the process of a release.With that said however I would very much like it if GarageGames (Torquepowered) would adopt the method of other projects and provide access to both a stable and nightly build category of the engine. Thus we get polished Q&A releases and bleeding edge (I think I might have fixed this today at work so I'm committing it to the nightly build) versions that people can use and merge on their own.
#16
Nightly builds work for OS projects not commercial level tools products, I think nightly builds provide an even worse solution by providing more broken releases just on a daily basis rather than monthly basis like the betas were.
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.
05/19/2010 (7:11 am)
I think the tradition of releasing broken release after broken release is something that really needs to be fixed, and if we have to wait longer between releases so be it, so long as they ARE polished.Nightly builds work for OS projects not commercial level tools products, I think nightly builds provide an even worse solution by providing more broken releases just on a daily basis rather than monthly basis like the betas were.
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.
#17
The main branch for your project should never be broken as you can break everyone else that's working on it.
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.
smaller increments are easier to build, easier to test and get something to us more often. sure its not as gee-whiz as a huge update that we have been waiting a long time release but it makes the releases more manageable.
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.
also there is nothing wrong with putting out a possible release date instead of the "its done when its done" as it gives you and us something to shoot for, it places a time constraint that forces you to made decisions, cut stuff thats not finished, start the QA in a timely manner and hopefully if managed well prevent feature creep because of having a wide open end date.
Its then a nice commitment to us that your willing to set a date, focus on it, and stick to it.
It helps you get into a cycle of this much time for development, this much time for docs, this much time for testing/qa, this much time for bug fixing, release. rinse and repeat.
you fit what you can do into the schedule instead of fitting the schedule to everything you want to do.
you might even do a build when following that type of schedule that is just bug fixes and nothing else, maybe another build are packages added to the engine (like rts starter kit, fps starter kit, rpg starter kit, etc)
I think at this point it would be nice to actually have a released version of T3D and although its admirable to want it to be "perfect"
you need to get it out as the community is drooling to get there hands on it and lets face it the community finds even more bugs then test (more eyes looking at it).
broken releases really don't have anything to do with how often(how frequently you release) its a process problem.
with the right process you could release every month.
just because you take 6months, a year, or whatever does not mean you wont have the same problems unless the process is fixed.
anyway Im sure T3D will rock and GG will get all the issues resolved
its just hard to wait for something you want so badly lol :)
05/19/2010 (10:44 am)
nightly builds is what a lot of other products do not just OS projects. If your nightly builds don't even compile you have big problems.The main branch for your project should never be broken as you can break everyone else that's working on it.
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.
smaller increments are easier to build, easier to test and get something to us more often. sure its not as gee-whiz as a huge update that we have been waiting a long time release but it makes the releases more manageable.
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.
also there is nothing wrong with putting out a possible release date instead of the "its done when its done" as it gives you and us something to shoot for, it places a time constraint that forces you to made decisions, cut stuff thats not finished, start the QA in a timely manner and hopefully if managed well prevent feature creep because of having a wide open end date.
Its then a nice commitment to us that your willing to set a date, focus on it, and stick to it.
It helps you get into a cycle of this much time for development, this much time for docs, this much time for testing/qa, this much time for bug fixing, release. rinse and repeat.
you fit what you can do into the schedule instead of fitting the schedule to everything you want to do.
you might even do a build when following that type of schedule that is just bug fixes and nothing else, maybe another build are packages added to the engine (like rts starter kit, fps starter kit, rpg starter kit, etc)
I think at this point it would be nice to actually have a released version of T3D and although its admirable to want it to be "perfect"
you need to get it out as the community is drooling to get there hands on it and lets face it the community finds even more bugs then test (more eyes looking at it).
broken releases really don't have anything to do with how often(how frequently you release) its a process problem.
with the right process you could release every month.
just because you take 6months, a year, or whatever does not mean you wont have the same problems unless the process is fixed.
anyway Im sure T3D will rock and GG will get all the issues resolved
its just hard to wait for something you want so badly lol :)
#18
Several key function of T3D that I have designed projects around have been busted (or constantly changed without true improvement) in every T3D build so far.
I don not think we need nightly code drops; but weekly 'BUG FIX' drops would be exceptionally helpful.
05/19/2010 (10:58 am)
It is not the release speed of the new 'builds' that is annoying. It is the speed in what we receive 'KNOWN' bug fixes that is truly disappointing. Several key function of T3D that I have designed projects around have been busted (or constantly changed without true improvement) in every T3D build so far.
I don not think we need nightly code drops; but weekly 'BUG FIX' drops would be exceptionally helpful.
#19
Along with some stable releases of upcoming features so we can add to the testing effort, and then releases which our development should be done on plus bug fix releases if required.
05/19/2010 (8:41 pm)
I'm with Caylo, weekly bug fixes would be great.Along with some stable releases of upcoming features so we can add to the testing effort, and then releases which our development should be done on plus bug fix releases if required.
#20
In theory I agree, but I don't really consider beta drops "releases." My perspective is that there've only been 2 actual releases of a T3D version, which is to say original 1.0 and the current minor point release that's up.
Obviously no one has forced any of us to port to 1.1a, 1.1b1, or any other "testing" version, we do so knowing the risks. The same would apply even moreso to possible CVS versions: If you port your current project to a weekly CVS drop, you are actively engaging in risk. If you don't want to be bothered by these "buggy" releases then avoid them entirely. That was actually why I suggested that these types of in-between releases might be better labeled as "at your own risk," and I'd be inclined to say it would make more sense to just drop the engine code and skip all of the usual installer packaging.
I still think the new QA process is likely to be a net win for the users, but I think this kind of QA really doesn't need to go into each actual work-in-progress update we see. I would expect to wait for this kind of QA cycle to complete if we were talking about 1.1 final, or even 1.1RC1, but not for something which is theoretically labeled "1.1b2." I'm not saying wait until RC to start the internal QA process, but basically... B2 exists, it compiles and builds, and the QA team has this code. So why don't we? If a fix for 1 issue breaks another feature the internal testers never used, it's going to be quite some time before this new issue gets reported, solved, and released using this cycle.
I'd actually forgotten there used to be a CVS repository.
On an even more selfish note, I'd love to be filling in the code updates as they appear on some repository instead of absorbing them all at once. Most users probably don't care, but I make sure to run a full WinMerge compare on stock versions of every update to see what's really going on, since the internal changes aren't really documented anywhere. I expect the 1.1b1->1.1b2 changes to take longer than usual to absorb, and I'd have rather been slowly consuming these over the past couple months than all at once. So, if not actual regular "test" code drops, it would be great to have an archive of solved issues. I see threads that end with "fixed for next beta," but don't include the fix, and that can be a bit discouraging if you know the next beta might not exist for several months.
I think I'm ranting for the sake of ranting now.. and I was doing so well before.
05/20/2010 (12:52 pm)
Quote:I think the tradition of releasing broken release after broken release is something that really needs to be fixed, and if we have to wait longer between releases so be it, so long as they ARE polished.
In theory I agree, but I don't really consider beta drops "releases." My perspective is that there've only been 2 actual releases of a T3D version, which is to say original 1.0 and the current minor point release that's up.
Obviously no one has forced any of us to port to 1.1a, 1.1b1, or any other "testing" version, we do so knowing the risks. The same would apply even moreso to possible CVS versions: If you port your current project to a weekly CVS drop, you are actively engaging in risk. If you don't want to be bothered by these "buggy" releases then avoid them entirely. That was actually why I suggested that these types of in-between releases might be better labeled as "at your own risk," and I'd be inclined to say it would make more sense to just drop the engine code and skip all of the usual installer packaging.
I still think the new QA process is likely to be a net win for the users, but I think this kind of QA really doesn't need to go into each actual work-in-progress update we see. I would expect to wait for this kind of QA cycle to complete if we were talking about 1.1 final, or even 1.1RC1, but not for something which is theoretically labeled "1.1b2." I'm not saying wait until RC to start the internal QA process, but basically... B2 exists, it compiles and builds, and the QA team has this code. So why don't we? If a fix for 1 issue breaks another feature the internal testers never used, it's going to be quite some time before this new issue gets reported, solved, and released using this cycle.
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'd actually forgotten there used to be a CVS repository.
On an even more selfish note, I'd love to be filling in the code updates as they appear on some repository instead of absorbing them all at once. Most users probably don't care, but I make sure to run a full WinMerge compare on stock versions of every update to see what's really going on, since the internal changes aren't really documented anywhere. I expect the 1.1b1->1.1b2 changes to take longer than usual to absorb, and I'd have rather been slowly consuming these over the past couple months than all at once. So, if not actual regular "test" code drops, it would be great to have an archive of solved issues. I see threads that end with "fixed for next beta," but don't include the fix, and that can be a bit discouraging if you know the next beta might not exist for several months.
I think I'm ranting for the sake of ranting now.. and I was doing so well before.
Associate Steve Acaster
[YorkshireRifles.com]
When bug-goblins have fixed bugs? ;)
When the stars are right and the ocean gives up R'hley - R'lhey - R ... how the hell do you spell that?
I loved Seal Team, great old game. :)