The next update

#21 Micheal,

The last time someone from GG posted to this thread regarding the issues was the 22nd. Your response comes on the 29th. I have not seen any official statement nor been notified of the status of iTGB. I may have missed other posts on the forum. I did not know a release was due within a week. Is that information in the forum or a blog? Is there a central place to check on the current status of iTGB?

I have no issues with TGB.

#22 Guys,

I want to chime in here a bit because I'm really concerned about the criticism I'm seeing of iTGB and iTorque in general. We've been SUPER honest (where others haven't) about what this device could and couldn't, regardless of the engine, from the very beginning. This is not a small PC. Getting PC-like framerates isn't just tough, it's impossible. The very best games on the iPhone have been optimized to the hilt and designed from the ground up to perform on this device, yet they still run at only 20-25fps. We're already there with a demo version of iTGB that most definitely was not designed for the iPhone. What's in the Behavoir Shooter demo is FAR more complex and demanding than what you'll see from any other engine provider. That includes Unity and Shiva for sure. What did we do with Behavoir Shooter? We optimized the art assets, but only by resizing and downsampling the quality some. That and we converted about 75% of the scripts to code. That's not much and the thing already runs at near production framerates.

Going forward, we're going to be building demos designed specifically for the iPhone to better demonstrate what's possible, but some of you need to come down to earth. There's no way a TGB game of serious complexity is going to run at production framerates without putting in some work. This is not a reflection on the engine at all. This is a tricky device to develop for and it can only do so much.

We're going way beyond providing just a port of TGB and TGE. We're going to be looking into automating some optimizations that will save you even more time and energy making your game, but to say that what we've provided isn't worth $750 is ridiculous. There's no way that starting from scratch, you'd be able to build a game (let alone an engine) of any complexity or fidelity and have it up and running without serious errors in a month or even two months full time without iTGB. TGB lets you build the game design, tune the concept and gameplay, and assign specific game behavoir in a straightforward, easy-to-understand fashion. It will take that game and allow it to deploy on a device that was NOT built to render complex scenes or perform the kind of calculations at runtime that most games require. iTGB does that for you with no headache and full access to what's going on. Your game may not be ready to run a production speeds on the device, but it's not throwing huge errors that you can't understand at you either.

After that, we've discussed many ways you can improve the performance of your game so that it works with the device. Script-to-code conversion is a HUGE win and while it MAY not be necessary after new improvements to the Torquescript compiler are released, that depends on the complexity of your game. You can only throw so much at the iPhone's CPU before it chokes on the calculations. If you're serious about making ANY complex game for the iPhone, converting all scripts to code should be considered. iTGB lets you do that because the full source code is included. Other engines do not. 1.0.1 is not a rough product. It's actually very impressive in that it supports all of TGB's current features out of the box. This doesn't mean you should abuse physics and texture memory and expect miracles. This means that no matter what kind of TGB game you've made, it's almost certain that your game WILL port and run on the iPhone. That's pretty astounding work actually. TGB is not a simple engine and we could have done a much rougher job with it by just cutting out and not supporting features that are commonly tough to make work with the iPhone. Rather, we're letting you see you game as you conceived it run on the device and make your own calls about what's okay to cut and where you're comfortable with compromise.

My point is, check your expectations. No engine on earth is going to port and optimize your game for you. We provide the port. We'll make optimizing easier and we'll open the doors for you to make a lot of key, game specific optimizations that will probably be necessary to get production framerates out of a complex game by providing you with the source code. Improvements are coming, but "push-button" doesn't exist and cannot. It's a ridiculous thought and if you are serious about making a successful game for this device, you're going to want to dig deeper than that anyway. We allow you to do that, and quite cheaply to boot.

I want you guys to be successful. I want to empower you with quality products. TGB for PC and iTGB 1.0.1 are quality products, but you need to take some responsibility and do your homework re: what this device can and can't do. I honestly hope that everyone one of you using iTGB get your game up in the App Store and sell thousands of copies, but at some point you're going to have to dig in. No technology will do it all for you.

Expect more news in the coming weeks. We're listening. Ask good questions. Talk to each other. Good luck!

#23

Quote:The last time someone from GG posted to this thread regarding the issues was the 22nd. Your response comes on the 29th.

The last inquiry someone posted was on the 28th. I responded within 24 hours, which I hope is fast enough for someone who is documenting 3 engines concurrently while helping with iTorque QA and community management.

