Blog for Josh Williams at GarageGames.com

News is out!

Josh Williams — 2007-09-18T15:28:29+00:00

Well, we've been sitting on this news for awhile, and it's great to finally announce it! We're very excited to let everyone know that GarageGames has partnered up with InterActive Corporation, IAC, to build a brand new network of action games playable in the browser, and to fund independent games, all in accordance with our long-standing philosophy, vision, and mission at GG.

As far as publicity goes, to get the word out there, we decided to talk about the business end of our deal with IAC first, as we knew it'd cause all kinds of questions, and we wanted to answer them frankly. We figure it's best to be honest about it, now that we're ready and able to talk. This is why the stories you're reading online today are pretty deal-oriented and chalk full of business terms. From here, we'll be talking a lot about what we've been working on lately, and what we'll be doing in the future, which will be much more interesting (at least to most everyone on our site :).

Similarly, in this blog, to get the big sticky questions out of the way, I'll start off by talking about the deal we cut with IAC, what it means, and why we did it. Then, I'll move onto the really cool stuff, including what we're working on now, the future of Torque, and how we're funding games. I'll be totally straight in this blog, as this is obviously huge news for us.

Why were we interested in funding at all?
We were interested in funding to try and do a better job fulfilling our mission. Since Jeff, Rick, Tim and Mark started the company 8 years ago, and since many of us joined up early on working for beans as we bootstrapped the company, the fundamental mission for GarageGames was pretty simple (yet powerful)... make the industry a better place for developers. By doing that, more great games would get made, which would be better for gamers everywhere.

GG started out working toward this mission by focusing on providing professional quality game technology and tools at prices literally anyone could afford, democratizing game development, in a sense. There's no getting around the fact that making games is just plain hard, and it takes a lot of talent and work to get one finished-- let alone to make it fun and appealing. We can't change that. But at least GG put a stake in the ground and took on one of the biggest hurdles facing aspiring game developers and indie teams-- access to affordable, effective game technology.

But making it easier to create games is half the battle, at best. Part and parcel to GarageGames' mission was to help developers get their games to market successfully and find their audiences. That is a massive challenge, as anyone who has shipped a game will tell you. At GG, we've taken some steps to try and help indies get their games to market-- we created the basic Game Store here on GG.com, which publishes lots of fun indie titles, and we have helped establish some successful games there. We've helped broker deals for a few games to break onto Xbox Arcade, casual portals, mobile devices, and other emerging, indie-accessible channels. We created The Great Games Experiment, a social-networking site for gamers and game developers to promote games and find friends.

While these were all good efforts, we've never had the resources at hand to fundamentally change the game and carve out new space that'd really help developers be successful.

With IAC, that is exactly what we're doing now. We've been dreaming of a new, better way to develop, distribute and play games online for a few years now, and we've been working on the technology to support that dream for a couple years, behind the scenes. I'll talk about the details below, but the bottom-line is... we started looking at funding possibilities because we wanted to do a better job helping other developers build their games and be successful with them.

There's no way we or any other single company can help every single game out there that deserves attention and success. But what we can do, now, is truly become the publisher and developer partner that we always wanted to be. We'll help lots of teams succeed, and we'll help drive the industry even further toward establishing newer, more developer-friendly channels and markets.

We've been actively building out a new network of games at InstantAction.com (which everyone in the GarageGames community will soon get early access to, as you'll all be given accounts at IA). We're working on games ourselves, and we're funding games on very developer-friendly terms that allow both us and the developers we're working with to win. Of course, we'll doing all this while continuing to push forward (harder than ever) on Torque and our commitment to developer tools.

There's much more to talk about in all this, and this blog is just the beginning...

What kind of deal did we do with IAC?
As must be expected when doing a big hairy announcement like we just did... sometimes not everything you want to say gets across cleanly in print. However, I want everyone to know that our deal with IAC was and is fundamentally compatible with our philosophies at GG, and the internal plans we had in place.

As some of you have read in the announcements by now though, IAC has acquired a majority of the equity at GG. However, we used a very unique structure in our deal with them. While IAC now has the majority of the future economic value of GG, we continue to run the shop right here in good old Eugene, OR.

IAC is a very smart, savvy group of people and they recognized right away how passionate and committed we were to making great games, to treating developers fairly, and to our philosophies here. As such, our deal is structured to accommodate all that, and to make sure we stay true to our goals. As it's headed up by people with a lot of experience in creative industries, IAC also understands the importance of creative control, and treating both content creators (developers) and audiences (gamers) the right way.

So, our wording in the press release and such today involves IAC's new majority stake in GG's equity, and we wanted to be honest about that. But keep this in mind too: we wouldn't have done this deal without knowing for sure that we'd have the freedom to stay true to our mission, and we of course made sure that freedom was baked into the deal structure itself.

Our partnership with IAC is a big one, and it's truly built for the long-term. IAC is helping us in a huge way, through funding and through sharing expertise and resources, to build an awesome new game network, alongside our existing commitment to providing great developer tools (and we've got a bunch of exciting stuff to talk about on that in the coming weeks as well).

Why did we want to work with IAC?
Simply put, IAC was and is the perfect partner for us. We couldn't have dreamed of a better deal structure, or a better company to work with.

As anyone watching the industry sees today, games are heating up, and all kinds of investment is pouring into the industry. This is actually a great thing for developers and for gamers, because it means that there is more funding available out there, and that new kinds of games and distribution channels are being built.

At GG, we were and are offered funding on a regular basis. However, we never found a partner who really seemed to get the industry, to share our vision, or who we found willing to work with us in a way we honestly felt would allow us to stay true to who we are. We were very hesitant about VC or any such form of funding, as we didn't want to be under pressure to "flip"... eg sell the company to the highest bidder, or go public really quickly, which is what most VC is built to do, but obviously not what we're all about here.

So, even though we've always had a big vision and we figured it'd take more than we could hope to bootstrap on our own to truly fulfill that vision, we were always hesitant to take on any funding, or bring in any sort of partner. Call us untrusting... but that's smart in the world of big business. :)

With IAC, we finally found a perfect partner, though. To me, there are three overarching reasons why this is true:

Vision. IAC had an uncannily similar vision to ours at GG. They'd been looking at games for years, hoping to see an opportunity to help transform the industry and carve out a new market by building a great new online game network. We shared practically all the same ideas. I met with Shana Fisher from IAC in New York a long time ago, and it was eery talking to her... the challenges and opportunities she and IAC saw facing the games industry were the same exact challenges and opportunities we saw. IAC's ideas were uncannily similar to the vision that Jeff, Mark, myself and really the whole founding crew and team here had.

Entrepreneurship. With IAC, we found a partner that truly understood us, and how to build and support great businesses in general. IAC has a very entrepreneurial approach, and we have the physical and mental space to really do what's best. At the same time, we have access to amazingly talented, strategic thinkers, and the resources of a huge organization to lean on. Truly, we now have the best of both worlds... we run and operate as a small, nimble, entrepreneurial company with a big vision and a lot to get done... yet we have the support and resources of a multi-billion dollar, publicly traded, well-connected company with a great deal of web expertise and experience backing us up. That is amazingly cool and powerful.

In case you didn't hear it... GG just dinged. Level up!

People. Straight up, IAC is full of incredibly bright, super talented, dedicated, strategic, passionate people. Shana Fisher is one of the smartest business people I've ever spoken with. Barry Diller's track record speaks for itself, and it's incredibly exciting to be able to work with him and the reast of the team there. Jeff and I met a lot of the team at IAC, and the people there were a big factor in deciding the partnership with IAC was the right call. In fact, we recruited one of IAC's lead people to come work with us directly at GG. We hired Andy Yang a few months ago to spearhead our web efforts and InstantAction! Andy, truly, is one of the most impressive, intelligent, and dedicated people we've ever met, in any setting. It is an honor and a pleasure (and a huge win for us) to have the opportunity to work with the people at IAC.

Really, these are the overarching reasons we proceeded to talk with IAC, whereas we normally dismissed offers for funding and the like.

When did this happen, and why did it take us a while to talk about it publicly?
Our deal with IAC actually went down several months ago. As you can tell... we're still the same place we've always been (just better, more effective, and able to do more). We didn't announce it right away because we didn't want to do one of those vaporware releases you so often see. In most cases, people jump up and down about doing a deal, talk about all the crazy stuff they'll be doing, and then go dark for several months as they scramble to actually get something done.

We didn't want to do that. We wanted to hold off until we actually had something worthwhile talking about... not just brag about the fact that we did some big deal.

We finally announced because the InstantAction.com closed beta is starting in just a few days, and we're accepting registrations for early access now. We've poured a ton of work into InstantAction already, and with IAC we're investing millions of dollars into its continued development. We already have a bunch of cool stuff running, and we'll be taking the veil off it all soon.

IA beta testers get access to the games we're working on, and all the games our partner teams and studios are working on, as well as all the features we're building into InstantAction itself. Beta testers will even get sneak peaks at new concepts and newly proposed games, and can help us decide what to work on next and how it'll look and feel. So, we wanted to wait to get the word out there until we had this truly worthwhile stuff to talk about.

What is InstantAction?
I can't do InstantAction justice by answering this question briefly in the middle of a long blog. So, we'll be talking about this a lot more in the near future. For now, I'll keep this very brief.

InstantAction is a new place to play games. We're working on games here at GG and we're working with great indie studios of all kinds, from some of the biggest names in the industry to total unknowns with great ideas and the ability to get them done. We're building a bunch of great new games that focus squarely on being fun. They'll all be playable in the browser, and they'll be rich, core-oriented, and often multiplayer games. Effectively, we are building a web-based console... and just like a console, we'll have a wide variety of games and will be working with lots of developers and eventually perhaps even other publishers to create games for it.

