New TGE Branch (2.0?)

#41 Brian,

Two excellent posts... and as I said, I don't like the GPL/LGPL... and most people don't... this is exactly what drives them to the commercial license :)

Outside of Dual Licensing I don't see how such Open Source methodology can be applied to Torque... and I don't see, from your post, a solution to this...

Maybe Garage Games shifting gears to Torque over the next year will calm the jitters I have... maybe my efforts will meet the approval necessary to have the project hosted... who knows...

There are the games and the technology... viewing them in isolation isn't appropriate for those of us working on larger scale goals...

-J

#42 edit: Rick's Post in the terrain thread made this question unneeded, deleted

#43 As I said in the terrain thread, if the engine was modular and plugable, this would all be a non-issue. All you'd need to host was core and plug variations. If bandwidth is an issue then figure a way that others could securely host pieces. I just don't see any of this being an earth-shattering problem. I'm sure there are ways for one server to provide a security front for another. It sounds like too common of a problem not to have been solved already. I'm not a web person so I don't know what specific solutions exist but I'm sure a quick Google session would provide numerous possibilites.

#44 GPL scares as many people away as the 100$ does. Some people dont want to share there code under any circumstances. Its a decision thats ultimately the responsibility of the gg's staff to make and Im sure theyll just say no. But it really does cripple and restrict across the board development of different efforts. I guess people could just use there better judgment for a private cvs between licensees. Its a shame that this operation apparently costs more money to operate than it generates. Regardless of anything gg's will own the rights to the code. I guess it really isnt a valid point unless 2.0 is so advanced it requires re-investment by licensees and 1.2 in comparison is really pathetic. Then i cant see how that anybody will ever use the old 1.2 except maybe some previously finished projects. We can all see that if we work together we can get the job done. Its just shady i have to go back to square 1.1.2 (or head) everytime i goto the cvs. It also sucks the license is still a bit restrictive and GG's has to handle all CVS. The best idea someeone had was TO SELL SOME TORQUE GAMES. Im sure over the next year some projects will get completed.

#45 I'm not a fan of changing Torque to a GPL, as noted above, the GPL is scary too, the LGPL slightly less so. I'm in favor of regular development cycles, a rotating bunch of people (with repeats allowed) getting their chance to make big changes at a time, then requiring the development branch to be re-stabilized so it can be merged back.

This has nothing to do with licensing. I don't think anyone is arguing they should get back their $100 for contributing in such a fashion either.

But it does have to do with having a systematic way for the community to contribute major code changes, with the cooperation of Garage Games.

#46 I think this GPL and LGPL talk should stop now. Don't get me wrong, I love open source, it is great.. but like Jeff Tunnell said before.. it isn't going to make them money no matter how you slice it.

Even if GG went with an LGPL license they could probably look forward to no one ever buying the updated engine.. why would people do that, when they could get a slightly less outdated engine that does the same thing for free.

I don't mean to be rude, but I guarantee you that you guys are just wasting your breathe advocating they dual license to GPL or LGPL.. just drop it already.

#47 if it's a hosting issue, I can help with that.

#48 I agree with the GPL issue part comin' to an end - Joshua's original post had something else completely in mind, and his dual license was just one means to accomplishing that :-)

I'd love to see a good solution to his original question too. However, I keep comin' back to the same problem with any idea I have about it - Mark already stated that GG is planning on a revamp of sorts on the engine. Should they just open that up, and let the entire community have a hand in the process (reducing effort, but, probably loosing the focus of whatever GG has in mind for thier plans on it), or should the community risk a new 'community branch' but have it be obsoleted by GG's planned work on the engine?