Prior to that, I did not have new information because I did not have a meeting with the iTorque devs. You've been a community member for 7 years Kenneth. When was the last time a Torque product received this kind of transparency treatment? I said it before: As soon as I know something, I will immediately post here to let you all know.

To answer your other question, these forums are the main source of iTGB news. If it is big, we'll post a new thread or a new blog similar to: "iTGB 1.0.1 Available Now!"

#24 Well spoken.

Knowing your device is critical on the iPhone, even more critical than knowing graphics hardware for TGEA (shader) development is. Because shaders just run less fast, but a anti-iphone developed game just dies to a handfull of FPS.


But I hope you agree Brett, that expecting native PVRTC support on an iPhone targeted engine of any kind is a fair expectation. After all, memory is one of the largest restrictions on the iPhone beside its raw performance, and the PVRTC profiles have a large impact there. (for those not knowing: PVRTC is a hardware compressed texture similar to DXT / S3TC on the pc builds. difference is that you can get an ARGB pixel which normally has 32bit into 2 / 4 bits which means a reduction by factor 8 / 16).


Otherwise you are right, iTGB offers a pretty good performance already out of the box and if teams start to optimize it for their own needs it can be expected that it gets even better.

As owner of Unity iPhone Basic and iTGB I've had the chance to compare both and have to say that both have their Pro and Con. I will use both in the future, as both are very powerfull, flexible and straight forward in their own area. But that was planned from point 0. Reason is simple: Unity is great for 3D games and/or games where you want a web version as well.
iTGB is great for 2D and comes with sources which offers (once I came up with a solution how) theoretically the possibility to use the UIKit to do option menu etc so you have the real iphone keyboard at your hand.

#25 @Marc: You're definitely right about PVRTC. That's been in the dev roadmap from the beginning and we'll roll that out as soon as we can. It will likely help a lot with texture memory issues. I just don't want anyone to get the impression that some future release is going to make finishing a game easy. It won't. It can't. Not unless a game is trivially simple will it run out of the box and at production speeds. PVRTC will help, but it's just one step, just as script-to-code, and game specific optimizations are important incremental steps to a finished product.

I have no doubt that many of you will get there with iTGB, just as some of you will not. We built a strong and sturdy bridge that will run your game on the iPhone. Once you get across that bridge, it's going to feel a bit foreign, but with some study and some exploration, you'll figure it out and adapt to the new environment.

#26 Thanks for your answer, but the important question is: when this update will come?one week? three weeks? Please tell us some details

#27 A note on PVRTC:

We are implementing support for this format but I wanted everyone to know this is _not_ a lossless compression format like PNG.

This means that you should use it for backgrounds and static objects but be aware that using it for your main characters may result in artifacts in your animation. For example a white pixel for a highlight in an eye may be gray or worse flicker on/off in the animation. Just something you might want to be aware of.

#28 On the usability front, I totally forgot to reply to Ed.

@Ed - You mentioned you wanted "Steps 3 and 5 to be unnecessary." What were you referring to? A tutorial?

Quick question: Would anyone find it useful to have a button in the TGB Editor which deleted and recompiled all of your game's script files?

#29 Yes, that would be very useful. I was never quite sure of the best way to make sure the .dso's were up to date before doing a build in XCode.

#30 Paul, I'm pretty much aware of those restrictions.
Its like S3TC up to a given point (just even more agressive, DXT1 at max offers compression to 1/8 of the size, so PVRTC4, PVRTC2 is compression to 1/16 ... clear that not much of the data theoretically survives. but we also are talking about 480x320 px on a small screen, so no large pixels which makes them much more interesting than they otherwise would be)


Micheal: Such a button would be interesting. But with the script-to-code Brett mentions above, would that still be needed at all? (or does script-to-code ASM compile the DSOs?)

#31 @Marc - One of the modifications being made is improving the script execution and compiling routines. Right now, the script system is the bottleneck. With the improvement comes the option to try and build your game in script again, which is great for newcomers to Torque.

#32 That sounds great :)

#33 Like Marc said, each engine has it's strengths.

I have switched to Unity Indie + iPhone Standard, and now my dominoes game is coming along nicely, have it running on the iphone and can toggle the physics on or off to make it play like a 2d game or a 3d game. The Unity 2d platformer tutorial is a good example of how one can do 2d in Unity. Someone ported the 2d platformer to the iphone in like 1 day after the release!

If anyone wants a list of reasons why Unity iPhone is superior kit, just email me. I wasn't a Unity user until right after I got the shock that was iTGB. I would ask for a refund except for the honest fact that I want GarageGames to grow and it's always been an awesome community. So, may the force be with you, GG. But simply- I found something better, for me, on the iPhone.