For gamers, InstantAction will be and is a place to find great games and to connect with friends to play.

Again, many more details to come, and we'll look forward to seeing all of you in the IA beta, soon. :)

What kinds of games are we looking for?
Again, we'll be talking about this a lot more soon, so I'll be brief here. Fundamentally, we are of course just looking for fun games. We want games that appeal to a core audience of gamers and ex-gamers, pretty much anywhere in the world. We're building games that are designed to interface with the web, and leverage the unique advantages and cool features we are building into InstantAction.

We're looking for lots of games too, and are even funding some. So, if you've got a great idea and truly have the chops to get it done, get in touch with us at games@garagegames.com.

How are we working with developers?
As I said above, we've now been able to become the publisher we always wanted to work with. We're funding many games, and doing so in a way that lets everyone involved win. We have the best developer terms in the industry, and they're right in line with our long-standing philosophies.

This is one of the most exciting parts of this announcement, and we'll be sharing a lot more details on this in the near future. And, by the way, if you want the full scoop, IGC is for you.

What does all this mean for Torque, and the GG community?
Very good things. We're getting more done on Torque than we ever have before. As you've seen, we recently pushed out updates to TGB, TGEA, and TGE, while shipping Torque X and more. But all of this work pales in comparison to what we have to announce in the coming weeks for Torque, and the community here at GG. We're pushing Torque forward in a huge way, re-vamping and overhauling the engine and tools in ways we couldn't have before. We can't wait to share the updates with everyone, and we have a bunch of cool stuff for the community up our sleeve. More details coming very soon.

Suffice it to say, we're getting more done on Torque than we ever have. Honestly, for a long while there, it was really hard to break out and make big, important changes to Torque. We were bootstrapping GG, which basically meant we lived hand to mouth, month-to-month on the business from licensing Torque. That makes it hard to try and do anything really revolutionary, or take any big risks. So, I feel like we were starting to stagnate. For the past few months, we've been able to truly step back and look at the big picture, and figure out what we want to do with Torque and our developer tools, and how we can really make them better. That's lead to some great work getting done, and we're excited to talk about it with everyone very soon (suggestion: again, come to IGC, and get the story).

What's changed at GG since the deal happened?
Well, we're bigger now, but actually not by a lot. A couple years ago, we doubled size in one year. We haven't grown that much this year, and in fact our growth rate is about the same as last year. But overall, we've added a bunch of great new members to the team at GG.

We've been building out InstantAction. We've been making new games! :) And we've been pushing forward harder and faster on Torque.

We're constantly trying to improve internally, to become more effective and efficient, and to do a better job defining and achieving our goals and promises. Like any company, we're growing and changing, but our soul is still the same. We're just empowered to do more, now.

Fundamentally... did we sell out?
Being perfectly honest, no, we didn't. On a philosophical level and in terms of what we're working on and how we're operating, we just took the right steps to do what we always wanted to. I'm sure we could've cut a better deal with someone, if all we cared about was making bucks from selling out GG. But we have to sleep at night, and look at ourselves in the mirror every morning, and money in and of itself is only so valuable. So, no souls were sold, I'm happy to say. :)

Of course, we obviously traded in the majority of the economic interest in GarageGames, so in that regard we did sell a lot. But we did so in exchange for a great partner and a better way to do what we've always wanted to. And even economically, the deal with IAC is structured such that it'll work out better for everyone involved (IAC, GG itself and our employees, and our external partners) now that we're supported by a great partner in IAC and have the resources to truly bring the longstanding visions Jeff and others originally laid out for the company to reality.

So, there's the straight dope on this whole announcement, and our new partner, IAC. I hope I answered the the most important, immediate questions that seeing this hit the stories and blogs brought to mind for everyone. Thanks very much for reading, and I'll do my best to reply to comments as soon as possible. We'll be talking about all this-- especially our plans for InstantAction, Torque, and new games-- in a lot more detail in the very near future! This is all very exciting stuff, and we can't wait to talk about it all more.

Saturday Feb 26 1:31

Josh Williams — 2005-02-26T01:31:16+00:00

It's alive! Stealth launch of Torque 2D...

Whew! It's been a pretty monster push over here to get Torque 2D out there, and there's lots more work left to do-- Melv and I are really looking forward to working with all of you who pick up T2D-- but it sure is a relief to get this thing out the door right now! Time to get some sleep. :)

All I can say right now is thank you, thank you, thank you for all the kind words and encouragement during T2D's development. This is the best game development community around by a long shot. I seriously can't wait to see what you guys do with T2D.

On our end... we just couldn't hold T2D back any more. We're launching a *little* prematurely. Only the Windows installer is packaged up right now (though OS X and Linux packaging only require a few more hours of work). But, we didn't want to make everyone wait until next week when everything is all packaged up and polished before we opened the floodgates.

So, here we are, pushing T2D out the door on the sly. No press release, no big announcement yet. Just want you guys, our "insiders", to be able to get your hands on it before everyone else. Please bear with us as we work to get all the information and platform builds online here over the next few days. But don't wait to join in on the fun. The T2D forums will be up real soon, so drop on in and say hi. :)

Well, I'm gonna shut up now since I tend to talk way too much in these things. Let me just also say thanks though to some teammates on this project: Melv, Pat, Jeff, Alex, Jay, Benjamin, Rick, Ben, and everyone at GG... it's just incredible working with these guys. And to community members.. Nauris Krauze, Craig Fortune (check out de-railed!) and Matt Mitman, and can't thank you guys enough for your incredible art work. Anthony Rosenbaum, Dan MacDonald, Dave Myers, Harold Brown, Phil Carlisle and the rest of the folks who helped us test T2D so much, thank you! No matter how hard Melv and I might've worked, T2D wouldn't be half what it is without these guys.

I could go on for pages thanking everyone.. so happy to have worked with everyone here on this. Now... let's go make some kickass games!!

Tuesday Feb 22 21:21

Josh Williams — 2005-02-22T21:21:05+00:00

T2D demos screenshots. Launch is just days away!

Okay, time to prime the pump here some more. :) Melv and I couldn't resist posting some screens of the T2D demos we've been working on. Check out the pics below!

These demos are just simple, simple little examples of what Torque 2D can do. "Demo in a day" is a good way to describe 'em. None of them are anywhere near being games, but they look great, thanks to some extremely talented artists: Craig Fortune, Nauris Krauze, and Matt Mitman. These guys are incredible. For your viewing pleasure, may I present screens from the Torque 2D demos!

Simple "grav gun" demo:

Every engine today is trying to show off their physics, with grav guns and pachinko machines, and blah blah. Grav guns are easy, as our little hero Flegg demonstrates in this demo. And check out those particle effects! Melv does amazing things w/ T2D's particle system, but I bet it won't be long after release before someone out there is even better with it than he is. The great looking art you see here was provided by Craig Fortune and Nauris Krauze, of De-railed. These guys amaze me.

Simple pool demo:

This is a little pool "game" (not quite a full game, but you can knock balls around). Art by Matt Mitman, thanks *tons* Matt! My real-life pool game has improved by about 10x since we started working on this thing. And, I have to be honest, T2D has probably been delayed a little, due to time lost playing this thing. ;)

Simple undersea scene:

Next, a little undersea screen-saver type demo. This screenshot doesn't really do it justice. Melv created some *fantastic* dynamic lighting effects for this thing. Melv's friend Craig Ball helped out with this demo, and the great art was produced by Craig Fortune and Nauris Krauze of the De-railed team, with a little help from Jeff Gran, a talented intern here in the office. Thanks guys!

Checkers!

The best-looking checkers game ever created? ;) If so, it's thanks to Nauris and Craig once again! These guys rock. Pat Wilson did most of the coding for this game, thanks Pat! This demo is still being worked on, it'll have some cool features that aren't displayed in this pic yet.

Side-scrolling shooter:

None of these demos have much gameplay at all, they're really just meant to show off a little bit of what Torque 2D can do. But Melv has been cranking away on this Mars attack shooter, and it's actually pretty fun to play. I guess earlier today Melv's whole office had a big high score competition for this one. You get power-ups like triple-shot, shields, and side-kick ships, and your goal is to destroy the swarms of enemies that fly your way. This demo has been totally re-coded since IGC, but it was originally written in < 9 hours by Pat, who it should be clear to everyone by now, rocks. Nate Feyma and Alex Swanson created this great art, thanks guys!

So there you have it. :) T2D is just around the corner! None of these demos took more than a dozen hours or so of coding, so T2D really lets you focus on game design and art. I can't wait to see what everyone does with this thing! Let's launch this puppy!!

And once again, many, many, many thanks and congratulations to Melv for all his hard work on T2D. Melv, it has been an utter pleasure working with you. With the help of the awesome community around here, I'm sure this thing is going to be worth all of the hard work we've put it on it. It's gonna feel great to see all the work put to use in helping people make cool new games!

For technical info on T2D, see my ridiculously long informal tech overview .plan: T2D core classes, and T2D core systems. Or.. just pick T2D up in a few days, and see for yourself!

Friday Feb 11 1:57

Josh Williams — 2005-02-11T01:57:19+00:00

Torque 2D informal technical overview .plans, pt 2. All the nitty-gritty on T2D's core systems.

Alright, here it is! First, my sincere apologies for the delay with this .plan... it's really cool that some of you have been looking forward to it, and I wish I could've found time to get it done right away. For as long as this .plan is, it didn't take too long to actually write, it was just hard to find the time to do it. There's been lots of actual work to do on T2D (let alone other cool projects!), so it was tough to justify taking time away to write this up. Finally got some time over the weekend though, and just got time to go back and edit / clean this monster up. Anyway, I hope some people find this thing interesting. Got some good feedback on the last .plan, so I figured I'd try to do the same here... only more! ;)