(Hopefully Brian didn't lump us all who said No GPL into the batch that thinks 'everyone just wants it for free' :-)

Now, I'm going to present somethin' completely unrealistic and utopian here. Joshua's comment "Collaboration is important... " triggered this unrealistic idea:

Why not grab all of the people who are wanting to get the engine stablized and ready for a new wave of expansion (I guess that would include me), and get everyone to agree on a short term development plan for just sheer cleanup - integrate in all the patches, bug fixes, cleanups, and minor non-combatibility breaking enhancements and get them all cleaned up and integrated with the current HEAD. Test it, make sure all the current issues are taken care of, and put it to bed. With some good coordination, the amount of manpower (and some of the highly competent people here in the community) would make the phase pretty short.

One it's to that point, then the modularization process would be easier to takle - the whole thing would have a stable launch point for the next branch, and the community could feel like all the stuff that's been submitted as fixes didn't go to waste. Call that the stable branch, and put into maintance only mode, possibly having a couple of community members handle the maintance of that branch if anyone was interested. All GG would really have to do is host the CVS stable branch (duh - they already do) and any mainance branch. Then 'Torque 2.0' branch could start rather easily. It basically would add one new branch, and just community people to get it maintained.

That would at least handle PART of the issues Joshua and others brought up. However, still doesn't quite cover Joshua's original question, and I haven't a good suggestion for that - unless GG opens up the development of 2.0, well, we've just gotta relax a bit I guess. ('Specially since that probably ain't gonna happen - I'd hate to see what Design By Commitee would make a T2.0 look like! ;-)

Anyway - overly optimistic idea on my part. But, maybe someone see's something salvageable there.

#49 Davis,

I think this is a good idea. I'm not the techie here at GG, but I think this sounds like a good way to accomplish a lot of what people are asking for.

Part of the puzzle would be for us to host CVS for interesting and important projects.

Another thought that I had, but don't know how feasible it is, would be to somehow allow others to host CVS, but validate user accounts through the GG site. I didn't get a chance to talk about this at the office today, but it seems like it could work.

Anyway, we'll be dark for about five days while at GDC. Rick is available since he is staying home waiting for his first child to be born.

Jeff Tunnell GG

#50 I thought about GG's doing authentications and another server doing the footwork the other day. Maybe some official 3rd party can help gg's.com reduce operating costs.

#51 I would love to see a scaled down, well laid out, solid, but minimal, version of Torque. Remove the mission code, remove vehicles, remove any remaining stuff that was Tribes2 specific, etc. Sure, there's a lot of neat stuff in there, but not every game needs all that functionality.

Then reorganize the code into a very modular, very understandable codebase and make that a separate development base for people to work from. The only changes that get merged into that base are bug fixes and general enhancements that would benefit any game.

I've tried several times to sit down and use the Torque engine for my project, and what happens is I get overwhelmed. I feel like I'm modding Tribes2 and not creating a game of my own. There is so much code in there that I just don't need, and to remove it would be such a massive undertaking that I end up searching for another engine, or (worse) attempting to write my own engine, which isn't very productive at all. I'm not alone - I see lots of threads here asking for a slimmed down version of Torque.

Once the code is cleaned up and modularized (is that a word?) then people could use it more efficiently and I expect we would see even more games being released. Torque has been available for 18 months now and there's only like 4 games out using it? That should say something about the ease of use of the current code.

What I'd like to see split out as modules are:

1 - Networking: single player games don't want/need it, so they should be able to easily remove it

2 - Different Terrain options: some projects require larger terrains, some want paging, etc. Have 2 or 3 different plug-in terrain handlers (I know some are in the works :) and allow people to easily replace one with another in their project

3 - Editor removal: The editors should be able to be easily dropped from a project. I know when (if) I ever get my game completed, I don't want to release the editors along with the game - there is no way I want players to modify the levels. Using them during development is great, but I should be able to remove them cleanly at the end if I want. Or if I want to leave a version of the GUI editor in, I can, but still drop the terrain editor, for example. Other games may want to leave both in, or neither, etc.

4 - Sound options: OpenAL, Ogg Vorbis, etc. People have preferences as to what they want to use. A properly structured Torque codebase would allow easy swapping. Plus, if you were a ways into development and someone released the most marvelous whizbang sound engine ever devised by mortal man, you could plop that in and use it easily :)

I'm sure there are others, but the thing is, with a good structured codebase, with everything split up into discrete modules, those items listed above should be easy to handle. As it is now, in Torque, it's a pain to undertake any one of those.

Don't get me wrong, I love the Torque engine. I just can't seem to be productive with it :)

As for the whole opensource issue, I like the licensing arrangement we have now. GG provides a great service and I have no problem paying them $100 to get the code to Torque in return for this service. There are a lot of opensource game engines out there and almost all of them have fallen flat. I'd hate to see that happen to Torque. Making Torque opensource would risk that, plus we'd lose the GG services we get.

