Blog for Stephen Zepp at GarageGames.com

TGB 1.7.3 released for PC and Mac!

Stephen Zepp — 2008-05-15T00:05:08+00:00

UPDATE: The Mac versions of TGB 1.7.3 are now available in your My Account link!

It's fun, it's super-charged, and most of all, it's a free upgrade...GarageGames is pleased to announce that Torque Game Builder 1.7.3 is released for PC!

Curse of the Pharoah--made with TGB

So what's new?

The 1.7.3 release is a combination of three major areas:

Physics enhancements, optimizations, and fixes

TGB's built in physics system has received a lot of love over the last couple of months, with super star Melv May leading the way to the most powerful TGB physics available. Here's just a quick list of the enhancements and updates:

*Added tick-physics smooth object rotation.

*Added tick-physics smooth particle interpolation.

*Added per-tick scene callback.

*Added "t2dSceneObject::getRenderPosition".

*Fixed tick-physics mounting issues.

*Fixed physics interpenetration issues.

*Fixed physics collision response issues.

*Fixed collision callback reporting issues.

*Fixed position-target system issue.

*Fixed mounting bug in t2dTextObject.

*Improved circle/poly circle/circle collision detection code.

*Improved t2dTrigger performance

*Improved contact-history renderer.

And a couple of quick videos if you missed them in the 1.7.3 beta announcement:

Integrated aStar Pathfinding
aStar Pathfinding has been available for TGB source code owners for quite a while now, but for the first time 1.7.3 makes this powerful capability available to binary owners with a fully integrated C++ algorithm built into the core engine.

Here's a small sample of some of the cool new things you can do with both binary and source licenses:

*Tile Map based weight grids to represent your world

*TorqueScript interface to path creation, following, and obstacle avoidance

*Real time modification of the weight grid with easy script calls

*High performance C++ implementation

New Game Demos and Enhanced Documentation
Through extensive effort from GG employees, interns and external consultants, we've greatly improved the reference documentation available with extended details on objects, method calls, and even game genres through the new Solitaire, Blackjack, Reactor, and BehaviorShooter demos.

We're excited about providing these new documentation and learning tools, and are looking forward to continuing to provide the information you want to make the games you love!

Community rocks!

Quite a few community members made this release what it is, and it wouldn't have happened without the users helping make TGB all it can be. Here are a few shining examples of community members that contributed their projects, effort, and ideas:

Fueling Melv's bug stomping machine with high calorie input:
Benjamin L. Grauer, Ken Pajala, Bruno Campolo, Patrick Shaw, Thomas Bang, Kevin James, and Wenceslao Villanueva Jr. -- by submitting their entire projects directly to Melv during the development of this release, we were able to cover just about every possible case where physics bugs could cause problems for developers. Thanks again guys!

Discussion is the spice of life!
Our products become better every time you, the users, let us know what you like, what you want more information on, and how you would like things to work differently--and here's just a short list of some of the folks giving us high quality feedback for this beta:

Mike Lilligreen, James Ford, Rodney Rindels, Marc Shaerer, Phillip O'Shea, and one of our most recent new TGB developers, Ola Falck Sprauten represented the community by asking questions about aStar, pointing out bugs and issues, and otherwise interacting directly with the developers of 1.7.3. Thanks!

Apologies in advance if I've missed anyone--everyone's posts, questions and suggestions are very beneficial!

"Thanks Mom, I couldn't have done it without you!"

Ok, so she didn't have a lot to do with this release, but there were a lot of folks behind the scenes that made this release possible!

Matt Langley -- From the documentation system assistance, to managing the external portions of this release, all the way to helping track down those hard to find bugs, Matt helped a ton with getting this release out the door.

Derek Bronson -- Derek was a fundamental driver in making sure this release became all it is--thanks for seeing the value in a part time prototype that set the stage for getting aStar into TGB!

Deborah Marshall -- some people think herding cats is hard, but it's trivial compared to wrangling developers--thanks for keeping an eye on things and making sure 1.7.3 went well!

Ken Holst -- the only guy I know who can even find bugs on Mother's Day--much respect man, much respect!

Paul Scott -- Mac users rejoice--without Paul's help, the Mac version of 1.7.3 wouldn't be released. Send this guy a beer, or at least an email if you can't fit a bottle through your network card!

Carribbean Hideaway--fun to the power of Torque!

Announcing TGB 1.7.3 Open Beta!

Stephen Zepp — 2008-04-29T00:07:03+00:00

GarageGames is excited to announce the TGB 1.7.3 Open Beta!

