Evaluating iTorque - Some questions first

#1

Quote:Does Torque allow you to create a game object that contains child "sprites" that can be changed at runtime, dynamically?

The engine allows mounting. You can have a base sprite and give it several mount points. You can then attach other sprites to each mount point, from the editor or dynamically from code.

Quote:Does the Torque animation editor tool allow you animate game object properties (i.e: rotation, scale, opacity, etc) or is it used only for spritesheet animations?

All of what you mentioned is possible. After viewing the video, that looks simple enough to do from script.

Quote:How would a game like Battleheart perform if it was built in Torque? Is Torque performant enough to use to create a game like Battleheart or are the limitations on iOS too much to warrant using Torque?

I have not played Battleheart, but I just watched a trailer for it. iTorque is more than capable of handling that. I have gotten 100 static sprites moving around a screen and bouncing off walls, performing around 45fps.

Quote:Is it possible to use Objective-C with iTorque or am I limited to just TorqueScript and C++?

Absolutely. I have become a fan of the language myself. The engine is full source, which is comprised of C++ and Objective C. If you wish to implement an iOS specific feature the engine does not support, you can write it in Objective-C and expose it to C++ or TorqueScript. You can look at a tutorial I recently wrote that shows a very basic example of this: Interfaces.

#2 Thank you very much for the response Michael!

I do have a couple follow up questions, though.. if you don't mind :)

Quote:The engine allows mounting. You can have a base sprite and give it several mount points. You can then attach other sprites to each mount point, from the editor or dynamically from code.

This is good to hear. If I were to do this, could that base sprite be reusable? Essentially, can I create a character sprite that I can instantiate 4 times with different mounted child sprites?

And lastly, and maybe you'll be bias on this question (seeing as you work for GarageGames), but is the future bright for Torque? I know it's been through some distress in the past year or so (so I've read). Are things starting to look up? I'd hate to adopt a platform and then have it fall off a cliff 6 months later, ya know? :)

Thanks again!

#3

Quote:If I were to do this, could that base sprite be reusable?

Yes. My approach would be to design the first version visually in the editor. I would create the base sprite, add the mount points, then mount the appendages. When you save the level, all of that data is written out to a text file. You can then copy that data into a function, stripping out all the code specific to that prototype (image file, position, orientation, etc). When the function is called, you can fill that code with your own variables, thus dynamically creating character sprites.

While we do not offer a trial for iTorque 2D, you can download a demo for the engine it is based on: Torque 2D. They share the same base technology and editor, so you can try to prototype the game using the editor and TorqueScript. There are some differences and modifications specific to iTorque 2D, mainly optimization and iOS specific options. However, you can get started with the concepts I mentioned.

Quote:And lastly, and maybe you'll be bias on this question (seeing as you work for GarageGames), but is the future bright for Torque?

The brightest I have experienced since joining the team. The new owners are extremely invested and care about the products, the team and the community. Eric, the CEO, is pushing us to new heights and is the perfect blend of tech and business experience. While we did lose some great team members when we rebooted, we have already grown significantly. We are building roadmaps that stretch over years, not months.

Yeah, I may be biased. However, I also have the inside information to trust we will be hear much longer than six months. The passion, the talent, and the finances available make me truly believe that.

#4 To add to the longevity question, I have been a contractor since 2007 primarily concerned with community management, e-mail support, etc. I just recently signed on full time and moved to Vegas, picking up 36 years of my life, community theatre involvement as the president of the board of directors, and a job of 13 years to jump onto this ride. I would not have done that if the company were in dire straits. :)

#5 Jason, is everyone on your team who plans on using iT2D going to be programmers?

Michael's response to 'reusable' base sprite speaks volumes. Yes you can do it, but you have to get into the code in order to do so. That sums up a lot of my experience with iT2D so far. As long as you are a coder, you should be alright in navigating the issues and hacking around them, just don't expect your artists or designers to be able to crank out levels on their own.

But, that is part of the beauty of it as well. Since its open source, you can bend it to meet your needs.

Ex:
I wanted reusable base sprites as well. But found that when designers copied and pasted mounted sprites, the mounts broke. Thus, making them worthless. Bug Report: http://www.garagegames.com/community/forums/viewthread/125140

