TSE question for potential customer
by Mike Winters · in Torque Game Engine · 10/19/2006 (4:51 pm) · 18 replies
Hello!
For the last two days I have been researching the TGE and TSE in my limited free time for a project I am currently doing a feasibility study on. My goal is to create an MMORPG using the TSE. I know Dreamer has made a kit with a good amount of code for the TGE 1.3 if I recall correctly, but I was unable to find a port for the TSE. Possibly due to the fact that certain sections of the website are closed to non customers. I also know he has made several MMO tutorials, which I have skimmed. I've read enough posts and seen enough of the TSE to feel confident that the engine can handle what I envision, should I have the talent and time to make it happen, and I have pretty much settled on the TSE as my engine of choice. I have a few questions about the TSE that are unanswered, however.
My questions are as follows:
Firstly, how similar to C/C++ is TorqueScript? I have not worked with C or C++ much in the past, and I don't particularly like the languages, preferring Java when possible. Because the vast majority of the code I have written does not need low level device type operations that I feel is the primary reason for using C based languages, I'm somewhat of a novice when it comes to that language. How difficult will it be switching to TorqueScript? Does it completely follow an established language's conventions, or is it more of an amalgamation of several languages? As a reference, I have worked with UnrealScript in the past (and absolutely loved it), if that helps.
Secondly, just to confirm, does the TSE come with the full TNL code, or will I need to purchase a license for that separately? $100 for the TGE +$150 for the TSE +$300 for the TNL would be a bit out of my price range, as I am but a mere college student who makes a living skydiving, and all that money goes to either tuition or my mortgage.
Thirdly, I've seen several posts on the terrain paging topic using Atlas with the TSE. Some have said it will be fully suppported, others have said it will be partially supported, some have vascillated on the topic. Will terrain paging be 100% supported out of the box, or will I need to devote a good deal of time developing that system? I want to allow my players to basically walk around the planet without stopping, without loading. The threads I have seen so far seem to indicate this is possible, but I want to confirm this.
Fourthly (this is more of a licensing issue), if I purchase the TGE and TSE licenses and am able to successfully create the code I need, is it legal (and possible) for other programmers to write code ONLY IN SCRIPT, without having a license of their own?
I think having answers to these questions will be enough for me to make a more complete proposal to the powers that be, so to speak.
Thanks,
Mike
For the last two days I have been researching the TGE and TSE in my limited free time for a project I am currently doing a feasibility study on. My goal is to create an MMORPG using the TSE. I know Dreamer has made a kit with a good amount of code for the TGE 1.3 if I recall correctly, but I was unable to find a port for the TSE. Possibly due to the fact that certain sections of the website are closed to non customers. I also know he has made several MMO tutorials, which I have skimmed. I've read enough posts and seen enough of the TSE to feel confident that the engine can handle what I envision, should I have the talent and time to make it happen, and I have pretty much settled on the TSE as my engine of choice. I have a few questions about the TSE that are unanswered, however.
My questions are as follows:
Firstly, how similar to C/C++ is TorqueScript? I have not worked with C or C++ much in the past, and I don't particularly like the languages, preferring Java when possible. Because the vast majority of the code I have written does not need low level device type operations that I feel is the primary reason for using C based languages, I'm somewhat of a novice when it comes to that language. How difficult will it be switching to TorqueScript? Does it completely follow an established language's conventions, or is it more of an amalgamation of several languages? As a reference, I have worked with UnrealScript in the past (and absolutely loved it), if that helps.
Secondly, just to confirm, does the TSE come with the full TNL code, or will I need to purchase a license for that separately? $100 for the TGE +$150 for the TSE +$300 for the TNL would be a bit out of my price range, as I am but a mere college student who makes a living skydiving, and all that money goes to either tuition or my mortgage.
Thirdly, I've seen several posts on the terrain paging topic using Atlas with the TSE. Some have said it will be fully suppported, others have said it will be partially supported, some have vascillated on the topic. Will terrain paging be 100% supported out of the box, or will I need to devote a good deal of time developing that system? I want to allow my players to basically walk around the planet without stopping, without loading. The threads I have seen so far seem to indicate this is possible, but I want to confirm this.
Fourthly (this is more of a licensing issue), if I purchase the TGE and TSE licenses and am able to successfully create the code I need, is it legal (and possible) for other programmers to write code ONLY IN SCRIPT, without having a license of their own?
I think having answers to these questions will be enough for me to make a more complete proposal to the powers that be, so to speak.
Thanks,
Mike
About the author
#3
Orion, thanks for your item by item response. I was under the impression that the demo was more of a tech demo (which I have seen) and less of an actual game. I'll check around for the script files and see what I can find. To be honest, I'm not concerned about learning a new langugage, I just need to give a rough estimate of how much additional time I need to factor in for language familiarization, on top of codebase familiarization, before I can really start writing code of my own.
Also, regarding the Atlas features, my current plan is to completely forego the TGE, and I will purchase it only for the TSE "early adopter" prerequisite. I plan to do all my work solely for the TSE at this point. I wish I could get a definite answer about the terrain paging, though. While I don't have a problem writing it myself (although I'm not sure if my abilities are up to that sort of undertaking at the moment), it would make my life a lot easier if I don't have to.
Thank you both, again, for helping me out on this. If anyone else has something to add, I'd be greatful for any help you can give me. I'm sure you guys get a lot of rookies around here asking the same stupid questions (of which I am probably already guilty of at this point), and I'd like to avoid that where possible.
Mike
10/19/2006 (6:23 pm)
Orion and Mark, thanks for the fast replies. Mark- thanks for that link. I had seen a mention of Titas once or twice, but I've been having some issues with my network the last week or so and was unable to access that domain for a while. I've now added Titas to my list.Orion, thanks for your item by item response. I was under the impression that the demo was more of a tech demo (which I have seen) and less of an actual game. I'll check around for the script files and see what I can find. To be honest, I'm not concerned about learning a new langugage, I just need to give a rough estimate of how much additional time I need to factor in for language familiarization, on top of codebase familiarization, before I can really start writing code of my own.
Also, regarding the Atlas features, my current plan is to completely forego the TGE, and I will purchase it only for the TSE "early adopter" prerequisite. I plan to do all my work solely for the TSE at this point. I wish I could get a definite answer about the terrain paging, though. While I don't have a problem writing it myself (although I'm not sure if my abilities are up to that sort of undertaking at the moment), it would make my life a lot easier if I don't have to.
Thank you both, again, for helping me out on this. If anyone else has something to add, I'd be greatful for any help you can give me. I'm sure you guys get a lot of rookies around here asking the same stupid questions (of which I am probably already guilty of at this point), and I'd like to avoid that where possible.
Mike
#4
re Script, if the Tech Demo doesn't have much in the way of scriptability,
download the TGE demo. The scripting language will be the same.
10/19/2006 (6:30 pm)
Hiya - re Script, if the Tech Demo doesn't have much in the way of scriptability,
download the TGE demo. The scripting language will be the same.
#5
10/19/2006 (6:35 pm)
Regarding scripting: anyone can write scripts without paying money. Only people seeing the C++ code need to pay money to GarageGames. It's in the license, if you read it carefully.
#6
JW- thanks for confirming this. It is what I thought, but just wanted to be sure. I don't want to be on the receiving end of a lawsuit, and figured it was better to ask and look stupid than not ask and break the law.
I guess the only thing I am still not sure about is the terrain paging capabilities of the TSE.
Mike
10/19/2006 (6:39 pm)
Orion- thanks again, I'm looking into that now.JW- thanks for confirming this. It is what I thought, but just wanted to be sure. I don't want to be on the receiving end of a lawsuit, and figured it was better to ask and look stupid than not ask and break the law.
I guess the only thing I am still not sure about is the terrain paging capabilities of the TSE.
Mike
#7
1) Answered in part, but in general the use of TorqueScript is much more like Java than c++ to be honest--it's a script language for high level game play implementation, and is simply "c++ like" for ease of transition for C++ developers.
2) As Orion mentioned, TNL is an extracted version of the normal Torque networking, which comes stock with both TGE and TSE. There is no need to purchase TNL separately unless you wish only Torque Networking for use with another engine or product.
3) Atlas is fully paged from the hard drive based on a chunked LoD style implementation. In theory it can render more square feet than their are particles in the known universe--in reality, you are limited by hard drive space and file format limitations for the textures, although that can be bypassed with the proper use of tiled or blended textures.
4) If a scripter will not ever have access to the source code, they can use the executable compiled by your licensed developers with no EULA restrictions.
5) None of our demos are "feature limited" by design. Basically, they contain everything possible with a source code license, except for the source code itself. That being said, the TSE demo is not up to date currently with the latest Milestone 4, and therefore is behind in released functionality.
10/19/2006 (9:32 pm)
Both Ben Garney (Atlas author) and I have actually been teaching TSE and Atlas all day in a Torque Boot Camp all day, so sorry we didn't get a chance to respond previously.1) Answered in part, but in general the use of TorqueScript is much more like Java than c++ to be honest--it's a script language for high level game play implementation, and is simply "c++ like" for ease of transition for C++ developers.
2) As Orion mentioned, TNL is an extracted version of the normal Torque networking, which comes stock with both TGE and TSE. There is no need to purchase TNL separately unless you wish only Torque Networking for use with another engine or product.
3) Atlas is fully paged from the hard drive based on a chunked LoD style implementation. In theory it can render more square feet than their are particles in the known universe--in reality, you are limited by hard drive space and file format limitations for the textures, although that can be bypassed with the proper use of tiled or blended textures.
4) If a scripter will not ever have access to the source code, they can use the executable compiled by your licensed developers with no EULA restrictions.
5) None of our demos are "feature limited" by design. Basically, they contain everything possible with a source code license, except for the source code itself. That being said, the TSE demo is not up to date currently with the latest Milestone 4, and therefore is behind in released functionality.
#8
Thanks for the responce. I've perused a bit of code from various locations, and I am confident I can pick this new language up with relative ease. I taught myself to program on a Commodore 64 when I was a child, and while I am far from a professional, I've been writing code long enough that it comes pretty easily to me.
My only real remaining concern is the limitations of the terrain engine in the TSE. Perhaps I am not knowledgeable enough to ask the right question, so I will attempt to explain what I want to do, just to be clear.
Essentially, given a M by N sized terrain square (obviously, a very large one), what I would need to be able to do is break that very large terrain piece up into smaller pieces or zones to lessen load time per zone/piece/grid square/whatever it really should be called. Then, I would need the engine to automatically detect when a player is nearing a zone border, and pre load the adjacent zone so that the player never has to wait. This would mean a minimum of 4 mini zones would need to be in memory at any given time (the one the player is in, and the nearest adjacent zones on each side and diagonally). The engine would also need to be able to unload zones to conserve memory. From what I understand, this is already implemented, at least in part. I'm just not sure how close the current capabilities are to what I envision.
I would also like to be able to make the terrain wrap onto itself, so that if the player walks off the edge of the terrain (the border), they just continue walking onto the other side. If what I described in the above paragrah is possible, I don't see why this would be any more difficult.
The combination of these two features would enable me to create either a very large terrain zone that is automatically sub divided into more appropriately sized and manageable pieces, or to create a number of smaller zones and set what the next "border zone" to load is. Either way, if done right, I can simulate a planet with complete wrap around, allowing the player to travel in any direction for a limitless amount of time.
For the record, I do NOT want something quite as large as the actual size of Earth, although my game world will take place there. Just something large enough to give the player the impression of reality. Offhand, I think something along the lines of 3/4 scale would be ideal.
I apologize for the lengthy post, and thank you again for taking the time to respond.
Mike
10/19/2006 (9:57 pm)
Stephen,Thanks for the responce. I've perused a bit of code from various locations, and I am confident I can pick this new language up with relative ease. I taught myself to program on a Commodore 64 when I was a child, and while I am far from a professional, I've been writing code long enough that it comes pretty easily to me.
My only real remaining concern is the limitations of the terrain engine in the TSE. Perhaps I am not knowledgeable enough to ask the right question, so I will attempt to explain what I want to do, just to be clear.
Essentially, given a M by N sized terrain square (obviously, a very large one), what I would need to be able to do is break that very large terrain piece up into smaller pieces or zones to lessen load time per zone/piece/grid square/whatever it really should be called. Then, I would need the engine to automatically detect when a player is nearing a zone border, and pre load the adjacent zone so that the player never has to wait. This would mean a minimum of 4 mini zones would need to be in memory at any given time (the one the player is in, and the nearest adjacent zones on each side and diagonally). The engine would also need to be able to unload zones to conserve memory. From what I understand, this is already implemented, at least in part. I'm just not sure how close the current capabilities are to what I envision.
I would also like to be able to make the terrain wrap onto itself, so that if the player walks off the edge of the terrain (the border), they just continue walking onto the other side. If what I described in the above paragrah is possible, I don't see why this would be any more difficult.
The combination of these two features would enable me to create either a very large terrain zone that is automatically sub divided into more appropriately sized and manageable pieces, or to create a number of smaller zones and set what the next "border zone" to load is. Either way, if done right, I can simulate a planet with complete wrap around, allowing the player to travel in any direction for a limitless amount of time.
For the record, I do NOT want something quite as large as the actual size of Earth, although my game world will take place there. Just something large enough to give the player the impression of reality. Offhand, I think something along the lines of 3/4 scale would be ideal.
I apologize for the lengthy post, and thank you again for taking the time to respond.
Mike
#9
There are no terrain based "zone times" for Atlas terrains. If, for example, you have a 250 km x 250 km Atlas terrain for your "mission", Atlas will only load in on the client from the hard drive the terrain needed to render the appropriate levels of detail for the visible distance range you have decided upon for your game.
Atlas accomplishes this by a combination of several techniques:
1) When you bring your massive terrain into the engine, it is pre-processed into a series of chunks of detail based on your input parameters into optimized rendering sizes in both geometry and texture.
2) The chunked lod algorithm for geometry, and a clipmap based rendering implementation determine which geometry and texture from your massive (hard drive stored) dataset need to be loaded into memory, both cpu and gpu areas.
3) A multi-threaded background loader does on-demand non-blocking loads from the hard drive the appropriate geometry, and textures if required, to meet the predicted demands of the current and near future rendering requirements.
In general, for the terrain specifically, Atlas is far in advance of your stated requirements.
Please note however that Atlas only deals with the terrain itself--in a truly large world, your problem becomes not the rendering and loading of the terrain, but prioritized and optimized updating of the tens or hundreds of thousands of objects you will need to populate such a large world.
Regarding your wrap-around concept, that is not stock, but given the power and flexibility of Atlas terrains, it simply becomes a data organization issue, and possibly a minor alignment requirement of the lod chunks of the edges for wraparound functionality.
10/19/2006 (10:14 pm)
No problem at all, but I don't think you are using the terminology for paged terrain that we are!There are no terrain based "zone times" for Atlas terrains. If, for example, you have a 250 km x 250 km Atlas terrain for your "mission", Atlas will only load in on the client from the hard drive the terrain needed to render the appropriate levels of detail for the visible distance range you have decided upon for your game.
Atlas accomplishes this by a combination of several techniques:
1) When you bring your massive terrain into the engine, it is pre-processed into a series of chunks of detail based on your input parameters into optimized rendering sizes in both geometry and texture.
2) The chunked lod algorithm for geometry, and a clipmap based rendering implementation determine which geometry and texture from your massive (hard drive stored) dataset need to be loaded into memory, both cpu and gpu areas.
3) A multi-threaded background loader does on-demand non-blocking loads from the hard drive the appropriate geometry, and textures if required, to meet the predicted demands of the current and near future rendering requirements.
In general, for the terrain specifically, Atlas is far in advance of your stated requirements.
Please note however that Atlas only deals with the terrain itself--in a truly large world, your problem becomes not the rendering and loading of the terrain, but prioritized and optimized updating of the tens or hundreds of thousands of objects you will need to populate such a large world.
Regarding your wrap-around concept, that is not stock, but given the power and flexibility of Atlas terrains, it simply becomes a data organization issue, and possibly a minor alignment requirement of the lod chunks of the edges for wraparound functionality.
#10
Thanks again for such a detailed response. While I don't fully understand everything you just said, you have answered my question completely. I know I need to do a lot more research, but you have given me enough to know where I would stand as far as coding goes, and a good starting point for further research.
Hopefully I will be discussing this topic in further detail on the TSE developer forums in the weeks to come.
One final question, if I may: would you say that having a terrain approximately 3/4 the size of North America is realistically attainable given the abilities of the engine as they currently are?
Thanks,
Mike
10/19/2006 (10:56 pm)
Stephen,Thanks again for such a detailed response. While I don't fully understand everything you just said, you have answered my question completely. I know I need to do a lot more research, but you have given me enough to know where I would stand as far as coding goes, and a good starting point for further research.
Hopefully I will be discussing this topic in further detail on the TSE developer forums in the weeks to come.
One final question, if I may: would you say that having a terrain approximately 3/4 the size of North America is realistically attainable given the abilities of the engine as they currently are?
Thanks,
Mike
#11
One server to handle all the objects? Absolutely not. You're looking at a server farm to rival World of Warcraft if not an order of magnitude or more larger to handle all of the objects that would be needed to populate that size of world, and some massive backend server architecture design and implementation to handle it.
And that's quite a large budget even to design and implement, much less actually purchase and operate.
10/20/2006 (12:11 am)
Terrain? Yes (given a lot of dataset creation--that's a lot of terrain!).One server to handle all the objects? Absolutely not. You're looking at a server farm to rival World of Warcraft if not an order of magnitude or more larger to handle all of the objects that would be needed to populate that size of world, and some massive backend server architecture design and implementation to handle it.
And that's quite a large budget even to design and implement, much less actually purchase and operate.
#12
Mike
10/20/2006 (5:48 am)
Thanks, that is the kind of information I wanted to know before diving into the deep end. Modifying design goals at this stage of the game is a lot easier than much further down the road.Mike
#13
1. Is it possible to use TGE (1.4 or 1.5) content packs with TGEA? For example, is it possible to drop Timothy Aste's building packs to TGEA project?
2. Currently TGEA is supported on Windows only. Are there any plans to make Linux port? Or maybe make it possible to compile dedicated server on Linux? (#ifdef DEDICATED ?)
01/30/2007 (11:57 am)
I'm checking various game engines to start with new project. TGEA is most promising, and the community here is amazing. I've found here answers to most questions that I had, but there is something left...1. Is it possible to use TGE (1.4 or 1.5) content packs with TGEA? For example, is it possible to drop Timothy Aste's building packs to TGEA project?
2. Currently TGEA is supported on Windows only. Are there any plans to make Linux port? Or maybe make it possible to compile dedicated server on Linux? (#ifdef DEDICATED ?)
#14
1) Some packs are TGEA ready, but I can't say if all are. The Medieval weapons pack shipped TGEA ready with the material definitions all scripted out. I doubt if the older content packs are the same. For the most part, getting art assets ready is not difficult, but full engines like AFX require more than just material definitions.
The great part is, whenever something is released, the source is usually working hard for a TGEA port as well. Faust (one developer for AFX), is an active poster and is helping to port AFX to TGEA.
2) The GG-Linux community appears to be pulling together to make this a possibility, from what I can tell. But it is only community driven, and no word of GG official support is available. There's always a way, as long as you have a community like this.
01/30/2007 (12:09 pm)
Hey Chris.1) Some packs are TGEA ready, but I can't say if all are. The Medieval weapons pack shipped TGEA ready with the material definitions all scripted out. I doubt if the older content packs are the same. For the most part, getting art assets ready is not difficult, but full engines like AFX require more than just material definitions.
The great part is, whenever something is released, the source is usually working hard for a TGEA port as well. Faust (one developer for AFX), is an active poster and is helping to port AFX to TGEA.
2) The GG-Linux community appears to be pulling together to make this a possibility, from what I can tell. But it is only community driven, and no word of GG official support is available. There's always a way, as long as you have a community like this.
#15
01/30/2007 (12:17 pm)
You will have to recompile the .map assets in Aste's packs with the TGEA Map2Dif.
#16
01/30/2007 (12:18 pm)
Big thanks for quick reply, Michael!
#17
Kinda. The original official word was that linux/osx would be supported in the first major release of TSE. That's no longer the case. The last time it was discussed, there were vague "Well, we're looking at probably maybe trying it". TGEA's graphics layer is very heavily tethered to directx.
As far as I know, no linux or mac community member is working on this. I know that *I* wouldn't do this;
1) It's a *lot* of work to do, that
2) may or may not be duplicative with what GG are doing internally... who knows?
3) It's basically a pretty thankless task
Anyways. I do dream of TGEA running on linux and mac, I've already purchased a license [back when it was garaunteed to come out for linux and mac on the first release]. But right now, if linux support is on your wishlist, TGEA isn't a suitable choice of engine.
Gary (-;
01/30/2007 (12:24 pm)
Quote:2) The GG-Linux community appears to be pulling together to make this a possibility, from what I can tell. But it is only community driven, and no word of GG official support is available. There's always a way, as long as you have a community like this.
Kinda. The original official word was that linux/osx would be supported in the first major release of TSE. That's no longer the case. The last time it was discussed, there were vague "Well, we're looking at probably maybe trying it". TGEA's graphics layer is very heavily tethered to directx.
As far as I know, no linux or mac community member is working on this. I know that *I* wouldn't do this;
1) It's a *lot* of work to do, that
2) may or may not be duplicative with what GG are doing internally... who knows?
3) It's basically a pretty thankless task
Anyways. I do dream of TGEA running on linux and mac, I've already purchased a license [back when it was garaunteed to come out for linux and mac on the first release]. But right now, if linux support is on your wishlist, TGEA isn't a suitable choice of engine.
Gary (-;
#18
01/30/2007 (12:45 pm)
Someone working on a Linux port is definatly not official, so as a Linux user I would stay away until there's more meat to it. 
Associate Orion Elenzil
Real Life Plus
it looks a lot like C, Java, Javascript, etc.
download the free demo and try it out.
> Secondly, just to confirm, does the TSE come with the full TNL code
TNL is the networking code from TGE/TSE extracted and made into its own product.
So no, no need to buy it. You get all the networking with TSE.
> Will terrain paging be 100% supported out of the box ?
not sure on that one. "Atlas" is a TSE feature, as far as i know.
> Fourthly, [can teammates work on script w/o their own copy of the license] ?
if it's licensed the same as TGE (and i think it is), then yes. check out the EULA.