Remember all that talk about community participation and transparent development? We're doing it again. We've done a lot of work (probably way more than the point update would indicate) on TGB 1.7.3 and we want your help to make sure it's really solid before it goes out the door with the official GG stamp of quality on it. If you currently own TGB (Binary or Source), you're invited to participate in the next stage of TGB development!

Ice Wolf -- a TGB game used to help test the new physics changes

If you want to jump right in before reading the rest of this update and already own a license to TGB, you can head on over to your My Account page and get started downloading the TGB 1.7.3 beta installer.

Note: Our Mac installer is going to be slightly delayed, so unfortunately this beta is only for PC users. The Mac build is in the works, so rest assured that we'll have a Mac compliant version of 1.7.3 very soon!

What's in Store for TGB 1.7.3

This update is pretty impressive--from bug fixes to the physics system to quite a few performance optimizations to enhanced documentation and new features, we've got a lot to talk about, so settle down and get ready!

Physics System Updates

Melv May, coding monster that he is, has been hard at work for the last month on optimizing the physics system for TGB, working with many of you to resolve issues by utilizing your real world projects to discover and correct many of the problems the community has discovered while using TGB. He's made a number of optimizations of the underlying code to provide a leaner, meaner, faster than before physics system. Here's a non-exhaustive list of things that have been addressed for this update:

*Added tick-physics smooth object rotation.

*Added tick-physics smooth particle interpolation.

*Added per-tick scene callback.

*Added "t2dSceneObject::getRenderPosition".

*Fixed tick-physics mounting issues.

*Fixed physics interpenetration issues.

*Fixed physics collision response issues.

*Fixed collision callback reporting issues.

*Fixed position-target system issue.

*Fixed mounting bug in t2dTextObject.

*Improved circle/poly circle/circle collision detection code.

*Improved t2dTrigger performance

*Improved contact-history renderer.

Some of this stuff is tough to "get" just reading the bullets, so Melv did a few video captures to show some of the bigger differences between the ways 1.7.2 handles collisions and physics in general to the new, much more accurate and efficient TGB 1.7.3. Check 'em out below:

Click any image to watch the movies

Physics System Theory Documentation
One of the things Melv discovered during his interaction with the community was that in some cases, the theory and best practices for optimizing the performance of a game wasn't clear enough to allow developers to properly use the systems the way they were intended. To help inform TGB developers of the best practices and underlying concepts of the TGB physics system, he's provided another of his amazingly detailed discussions to help illuminate the sometimes confusing details of TGB collision and physics. Here is just a sample:

Quote:

To explain collision contact and collision normal further let's bring back our objects "A" and "B". Imagine that
object "B" is stationary and cannot be moved no matter what; it's immovable. Now imagine that object "A" is moving right and hits object "B". When it hits it hits at the collision point (the collision contact) and that
collision has a collision normal as shown here:

New Game Demos and Documentation

The community has asked for new examples of how TGB can be used to make a variety of game types, and we've responded! Thanks to the hard work of Tom Eastman , Matt Langley and a member of our intern team, Robert Potter, we bring you some new game examples:

Reactor

Solitaire

As well as a Behavior based version of the Shooter Demo, Blackjack, and an enhanced Checkers Demo!

All of the new Game Demos come with full TorqueScript, images, and can serve as starting points for an even larger variety of game types for the new user.

In addition to the four new Demos, we've also greatly increased the reference level documentation of TGB's user API, providing even more detailed information on hundreds of TGB classes and their methods. Here's an example:

castCollision(float elapsedTime)
Description: Returns collision details for object over elapsed-time.
Params:
  elapsedTime: The number of seconds into the future to check for collisions. If this number is
 0.0, the collision will be done based on the current position of all objects. If it is greater
 than 0.0, the engine will perform the collision detection across a simulated time period of 
 length time and return the first collision detected.
Return:
  space separated list: If no collision occurs, the return value is an empty string. 
  Otherwise,  the list is in the form 'object time contactX contactY normalX normalY'. 'object' 
  is the object collided with, 'time' is the number of seconds in the future the collision took 
  place as a float (this number will always be less than the time parameter), 'contact' is 
  the position the objects collided at as a  vector, and 'normal' is the normal of the 
  collision as a vector.

Example(s):

// time - time to check for collision using current object setup.
// This function allows you to check to see if the object, usings its current setup, will 
// collide over a specified period of time. 

%obj.castCollision( 1.0 );

New Functionality: Built in A-Star Pathfinding

We always love to see users enhancing Torque to accomplish cool things, and it's even better when they decide to give back to the community the results of their hard work as a resource or asset for the community to use. Sometimes, the contribution is so nice to have that we decide it should become a core feature of future products.