#34 I've tried avoiding rants not related to documentation, but sometimes a little venting goes along way in communication...not to mention game developers are extremely passionate about what they do and love =)

@Alex - Interesting 1000th post.

I could spend the rest of my weekend talking about why I think Torque is better than Unity, but I think the fact that Torque was included in a top 10 AAA engine list (and not Unity) speaks for me. I'd rather get back to writing docs and passing along this thread's feedback to the developers, so let this message be my final word on this matter.

While competition is inevitable, and honesty is fully appreciated, claiming to want GG to grow AND promoting a competing engine (in our forums) are at complete odds. Correct, you weren't a Unity user before iTGB's release. You were a GarageGames Associate.

The choice to use another engine for a particular platform is not uncommon, but heralding the bugs of iTGB in another development community within a few days of its release is in poor taste. As is the advertisement for Unity here, which destroys the original intention of the thread.

I've been apart of the community as long as you have been. Becoming an employee does not lessen my involvement: nothing will change my stance. If you are a GG member, I wish you all the development success, health, and happiness you can achieve.

Another developer posted a blog about his iPhone application, which he published using his own engine. I applaud his game, just as I will applaud what you can push to the iPhone App Store. I can't applaud your post, though.

I'm not trying to fight with anyone. My whole purpose at GarageGames is to help everyone else develop their game. It will probably be a long time before you ever see my name on any credits screen. I'm OK with that, because I have put myself behind something I believe in: GarageGames and Torque Tech.

#35 @Michael, I hear ya. 1000ths post really? I should get off the forums (in general)
@GG, thanks for turning my Associate badge off. I was going to request that but you beat me to it.

Alright I'll see youze all in the iphone app store.

#36 I own both, Unity iPhone Basic and iTGB and I bought both because they both have their seriously strong fields.
As my current project benefits of not having 3D, iTGB is the much better choice. Also I need to add some extra stuff and there iTGBs source is a top notch reason to use it :)

After the initial frustration that an unfinished product has been thrown out at least a month too early, the now much better communication has compensated that for me. Thank you guys and please keep that up.

I'm looking forward to 1.0.2 or 1.1 depending on what version the one with script2source will be :)

#37 When is the next update due and what features will it fix/support?

#38 @Conor O'Kane - I do not have an exact date yet, but last I heard we are within weeks of a release. I believe the major feature is the scripting system improvement. Do not treat my words as concrete. I will be checking in with the devs again later this week, and if I receive an update I'll pass it on.

I'm hoping to have another set of tutorials go out. After the tutorials, I will start focusing on module overviews, which will take us into the engine.

#39 @Conor: I think I outlined this with you via email just a few days ago. There's a lot of effort going into Torquescript and PVRTC. There is no hard date for delivery on anything specific though. I'll let everyone know when there is.

@Marc: Thanks for your patience. It sounds like you "get it" and I'm definitely betting on you to be amongst the first people here to finish a game. If you ever have any questions that aren't getting answered here, just shoot me an email and I'll see if I can help.

@everyone: To reiterate my response to Conor, there is no hard deadline for the next update. In the meantime, there is a TON you guys can do that's not dependent on either effort. Just having the ability to get maximum performance from your game with a code-only implementation is a huge leg up on people using other tools or technology. It's is NOT a difficult process either if you're comfortable with Objective C / C++. NOT having the ability to do this is incredibly limiting, as you'll see if you spend any time trying to decipher the kind of build errors many Unity users are seeing as a result of Unity's implmentation not supporting dynamic typing. Note that the time this was released, Unity provided no documentation giving people a heads up that they would have to mod all their scripts this. Eliminating dynamic typing removes a major ease of use advantage that scripting has over coding. Debugging tools for Javascript or C# are not going to warn you about the kind of errors you'll encounter either. Putting headaches like that aside though, you will *never* get maximum performance out of a game that uses scripting. Sure, prototype your game in script. Get a concept that makes sense and creates a fun experience. Finalize the logic. But when it's time to get every extra fps possible out of the end product, you should be seriously considering an all-code implementation on the iPhone.

We've been straight from the beginning about what you'll need to do to ship a commercial quality game. Scripting is a compromise. Being forced to use scripting because you have no access to the code (the way Unity and Shiva do it) is seriously limiting. How are you supposed to profile bottlenecks or optimize systems? Trust me, they're NOT already optimized to production quality. If they were, you wouldn't see the poor frame rates on very simple demos.