In the last .plan, I went over T2D's core classes, describing what T2D objects are capable of and how they're structured. Many people actually seemed interested to hear about all these nitty-gritty details. The geek factor around here is way too high to be healthy. Which is why I like this place so much.

So, let's dig in again. This time around, we'll take a look at T2D's core systems. Only now, I'm going to out-geek all of you. ;) In fact, this .plan has so much detail, I've had to create breakout sections in the discussions of collision detection and physics. Those topics contain some blocked sections, like this...

Quote:

Hello, I am a block section containing unnecessary but potentially interesting detail on certain aspects of T2D's sub-systems, or general asides on relevant but tangential topics.

These sections can safely be skipped without breaking the main thread of this .plan. These breakouts contain asides, explanations of the reasoning for why certain design decisions were made, and other discussions that might be interesting, but aren't necessary to the main technical overview. I thought some people would find them interesting, but want to make it easy for anybody who's not interested to skip 'em.

Also, some of the breakout sections are *really* long. One in the physics section weighs in at 6 pages long. But, rather than having all that text on this page and forcing folks who don't want to read it scroll-through everything, I've created separate little landing pages for that content, and I just link to the pages from within the block sections below. Also, this .plan was too big for the site to handle, literally-- it puked when I tried to post this behemoth. (Take that Davis Ray Sickmon! ;)

Okay, before getting started, let me give everyone a quick update on T2D's development status. Here in the last couple weeks of development (hint!), we've been pushing really hard, and making great progress. Melv is incredible, and I've been putting in some long (but fun!) hours over here too.

First thing to report is that T2D beta testing is going extremely well. Our ace team of beta testers never fails to hunt down even the tiniest bugs. Check it out:

That's Melv's baby daughter Jess, pounding away on T2D, and I'm happy to report that we passed the drool-plus-random-key-smashing test with flying colors!

GG Associates have been hammering on T2D for a while now too, and it's going great. I'd particularly like to thank Dan MacDonald and Anthony Rosenbaum for their thorough testing and detailed feedback. You guys rock.

On the development front, we're just about to finish the final release candidate build of T2D! It's been through five beta builds already, including 3 major revisions, so we're confident this puppy is ready to go. From here it's just finishing up documentation, demos, merging in some of the excellent work Pat has done, adding some better GUIs, and then doing the final installer packaging, etc. In addition, Melv is doing some new editor work, described below. All in all, the release candidate will be out almost immediately! Of course, confident as we are, we still need to put this last release candidate through testing, so don't expect T2D in your hands right away or anything. Trying to be really careful and give it a lot of testing love. But, it's obviously not very far away now. :)

The biggest development update to talk about is that we've decided to do our own simple tile editor for the Early Adopter release, instead of just doing .fmp / Mappy support. Mappy importing is still planned at some point, but after a looooong conversation and debate on the subject that lasted until 6 or 7am for me a few nights ago, Melv and I decided that the best thing would be to do our own little editor. Mappy is great, but no engine I'm aware of has as powerful a tile system as T2D. As such, Mappy just wasn't designed to support such a flexible system, and can't take full advantage of it. Doing a Mappy importer and working around the limitations seemed pretty simple on our first look, and it still isn't going to be too awfully hard, but we decided at this point time would be better spent working on our own stuff. If we're going to burn much dev time on this task, we'd rather produce something that will let people take advantage of T2D's tile system to a fuller extent. Melv is cranking away on the tile editor probably as I type right now, and it's one of the last things to go in this final (hopefully) release candidate build.

Well, that's where things stand at the moment. Very exciting! I hope appetites are whetted. Now, let's dig into T2D's core systems, as promised. The structure is similar to the last .plan, but we're describing systems instead of classes here. We'll cover the collision, physics, layer and group, mount, object picking, world limit, camera, scenegraph, and window systems, as well as discuss briefly the systems T2D inherits from TGE itself.

Okay ready? Collision is first-up, then physics. These first two topics are complicated, but very important, so get ready for long reads in these sections. :)

Collision
T2D's collision system underwent a pretty interesting development cycle, a brief history of which is in one of the breakout sections below. We want T2D to be, far and away, the best 2D engine around when it's fully complete (after the Early Adopter period is over). We know that the collision system T2D provides will be crucial in achieving that goal, and we want indie developers to have the best collision system around at their disposal. As such, after much thought, research, and discussion Melv and I set some very aggressive goals for T2D's collision system. We wanted to:

Allow detailed collision polygons to be specified for objects and accurately collide them
Let users enable or disable individual objects' ability to cause or be affected by collisions
Easily restrict collisions between particular groups of objects
Return rich collision information
Make it possible for people to customize the system, even with scripting only
Easily hook-up to custom collision response systems
Use the same system for tile-maps and normal scene objects
Handle hundreds of objects in a scene at once
Create a network-ready collision scheme
Do it all in a very easy to configure manner, so that anyone can use T2D with little hassle

The design we came up in the end met all these requirements, and Melv, as always, knocked the implementation out of the park (and in an ungodly-short amount of time, with very few bugs... all of which have since been squashed ;). So, I'm happy to report that T2D meets all of the lofty goals set above. We have even more cool stuff in mind for the future of the collision system, and we've designed this version with those in mind.

So how does this whole system work? Let's take a look.

Object collision settings:
As described in the last .plan, all script-instantiable T2D classes are derived from fxSceneObject2D, and this class defines the default collision system. Part of this definition allows objects to specify a collision polygon. Collision polys can either be regular n-gons, or custom convex shapes. This means that you can define tight-fitted custom polygons for your sprites, which makes it possible to create nicely accurate collision systems. Also, the collision polys are sized along with the object, so you don't have to worry about adjusting them.

In addition, objects can be configured to "send" and "receive" collisions. When an object sends collisions, it means that it's capable of causing collisions on other objects. Receiving collisions means that an object can be affected by collisions.

Quote:
Aside: Sending and receiving collisions, what?
------------------------------------------
To make this more clear... objects in the real world of course both send and receive collisionswhen you and your buddy stand at opposite ends of the room, run at each other, and smack together (because you are smart and you find this activity enjoyable), you both send a collision to the other and receive a collision from the other. Your skull sends a collision to your buddy's, and your buddy's skull receives your collision. And vice versa.

Torque itself has a similar concept of active and passive colliders, but it doesn't define a clean interface regarding it.

In the majority of T2D games, most objects will no doubt be configured to both send and receive collisions, just as in the real-world. But we've made it possible to easily turn off either of these capabilities for any object. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in T2D by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.

Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might assign a player's avatar and their bullets to a specific layer and group. Likewise, you might assign all enemies and their fire to the same layer, in a different group. Then, you can set collision layer and group collision masks on the player and enemies-- for the player, you might turn on collisions with its own layer, but turn off collisions with its own group (meaning that the player can't harm himself with his own projectiles), and turn on collisions for the enemy group. For enemies, you might do exactly the same, but perhaps turn on collisions with their own group as well, so that enemies can shoot each other. If you were making a multiplayer game (in the near future ;), you might turn off friendly fire by assigning players on the same team and their projectile fire to the same group, and turning off their collision with the team's group.

Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. No matter how optimized the code (and T2D's collision code is nicely optimized, again, Melv is an animal), collision detection is an expensive operation. This can especially be true when you're dealing with accurate swept-polygon collision (more info below), as T2D does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.

Finally, objects can be configured with a script collision callback function. In this way, players can over-ride or add to the default collision detection and response system. By default, the collision callback is passed the time of collision, up to two contact points, collision normals, and a custom string field which can be used to extend the callback info on the cheap. :) One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision. You could modify your sprites, perhaps amongst some pre-set collection of deformation frames, and their collision polygons in this callback.

All in all, this puts a lot of power and flexibility in the user's hands. Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. It's a very powerful and flexible collision specification system, but it only takes a few lines of script to get set-up. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get the collision set-up.

So, those are the collision configuration options. Now, let's see how collisions are detected and processed.

Collision Detection:
Like most collision systems, Torque 2D detects collisions in two phases. The first is a broad-phase, early-out collision test, which narrows the list of potential collisions. The second is a nitty-gritty collision test which returns accurate collision information both for when objects overlap, and for when they are disjoint but collide in forward-time. We'll look at both of these systems in more detail.

First, broad-phase, early-out collision is very common in collision detection schemes, as most of you no doubt already know. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection.

T2D's scenegraph sorts objects into "bins", which are just regular space divisions. Its broad-phase collision check compares objects in the same bin against axis-aligned bounding-boxes (AABBs) to determine whether the two objects might collide. This technique is very common, and it's tough to beat in 2D.

Quote:
Aside: Broad-phase CD information:
---------------------------------------------------------
One can use a large variety of techniques in broad-phase collision checks. Some of the best information and resources on the subject can be found here, here, and in the book Real-Time Rendering. Most recent research in this area is specifically targeted at handling 3D collision detection with highly complex objects. In these scenarios, AABB checks are not usually optimal, and the most recent research is generally hostile toward using AABB checks in the broad phase. But, Melv is smarter than all these fool academics. ;) In all seriousness though, 2D game scenes are generally quite well-suited for using AABB in early-out, broad-phase collision pass.

Once T2D is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. As stated above, T2D is capable of performing swept-polygon collision detection, which Melv and I agreed on using after much research, discussion, and debate (see the development history breakout below... this particular decision took 20+ pages of dialogue between Melv and I. :). This system is capable of detecting both overlapping objects, and disjoint objects which collide in forward-time. It is very robust, and is designed to fit perfectly with the upcoming networking changes we'll be making (see another aside below, on networked collision detection, for more info on why this is true).

