New TGE Branch (2.0?)
by Prairie Games · in Torque Game Engine · 03/02/2003 (10:45 am) · 74 replies
Isn't it about time to branch the TGE code? perhaps towards TGE 2.0?
It would be great to address some of the more fused architecture... *cough* 138k player.cc *cough* without the worries of breaking current games in production.
Torque would really benefit from better interfaces and code seperation... obviously, this is a pretty large task, a branch would at least allow it to be *started*...
-Joshua Ritter
ActionRPG Revolutionary
It would be great to address some of the more fused architecture... *cough* 138k player.cc *cough* without the worries of breaking current games in production.
Torque would really benefit from better interfaces and code seperation... obviously, this is a pretty large task, a branch would at least allow it to be *started*...
-Joshua Ritter
ActionRPG Revolutionary
#2
-brad
03/02/2003 (2:00 pm)
it seems to me that HEAD has turned into the main path, instead of being experimental or dev.-brad
#3
Another fork would essentially divide us into two parties. "I have a solution for your problem - oh wait, you're not on my branch" ...
I dunno. Maybe I'm exaggerating here. I just don't see how a branch would help us.
03/03/2003 (4:14 am)
I personally stick with HEAD too, as the release versions are too boring for me. Is there such a thing as the "right" way? I don't have any problem keeping up with the latest HEAD, and my branch is blown up with all the modifications you can think of (Melv's stuff, day/night with fixed interior lighting, turrets, guided missiles, bots with pathfinding, etc.)Another fork would essentially divide us into two parties. "I have a solution for your problem - oh wait, you're not on my branch" ...
I dunno. Maybe I'm exaggerating here. I just don't see how a branch would help us.
#4
Branching is standard development procedure... the stable branch is for current development.. and the development branch is for, well, development... in this case there never really is a merge except for perhaps bug fixes that cross branches...
-J
03/03/2003 (4:28 am)
Development needs to continue and not be held back by decisions influenced by Tribes2 requirements/deadlines or wholesale compatibility with 1.1.2Branching is standard development procedure... the stable branch is for current development.. and the development branch is for, well, development... in this case there never really is a merge except for perhaps bug fixes that cross branches...
-J
#5
03/03/2003 (5:11 am)
I concur. Branch a 'stable 1.0/1.2' that's just for critical fixes and encourage more contributions to the head branch.
#6
One thing I was thinking of, would be to move to a semi linux kernel style of model, with a "development" tree and a "stable" tree. Stuff that has proven its worth in the development tree periodically gets merged over to the stable tree. Semi-experimental code and community contributed resources could be checked in to the development tree.
More people would have write access to the development tree, and patches to it would not need to go through GG staff. Maybe 5 or so additional write-access enabled people to start with.
Care would need to be taken to make sure the dev tree doesn't become a free for all, and that it isn't substantially broken. The people with write access would need to filter out bad patches as well. Bad code should just get rejected. They could also recommend additional people for write access, and ask for write access to be revoked in case someone starts abusing it.
Just some ideas.
03/03/2003 (2:12 pm)
I also have been thinking about this for a while. Fact is, the head seems to have become "stable" by default. One thing I was thinking of, would be to move to a semi linux kernel style of model, with a "development" tree and a "stable" tree. Stuff that has proven its worth in the development tree periodically gets merged over to the stable tree. Semi-experimental code and community contributed resources could be checked in to the development tree.
More people would have write access to the development tree, and patches to it would not need to go through GG staff. Maybe 5 or so additional write-access enabled people to start with.
Care would need to be taken to make sure the dev tree doesn't become a free for all, and that it isn't substantially broken. The people with write access would need to filter out bad patches as well. Bad code should just get rejected. They could also recommend additional people for write access, and ask for write access to be revoked in case someone starts abusing it.
Just some ideas.
#7
I suggest it should work in development cycles and be limited to a 'who's in development this cycle' checkin basis. At the start of the cycle, all participants check out and start doing their changes, preferably with as much cooperation as possible so they don't step on each other. Midway in the cycle, emphasis changes from developing new code to making sure what's all there works and sorting out who fixes what. At the end of the cycle, changes are merged over to head and a new checkpoint is created.
Then you make a new list of people who are signed up for changes for the development branch, and start a new cycle so they can start doing their changes...
If the development branch isn't stabilized periodically, it might never become stable, and therefore never go to head.
The stable branch still should get bug fixes, and minor changes that don't require development shakedown, but that's what it's getting already.
03/03/2003 (2:21 pm)
I'd like to see development/stable branching as well. Bug fixes need to get out to developers sooner rather than later.I suggest it should work in development cycles and be limited to a 'who's in development this cycle' checkin basis. At the start of the cycle, all participants check out and start doing their changes, preferably with as much cooperation as possible so they don't step on each other. Midway in the cycle, emphasis changes from developing new code to making sure what's all there works and sorting out who fixes what. At the end of the cycle, changes are merged over to head and a new checkpoint is created.
Then you make a new list of people who are signed up for changes for the development branch, and start a new cycle so they can start doing their changes...
If the development branch isn't stabilized periodically, it might never become stable, and therefore never go to head.
The stable branch still should get bug fixes, and minor changes that don't require development shakedown, but that's what it's getting already.
#8
That said, that still doesn't address the issue of getting patches integrated into the code tree.
Linux's model works well because the "kernel" is maintained by Linus but all the external bric-a-brac -- video, filesystems, etc. -- are done by third parties and/or handled by the distros.
Because Torque isn't truly open source, we can't follow that model, otherwise I think someone would have already taken it, refactored it all, and set up a fork.
So we're in this really difficult situation where we're not allowed to fork our own radically modified versions -- using resources and patches to maintain branches is simply not tenable, you need to create a new repository -- but at the same time getting patches into the current tree seems really difficult.
Ideally it would be nice if Torque was divided into a kernel + modules, as has been proposed numerous times. Then GG could maintain the kernel, but modules could be truly open source since they would not be able to run independently of the kernel. Very few people would need to patch or modify the kernel, and entire teams could be off making new subsystems and plug-ins without fear of breaking things.
Much like when someone makes a new file system for Linux, it has almost no effect on those making other file systems or working on the kernel. Right now when someone needs to make a change to a subsystem in Torque, it often has massive ripple effects.
Even the Quake 2 engine -- ANSI C and all -- works this way. The renderers and games are independent of each other, so by and large if you change how the software renderer works, you won't affect the game. And new games can be written without modifying the client, etc.
To compound matters, GG is going to be in the position where they want to maintain as much backwards compatibility as possible, which may have the adverse effect of preventing any major -- but good and necessary -- changes from ending up in HEAD _ever_.
I think the middle ground is the devel + stable strategy, and then every year or so to push devel into stable. If HEAD is stable right now, just lock it down except for bug fixes _only_, and then fork off a DEVEL tree and call it 1.3. Go to town and overhaul the codebase, breaking compatibility if necessary, update the assets/scripts, etc.
Anyone doing serious development just stucks with 1.2.x, and anyone that wants to be on the cutting edge can use 1.3.x. When 1.3.x reaches the same state of functionality that 1.2.x has achieved, then rev it to 2.0 and fork off a 2.1.x, rinse, repeat.
03/03/2003 (2:34 pm)
It's become apparent that either a strategy needs to be outlined or, if a strategy exists, that it needs to be communicated by the GG folk. I think they really want to see Torque succeed, but at the same time I'm sure they also have a lot of their own internal projects they need to work on instead of spending all day dealing with patches.That said, that still doesn't address the issue of getting patches integrated into the code tree.
Linux's model works well because the "kernel" is maintained by Linus but all the external bric-a-brac -- video, filesystems, etc. -- are done by third parties and/or handled by the distros.
Because Torque isn't truly open source, we can't follow that model, otherwise I think someone would have already taken it, refactored it all, and set up a fork.
So we're in this really difficult situation where we're not allowed to fork our own radically modified versions -- using resources and patches to maintain branches is simply not tenable, you need to create a new repository -- but at the same time getting patches into the current tree seems really difficult.
Ideally it would be nice if Torque was divided into a kernel + modules, as has been proposed numerous times. Then GG could maintain the kernel, but modules could be truly open source since they would not be able to run independently of the kernel. Very few people would need to patch or modify the kernel, and entire teams could be off making new subsystems and plug-ins without fear of breaking things.
Much like when someone makes a new file system for Linux, it has almost no effect on those making other file systems or working on the kernel. Right now when someone needs to make a change to a subsystem in Torque, it often has massive ripple effects.
Even the Quake 2 engine -- ANSI C and all -- works this way. The renderers and games are independent of each other, so by and large if you change how the software renderer works, you won't affect the game. And new games can be written without modifying the client, etc.
To compound matters, GG is going to be in the position where they want to maintain as much backwards compatibility as possible, which may have the adverse effect of preventing any major -- but good and necessary -- changes from ending up in HEAD _ever_.
I think the middle ground is the devel + stable strategy, and then every year or so to push devel into stable. If HEAD is stable right now, just lock it down except for bug fixes _only_, and then fork off a DEVEL tree and call it 1.3. Go to town and overhaul the codebase, breaking compatibility if necessary, update the assets/scripts, etc.
Anyone doing serious development just stucks with 1.2.x, and anyone that wants to be on the cutting edge can use 1.3.x. When 1.3.x reaches the same state of functionality that 1.2.x has achieved, then rev it to 2.0 and fork off a 2.1.x, rinse, repeat.
#9
03/03/2003 (2:57 pm)
Yes, I agree there needs to be a plan backed by GG. This style of monolithic code structure will never work on a long-term basis and cannot handle numerous updates. I would support the stable freeze and redesign idea set forth by other posters.
#10
First, what's the upgrade plan for Torque? Torque is showing its age in terms of rendering features and has never been strong on modular design. The plan here at GG is to do a major overhaul on the engine, both in order to bring it in line with current hardware capabilities, as well as create much more modular interfaces to and between the various subsystems. It's safe to say that this refactoring of the engine will severely break backward compatibility with the current version of Torque. We're currently in the design phase of this project - identifying which components to keep, which to modify (clean up), and which to rewrite entirely. Our intent is to get interested community members involved in the project as soon as possible. When we return from GDC we'll begin outlining our roadmap for version 2.0 of Torque.
The second issue, touched upon in another thread, is seperate CVS repositories for branches of torque or related projects. This issue is tricky - as Brian mentioned, if you host it yourself, controlling access to only Torque licensees is difficult, thereby making it difficult to avoid violating the Torque EULA. On the other hand, having GG host those CVS repositories adds maintainance issues as well as recurring bandwidth costs. We're currently considering several options, including just doing the hosting ourselves for a small number of projects we think will most benefit the community.
Right now I'm just trying to get this Marble Blast FX demo working (along with Brian and Pat) for the big show in San Jose, so don't expect much movement on this stuff til after GDC.
03/03/2003 (4:54 pm)
There are really a couple of separate issues here.First, what's the upgrade plan for Torque? Torque is showing its age in terms of rendering features and has never been strong on modular design. The plan here at GG is to do a major overhaul on the engine, both in order to bring it in line with current hardware capabilities, as well as create much more modular interfaces to and between the various subsystems. It's safe to say that this refactoring of the engine will severely break backward compatibility with the current version of Torque. We're currently in the design phase of this project - identifying which components to keep, which to modify (clean up), and which to rewrite entirely. Our intent is to get interested community members involved in the project as soon as possible. When we return from GDC we'll begin outlining our roadmap for version 2.0 of Torque.
The second issue, touched upon in another thread, is seperate CVS repositories for branches of torque or related projects. This issue is tricky - as Brian mentioned, if you host it yourself, controlling access to only Torque licensees is difficult, thereby making it difficult to avoid violating the Torque EULA. On the other hand, having GG host those CVS repositories adds maintainance issues as well as recurring bandwidth costs. We're currently considering several options, including just doing the hosting ourselves for a small number of projects we think will most benefit the community.
Right now I'm just trying to get this Marble Blast FX demo working (along with Brian and Pat) for the big show in San Jose, so don't expect much movement on this stuff til after GDC.
#11
03/03/2003 (7:38 pm)
yes
#12
edit- Ive been thinking lately how nice it would be to have a much more advanced demo to work with.
03/03/2003 (7:44 pm)
It would be awesome if the 1.1.2 cvs version of torque went gpl (hosted by sourceforge) and 2.0 stayed private. If its breaking backwards compatability and your not losing anything (nobody will buy torque for the previous 1.1.2 version). I see torque missing out on alot becuase poor programmers cant afford to get involved with development.edit- Ive been thinking lately how nice it would be to have a much more advanced demo to work with.
#13
03/03/2003 (8:14 pm)
You do NOT want Torque going GPL, unless you never intead to sell your games. LGPL yes GPL no.
#14
Dual Licensing could make a lot of sense...
GPL to get people working with Torque, promote the engine, and provide an impetus for the ->
Commercial License for use in closed source projects
This of course depends on torque's current license entanglements (if any), and how important Torque's revenue is to GarageGames vs. the benefits to the technology and it's developers.
-J
03/03/2003 (8:17 pm)
Not that this really belongs in this thread...Dual Licensing could make a lot of sense...
GPL to get people working with Torque, promote the engine, and provide an impetus for the ->
Commercial License for use in closed source projects
This of course depends on torque's current license entanglements (if any), and how important Torque's revenue is to GarageGames vs. the benefits to the technology and it's developers.
-J
#15
03/03/2003 (8:26 pm)
I would have said lgpl but i know they wouldnt even consider thinking about doing that... we can dream though. IDsoftware dosnt sweat gpl'ing the quake2 source. Other companies recognize that theyre not loosing anything directly by open sourcing there software. Just becuase people can download and edit something dosnt mean they can redistribute altered forms of it in source form electronicly for money etc etc. Im glad ive mostly seen legit developers and no pirating, i dont want thieves hanging around anyways. But having the people who cant or wont pay the 100$ work on your software for you is as good as getting the 5% that might actually buy torque for 100$
#16
03/03/2003 (8:27 pm)
TIMMAH!
#17
03/03/2003 (8:29 pm)
I stand corrected. Dual license the puppy and put it up on SourceForge. That very neatly solves the CVS access issue as well as CVS access for any forks + project management + defect tracking + mailing lists + + +
#18
03/03/2003 (9:23 pm)
except SF sucks badly.
#19
BTW SF.net isnt the only possible solution to 3rd party cvs hosting. I know they can handle the size and bandwidth necessary for free, and relatively securely.
03/03/2003 (10:00 pm)
How would sierra feel about gpl'ed torque code?BTW SF.net isnt the only possible solution to 3rd party cvs hosting. I know they can handle the size and bandwidth necessary for free, and relatively securely.
#20
Edit: This actually tweaks me. You guys just volunteer us to give away our code. What are we supposed to pay our rent with? If you want GPL code, use Crystal Space.
Jeff Tunnell GG
03/04/2003 (8:39 am)
Torque is not going GPL or LGPL. Even with our measly $100 per programmer, we are not making enough money to pay ourselves.Edit: This actually tweaks me. You guys just volunteer us to give away our code. What are we supposed to pay our rent with? If you want GPL code, use Crystal Space.
Jeff Tunnell GG
Torque Owner J. Donavan Stanley