Release Candidate for Torque3D

#41 @Brett: That is understandable. Just on the todo list is some optimization for it and I think it would be beneficial for that to make it into the release than after the release. It will be a major point of interest for many and a bit more optimization should help with that.

As a side note, I get better frames with AL with the shadows off from the sun than in BL (with a higher end video card, that is not the case with a lower end). Kind of nice to see that though and hoping something can be placed in the middle for AL.

--Josh

#42 @Brett, the only mention of you guys even considering some official effort on the linux direction brought tears to my eyes.

On the other side, the asymetry between Windows and OSX feels scary. Lighting, physics, dev times in general...

PhyX doesnt support OSX? didnt knew that, btw Then why was it the first option for physics support on T3D?

I think some comments on this thread pointing to underestimate the importance of OSX compatibility are immature. Successfull indie developers on this community have stated many times the relevance of Mac support in the income on indie companies.

#43 Do most people on Macs even have enough of a video card to run AL? You practically need a Mac Pro to even get any kind of real graphics on the Apple side. As much as it is nice to target Apple users that want to run a game natively, it is going to be practical for the most part to target BL and lower end casual games that direction.

#44 @Novack:

Quote:PhyX doesnt support OSX? didnt knew that, btw Then why was it the first option for physics support on T3D?

That's a good question. There are a few reasons. It's widely used, freely licensed, and Sickhead had already done some work with it previously. If I had my choice, we'd probably use Havok as it's by far the more popular choice in the industry. Havok is the same story though, no OSX support without a license and, I believe you have to do the port yourself. I don't know if they're working on OSX support or not. The ODE implementation that Josh Engebretson was working on could be polished / completed and it should be cross-platform, but it needs a bit more work to support everything we want to support.

I want to reiterate that we are not dropping our commitment to Mac deployment or development. While the demand for deployment is far higher than development, we plan to continue to support both. It's very likely that we'll see some minor feature or performance deltas between Mac and PC for a while yet. We'll talk about why when we're clear where we'll land with respect to things like Advanced Lighting, but there are things we just can't do (like fix Apple's OpenGL drivers).

This from Alex Scarborough (the most capable OSX / OpenGL expert any of us have ever met):

Quote:Not supporting Advanced Lighting is driven primarily by the technical limitations of OpenGL and the subsequent performance penalties Advanced Lighting suffered. Advanced Lighting performs best with single channel 32 bit floating point textures, and dual channel 16 bit integer textures. OpenGL lacks native support for either of these formats, forcing Advanced Lighting to use much less efficient four channel 32 bit floating point textures andfour channel 16 bit floating point textures. The latter is not a typo, due to various implementation oddities 16 bit integer textures in any form are not reliable in OpenGL. Using these less efficient texture formats has an extreme impact on Advanced Lighting's VRAM usage, pushing it as high as 100 MB for a "simple" scene. Add that to the VRAM used by OS X itself and to the VRAM required for your game assets, and it quickly exceeds the capacity of most GPUs Apple ships, including the 512 MB 9600M in my MacBook Pro.

Compounding these performance issues, we encountered a couple of bugs in Apple's OpenGL drivers which cost us a considerable amount of time to track down and workaround (we aren't the only ones suffering here), and there are still a few which we have not managed to track down yet. I believe with time and with Apple's assistance we might be able to work around or solve these issues, but that's a dependency we may not wish to place ahead of the product's release. Our time before 1.0 is likely better spent improving stability and performance for all users and ensuring that the Mac experience with Basic Lighting is as smooth and polished as possible.

#45 Novack: Because physx likely is the only option.
Aside from Newton, no physics solution officially supports apple and newton is license wise a trouble maker.

Also, PhysX is rumored to get precompiled support for OSX, question would be when and if it will happen for 10.5 (10.4 is near granted out of the game). NVIDIA already has full CUDA support on OSX, so it basically would be possible, I think its might be more a matter of "Apple does not want non-hardware drivers to be installed".

The portation definitely is doable as different companies have shown (including the regularily named Torque competitor Unity which uses PhysX for collision and physics, independent if Windows, OSX or iPhone).

