Blog for John Kanalakis at GarageGames.com

Torque X Builder 3D Update

John Kanalakis — 2008-05-26T23:29:09+00:00

Torque X Builder 3D is making great strides as its coming near the end of development. The awesome Ken Holst has already ramped up the QA team to begin seeking out those pesky bugs. We're all moving as fast as possible to bring this out to the public quickly. That means trimming back some of those features that would be nice to have.

In order to make the game truly WYSIWYG, the 3D Builder essentially runs an instance of the stock Torque X 2.0 game engine. That means getting creative about how some things are implemented, such as a new Designer camera, Axis Gizmo (as described in the last post), and scene Serializer (to compliment the existing scene De-Serializer).

Here are a few of the features that did make it into the first release. In this picture, the well known desertLevel.txscene from the FPSDemo project is loaded. The Object Type editor shows the object types that are defined within the project that can be assigned to various objects. The 3D Builder is also set to the default panel layout with the color scheme is set to silver.

In this picture, I've changed the panel layout to my personal favorite - the Asset Browser on the left, scene graph on the top-right, and the Properties window on the bottom right. I've also changed the color scheme to blue. You can also see the representation of a "Spawner" object (the green box). Invisible entity objects, such as Spawner, Lights, Sound Emitters, Cameras, and Triggers appear as box markers.

Sometimes I find it faster to tweak values straight in XML (though I dread creating levels by hand in XML). Here's a monstrous view with the XML editor side-by-side with the 3D viewport. The viewport also reveals the latest form of the Axis Gizmo which looks a lot like the TGE(A) Mission Editor gizmo. Although they look and work similarly, they are completely different in code. You can also see the automatic sizing of the 3D Viewport to maintain a 4:3 aspect ratio. Adding a 16:9 HDTV aspect ratio will probably be saved for the next release.

Assigning and editing components is pretty easy, but I can try to make it look complicated. In this picture, the selected component Properties are listed. You can change the selected component from the drop-down-list. As you set the component properties, they are applied in realtime to keep-up the WYSIWYG goal. To add or remove components, click the green Add button to the right of the drop-down-list. This opens a new dialog box that lets you add or remove components.