On the positive side, since the project is open source I was able to spend a couple days and figure out how to enable copy and paste so that our designers and artist could copy and paste 'baddies' (with their mounted limbs) throughout the level at will. Resource: http://www.garagegames.com/community/resources/view/20931

Sooo, its not all rainbows and puppy dogs, there are some concerns. BUT being open source you have the power to fix them. AND Michael, Garage Games, and the community are a wonderful and responsive support system. Garage Games is listening, they are eager to address issues, and the toolset has already been improved since I joined just earlier this year.

#6

Quote:Jason, is everyone on your team who plans on using iT2D going to be programmers?

My team consists of me and an Artist :) I'm the sole developer, and he's the sole artist. I'll be the only one using Torque.

On the "mount points" that Michael mentioned... maybe I'm crazy but I'm looking around inside the TGB that comes with the Troque 2D trial installation (On Mac) and I can't see where I can edit mount points for a static sprite. Am I missing something?

#7 @Jason - Have a look at this specific section of a tutorial I worked on: Rainy Day: Mounting

They are called Link Points officially.

#8 Thanks a bunch, Michael! That was super helpful!!

Now, my second question. Can I define a mount point on one static sprite, and a second on second static sprite, and have the two "mount together" at their defined points? It seems like the "mounting sprite" always wants to mount at the center, and that's not where I want it to mount.

I guess I could just move the mounting points to account for the offset from center but I'd much rather have the two mount at their designated points.

Make sense?

#9 @Jason - That does make sense. Honestly, I've never tried that. I think it will only try to mount the center of the sprite to the link point, but I will run a test and check the engine code for potential solutions.

#10 @Michael - I look forward to your findings on this. Your help has been greatly appreciated and has single handedly persuaded me to go ahead and make the purchase of Torque once the trial runs out. You don't find help like this in many places these days!

#11 To share some good news.. Following Michael's guidance I was able to get my sprites setup properly. I did this by creating a set of link points on a scene object. I was then able to mount my static sprites to these points to create my sprites.

The following images show the result of this. I'm pretty happy with how easy this was to setup. This was all done through TGB, copying and pasting the "base" scene object so that I didn't lose my link points. I have not attempted to make this reusable through code yet, but I'm excited to get around to trying!

The only downside, IMO, is if you notice points 1 and 3 are set way off the object (-1.250 and -2.240, respectively). I wish I could set "matching link points" on the sprite and on the scene object that I can match up when mounted. Hopefully Mr. Perry's tests prove this to be possible! =)

Anyways, just thought I'd share and show off my effort :)

From within TGB:

And the result:

#12 ha, love the images. grats on getting the ball rolling!

#13 @Jason
It's possible to mount 2 sprites connected not at the default (center) point. Here's some code

%x = %this.block[1,%j].getPositionX() - %this.block[1,%j].getSizeX()/2  - %this.block[0,%j].getSizeX()/2;	
%y = %this.block[1,%j].getSizeY()/2;
%localPos = %this.block[1,%j].getLocalPoint( %x, %y ); 
%xl = getWord(%localPos, 0); 
%this.block[0,%j].mount ( %this.block[1,%j], %xl, 0 );

the "block" variables are 2 sprites, here I was only interested in the x axis. These were bricks that needed to be connected to each other and not overlapping at all.

See the documentation for the "mount" method of t2dSceneObject, it accepts extra parameters for x and y offsets. These offsets are in object coordinates, so that code sample does some translation between coordinate systems; this explains coordinate systems
docs.garagegames.com/tgb/official/content/documentation/Reference/TGB%20Glossary...

#14 Here's the example, before and after mounting

#15 @Jason - Very nice! Looks like you picked up on the tools fast. The art looks fantastic. I'm glad you are having positive experience and look forward to seeing you in the forums. We'll be around if you have other questions

@Pedro - Excellent code snippet. That's extremely handy. I'm bookmarking this myself =)

#16 Thanks Michael. Yes, that code can be adapted for a general purpose function to connect 2 sprites side by side.