Perhaps we get a GG built cross platform PhysX once enough licensees have joined the boat to make the $50k license an option.
After all it would open up the use of it on more than just Windows and there is much more than just windows thats supported by GG currently that can't use it.

#46 Well ive only been part of site a few months. I like the torque 3d engine so far but. Having to just go into the engine an learn completely everything on my own without any kind of docs but the ones i try to search on here is pathetic from a customer stand point. Its like sell a new game with no manual to know what does what or a manual for a car on how to run it an tweak or fix it. Basically you all really need to focus on docs even if in the end you make it have to be payable. I think as a customer making me have to go through community forums an searching resources to find fies or docs on how to do things bad as a company. It should be laid out right from the point of offical release and be ready for anyone to pick up an read an be able to code. Personnely I know that crysis tech an unreal engine and stuff is way advance an way more expensive then what your tryin to sell. But wether you try to sell a cheap car or a ferrai everythign should be there to work an should wok properly. So that being said I think i rather wait months of long beta tests an periods where all features get into the final release an bug free then pushing out a final release thats stable an half done then doin add ons wether paid or not.

I appreciate the hard work you all doing but in the end your all getting paid to do it. So please just do it right an i rather not have you guys rush something out because some users on forums want a final release now thats stable an bug free then you guys make add ons later. Why not just do it all at once even if it takes 6 more months to do. Wether you push a stable finaly build in 1month but if its missin say another 25% still you want to add whats the point? Were techincally still waitin then for a final build. Its like microsoft or ubisoft or any developer sayin ok we got this game half done its stable an we got msot features to work so users can play with tis til we get rest done what we that do if a game was 75% done release an you bought it an later on had to wait for the other 25%. If im goin to wait for the rest of the features to get in after final release i would rather just u wait an just make it all done at once. And after that it would really only be bug fixes an minor imprvemtns / featurs you might add.

I truly sorry if i said anything wrong or some peopel take my post as beign rude but it just the way i feel about a complete engine I didnt pay for a half fast engine to be done in 4-5months I paid to have full complete engine wether it takes 2-3 month or 2-3 yrs

#47

Quote:in the end your all getting paid to do it

We only get paid as long as we get enough sales to keep paying us. That's how running a business works =)

One of the things that we have to take into consideration when trying to decide when to stop adding features and to concentrate on getting out an official "1.0" is that having a "Beta" label on the product can actually hinder sales up to a point. Ideally, from a development standpoint, we'd just keep pushing out beta after beta until we had a perfect product but practically we have to balance our development investments versus our sales returns and try to find the sweet spot.

#48 @Brett, thanks for the insights, thats makes sense.

@Marc, that was interesting info as well.

#49 @Matt,

that makes sense, google removed the beta label from gmail, motivated for the need of confindence in the corporate sector, as they recently stated.

So if even the kings of the long term betas feel that pain, is obviously understandable that GG will.

The whole thing really, does not lie on the naming, but the meaning behind. If you guys are going to name it Ultra-Final-Customer-Ready Edition, but still treat it as a product that deserves polishing and feedback, then please go ahead.

As Brett stated, more customers for you (GG), also means an stronger community.

#50

Quote:Ideally, from a development standpoint, we'd just keep pushing out beta after beta until we had a perfect product but practically we have to balance our development investments versus our sales returns and try to find the sweet spot.

As long as that is done then too and not just "planned" ;)
With TGEA a similar approach was planned and many here know what happened.

TGEA and iTGB are two engines more than there should be in that sector. Both were basically released in a significantly undone state. TGEA because the whole rendering related core was completely replaced in the last beta, without any testing before release, and that although major problems were not even adressed like the considerably broken, half finished port of the TGE editor (yet fully advertised as GG sadly commonly does, you really should change that practice and advertise what you have) and iTGB because it just never was tested in a realscale realworld beta all


