Posts Tagged ‘tgb’

Is it possible to make an MMO in Torque Game Builder (TGB)? – Part 2

Monday, September 27th, 2010

You might remember my more optimistic part 1 post.

Well, I’m about 300ish hours into my MMO development (part time over the past year or so) and the other day I decided to finally do some performance testing… way too late to be doing this sort of thing btw.  I didn’t think too much of it before because the GG engines are touted for their networking layer, so I figured it should be able to handle the tiny packets that I was sending back and forth with no problem.

I started my testing with what I thought was a modest number of players for an MMO… 1000.  Not too high, not too low.  The server grinded to a halt! and suddenly I got that ‘Oh shit! What have I done?!’ feeling.  So just to get a better measurement, I dropped it to 500, then 100 and finally to 50 before things started to perform normally.  Ouch!  Now, I’m not trying to get EVE Online numbers, but 50?!?!  My stomach sank a little as I thought about all of the wasted work and all of the work I would have to do to rewrite the server.

How could something awarded for its networking ability come up so short?  Well, it wasn’t the networking causing the bottleneck at all.  What I failed to consider was not networking, but the processing cycles needed.  Apparently, TGB doesn’t make the greatest server for a synchronous MMO.  The inherently single-threaded processing and the speed of torque-script were drastically overestimated on my part.

I can probably performance tune the TGB server more and move some things into native C++, but in the end I decided it would be easier to rewrite the whole server in Java which is my native language ;)   While most people still have a negative impression of Java performance-wise, 1.6 is quite fast and it can usually be further performance tuned.

Moral of the story: performance test early so that you can change technologies if necessary and not have to rewrite a ton of code.

I haven’t finished writing the server yet, but I will post an update once I do some early performance testing.

Is it possible to make an MMO in Torque Game Builder (TGB)?

Tuesday, November 24th, 2009

I hear this asked here and there throughout the Garage Games forums and once in a while in various other game development forums. So what’s the answer?

Honestly I can’t say for sure, but my current project is an MMO(RPG) and I’m using TGB to develop it.  Anyone who has used TGB might be thinking, “That’s suicide!”, but I think its possible and sooner or later (at the rate I develop games, definitely later) I’ll find out for sure!

I know TGB can be used to make quality games, so what more is there to consider in making an MMO?  Besides the sheer size of the project, the biggest thing that comes to mind is networking/data architecture to support thousands and thousands of players.

With that, here are some of the things I’ve already considered:

  • Will TGB’s “turn-based networking” be an obstacle? The networking that comes with TGB was initially referred to as turn-based networking which to me implies that it is kind of slow/laggy, but in reality its more of an RPC-based networking so as long as you don’t need real-time ghosting for something like a twitch-based game, I think TGB may be able to hold its own.
  • Can TGB handle that many concurrent connections? I asked this question a few different ways on the GG forums and the big shots tell me that the only realistic limit is the bandwidth and server hardware.  I guess if they are wrong then by the time I find out for myself it would be way too late to change to a different engine and you’ll surely find me hacking away at TGB source code to try and make it work.
  • Does TGB have DB support? No, but there are some community source code mods that make it pretty painless to add SQLite support and it took me all of a couple hours to get this working. I hate making source code mods to TGB, but this one was definitely worth it… you simply can’t make an MMO without DB support.
  • How much bandwidth will the server need? This is one thing that worries me because its not something that I can easily test.  As far as bandwidth goes, EQLive published EverQuest’s usage years ago as being about 1 KB/s per user download and .25 KB/s upload.  While I’m sure today’s MMOs (WoW, etc) use way more than that, I’m also estimating that my MMO will use quite a bit less than that as it doesn’t require as much information to be sent as often (in theory).  TGB also has a way to ‘tag’ strings between the server and each client such that subsequent sending of the same string gets sent as a tag ID rather than continuing to resend the same string over and over again.  This should cut down on the bandwidth usage.
  • How will I scale up the server as more players join? Most likely I will host the TGB server myself until the beta is underway and then scale up to a VPS or Dedicated server as needed.  The server will need to be Windows based (mostly because that is my development platform).  I also need to be able to scale up quickly in case I get an honorable mention on one of the big gaming news sites, but I also don’t want to break the bank while I’m anxiously waiting for that to happen.

All-in-all I think I’m going to have my hands full for a long time, but I wouldn’t even try this if I didn’t think it was possible.

If you’re considering using TGB or another GG engine to make an MMO, check out this awesome list of discussions on the subject:

Even if you’re not going with TGB, here is a huge list of things to consider when making an MMO:

Torque Game Builder Review

Friday, October 9th, 2009

I first started using Torque Game Builder (TGB) from Garage Games about a year ago.  I haven’t actually released a game developed in TGB yet, but I’ve created a few prototypes and my latest project will be developed in TGB (assuming I keep enough momentum to actually finish it :| ).  Also, I’m using TGB after having used my own home-brew C++/DirectX 6 engine which sucked in comparison, so keep all of this in mind as you read this post.

I own the full source version of TGB (currently v1.7.4), but since I’ve only made one engine change so far (to add SQLite DB support), I think this review applies to both the full version and the binary-only version.