I could go on and on about why using iTGB or iTGE is a *much* smarter choice than the alternatives, Unity included. If you'd like me to, please email me. Alex, this is an invitation for you to email me and tell me why you're happier with no source code, build errors you can't debug, weak performance, and no iPhone specific documentation. If the goal is to ship a game that will stand out from the crowd of junk on the App Store and make you money, I'm at a loss as to why you'd be happy with no source code. If the goal is to experience the novelty of seeing something you made running on the iPhone, iTGB and iTGE actually have full feature support out of the box, so you project will port in the form you created it. You'll still have dynamic shadows, dynamic lights, multi-texturing (which Unity calls "shaders" for some reason) etc. What about getting your app up and running? Yes, iTGB and iTGE will do this in a much more straightforward way as well. There are steps, but they are there for a reason. Combining or eliminating specific steps only leaves you vulnerable to longer turnarounds on build errors and debugging in most cases. The only reason I could see using Unity over Torque is if you're infatuated with the "remote edit" mode. This features feels entirely gimmicky to me. Torque could easily do this if you all wanted it, but I'm at a loss to see why this is useful to the process of making a game.

Unfortunately, I'm getting off on a Dennis Miller style rant and I don't like beating up on other's products or approach to business without provocation, but I'm not a fan of drinking the Kool-Aid either. Unity has a no-holds-barred approach to marketing that I find distasteful, but it certainly makes an impression. I've always aimed GarageGames marketing and messaging to set appropriate expectations and be honest about what our products will do. If you're impressed by the Unity demo video which does some fancy cutaway editing to gloss over the lengthy build process and gives you no reason to anticipate any build errors, I don't blame you. It's some fancy footwork, I'm just not comfortable with it. I won't pretend that making an iPhone game is push-button easy when it's not and never will be. If it's that easy, please show me the results? If it's that easy, why don't I see Unity games up in the App Store yet? I'm not claiming it's easy. I'm claiming the opposite. Making a game for the iPhone is hard--much harder than for PC or Mac, no matter what the tools or technology. We focus on getting you guys all the way to the finish line, not a quick flashy sprint off the start. That's why you have source code. That's why we disclosed the performance bottlenecks and offered strong alternate paths from the beginning. That's why you'll have ongoing updates that address issues specific to this goal. If you want a product that actually ships games and makes developers money, you'll find nothing better than Torque.

#40 Actually there are unity games on the store. Like the snowboarding game done in under a week.

I guess the main reason to go with Unity for common users is the editor + unity Remote which allows you to test your game live within the editor using the iphone/itouch as an input device (the app does so by sending screenshots through wifi onto the itouch screen and sending the input data back). this does not replace build testing but it allows you to do live testing, another benefit of Unity (change value at runtime just within the editor). This makes the balancing for example much more straight forward than the enforced recompiles on iTorque to get it running with accelerometer & touch to get a real feeling for it. This is a clear benefit at the moment, especially as each test build for iTGB takes 5-10 mins to build and deploy.
I have the small hope that the "iTorque client build" for Windows / OSX at some point will offer such a remote as well to at least be able to test it.
The dynamic typing by the way is a JS only problem in Unity. C# does not have such a feature, so there is no problem. (unitys JS isn't JS anyway, its a JS like syntax over the boo core)

Why I use scripting mainly: iTGB consists of 432 files. Even thought I've a 2x 2.4ghz mbp, this still is a fairly long time to wait after the slightest change in sources.
I think some kind of encapsulation of the source blocks into fixed source blocks to reduce that, so only needed modules would have to be recompiled, would be a great thing here, but I'm aware that this is a trip to hell crawling on your knees sadly.
Once I reach the point where I'm happy with it thought I will likely backport them at least where needed and usefull.

The for me strongest reason for iTGB is that I can modify the sources to make it MY technology for future development as the game I intend to actually really do to grow over time, have different episodes etc so a for me opted technology is a pretty interesting option :)

In the end thought, I'm no fanboy. I use the best technology (I can afford) to hopefully somewhen reach my goal. Guess thats the reason I own licenses to about 14 3d technologies haha ...



Thank you for those information and the openness Brett. Should I have problems or struggle over hurdles where I could need some iTGB professional input, I will happily drop a mail.


PS: Just came up with a way to tell at least long term gamers how much power the iphone has: think of the iphone graphically wise as a cut down Nintendo 64, because thats what you should be targetting at visually.