When will this be stable??
by David R. Green · in Torque Game Engine · 12/22/2001 (2:32 am) · 17 replies
Hi GG and Torque-ees,
This is a serious message and in no way is meant to be a flame or start a war...
I have been a licensee since the summer -- when can we expect to see something that properly works and is relatively bug-free?
I don't mean to sound rude, but the "feature list" etc. on the site is misleading and misrepresents the current state of this engine -- both now and back at summer-time. Of course would-be licensees don't usually find this out until...
After purchasing the license I was discouraged to find out that listed features are not present, not working, buggy, etc.
I stopped working on fixing code and creating utilities, since the updates by the GG staff et al keep breaking old code, and trying to get the community to agree on what direction many things will go is like trying to herd cats.
I (and my small team) have gone back to working on the in-house engine here. I'm also seriously considering simply moving the game ideas back onto the back-burner that I had targetted Torque for, probably until I locate a different engine or things expand into doing it all in-house.
Any thoughts on this GG? Next year? 2003?
No offense meant by this, I'm only asking.
Thanks,
David "tired of re-coding" Green
This is a serious message and in no way is meant to be a flame or start a war...
I have been a licensee since the summer -- when can we expect to see something that properly works and is relatively bug-free?
I don't mean to sound rude, but the "feature list" etc. on the site is misleading and misrepresents the current state of this engine -- both now and back at summer-time. Of course would-be licensees don't usually find this out until...
After purchasing the license I was discouraged to find out that listed features are not present, not working, buggy, etc.
I stopped working on fixing code and creating utilities, since the updates by the GG staff et al keep breaking old code, and trying to get the community to agree on what direction many things will go is like trying to herd cats.
I (and my small team) have gone back to working on the in-house engine here. I'm also seriously considering simply moving the game ideas back onto the back-burner that I had targetted Torque for, probably until I locate a different engine or things expand into doing it all in-house.
Any thoughts on this GG? Next year? 2003?
No offense meant by this, I'm only asking.
Thanks,
David "tired of re-coding" Green
#2
A development Road Map would be great. The change log descriptions being more descriptive will help with chasing down breaks, but with a road map for dev teams could actually make more informed decisions about resource allocation.
We've begun using Bugzilla for our tracking and have found it, in our limited use, to be reasonably full featured and slick.
I'm actually surprised by how stable the Engine is, particularly on our Macs. My code guys have nothing but enthusiasm for the overwhelming majority of the engine - some grumbling about how far flung the physics components are - and it's organization. Some of our team members are decomp'ing the source (for functionality), and we hope to release this information to the community as soon as it's complete.
But yeah yeah yeah - road map, bug tracking, and documentation. ;]
12/22/2001 (1:03 pm)
An issue that is causing me and my team some grief is the limited support for Mac development, of course this was bound to be the case but we were surprised to find that 3ds Max is basically the only way to get AAA-class models and ani's into your game. Milkshape is a limited option, but is also PC only. Academic pricing on Maya isn't attrocious (certainly no worse than Retail Max), and Blender (free, licensing caveat emptor not withstanding) is available for all the platforms the SDK supports, it'd be great to see some headway in this area, or to see some mention of the express need (at this time) for a PC to produce models for your Mac or 'nix SDK.A development Road Map would be great. The change log descriptions being more descriptive will help with chasing down breaks, but with a road map for dev teams could actually make more informed decisions about resource allocation.
We've begun using Bugzilla for our tracking and have found it, in our limited use, to be reasonably full featured and slick.
I'm actually surprised by how stable the Engine is, particularly on our Macs. My code guys have nothing but enthusiasm for the overwhelming majority of the engine - some grumbling about how far flung the physics components are - and it's organization. Some of our team members are decomp'ing the source (for functionality), and we hope to release this information to the community as soon as it's complete.
But yeah yeah yeah - road map, bug tracking, and documentation. ;]
#3
Thanks for your reply and insights.
I hope that you and no one reading this thread are offended or angered by my post, I am in no way meaning this as a slam on GG. I have been a multi-language multi-platform programmer for over two decades now (I started young), and I know what it takes to write this much code.
I wish I could give some constructive comments on how you could implement a more successful method of keeping all aspects of the development together and operating smoother.
Having programmed with teams both local (everyone in the same place) and remote, I realize the difficulties in keeping the community moving in the same direction.
Personally, I feel I'm getting too old to handle the "remote" method of working with team programmers.
:-)
I shelved our current Torque-based game, with much of the models and some of the maps, textures, and scripting completed.
I feel it best for us to just wait for the time being until Torque is at a level that I feel comfortable with, then freeze your code at that point, with only in-house mods and fixes from there.
The other engine we are working on here is for a totally different genre of game than Torque, and in many ways is easier to develop, so that is where we are headed at this time.
When it is farther along, we'll see about maybe having GG distribute it for us.
Once that project is completed, I'll look at dusting off our Torque coding again.
Don't fret though, I'll still be around here to hassle everyone. :-)
Thanks,
David
12/22/2001 (2:33 pm)
Hi Tim,Thanks for your reply and insights.
I hope that you and no one reading this thread are offended or angered by my post, I am in no way meaning this as a slam on GG. I have been a multi-language multi-platform programmer for over two decades now (I started young), and I know what it takes to write this much code.
I wish I could give some constructive comments on how you could implement a more successful method of keeping all aspects of the development together and operating smoother.
Having programmed with teams both local (everyone in the same place) and remote, I realize the difficulties in keeping the community moving in the same direction.
Personally, I feel I'm getting too old to handle the "remote" method of working with team programmers.
:-)
I shelved our current Torque-based game, with much of the models and some of the maps, textures, and scripting completed.
I feel it best for us to just wait for the time being until Torque is at a level that I feel comfortable with, then freeze your code at that point, with only in-house mods and fixes from there.
The other engine we are working on here is for a totally different genre of game than Torque, and in many ways is easier to develop, so that is where we are headed at this time.
When it is farther along, we'll see about maybe having GG distribute it for us.
Once that project is completed, I'll look at dusting off our Torque coding again.
Don't fret though, I'll still be around here to hassle everyone. :-)
Thanks,
David
#4
Maybe you can implement bugzilla too
Well, hope to see a nice bugtracker soon :)
Regards
12/22/2001 (5:13 pm)
Tim, about the bug tracker... that would be really cool, maybe something similar to gnome's bug tracking system (http://bugzilla.gnome.org/query.cgi) ... it really rocks!! ... no kidding...Maybe you can implement bugzilla too
Well, hope to see a nice bugtracker soon :)
Regards
#5
12/22/2001 (5:38 pm)
We are using Mantis (http://mantisbt.sourceforge.net/) for our bug reporting on our game. We looked at many different Bug tracking packages and a lot of them are bloatwear. Another good package is phpBugTracker (http://phpbt.sourceforge.net/). I found Bugzilla to be too complex for what we are doing. Anyways just a heads up :)
#6
We create our game as a mod, so we do not get much problems.
At this time, our game won't work without 'fps'.
At the end, we will merge our game directly into 'fps', but at the moment, we avoid all changes we do not need.
(e.g. We did not add our mod to the list. We have to start with 'torque.exe -mod carrier').
We also just write modified functions into our files, so the others can be updated.
When we update Torque, we have a look at the modified files and merge the changes manually, which is easy to do.
Of course, you cannot do this with the source code, it's much too big (Hope you can say it in this way in english, plz correct me).
But with developing our game as a mod, we also have our files and models set apart from 'fps'.
greetings
Daniel
12/23/2001 (1:59 am)
Merging of Torque and your project:We create our game as a mod, so we do not get much problems.
At this time, our game won't work without 'fps'.
At the end, we will merge our game directly into 'fps', but at the moment, we avoid all changes we do not need.
(e.g. We did not add our mod to the list. We have to start with 'torque.exe -mod carrier').
We also just write modified functions into our files, so the others can be updated.
When we update Torque, we have a look at the modified files and merge the changes manually, which is easy to do.
Of course, you cannot do this with the source code, it's much too big (Hope you can say it in this way in english, plz correct me).
But with developing our game as a mod, we also have our files and models set apart from 'fps'.
greetings
Daniel
#7
12/23/2001 (10:31 am)
Thanks for the bug tracking leads, I'll check them out... Right now were planning our own though, as we want a bug tracking system that will integrate with the GG projects. This will eventually roll into the "gamers" site, where we'd like every published GG game to have bug tracking on it.
#8
In regards to a bug tracking system:
"Rolling your own" bug tracking system would be the investment of time that we all have little enough of. Based on posts that I've been reading since I became a GG member a few weeks ago, I get the impression that the community could benefit from this type of system sooner, rather than later.
One of the reasons that many of us purchased the Torque engine was to save the time and effort of creating our own game engine from scratch. Wouldn't it make sense to use that same logic, and utilize an existing bug tracking system.
Benefits:
1) Immediate system for the GG community to benefit from.
2) Very little effort on behalf of the GG employees to deploy.
3) Members who have not utilized a bug tracking system will be able to realize the benefits of such a tool.
Cons: (with my own comments)
1) Lack of pride that "I" didn't create it...
(I personally will get over it as I'm using a game engine that I didn't create.)
2) It won't be customized for the Torque engine.
(A bug is a bug is a bug)
3) Implementing a bug tracking system for every published GG title to use would benefit from a customized, hand written bug tracking tool.
(Fine, create a customized bug tracking tool when it happens, until then, let's have something.)
(Side note, hogwash... you could probably take an existing bug tracking tool and modify it for this purpose, again saving time...)
I'm sure there are people on both sides of the fence, it is just my opinion that somethings gets deployed. I'd rather the GG community keeps investing their efforts on improving the Torque game engine. Leave the effort of creating, and bug fixing a bug tracking tool to someone who has already done it.
Regards
12/26/2001 (9:28 am)
Just my $.02. Disclaimer, please don't take offense, unless you feel the need.In regards to a bug tracking system:
"Rolling your own" bug tracking system would be the investment of time that we all have little enough of. Based on posts that I've been reading since I became a GG member a few weeks ago, I get the impression that the community could benefit from this type of system sooner, rather than later.
One of the reasons that many of us purchased the Torque engine was to save the time and effort of creating our own game engine from scratch. Wouldn't it make sense to use that same logic, and utilize an existing bug tracking system.
Benefits:
1) Immediate system for the GG community to benefit from.
2) Very little effort on behalf of the GG employees to deploy.
3) Members who have not utilized a bug tracking system will be able to realize the benefits of such a tool.
Cons: (with my own comments)
1) Lack of pride that "I" didn't create it...
(I personally will get over it as I'm using a game engine that I didn't create.)
2) It won't be customized for the Torque engine.
(A bug is a bug is a bug)
3) Implementing a bug tracking system for every published GG title to use would benefit from a customized, hand written bug tracking tool.
(Fine, create a customized bug tracking tool when it happens, until then, let's have something.)
(Side note, hogwash... you could probably take an existing bug tracking tool and modify it for this purpose, again saving time...)
I'm sure there are people on both sides of the fence, it is just my opinion that somethings gets deployed. I'd rather the GG community keeps investing their efforts on improving the Torque game engine. Leave the effort of creating, and bug fixing a bug tracking tool to someone who has already done it.
Regards
#9
Of course, community participation is a key ingredient to the success of Torque as well as communication. For those of us who have licensed Torque and are putting all of our time into building a game around it - we have a vested interest in the success of Torque as a product and Garage Games as a company.
Community participation can take the form of engine enhancements, stability improvements, documentation, web site development (if GG needs help there), and probably a few other key areas. Everyone tends to lean towards engine enhancements first because undoubtedly they are excited about how easy it is to implement new features. Our team is experiencing that same euphoria as we get started with development this phase.
I am guessing, however, that the euphoria starts to wear off soon and the bulk of developers and artists in this community will start creating the other important assets for Torque like documentation. Our team is excited to contribute to the core Torque product but are still "getting our legs" in the engine, per say, and are nervous about implementation, etc. My hope is that by the end of Phase 2 for Myrmidon, we will have some valuable assets to contribute to the Torque engine that are well implemented and tested.
For 21-6, I can say that it is truly exciting for us to be part of the evolution of Garage Games. Their vision is something which we believe in strongly and hope to continue supporting throughout the development of Myrmidon.
Justin Mette
21-6 Productions
12/26/2001 (10:53 am)
David - I think it's great that you brought these subjects up. These are tough issues that face GG and the community in making Torque a success and they need to be discussed. Some of the ideas Tim mentions like the Road Map are particularly interesting and will help facilitate communication about the evolving engine and overall GG vision (docs, publishing site, etc). Of course, community participation is a key ingredient to the success of Torque as well as communication. For those of us who have licensed Torque and are putting all of our time into building a game around it - we have a vested interest in the success of Torque as a product and Garage Games as a company.
Community participation can take the form of engine enhancements, stability improvements, documentation, web site development (if GG needs help there), and probably a few other key areas. Everyone tends to lean towards engine enhancements first because undoubtedly they are excited about how easy it is to implement new features. Our team is experiencing that same euphoria as we get started with development this phase.
I am guessing, however, that the euphoria starts to wear off soon and the bulk of developers and artists in this community will start creating the other important assets for Torque like documentation. Our team is excited to contribute to the core Torque product but are still "getting our legs" in the engine, per say, and are nervous about implementation, etc. My hope is that by the end of Phase 2 for Myrmidon, we will have some valuable assets to contribute to the Torque engine that are well implemented and tested.
For 21-6, I can say that it is truly exciting for us to be part of the evolution of Garage Games. Their vision is something which we believe in strongly and hope to continue supporting throughout the development of Myrmidon.
Justin Mette
21-6 Productions
#10
xx: fixed wheeled vehicle code - vehicle.cc, vehicle.h, wheeledvehicle.cc, wheeledvehicle.h.
This way I could take those new files and take my older files and do a Windiff on them and add the changes to my old files and not lose any of my custom code for my project.
-Tim aka Spock
12/26/2001 (1:24 pm)
I would like a list of the files changed on each change in the changelog. (hope that makes sense) This way lets say you fix the collision bug with the wheeled vehicles, Id like to look at the change log and see.xx: fixed wheeled vehicle code - vehicle.cc, vehicle.h, wheeledvehicle.cc, wheeledvehicle.h.
This way I could take those new files and take my older files and do a Windiff on them and add the changes to my old files and not lose any of my custom code for my project.
-Tim aka Spock
#11
12/28/2001 (9:04 am)
Tim, we plan on extracting that information from the CVS logs. There's a perl script that will filter the CVS log and produce a HTML changelog (with affected files). If I can get that going, it will be much nicer than doing it manually.
#12
I own a software company (in my RL) that produces products used for in banking / home finance. I have customers in every state, and have thousands and thousands of users. Data center, help desk, blah, blah blah....Basically I understand how software gets made.
Here are a few things I learned about how software gets made and released:
1. Software will never be bug-free. Ever. There are dozens of reasons why.
2. You will never be able to give your users all the features they request.
3. Some of the ideas you love will not make it into release due to about a zillion reasons.
4. A very small percentage of your user base will have problems you will spend a large percentage of your time trying to fix.
5. A large percentage of your user base will have problems that have nothing at all to do with you. You will spend time and money solving other people's problems.
6. You will be criticized for problems you did not cause, create, or control.
7. Somebody else will think up something really cool before you do. Sometimes you will get to add it to your product, sometimes not.
8. Features you think are cool will be ignored. Features you care little for will make most of the difference. It's impossible to tell them apart before release.
9. You cannot be objective about the program you have created. Listening to outside opinions should be as important as backing up your work.
10. Finally, always backup your work. Make backups of your backups. Then test to make sure your backups are good, before you need them.
Last and possibly most important:
11. You will be forced to make sacrifces to meet release dates.
I'm probably wrong about most of this, but it works for me.
In the meantime, I think the GG staff has performed miracles on a very limited budget.
The more I learn about the code, the more respect I have for the team that wrote it.
12/29/2001 (8:37 am)
Let me add my .02 cents to this also. I own a software company (in my RL) that produces products used for in banking / home finance. I have customers in every state, and have thousands and thousands of users. Data center, help desk, blah, blah blah....Basically I understand how software gets made.
Here are a few things I learned about how software gets made and released:
1. Software will never be bug-free. Ever. There are dozens of reasons why.
2. You will never be able to give your users all the features they request.
3. Some of the ideas you love will not make it into release due to about a zillion reasons.
4. A very small percentage of your user base will have problems you will spend a large percentage of your time trying to fix.
5. A large percentage of your user base will have problems that have nothing at all to do with you. You will spend time and money solving other people's problems.
6. You will be criticized for problems you did not cause, create, or control.
7. Somebody else will think up something really cool before you do. Sometimes you will get to add it to your product, sometimes not.
8. Features you think are cool will be ignored. Features you care little for will make most of the difference. It's impossible to tell them apart before release.
9. You cannot be objective about the program you have created. Listening to outside opinions should be as important as backing up your work.
10. Finally, always backup your work. Make backups of your backups. Then test to make sure your backups are good, before you need them.
Last and possibly most important:
11. You will be forced to make sacrifces to meet release dates.
I'm probably wrong about most of this, but it works for me.
In the meantime, I think the GG staff has performed miracles on a very limited budget.
The more I learn about the code, the more respect I have for the team that wrote it.
#13
the post before your's is dated:
Posted: Dec 29, 2001 08:37 PST
06/16/2004 (12:21 pm)
Rofl dave..the post before your's is dated:
Posted: Dec 29, 2001 08:37 PST
#14
I personally think that the road map idea is great. So we can see whats going on and what is not.
Bug Tracking on the other hand is not a good idea in my opinion. Here is a list of reasons:
1. Most posted bugs are usually someone not using it correctly.
2. Most bugs in the list are duplicates but they are described in different ways.
3. Most bugs are not closed in the tracking system, partly due to duplicate bug listing and partly due to unreproducable bugs and an inablility to get in touch with the person that listed it.
4. People will use it to ask for features.
5. It takes a lot of resources to manage a bug tracking system or you end up with millions of unresolved bugs listed and that just give a false impression.
The way things work now, I personally think is the best approach. People list the bug in the forum and other people explain what is being done wrong. If its a serious bug then people will keep listing it till its resolved.
The linux kernel works that way and it works great. Bugs just keep floating back up until they are resolved. Its pretty much a pear review of all bugs listed. The community gets a chance at it before the people at GG have to worry about it.
Ben
06/17/2004 (7:07 am)
Hello, I personally think that the road map idea is great. So we can see whats going on and what is not.
Bug Tracking on the other hand is not a good idea in my opinion. Here is a list of reasons:
1. Most posted bugs are usually someone not using it correctly.
2. Most bugs in the list are duplicates but they are described in different ways.
3. Most bugs are not closed in the tracking system, partly due to duplicate bug listing and partly due to unreproducable bugs and an inablility to get in touch with the person that listed it.
4. People will use it to ask for features.
5. It takes a lot of resources to manage a bug tracking system or you end up with millions of unresolved bugs listed and that just give a false impression.
The way things work now, I personally think is the best approach. People list the bug in the forum and other people explain what is being done wrong. If its a serious bug then people will keep listing it till its resolved.
The linux kernel works that way and it works great. Bugs just keep floating back up until they are resolved. Its pretty much a pear review of all bugs listed. The community gets a chance at it before the people at GG have to worry about it.
Ben
#15
As a matter of fact, the linux kernel does use a bug tracker. Take a look at http://bugzilla.kernel.org/
Furthermore, since this dicussion, a Torque bugtracker has been added as well. You can find that at http://www.garagegames.com/projectmanager/module.php?qpj=4
06/17/2004 (7:46 am)
@BenAs a matter of fact, the linux kernel does use a bug tracker. Take a look at http://bugzilla.kernel.org/
Furthermore, since this dicussion, a Torque bugtracker has been added as well. You can find that at http://www.garagegames.com/projectmanager/module.php?qpj=4
#16
Edited on Dec 29, 2001 09:38 MST
06/17/2004 (8:08 am)
Ah, but Badguy... this thread is not as outdated as you think...Edited on Dec 29, 2001 09:38 MST
#17
Some people do use it, but its continually stated by Linus that he does not. Linus uses only the mailing list for his bug tracking. I don't have a link handly to his last message about it but he has been in direct oposition to it for as long as I have been on the mailing list.
Ben
06/17/2004 (8:56 am)
Hello Mark. Some people do use it, but its continually stated by Linus that he does not. Linus uses only the mailing list for his bug tracking. I don't have a link handly to his last message about it but he has been in direct oposition to it for as long as I have been on the mailing list.
Ben
Torque Owner Tim Gift
On the updates breaking old code... Obviously we want to continue to improve and/or fix the engine. This will inevitably cause problems with developers merging with the latest rev and I'm not sure what the solution to this is... I think our changelog comments need to be more descriptive, that may help. We also need to put together a "road map", so developers at least know what we're working on. Otherwise, I'm open to ideas...
On the stability... since the engine was used to ship two successful commercial products you could argue that it's pretty stable right now :) Those products though, only tested a fairly narrow set of functionality in the engine, and as we try to do new things with it, we're bound to run into problems. I think there are two solutions here: the first is that we need a bug tracking system! Posting bugs in the forums doesn't quite cut it. We need a clear way of submitting, prioritizing, and tracking the status of problems and knowing that they are being resolved. The second of course, is documentation. I've seen many forums "bugs" turn out to be a miss-understanding on how a feature is supposed to work. When something is used incorrectly, and it doesn't work, that's not a "bug". Though without documentation, it's hard to know how to use some things :) Good documentation is very time-consuming to write though. At some point we'll have to knuckle down at dedicate a fair amount of time to it as this "document as we go" does not seem to be working very well.
So, as far as a date on when the engine will be ready? Personally I think it's ready now. I don't know of any engine that doesn't have problems, and no engine is going to do exactly what you want (even the one you write yourself). I've never started on a game with an engine as complete as this one before, so I have to say this is a pretty good starting point. Having said that, I in no way believe this engine is perfect :) It definitely needs work. Hopefully we'll continue to get constructive feedback and address what I think is the main problem: communication (in the form of bug tracking, roadmap, and documentation).