Swept-volume collision detection is an active area of current research, so I guess you could say that T2D is right on the cutting-edge here. ;) We aren't doing anything too hyper-fancy (like leveraging GPU-acceleration for the sweep calcs), but the swept system we've got is pretty nice.

And you know what one of the best things about the whole system is? Despite the fact that Melv was working to get all this stuff implemented absolutely as quickly as possible, all of this code is very clean and very well commented. Even though this all involves complicated, math-heavy algorithms, you can actually read the code and understand it without even needing a piece of scratch paper.

The other cool thing about all this code is that it's fast. Yet, it's easy to use and extend. Imagine that, complicated chunks of code that are still clean, easy to extend, easy to interface with, and fast. I love Melv. :)

Quote:
Aside: Collision detection schemes
--------------------------------------------------------
Collision detection is a well-established field of study, but it's still researched very actively, in both academic and private fields like game development, CAD, CGI, robotics, and others. For anyone interested, here's a quick aside on collision detection. The goal of this discussion isn't to offer a detailed tutorial on collision detection algorithms (this .plan is getting long enough already). Rather, I hope to give a feel for how some common collision schemes work, so you can see a context for T2D's collision detection, if you aren't already familiar with these algorithms.

... Read more! ... this one is about 1.5 pages long, so it's broken out separately. Very briefly talks about the usual kinds of narrow-phase collision detection schemes: feature-oriented (Linn-Canny), simplex-oriented (GJK), and methods more appropriate for dealing with less strenuous CD constraints.

Quote:
Aside: Network-ready collision detection:
---------------------------------------------------------------
What's so hard about networked collision detection anyway? If you haven't thought about it much yet, read this quick aside and see why preparing for the inevitable move to networked simulation was so important for T2D.

... Read more!... this one is about 1.5 pages long as well, so it's broken also out separately. Offers a high-level overview of the problems associated with network simulation in general and as applied to collision detection in particular.