One perfect example is the amazing work done by Phil Shenk on his resource A-Star Pathfinding Extension for T2D -- a C++ implementation of a very popular and powerful path finding algorithm used in hundreds if not thousands of 2D and 3D games.

Based extensively on Phil's resource, we're proud to announce that Torque Game Builder 1.7.3 now provides integrated A-Star Pathfinding for any TGB object. We've taken Phil's resource and provided a TorqueScript interface that allows even binary only TGB owners to use real time path finding within their game, including dynamic modifications of the world affecting current and future paths.

We've also written a new tutorial to teach the basics of the TGB aStar API, Attack of the Mutant Butterflies!

You have Become Better at Transparent Development (100)!

As I mentioned above, we've been very impressed with the community participation we've received so far during our Transparent Development strategy, and we're ready to take it to the next step: interactive development.

For the TGB 1.7.3 update, this will take place in two different ways:

Enhancement of the aStar Pathfinding feature for future releases

The aStar implementation provided with this update has some interesting features, but there's always room for improvement! Over the course of both the 1.7.3 open beta period, and in the following months we will be looking for active feedback and contributions to make the feature even more powerful for you, the community. We hope to see both developers brand new to TGB and power developers that have been with us since the beginning work together to further enhance the aStar capabilities built in to TGB.

A soon to be announced interactive project between GarageGames and the Community

I'll save the details for a .plan in the very near future, but we will be sponsoring an interactive development project for the community based on the aStar functionality. Stay tuned for further announcements, but I'll leave you with this teaser:

TGB 1.7.3 Beta Discussion/Reporting

Here are a couple of posts that should be used when discussing this beta, as well as directions for how to submit bugs:

TGB aStar General Discussion
How to submit bugs for TGB 1.7.3 beta
TGB 1.7.3 Installation/general questions

Full change list

Known Issues with TGB 1.7.3 beta 1

Transparent Development, Torque 2, and You!

Stephen Zepp — 2007-10-18T05:26:18+00:00

There has been some buzz floating around since IGC this year, and a lot of it has been around InstantAction, but we also announced a couple of additional topics that are starting to sink in, so I wanted to dive in to the deep end of the community pool and make some waves....

Transparent Development

Sounds nifty, but what is it? One analogy I've heard that is a pretty solid description is consider TD a window into the offices of the development staff working on Torque 2--see what's being worked on this week, read discussions about designs as they are being discussed internally, and most importantly be able to discuss the designs and implementations themselves, as they occur.

We're not talking marketing information for a product that has already been developed--we're talking watching, and even being able to discuss and provide feedback on the development of Torque 2 as it occurs. I'll get to Torque 2 in a moment, but I want to reinforce that this is a fundamental shift back to the way GarageGames used to interact with the community--away from keeping completely silent regarding what we're working on and why, and back to giving the community rapid and fully packed pages of information on the development as it occurs--not after the fact, and especially not after it's released. Torque 2 isn't even scheduled for beta until well in to 2008, but we're working as rapidly as we can to get infrastructure in place to set up discussions as the engine team works on development.

