Is T2D still going to get full networking support?
by jesusphreak · in Torque Game Builder · 03/17/2006 (6:26 pm) · 27 replies
Back a few months ago, it was said that T2D for the time being was going to have limited networking functionality, but in the future it would get complete networking support, much like the TGE.
Is this still going to happen, or will T2D forever have a "lite" version of networking?
Thanks
Is this still going to happen, or will T2D forever have a "lite" version of networking?
Thanks
#2
-JF
05/29/2006 (11:43 pm)
There's an aticle in the TDN area that will let you get most of the way there today, if you're feeling adventurous and own a TGE license.-JF
#3
05/30/2006 (2:34 am)
I am also interested in this. It was said to be included before end of EA.
#4
In the mean time the article Jon points out is probably your best bet.
05/30/2006 (4:44 am)
I don't think real-time is coming before final release anymore. Hopefully we'll see some work in this area once TGB is out of EA, how long that will be I've no idea though (networking that is, not the out of EA date). In the mean time the article Jon points out is probably your best bet.
#5
06/01/2006 (7:30 am)
Real-time networking out of the box will NOT be coming to TGB. The limited turn-based stuff is all that there will be. Anything else will have to be community built. Bait and switch? You can make up your own mind on that...
#6
06/01/2006 (7:46 am)
Hrm...this is one of the huge gating factors for my use of this engine. If there are absolutely no plans to implement full networking then you're really limited to the type of multiplayer game you can develop.
#7
-JF
06/01/2006 (9:14 am)
Now, don't get me wrong -- I have plenty of gripes about TGB, but bait and switch? I have never once seen anything from a GG employee or affiliate promising any such thing as full networking support.-JF
#8
That being said, no engine will give you everything that you need without having to do some of the heavy lifting yourself.
Personally I wish that more attention had been paid to including things like the networking instead of getting distracted with the whole point-and-click tools that were developed instead.
06/02/2006 (7:53 am)
Well, it may be true that it actually wasn't promised in the "T2D WILL INCLUDE A FULL REALTIME NETWORKING SOLUTION" type of statement.... I would argue that it was implied both through the wording of the original T2D webpage as well as discussions made in the private forums.That being said, no engine will give you everything that you need without having to do some of the heavy lifting yourself.
Personally I wish that more attention had been paid to including things like the networking instead of getting distracted with the whole point-and-click tools that were developed instead.
#9
As for their priorities: Real-time networking is only useful to a small subset of game projects, but the Level Builder is useful to a much much larger subset. I was skeptical at first too, but putting that tool in my graphic designer's hands has freed up a TON of my time and reduced the number of round-trips necessary to get artwork integrated and looking right into my game. That alone makes it more valuable to me than networking, physics, or any number of other areas that aren't as well developed. On top of that, it's allowed me to rapidly prototype half a dozen game ideas to see what's fun -- that's also quite valuable to me.
-JF
06/02/2006 (8:03 am)
The only thing I ever recall the T2D product page saying is that it included "TorqueNET Lite". I've also yet to see any mention by anyone who is associated with GG who has even implied that full networking support would be included. Could you post a reference to the discussion threads you are referring to?As for their priorities: Real-time networking is only useful to a small subset of game projects, but the Level Builder is useful to a much much larger subset. I was skeptical at first too, but putting that tool in my graphic designer's hands has freed up a TON of my time and reduced the number of round-trips necessary to get artwork integrated and looking right into my game. That alone makes it more valuable to me than networking, physics, or any number of other areas that aren't as well developed. On top of that, it's allowed me to rapidly prototype half a dozen game ideas to see what's fun -- that's also quite valuable to me.
-JF
#10
**************
David "NfoCipher" Bunt (Sep 03, 2005 at 02:32)
My question is, and pretty much always has been - when is networking going to be implemented? No, not the turn based networking, full twitch action stuff.
Melv May (Sep 03, 2005 at 15:05)
@David: For the same reason I can't answer when will the next release come out, I can't answer this. As soon as humanly possible is the best answer I can provide at the moment. I know this isn't what you wanted to hear but it IS the best answer I can do at the moment.
- Melv.
**************
Its in other places around if you look. Melv had the best intentions... but GG changed it at some point.
EDIT:
From his blog on Nov 18th:
**************
Melv May (Nov 20, 2005 at 09:40)
@Ian: The T2D objects don't have realtime streaming of network packets yet. Juggling what we do has been a hard thing to do and we always knew we'd be letting some people down by not doing this but there's lot of other stuff that equally, if we'd not have done it, we'd be letting people down. It's not just the technical details of getting it working, a big issue is dealing with it in such a way so that we don't enforce using the network on everyone. We could end up with a situation where new people, who're not interested, have to learn alot of networking techniques and understand a more complex script setup from the go. It's not that it isn't going to happen, it just isn't in there yet. The first stage to networking has been done and in the new SDK is an example of setting up a server and a client as an introduction to the networking basics for stuff such as chatting etc. As Scott mentions, there are many other ways (and better) if you're not developing 'twitch' games but turn-based or lower-paced games.
**************
06/02/2006 (8:19 am)
Check out Melv's blog from Sept 1, 2005:**************
David "NfoCipher" Bunt (Sep 03, 2005 at 02:32)
My question is, and pretty much always has been - when is networking going to be implemented? No, not the turn based networking, full twitch action stuff.
Melv May (Sep 03, 2005 at 15:05)
@David: For the same reason I can't answer when will the next release come out, I can't answer this. As soon as humanly possible is the best answer I can provide at the moment. I know this isn't what you wanted to hear but it IS the best answer I can do at the moment.
- Melv.
**************
Its in other places around if you look. Melv had the best intentions... but GG changed it at some point.
EDIT:
From his blog on Nov 18th:
**************
Melv May (Nov 20, 2005 at 09:40)
@Ian: The T2D objects don't have realtime streaming of network packets yet. Juggling what we do has been a hard thing to do and we always knew we'd be letting some people down by not doing this but there's lot of other stuff that equally, if we'd not have done it, we'd be letting people down. It's not just the technical details of getting it working, a big issue is dealing with it in such a way so that we don't enforce using the network on everyone. We could end up with a situation where new people, who're not interested, have to learn alot of networking techniques and understand a more complex script setup from the go. It's not that it isn't going to happen, it just isn't in there yet. The first stage to networking has been done and in the new SDK is an example of setting up a server and a client as an introduction to the networking basics for stuff such as chatting etc. As Scott mentions, there are many other ways (and better) if you're not developing 'twitch' games but turn-based or lower-paced games.
**************
#11
----------------------------------------------------------------------------
I'm not pointing fingers here. But saying it was never promised is not true.
Edit: I'm pointing fingers, so I pulled out their names. :p
06/02/2006 (8:40 am)
Quote:- Unknown
I kept networking in mind when I was developing T2D but I was initial cautious about making it too complicated as I wanted to make it as simple as possible but networking does make for some very interesting game ideas and it'll be networked as per standard TGE fairly soon.
Quote:- Foo
Shannara, for the EA release, T2D has a helper-networking class that I designed. It is very, very, very easy to add simple messaging for networking. The downside is that it is not a realtime simulation designed network, it's messaging. It's perfect for most T2D games, actually, but for the other 10% there will be a fully networked version 1.0.
Quote:- NULL
Networking is one of the the most important changes post EA1, alongside the editors. You won't be waiting a year for networking, nobody said you would.
Networking will be TGE networking well before year end of 2005. If this is just cynicism then please take it elsewhere, there's no need for it.
----------------------------------------------------------------------------
I'm not pointing fingers here. But saying it was never promised is not true.
Edit: I'm pointing fingers, so I pulled out their names. :p
#12
Somebody write it, I'll buy it - till then I suggest using TGE if you *need* this type of network support.
As for TGB, it's perfect as is for many many projects. I'm currently using it for a commercial project that isn't even game related. For the price you just can't beat it. You get the source - I mean what else do you need/want?
Can TGB do x,y,z? I don't know, can you make it do x,y,z?
06/02/2006 (9:05 am)
Guess I should point out that Melv isn't a gg employee. While I would love to see full TGE networking in TGB - it's just not going to happen by release. What this means is there's a market for this add-on and someone could make some real cash if they took the time to write it. I started down that road for a game I'm making, but it turned out that dumbing down tge would be cheaper than writing network stuff for TGB. Somebody write it, I'll buy it - till then I suggest using TGE if you *need* this type of network support.
As for TGB, it's perfect as is for many many projects. I'm currently using it for a commercial project that isn't even game related. For the price you just can't beat it. You get the source - I mean what else do you need/want?
Can TGB do x,y,z? I don't know, can you make it do x,y,z?
#13
Despite what you think the GG TGB dev team and Melv all work quite well together lol... in fact if anything he works mostly on the core engine funcitonality while we work on the Level Builder stuff (while he does some tweaks to enable us to do the Level Builder stuff and we fix some issues with the engine when we run into it)... there is no conspiracy against Melv lol.
Priorities have seemed to change since then, we realized how important the Level Builder is and other aspects of the engine. Melv is plugging away at further things, busy with aspects that take presedence over real-time networking for now...
also I'd like to say the networking that's in there is "full" networking... it's just not TGE style "real-time" networking. A lot of this has to do with the phsyics in TGB, also a lot of it has to do with TGB being more of an all-in-one game engine, while TGE is FPS/ Third PS and takes some good source tweaking to tell it otherwise, likewise if you change TGE from an FPS to someth ing else you'll probably have to modify the networking code.
TGB's vision is that you don't have to modify the source code to make a game (at least for the majority of games)... so im plementing an all in one real-time networking system t hat supports physics and just about any type of game is not an easy thing at all.
Heck, we could throw in a quick real-time networking port from TGE code, but it isn't going to work well, there are a lot more considerations for TGB and I'd like to think that when we do it, it will be done very well, instead of just a quick plug to meet a feature list, we don't work that way at GG :)
06/02/2006 (9:07 am)
You can say you're not pointing fingers, yet your finger is up in the air..Quote:Its in other places around if you look. Melv had the best intentions... but GG changed it at some point.
Despite what you think the GG TGB dev team and Melv all work quite well together lol... in fact if anything he works mostly on the core engine funcitonality while we work on the Level Builder stuff (while he does some tweaks to enable us to do the Level Builder stuff and we fix some issues with the engine when we run into it)... there is no conspiracy against Melv lol.
Priorities have seemed to change since then, we realized how important the Level Builder is and other aspects of the engine. Melv is plugging away at further things, busy with aspects that take presedence over real-time networking for now...
also I'd like to say the networking that's in there is "full" networking... it's just not TGE style "real-time" networking. A lot of this has to do with the phsyics in TGB, also a lot of it has to do with TGB being more of an all-in-one game engine, while TGE is FPS/ Third PS and takes some good source tweaking to tell it otherwise, likewise if you change TGE from an FPS to someth ing else you'll probably have to modify the networking code.
TGB's vision is that you don't have to modify the source code to make a game (at least for the majority of games)... so im plementing an all in one real-time networking system t hat supports physics and just about any type of game is not an easy thing at all.
Heck, we could throw in a quick real-time networking port from TGE code, but it isn't going to work well, there are a lot more considerations for TGB and I'd like to think that when we do it, it will be done very well, instead of just a quick plug to meet a feature list, we don't work that way at GG :)
#14
I am extremely happy with how TGB is turning out, the tools are great. The engine is still not a drag n' drop engine, but the tools complement the scripting language very well now. This was a much higher priority than real-time networking. You have the source and you have the existing networking (Tom Bampton also has posted a resource porting some of the TGE networking to TGB), you can network quite a few games with the present "turn-based" networking. Turn-based really isn't the best term for it, it just requires you to specify what info you want to pass back and forth.
EDIT: just wanted to add that Melv is awesome and his original vision of TGB (along with Josh's) was amazing and has grown even more. I love working with both of them (as well as the rest of the TGB team (Justin is doing a great job as Lead, Adam L. kicks ass on Level Builder dev, Paul keeps our mac side working - despite our many attempts at foiling it without even knowing :) and all community members involved Michael W. ... all the bounty submissions people, all the people helping me with docs - you are all great). Heck, all of us at GG want to steal Melv away from the UK and keep him over here in Oregon :) We had him for a week and it was a blast, lots of TGB planning and dev work done that week (as well as lots of drinking)...
Keep the feedback coming, just wanted to let you know that there is no GG conspiracy, honestly, you should know us by now... come up to a TGB bootcamp in Eugene, OR sometime and you'll get to visit the GG office. A lot of people would realize a lot of things by meeting the GG team in person, we are not out to work against you, in fact the oppossite, we don't work 10-14 hour days on average because we dislike our community and what they want. It's because you guys are great! We want to give you all that we can, unfortunately there is only so many hours in a day and only so many people at GG that can work on TGB... though on Melv's end, he's like a 5 coder team all in one.
06/02/2006 (9:12 am)
In the end there are more people who want those point and click tools than those that want real-time networking. Should we drop the majority and listen to the minority? Do you think that your concern might be more valid than what 10 other people think. I know what it's like on the other side, usually on the other side of the situation you don't think of those concerns, but we have to and in the end you listen to the majority of your customer base. It doesn't mean we are ignoring the rest, we just have limited resources. I mean at the most there was 3 GGers working full time on the TGB dev side, with about 2-3 slipping hours in when they weren't hammering on other projects. Our resources are limited, but we're doing all that we can to make TGB the best it can possibly be :)I am extremely happy with how TGB is turning out, the tools are great. The engine is still not a drag n' drop engine, but the tools complement the scripting language very well now. This was a much higher priority than real-time networking. You have the source and you have the existing networking (Tom Bampton also has posted a resource porting some of the TGE networking to TGB), you can network quite a few games with the present "turn-based" networking. Turn-based really isn't the best term for it, it just requires you to specify what info you want to pass back and forth.
EDIT: just wanted to add that Melv is awesome and his original vision of TGB (along with Josh's) was amazing and has grown even more. I love working with both of them (as well as the rest of the TGB team (Justin is doing a great job as Lead, Adam L. kicks ass on Level Builder dev, Paul keeps our mac side working - despite our many attempts at foiling it without even knowing :) and all community members involved Michael W. ... all the bounty submissions people, all the people helping me with docs - you are all great). Heck, all of us at GG want to steal Melv away from the UK and keep him over here in Oregon :) We had him for a week and it was a blast, lots of TGB planning and dev work done that week (as well as lots of drinking)...
Keep the feedback coming, just wanted to let you know that there is no GG conspiracy, honestly, you should know us by now... come up to a TGB bootcamp in Eugene, OR sometime and you'll get to visit the GG office. A lot of people would realize a lot of things by meeting the GG team in person, we are not out to work against you, in fact the oppossite, we don't work 10-14 hour days on average because we dislike our community and what they want. It's because you guys are great! We want to give you all that we can, unfortunately there is only so many hours in a day and only so many people at GG that can work on TGB... though on Melv's end, he's like a 5 coder team all in one.
#15
1) The main reason that we don't talk about feature lists and expected development for our products is exactly this thread. First, what both we and the customers think we want, and think are feasible aren't always, and in-depth R&D combined with market analysis made an implementation of the "stock" ghosting system as applied to TGB impossible to achieve as a viable product implementation given the entire structure and intent of TGB. Just a few thoughts on why:
--the reason Torque networking (ghosting) is so powerful is bit level packing of every single (extremely game specific) networked data element in a game. This requires c++ coding in some of the most difficult areas of the code to perform. From the beginning, TGB's design principle has been "don't make the developers even glance at C++ code unless they want to", but to implement any form of ghosting would require c++ modifications of the code base--catch 22. It was determined as a company (with many strong supporters of implementing it anyway, don't think it was an easy decision!) that TorqueNet Lite was the way to go.
--As Matt mentioned above, the ghosting concept/system applies to a more limited set of game genres than you would think, and TGB does not make the same assumptions as an application that are required for those genres. A more general solution is an extremely intensive project only applicable to a small subset of the total genre market TGB supports.
--TGB, and the nature of historical 2D games imply games that have a couple of basic fundamental designs:
----hundreds/thousands of objects (that would need updates)
----strict player/level timing based play (very possible on arcade machines, extremely difficult/impossible on fully cross-platform, multi-generational target market technology)--which is basically impossible to agnostically implement on a networked game given TGB's audience.
In summary:
-- TGB's internal networking architecture is very close to what is needed for a full ghosting style implementation.
-- The select sub-set of total games we expect to see made with TGB that need ghosting style networking also need extensive c++ development in any case.
-- Resources and code examples (TGE, TNL) are available for those projects that need ghosting capability, and a capable development team can certainly implement their game specific ghosting needs with some research and development work.
-- A viable, totally genre agnostic, script only, optimized ghosted networking implementation that meets the full design and development/marketing plan of TGB is well beyond the scope of TGB 1.1.
My personal general thoughts: Sometimes features that you think aren't difficult to implement turn out to be the most time/resource consuming implementations possible, and wind up having to be cut from the design plan. It's very regrettable (we as a company really DID want to see ghosting in TGB, but it simply wasn't viable) when you have suggested/mentioned it as a function set of a product, but the reality is, it happens occasionally.
06/02/2006 (9:35 am)
Couple of points out of the whole bunch that exist--1) The main reason that we don't talk about feature lists and expected development for our products is exactly this thread. First, what both we and the customers think we want, and think are feasible aren't always, and in-depth R&D combined with market analysis made an implementation of the "stock" ghosting system as applied to TGB impossible to achieve as a viable product implementation given the entire structure and intent of TGB. Just a few thoughts on why:
--the reason Torque networking (ghosting) is so powerful is bit level packing of every single (extremely game specific) networked data element in a game. This requires c++ coding in some of the most difficult areas of the code to perform. From the beginning, TGB's design principle has been "don't make the developers even glance at C++ code unless they want to", but to implement any form of ghosting would require c++ modifications of the code base--catch 22. It was determined as a company (with many strong supporters of implementing it anyway, don't think it was an easy decision!) that TorqueNet Lite was the way to go.
--As Matt mentioned above, the ghosting concept/system applies to a more limited set of game genres than you would think, and TGB does not make the same assumptions as an application that are required for those genres. A more general solution is an extremely intensive project only applicable to a small subset of the total genre market TGB supports.
--TGB, and the nature of historical 2D games imply games that have a couple of basic fundamental designs:
----hundreds/thousands of objects (that would need updates)
----strict player/level timing based play (very possible on arcade machines, extremely difficult/impossible on fully cross-platform, multi-generational target market technology)--which is basically impossible to agnostically implement on a networked game given TGB's audience.
In summary:
-- TGB's internal networking architecture is very close to what is needed for a full ghosting style implementation.
-- The select sub-set of total games we expect to see made with TGB that need ghosting style networking also need extensive c++ development in any case.
-- Resources and code examples (TGE, TNL) are available for those projects that need ghosting capability, and a capable development team can certainly implement their game specific ghosting needs with some research and development work.
-- A viable, totally genre agnostic, script only, optimized ghosted networking implementation that meets the full design and development/marketing plan of TGB is well beyond the scope of TGB 1.1.
My personal general thoughts: Sometimes features that you think aren't difficult to implement turn out to be the most time/resource consuming implementations possible, and wind up having to be cut from the design plan. It's very regrettable (we as a company really DID want to see ghosting in TGB, but it simply wasn't viable) when you have suggested/mentioned it as a function set of a product, but the reality is, it happens occasionally.
#16
I won't take your flamebait Matthew, though I have to say I never thought anyone would get offended when all I did was quoting previous statements, and sincerely pointing out that my reason for that was to show Jon that it had indeed been promised full networking support.
Now, things change and I understand that - which is why I said I'm not pointing fingers. To make sure *no one* misunderstands. Still, you resort to flames - very professional, and thank you.
I'm out of here.
06/02/2006 (10:42 am)
Quote:
You can say you're not pointing fingers, yet your finger is up in the air..
I won't take your flamebait Matthew, though I have to say I never thought anyone would get offended when all I did was quoting previous statements, and sincerely pointing out that my reason for that was to show Jon that it had indeed been promised full networking support.
Now, things change and I understand that - which is why I said I'm not pointing fingers. To make sure *no one* misunderstands. Still, you resort to flames - very professional, and thank you.
I'm out of here.
#17
In any case I think you had a valid point. Though since you didn't detail what it was aimed at it did look as though you meant it negatively. Also the rest of my post wasn't directed at you, was directly responding to the ideas that GG has somehow undermined Melv, if you saw it as flamebait then I apologize... I despize flaming and really dislike those who incite it.
06/02/2006 (11:52 am)
It was not flamebait... Unless you were looking for it to be. I simply saw you quote people and reference there names and then say you weren't pointing fingers. To me thats as close as it gets to pointing a finger on a post, not to say that you ment it in a malicious way. Considering you only posted a couple sentences after the quotes I wasn't exactly sure what your motive was. In any case I think you had a valid point. Though since you didn't detail what it was aimed at it did look as though you meant it negatively. Also the rest of my post wasn't directed at you, was directly responding to the ideas that GG has somehow undermined Melv, if you saw it as flamebait then I apologize... I despize flaming and really dislike those who incite it.
#18
OH OH OH! I want that! :)
That would be looove for a noob like me!!!
(yeah i know i can copy "snippets" to add, but i dont understand what i am doing really. Since i dont understand what i am doing, and cant see if it looks "right" - its kinda hard to find out what i do wrong when i mez stuff up.)
*Dreaming of an interface where TGB has 50+ different buttons that can do/acces all functions. Where all script parts are included under, where i could just click, drag, dropp and add values, sprites, textures, maps or whatever....*
mmmmm.... Can i have that for christmas Santa Garage Games? :)
(yeah its written like a joke, but the fact is: i would LOVE if it could be as easy as that) he he
06/02/2006 (12:18 pm)
Quote: "The engine is still not a drag n' drop engine....."OH OH OH! I want that! :)
That would be looove for a noob like me!!!
(yeah i know i can copy "snippets" to add, but i dont understand what i am doing really. Since i dont understand what i am doing, and cant see if it looks "right" - its kinda hard to find out what i do wrong when i mez stuff up.)
*Dreaming of an interface where TGB has 50+ different buttons that can do/acces all functions. Where all script parts are included under, where i could just click, drag, dropp and add values, sprites, textures, maps or whatever....*
mmmmm.... Can i have that for christmas Santa Garage Games? :)
(yeah its written like a joke, but the fact is: i would LOVE if it could be as easy as that) he he
#19
06/02/2006 (12:21 pm)
Hehe yeah I know what you mean Hege... I love how easy TGB has gotten. Though we never want to create quite the same type of engine that GameMaker or others like it has, we are working on making every step even easier... one our main hopes is that the tutorials that we now provide will teach enough of basic scripting and Level Builder usage that you should be able to do whatever you want :)
#20
Maybe a resource or TDN article showing how one might implement a custom network "ghost" object would suffice (at some point down the road).
06/02/2006 (12:38 pm)
I can see why some might be upset over this, but I'm definitely in support of the tools being priority. This is already the best 2D engine feature-wise and the tools put it way over the top. Maybe a resource or TDN article showing how one might implement a custom network "ghost" object would suffice (at some point down the road).
Torque Owner NoobGank
Thanks