Things I Like:

  • Rapid Development – This is the number one thing going for TGB.  I recreated one mode of Invadazoid in a couple weeks, which originally took me a couple months, and it looked even better than the original (even using the same image sets).  With the fairly recent inclusion of behaviors into TGB, the development time should be even less.  I love being able to drag and drop elements onto the scene in the level builder, apply behaviors to things where I can, and then finally script the rest.  The built in callbacks make it fairly easy to script everything as well.
  • Price – You really can’t beat the price for what you get.  I literally spent twice as many hours (creating my own engine) as dollars (buying TGB) and TGB blows my engine out of the water.
  • Graphics Capabilities – I like to use PNGs and TGB displays them very nicely with all of the proper alpha layer and anti-aliasing effects.  While these things are to be expected in any game engine these days, remember I upgraded from my home-brew engine that didn’t have these capabilities, so this was a big plus for me.  The particle engine is great too.  You can customize literally every aspect of the particles and their emitters to create anything from a jet’s contrail to a zombie’s blood splatter, all from within the level builder.  I wish they would include more prebuilt particle/emitter templates, but all-in-all, I’m happy with it.  One issue I noticed was that if my images were too big, the level editor wouldn’t load them.  I never figured out if it was a limitation of my video card or of Torque… I ended up just breaking up some of my tile sets into smaller images.
  • TorqueScript – A lot of people complain about TorqueScript, but I really like it.  Its very C like in syntax, plus it has a lot of built in functions.  I also like the the fact that it’s a typeless language, which is a great time saver for a skilled programmer.  I say ’skilled programmer’ because for novice programmers it can sometimes be difficult to debug ‘type’ issues.  I also highly recommend getting the Torsion IDE and this book.  I remember trying a demo version of Torsion when it first came out and I was very disappointed, but I re-downloaded their latest version recently and its pretty sweet!  The code completion and the debugger alone decrease dev time significantly.  Not as nice as eclipse for java development when I’m at work, but still much better than hacking away in a text editor (I know, you Linux guys are screaming “vi rules” right now, but seriously… get with the times).
  • Networking Support – Although the only networking included in TGB is event based (as opposed to real-time, ghosting systems), I’m enjoying working with the RPC style interface in my new project.  It’s simplicity prevents you from getting bogged down in networking protocols and sockets and all that.
  • The Community – The Garage Games community is huge and often very helpful.  You can find a lot of community-developed resources to add to your engine (assuming you have the full version), prebuilt behaviors, and the forums can usually answer your questions pretty quickly.
  • Cross-platform Support – I can’t really speak to this because I’ve never actually ported anything to Mac or Linux, but folks like Rake in the Grass Games (who have released multiple TGB games) say that it takes them about 1-4 hours to port to Mac, which seems pretty impressive.  GG also touts being able to ‘quickly’ port to the iPhone, XBox360, and Wii, but I definitely don’t have any experience with that.
  • Source Code – If you buy the full version, you are able to make engine modifications and also browse the source code to learn how things work.  There are tons of resources out there that tell you how to modify the engine source to add certain functionality.  Some are trivial and others require major source mods.
  • GUI Editor – It has one… see below.

Things That Need Improvement:

  • Documentation – Although the documentation has improved in the past year or so, it still leaves something to be desired.  I code in Java for a living and I’m used to the level of documentation provided by Sun’s Java Docs… I guess I’m spoiled :|   I often go looking for a Torque method in the docs and either I can find the method signature with no explanation for each parameter, or sometimes the documentation for an object is missing completely.  It slows down development time when I need to fiddle with an object method to get it to work.  In these scenarios I find the quickest way to figure out how to use the object/method is to open up the C++ source code and find out exactly how it works (one big advantage of the full version of TGB).
  • Occasional Bugs – Once in a while you will come across something that doesn’t work.  Did you make a mistake?  No problem, just go check the docs and see if your script call is right… oh wait… this is one of the many calls that isn’t documented :mad:   So you play around with your script for a while and you still can’t get it working… off to the forums to search for a user with the same issue.  If you’re lucky, someone has already posted on the topic and there’s a easy solution.  If not you post a question and hope someone answers it… and once in a while, after hours days of repeating this vicious cycle it turns out that there is a bug in the engine.  You have two options here.  Either you 1) open the source code and fix the bug (I personally don’t recommend this because if you like to keep up to date with the latest engine versions like I do, then you’ll have to do a bunch of code merging for every bug you fixed that GG hasn’t yet), or 2) you can work around the issue by potentially using another object type or coding a bunch of hacky type script that ‘hides’ the issue… either way its not fun and you just lost a ton of dev time.
  • GUI Editor – It has a lot of ‘widgets’ and it’s usable, but it’s not nearly as nice as the Level Builder.  You can drag and drop GUI controls from the ‘palette’ to the canvas and then modify it’s settings in the property editor… seems fairly simple.  Lets say you want to change the font/color of a label, you would just modify the ‘font’ property right?  Nope.  TGB uses what they call ‘profiles’ instead and you can only create these profiles from script :mad:   Another problem is that the most common controls have minimal documentation and the rest have none!  Lastly, its kinda buggy.  Its fairly common to crash the entire application when you do something it doesn’t like.  Things like this are the reason us paranoid coders wear out the Ctrl+S keys on our keyboards.

Overall, I’ve been very happy with Torque Game Builder.  The pros definitely outweigh the cons and the full version price is worth every penny.  Garage Games has posted saying that they are making a ton of improvements and re-releasing the engine as T2D sometime in the not-too-distant future.  They are also actively trying to improve their documentation from what I can tell.  GG has been very good about releasing major and minor updates to TGB… I just hope that its fairly easy to convert a TGB project to T2D… *fingers crossed*