Even integration with Visual Studio (2005) is completed. Torque X Builder 3D works just like its 2D counterpart. You can import assets, such as 3D shapes and textures into the 3D Builder. The 3D Builder will automatically update your XNA Game Studio (C#) project. But it's up to you to rebuild that project. After the project has been rebuilt (and the art assets have been compiled into .xnb files), you can add them into your 3D scene and position them. Also, like the 2D Builder, the 3D Builder also scans the generated myschema.txschema file to find out what components you created, so you can attach them to your project.

That's about it for now. We have been working pretty hard on this project to bring out to the public as soon as possible. Though I don't have any official release date to share, we're now talking in terms of weeks instead of months. And with our level of excitement, I'm sure there's going to be a lot of fireworks with the product launch.

John K.

Torque X Book Completed

John Kanalakis — 2008-05-04T03:48:46+00:00

It's finally finished. After several months of work, the The Complete Guide to Torque X is finally completed and on its way through the rest of the book publishing process. I'm not sure about the final page count (since it still needs to go through copy-editing and layout). But it should be really comprehensive. Here's a sneak preview of the topics covered in the book. (Not the final book cover)

Introduction to Torque X

The first chapter provides an introduction and overview of XNA and Torque X. It covers some of the history behind XNA and its roots in Managed Direct X. It goes on to explain the benefits Torque X adds on top of XNA to quickly prototype and create new games.

Part One: Torque X Game Design Tools

Chapter 2 dives right into game development by describing the Torque X Builder 2D game design tool. It starts by creating a new game project in XNA Game Studio and then use Torque X Builder 2D to pull game art assets together and organize them into game levels. The chapter ends by building a simple game using only the stock Torque X components applied to different scene objects.

Chapter 3 works with two more important Torque X Builder 2D editors, the Tilemap Editor and the Particle Editor. Both are important tools to understand when building games with Torque X.

Chapter 4 introduces the Torque X Builder 3D game design tool and shows how to create material definitions, position game objects within a scene, assign components, and then save the resulting 3D scenes.

Part Two: Programming with Torque X

Chapter 5 begins shifting game development work from the designer to code. This chapter presents an introductory overview to the C# programming language. In outlines the fundamental aspects of the C# language that will be used most throughout the remainder of the book. Concepts, such as classes, object, interfaces, and delegates will all be spelled out.

Chapter 6 introduces to the key classes that make up the powerful Torque X Framework. Understanding these classes will be key to successfully creating games. This is also where components will become familiar with examples of how to use them.

Part Three: 2D Game Programming

Chapter 7 begins working with the Torque X Framework code by manipulating tilemaps and uses them to build a completely Tilemap-based puzzle game.

Chapter 8 focuses on the 2D representation of a player and its related responsibilities, such as responding to player input positioning the player on screen, animating the character, and interacting with other game elements. This chapter presents the inner workings of components and best practices for creating them.

Chapter 9 adds more common 2D game functionality using components. In doing so, it uncovers more useful Torque X Framework classes and reveals best practices for designing and creating your own game components.

Chapter 10 continues to create additional components that enhance gameplay features. It creates three new components that implement some basic artificial intelligence for game enemies. In addition to adding some interesting game functionality, these components demonstrate some important lessons.

Part Four: 3D Game Programming

Chapter 11 exposes the fundamentals of 3D game programming. This chapter discusses the concepts of 3D coordinates, vectors, scene graphs, models, and animations.

Chapter 12 applies the new knowledge of the Torque X 3D Framework to create a series of player-centric objects. This chapter applies the same techniques of modular design to create re-usable game components that will move and animate a 3D player.

Chapter 13 shows how to create additional 3D game objects. These useful game objects will work together to help implement a basic first-person shooter game.

Chapter 14 revisits some of the AI concepts discussed earlier and translates them into 3D space. This chapter shows how AI components that were easy in 2D quickly get complicated when it applies to 3D space.

Part Five: Finishing the Game

Chapter 15 explores the audio tools available for creating sounds with XNA. Adding audio to a game using XNA is much more restrictive than for a PC game since the game must run within a managed code environment. There are restrictions on audio formats and compression that need to be met.

Chapter 16 explains the fundamentals of GUI building with Torque X and then applies those fundamentals to create some game setup screens and HUD controls.

Chapter 17 explains materials and shaders and how shaders effects can significantly enhance the visual appeal of a game by adding more to the screen rendering process. This chapter dives into the Framework code, tools, and effect files that put shaders to work.

Chapter 18 will focus on what's involved with moving a game over to the Xbox 360 game console. This starts with design considerations for games that target the console and television. Then, this chapter covers specific steps involved in moving a game onto the Xbox 360, using the project converter, XNA Game Studio, and a Creator's Club membership.

That's about it. It took about seven months to pull all of this together. The biggest challenge was probably trying work on the book in middle of some big changes to Torque X. I will also be managing a new website dedicated to the book, where I can post book updates, downloadable code, and a forum dedicated to answering questions about the book. The site is going to be located at: TorqueXBook.com and should be available in a few days. But now that the book is finally finished, I can get back into the Torque X forums more often ;)

John K.

Torque X Builder 3D Progress: The Axis Gizmo

John Kanalakis — 2008-04-22T02:14:55+00:00

Torque X Builder 3D is coming along very nicely. I have received a lot of great community encouragement and feedback. And as a part of that community, I'm doing my best to factor in all the feedback. I'm also limiting how much I "perfect" the tool in order to get it finished as quickly as possible. Today's focus is on the Axis Gizmo. Since the main goal of TXB 3D is to make Torque X 3D scene creation easier, the Axis Gizmo is a really big part of hitting that goal.

The problem is that creating an Axis Gizmo is not as easy as it sounds. I spent a lot of time researching differnt methods of creating an Axis Gizmo and the one thing I found is that there really is not much information out there about it (or I'm really bad at online researching ;) ). This becomes even more complicated when you need to work within the limitations of the XNA Framework, where simple rendering primitives, such as line and circle drawing, simply don't exist. So, what does one do? I broke the problem out into two smaller problems: rendering the gizmo and processing the user input. I naturally started with the easier problem.

Processing Input
Processing input is pretty straight forward in Torque X, since it just involves creating an InputMap and processing Move structures, just like any other Torque X game does. It took a little more to work to figure out the dragging functionality, and was implemented by tracking the mouse button states. The scene object movement is accomplished by setting the T3DSceneComponent position position by scaling the mouse input. The harder part to figure out was how to select objects in the first place. In short, you need to get the position of the camera, take the mouse's X and Y screen coordinate, scale the position to the view frustrum (accounting for FOV and Aspect Ratio), and then cast a ray forward into the scene and test which 3D shape's bounding box is hit. So, now that shapes are being selected and dragged around the screen, I needed to have some sort of visual representation for the Gizmo.

Rendering the Gizmo
I started out by creating one by hand. The following lame gizmo (shown in the last blog) was created by dynamically generating 3 tall and thin boxes. It was functional, but the Gizmo looked pretty bad as you can see here:

The biggest lesson learned was that the "implementing the Gizmo as a mesh" solution was working. Great! Now, it's a matter of getting it to look good. I received a lot of great community feedback to work with (Thanks James B. and Chris K.). So, I popped open my favorite 3D Modeling program and produced 3 models to represent the Gizmo in the three different functional states (move, rotate, and scale). I exported the models into the .FBX format (native to XNA) and used the T3DXNARenderComponent to render them on screen. The models are simple enough to scale them up and down to match the size of the object selected. Here's how they look in each mode:

Translation Gizmo Arrows

Rotation Gizmo Rings

Scaling Gizmo Blocks

The Gizmo meshes can probably be improved, but most likely won't for a while. Since they are working out well enough, I'm moving off to the next challenge. Again, I'm taking every possible shortcut to get this out as quickly as possible. I just wanted to take a few minutes and write about creating the Gizmo, because everything involved used stock Torque X code. This is just a testament to the power of Torque X that's already built-in... Great Job GG!

John K.

Development Journal for Torque X Builder 3D

John Kanalakis — 2008-04-07T21:07:28+00:00

In case you haven't heard, Torque X is an amazing game engine that sits on top of Microsoft's XNA Framework. XNA provides a great foundation for bringing graphics, 3D models, and sounds together into a game that can run on Windows and any retail Xbox 360. And Torque X builds upon that framework to offer important commercial game features, like scene graph, templates, spawning, GUI, level loading, particle effects, and so on. Torque X Builder 2D is a great editor for assembling game levels, but now that the Torque X engine supports full 3D functionality, what about an editor for creating 3D game levels?

Last year, I started working on Torque X Builder 3D. As its name suggests, it is meant for assembling game assets into complete 3D scenes that can be loaded by Torque X. It was originally revealed at GDC2008 and then recently announced here by Brett Seyler. Development has turned out to be a real challenge and with this blog, I want to share my experience with talks about some of those hurdles (and how we've overcome them) while offering a deeper sneak peek into this project.

The Goal
Every project needs to have a goal, and my goal was to create a very user-customizable environment for creating 3D levels leveraging the power Torque X. That's a very specific goal with three core objectives in just the priority I want them: user-customizable, creating levels, and leveraging the Torque X engine.

User-Customizable
Not every game designer is the same, so why should their tools be?!? User customization was my top objective, so dockable panels was a must. Some may want the Assets window on the left, others on the right, while the rest just don't care. With TXB3D, you get to choose with your preferred layout saved for your next use. Here are a couple examples ranging from the minimalist (left) to the information dominator (right).

TXB 3D also supports user-created Plug-Ins. There's nothing too fancy here. I just wanted a mechanism for anyone that can code in C# to create their own Plug-In that can be loaded by TXB 3D, be given some screen real-estate, and handed access to the viewport. So, you can create any Plug-In you like, from an AI editor to an online chat tool.

Lastly, TXB 3D needs to really support (and embrace) Vista. I'm still just getting used to Vista, but it's enough to appreciate an application that can really take advantage of its strengths by "playing nice" with its security guidelines as well as parking application data where it's expected. Allow or Cancel? Allow or Cancel? Allow or Cancel?

Creating 3D Levels
This is the real meat of the application. When I first looked at this project, I broke it out into five areas: WYSIWYG Viewport, Loading & Saving Scenes, Adding/Editing Objects, Editing Components, and Editing Materials. It turns out that although these sounds like easy tasks, XNA makes them a bit more challenging. Remember, XNA is essentially a game-creating sandbox with a lot of restrictions.

Editing 3D Scenes
WYSIWYG (or what-you-see-is-what-you-get) is pretty much the expected norm for any Windows application. So, creating an editor in C++/DirectX that creates levels for C#/XNA wasn't acceptable to me. I decided that TXB3D has to have an instance of Torque X running inside of it to render the scene in real-time. It turns out that this decision had a lot of benefits and a lot of headaches. The biggest benefit is that creating the editor is now like creating an elaborate Torque X game - and I can use the scene de-serializer to load the scene, and use TorqueComponents for all the scene design objects, viewing paticle effects in realtime, and so on. The challenges were more along the lines of working with the XNA content pipeline and bringing uncompiled assets into your project and modifying components already registered with the TorqueObjectDatabase. The result was worth it and when you use TXB3D, you can be sure that your game will look exactly the way it does within the TXB3D viewport.

Loading & Saving Scenes
Loading scenes was easy, I just need to call SceneLoader.Load(); But saving scenes was a bit trickier. I decided to be lazy and make the .NET Framework do the hard work for me. So, I created a Serializer class that goes through all of the scene elements and use reflection to get their public properties and values and then write them to the scene data file. Easily reading and writing scene data lended itself well to creating a built-in XML editor for hand-coding/editing scene data.

Adding and editing scene objects is easy within a Torque X game, so no problem there. In fact, given that the editor is running a Torque X game in realtime, you can instantly see the effects of your changes. The only challenge here was that new components couldn't be added to already registered TorqueComponents. Now, you can easily add, remove, and modify any component attached to any object within the scene.

Working with Materials
Editing materials is also easy because of the great built-in support for materials within Torque X. You can create simple materials, lighting materials that can point to a normal map, or even an all new material linked to a new shader that you write... hmmm... a shader preview plug-in...

3D Axis Gizmo
But it's not all a breeze... creating a 3D Axis Gizmo for positioning scene objects is a lot easier in DirectX than it is within XNA. There's a lot of work involved in drawing a simple line within 3D space, when it comes to XNA. So drawing the Gizmo proved to be a challenge, but fortunately, it was do-able. There are still many refinements going into the Gizmo today to make it easier to work with.

Overall, this has been a really fun project to work on. I've been building desktop applications for a while with C#, but this has to be the most fun one ever. It's a great testament to the power and flexibility of XNA as well as Torque X. As for Torque X Builder 3D, it's nearing the finish line and you should see a lot more to get excited about in the next couple months.

John K.

Torque X 2.0 Tutorials Updated

John Kanalakis — 2008-03-31T02:20:05+00:00

I've just finished updating the popular Torque X tutorials and they can be downloaded from:
www.envygames.com/tx/TorqueX_TutorialsVersion2.zip.

These Tutorials were originally written by Dan Maruschak and then updated to support Torque X 2.0 by Josef Rogovsky (I'm just the guy that chimp'd-in the changes into the HTML). The tutorials broke a few months back when the 3D version of Torque X (1.5) introduced a new methodology for managing scene graphs and the GUI system. Now, you should be able to follow each tutorial step-by-step on Windows XP and Windows Vista.

If you have installed Torque X 2.0 and have not tried these tutorials yet, I really encourage you to check them out. They are a great learning resource. That's all for now, time for me to get back to finishing off the Complete Guide to Torque X Book.

John K.

A New Casual Game

John Kanalakis — 2007-11-04T05:57:56+00:00

Introducing Solicheck, a casual solitaire checkers game for Windows. I created this game with Torque Game Builder in about a week. The object of the game is to use your mouse to pick a checker piece and 'jump' diagonally over other checker pieces. You get extra points when you land on a bonus spot. You rack up points as you clear the board and win by exceeding the determined par score.

I made two versions of the game; one with several levels that become increasingly difficult (and changing scenery), and the one available here for download, that randomly generates layouts and calculates par scores.

The game can be downloaded from here. (3 MB Download)

A video of the game can be viewed from here.

Please let me know if you run into any problems. I'm also interested in hearing what you like or don't like about the game. I'm sure there's plenty of room for improvement.

John K.

Torque X: Progress, Pics, and Free Code

John Kanalakis — 2007-10-26T23:10:54+00:00

For a several months now, I've been exploring Torque X and enjoying all that it has to offer. I've enjoyed the quick and productive results of coding in C#, the rich Torque X Framework, and the elegant simplicity of components. So far, I've created over a dozen or so mini-games with TorqueX; mostly rips of classic games like Missile Command, Breakout, PacMan, etc. These are usually prototype games that take a few hours to put together to try out a new concept.

A simple air assault game testing controller input, inventory, pickups, a radar control, and basic AI

Today, my focus was on working with the sound and XACT. I wanted to test the playback of different sounds, based on different buttons pressed. So, I thought it would be fun to explore the sound capabilities of XNA with a Guitar Hero-ish mini-game.

I purchsased Guitar Hero II for the Xbox 360, so I still have an Xplorer Guitar Controller hanging around. So why not. I spent about 6 hours on this little mockup. About an hour was spent creating the very weak graphics, about 2 hours playing around with Torque X Builder, about 30 minutes playing with XACT, and about 2 hours coding the guitar component.

The guitar's musical notes were recorded and provided by good friend Dave Avery.

A short video of the game running.

The code is pretty simple. Afterall, the Xplorer controller is just another Xbox gamepad. Putting the mini-game together came down to a few steps:

1. I created 5 notes off to the side as scene object templates with a Y velocity of +20.

2. Next, I created 5 spawners at the top, outside camera range.

3. The spawners are completely random between 1 and 2 seconds apart.

4. I have a simple scroller for the board also at Y +20.

5. I have 5 animated objects (frets) on the bottom that are supposed to animate when the strum happens (next task).

6. On top of the frets are 5 blank scene objects which have a T2DTriggerComponent attached that calls back into a method called ProcessFret().

7. The ProcessFret() method checks what buttons are currently pressed (setup in an input map). If the right keys are pressed while the note is inside the trigger area, then I delete the note (and then play a blast away particle effect)

8. The input map is bound to actions which check the fret buttons and strum button to playback the sound.

That's mostly it. This isn't meant to be an actual game, just a fun excuse to play with the Xplorer controller while learning more about the limits of XACT. This is more about praise to Torque X and its creators. The framework is so robust, it's fast and easy to build interesting things. Just imagine what we'll be able to do with Torque X 3D!

Anyone who wants the code can download it from here. You can play the mini-game, read through the code, open the .txscene in Torque X Builder. Have fun with it. I'm not able to take this code any further (I have way to much else to do.) But, I thought it would be fun to have a Galaga style game where your player (a rocker) is at the bottom and uses his guitar to zapp incoming attackers, coming from the top, with the right music notes.

John K.

Rocket Commander XNA

John Kanalakis — 2006-12-25T19:49:23+00:00

The folks at exDream have launched their Christmas gift to the XNA community: the complete source code to Rocket Commander XNA. You can download the solution files, complete source code, and art assets to build the game and run it on Windows or your retail Xbox 360. The code compiles cleanly and depolys easily to the Xbox 360. All you need is Microsoft's Game Studio Express (free), a membership to the Creator's Club ($99/year), the XNA Launcher (free at the Xbox Live Marketplace), and of course a retail Xbox 360 console.

The game features great graphics, smooth shader effects, wide screen display, and best of all the complete source code. Time to dig into the code and add some wacky twists to the game.

You can download the game source code directly from exDream here.

Also, if you're interested in developing games for your Xbox 360, please check out the TorqueX and XNA Developers Group on the Great Games Experiment. Connect with other developers using the .NET Framework to create games for Windows and Xbox 360.

Solitaire Blaster Preview Images

John Kanalakis — 2006-07-06T18:33:45+00:00

After taking a brief break from our TSE Racer to put TGB through it's paces, we're putting the finishing touches on Solitaire Blaster.

About the Game
Solitaire Blaster is a new twist on an old classic. It plays a lot like classic Solitaire, only faster. A timer at the bottom of the screen counts down. Before the timer hits zero, you must make 3 legal Solitaire moves. If you successfully make 3 moves in time, you're rewarded with a hidden card being blasted out of a column and into the card deck. However, if you fail to make 3 moves in time, the card deck is blasted, tossing a card back into one of the columns. The faster you play, the better your chances of completing the game.

There are 5 levels of difficulty, in which the clock ticks down faster and more distractions attempt to slow you down. My favorite level has cards floating around in zero-g (image below).

About Development
Game development was pretty fast and painless, thanks to the power of TGB. The biggest complication was managing all the mounts and layers for all the cards. Since Solitaire is a pretty open ended game, where player moves are unpredictable, we needed some solid game logic rules.

We came up with the general rule that every card is mounted to something, whether it be a column marker, a final drop marker, the card deck marker, or just another card. This way, the core game logic boils down to the player clicking a card, moving that card with the mouse, and testing the drop area when the mouse is released. Drop tests inlcude a half dozen checks to determine if the move is legal - if not, the card is sent back.

Layering was also a little complicated, since the cards need to appear overlapping. Normally, this is no problem, however, when dragging an entire column of cards, we wanted the whole pile move across the screen over all the over cards already in play (at the lowest possible layer). So, we came up with some new methods that quickly return the number of child mounts, the number of parents, as well as a method to quickly re-sort the layering for all cards.

Aside from the mounting and layering complications, the game was mostly art driven. We worked with Ryan Bliss to get some great 3D artwork into the game and spent quite a bit of time working on the card deck image map to get it to look right. Each level has its own feel with its own effects and music track.

Overall, it's just a fun little game to kill some time - all thanks to TGB!

Next Steps
We're currently testing, testing, testing. The Windows work is pretty solid and now we're testing out the game with Mac OS (Tiger). We'll probably open the game to public Beta next week, so if anyone is interested in participating, please email: beta@envygames.com . Our goal is to get some feedback about the gameplay, and work out any machine compatibility issues. We're aiming for a release in early August.

John K.

Racing Along with TSE

John Kanalakis — 2006-06-15T22:50:30+00:00

We haven't had much time to write about our project, so here's a first look at what's in the works at EnvyGames. Although the game still remains untitled (internally referred to as project GrandSlam), we're making great progress with the underlying technology and game mechanics. Building the game with TSE has been a huge win for us in terms of the visual polish we have been aiming for. Here's an example...

Image Expired.

About the Game
The game itself is a futuristic Baja Rally race where players sport hover vehicles across a 2,000 mile stretch of an abandoned mining asteroid at the edge of space. This is where the galaxy's roughest & toughest badasses get together to race a track filled with mechanical and natural hazards. With danger at every turn, this race isn't about winning, it's about surviving!

Game Technology
As mentioned earlier, the game is being developed with the Torque Shader Engine. TSE has a lot of fantastic features that help us reach the realistic gameplay we're trying to achieve, including:

* Material Shaders: adding bumpmapping, glow, and specularity to shapes

* Render-To-Texture Shaders: allowing us to produce HDR and shadow lighting effects for greater depth

* Atlas Terrain: providing realistic looking, highly detailed terrain

* Optimized Rendering: leveraging TSE's fast rendering code for highest possble performance

* Well Organized Source Code: easy to modify and extend; the scripting lets us quickly change and experiment with gameplay.

Target Hardware
This game targets high-end PC hardware supporting Pixel Shader 2.0 graphic cards. Our design goal for the game is to offer a gaming experience that intelligently pushes the limits of the hardware, while keeping under a file size appropriate for download distribution.

Next Steps
* Shaders: Applying shader materials to shapes is relatively easy. The real challenge is in creating full screen effects that add more depth to the game, such as shadowing and high dynamic range lighting. As such, glowbuffer is quickly becoming our best friend.

* AI: This is proving to be the most difficult aspect of the game's development. Although the core challenge of the game is navigating through the rough terrain, we're working hard to build character into the opponent AI. Simple path-following opponents don't offer enough, so we're building out a system to give opponent racers the smarts to pass, slow down, crash into you, and so on.

* Level Building: Since this is not a lap race game, we are putting a lot of emphasis on uniquely building out the 8 legs of the race. Each leg features a different aspect of the abandoned mining asteroid and comes with its own set of dangers. The challenge here is creating the terrain in one tool, the interior shapes in another tool, and assembling everything with the in-game editors.

More details to come in future updates...