Plan for Gian Piero Favini

Seven weeks of Torque2D

Hello everyone, this is my first plan even though I've been a Torque2D owner and an avid reader of these forums for about two months. I want to get more involved in this active and very helpful community from now on! I wrote a longer plan yesterday, but it turns out it got eaten because it timed out and I didn't save it beforehand, so this one will be shorter. :)

I'm a 23-year-old computer science student who is 3 exams and 1 thesis far from getting his Master of Science, and I've programmed a couple of shareware games before, but I got to a point where my ambition required a game engine I had neither the time nor the expertise to make, and I finally stumbled into the GarageGames site where I saw Torque2D.

When I bought it, I knew perfectly that it wouldn't do everything I wanted it to right out of the box, but I was well prepared, and hoping the code was easy to extend, my very small team and I began work on our game, which currently goes by the working title of The Game, a title so brilliantly simple it's almost scary. :)

My aim is to make a Tactical RPG with many twists, combining the classical Japanese genre of isometric battles tied together by a dynamic and possibly player-driven storyline, with a good injection of Western mentality with rulesets based not on end-of-the-world spells that last two minutes to watch (and the enemy, strangely enough, survives), but actual tactical moves that, if mixed wisely, can turn the tide of a battle.

Now let me say it, the Torque foundation and T2D are great! For someone with previous programming experience, diving into the code is surprisingly easy and satisfying, it does everything it's supposed to, and making a change actually changes the program without breaking it. Excellent. :)

But Torque didn't support isometry!

That was a problem, since the game was supposed to be isometric. Sure, I could have done it 3D, but 3D isn't the remedy to all illnesses. This kind of games can still benefit greatly from a 2D approach, and no-one in the team has any significant experience with 3D modeling. So I studied the way T2D works and implemented a middle layer in C++ that takes tile data and heights and generates the appropriate T2D objects and tilemaps to convey the required isometric effects. This took me about a week, programming in my spare time, mostly evenings. Here is a screenshot.

Large Version!

Full isometry, supporting 90 degree rotations even though I'll improve those later, because tiles may look differently when rotated. In this game you can't have multiple isometric layers (like elevated bridges), but they could be added without too much trouble, it's just that a lot of other things such as AI would get even more complex, and the project is already big enough as it is.

Z-Ordering Love...

This gave me the biggest headache. I failed to consider that when you have entities that span across multiple tiles, you might not be able to tell whether A must be drawn before B or vice-versa by just looking at their coordinates. Depending on what lies between them, sometimes A must follow B, or the other way around. I've set up a sorting algorithm that computes "hard precedences" between two entities (A>B or B>A). If a hard precedence cannot be found, the algorithm scans the object list for a "soft precedence", that is, an entity C such that A>C>B (and then A>B) or A
The Dirty Hack of Doom!

I love Torque's event-driven paradigm, but one size does not fit all. As dirty and repulsing as it may sound, I like a nice "wait(1000)" call every now and then, especially in a game which is centralized by its own nature. Being able to advance the simulation and then return control beats using 'schedule' calls because you don't need to break up your code or pass insane amounts of parameters.

So I basically made Torque's main loop re-entrant... It was just a test, but the baby is robust and it worked! I can now call the main loop from both C++ and TorqueScript, and so far the only glitch happened when I called the 'wait' function from a mouse callback (it would freeze the mouse until completion). But putting a single schedule call there and deferring the entire procedure containing the 'wait' by 0 millisecs solved the problem... so I'm happy. :)

What next?

Lots and lots of things! So far characters can move, attack, jump and use a few skills, and the AI (with building blocks written in C++, like pathfinding, and then scripted AI schemes) can home on the nearest target and attack it. More GUI work is needed (so far I have a nice drag'n'drop GUI Control that doesn't touch Torque's code and works nicely by just implementing a few callbacks, then I have dynamically resizeable portraits and a text sceneObject that can hover over a character's head to taunt/comment Fallout anyone?). Weather effects - rain, snow, hail. And... ranged attacks will be very hard to do. I want people to be able to take cover behind columns and the AI not to shoot people behind columns. But with a little bit of patience, it should all work out. :)

In my next plan, I'll be talking a little bit about my thesis since it's game-related, too; artificial intelligence for a hard chess variant, Kriegspiel, where you can't see your opponent's pieces.

Thanks for reading this far, :)
-GP