Game Development Community

iTGB - Application development.

by Marcin Maciukiewicz · in iTorque 2D · 09/30/2009 (9:31 pm) · 2 replies

Hi guys,

I'm creating a rich UI application for the iPhone platform. The design considers use of non standard widgets for
user interaction thus at some stage I started looking at this project like at a simple game not an utility application.
That's because there will be a lot of graphics and animations used for the frontend. Beneath that there will be a layer talking to a remote server (JSON) and using persistent storage.

This lead me to the gaming engines as an option to speed up development. So far I compare iTGB with cocos2d-iphone - trying to decide which will be most suitable. I understand the different approach each framework have and I see benefits of using the iTGB's editor. Although I did some work using TGB demo version, I still have some questions I couldn't answer.

Please help me and answer the following. This will fill the blanks on my comparision chart and help me to make a concious decision between.
1) I hope to have view layer built with iTGB editor and custom controllers developed by hand. I can accept using framework's scripting for controllers as long as they can communicate with remote services (JSON) and persist data (sqlite). How (in)accurate is this design for the iTGB project?
2) How easy/difficult it is to merge iTGB project with my own custom Objective-C code?
3) What is a normal development routine while working with iTGB?
4) How would you describe the learnig curve?
5) How do you deal with external libraries required in project? (I have sqlite and json in mind)
6) Is there a way to build a testable piece of code? ( unit testing )


Thanks in advance,
Marcin.

About the author

Recent Threads


#1
09/30/2009 (10:06 pm)
1) if you implement it all, thats accurate.
iTGB like TGB doesn't use any of those thing, its all C++ and scripting, no use of objc functionality where it isn't needed to talk to the iphone

2) will be quite some work. iTGB is not a framework that you just plug in, its a fullscale engine and you will ahve to rewrite your code to please iTGB not vice versa. how much work depends on what you want to do and how much interaction with iTGB exists.

3) To explain it in a formal way [develop, test, find bottlenecks, optimize]*
develop can be in the editor or archaically through text editors.

4) As with any torque tech, expect to spend weeks on it at least (advanced C++ dev)

5) you have to implement them and their usage. There is no such thing as plugins / modules.
#2
09/30/2009 (10:13 pm)
1) Communicating with remote servers is no problem. SQLite use would need a little custom code, possibly exposing the functionality as script functions if needed. More custom code is needed if you also want secure communication.

2) Not very hard, fortunately. You can drop in some existing classes, and find the initialisation of the platform code in T2Di to activate/allocate your custom stuff. I'd look at hooking them into Platform class methods, and making some script functions.

3) I dunno :)
Some people don't even touch the TGB editor. You can edit levels in it and compile the scripts, then move the compiled script hierarchy into the Xcode project. Or you can have the builder auto-generate its Xcode project every time (which it can also launch in the simulator).

It's also possible to work with desktop and iPhone projects at the same time, just tweaking graphics and resolutions for the portable devices near the end.

4) Not too steep. Easier than stairs to an experienced programmer. There are peculiarities with all engines while they're new to you (something to discover as you learn), like coordinate systems differing, or TorqueScript having its own operator to compare strings.

5) SQLite is built into iPhone OS, so just link and go. JSON? I know of several projects, and they're usually a few drop-in classes. You might want to write CocoaTouch code that fully integrates with it, and just pass strings back and forth via script methods.

6) There is a unit test suite in the source tree, but I've never bothered with it ;)

I dunno if T2Di is the best fit for a utility app, though. You're adding some startup time to initialise a graphics, sound, networking and script system. It might be better to rethink it with Quartz.