For that reason it would be great if there would be at least 2 further releases. One with the whole optimizations and the multiple times mentioned SSAO shader rework, the last beta and then an RC1 (can be beta 5 given we don't find any impacting bugs anymore). Please just don't repeat the TGEA error by messing with the core shaders, throwing it at us as RC1 and at worst as T3D 1.0
But I'm confident that the whole team has grown and learned their lessons from the past fiascos and am looking forward to the progress :)

PS: Is T3D in beta at all ^^
Doesn't the start of a beta mark the point of feature completness and start of intense bughunting and feature refinement? Alpha is commonly the phase of feature implementation.

#51 @Marc:

Quote:But I'm confident that the whole team has grown and learned their lessons from the past fiascos and am looking forward to the progress :)

Well, it's actually a *completely* different team working on this product. There's not a single person who worked on TSE / TGEA 1.0 working on Torque today, and we have about 6X the headcount working on Torque 3D as ever worked on TSE / TGEA. We're going to move fast and we're going to get a lot done.

Quote:PS: Is T3D in beta at all ^^
Doesn't the start of a beta mark the point of feature completness and start of intense bughunting and feature refinement? Alpha is commonly the phase of feature implementation.

Oh beta... Such an abused term these days. Did Google add any features to Gmail during it's beta period? Definitely. A lot. There are other examples that essentially redefine the way most people think of "beta" but Google is the most oft-cited and perhaps the worst offender. The traditional definition, the one still used in most games and products, is feature complete at beta, bug free and stable at RC. This latter model was built around products that people purchased in a box on store shelves or through the mail though. Digital distribution and apps as services have changed all that. The product will continue evolving in a live state perpetually, just as web apps and web games now do. I understand that a game engine must be stable and bug free to ship games with. We're mindful of that and that's what we're targeting for actual version releases.

#52 Good to hear :

from Brett :

Quote:I'm cheating a little bit because there's more coming with Basic that we haven't shown yet. There are shadows, and lots of lights, and it's very fast.

from Alex :

Quote:Our time before 1.0 is likely better spent improving stability and performance for all users and ensuring that the Mac experience with Basic Lighting is as smooth and polished as possible.

because Basic Lighting with shadows can work for me on OSX to start using it.

And Basic Lighting in early betas was already very fast.

So I can work and deliver projects for my clients (not wide audience) with Basic Lighting; that can permit to use and become knowledge with T3D from a simpler point of view, and then, get Advanced Lighting coming, 2 or 3 months later (not more).

Concerning PhysX, Havok, they both were used by Macromedia/Adobe with Director/Shockwave on the Mac side. So, the technology was ported. Was it done internally to Macromedia/Adobe or made with the help of NVidia/Havok/Intel, I don't know. And as was already told, Unity use PhysX on Windows, Mac and iPhone (and perhaps Wii, I don't know).

I keep hearing that bullet is a very good physic library that seems to be available for Windows, Mac and even ported to Wii.

Nicolas Buquet
www.buquet-net.com/cv/

#53 My 2 cents would be to lock features, make the next release RC1 with a 1.0 release soon after. I agree with Brett, regarding his definition of "Done". In product development "Done" is a very subjective term. In most cases "Done" generally means that the product has enough quality and features to do what it was intended to do well. Done never means it's finished. This is a very complex balancing act but I feel like T3D is probably there.

The other interesting aspect to releasing a product is the perception factor. If you release to early the perception is that the product isn't finished. If you take too long the momentum and excitement around your product starts to die off and the final release comes with a lot of skepticism. Right now T3D has a ton of momentum and excitement behind it and it's pretty much there in terms of features and stability compared to other products like it on the market. In fact, I would argue that the beta already supersedes many released engines that are on their second or third version. In any case, if T3D starts to go into beta 7,8,etc the momentum behind the product will decrease and you run the risk of a release that falls short of expectations.

So 4 to 6 weeks for a release 1.0 sounds about right to me. Any missing features can be rolled into the next release. Having run several projects using SCRUM, I found this generally easy to do without upsetting the integrity of the development process.

Brett mentioned the possibility of sharing the roadmap with us, which I think is great. My thinking is that the road map could have future versions with anticipated features in each version. As things change this roadmap could be updated. If this is done, I'm hesitant to necessarily want to see timelines for feature releases in there. I think just having a road map with features that are planned for each release is plenty. No matter what you do or how clear you say timelines are subject to change, the forums will still be full of people asking why feature X hasn't been released yet. Personally, I find these posts somewhat annoying. Just my 2 cents though.