#52 I agree with you about striping down Torque to the basics and then adding what you want; The other good point that I would like to see is the easy removal of the editor.

#53 Minimal Torque? A modular Torque is as minimal as you want it to be...

Modular... everyone in unison... M-o-d-u-l-a-r

-J

#54 Removing the editors is a fairly simple process - remove the key bindings for the editor, then remove the script files for it.

That doesn't address the rest of the modularization of course ;-)

#55 Gosh this thread makes me wish I knew this engine better.

As a C programmer, trying to wrap my head around what too often becomes some pretty ambiguous code, I really like some of what I'm hearing (reading) here! I feel like I am learning to think all over again!

I would love to see Torque get modularized. It would bring the overall complexity of the engine down to a highly managable level. Contributors would be able to focus their efforts on specific features with little or no concern for repercusions elsewhere in the engine! I can only foresee this as being a good thing.

Not going to belabor points that have allready been made, let me just say... count me IN on this one! (C:

edit: sp/grammar

#56 Greetings!

Making the Torque Engine more modular sounds great to me.

What I definitely don't want to see is the removal of the existing game logic. Improvements and bug-fixes, yes, but I still want it to be there as a starting point. I don't want to end up with just a network library and scene-graph.

I want to be able to see what it takes to make a complete game. I personally love to tinker with what exists, and if it doesn't completely fill my need, then I change it to fit my own game logic.

The advantage of modularity is it allows minimalists to remove everything they feel is junk while still allowing me to get the whole ball of wax. However, I don't want the push for code modularity to reduce the current speed and power of the engine. That's just the way I am. :o)

My CDN$0.02

- LightWave Dave

#57 Lightwave Dave: Totally agree with ya. In fact, not only do I not want to see the existing demo applications of the engine go away, I'd love to see more of 'em. It's great to have an existing starting point for an app - right now, if I was going do to a racing game, I'd grab the racing mod, and start hacking from there. None of the existing stuff that comes with the engine are full fledged games - just enough to get ya started, which is about perfect IMHO :-)

Heck, I'd really like to see some demo apps using Joshua's PyTorque :-) (One thing that I proposed over at TEP that I figured would happen is that someone would abstract the scripting interface, and make the language modular. Want to use VBA? Slap it in there. What to use Ruby? Slap it in there. However... I'm thinkin' I like Joshua's idea with PyTorque better - going the other direction with it, and having the language call a Torque lib. Very slick ;-)

But I have a similar concern as Dave's - getting TOO modularized with it, and abstracting things too far for a seriously modularized could increase overhead. *SHRUG* Really won't know for sure how much impact something will have until it someone has a completed plan for making the engine modular. Then it's a little easier to see what the impact COULD be.

Kirby: I'm of the opinion that even with a modular approach, you'll still have times where changes in the network engine, for instance, are going to cause problems with the player, things like that. Part of it depends on how well it's done, really, but making changes in one area always runs the risk of breaking things in another area - it's the nature of complex systems like this. It will be interesting to see how it's done for some areas (I'm interested to see how the network engine is abstracted, for instance. Some of that stuff laces through a lot of other areas.)

Even with my concern about speed, I'm all for a modular approach. It just makes sense. But step 1 is still getting everything that's there fixed first, and getting a last 'stable' version done before starting a modularized version. There's a whole lotta bugs & issues marked as 'open' at the moment. Some near and dear to my hear like problems with the Terrain Editor on Mac.

#58 You wouldn't have to necessarily dump the demo, but at least make it a module that can be easily removed if needed. As it is now, the demo code is intertwined with some engine functionality that makes it difficult to sort out.

#59 @Davis: One of the benefits to using SWIG on pyTorque is that the same interface files can be used to generate bindings for other languages such as Lua. So in one respect the sctiping engine will be plugable.

#60 I'm all for modular design, to a certain extent. You can't sacrafice speed and performance for usability, I ask that you all keep that in mind.

Game programmers are a different breed. We take shortcuts when we need them because speed and performance for a 'game engine designer' are #1 on the priority list, followed by features and then usuability.

Like I said above, I'm all for modular design, but I would gladly take the current code base over a more modular designed version if my non-modular version runs 10 frames faster.