Quote:
Aside: A brief development history of T2D's collision detection system
------------------------------------------------------------------------------------
See how we got where we are today. Torque 2D originally had a very simplistic collision detection system, which Melv created just as a temporary placeholder. It used simple bounding box checks for collision detection and checked only for overlaps, in discrete time (see the aside above for a simple discussion on why this doesn't work too well in general, and especially not in networked games).

... Read more!... Another 1.5 pager, also broken out. Get the inside scoop!

Alright, we now have a pretty good understanding of how T2D's collision detection system works. It meets all the goals we set for it, including being highly configurable. It's capable of handling lots and lots of objects at once, yet returns accurate collisions against detailed collision polys, thanks both to the two-phase systems used and the speed of the actual code Melv wrote. And, it's got a headstart on networking.

For those of you who weren't already familiar with the subjects, I hope the asides on collision detection were somewhat interesting. Now, let's move on and look at T2D's collision response system, and its implementation of rigid-body physics.

Physics
Okay, we've looked at collision detection in T2D, so let's look at the other side of the coin: collision response.

T2D defines a totally customizable and overridable collision response system. The basic tenant was to first assume that individual developers will want the ability to create their own collision response schemes, either in C++, or in script. So, we tried to design the physics so that customization or replacement would be as simple as possible. For developers that don't want to implement their own collision response system though, we planned out a robust default system. T2D's default collision response system utilizes an impressive rigid-body physics model, which any object can plug into. And again, developers have the ability to leverage the default rigid body dynamics system to meet their own needs, by extending and customizing the default behavior (even just with scripts, using T2D's collision callback).

Before we go into more detail about implementing custom collision response, let's take a detailed look at T2D's default system. For all the talk above about how cool it is that T2D makes it easy for you to define your own collision response systems, or to extend the default system, I think one of the very best features of T2D now is its default rigid body physics capabilities. It feels great that all kinds of 3D engines this year are bragging about their rigid body physics... and here is T2D, starting to catch up with 'em, in one less dimension. ;)

Rigid-Body Dynamics in T2D:
Torque 2D's rigid body dynamics simulation models all the standard bells and whistles, including inertia, linear velocity, angular velocity, friction, restitution, relaxation, and damping, and has an easy method for applying impulse-forces and torque. If you aren't a pro with rigid body physics, check out the breakout section below for an overview of rigid body dynamics in general, and their simulation in games in particular. If you are already a pro (or just don't care to read all the junk in the breakout), skip over and continue on to read more about T2D's physics system.

Quote:
Aside: Rigid-body dynamics, real-time simulations, and Torque 2D:
---------------------------------------------------------------------------------------------------
This discussion offers a simple overview of the common algorithms used in real-time rigid-body dynamics simulations, and relates them to the physics system in Torque 2D.

...Read more!... this one is about 6 pages long, needed to break it out. Sub-sections:

Introduction
Methods of real-time rigid-body simulation
-Approaches for constraint and contact handling
-Integrators
Closing
References

Torque 2D's rigid-body system simulates Newtonian physics. Below is another breakout very briefly defining the physics terms used to describe T2D's simulation capabilities.

Quote:
Aside: Brief definition of physics terms:
---------------------------------------------------------------
Here are quickie definitions of the terms used to describe T2D's simulation of Newtonian rigid body physics. (For physics buffs and sim nuts, I'm just using commonsensical definitions here, not scientifically or pedagogically satisfactory ones)

Linear velocity - The speed and direction an object is moving at
Angular velocity - The speed and direction an object is rotating at
Friction - Resistance to moving or rotating
Restitution - Bounciness
Relaxation - Returning to a balanced state after a disturbance
Damping - Loss of energy over time

Configuring objects for use in T2D's rigid-body dynamics is very simple. You just need to enable automatic collision response for the object (see below), and set-up the object's physics parameters. These parameters include friction, restitution, relaxation, damping, density, and a force scaling factor. The parameter naming is obvious: the first four are the coefficients used to model the object's physics properties (see definitions above), density is used to calculate the object's mass based on the area of its collision poly, and force scaling is used, as you might expect, to lessen or heighten the net force applied to the object at any time.

Note as well that T2D once again leverages datablocks to make the process of setting up physics properties as simple and quick as possible for developers. T2D defines the fxCollsionMaterialDatablock, which contains the six parameters above. Multiple objects can share the same datablock, so using collision material datablocks can be a real development time-saver.

There are additional physics parameters which can be used. For instance, objects can be configured with maximum and minimum linear and angular velocities. They can also be affected by an individual, constant gravitation force, or be set-up to automatically rotate at a given pace. These additional parameters are part of the core fxSceneObject2D definition, and the corresponding datablock can be used to set-up these properties too.

Customizing physics:
So, T2D's default collision response system is pretty darn impressive. But, you're not forced to use it. Similarly to how collisions work, any object in T2D can have its ability to send or receive updates to/from the default physics system turned on or off. For more information on "sending" and "receiving" collision-related information in T2D, see the discussion on the subject in the collision detection section above.

For a T2D object which you want to be fully a part of the default physics simulation, you'd enable both sending and receiving of physics. For an object which you didn't want to part of the physics simulation at all, you'd disable both. If you wanted an object to be able to cause automated physical reactions in other objects, but not be affected by default physics itself, you'd enable the ability to send physics, and disable the ability to receive. You'd do the opposite if you wanted an object which could react to other objects using the default physics system, but that wouldn't initiate default physical responses with other objects itself.

In this way, you can completely (or partially) detach any object from T2D's default physics system. You are then totally free to implement your own collision response system, in C++ or even just in script. Or, you could customize the existing system, again, either in C++, or in script.

Should also note that the ability to turn default physics off is independent of whether collision detection on an object is enabled or disabled (though they are obviously related... turning off collision sending and receiving but turning on physics won't get you far).

All in all, besides having a great built-in physics simulation, T2D makes it easy for you to develop your own collision response / physics, if you so choose!

And that's a quick look at T2D's collision response! Pretty nitty-gritty details on how the physics system itself works can be found on the page linked in that aside. Now, with collision detection and response out of the way, all the hugely-long and boring sections of this .plan are done with. There are lots of other nice T2D systems to discuss, but they don't require very long-winded explanations.

Mounting
Torque 2D allows you to mount objects to other objects. A "mount" is an attachment between two objects. When you mount one object to another, the two objects can automatically move around together (more information on how mounted movement can be controlled below).

Now, any object can be mounted to any other object in T2D. As Melv mentioned in my last .plan, that means that you could even mount a tile layer to a particle. :) This is pretty cool, especially once you start considering all the neat stuff you can do with mounts.

It's really fast setting up mounts and you can have multiple objects attached to another. And any of those mounted objects can have one or more objects mounted to them. And those secondarily mounted objects can have other objects attached to them. And so on. :) So, it's easy to create long chains and big webs of mounted objects.

Besides that, you can mount objects to any point on another object. So, mounted objects need not be attached at the center of an object, and mounted objects needn't be spaced out evenly around their parent's perimeter or anything.

In addition, you can specify whether a mount should be rigid (such that the mounted object always stays the same distance from its parent), or use mount forces. With a mount force, you can dictate that a mounted object should move with its parent after the specified force is being exerted on the mount connection. When the parent object moves, a mounted object with a mount force will lag behind the parent's movement, catching up if/when the parent comes to rest.

For example, you can create a long chain of mounted objects, each with a mount force defined. Then, you can the parent object, move it horizontally and start shaking it up and down. If you've got your mount forces configured correctly, you'll see the chain begin to "slither" like a snake, with each object in the chain eventually moving sideways, and bouncing up and down. You can change the mount forces at any time too, so you could easily make parts of the chain whip quickly into position next to their parents, or stretch further behind. Or, if you'd had the same long chain of mounted objects and had specified that each mount be rigid, when the parent object started moving, the whole chain would move simultaneously. It'd be a straight line of objects, following the parent's movement exactly.

And that's not all... you can also do fancy mount rotations. For example, you can tell a mounted object to adhere to its parent's rotation, so that when the parent rotates, the mounted object will too (and rotations are controlled in the same way, via rigid or force-based connections). Or, you could tell the mounted object not to follow the parent's rotation, so that the parent object might be spinning away, but the mounted object isn't affected at all. Or, you can rotate the mount itself. In this scenario, the parent object might not be rotating, and the mounted object might not be rotating itself either, but the mounted object's position would be rotating about the parent object (so the mounted object is orbiting the parent). Neat! You can even set-up automatic rates of rotation for all these things.

Well the possibilities are endless here. In no time, you could set-up a boss with a bunch of mounted shields rotating around him that the player has to blast off or shoot between. Note as well that you can assign mounted objects to different collision groups, so it'd be easy even to do stuff like have a "fire shield", "ice shield", "water shield", etc that you had to hit with particular kinds of weapons.

I don't know... I'm just not a good game designer, but there's obviously tons of cool stuff you can do with this system. There are lots of creative people around here, so I'm sure you're already brewing up neat gameplay ideas that could take advantage this functionality. Also, mounted objects + physics = fun, believe me. :) This is another neat little system that T2D provides out of the box, and it makes it easy to pull off all kinds of fun pieces of gameplay.

Oh, almost forgot... there is also a "link" system in T2D. Link nodes / points can be set-up exactly like mount points, however links don't imply a relationship with another object. Rather, links can be used to track a specific point on an object. Say you have a spaceship with a big rotating gun... you could set-up a link point on the tip of the gun, and use it to spawn a projectile from the correct spot at any time. Very handy.

Layers and Groups
We've already discussed layers and groups a little in the collision detection section. But layers and groups are useful for more than just customizing and speeding up collision detection.

Objects can be assigned to layers, and you can specify that layers be sorted for rendering. In fact, the sort order for layers can be changed at will, and objects can be re-assigned to different layers at any time. Also, objects on the same layer can be assigned intra-layer z-ordering, and this ordering can be changed at any time. In this way, T2D gives you very fine-grained control over the z-ordering and rendering of your objects,

Unlike many 2D APIs / libraries, T2D doesn't limit you to using a small number of rendering layers. So, T2D makes it easy, for example, to set-up very nice-looking parallaxed backgrounds with lots and lots of layers.

And groups are a handy tool all around. You can use groups not only as a nice way to set-up collidable collections, but to help keep track of and manipulate logical classes of objects.

Object picking
There are many utilities in T2D that were put in to help developers handle common game problems. One thing that comes up a lot in games is object picking. Sometimes, you want players to be able to click on particular objects and select them. Or, if you were making a 2D RTS, you'd want to be able to let your players click-drag a box around units and select them all.

These are common object picking problems, and T2D has a nice picking interface. There are routines to pick objects that intersect with a point (mouse click), line, or area within the world. Picking is basically a collision detection test, and Torque 2D performs accurate picking against object collision polygons. This also means that it's easy to specify that a pick should only return objects in certain layers or groups. Again, if you were making an RTS, you might have a player's units in a group, so it'd be easy to pick just the player's units.

Also, it's possible to have custom pick functions. Tile maps, for example, have a special pick function which can return the logical tile(s) that intersect with a pick query.

This is just one example of the neat utilities T2D provides. Again, the goal throughout T2D's development has been "hey, let's make it easy for people to make 2D games!" So, we've tried to provide a bunch of stuff like this. Credit to Melv for caring so much about indie developers and wanting to put in the time and effort it takes to create all these functions, even though they're not the most fun things to implement.

World limits
The term "world limit" is a bit of a bad descriptor for what this particular system actually does. "World limits" in T2D are used to define the region in which a particular object can move around. Probably a better term would be "movement regions" or some such.

Regardless, world limits are a nice little feature of T2D. They allow you to set, on a per-object basis, the rectilinear area in which an object can exist in.

The world limit system is turned off by default-- T2D objects don't have world limits unless you explicitly turn them on for it-- because using world limits has a (small) performance penalty. Of course, performance was extremely important to us during T2D's design and development, so world limits were turned off by default.

When world limits are on though, you can do several neat things. Besides defining a valid area for an object to exist and move around in, you can also utilize various built-in world-limit collision-responses. By calling the setWorldLimit(...) method, you can specify what kind of response the object should have when it collides with a world limit.

The first world limit collision mode is "null", which tells T2D not to do anything special to the object when it collides with its world limit. Next is "rigid", which tells T2D to use the normal rigid-body dynamics system to handle world limit collision. Next is "bounce", which will bounce the object back from the world limit by perfectly reflecting the angle of incidence and maintaining the object's incoming speed. Next, "clamp" zeroes the object's perpendicular velocity component (colliding against a side wall of the world limit will result in the x component of the object's velocity being zeroed immediately). "Sticky" results in the object coming to rest against the world limit edge it hit. And "kill" results in the object being deleted once it reaches a world limit.

As with all collisions in T2D, world limit contacts are detected accurately against an object's collision poly.

Scenegraph
Torque 2D is a scenegraph-driven framework. (I'm assuming anyone who's read this far into the overview is already familiar with scenegraphs. If you're not, there are many good descriptions available online.)

We've already indirectly discussed many aspects of T2D's scenegraph in the sections on collision detection, physics, and layers here, and I won't re-tread. T2D's scenegraph uses a bin system to divide space and store locality information for scene objects. As per usual, this information is used to cull and optimize rendering, collision detection, etc. The scenegraph provides a great interface for initializing, querying and updating the scene, and you'll see many examples of how it can be used below.

The scenegraph is used to run the overall game simulation, and can be used to specify scenegraph-wide simulation parameters. For example, with one simple call to a scenegraph's setConstantForce(...) method, you can apply a global force to all objects in the scene which adhere to the default physics system. One obvious use for this functionality is to set-up (or modify) gravity for a scene. You can also pause the scene time at any moment, and resume it whenever you like.

The camera system in T2D is really flexible. You can set windows to cover a given area of the scene with a specific zoom level, and you can zoom, rotate, and pan the view any time. Also, you can give the view window a target position or area and have it move there smoothly over time from its current position. From there, you can undo / revert the view's move, returning to the old position. In fact, the last 64 view target calls are stored in T2D, so you can revert / undo up to 64 view moves. There are lots of cool possibilities with this system, and with just a little extension, you could define a nice easy interface for creating complex camera paths and scenes.

Man, so many other features. Check it out:

-Camera Mounts: the view window can be mounted to any object, and the mount can work identically to any other mount. So, you can make the camera follow an object (like the player avatar) with a rigid or force-based connection.

-Special effects: effects like camera shaking are easy. In fact, camera shakes are implemented specifically out of the box, and you can specify a shake period and intensity, as in Torque's own default camera. This is great for stuff like providing feedback when a player gets hit.

-Multiple scenes, multiple views! You can have multiple scenegraphs running at the same time, and multiple windows on any scenegraph. So, you can have multiple separate scenes, and/or multiple views of the same scene. (Nintendo DS, anyone? ;)

-Render filtering: You can dynamically filter what kinds of objects should be rendered at any given time.

-Scene saving a loading! The entire scene state can be serialized and saved at any time. Likewise, saved scene data can be loaded, and simulation can pick up right where it left off. Or, you can load a scene, pause time, and re-set any properties of the scene or its objects that you like.

Finally, the scenegraph is capable of detailed debug and performance reporting. You'll see in some forthcoming screenshots how nifty this system is. The collision poly, oriented-bounding box, and axis-aligned bounding box for all scene objects can be visualized at any time. And you can turn on automatic reports for all kinds of information, including: the total object count in the scene, the current FPS, the number of objects which are potentially going to be rendered (those which haven't been culled from the current view), the number of potential collisions, the number of current collision contact points, the percentage of objects currently colliding with each other, and the time it took to process physics for the current frame, amongst other information. Of course, you can also customize the debug and performance queries to provide whatever other information you'd like to have. These reporting tools are very helpful when it comes to debugging and optimizing a game!

The T2D scenegraph is really slick, and just having a hardware-accelerated, scenegraph-driven 2D engine is impressive in and of itself. Between this and the preceding sections on collision detection, physics, and layers, you should have a pretty good feel for what T2D's scenegraph is capable of. The scenegraph is basically the central system of T2D, which is saying a lot, considering all that T2D can do. So, it would take many pages to fully describe all of what the scenegraph can do and how it all works. Suffice it to say, the scenegraph + the base fxSceneObject2D class form the very core of Torque 2D, and the two provide an extremely powerful basis to build from, as I hope has been indicated by the discussion so far.

Torque integration
Torque 2D, of course, integrates with the overall Torque platform. Specifically, T2D takes advantage of Torque's cross-platform support, GUI system, scripting, and sound.

That's a lot of stuff to cover, but I assume folks here are familiar with these already, so I won't go into detail about them. But, one of T2D's biggest advantages overall is that it is built on all these great core Torque technologies. Just because it's built on Torque, T2D almost automatically becomes one of the only cross-platform 2D engines, and with Torque's system, it's set-up to go to even more platforms. It also gets to use a full-fledged scripting language and powerful console command processing capabilities. T2D gets a great GUI system for free (which is undergoing a major overhaul here at the office, btw, you'll see Ben and the rest of us talking about that more in the future), and the GUI editor to go along with it. Also, T2D gets to use Torque's audio functionality, so it has good sound support.

Just taking those things right there... even if T2D had just a normal rendering system, physics, etc, it'd still be one of the best engines around. Now, it's just insane. :)

Quick note: you've no doubt noticed that networking isn't part of the list of Torque technologies which T2D takes advantage of. That's true, for now. For the Early Adopter release, we've implemented a temporary networking solution. Essentially, you can use CommandToServer() and CommandToClient() calls to do many kinds of networked games. For example, T2D ships with an example networked multiplayer checkers game.

However, full-on, Torque-style networking isn't a part of T2D just yet. It will be very soon after the initial Early Adopter release though, and that'll be another outstanding system T2D gets to leverage for free.

The reason we didn't include full networking in this initial release is that we didn't want T2D objects to take on the overhead associated with deriving from Torque's GameBase class. For T2D, we'll be splitting out tick processing (similar to the work Pat has done recently) and implementing networking from there. That said, all of T2D's systems have been designed with networking in mind. Collision and physics are the stickiest things to get networked, and Melv and I were extremely mindful of the need to network those systems in the future when we were designing them.

Getting networking in won't be a difficult task, but we wanted to get T2D out into people's hands as soon as possible. It's already an outstanding solution for most games. Even people who have fast-paced multiplayer games in mind can pick up T2D now and begin learning to use it, knowing full-well that robust, highest-quality networking support as is standard with the Torque platform is on the way.

And with that, we've covered each of T2D's major core systems. Woo!

Of course, it's also important to note that you'll be able to get the full C++ source code for T2D (details on how you get it will be announced very soon). The code is all structured to be as clean to read and understand as possible, and one of the main design goals for the entire T2D architecture was to make it easy to customize and extend.

In addition, T2D ships with about 100 pages of detailed documentation (and that's not counting source-code comments). This documentation includes a tutorial in which a small game is built from the ground up, a detailed technical overview (a stripped-down and cleaned-up version of these .plans), and an object reference. So, you'll be covered when you start learning how to use and/or customize this sweet 2D engine. :)

Okay, thanks to everyone for reading. It was fun writing this .plan and I'm sorry it took me longer to get started on it than I hoped. But, I guess the upside there is that I was able to get lots done on T2D in the mean time! Hopefully some of you found this an interesting read.

Catch you all around, and watch this space for more T2D info in the very near future! Launch sequence starting in...

Tuesday Feb 1 1:25

Josh Williams — 2005-02-01T01:25:55+00:00

Exposing the seedy underbelly of T2D

In this .plan, I'm taking a first-pass at a technical overview for T2D. I'm hoping there are some crazy fools out there like me who can't seem to get enough details about cool technologies like T2D. So, hopefully somebody will find this (long and boring) .plan interesting (despite it's long and boring nature). (Update: this .plan covers T2D's core classes, read the next .plan to read about it's core systems![/url]

I'm sure this .plan won't answer all your questions about T2D, but it should end up being a nice overview. I promised to do something like this in my last .plan, so here we go!

To start off, for most of us here, all I really need to say about T2D is that it's developed by Melv May. :) For anyone that knows the guy, it is immediately possible to conclude with a high degree of confidence that T2D must, technically speaking, friggin rock. Melv has been working on T2D like a madman, and it is a quality product of outstanding engineering.

All told, T2D represents about 9 months of dedicated, impassioned work on Melv's part, and by us here at GG for the past 6 months or so. I know how much thought and effort has been poured into T2D, because I've been right there for most of the ride. I've already got great memories of late-night chats with Melv where we approached every design decision from a hundred angles, trying to make sure we'd end up with the best 2D game engine out there.

I'm very proud of Torque 2D. I think every day we get closer to achieving our goal for this engine, and by the end of this year, I do expect T2D will be far and away the best 2D game engine around. I love being a part of its creation.

Even at this point, as we push to finalize T2D for its Early Adopter release, the engine already has numerous advantages over other 2D engines. It'll be very exciting to see what the early adopters do with all this power, especially as the year goes on and we add easy to use editors and more core technology.

Okay, if I were reading this .plan right now, I'd be skimming ahead to get to the juicy parts, so let's just have at. :)

Below, you'll find a pretty detailed technical write-up on T2D's core feature set. It's long, and it's dry, so most people will probably just want to skip or skim this one. But for those of you out there like me who love reading this kind of stuff... enjoy!

T2D Technical Overview

Overview
Torque2D is a platform for 2D game development, built on top of the Torque Game Engine. This means T2D gets to leverage Torque's scripting, sound, platform, GUI, and other core systems. T2D implements its own scenegraph-driven, hardware-accelerated 2D rendering and game world systems.

In addition to the systems provided by TGE's core, Torque 2D's custom systems include everything you want in a 2D engine: sprites, tiles, particles, collision, physics, advanced camera capabilities, object mounting, parallax scrolling, rendering layering, object picking, and more. Each system is designed for power, ease of use, performance, and to be as readily customizable and extendable as possible. Scene saving and loading, multiple viewports, debug rendering and easy to visualize performance statistics, along with about 100 pages of tutorial and reference documentation round out the package, with many time-saving editors on the way.

Let's look at the primary classes T2D defines:

Core object fxSceneObject2D
T2D defines a base class from which every other major class is derived, the fxSceneObject2D. fxSceneObject2D provides:

Extendible, efficient swept-polygon collision detection
Rigid-body physics
Unlimited, hierarchical object mounting
Assignment to rendering layers
Object picking with points, lines, and areas
Individual world-limit definition, clamping and collision response
Object scaling, rotation, and automated / fixed rotation
Object serialization
Scriptable interface and callbacks
Debug and performance reporting
Customizability and extendability for simple creation of custom objects

fxSceneObject2D has no rendering overhead, and since all of the performance-heavy functions (eg collision detection and response) it does implement can easily be disabled, it is a perfect core class on which to build other, more specialized classes. Since all of T2D's primary classes are built on the fxSceneObject2D, every object in T2D inherits the powerful capabilities listed above.

Each of these capabilities and systems will be described in more detail later. First, we'll cover the fxSceneObject2D subclasses.

Sprites fxStaticSprite2D, fxChunkedSprite2D, fxAnimatedSprite2D
T2D has a very impressive sprite system. Sprite rendering in T2D is ultra-fast and sprites, like all T2D objects, can be scaled and rotated in graphics hardware. Sprites are divided into two main kinds: those with complex animation capabilities, and those without.

fxStaticSprite2D
The fxStaticSprite2D is a general-purpose sprite, allowing you to place (and move) renderable shapes in your scene that don't require complex animation sequences. The "static" in the name refers to the animation frames, as opposed to the object's ability to move around in the scene. Static sprites are perfectly free to move about the scene, and their rendering frames can even be changed, but they don't have a powerful animation interface.

fxStaticSprite2D uses an "image map", defined as an fxImageMapDatablock2D, to identify it's graphics frames. More information on image maps can be found below, but the basic idea is that image maps are used to load a sheet of images for use by sprites (and scrollers, tiles, and particles).

fxStaticSprite2D objects can be moved around the scene, and can have full collision, physics, etc. Again, these objects, like all the core objects in T2D, derive from fxSceneObject2D which provides a very powerful base to build from.

Related to the fxStaticSprite2D is the fxChunkedSprite2D. These sprites are very similar to static sprites, but are better for handling very large imagery. In particular fxChunkedSprite2D uses the fxChunkedImageDatablock2D, which is capable of loading imagery from non-power-of-two textures. More information on the fxChunkedImageDatablock2D can be found in the appropriate sub-section below. Ultimately, this interface for loading imagery from non-power-of-two sources will be simplified even further, but for now, T2D makes it easy to load images from any source by using these chunked resource capabilities. The fxChunkedSprite2D is also capable of tiling sprite imagery across its surface, according to parameters you can set.

fxAnimatedSprite2D
The fxAnimatedSprite2D provides very powerful tools for creating, playing, and managing animated sprites. Animated sprites (and animated tiles and particles) rely on animation datablocks and animation controllers in order to play animations. In order to get a grasp of the fxAnimatedSprite2D, we must first examine these systems:

The fxAnimationDatablock2D datablock class can load frames from an image map and define an animation as a chain of frames. The animation datablock can then define the play time of the animation, and set whether the animation cycles, and even whether the animation should start playing with a random frame.

The fxAnimationController2D is a utility class used by fxAnimatedSprite2D (as well as by animated tiles and animated particles) to control and play animations.

The fxAnimationDatablock2D and fxAnimationController2D abstract the process of defining, setting up, playing, and manipulating animations. Since there are multiple kinds of animated objects in T2D, this is very convenient, as each animated class can utilize the same functionality. This encapsulation of behavior is also nice because it allows you to easily define your own custom animated classes by leveraging the functionality provided by the standard animation classes.

Now, with all the animation functionality provided by the animation datablocks and controllers, creating animated sprites is a fairly simple matter. fxAnimatedSprite2D::playAnimation(name) is used to play a particular animation, as defined and controlled by the sprite's animation controller. fxAnimatedSprite2D also defines a callback function, onAnimationEnd(), so you can perform some custom actions when an animation ends.

Note that static sprites have none of the animation overhead incurred by the fxAnimatedSprite2D. Thus, while all sprites could really be animated sprites with no animations defined or played, it was decided to create the specialized static sprite class, just for that added bit of specialization and efficiency. Structuring things this way also makes it easier for people to get a grip on sprites-- making it as simple as possible for people to set-up basic sprites, without worrying about any extra calls or functionality, is a good thing.

That's the overview of sprites in T2D. Sprites are pretty much the core of most any 2D game, so Melv was careful to treat 'em right, and we've all been careful about suggested modifications to these core classes.

Setting basic properties and loading images datablocks, and image maps
Torque2D makes heavy use of datablocks. (If you aren't familiar with Datablocks, I encourage you to read the scripting documentation here on the site). Every object in T2D has a datablock associated with it, which can be used to configure its initial or static properties.

Image maps
Image maps, or the fxImageMapDatablock2D, are some of the most important and most used datablocks in T2D. As described above, image maps can be used to load imagery from a sheet of frames. Image maps essentially read textures and then extract image frames from the texture. These image frames can be extracted in one of three ways: single frame, color-keyed, or celled.

Using single frame extraction will result in an entire texture being loaded as a single frame.

To use color-keyed extraction, the source image must be separated by lines of a particular color-- each image to be extracted must boxed-in by straight lines of this particular color, and the color must not be used anywhere else in the image. Often, people use pure black, pure green, or bright pink for this key color. When in color-keyed extraction mode, the image map reads the upper-left texel on a texture and sets that as the color-key. Note that this is the same system used to define image maps for GUI controls in standard TGE.

Celled extraction means that the source image is split into a regular grid of equally-sized cells, and that each cell should be loaded as a separate image frame. You specify the size of each grid, and the number of grids, and the image map can load any frame from the source texture.

Image maps, again, abstract and encapsulate the process of loading graphics frames from source imagery. This way, multiple objects can extract renderable frames from a source image without having to do the actual loading work themselves. This architecture also means that multiple objects (even of different types) can use the same image map to load their particular animations. This can end up saving texture memory usage, by decreasing the need to define redundant animation frames in separate textures. Once again, this functionality also makes it easy to define your own custom, renderable objects by utilizing the image map's frame loading functionality.

Besides the normal fxImageMapDatablock2D, there is also the fxChunkedImageDatablock2D, as mentioned above. This datablock is similar to the normal image map, but allows for loading from non-power-of-two sources. Again, the interface for handling non-power-of-two source imagery will be simplified soon after the initial Early Adopter release of T2D, but this system provides the baseline functionality needed to allow people to load from irregular sources.

Okay, now we've got some basic ideas about T2D down... we know a little about the high-level features provided to all T2D objects by the fxSceneObject2D, we know about T2D's sprite capabilities and animation system, and we have an understanding of T2D's architecture for loading images.

Next, we'll continue digging into each of the objects provided in T2D, and then we'll go over the major processing systems provided by default in T2D and the core fxSceneObject2D.

Scrolling backgrounds fxScroller2D
T2D provides a really simple way to get scrolling backgrounds in your game. There is a more powerful methodology for backgrounds in T2D, (..tile maps, which are discussed below) but the fxScroller2D provides a very simple, efficient way to use scrolling backgrounds.

fxScroller2D loads its image using the image map interface (and can only have one frame). This image is then scrolled, according to parameters set either in the fxScrollerDatablock2D, or by calling the setScrollMode(mode, dx, dy) method. Mode is a boolean parameter specifying whether the scroller should scroll or remain static, and dx and dy define the scrolling speed, in world units per second, to be used.

Regarding world units, T2D has a nice system for handling coordinates in your game world. Whether working with the game world itself, with background scrollers, tiles, sprites, or anything else, you don't need to worry about the actual pixel size of anything-- T2D does all the translation for you, and you can simply work in world coordinates. This kind of functionality is standard in 3D engines, but (surprisingly) some 2D engines out there don't provide this nice level of abstraction. Scrollers are one area where this consistent coordinate system is very useful.

Again, the main advantage of fxScroller2D objects is that they are very easy to set-up, and very performance-friendly. They can also be used to get parallax-scrolling up and running in no time. By defining multiple scrolling backgrounds, you can easily sort and assign them to different rendering layers (more info on this later), and assign different scrolling speeds. Thus, scrollers in the far background can scroll slowly, while those in the foreground scroll by rapidly. This creates the cool, pseudo-3D "parallax" scrolling effect common in many 2D games, and it's incredibly easy to get going with Torque 2D.

Tiles
I've looked very thoroughly at a lot of 2D engines out there, especially the major, well-known ones, and I am happy to say that T2D is well on it's way to having the most powerful and flexible tile system around. It took us quite a bit of wrestling to figure out the best way to handle tiles, lots of lunch discussions with Pat and Alex here at GG, and many more late night design sessions with Melv, but we finally ended up with an outstanding system. There's still more work to do on tiles, but the core system is in place, and I'm very happy with it. Let's check it out:

One impressive feature of T2D's tiles is their integration with the physics system. Objects can collide with tiles, and these collisions can generate full physics responses (on the objects). Given how powerful T2D's collision and physics system is, this is a very nice, and uniquely powerful, feature of the tiles. It was also a tough one to get in, let alone to make performant. After some long conversations about how to handle the tiles, Melv and I came up with an excellent plan for them, and Melv knocked the implementation out of the park. The tile interaction in T2D is really great (and we're not done yet ;)

Overall, there are three kinds of tiles in T2D: static, animated, and "active". Static and animated tiles are very similar to their sprite counterparts, and they use the same encapsulated sub-objects to manage their imagery and animations. The cool thing to note here is that T2D supports richly animated tiles, should you wish to use them! Not all 2D engines do. :)

Active tiles are a different animal. Active tiles define a skeleton which you can use to create tiles which actively affect the world. One example that's been talked about before is creating turrets as active tiles in your tilemap. This has some efficiency advantages versus creating a tile layer and associating a stand-alone turret object with it. There are lots of creative ways to take advantage of this functionality. We (probably) won't ship the Early Adopter version of T2D with a good example of an active tile, but soon afterward, we should produce some. Eventually, we both expect that there'll be libraries of active tiles out there people can use and customize.

Another neat feature of T2D's tile system is that each tile object can have an associated script which runs once the tile is displayed. Again, this is a cool little feature that allows you to more easily create really dynamic tiled environments.

T2D tilemaps can also be panned, in any direction (with a little bit of set-up work)

Object picking also works for tiles-- you can, for example, determine exactly what tile (if any) currently lies directly beneath a current screen or world-space point.

Those are some of the big features of T2D tiles. Now, here's how the system works in general:

T2D stores tiles, at the highest level, in a tile map-- fxTileMap2D. fxTileMap2D objects create, maintain, and destroy fxTileLayer2D objects, which in turn handle the virtual tile objects. fxTileMap2D can load and save maps from and to disk.

The fxTileLayer2D object is the meat of the tile system. Where the fxTileMap2D class provides some high-level loading and management routines, fxTileLayer2D actually does the dirty tile work. Tiles are simply defined as a grid in the tile layer, and the tile layer can control any individual tile, determining whether the tile is static, animated, or active, setting the tile's script callback, changing the tile, etc.

The tile map can set-up the tile layer's actual dimensions, and how many individual tiles it contains.

The tile layer has some convenient features: for example it has a layer clear, which will remove all the information on the layer's grid. Also, there are fine-grained animation controls on the tile layer, for example, you can force an animated tile to be "unique", which means it will use it's own instance of an animation controller, so as not to be affected by potential changes to a central controller (non-uniquely animated tiles are animated together, and save some memory overhead and cpu overhead, as they all rely on the same instance of an animation controller). Tile layers can also be panned, and can be set-up to for auto-panning at a fixed rate. Tile layers can be wrapped as well-- in fact, you can control wrapping behavior independently along both major axes.

Another important consequence of the tile layer's structure is that individual tiles can be deleted (cleared) and changed at any time. So getting some truly dynamic and active tile maps is easy in T2D, you're not simply confined to static backgrounds and collision imagery.

That's where things stand at the moment. We have even more plans for tiles in T2D, but we'll wait until after the Early Adopter release to go into them in more detail. One thing I will say now though is that we'll have support for non-rectilinear tiles as soon as possible. For now, we just wanted to get the core backbone of the tiling system up and running. We achieved much more than we originally set out to achieve with the tile system, I think. And with this infrastructure in place, adding in new tile types won't be very difficult.

Great. So, there's all this awesome tile support in T2D. But, how do you load tiles? It'd be a royal pain to have to set-up tile maps all by hand in script. Thus, T2D will ship with an FMP loader, meaning you can load tile sets created in the well-known (and cross-platform) Mappy tile editor. Then, you can take advantage of T2D-specific tile functionality via script setup. In the future, we'll either be creating our own tile editor, or extending an existing editor (perhaps Mappy).

Particles
Okay, I'm going fanboy mode here, I can't help it:

Particles are incredible in T2D. In my opinion, T2D has the most impressive real-time particle system in any engine. Once we get a finalized, user-friendly particle editor in, I know T2D owners are going to lose hours and hours of time just creating pretty particle effects. I love this system, and I have to give all props to Melv for coming up with it.

So, how's it work?

There are three layers to the particle system: effects, and emitters, and particles themselves. Effects contain an unlimited (virtually) collection of particle emitters, and control these emitters over time. Particle emitters spew particles in a fine-grain controllable, time-dependent manner. Particles themselves are like very lightweight, efficiently rendered animated sprites as they can utilize animation controllers to change their rendered frame over time.

fxParticleEffect2D
Particle effects are essentially a large collection of specific fields and particle emitter sub-objects which are used to define a particle effect. The effect's fields can be split into two groups: those which change over time, and those which are static.

Fields which change over time are controlled via a time-graph system, meaning that you specify time and key-value pairs for these fields. For each field, the effect will interpolate between the currently adjacent key-values, arriving at the proper values at the specified time.

For example, the quantity_scale is a time-dependent particle effect field. This field, like many effect fields, specifies a value by which to multiply the particle emission quantity specified in the effect's particle emitter objects themselves. Essentially, this provides particle effects the ability to override their sub-object emitters' settings, inducing effect-wide changes in emitters.

In this example, we might specify that we want all emitters that are a part of this effect to begin spewing particles faster and faster after two seconds, peaking at twice their normal rate after two more seconds, and then ramping down to their normal emission rate after another second. To do so, we'd specify time and key-value pairs for this field: (time, key-value) : (2.0, 1.0), (4.0, 2.0), (5.0, 1.0). In script, assume we have a whole particle effect set-up, then applying this change to the effect would work like so:

%exampleEffect.selectGraph("quantity_scale");
%exampleEffect.addDataKey(2.0, 1.0);
%exampleEffect.addDataKey(4.0, 2.0);
%exampleEffect.addDataKey(5.0, 1.0);

This tells the effect that we want it to ramp up all of its particle emitter's particle emission quantities to twice their normal rate between seconds two and four of the effect, and to be back to normal by the fifth second the effect plays.

An example of a non-time-dependent field is the effect's timeRepeat, which is accessed via getTimeRepeat() and setTimeRepeat(scale). This field affects the timescale of all emitters that are a part of the effect.

fxParticleEmitter2D
Emitters are actually very similar to effects, they utilize a similar system of fields, and whereas effects spawn emitters, emitters spawn particles. Emitters define a long list of fields which can be used to control particle emission behavior. These fields are also split into two groups: time-graph controlled, dynamic fields which are interpolated over an unlimited chain of time / key value pairs, and static flags which parameterize the emitter's general behavior.

Examples of dynamic emitter fields include particlelife_base and particlelife_variation. These two fields are used to determine the lifetime of each particle spawned by the emitter. The base component defines the default particle lifetime, while the variation component defines a range [-variation, variation] of deviance from the base value. This variation is randomly distributed, using a standard linear random generator.

Emitters use this base / variation concept for many of their dynamic fields. The particle emission quantity, particle size, particle speed, emission force, and other fields all use this dual base / variation time-graph controlled paradigm. Other fields don't use it, for example, visibility_life is time-graph controlled but has no variance. This field controls the length of time for which each particle is visible.

Now, all this leads to a very powerful, highly flexible particle effect system. But it'd be awfully nasty if you had to control it all via scripting. Luckily, T2D Early Adopter comes with a (very basic!) particle editor. This saves you from ever having to script any particle effects. The Early Adopter particle editor isn't at all the prettiest or most user-friendly tool ever made, but it is fully functional and you can do anything with it that you can in script.

Emitters efficiently handle particle spawning and control, keeping a particle pool handy to minimize memory allocs. Particle rendering is quite efficient as well, though there are still some important optimizations to make after the Early Adopter release.

Emitters also provide a rich interface for querying their current field values, and include debug rendering information.

What's more, particle effects can be saved to disk, for later re-use.

Very cool. And that's not all... like all of the standard objects in T2D, particle effects are derivatives of fxSceneObject2D. That means effects can be manipulated like any other object.. they can be moved, mounted, scaled, assigned to groups and layers, and even have physics interaction!

I don't think even Melv fully realizes how cool this system is. And if he does, then he's way the hell too humble about it. By all rights, he should be out screaming his head off about what a badass he is for creating it. :) In all honesty, I'd pay just for a real-time particle effects system like this. There are particle systems without as much power (let alone being real-time!) as this system out there that people pay pretty big bug bucks for, for use in film, scientific visualization, etc.

Once we have a polished particle editor, I bet all kinds of people will produce dazzling particle effects, and I'm sure we'll all while away hours just sitting around staring at them. Mmm.. shiny.

Note: the T2D reference documentation contains a complete list of every script-accessible field and method for particle effects and emitters, as it does for all objects in T2D.

Further Note: presently, T2D interpolates over time-graphs only linearly, but in the future other common interpolators will be implemented.

Scoop: just a couple weeks ago I was contacted by two experienced engineers who are interested in porting this particle system up to Torque (and TSE). So, no promises, but watch this space for more details. :)

With that, we've covered the basic objects found in Torque 2D. Between the core scene object, sprites, scrollers, tile maps, and particle effects, you have all you need to make every kind of 2D game.

I'm just realizing that this .plan is almost ten full pages long already. If I'm lucky, maybe two or three people out there actually read the whole thing. It's still not done yet, but it'd probably be best to split this technical overview up into two pieces. This .plan covered the core objects in the engine, so watch for Episode II: Attack of the Core Systems tomorrow! (Or very soon afterward, depending on how much sleep I'm willing to deprive myself of tonight). You can see the outline for tomorrow's .plan below. (Update: the next .plan is out :)

Thanks for reading. If you made it straight-through the whole thing, with its utter lack of pictures or funny personal anecdotes or really any redeeming qualities of any sort, hats off to you, friend. You are indeed a hardcore technophile. ... You pervert.

Collision

Physics

Layers and Groups

Mounting

Object picking

World limits

Camera

Scenegraph

Torque integration

C++ source available

Detailed documentation

(continued in the next .plan

Wednesday Jan 12 13:16

Josh Williams — 2005-01-12T13:16:56+00:00

Torque2D!

Well, this is a .plan I've been anxious to write for quite some time: Torque 2D is almost here!

As we speak, T2D is out for what should be the last major testing cycle it needs. We can't wait to see what everyone is going to do with it... this is going to be a fun year.

T2D is coming out under the Early Adopter program, at a reduced price, and it'll be released very soon! We want to bring you all on the inside early again, as with TSE. Early Adopter means you get your hands on the technology as soon as possible, and get an inside line as we develop more tech, tools and editors.

Work will continue on T2D until it's the best little game maker ever. :) Of course, it feels like we're practically to that point already, so I'm very glad T2D's launching sooner rather than later. The technology in T2D is way beyond "Early Adopter", more than stable enough to use in serious game development, and we can't wait to get equally powerful tools into everyone's hands.

Shots from a T2D IGC demo, thanks to Alex Swanson and Pat Wilson.

Torque 2D is all about rapid development. It takes care of the technology, and let's you focus on gameplay and art.

Bleh, that probably sounds like marketing-speech. Look... let me be honest, I don't know what to say other than... I have a very hard time not asking Jeff if I can go on a 3 month sabbatical and just make a game with T2D. Seriously, I get to work with it a lotat least a little every single daybut not enough. I would like nothing better than to make a T2D game. It's that good. This thing is Melv's baby, so I can brag on it without being too pompous... it is amazing . I'm proud to be a part of the development, and of Melv for doing such an outstanding job.

Check out the features:

Sprites (static and animated)
Tiles (static, animated, dynamic, script-executable, unlimited layers, import from popular formats, fully scrollable)
Collision (swept-poly collision, highly optimized, returns rich info: contact points, normals, time of impact, etc, collision with individual tiles)
Physics (full rigid-body dynamics: linear and angular velocity, mass, inertia, friction, torque, etc)
Particles (well... wow... watch the video)
Documentation (tutorial, demo mission, and complete reference guide)
Complete C++ Source
Beginnings of editors: particle, animation... sprite, tile, and much more coming
Tons more... too much to mention really... parallax scrolling, mounted objects, statistics / performance HUD, object debug rendering, flexible camera, object picking, scene saving / loading, fully scriptable, Torque integration, much more!

In my next .plan, I'll go over all these features in detail, and watch for more info from Melv soon too.

And did you catch that? C++ source... T2D was going to be binary only, but we decided that we had to see what people could do with the source in-hand. Torque SDK owners will be able to purchase the full T2D source code. Going to be fun seeing all the crazy stuff people do with it.

In the end, there simply isn't a more powerful 2D engine out there. We're very, very excited to launch T2D.

Speaking of which, we'd love to roll out with some great demos, and if you'd like to help out, we'd be glad to give you a free copy. Watch the forums in the next couple days for more details!

Shot from a T2D IGC demo, thanks to Alex Swanson and Pat Wilson.

On a final note, and I don't mean to get too mushy here but... Melv May is an absolutely incredible guy. T2D is his baby (besides his new, beautiful daughter), and it's got his mark all over it. It's phenomenally well engineeredif you look at T2D and really consider all the design, production, and implementation decisions, you quickly realize how truly smart Melv is. Moreover, he is incredibly easy to work with, and one of the nicest guys I've met. One of the things I like most about my job here as GG's "3rd Party Development Director" is getting to work closely with guys like John Kabus, Dave Wyand, the crew over at BraveTree, Ed Maurina, Ken Finney, Melv, and many more. All these guys are shining examples of indie developers.. and more than that, they're indie developers who are just as passionate about helping other indies out as we are here at GG. Melv, it's been a pleasure working with you bud. :)

Just had to spout a bit and give Melv proper credit for all his hard work... he's been working like a machine (despite my encouragements to take a break, once in a while at least). I hope he is very proud of T2D, I certainly am.

I'd also like to say thanks to Pat Wilson for helping out with T2D. Pat took on the task of implementing some of the less fun pieces of code we needed to write in order to make T2D a great product, and he, as always, did an excellent job. I know Melv and I both would like to thank him for the hard work. Alex Swanson helped put together a couple cool-looking IGC demos too, and it's always fun to see Alex show off his art skills.

Thanks for reading everyone... this was probably a bit dry, what with the relative lack of pictures and all, but watch for more next time. In my next .plan, I'm going to bore some people (and probably interest some others very, very much), and dig deep into some of the technical features of T2D. Melv will be doing some cool .plans as well, so watch the page!

(Previous T2D .plan (from Melv))