TGEA questions...
by Matthew Koch · in Torque Game Engine Advanced · 05/21/2009 (8:28 pm) · 6 replies
I'm looking to use TGEA to develop a tech demonstration for a MMO. Yes I know, everyone else is doing it too. Here's the thing, I only want to use TGEA to produce the demo. I pretty much get that TGEA can't scale to MMO levels and I'm willing to throw out the demo once we've secured funding so I'm looking to invest the least amount of time getting this demo to work.
That said, here's the plan.
TGEA is the client.(obviously) We have a single mission contacting a single server which should work out of the box pretty easily. Here's where it gets tricky. Our game code is not written using datablocks and TGEA networking. It is written as a Service Oriented Architecture based Web Services API. For instance, a typical /say command works as follows.
3D client GUI calls CommandProcessor web service and hands off the command text.
Web service processes the say and sends a command to TGEA server using TGEA networking.
TGEA server calculates locality and forwards the say text to all clients in the area of the say using TGEA networking.
3D client processes the TGEA networking data and displays the contents of the say.
Another instance.
3D client GUI asks for a list of users by calling a ListUsers web service.
Web service returns to the 3D client GUI a list of data serialized as XML like any good web service would return data.
3D client GUI consumes the XML and displays the data. TGEA server never gets involved.
In this setup, the 3D client GUI does the bulk of the processing against a web service API and the TGEA server does nothing but simulation management and server->client message forwarding.
Here's my problem; I can do this one of two ways and both seem to have issues that require a tun of work to get it working. I'm hoping that someone here can shed light on something that I may have overlooked. We can implement the demo in one of two ways, Total TGEA client with TGEA GUI or Windows Forms app with an embedded TGEA rendering engine.
Total TGEA client with TGEA GUI.
Pros: Everything is done in TGEA. Most of the work is largely out of the box.
Cons: TGEA GUI has no idea how to consume web services so all the plumbing necessary to handle building the SOAP envelope, processing errors and presenting the XML returned as an object would need to be developed by our team. It seems like we'll be sinking a tun of time into TGEA to get stuff like data binding to work. Low level GUI stuff because TGEA cannot do more than a simple HTTP POST.
Windows Forms app with embedded TGEA
Pros: Windows Forms and .Net 3.5. There's no limit to what the GUI could be here. Look again at any MMO screenshot with the GUI on. The GUI is half the client at least. It makes sense to use a robust GUI in a MMO and Windows Forms is just that. I mean, all TGEA GUI is trying to do is work like Windows Forms. (scrollbars, windows, listboxes, checkboxes, buttons...) If we use Windows Forms, we get rich class bindings and data bindings built in and our server side processing becomes much easier and significantly easier to secure using WCF. TGEA GUI can only do old style web services (SOAP 1.0/1.1) by using HTTP POST and then forcing the developer to parse the text returned, forget WCF secure services with cached credentials and such from Torque script.
Cons: Integrating TGEA into a C# window is not trivial. We would have to make sure that input worked properly between the TGEA window and the rest of the GUI.
So my question is, is it worth developing the XML processing framework in Torque Script or is it worth figuring out how to get TGEA to run from a child window in a Forms app. Which one seems to require more work? Thoughts would be appreciated.
That said, here's the plan.
TGEA is the client.(obviously) We have a single mission contacting a single server which should work out of the box pretty easily. Here's where it gets tricky. Our game code is not written using datablocks and TGEA networking. It is written as a Service Oriented Architecture based Web Services API. For instance, a typical /say command works as follows.
3D client GUI calls CommandProcessor web service and hands off the command text.
Web service processes the say and sends a command to TGEA server using TGEA networking.
TGEA server calculates locality and forwards the say text to all clients in the area of the say using TGEA networking.
3D client processes the TGEA networking data and displays the contents of the say.
Another instance.
3D client GUI asks for a list of users by calling a ListUsers web service.
Web service returns to the 3D client GUI a list of data serialized as XML like any good web service would return data.
3D client GUI consumes the XML and displays the data. TGEA server never gets involved.
In this setup, the 3D client GUI does the bulk of the processing against a web service API and the TGEA server does nothing but simulation management and server->client message forwarding.
Here's my problem; I can do this one of two ways and both seem to have issues that require a tun of work to get it working. I'm hoping that someone here can shed light on something that I may have overlooked. We can implement the demo in one of two ways, Total TGEA client with TGEA GUI or Windows Forms app with an embedded TGEA rendering engine.
Total TGEA client with TGEA GUI.
Pros: Everything is done in TGEA. Most of the work is largely out of the box.
Cons: TGEA GUI has no idea how to consume web services so all the plumbing necessary to handle building the SOAP envelope, processing errors and presenting the XML returned as an object would need to be developed by our team. It seems like we'll be sinking a tun of time into TGEA to get stuff like data binding to work. Low level GUI stuff because TGEA cannot do more than a simple HTTP POST.
Windows Forms app with embedded TGEA
Pros: Windows Forms and .Net 3.5. There's no limit to what the GUI could be here. Look again at any MMO screenshot with the GUI on. The GUI is half the client at least. It makes sense to use a robust GUI in a MMO and Windows Forms is just that. I mean, all TGEA GUI is trying to do is work like Windows Forms. (scrollbars, windows, listboxes, checkboxes, buttons...) If we use Windows Forms, we get rich class bindings and data bindings built in and our server side processing becomes much easier and significantly easier to secure using WCF. TGEA GUI can only do old style web services (SOAP 1.0/1.1) by using HTTP POST and then forcing the developer to parse the text returned, forget WCF secure services with cached credentials and such from Torque script.
Cons: Integrating TGEA into a C# window is not trivial. We would have to make sure that input worked properly between the TGEA window and the rest of the GUI.
So my question is, is it worth developing the XML processing framework in Torque Script or is it worth figuring out how to get TGEA to run from a child window in a Forms app. Which one seems to require more work? Thoughts would be appreciated.
About the author
#2
Thanks for the feedback. I appreciate it.
05/22/2009 (6:31 am)
The MFC method might be a pretty good one to look into and I'm going to give it a whirl this evening. I wanted to clarify that movement and other such latency sensitive commands will still be implemented using standard TGEA networking simply because the latency of a web service would be too much for it.Thanks for the feedback. I appreciate it.
#3
If you need, you can expose cURL to Torque Script and do a lot of the processing in script.
Although a GUI takes up a lot of the screen for an MMO, it's actually a very small part of what goes on behind the scenes, so I would just use the stock Torque GUI.
TGEA can scale to make an MMO game, provided you only use it as you've said:
That's perfect.
The two most difficult parts in making TGEA scale to MMO levels is lowering the networking / simulation fidelity.
Torque is tuned for an FPS game, to the point where it synchronizes everything and attempts to make the client view as accurate as possible. This includes animations, projectile effects, etc. For the typical MMO game, this is overkill.
The default collision detection is also very accurate, but overkill for MMO games.
This "high fidelity" implementation in Torque will cost you bandwidth and significant CPU utilization on the server, but it's not impossible to replace that area of code with your own "low fidelity" implementation.
I have a question... Other than the fact that you've already purchased it, why Torque? Have you looked at other alternatives that don't require so much wrangling?
Granted, you're just working on a prototype, but why not work on a prototype that you don't have to throw away once you get funding?
05/22/2009 (6:39 am)
I suggest you use cURL in the TGEA client to access your web services.If you need, you can expose cURL to Torque Script and do a lot of the processing in script.
Although a GUI takes up a lot of the screen for an MMO, it's actually a very small part of what goes on behind the scenes, so I would just use the stock Torque GUI.
TGEA can scale to make an MMO game, provided you only use it as you've said:
Quote:TGEA server does nothing but simulation management and server->client message forwarding.
That's perfect.
The two most difficult parts in making TGEA scale to MMO levels is lowering the networking / simulation fidelity.
Torque is tuned for an FPS game, to the point where it synchronizes everything and attempts to make the client view as accurate as possible. This includes animations, projectile effects, etc. For the typical MMO game, this is overkill.
The default collision detection is also very accurate, but overkill for MMO games.
This "high fidelity" implementation in Torque will cost you bandwidth and significant CPU utilization on the server, but it's not impossible to replace that area of code with your own "low fidelity" implementation.
I have a question... Other than the fact that you've already purchased it, why Torque? Have you looked at other alternatives that don't require so much wrangling?
Granted, you're just working on a prototype, but why not work on a prototype that you don't have to throw away once you get funding?
#4
We're a Windows shop with most of the required licenses in place already that we can use for a back end. SQL Server 2008, Windows Server 2008, ... That eliminates nearly all of the MMO projects out there that are being developed on a shoestring budget. Our demo is on a shoestring budget but our full development plan is not. We're using the demo to raise money. I don't particularly want to introduce LAMP, PHP, Perl, Java, WebSphere and other technologies into our environment if at all possible. All our Web Service code is written in .NET 3.5, WCF and hosted using IIS7. Our websites are ASP.Net 3.5 on IIS7. I'd prefer an engine that didn't have to resort to ODBC to do its work and I have SQL Server so why downgrade to MySQL?
That left me with few options but I was OK with that because I'm not interested in the other programming environments. The question for me was which platform came out of the box closest to what we wanted to do. Torque seems to be it barring a bigger investment in a commercial engine like Gamebryo. From there I read about the IBM MMO project and thought, maybe, just maybe we could get Torque working in an MMO setting. So we bought TGEA, mainly because TGE was DirectX8 only and TGEA added DirectX9. DirectX8 is ancient. Our project requires seamless worlds so right there, that sorta limited Torque to just the demo but if we get enough experience with it in doing the demo, perhaps we can gut the code and make a seamless terrain system work. I'm leaving that for a later decision.
In my opinion, Unity3D doesn't have a real server environment. I need a real synchronization server and not a glorified client with a null render target that is Unity3D. Ogre3D didn't have a server at all and I'm trying to not have to write a dead reckoning server. XNA is the same, though if I had to write a server, XNA might be a good fit because it at least uses the same language that all the rest of the code is using, C#. Beyond that, I got tired of evaluating engines and figured I'd venture into Torque and just get it working. That's what prompted this post.
I'm going to have to look at the link you provided to see if it does some of the web service processing that I'd need it to do but as far as I am concerned right now, Torque will only be a demo system. We'll see how the scalability issue works out and I'm anxiously looking forward to seeing what I can do with the engine.
The only other drawback is that if we were to go into a two year development cycle for full blown AAA MMO with torque, I'm afraid that DirectX9 is going to become long in the tooth with the release of DX11 and Windows 7. Two years from now DirextX9 is very old technology. Two years from now, a AAA game (not a casual game) probably won't need to develop for XP or DirectX9 and with no real announced plans on how Torque will move into the Vista/Windows 7 age, it's harder to have faith in the future of the engine beyond the demo.
You asked :) Hopefully, that's enough of an explanation of my thinking.
05/22/2009 (12:53 pm)
We chose to work with Torque based on the whole idea of path of least resistance and being able to reasonably approximate the environment we wanted to work with in full production.We're a Windows shop with most of the required licenses in place already that we can use for a back end. SQL Server 2008, Windows Server 2008, ... That eliminates nearly all of the MMO projects out there that are being developed on a shoestring budget. Our demo is on a shoestring budget but our full development plan is not. We're using the demo to raise money. I don't particularly want to introduce LAMP, PHP, Perl, Java, WebSphere and other technologies into our environment if at all possible. All our Web Service code is written in .NET 3.5, WCF and hosted using IIS7. Our websites are ASP.Net 3.5 on IIS7. I'd prefer an engine that didn't have to resort to ODBC to do its work and I have SQL Server so why downgrade to MySQL?
That left me with few options but I was OK with that because I'm not interested in the other programming environments. The question for me was which platform came out of the box closest to what we wanted to do. Torque seems to be it barring a bigger investment in a commercial engine like Gamebryo. From there I read about the IBM MMO project and thought, maybe, just maybe we could get Torque working in an MMO setting. So we bought TGEA, mainly because TGE was DirectX8 only and TGEA added DirectX9. DirectX8 is ancient. Our project requires seamless worlds so right there, that sorta limited Torque to just the demo but if we get enough experience with it in doing the demo, perhaps we can gut the code and make a seamless terrain system work. I'm leaving that for a later decision.
In my opinion, Unity3D doesn't have a real server environment. I need a real synchronization server and not a glorified client with a null render target that is Unity3D. Ogre3D didn't have a server at all and I'm trying to not have to write a dead reckoning server. XNA is the same, though if I had to write a server, XNA might be a good fit because it at least uses the same language that all the rest of the code is using, C#. Beyond that, I got tired of evaluating engines and figured I'd venture into Torque and just get it working. That's what prompted this post.
I'm going to have to look at the link you provided to see if it does some of the web service processing that I'd need it to do but as far as I am concerned right now, Torque will only be a demo system. We'll see how the scalability issue works out and I'm anxiously looking forward to seeing what I can do with the engine.
The only other drawback is that if we were to go into a two year development cycle for full blown AAA MMO with torque, I'm afraid that DirectX9 is going to become long in the tooth with the release of DX11 and Windows 7. Two years from now DirextX9 is very old technology. Two years from now, a AAA game (not a casual game) probably won't need to develop for XP or DirectX9 and with no real announced plans on how Torque will move into the Vista/Windows 7 age, it's harder to have faith in the future of the engine beyond the demo.
You asked :) Hopefully, that's enough of an explanation of my thinking.
#5
I thought I could help more, but if you're going with a full Microsoft solution then it's likely I cannot help other than answering questions here and there.
I am the lead developer for the open source project Zen Worlds being developed by the IndieZen.org community. It's a high performance service oriented MMO framework, but since it's written entirely in C++ then it likely wouldn't mix with your .NET architecture.
The way we've written it, you can use pretty much any C++ thick client or Web / Flash based thin client and it sounded like it might be exactly what you needed, hence the question.
Good luck with your project.
05/22/2009 (1:28 pm)
Thanks for the detailed explanation... it made for a good read.I thought I could help more, but if you're going with a full Microsoft solution then it's likely I cannot help other than answering questions here and there.
I am the lead developer for the open source project Zen Worlds being developed by the IndieZen.org community. It's a high performance service oriented MMO framework, but since it's written entirely in C++ then it likely wouldn't mix with your .NET architecture.
The way we've written it, you can use pretty much any C++ thick client or Web / Flash based thin client and it sounded like it might be exactly what you needed, hence the question.
Good luck with your project.
#6
It looks like we'll be covering a bunch of the same stuff, so I'm sure I'll keep the community posted with progress. One of the things that has me curious, is with our C# back end, would we be better off using TorqueX 3D? Is TorqueX 3D the same as TGEA from a client server feature set? I'm still looking into this and am really just beginning to wrap my head around how to use Torque to accomplish what we want to.
05/22/2009 (6:49 pm)
Looks like you have yourself something pretty nice there. We've chosen a Microsoft Solution for a couple of reasons. One, we have the software and choosing something else would be throwing away money spent on perfect good software for the task. No matter what the Linux/Mac guys say, Windows Server 2008 is rock solid and easily up to the task. The other overriding factor really has to do with Louisville Kentucky. If you've ever worked here, you'll quickly realize that this city is about 90% Microsoft companies and as such, so is the labor pool. When we hire additional people, I want to be able to pull from the local community and finding a Linux/Mac programmer in this town is nearly impossible.It looks like we'll be covering a bunch of the same stuff, so I'm sure I'll keep the community posted with progress. One of the things that has me curious, is with our C# back end, would we be better off using TorqueX 3D? Is TorqueX 3D the same as TGEA from a client server feature set? I'm still looking into this and am really just beginning to wrap my head around how to use Torque to accomplish what we want to.
Torque Owner Gerald Fishel
Development Ninja
But that aside, trying to embed TGEA in a WinForms app is probably not the way to go, even though it is doable. You'd really need to reduce TGEA to a DLL to be consumed by your .NET app and link the render target to your WinForms window, and use a bunch of interop plumbing to link your controls to the underlying engine, and the coordination of input controls between the engine and the GUI would be complex.
If you want the rich GUI, you may be better off integrating TGEA into an MFC application. This will give you most of the same rich GUI capabilities as WinForms without all of the hassle of crazy interop plumbing between your GUIs and TGEA. You can just make TGEA an MFC application itself, and pass in the HWND of an MFC child window for the render window to become a child of. I did this for some of our in-house tools. It's not all that hard to do, and if you need some tips on getting that started I can probably help you out.
Also, for your web services, you may be better off just finding a native C++ web services library that you can use directly in the engine. You definitely don't want to try and do it in TorqueScript, but you have the source code to the engine so you can do it in C++.
Another option would be something else that I've done, which is integrate Mono as a .NET-based scripting platform in the engine, which would allow you to use .NET libraries from the engine quite a bit easier than trying to pipe TGEA into WinForms. Though that may be overkill just for web services. And it wouldn't allow you to use the WinForms controls, though I'm working on a way to have Mono WinForms/GTK controls rendered in the engine. It's a bear of a problem that is going to take a lot of work. Definitely not something you'd want to get into for a throw-away demo.
Cheers