In terms of features I really care about for the engine for release 1.0

1. Solid documentation with tutorials. Again, just my personal opinion, but it would be nice to kill, once and for all, the perception that Torque products are hard to use and don't have good docs. This was my perception originally, however, that has changed. I think solid docs and some good tutorials will go a long way in improving this perception for others. As a BETA owner I can say the engine is 10x easier to use and the documentation looks promising. However, it's all about the first impressions of potential buyers.

2. Improved particle editor

Wishful thinking features:

1. Buy Jeff and Make AFX part of the core engine already!!!! Gosh! :)

I am super excited about the progress being made with the engine. T3D opens the doors of game development to people that wouldn't normally have an opportunity to be involved. Thank you!

#54 PhysX is quite easy to use under Linux (hint..hint). There was some talk at some point about ODE getting Physx card support which would also include recent Nvidia graphics cards, but I'm not sure if that was rumor or simply became too difficult. I've also heard that Bullet is pretty good but I've not used it myself. The only thing I can really say is avoid Newton.

@Brett: When you say the forward shading implementation is "very fast" is that while rendering a complex scene of many materials and objects, and is that compared to the hybrid shading implementation being slower then it? Typically when forward shading is rendering simple scenes it is easily hundreds of times faster then deferred shading doing the same scene, but as the complexity increases, forward shading usually peaks and becomes impossible to maintain a real-time framerate while deferred shading typically remains at the same framerate it started at regardless of complexity as long as the pipeline is efficient at material switches.

#55 Bryan,
The forward shading implementation is a 4-light per-pass SM2.0 solution right now. Forward shading is great if all you need is forward shading, however, like you mentioned, it scales poorly with complexity. This is why most AAA game engines (Torque included) have switched to a hybrid rendering solution. In fact there'll be at least 2 talks at SIGGRAPH on the same rendering methodology Torque uses. It has it's nay-sayers, but those nay-sayers haven't tried shipping cross-platform console games ;) It is very telling that Crytek did 2 generations of forward rendering and then up-and-switched to a pre-pass hybrid. I was very pleased this year at GDC when everyone else announced they were using pre-pass lighting :)

-Pat

#56 A few things i can address:

Quote:1) No light leaks to other rooms/zones, please!

There is some technical stuff we want to fix... like lights from non-adjacent rooms. We feel that fixing the lights to only flow thru portals would help there.

Better shadows also helps... the "single pass" dual paraboloid shadow always leaks by design and that cannot be fixed in DX9. But its crazy fast. The regular dual paraboloid does not leak, but is 2x the cost and has been buggy... something we're addressing for the next release.

In the end when we get these issues addressed... light will leak if your sloppy, but not if you use the tools you have correctly.

Quote:3) SSAO improvements.

James and i did more work on this yesterday... we almost have it working really well. It will be in a future update before the 1.0 release.

Quote:PhyX doesnt support OSX? didnt knew that, btw Then why was it the first option for physics support on T3D?

Because we implemeted with a library we had already written a bunch of TGEA code for. Physics support was not really an official bullet point, but one that happened thru our work on the Pacific demo (which you'll add see again soon).

I hope that in 1.1 or 1.2 we can add another one or two physics solutions (Havok, Bullet, ODE, Newton, etc) as plugins to give people more options.

#57 Ya know, if I may make a suggestion, something I think may work rather nicely until release (maybe even after? *shrug*) is that if you were to want to consider a feature clamp while you iron out lots of bugs, what about maybe establishing a sturdy, but efficient way of integrating community-made features?

There's always quite a few resources out there that I'm sure a lot of people end up doing over and over again which gets awfully frustrating. What I was thinking is what if you did something like say, have a detailed form for someone to fill out and submit a fully working feature in the form of the standard resource, and if it is in fact highly usable and desirable, toss it into the base code? This way a lot of the simple features that would be nice but would take time to do yourselves, and would just be a pain for everyone to do at once, you basically have people volunteer their work into it. Which also has bug benefits because that way on release the engine will already have these features and people can code around the already present things, rather than writing their own stuff, trying to add the resource, having all sorts of trouble, etc.

My water effect would be a good example. Hopefully I get around to finishing my work with that, but having that as an extra water feature and just toss that in. As much demand as I've gotten about it, both publicly and in private, I have a feeling a lot of people would be using it. However if you change too much, adding it as a resource may be troublesome later. If the engine came with it though, it would save you that trouble. *shrug* Just a thought.

#58 Here’s my take on the original question:
1) I agree with Jason Guzzardo’s post regarding the market timing as related to market share/sales/cashflow maximization. I would add that moving revenue into 2009 will be more advantageous than 2010 given what is likely to happen with Federal Tax Rates.