We're talking roadmaps, milestone lists, design write ups, expected work flow and implementation standards, the works--all up front, all the time. One of the projects that I am working on right now is designing a new set of forums, wiki, and related web tools to manage extensive and extended data flow between the Transparent Development Community (that's you guys) and the engine development team (that's us!). Once this infrastructure is in place, we're going to open it up for communication purposes to a limited set of users for beta testing for a few weeks, and then we will make the information available to all.

[edit: see below in the comments section for further clarification on content and timing]

It's going to be several weeks yet before this infrastructure is ready, and it will be a few weeks of beta testing of that infrastructure as well before we're ready to turn on the fire hose, so please be patient while we get things set up for this to work in the long term--when it's ready, we'll let everyone know and let the show begin!

I do want to make something fundamentally clear from the beginning (and trust me, I'll keep pressing this point until it sinks in fully!): Torque 2 development will be an iterative process, very similar to the SCRUM, or Agile/Spiral Development models--and one of the key aspects of this style of development is that sometimes you go down a path, and it turns out that the path is not the best solution. When this occurs, the best course of action is simply to cut out the results of that development spiral, and reset your project expectations. Sometimes this means removing features, adjusting the milestone list, or delaying (or in some cases even canceling) entire systems.

It is critical that the entire Transparent Development Community understand that this development process you will be watching and discussing is a fluid one--and it should be fully expected that features and systems being discussed one week may very well end up being cut forever the next. No projects, games, and especially no funds or contracts should ever be committed during this development process--if you need to make commitments or financial decisions regarding your projects, then the Torque 2 Transparent Development Community is absolutely not somewhere you should be.

Torque 2

So what's Torque 2? To put it simply, Torque 2 is a ground up re-factor of the entire architecture of all of our engines into a new engine with some pretty amazing architecture and features. We've learned quite a bit over the last several years of engine development, and the time has come to take those lessons and build a new engine that not only provides the maximum flexibility possible to game developers, but fundamentally change many of the designs of the engine itself--correcting design assumptions and work flows that came about over the years that we ourselves find too restrictive, and along the way providing customization and feature enhancement capabilities that were never available before.

Torque 2's fundamental changes fall under three primary areas:

Modularity of Systems: In the past, it was very difficult to leverage into Torque systems, libraries, and raw code written by 3rd parties, such as ODE/Havoc/PhysX Physics, alternate scripting languages such as Lua, Python, and even .NET languages, and many other cool things that are available to game developers. Torque is extremely integrated, with each of the systems tightly coupled to provide a powerful, but ultimately restrictive engine when it comes to "mashing up" other solutions into a coherent whole--and Torque 2 is designed from scratch to correct those issues by allowing game developers to replace major system modules in a "plug and play" style--as long as the external systems match interfaces that the Torque 2 framework expects, you will be able to use just about any 3rd party (or self-developed) system within the core Torque 2 framework.

Abstraction and Interfaces: One of the key ways we will be able to provide this type of "swap out" modularity is by abstracting most of the core systems via the use of interfaces. Each major system will describe a set of interfaces that other systems and objects will use to communicate with the system, so instead of calling code directly within a system, external modules and objects will interact with the interfaces that system exposes--allowing other systems to replace core modules at the whim of the developer.

Torque 2 has already leveraged the previously developed GFX abstraction layer present in TGE-A, and in addition has had several iterations of abstraction of core systems as well, such as the sound layer (now abstracted through a new SFX system), lighting (fully abstracted into a separate module), collision and physics (currently under iterative refactoring towards a comprehensive interface), and many others. As the iterative development spirals of Torque 2 continue, additional systems will be abstracted and interfaces implemented for even more comprehensive modularity.

Components: The concept of a component based architecture is actually very simple--but it has some far reaching design implications, and in many cases can take some time to adapt towards. In most game engines, including Torque, you have a very deep set of classes that form a pretty static ancestry, and you use inheritance of all of these classes in your game object level classes. Unfortunately, this has several issues that become more apparent the longer you use these classes for development, especially across multiple games: your game object classes start becoming more and more bloated, and less appropriate for specific uses. Anyone that takes a good look at the Torque ShapeBase class will soon see what I mean--there are still left over methods in the ShapeBase class that are part of original Tribes code, and aren't particularly useful for most games.

Here's an example of exactly what I mean: Back when BraveTree was working on their environment pack, one of the neat things they wanted to have was butterflies with random movement about the scene. Pretty nifty stuff--they derived a new class off of ShapeBase, and their butterflies merrily wandered about the stronghold mission randomly--until one of them happened to run in to a crossbow object placed in the scene.

Suddenly, this tiny little butterfly picks up this huge crossbow, and starts swinging it back and forth madly as it continues to wander about--merrily meandering about the scene with a totally unexpected weapon of mass destruction dangling from its cute little mandibles.

It was immediately obvious what was going on, and as soon as they picked themselves up from off the floor and stopped laughing, they realized that since the butterfly inherited from ShapeBase, it also inherited the ability to collide with Items, and mount weapons--and that's exactly what it did!

So what does this have to do with components? Well, with the idea of components (based on the Object Oriented Programming concept of aggregation, sometimes called composition), instead of inheriting a series of ever more complex functionalities that your particular object may not need, you create very small units of functionality that accomplish simple tasks--and "build" your game objects from these little components. In the case of the butterfly, they might have added a render3D component, a collision3D component, a hoverFlightMovement component, and a AIRandomMove3D component--and thereby had all the functionality they needed for the butterfly, without any of the bloat that inheriting from a full class would have given them.

We'll be covering components in quite a bit more depth once the Transparent Development Community is in place, but if you are interested in learning more about how component based game development works, TorqueX also uses components, and is a great place to learn how the new design concepts can be used.

What this means for You

Well, the very first thing it means is not a lot to be honest--this is an announcement of a new development style (transparency), and a new engine that is just now entering heavy development. Torque 2 is not going to be ready for use in a major (or even minor) game project until sometime in 2008 (more accurate time line will come when we get more iteration cycles finished up). If you are currently working on a game with Torque (or another engine), or are planning on starting a new project in the next 6 to 9 months, Torque 2 is not for you at this time.

If you are someone that is interested in how an engine is developed, and want to participate in discussions of that development process as it occurs, stay tuned for further announcements about the Transparent Development Community. Once it opens to the public stop on by and hang out--at the least it should be educational and informative, and hopefully some of you might even generate ideas, designs, and implementations that may very well be factored in to the future of Torque.

I'm already well over my word count for a .blog, so I'll answer specific questions in the comment area below.

Torque Boot Camp for Game Builder Announced!

Stephen Zepp — 2006-02-16T23:32:38+00:00

Rather short .plan, since all of the content is in a link: the first Torque Boot Camp for Game Builder is now available!

A couple of short notes:

--March 6-8 2006 (that's in 3 weeks!) in Eugene,Oregon
--one price for both commercial and indies: $199
--3 day class, taught by myself, Matt Langley, and a special guest instructor: Melv May! Yes, that's our very own Melv, who is travelling all the way from Europe to help us kick off the first TGB Boot Camp!

Follow the link, lots of cool pictures and even cooler information.

Torque isn

Stephen Zepp — 2006-01-12T18:50:43+00:00

The Past
Historically, many of the opportunities that have become available on these forums are in the normal "indie" mode: join a team, perform your tasks working on a project as an indie developer for future royalties/credit, and along the way not only gain strong knowledge of Torque, but many of the team skills and experience needed for successful game development.

Some of the time the projects make it to publish, and studios such as Bravetree (now part of GarageGames), 21-6, Large Animal, MaxGaming Technologies, PocketWatch Games and many others have been able to generate income--in many of those cases continuing to work together as a studio to continue on the path to their dreams.

Please note that this post isn't intended to suggest this original paradigm is bad in any way...but things are quickly expanding!

Over the last 9 months GarageGames has been focusing on the marketing, technology, training, and services areas to make Torque extremely attractive as a development platform for markets other than indie developers: we have established companies in Military Simulation/Visualization, Casual Game Dev, A/AA/AAA Game Dev, and many others that are quickly finding out that both GarageGames as a company and Torque as a development platform are extremely attractive--great tech, excellent training (Torque Boot Camps), commercial support, and deep penetration into the educational sphere (we have more than 40 schools using Torque, and the number is growing exponentially).

The Present
I participated in a call yesterday from an extremely experienced studio that was researching all commercially available engines for development of a new funded title, and even I was surprised to hear the following:

Quote:

One of our selection criteria is availability of experienced developers and artists. Our research has demonstrated that the Torque Community provides a developer/artist pool of experienced individuals that rivals Unreal 2.

(Note: that's paraphrased, but the spirit of the quote is spot on)

Now, that's wonderful, but it got me to thinking: one of the (in some ways at least) downsides of being an experienced member of an "indie community" is that we see a lot of projects and job opportunities that simply don't pan out. That's not a bad thing honestly, but it does have an effect of having individuals looking for paying work to become jaded regarding both their expectations and their "belief" in things they see here on the forums and especially the "Job Opportunities" section of the community--everyone knows that these posts are going to be glowing, promising the world, and it becomes sometimes a bit difficult to take them seriously--just human nature.

One of Jeff Tunnel's biggest tasks this year is putting together a program to make sure Indie Developers and projects can coordinate, and get their projects published by providing organization, resources, and team building capabilities to help overcome the issues I mention above. I am extremely excited about this project, because it is sorely needed--we as a company are best situated to help tie together motivated and skilled Torque users into teams that can be successful.

However...there is another segment of the Torque developer market that doesn't really fit into this category: experienced (and jaded, see above) developers, artists, and designers that may be looking for a more traditional (or new generation) role in a non-indie company, using their experience in Torque to leverage success.

Disclaimer: the following list is absolutely not complete, and selected only to provide a spectrum sample of just some of the possible opportunities out there. None of these companies have asked, or even suggested they should be listed, I'm just picking a sample of the ones I am very familiar with, and/or have recently posted Job Opportunities on our website. The one randomly chosen criteria I used is that these are pay positions (not royalties/intern/percentage of profit), simply because that's the topic of this blog.

Valador -- Military, NASA, and Corporate Visualization, Simulation, and Training, looking for a Engine Coder/Script Programmer

Houston Community College-- looking for a Full Time Digital Gaming and Simulations Instructor and Artist

Roxor Games -- looking for a short term Experienced Programmer

Mind Control Software -- Looking for: Level Designer, Game Engineer, and Senior Artist

These are just a few of the opportunites available out there (and just the ones that have publically notified the community, I know about a lot more that are coming down the road!)...as a community, you guys and gals are so respected in the marketplace now that even Electronic Arts has started posting positions in our Help Wanted forums for 13 positions!.

The Future
GarageGames will always be focused on our indie community, and Jeff T's initiative to make indies more capable and productive by tying together motivated and experienced team members and associated resources is extremely important--and something the entire company is excited about. Indies are our core mission: "To provide independent developers with tools, knowledge, co-conspirators - whatever YOU need - to make great games."

However, as the title of this blog says, Torque isn't just for indies anymore--and we want to make sure those professional developers, artists, scripters, and anyone else with Torque experience are aware of the opportunities that exist. We as a company are going to continue to provide quality technology to all comers, as well as the training and support needed for the companies using our engine. You as a community are responsible for using your Torque expertise to meet your dreams...and if that dream is a position in a corporate structure that uses Torque, this is just a small selection of what is coming!

I/ITSEC trip--(blog removed due to extreme photo content)

Stephen Zepp — 2005-12-03T05:33:22+00:00

.plan removed due to complaints about large file sizes for the images. Smaller images coming soon!

Torque isn't just for games any more!

Stephen Zepp — 2005-11-23T02:00:14+00:00

Six months ago when I came on board with GarageGames, I never thought in a million years that I would be going to the Kennedy Space Center to teach NASA how to use Torque...yet here I am!

More than a year ago, Valador, Inc. researched more than 40 Game and Simulation engines in their search for an engine that could provide simulation and visualization capabilities for NASA at a reasonable price, with exceptional quality. After all was said and done, they selected the Torque Game Engine, and never looked back. They now use TGE and TSE for a variety of internal research and development projects, as well as contracted work for NASA, and have helped to achieve Torque's penetration into the serious games/simulation space.

But NASA is just one of the "big names" that are interested in Torque. On saturday evening, Josh Williams and I catch a plane for Orlando, FL for the Interservice/Industry Training, Simulation, and Education Conference, which is the US Military's equivalent of E3--more than 400 exhibitors on a floor of 140,000 sq feet, with 16,000 attendees currently registered. Nestled in among exhibitors such as Boeing, Aviation Week, Lockheed/Martin, General Dynamics, L3 Communications, SAIC, and Valador, and enveloped by the sounds of machine guns firing, 2,000 lb bombs going off, and helicopters strafing city streets, there will be certain vendors proudly displaying:

Now how's that for cool?

I'm certainly glad that Jay Moore and Davey Jackson will be joining Josh and I on Monday morning, because there's no way the two of us will be able to handle the questions from an audience that size alone!

As of this .plan I can't release the specific vendors that will be presenting Torque powered projects other than Valador, but I hope to be able to present additional information on some of the extremely cool ways Torque is being used in this space in the very near future, so stay tuned!

And for all you Orlando/Central FL Torque users out there, we haven't forgotten you: on Wednesday, November 30th, GarageGames will be co-sponsoring a hospitality suite with Valador and the GAMES Synergy Summit at the Peabody Hotel on International Drive, and GarageGames community members are invited! Come join us at the bar for a night of Torque hospitality from 7 PM to 11 PM.

Once I/ITSEC is over, Josh, Jay and Davey have to go home, but I get a brief rest and then am off for our latest TBC--Commerical located at America's SpacePort, the Kennedy Space Center. From the 5th to the 7th I'm going to be up close and personal with real rocket scientists, teaching them how to use game engine techonology to make their jobs easier---now who would have ever thought that?

Needless to say I'm looking forward to a very exciting (and very long!) week and a half just after Thanksgiving, and I'll do my best to capture some of the excitement and wow factor of the technology that will be demonstrated and bring it back to the community!

Is that really Mars?

Stephen Zepp — 2005-10-15T07:14:07+00:00

I got some (valid) heat for my last .plan, where I mentioned things that I wasn't allowed to talk about (yet), and how that type of "tease" wasn't fun for the community as a whole. While I'm still very excited about some of the incredibly cool stuff I'm working on that I can't talk about....I did get permission to talk about (and show!) some of the really cool things being done with Torque in the commercial/military space (pun intended!) that I am aware of (even though I'm not working on it myself)...so here we go.

Many people have played around with getting real world terrain into TGE, and while some have been successful, the restrictions of the TGE terrain implementation (as strong as it is) really don't allow for much in the way of real world/large size terrains. With milestone 2, the Atlas terrain implementation in TSE allows for some incredibly amazing terrain capabilities, including the ability to bring large (and extremely large) real world terrain into your simulation.

But why limit ourselves to just one world? Earth is cool and everything, but other planets are even cooler...and when it comes to cool factor, it doesn't get much better than real terrain data (captured from satellite surveys) of the planet Mars:

Yes, for those still in doubt: that is actual terrain information from the planet Mars loaded into TSE, with a very nice model of the Mars Rover(s) in place. Here's another:

Ok, so we don't see any amazing shaders in play here, nor do we really see anything that couldn't have been done in Photoshop, but if you attended IGC this year you may have seen Valador's demo running on the main screen during session breaks on Sunday. The Rover is fully controllable, and has a "weapon" that gives you a beam to check line of site distances and rangefinder target coordinates of terrain impacts:

And let me tell you what--this was simply a proof of concept demo for a money saver project designed to package Rover capabilities in a less expensive presentation format. Once this little demo made it's splash, the brains at NASA started thinking about some really nifty stuff! I apologize for pulling the "can't talk about that" card again, but let me put it this way: would you rather see a Mars Rover in action, or read about it via lines of text?

One last shot:

This .plan requires a TOP SECRET clearance!

Stephen Zepp — 2005-10-05T07:33:53+00:00

Well, it's only been two weeks since our last Torque Boot Camp--Commercial, and we already have IGC here (it starts for GG staff today...setup, Associates start arriving, etc.) and another Torque Boot Camp immediately following....and the [sarcasm]best[/sarcasm] part is that I am in crunch mode for what has to be the coolest development project I've ever worked on!

Unfortunately, I can't talk about it...and that sucks! The fortunate part is that the clearance gets lifted in a couple of months, and we'll be doing a full writeup of the technology and what it accomplishes, so stay tuned! I can say however that I discovered that pretty much whatever your background is, sometimes all those things you thought you'd never be associated with again may come back and help you overcome difficult challenges in programming! Nebulous I know, but hey, it's late, and like I said, I can't talk about it yet...

The Indie Boot Camp is going to be a blast...we're going to squeeze in a ton of tech, do some round table discussions about participant's projects and challenges, and discuss in detail strategies and methodologies for independent developers. The 3 days are going to be a mix of:

Demos of tech, and how to use it
Lectures on theory, and how to understand it
Discussions on challenges, and how to overcome them
Walks around Eugene! (no, seriously!)

It's getting quite late, but we are still accepting last minute attendees, so if you are on the fence about attending, I can promise that everyone will get something out of it, no matter what your experience level in game development, or Torque...so call GG and have your credit card ready!

As Davey mentioned, the "travel team" is gearing up for quite a busy fall--he listed the major conferences so I won't bother re-hashing them, but at least one of the team (Davey, Jay Moore, Benjamin Bradley, Josh Williams, and myself) will be in the following cities over the next two months:

Austin, TX
Orlando, FL
East Lansing, MI
San Fransisco, CA

We will do our best to make sure everyone knows where the (informal) GG get-together will be so folks can plan ahead.

Torque Boot Camp--Commercial 19-21 Sep 2005 Recap

Stephen Zepp — 2005-09-24T03:20:47+00:00

I just wanted to do a quick recap of our latest Commercial Boot Camp, and put in a last minute plug for the Indie Boot Camp just after IGC. Long post with zero pictures, and for that I apologize!

One of the really interesting things that Commercial TBC's do is to bring an incredibly varied spectrum of projects into one room...our first Boot Camp was a mix of military simulation and AAA game development, and it was extremely interesting to see how many ideas cross over between two drastically different genres. The second was just as varied: we had once again both AAA game development teams as well as the military simulations sector, and some of the conversations that resulted while talking about Torque theory and tech demonstrated just how fundamentally tied the two genres can be.

The Commercial camps are no holds barred when it comes to Torque: there are so many systems and subsystems that are critical to successful development with Torque that we can't cover all of them--so we very quickly do an overview of tools, editors, pipelines and the like while "trolling" for areas of interest and/or confusion. This allows us to make sure we adjust the course on the fly to the average experience levels of the attendees, while not boring the group with infinite details about systems they may be using every day.

First Day

The overview covers the following major areas:

**Torque Editors (we commonly don't touch on the GUI editor unless it's requested, but do a quick overview of the rest)

**Torque Scripting basics

**External Tools and Projects (Show Tool Pro, Exporters if needed, new projects/tech that are being developed at GG that we can talk about)

**Art Pipeline Overview (we don't go into art creation and preparation details, but we do cover common issues and problems if questions arise)

**Project Design and Implementation Strategies within Torque

**Intro to Torque Scripting
--again, this area is an extremely quick survey. We commonly find that the attendees for commercial Boot Camps are very up to speed on the uses and need for a scripting language, and don't normally need much of a review of the scripting techniques. Of course, questions and review of the Scripting environment are covered if needed!

The first day (and the rest of the course) is very interactive and free-form so this actually takes most of the day, and lets the instructor identify areas to focus on once we get deep into the theory and tech side of Torque.

Second Day

**Torque Client/Server Model
--Since the architecture of Torque is based around the concept of always having a server and a client, this is the first area we cover in detail. We discuss the three basic types of Torque projects (Dedicated Server/Dedicated Client, Hosted Multiplayer, and Single Player), as well as discuss the concept and implications of the authoritative Server Simulation and the replicated Client Simulations.

**Simulation Theory
--we discuss the underlying operations of the simulations themselves, and how to design and implement in a polling + event driven environment
--we also discuss the concept of callbacks and how they allow objects to inter-relate, and also how to use the concept for performance and functionality

**Torque Network Model
--we introduce the concept of Ghosting objects and how it allows us to have the clients replicate the appropriate aspects of the server simulation without overloading our network.
--we also introduce and discuss the major challenges for networked games, and discuss some of the strategies Torque uses to optimize network utilization.

**Torque Hierarchy
--this is the meat of the second day from the pure tech perspective: after introducing the three theory areas above, we demonstrate by stepping through the dOxygen documentation that describes the functionality that each of our objects in the hierarchy provide all the way down: ConObject, SimObject, NetObject, and SceneObject all get detailed attention, and we do an overview of the primary functionality GameBase and ShapeBase provide.
----During the NetObject discussion, we also drill down deeply into the Ghosting model that we introduced earlier, including the differences between the control object and "normal" ghosts, as well as stepping through the requirements for either creating or utilizing existing ghosted functionality: netMasks, pack/unpackData, and the related methods that implement these concepts.
----we also introduce the MoveManager, and discuss how moves are treated and utilized for control objects

**Torque Network Model--Continued
--once we've swallowed the primary object tree, we also discuss the underpinnings of NetConnection and GameConnection, and what they provide for us. Depending on the current projects of the attendees, this may either become an extremely low level discussion, or in some cases a discussion about how to modify and/or re-implement Torque connections for communicating with Torque itself from other applications.
--we also drill down into NetEvents and their uses, including the concepts behind both guaranteed and guaranteed ordered events, and how they are processed by both the client and the server.

**Script Space and Engine Space Interaction
--we discuss how to implement a new class, and provide bi-directional interface between that new class and the scripting environment, as well as the design concepts behind scripting languages and their uses.
--we also discuss debugging techniques and capabilities, including journaling and in the future more detailed uses of the profiling system.

Third Day

The third day of commercial Boot Camps are even more free-form than the first two: We commonly review topics and have a question/answer period about both what was previously covered, as well as challenges and issues the attendees either have already had, or see coming. Additionally we may discuss topics that weren't covered in the first two days (again depending on class needs and requests) such as the rendering layer, in depth collision discussion, player/vehicle physics, or pretty much anything that is asked!

We also provide the opportunity for direct access to GG developers, artists, and project managers by having guest lectures on topics of interest to the attendees. From help debugging code and resolving specific problems, to design discussions about new systems and how to use existing systems, to best practices for model and map creation, these lectures provide excellent insight and information from the most experienced Torque users around..GG staff!

That's just the "on duty" time! During the off times (both lunch and evenings), attendees are given the opportunity to hang with the GG crew and discuss pretty much anything they are curious about. Josh gets to be his cool self, Ben Garney demonstrates just how tall he really is, Matt Fairfax proves that "farm boy" isn't an insult when it comes to Torque, and Pat proves once and for all that you CAN have "mood ring" hair colors working in XBox 360!

We show off the 5th Street Market that is the lunch hangout of choice for GG'ers, and depending on what may be happening locally may have a BBQ, night out on the town, or whatever folks are interested in. In some cases, all they may be interested in is sleep since the tech comes fast and furious, but we have no problem with that either!

Our current schedule has approximately one Commercial Boot Camp per month, so if you are interested in attending, please contact us either via email or telephone for the latest schedule!

Torque Boot Camp for Indies

I will flesh out the plan and structure of the Indie Boot Camp in a future .plan, but we will be covering additional topics (and therefore not going quite as in depth on specific ones), including Virtual Team Management, Independent Game Development Methodologies and Practices, and other topics of special concern for Indie Developers. More to come on this topic as we get closer!

Future Plans

We do understand that for various reasons attending a three day seminar isn't always possible for all of our customers, and we do have plans for providing alternate ways of learning about Torque directly from the staff in the future. Since the face to face interaction is so valuable we will always have Boot Camps, but we both recognize and understand the community's needs, and have plans in the future for meeting them!

We also realize that TGE isn't the only product that people are interested in learning about, so we are developing Boot Camps for our other products as well...look for these in the near future!