Calling all TGE Fanbois: Turning TGEA into a true MMO framework
by Dr Doolittle · in General Discussion · 01/06/2009 (10:48 pm) · 20 replies
TGE/TGEA has always been a great tool for building multiplayer FPS, even RTS, but what about MMO's? MMOKIT was a decent attempt at an MMO, no doubt about it! And my hats of to them!
But, I believe a few things have changed in the industry over the last few years. One of the most important things has been the recognition that design matters, a lot, then QA, then Community. One might have a well funded game, but if it plays like crap, is as stable an early Win 95 RC, and theres no effort at community management, then forget about it!
The other important change, and this is relevant to Torque, is the evolution of MMOG frameworks, chief among them, SUN Micro's Darkstar. A quick and dirty Darkstar/Torque hybrid has already been done, with TGEA as the client, and multiple TGEA servers on each Darkstar node, with Darkstar acting like the Master Server and basically maintaining the PW(Persistent World) framework.
Ive noted some posts on the Forums, namely Bryce Wiener's, who has demonstrated 250 users on a single server(prolly a P4 with 1GB RAM, from 2004), with 5 multiple zones. So it can be done! 64, schmixty fooey!
Well here's what we want to do. We're an Indie studio at Bangalore India, partially funded by US and locally linked people, and we want to make an MMOG which employs TGEA, in tandem with Darkstar as the PW framework. We have a solid and interesting design, through some of the best content designers around. We have amazing artwork from solid artists and modellers and decent animators. But our challenge is integrating TGEA into Darkstar, with TGEA servers on each Darkstar node. We're getting consultancy assistance from 3rd parties on our early(non MMO) prototype, as well as some pointers from the same party regarding MMO scalability feasibility, but I'd like to open this discussion to the public, at large, as well.
The good news: Since Darkstar is GPL, whatever we do will be in the public domain, as far as Darkstar goes. And we will likely put up an MMOKIT like product on Garagegames, with support, etc, for other would be developers of TGEA based MMO's, who want some paid support, if all goes well, in association with, and pending further discussion with Garagegames and our consultancy partners.
In a nutshell then, our project goals are:
1. Deliver a functional TGEA/Darkstar hybrid, with TGEA servers on each Darkstar node, and Darkstar as the PW framework, with a maximum of 256 users per physical server(without having much resultant slowing down)
2. Use a toolset such as Plastic Games Tweaker + Torsion + Content Packs to deliver upon design features, gradually working with these, and on these toolsets, and perhaps making some of our own, to deliver something roughly matching Unreal's excellent modding and visual scripting feature, Kizmet.
3. Make the hybrid framework production ready and rock solid, tackling issues such as scalability, stability, and security(adding logging, secure communication wheres its essential to security, databases - MySQL/MSSQL), and so on.
4. Release the Open Source developments on the Darkstar front to the Public. Release the Torque side of things as a content pack, with approval from Garagemes, in association with our partners, as the case may be.
5. Assist the community with the evolution of TGEA into a threadsafe and multithreaded application, where multithreaded operation will deliver performance benefits, and to take advantage of newer multi-core processors.
What I want to hear back from all of you is what you feel regarding this attempt on our part to turn TGEA into a viable MMO component, much like what has been done with Unreal. Do you think we're nuts? Cant be done? Can be done? I've done it! Would love to hear back from all of you, and would love this project to deliver upon its promise, and give a fillip to this wonderful community of Indie Game Programmers!
Regards,
Nerfster(aka Bodhisattva)
www.mangaldesh.com
But, I believe a few things have changed in the industry over the last few years. One of the most important things has been the recognition that design matters, a lot, then QA, then Community. One might have a well funded game, but if it plays like crap, is as stable an early Win 95 RC, and theres no effort at community management, then forget about it!
The other important change, and this is relevant to Torque, is the evolution of MMOG frameworks, chief among them, SUN Micro's Darkstar. A quick and dirty Darkstar/Torque hybrid has already been done, with TGEA as the client, and multiple TGEA servers on each Darkstar node, with Darkstar acting like the Master Server and basically maintaining the PW(Persistent World) framework.
Ive noted some posts on the Forums, namely Bryce Wiener's, who has demonstrated 250 users on a single server(prolly a P4 with 1GB RAM, from 2004), with 5 multiple zones. So it can be done! 64, schmixty fooey!
Well here's what we want to do. We're an Indie studio at Bangalore India, partially funded by US and locally linked people, and we want to make an MMOG which employs TGEA, in tandem with Darkstar as the PW framework. We have a solid and interesting design, through some of the best content designers around. We have amazing artwork from solid artists and modellers and decent animators. But our challenge is integrating TGEA into Darkstar, with TGEA servers on each Darkstar node. We're getting consultancy assistance from 3rd parties on our early(non MMO) prototype, as well as some pointers from the same party regarding MMO scalability feasibility, but I'd like to open this discussion to the public, at large, as well.
The good news: Since Darkstar is GPL, whatever we do will be in the public domain, as far as Darkstar goes. And we will likely put up an MMOKIT like product on Garagegames, with support, etc, for other would be developers of TGEA based MMO's, who want some paid support, if all goes well, in association with, and pending further discussion with Garagegames and our consultancy partners.
In a nutshell then, our project goals are:
1. Deliver a functional TGEA/Darkstar hybrid, with TGEA servers on each Darkstar node, and Darkstar as the PW framework, with a maximum of 256 users per physical server(without having much resultant slowing down)
2. Use a toolset such as Plastic Games Tweaker + Torsion + Content Packs to deliver upon design features, gradually working with these, and on these toolsets, and perhaps making some of our own, to deliver something roughly matching Unreal's excellent modding and visual scripting feature, Kizmet.
3. Make the hybrid framework production ready and rock solid, tackling issues such as scalability, stability, and security(adding logging, secure communication wheres its essential to security, databases - MySQL/MSSQL), and so on.
4. Release the Open Source developments on the Darkstar front to the Public. Release the Torque side of things as a content pack, with approval from Garagemes, in association with our partners, as the case may be.
5. Assist the community with the evolution of TGEA into a threadsafe and multithreaded application, where multithreaded operation will deliver performance benefits, and to take advantage of newer multi-core processors.
What I want to hear back from all of you is what you feel regarding this attempt on our part to turn TGEA into a viable MMO component, much like what has been done with Unreal. Do you think we're nuts? Cant be done? Can be done? I've done it! Would love to hear back from all of you, and would love this project to deliver upon its promise, and give a fillip to this wonderful community of Indie Game Programmers!
Regards,
Nerfster(aka Bodhisattva)
www.mangaldesh.com
About the author
#2
01/08/2009 (4:22 am)
So youre going to rip out the TNL portion and implement your own networking. Thats a lot of work. I wish I had the engineering resources and the confidence to put something together and be confident it going to be rock solid stable and production ready .. But then Im sure you'll have top notch QA and testing for 1-2 years including stress tests, stability and exploit and bug hunting, to make the server production ready and comparable to a relatively mature 8-9 year old tech in TGE/TGEA. But then again, Im a TGE fan :)
#3
You might want to take a look at lineage 2 private server emulator l2j. It is architecturaly not the best thing, but you can get some insight on how the communication works. The game protocol is really lightweight, but it works perfectly for the game. It took our programmer about one month to develop client networking layer in our current engine. I expect similar timeframe for implementing it into TGEA.
It is not very hard to implement networking in client. The server side is much greater challenge, but it can be done, and it can perfectly work. You don't have to be genius to do that. Now in the time of seamless MMO games, using TGEA as server is such a waste of time, talent and resourcers. The best thing you can do is to use tools for what they've been created. Use TGEA as 3D engine, Oracle as SQL server, Darkstar(maybe) as game server.
If you stick to TGE networking, you mail fail because:
- the game will not be good enough to attract enough players(not enough players supported in a zone, no seamless world, loading time while changing zones, problems with changing zones)
- you will spend too much time in improving your technology to the point it could be suitable for MMO that you will waste too much of your resources
- as far as I know, Darkstar isn't already implemented in any published MMO. This a big risk. You may come upon unpredicted problems during development, but even worse, after publishing. This could cost you your head.
01/08/2009 (5:00 am)
Well it doesn't matter how old TGEA tech is when it is not good enough for a good MMO game. You might want to take a look at lineage 2 private server emulator l2j. It is architecturaly not the best thing, but you can get some insight on how the communication works. The game protocol is really lightweight, but it works perfectly for the game. It took our programmer about one month to develop client networking layer in our current engine. I expect similar timeframe for implementing it into TGEA.
It is not very hard to implement networking in client. The server side is much greater challenge, but it can be done, and it can perfectly work. You don't have to be genius to do that. Now in the time of seamless MMO games, using TGEA as server is such a waste of time, talent and resourcers. The best thing you can do is to use tools for what they've been created. Use TGEA as 3D engine, Oracle as SQL server, Darkstar(maybe) as game server.
If you stick to TGE networking, you mail fail because:
- the game will not be good enough to attract enough players(not enough players supported in a zone, no seamless world, loading time while changing zones, problems with changing zones)
- you will spend too much time in improving your technology to the point it could be suitable for MMO that you will waste too much of your resources
- as far as I know, Darkstar isn't already implemented in any published MMO. This a big risk. You may come upon unpredicted problems during development, but even worse, after publishing. This could cost you your head.
#4
Hey, I appreciate the advice. Its free, and I think its meant in all honesty. I think you might just be hitting the nail close to a very sore point, ie, TGEA's non-seamless zone/mission based server structure. I think in the long run, it might be a good idea to took at using TGEA just as a 3d engine, and use a completely different server platform.
However, I think its worthwhile to try out a quick and dirty TGEA client server setup within Darkstar, try and see how scalable it is, then if it doesnt work out and is a real dampener, your internal QA team telling you it sucks, pull it out of the server portion, implement your own server, and use that. One of our consultants told me it might be a case of trying to push a square peg into a round hole, could be painful!
I think I'll give it a try, then see how it goes. I think its 30-70, ie, 3/10 that TGEA scales up for upto 300+ players per server on a single machine, without much slowing, and shows good stability and performance, and for the effort saved as compared to going for a server engine, and 7/10, we go for our own server, whole hog.
Now please note, Im just an entrepreneur, and a content writer and designer, when it comes to programming, Im quite skilled, but Im hardly a game programming and network programming guru. I hear that TGEA does not make use of multithreading, though a good GPU takes care a lot of the graphics stuff. How much of a hit will that cause as compared to multi-core ready, multithreaded and threadsafe engines that are out there? Name a few? Is GG going for a threadsafe TGEA?
Thanks for all the kind advice, even it isnt exactly what I want to hear, Lamiznik and Pacol.
Thanks
Nerfster
01/08/2009 (5:13 am)
Lamiznik: Hey, I appreciate the advice. Its free, and I think its meant in all honesty. I think you might just be hitting the nail close to a very sore point, ie, TGEA's non-seamless zone/mission based server structure. I think in the long run, it might be a good idea to took at using TGEA just as a 3d engine, and use a completely different server platform.
However, I think its worthwhile to try out a quick and dirty TGEA client server setup within Darkstar, try and see how scalable it is, then if it doesnt work out and is a real dampener, your internal QA team telling you it sucks, pull it out of the server portion, implement your own server, and use that. One of our consultants told me it might be a case of trying to push a square peg into a round hole, could be painful!
I think I'll give it a try, then see how it goes. I think its 30-70, ie, 3/10 that TGEA scales up for upto 300+ players per server on a single machine, without much slowing, and shows good stability and performance, and for the effort saved as compared to going for a server engine, and 7/10, we go for our own server, whole hog.
Now please note, Im just an entrepreneur, and a content writer and designer, when it comes to programming, Im quite skilled, but Im hardly a game programming and network programming guru. I hear that TGEA does not make use of multithreading, though a good GPU takes care a lot of the graphics stuff. How much of a hit will that cause as compared to multi-core ready, multithreaded and threadsafe engines that are out there? Name a few? Is GG going for a threadsafe TGEA?
Thanks for all the kind advice, even it isnt exactly what I want to hear, Lamiznik and Pacol.
Thanks
Nerfster
#5
Trust me, you won't be able to scael TGEA server to use seamless world. There are many things that need to be solved.For example what if one player on one zone's corner is shooting arrow on a player over other zone's corner? Which server would decide what happens? What if you standing in one corner shoot an arrow on mob on the other corner? Which server has the last word? You will come onto other questions like this, and your head would probably explode.
If you have cheap programmers in Bangalore, you may go for trial-failure-decision method. But it is too expensive for most of other companies, so we rather go for think-evaluate-decision method. TGEA is pretty well written, it is not that hard to extract a layer from it and use something else.
When it comes to multithreading, you may want to multithread some of the calculations, but I think multithreading is rather a title specifical, than engine specifical. You may want to develop your own multithreading solution on the engine itself and optimise is for your game. As far as I know, there is no specifical need for multithreading in MMO clients, because AI and other stuff is calculated on the server. When you ask about multithreading on the TGEA server, then I don't know. In most MMO game servers, the server load is rather split vertically than horizontally. AI/NPC server is running on different process(maybe machine) than game server is and specifical server application is using multithreading inside itself as well. You probably won't be able to achieve this in TGEA, but I will repeat myself: you need to know what exactly you want before you start to make any technical decision at all. Anyway waiting until GG implements multithreading into TGEA might turn out into major disappointment.
01/08/2009 (5:36 am)
I don't say it is definetely. But when you think about making a MMO, make at least basic technical design first. Is 300 players in one zone enough? Will it satisfy your gamers? Do you want to have seamless zones or not? That is all you NEED to know before you make any technicall decision.Trust me, you won't be able to scael TGEA server to use seamless world. There are many things that need to be solved.For example what if one player on one zone's corner is shooting arrow on a player over other zone's corner? Which server would decide what happens? What if you standing in one corner shoot an arrow on mob on the other corner? Which server has the last word? You will come onto other questions like this, and your head would probably explode.
If you have cheap programmers in Bangalore, you may go for trial-failure-decision method. But it is too expensive for most of other companies, so we rather go for think-evaluate-decision method. TGEA is pretty well written, it is not that hard to extract a layer from it and use something else.
When it comes to multithreading, you may want to multithread some of the calculations, but I think multithreading is rather a title specifical, than engine specifical. You may want to develop your own multithreading solution on the engine itself and optimise is for your game. As far as I know, there is no specifical need for multithreading in MMO clients, because AI and other stuff is calculated on the server. When you ask about multithreading on the TGEA server, then I don't know. In most MMO game servers, the server load is rather split vertically than horizontally. AI/NPC server is running on different process(maybe machine) than game server is and specifical server application is using multithreading inside itself as well. You probably won't be able to achieve this in TGEA, but I will repeat myself: you need to know what exactly you want before you start to make any technical decision at all. Anyway waiting until GG implements multithreading into TGEA might turn out into major disappointment.
#6
Maurina mentions the 128 player cap specifically, but does say that one can go further. With regard to multithreading, I think using thread pools for the networking portion might be an idea ..
Thanks,
Nerfster
01/08/2009 (6:15 am)
I think you raise very valid points Lamiznik. Our design calls for allowing 256 players per zone, with perhaps 10-15 on screen at once, without much slowing down. But 256 is not a hard cap, 500 would be. So we are looking at a zone based setup, from the start. So thats where TGEA server becomes relevant, since its already been done!Maurina mentions the 128 player cap specifically, but does say that one can go further. With regard to multithreading, I think using thread pools for the networking portion might be an idea ..
Thanks,
Nerfster
#7
As a non-licensee, I'm not sure lamiznik is in the best position to note what teams can and cannot scale with TGEA. But the points are sound when it comes to initial design methodologies. A team does need to see what the overall goals of their design are and come up with practical means of implementing them.
01/08/2009 (7:36 am)
TGEA (and most other engine's) level/mission-based structure can be a limiting factor in terms of MMO's like lamiznik is discussing, where paged zoning is important. For those implementations, some rearchitecting would be necessary on both the client and server side to add such support. As to how difficult it would be depends on your implementation.As a non-licensee, I'm not sure lamiznik is in the best position to note what teams can and cannot scale with TGEA. But the points are sound when it comes to initial design methodologies. A team does need to see what the overall goals of their design are and come up with practical means of implementing them.
#8
I've seen the seamless/scaling talk derail open source MMO framework projects before. This is a pity as something that was flexible and could handle small/medium (population-wise) worlds and greatly shortened the indie dev would likely change the world. Torque is just fine for those small worlds and the added advantage of TNL would be a boon to those worlds with an FPS style of play.
01/08/2009 (7:53 am)
This is going to sound either naive or arrogant, but are the issues being discussed in this thread really important? Firstly, is it not at all clear that players are clamoring for "seamless". Secondly, >256 players per zone is an issue that indie developers are not likely to run into. I'd be happy with a flexible framework that worked for small worlds. So would most other hobbyists and indies interested in persistent worlds. I've seen the seamless/scaling talk derail open source MMO framework projects before. This is a pity as something that was flexible and could handle small/medium (population-wise) worlds and greatly shortened the indie dev would likely change the world. Torque is just fine for those small worlds and the added advantage of TNL would be a boon to those worlds with an FPS style of play.
#9
What happens if what you do becomes popular and you suddenly get a lot more players than you could have imagined? Do you just start turning them away? Deal with the people whining because the server is full? Or scramble to try and find a solution if what you're already using isn't easily scalable?
I'm all for an MMO framework for TGEA. I'd probably even use it. But those that would use it should be prepared for the "what if" or at least well aware of it.
01/08/2009 (8:03 am)
While I am one of those more interested in more of a small scale persistent world use as you say, David S, I still believe that you have to keep the players per zone issue in mind.What happens if what you do becomes popular and you suddenly get a lot more players than you could have imagined? Do you just start turning them away? Deal with the people whining because the server is full? Or scramble to try and find a solution if what you're already using isn't easily scalable?
I'm all for an MMO framework for TGEA. I'd probably even use it. But those that would use it should be prepared for the "what if" or at least well aware of it.
#10
The thing about fixed zones and 256 player zones, even if you get there, though, is, even with very good design, lots of instantiation, you're talking about a server farm supporting say a max of 20,000 concurrent players, because the 'cell', 'area' size is pretty high. Whereas, with some of the commercial engines, cell size is really small, and the PW framework load balances cells dynamically across the entire server farm, optimizing server load.
Perhaps one could something similar with TGEA, in two ways. An easy way and a hard way. IOW, the PW master server and framework blocks players from entering a crowded zone/mission, then spins one up on a different server, directing players to the new zone, provided they arent being summoned there or part of a team there, while running the current mission, till it winds down, and when zone numbers are low, perhaps spinning up a ready to go instantiation zone, or a low density zone, on the original server, and then eventually shutting down the original mission/zone.
The hard way would be to divy up the game world into small areas/cells, say 50 meters by 50 meters, dynamically load balance, across the server farm, and re-architecture the Engine, and the PW framework, to cater to this. This would be the ideal solution, IMO, but then you run into questions like what do you do with Datablocks, do you reload them every time you move out from an area into another. It would require a solid redesign effort and build effort from people very experienced with the TGE ...
In MMOG design, what you do is, in the pre-production stage, you do an initial design, then a design review, with a simplistic prototype in hand perhaps, then another redesign, then build, build, till design freeze, and alpha, then youre into full fledged production and beta testing, and the real *fun* starts lol.
Well right, we're working on our design feature demonstration prototype lol, let me get back to that. First things, first! Its very early days yet.
David (Montgomery) Sir, thanks for your kind advice!
What would really help when it comes to MMOG creation using TGEA as a component would be a visual scripting and content addition tool(AI's, pathing, complext tasks, questing), something like Kizmet. Lets see what we can do there. I think theres another team called Ubiqvision working on a 3d RPG kit, it looks good, lets see what the toolsets are. Tweaker from Plastic Games also has the potential to evolve into a MOD kit, hopefully.
Regards,
Back to work for me!
Laters,
Nerfster(Bodhisattva)
01/08/2009 (8:21 am)
David S., thats a valid point there. Vanguard had seamless zones, and it was a bit of a pain running into a zone paging area sometimes and, and getting hit with lag, and the rest of the fun team including trains, people testing zone paging, discoes, weird behaviour like going through half a city zone, before getting paged back, and what not.The thing about fixed zones and 256 player zones, even if you get there, though, is, even with very good design, lots of instantiation, you're talking about a
Perhaps one could something similar with TGEA, in two ways. An easy way and a hard way. IOW, the PW master server and framework blocks players from entering a crowded zone/mission, then spins one up on a different server, directing players to the new zone, provided they arent being summoned there or part of a team there, while running the current mission, till it winds down, and when zone numbers are low, perhaps spinning up a ready to go instantiation zone, or a low density zone, on the original server, and then eventually shutting down the original mission/zone.
The hard way would be to divy up the game world into small areas/cells, say 50 meters by 50 meters, dynamically load balance, across the server farm, and re-architecture the Engine, and the PW framework, to cater to this. This would be the ideal solution, IMO, but then you run into questions like what do you do with Datablocks, do you reload them every time you move out from an area into another. It would require a solid redesign effort and build effort from people very experienced with the TGE ...
In MMOG design, what you do is, in the pre-production stage, you do an initial design, then a design review, with a simplistic prototype in hand perhaps, then another redesign, then build, build, till design freeze, and alpha, then youre into full fledged production and beta testing, and the real *fun* starts lol.
Well right, we're working on our design feature demonstration prototype lol, let me get back to that. First things, first! Its very early days yet.
David (Montgomery) Sir, thanks for your kind advice!
What would really help when it comes to MMOG creation using TGEA as a component would be a visual scripting and content addition tool(AI's, pathing, complext tasks, questing), something like Kizmet. Lets see what we can do there. I think theres another team called Ubiqvision working on a 3d RPG kit, it looks good, lets see what the toolsets are. Tweaker from Plastic Games also has the potential to evolve into a MOD kit, hopefully.
Regards,
Back to work for me!
Laters,
Nerfster(Bodhisattva)
#11
The MMOkit actually does things differently. It compiles Torque as a static library and uses it seamlessly with python. It then exploits the Twisted framework for the networking backend.
Torque's standard networking will just not cut it. Apart from just integrating it with Darkstar (which like another poster pointed out hasn't been commercially proven yet), you'd need to make a fair deal of changes to a lot of things core to TGE(A)
I don't know if you meant it, but everything will be in the public domain. I'm pretty certain there's a clause in the GNU GPL v3 which prevents you from integrating proprietary (non GPL-ed) software with GPL code, it doesn't just limit you to not making changes to the GPL code itself. This would seriously come into conflict with GG's licensing terms - even the commercial license does not allow you to release the TGE(A) source to the public. If it were LGPL, there wouldn't be any issues.
Don't think so. Even if you do implement a different scheme, you'd need to spend a considerable amount of time testing out the framework, as I'm certain you'd have to remove a fair deal of code that's already in there and might not help your cause. Once you're done refactoring the current networking layer to suit your zoning needs, you'd no longer have 9 year old technology to bank on. :)
01/08/2009 (8:28 am)
You'd definitely have a market for your idea, since most people who purchase TGE(A) want to make an MMO right away! That apart, there have been some decent attempts at making modifications to the TGE core to make it 'MMO compliant', though most attempts have been mere hacks.The MMOkit actually does things differently. It compiles Torque as a static library and uses it seamlessly with python. It then exploits the Twisted framework for the networking backend.
Torque's standard networking will just not cut it. Apart from just integrating it with Darkstar (which like another poster pointed out hasn't been commercially proven yet), you'd need to make a fair deal of changes to a lot of things core to TGE(A)
Quote:The good news: Since Darkstar is GPL, whatever we do will be in the public domain, as far as Darkstar goes.
I don't know if you meant it, but everything will be in the public domain. I'm pretty certain there's a clause in the GNU GPL v3 which prevents you from integrating proprietary (non GPL-ed) software with GPL code, it doesn't just limit you to not making changes to the GPL code itself. This would seriously come into conflict with GG's licensing terms - even the commercial license does not allow you to release the TGE(A) source to the public. If it were LGPL, there wouldn't be any issues.
Quote:But then Im sure you'll have top notch QA and testing for 1-2 years including stress tests, stability and exploit and bug hunting, to make the server production ready and comparable to a relatively mature 8-9 year old tech in TGE/TGEA
Don't think so. Even if you do implement a different scheme, you'd need to spend a considerable amount of time testing out the framework, as I'm certain you'd have to remove a fair deal of code that's already in there and might not help your cause. Once you're done refactoring the current networking layer to suit your zoning needs, you'd no longer have 9 year old technology to bank on. :)
Quote:Anyway waiting until GG implements multithreading into TGEA might turn out into major disappointment.There have been a couple of decent attempts to write make TGE multi-threaded. There weren't any major improvements though. In fact, there was so much overhead that in some cases it just reduced performance. I dont know about TGEA much (dont own it) but I do know that forcing multi-threading into it isn't by any means trivial. I don't even know if its on GG's radar (and I don't blame them too)
#12
Hey thats an important point. Now, Darkstar will be released in two flavours. The Client side API, etc, will be BSD, so incorporate code, as you like, and release through GG, with their approval, as far as I understand it, when it comes to the client.
The server side will be released under GPL, but there will be other flavours as well, perhaps including a small license fee for a commercial license, legal indemnification, support, etc. So one would perhaps be careful about doing mix and match with code, willy nilly, but I think it should be possible to keep a clear dilineation between Darkstar server code base(in Java), TGE Server code base, and so on.
Quote from SUN devs/admins:
Would be glad to learn more about what you think on this topic, as well as on multithreading, ie, where its relevant, easily implemented, etc.
Regards,
Nerfster
01/08/2009 (9:05 am)
Quote:I don't know if you meant it, but everything will be in the public domain. I'm pretty certain there's a clause in the GNU GPL v3 which prevents you from integrating proprietary (non GPL-ed) software with GPL code, it doesn't just limit you to not making changes to the GPL code itself. This would seriously come into conflict with GG's licensing terms - even the commercial license does not allow you to release the TGE(A) source to the public. If it were LGPL, there wouldn't be any issues.
Hey thats an important point. Now, Darkstar will be released in two flavours. The Client side API, etc, will be BSD, so incorporate code, as you like, and release through GG, with their approval, as far as I understand it, when it comes to the client.
The server side will be released under GPL, but there will be other flavours as well, perhaps including a small license fee for a commercial license, legal indemnification, support, etc. So one would perhaps be careful about doing mix and match with code, willy nilly, but I think it should be possible to keep a clear dilineation between Darkstar server code base(in Java), TGE Server code base, and so on.
Quote from SUN devs/admins:
Quote:
Sun has stated in its FAQ:
Q: Does Darkstar being GPLd mean I have to GPL my game code?
A: No. It is our best belief that using Darkstar in no way obligates you to release your own code as GPL as long as it is just code that runs as a Darkstar application. If you make changes to the Darkstar codebase itself, then yes you are obligated to share those changes with the community.
Would be glad to learn more about what you think on this topic, as well as on multithreading, ie, where its relevant, easily implemented, etc.
Regards,
Nerfster
#13
Thats exactly what I said. Let's say you use a GPL library to write one application and then use that to integrate into a separate client (based on TGEA for instance), then you'd be free to do as you wish (as long as you release the server application to the public). The problem will come up when you try to mix Darkstar with TGEA on one side, say writing a backend for the network that distributes on some sever clusters for instance. That way, your entire library, which links with the GPL library needs to be open-source.
The key here is linking with a library, not interacting with a GPL application - the latter would be perfectly alright (and is what, I suppose, the FAQ refers to) but the former might cause headaches
The BSD license of course removes all of those limitations.
Firstly, as far as multi-threading goes, let us assume that you're planning to 'multi-thread' the client. That would mean that you'd need to logically split up the update process into multiple threads interfacing with Torque's memory manager and AFAIK Torque's memory manager isn't thread-safe (and I don't think its just limited to the memory manager alone, a number of other classes aren't thread-safe too) So you'd need to make some considerable base changes there. From what I've learned with my use with TGE, its not really advisable to dig it up and write multi-threading into it. It definitely isn't a trivial task by any means.
Pretty heavy undertaking, and I would advise taking a different route and avoiding it altogether. There really shouldn't be too much change if you're using TGEA as-is (with regards to threads atleast) for the client.
01/09/2009 (12:33 am)
Quote:
Sun has stated in its FAQ:
Q: Does Darkstar being GPLd mean I have to GPL my game code?
A: No. It is our best belief that using Darkstar in no way obligates you to release your own code as GPL as long as it is just code that runs as a Darkstar application. If you make changes to the Darkstar codebase itself, then yes you are obligated to share those changes with the community.
Thats exactly what I said. Let's say you use a GPL library to write one application and then use that to integrate into a separate client (based on TGEA for instance), then you'd be free to do as you wish (as long as you release the server application to the public). The problem will come up when you try to mix Darkstar with TGEA on one side, say writing a backend for the network that distributes on some sever clusters for instance. That way, your entire library, which links with the GPL library needs to be open-source.
The key here is linking with a library, not interacting with a GPL application - the latter would be perfectly alright (and is what, I suppose, the FAQ refers to) but the former might cause headaches
The BSD license of course removes all of those limitations.
Firstly, as far as multi-threading goes, let us assume that you're planning to 'multi-thread' the client. That would mean that you'd need to logically split up the update process into multiple threads interfacing with Torque's memory manager and AFAIK Torque's memory manager isn't thread-safe (and I don't think its just limited to the memory manager alone, a number of other classes aren't thread-safe too) So you'd need to make some considerable base changes there. From what I've learned with my use with TGE, its not really advisable to dig it up and write multi-threading into it. It definitely isn't a trivial task by any means.
Pretty heavy undertaking, and I would advise taking a different route and avoiding it altogether. There really shouldn't be too much change if you're using TGEA as-is (with regards to threads atleast) for the client.
#14
The RPC is sort of complicated for this because the flow is like
Request:
TGE Client --> TGE Server --> Darkstar
Response:
Darkstar --> TGE Server --> Client
With the TGE server playing middle man all the time for requests that need to happen on the Darkstar side of things. The other disadvantage, which was probably already pointed out, is that stuff that happens in Darkstar can in theory be spread out among N servers, but the portion of the simulation that occurs in TGE cannot.
This was really quick and dirty, but ultimately I think the way to go is the much more difficult option of going with a pure darkstar server and making whatever changes are needed to either replicate TNL or rip it out and replace it entirely.
01/09/2009 (8:42 am)
I have personally implemented a combination of TGE/Darkstar server + TGE Client. I spent about two weeks on it, about 90% of the time integrating and debugging the (at the time very beta) c client for Darkstar and maybe a few days rolling together some RPC to get all the stuff on the server side to talk.The RPC is sort of complicated for this because the flow is like
Request:
TGE Client --> TGE Server --> Darkstar
Response:
Darkstar --> TGE Server --> Client
With the TGE server playing middle man all the time for requests that need to happen on the Darkstar side of things. The other disadvantage, which was probably already pointed out, is that stuff that happens in Darkstar can in theory be spread out among N servers, but the portion of the simulation that occurs in TGE cannot.
This was really quick and dirty, but ultimately I think the way to go is the much more difficult option of going with a pure darkstar server and making whatever changes are needed to either replicate TNL or rip it out and replace it entirely.
#15
Id be interested in hearing what you think would be a decent design for an implementation for Darkstar + TGE hybrid, with multiple TGE servers on each Darkstar node, assuming that we would want to stick to using TGE/TGEA server as well. One would have to factor in transitioning the clients connectivity through from the initial Login GUI(which would have to be seperate server(s)), then a character select/creation mission server(s), then the real mcoy, the zone servers, one would suppose
Looking forward to your reply,
Regards,
Nerfster(Bodhisattva)
01/09/2009 (9:46 am)
Hey well done Tigeba! Replacing TNL would be quite a big task, Id imagine!Id be interested in hearing what you think would be a decent design for an implementation for Darkstar + TGE hybrid, with multiple TGE servers on each Darkstar node, assuming that we would want to stick to using TGE/TGEA server as well. One would have to factor in transitioning the clients connectivity through from the initial Login GUI(which would have to be seperate server(s)), then a character select/creation mission server(s), then the real mcoy, the zone servers, one would suppose
Looking forward to your reply,
Regards,
Nerfster(Bodhisattva)
#17
01/11/2009 (9:55 am)
Yep lots of great developers have made it really big in Europe/US, from the ex-Soviet bloc. Kaspersky, ProEngineer, Bitfold too, you name it! Theve done very well for themselves. 
#18
01/12/2009 (1:01 am)
Would it be practical to compile TGEA as a library on the server-side, and use JNI as an interface to the torque functionality from within an app written on top of darkstar? I have never done something like this, but it seems like it would work.
#19
Has anyone ever looked into or thought about tying TGE(A) with SmartFoxServer? I know people are doing this with the Unity client.
SmartFoxServer (http://www.smartfoxserver.com/) seems to have no problem handling the kinds of loads you'd want to have. It's the technology behind Club Penguin for example, so you know it's got some oomph to it.
It's also pretty cheap, and free to use as long as you don't exceed I think a 20 player cap - which would not be a problem at all for development of a proof of concept.
One negative though is that it's room based. However I think you could build your game world to have different zones, and treat each one as a "room", whether it be a city, a dungeon, a building or an outdoor area.
The other interesting server technology out there is from Multiverse. Their client is weak as are their tools, but their server really isn't that bad, especially considering the costs. If someone were to set up a Torque based client for Multiverse, it would be an interesting combination IMO.
04/15/2009 (7:47 pm)
Bumping an old thread...Has anyone ever looked into or thought about tying TGE(A) with SmartFoxServer? I know people are doing this with the Unity client.
SmartFoxServer (http://www.smartfoxserver.com/) seems to have no problem handling the kinds of loads you'd want to have. It's the technology behind Club Penguin for example, so you know it's got some oomph to it.
It's also pretty cheap, and free to use as long as you don't exceed I think a 20 player cap - which would not be a problem at all for development of a proof of concept.
One negative though is that it's room based. However I think you could build your game world to have different zones, and treat each one as a "room", whether it be a city, a dungeon, a building or an outdoor area.
The other interesting server technology out there is from Multiverse. Their client is weak as are their tools, but their server really isn't that bad, especially considering the costs. If someone were to set up a Torque based client for Multiverse, it would be an interesting combination IMO.
#20
TGEA is nothing like what you would need for an MMO server. You would be talking about 2 entirely different things. TGEA can be used for a client but it would need to be cleaned up and probably would be best to remove anything that would no longer be needed for an actual client.
While I have never seen the actual client code for WOW: The Burning Crusade, I did spend over a year coding on a branch of a now defunct emulator. I myself have thought about using TGEA as a client but using the existing emu with modifications to create an MMO. The emu I worked on was used by hundreds of private emu hosters. The network code itself would handle 1000+ players at any given time. I ran the Wow client, Mysql, Login Server and Account Server on my home pc (Quad Core) and had close to 800+ players over FIOS for months when I finally started getting stable builds together.
However, Working on the server side became a breeze.. The client side would be a stretch for me as i'm not a level builder or an artist. I can't model worth crap.
But anyway, look at the source code yourself. If you have ever played WOW, the code that works very simular to WOW including changing or transitioning of levels, handling quests, particles and anything else you ever wanted to know. Other than mentioning an Emu for a hugely popular MMORPG, there really are no MMO servers that you can actually take a look at. This is the only way I know for anyone to really get an Idea of what it takes to build an MMORPG from the server side of things.
Download V6 source;
AngelEmu: code.google.com/p/angelemu/
If you want an idea of how the tables were setup, you can download the tbc database and scan through it. In the V6 source is the entire server, including awesome network code, login server, accounts server ect.
Chris
04/17/2009 (1:10 am)
Hello,TGEA is nothing like what you would need for an MMO server. You would be talking about 2 entirely different things. TGEA can be used for a client but it would need to be cleaned up and probably would be best to remove anything that would no longer be needed for an actual client.
While I have never seen the actual client code for WOW: The Burning Crusade, I did spend over a year coding on a branch of a now defunct emulator. I myself have thought about using TGEA as a client but using the existing emu with modifications to create an MMO. The emu I worked on was used by hundreds of private emu hosters. The network code itself would handle 1000+ players at any given time. I ran the Wow client, Mysql, Login Server and Account Server on my home pc (Quad Core) and had close to 800+ players over FIOS for months when I finally started getting stable builds together.
However, Working on the server side became a breeze.. The client side would be a stretch for me as i'm not a level builder or an artist. I can't model worth crap.
But anyway, look at the source code yourself. If you have ever played WOW, the code that works very simular to WOW including changing or transitioning of levels, handling quests, particles and anything else you ever wanted to know. Other than mentioning an Emu for a hugely popular MMORPG, there really are no MMO servers that you can actually take a look at. This is the only way I know for anyone to really get an Idea of what it takes to build an MMORPG from the server side of things.
Download V6 source;
AngelEmu: code.google.com/p/angelemu/
If you want an idea of how the tables were setup, you can download the tbc database and scan through it. In the V6 source is the entire server, including awesome network code, login server, accounts server ect.
Chris
lamiznik
We plan to buy TGEA for client, but we are ready to implement our own networking inside the engine. As much as I respect their work, I believe there can be better solution than what are mmokit and Darkstar offering.