2) The December Relocation creates a clear deadline. Since a clear disruption in product support and business capacity is certain during this time, the controlling factor is planning the product launch in anticipation of this event. Clearly, relocation of systems, files, and talent will create confusion and introduce inefficiencies into every business process. Furthermore, as the talent at GG reorients themselves to a new location (families, schools, housing, doctors, etc.) while digesting the normal Holiday stress you must anticipate a sever reduction in productivity. With this in mind you must consider where you want this launch cycle at that time.

I would think you need a 1.0 release no later than Mid-September, which will allow you five to six weeks of efficient operations prior to the beginning of the Thanksgiving Holiday.

Since I am just a Business guy who is having fun trying to learn this game-making thing, I really can’t add to the feature quality argument, but the release must deliver on expectations and enhance the reputation and brand value of GG above all other considerations, but if you are not there by Early September I think you will find yourself pushed into 1st Qtr. 2010!

Hope this helps in some small way.

#59 wow so I should clarify my meaning since I originally asked the question.

Couple quick comments. The whole concept of there will always be bugs is true but there is a point where major features are done and all showstopper bugs are fixed.

This is one level of "done", next is pounding out the worst bugs, documentation, etc. But at this point you essentially have a "completed product" that you can run off and make games worth and it essentially works and functions well enough when it comes to the main features of the engine.

above and beyond that, your all right, it could go on for years hammering away on bugs trying to get to something like zero bugs (lol).

but for those of us dishing out the now much fatter cash(yes its still an awesome price so lets not argue about it) to license the engine I dont have arbitrary time to wait. I need something a little more professional then it will be done whenever.

Even with bugs a development team shoots for and tries to follow some sort of timeline. This sets expectations. You shouldn't blow off the concept of when your going to try and get it done with the excuse of you don't know because you don't know when all the bugs will be fixed.

That type of attitude is why game studios go under and fail miserably.

Set a timeline/milestones/scrumms whatever and then work hard to achieve it.

Your selling a product for money and profit, its only normal for the purchasers to ask "when is it going to be done?".

To me beta 4 is not ready for prime time, when can I expect it to be there?

This isn't just a game that some players are waiting to play, its a technology that will be used to create games and it needs to be reasonably sound and ready for prime time as it really sucks to start developing on technology that keeps changing all the time. Those of you that have been there know what Im talking about.

minor bug fixes and minor feature improvements aside, thats fine and manageable.

Essentially all I was asking is have you given yourselfs a general timeframe on when you would like Torque3D to be a "released" product?

Its a touchie questions obviously because if you tell me 2 more years then Ill go use tgea or something and not wait or spend anymore money on this new version. You tell me 4 months, then cool, can't wait to get there.

No reason to be wishy washy about it, put some reasonable time frame out there and run with it.

#60 I would just like to comment about BUGS.

Quote:
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program that produces an incorrect or unexpected result. Most bugs arise from mistakes and errors made by people in either a program's source code or its design.

While I agree to say a program is 'bug free' is dumb, I believe IT IS
possible to state 'No known bugs' or be able to say any known bugs are
not a direct result of the program's code (see below about 3rd party)

Any programmer that can say he or she is happy to release their software
with known bugs IMHO is not a professional programmer.
And simply stating there no such thing as a bug free program to defend
their inability to create well written software is in itself laughable.

The above does not take into account 3rd party software / drivers / hardware
that the original program relys upon, and the programmer has no influence on.

/rant off

The above rant IS NOT directed at GG, but a general observation of todays
'It will do' mentality of mediocrity.