Torque 2D: Informal technical overview - brief development history.
This discussion offers a brief development history of Torque 2D. This information is part of a .plan file created during the development of Torque 2D.

The first version of T2D that Melv brought to us was very cool, but it was definitely a long way off from where it is now. For example, back then, T2D used bounding-box collision checks, and checked only for overlaps in discrete time (see the aside on networked CD for a simple explanation of the problems associated with this kind of collision detection). As such, collisions weren’t accurate, and definitely not network-ready. But, it was all good, Melv just created that simple system as a temporary place-holder. In the months following the initial code drop we got from Melv, he worked a lot on Torque 2D, and so did Pat Wilson and I here at GG. Much as T2D rocked back then, there was still a lot to do before we could release it!

As for collision, we thought at first that we’d just leave the simplistic collision scheme in T2D for the initial Early Adopter release. Early on, both Melv and I were hesitant to do that, but we weren't sure if people would rather have T2D early and just deal with the poor collision.

Soon, November rolled around and we were, at the time, trying to ship T2D before the Christmas holiday. However, Melv and I thought more about it, and decided we weren’t comfortable with actually shipping the first, place-holder collision scheme. Besides the obvious problems with collision fidelity, the system also wasn’t adapted for the tile system yet (which was in active development at the time). Plus, if we were later to change the collision scheme, we knew that the collision interface would need to be changed from this simplistic place-holder implementation. So, that meant that when we switched T2D projects would need to re-do a lot of their project’s code if they wanted to take advantage of any collision updates provided for T2D’s CD system.

After a lot of thought, Melv and I decided that if time was going to be spent getting the collision system working with tiles, we didn’t really want to spend it working on the original, unsatisfactory collision system. If we were going to touch collision, it seemed we should invest a little extra time to create a system that was more robust overall.

There was some internal debate at GG about which way to go, and understandably so. We all want to ship to T2D as quickly as possible, since we can’t wait to see what everyone does with it, so a delay wasn’t palatable to anyone.

By the time we got around to thinking about this decision carefully, we knew that implementing a new system would mean we’d miss the holiday deadline. So, the decision really boiled down to either shipping T2D right away, with a simplistic collision detection scheme that wasn’t even hooked into the tile system, or to delay shipping for a little while and implement a rich, robust collision system that integrated well with the tile system, considered networking as a fundamental component in its design, and would actually end up being one of the strongest points of T2D’s featureset.

It was actually a hard decision. Believe me, everybody wants T2D out in the wild as soon as possible… it’s exciting and the wait for T2D is killing us too! Ultimately though, we all agreed that it would be for the best in the long run to implement a new collision scheme. I have to thank Jeff for excellent leadership here, and throughout T2D’s development. He gave some very valuable input on the situation, and demonstrated a lot of trust in Melv and my opinions.

Melv and I were really happy that everyone was on-board with the decision to change the collision detection scheme. But now that we’d promised a badass new collision system, we had to figure out exactly how it was going to work. Eep! After catching up on some research and many long discussions, we came up with a good plan.

We started out thinking we might just use swept-spheres to take care of our basic collision fidelity goals. We looked at Zap’s collision system (check this nice paper on swept-sphere and ellipsoid collision detection). After careful consideration, we decided (and Melv was particularly convinced) that swept-ellipsoid checks were insufficient for our purposes. Of course, this led to more late-night design and algorithm discussion sessions! In fact, I just found a 20+ page email + IM conversation between Melv and I back in November when we were deciding for sure what collision system to use.

Finally, we decided full swept-poly vs swept-poly collision checks would be the best decision. Melv implemented some impressive test code in no time, and after seeing the results, we were both solidly in favor of the new design. Another benefit of this system is that it allowed rich, detailed collision detection, which would make it easy to feed into a more advanced physics system (see the section on physics in the .plan).

Melv and I were very happy with our final decision, and we’ve never looked back! The collision system is just plain cool, and it’s great to put all that power in indies’ hands. There’s still more to do (whoa.. put down the pitchforks and disperse the mob… I mean there’s more to do*after* the Early Adopter release… we’re getting this thing out the door for you guys ASAP now). We have many ideas for even more cool stuff we hope to implement in the coming months, but this system is very nice, as is.

I should note too that the entire time since the holiday season hasn’t been spent on collision development or anything. Melv had 90% of the collision and physics code done by the beginning of January. Our time since then has been spent doing all the little things it takes to make a “project” into a product. In retrospect, whether we’d updated the collision system or not, shipping before the middle of December would’ve been impossible (or would’ve required an even harder crunch than we were already putting in).

So, that’s the brief dev history of T2D’s collision system. All-in-all, research, discussion, and design time aside, it probably only took Melv 40 hours to implement fully, which you’ll find awfully impressive once you get a look at the code and exactly what it does.

-Josh Williams
GarageGames
Return to the T2D informal technical overview .plan