#17 @Michael - I'll pass the art feedback onto my artist. He did do a fantastic job capturing the spirit of the game. They seem to belong in a game called "Patchwork Battle" =)

@Pedro - Thank you very much for that code snippet! I'll def. have to give this a look when I get home tonight. I do have a couple question questions on it, however -

1) I'm assuming I could just easily achieve this in Objective-C/C++? I'd like to avoid TroqueScript as much as possible. I just don't like scripting languages :)

2) Could this be modified to get the link points off of the mounting sprite, calculate the offset from center, and then mount at that point?

#18 1) Yes, but I should manage expectations here. The base engine was built to support creating objects in TorqueScript. When objects are created, a lot happens behind the scenes. I Just woke up, literally about 5 minutes ago. Now is not a time for me to post code, since it will be prone to errors. When I get to the office, I will post more details.

2. Yes, but some modification will have to happen. You have two options. Either programmatically run a routine for the nodes at run time or extend the mounting system to have multiple link points and offsets. That's the benefit of offering full source.

That brings me to the main point of my thread. From your questions and desire to use C++/Objective C, I am assuming you are a competent developers. I do not have doubts that you could work in the source and bypass TorqueScript for a lot. You will still have to rely on scripting for very basic things, but a lot of iTorque 2D developers move their code into the source for performance reasons. More details when I get to the office.

#19 1) Foruming while half asleep is a dangerous game. I've inadvertently fed many a troll that way.

2) Once I pick up my iTorque license I'll have to check out the source for link points. See if I can get them modified to act how I'd like.

3) I'd like to consider myself a competent developer. I've been doing it for so long that sometimes I forget if I really am good at it or I just think I'm good at it =) I also don't mind some scripting. I just want to avoid using TorqueScript for as much of the core game logic as possible. Which, judging by what you say and what I've read, is entirely possible.

Thanks again for all your help!

#20 @Jason
You're welcome.

Regarding the C++ issue here is an old thread on how to possibly do everything in C++, that didn't got much traction though.

www.garagegames.com/community/forums/viewthread/28383

Like Michael said is engine is based in reading script from the ground up. To change this for using only C++, it would require major rewrites of the engine, that possibly would not be "officially" supported.

From reading these forums, what most people end doing is do a mixed approach: the "logic" part of the program in C++, the render part in script.

For the render part there are a couple of key classes that deal with this: Canvas, t2dSceneWindow and t2dSceneGraph. You add your t2dSceneObjects to t2dSceneGraph.

Here's what is possible a minimum app that just shows a window. It only uses the Canvas class to do this. To use this just replace your "main.cs" with this code:

$pref::Video::allowOpenGL = "1"; 
function initCanvas(%name)
{
   if (!createCanvas(%name)) {
      quit();
      return;
   }
}

function resetCanvas()
{
   if (isObject(Canvas))
   {
      Canvas.repaint(); 
   }
}

initCanvas("My window");

See the "Advanced" section here
tdn.garagegames.com/wiki/TGB/Tutorials_and_Guides
for tutorials on how to interface C++/script.

If you see these tutorials, the C++ part does not deal with any OS windoing part, it is completely OS independent (not IPhone or Windows specific). If I were you I would avoid to write any OS specific code for general rendering purposes, for example iPhone specific Objective-C parts.

The great thing about the engine is that is multi-platform (Windows, Mac, iOS). So, you can develop in Windows where you have script debugging tools like Torsion and then deploy to iOS.

Dealing with Canvas, t2dSceneWindow, t2dSceneGraph and t2dSceneObjects at the script level is the way the engine works.

I would be very interested in knowing if anyone in these forums ever tried to deal with these classes at the C++ level.

In my current project I have the logic part in C++ and I do some exchange of t2dSceneObjects from the script/C++ sides, but the render is completely script, which is totally fine for my purposes.

I do this not actually for performance reasons, but while developing a large scale program, you would want to have the main logic code in a way where you can develop it in a robust way, debug it, so it's for productivity reasons (and just because I like C++ :) ; C++ is not going to disappear anytime soon too.. )

This post has some code for C++/script object exchange

www.garagegames.com/community/forums/viewthread/100471