My TGE/Cocoa experiment
by Rocco Bowling · in Torque Game Engine · 10/01/2007 (9:02 pm) · 17 replies
About a year ago back I bought Torque in order to evaluate it for my future projects. A big part of that revolved around making Torque more Mac friendly (that's fairly important to me: www.freeverse.com/games/game/?id=4015). After a couple of weeks I stopped experimenting with it as life got busy. I've finally thought about telling people about it, so I figured some here might find it interesting.
My main development arena is Cocoa, so I wanted to make Torque play well in a Cocoa app. Hence, getting Torque to compile as a framework was #1 priority. #2 was getting it to work in CGL/NSOpenGLView and not AGL/Carbon. Finally, I threw in some fun stuff like bindings, bundle support, and basic HID support.
Probably incomplete list:
+ Torque compiles as a framework
+ Provides binding support for console variables
+ Provides special binding to execute Torque scripts when set
+ Provides Cocoa API to execute Torque console commands
+ Provides Cocoa API/bindings to support a Cocoa-based console window
+ Uses CGL/NSOpenGLViews instead of AGL
+ Automatically looks for game data in the application bundle, the application directory, or in ~/Documents/Torque (eases development)
+ Uses the system hardware cursor, and not a GL rendered one
+ HID button support
+ Panther/Tiger/Universal Binary
Demo application:
www.littlegenerals.com/cocoatorque.zip
- Rocco
My main development arena is Cocoa, so I wanted to make Torque play well in a Cocoa app. Hence, getting Torque to compile as a framework was #1 priority. #2 was getting it to work in CGL/NSOpenGLView and not AGL/Carbon. Finally, I threw in some fun stuff like bindings, bundle support, and basic HID support.
Probably incomplete list:
+ Torque compiles as a framework
+ Provides binding support for console variables
+ Provides special binding to execute Torque scripts when set
+ Provides Cocoa API to execute Torque console commands
+ Provides Cocoa API/bindings to support a Cocoa-based console window
+ Uses CGL/NSOpenGLViews instead of AGL
+ Automatically looks for game data in the application bundle, the application directory, or in ~/Documents/Torque (eases development)
+ Uses the system hardware cursor, and not a GL rendered one
+ HID button support
+ Panther/Tiger/Universal Binary
Demo application:
www.littlegenerals.com/cocoatorque.zip
- Rocco
#2
It drastically simplifies the Cocoa development portion. As a framework I can now incorporate Torque into a much larger Cocoa development with just a small ObjC class. If I wanted to do otherwise, I'd need to compile the entire torque into my cocoa application. I guess it boils down to what's important; if the main focus of the application is not entirely in the torque OpenGL window (which is not everyone's main concern, I know).
Further example, here's the XCode project for this demo application:
www.littlegenerals.com/TorqueDemoXCode.zip
The interesting Torque bit is in Controller.m... the only other code is my NSOpenGLView subclass.
[edit]
To clarify: My main goal was to embed Torque in a Cocoa application, not just to make Torque use Cocoa. Make sense?
[/edit]
10/04/2007 (12:24 pm)
Quote:why is compiling Torque as a framework a big win for you?
It drastically simplifies the Cocoa development portion. As a framework I can now incorporate Torque into a much larger Cocoa development with just a small ObjC class. If I wanted to do otherwise, I'd need to compile the entire torque into my cocoa application. I guess it boils down to what's important; if the main focus of the application is not entirely in the torque OpenGL window (which is not everyone's main concern, I know).
Further example, here's the XCode project for this demo application:
www.littlegenerals.com/TorqueDemoXCode.zip
The interesting Torque bit is in Controller.m... the only other code is my NSOpenGLView subclass.
[edit]
To clarify: My main goal was to embed Torque in a Cocoa application, not just to make Torque use Cocoa. Make sense?
[/edit]
#3
10/04/2007 (5:03 pm)
Would it help simplify the work of putting Torque inside a framework, if Torque were creating an NSWindow with an NSOpenGLView as its contentView?
#4
Having Torque create the window is too restrictive. As an application developer, I may want to load in the window dynamically, perhaps use a transparent window, have it be part of a more complex NIB, or even have it embedded in a sheet for all Torque should care. Ultimately you're just rendering to an opengl context, why restrict the application developer?
(Granted, I'm more picky than the typical game dev. I'm sure the 80% is probably happy with a simple window and opengl content view).
10/04/2007 (5:51 pm)
How would that simplify? I still need to include the entire torque code in new projects, instead of just a simple framework.Having Torque create the window is too restrictive. As an application developer, I may want to load in the window dynamically, perhaps use a transparent window, have it be part of a more complex NIB, or even have it embedded in a sheet for all Torque should care. Ultimately you're just rendering to an opengl context, why restrict the application developer?
(Granted, I'm more picky than the typical game dev. I'm sure the 80% is probably happy with a simple window and opengl content view).
#5
So far the demo you provided, doesn't support resolution changes, and also how would you partially update such an application?
Mostly curiosity... ;)
What is your connection with Freeverse? I own the game you pointed to, and it is very good. A great Mac App. :D
Thanks.
10/13/2007 (4:45 am)
Rocco, would you mind explaining to a complete nOOb what are the main assets in getting TGE running as a Cocoa application?So far the demo you provided, doesn't support resolution changes, and also how would you partially update such an application?
Mostly curiosity... ;)
What is your connection with Freeverse? I own the game you pointed to, and it is very good. A great Mac App. :D
Thanks.
#6
I didn't quite understand this question, could you be more specific?
You are correct in that the demo I provide doesn't support fullscreen. However, you can add that as you would in any other Cocoa application (use the Core API to take over the fullscreen and switch resolutions, and then CGL/NSOpenGL to make a fullscreen context). As far as the Torque framework should care, you just provide it the OpenGL Context once you've created it and away it goes.
The only inherent problem in the Torque framework is that you can only have one (do to torques current overwhelming use of global variables). Otherwise you could load multiple torque games simultaneously in a single application.
Do you mean how can the application update itself after release? You can use Sparkle for that.
[bio]
Resume
The short answer is I partnered with Freeverse to create them. I was responsible for the majority of the coding, artwork, and design (check the credits). Before them I released Solace with Freeverse, and have won a number of game dev contests over the years. Now I work for Big Nerd Ranch where I do consulting for a large casino company and I teach the OpenGL Bootcamp
[/bio]
10/13/2007 (10:27 am)
Quote:what are the main assets in getting TGE running as a Cocoa application?
I didn't quite understand this question, could you be more specific?
Quote:doesn't support resolution changes
You are correct in that the demo I provide doesn't support fullscreen. However, you can add that as you would in any other Cocoa application (use the Core API to take over the fullscreen and switch resolutions, and then CGL/NSOpenGL to make a fullscreen context). As far as the Torque framework should care, you just provide it the OpenGL Context once you've created it and away it goes.
The only inherent problem in the Torque framework is that you can only have one (do to torques current overwhelming use of global variables). Otherwise you could load multiple torque games simultaneously in a single application.
Quote: how would you partially update
Do you mean how can the application update itself after release? You can use Sparkle for that.
Quote:What is your connection with Freeverse? I own the game you pointed to, and it is very good. A great Mac App. :D
[bio]
Resume
The short answer is I partnered with Freeverse to create them. I was responsible for the majority of the coding, artwork, and design (check the credits). Before them I released Solace with Freeverse, and have won a number of game dev contests over the years. Now I work for Big Nerd Ranch where I do consulting for a large casino company and I teach the OpenGL Bootcamp
[/bio]
#7
First question could be better written like this:
What are the main advantages of a TGE inside a cocoa application compared to the current system?
10/13/2007 (11:04 am)
Thanks for the bio Rocco. :)First question could be better written like this:
What are the main advantages of a TGE inside a cocoa application compared to the current system?
#8
Ultimately, it boils down to what you believe a polished game should be. Excuse me for a second if I mount a soapbox.
The "problem" with most (if not all) cross-platform game engines is that they try very hard to provide a consistent experience across all of the platforms they support. Don't believe me, look at Paul's bio on this forum: "Paul writes and maintains the Mac port of Torque, and ensures that Torque games & products across Mac and PC platforms maintain a consistent, platform agnostic look and feel." I can understand... I did this myself in the past. That's why Solace looks and feels exactly the same on a Windows PC or on the Mac.
One of the lessons I learned from Solace is that by trying to provide the exact same look and feel across platforms leads you down the road of making a game to the least common denominator. You may find yourself disregarding features for a particular platform because there's no obvious or easy way to duplicate that support on another platform.
When I started the Big Bang Board Games (BBBG), I decided to take the exact opposite approach. I wanted to embrace a single platform and really make it shine in that environment. Once you make that embrace, whole new worlds of features suddenly become viable; features which can greatly enhance your customer's gaming experience. Luckily for Mac developers, the typical Mac user will fall in love with applications which feel like "great Mac Apps". The BBBG aren't special because they provide a great AI or that they included hours of tutorials or tips from game board experts, they're special because they are the complete Mac package. Integrations with technologies which make sense, like iChat, Bonjour, iSight, Mail, iTunes.
The easiest way to start along the path of feeling like a great Mac application is to use Cocoa. You gain much of that Mac look & feel for free. Specific example: live resizing of windows. Resize a window with Torque today and then resize the window in my demo, you'll see the difference. Mac user's have come to expect live resize in all applications, when your application doesn't have it then it doesn't feel like a Mac app.
After the BBBG I thought I'd look into some of the available engines, get a feel for how customizable they were. My one criteria was "Could I have written the BBBG if I used this?".
I started with Unity. While a neat idea, the answer was quickly a No. At the time (this might have changed now), Unity did not provide source code, so you were basically buying a hyped up world builder application. I had other bad experiences with Unity, but that's not the purpose of this post.
Next I examined Torque, and the results of which were the original posting of this thread. Given the changes I made to Torque, I believe I could rewrite the BBBG with it. After making it into a framework, I can simply plug it into my existing application in under five minutes. Want Bonjour networking with your Torque game? Write the Cocoa code in 5 minutes, then have that code fire off a torque script to cause the game to connect and start. Done.
To make a long post short (yea, right), from my experience cross-platform-ness at the cost of degrading the user's platform experience is a bad idea. Sure, you can cast a wider net that way, but with a little extra effort you can make something that really shines. The amazing part is, your customers will notice.
10/13/2007 (11:25 pm)
Quote:What are the main advantages of a TGE inside a cocoa application compared to the current system?
Ultimately, it boils down to what you believe a polished game should be. Excuse me for a second if I mount a soapbox.
The "problem" with most (if not all) cross-platform game engines is that they try very hard to provide a consistent experience across all of the platforms they support. Don't believe me, look at Paul's bio on this forum: "Paul writes and maintains the Mac port of Torque, and ensures that Torque games & products across Mac and PC platforms maintain a consistent, platform agnostic look and feel." I can understand... I did this myself in the past. That's why Solace looks and feels exactly the same on a Windows PC or on the Mac.
One of the lessons I learned from Solace is that by trying to provide the exact same look and feel across platforms leads you down the road of making a game to the least common denominator. You may find yourself disregarding features for a particular platform because there's no obvious or easy way to duplicate that support on another platform.
When I started the Big Bang Board Games (BBBG), I decided to take the exact opposite approach. I wanted to embrace a single platform and really make it shine in that environment. Once you make that embrace, whole new worlds of features suddenly become viable; features which can greatly enhance your customer's gaming experience. Luckily for Mac developers, the typical Mac user will fall in love with applications which feel like "great Mac Apps". The BBBG aren't special because they provide a great AI or that they included hours of tutorials or tips from game board experts, they're special because they are the complete Mac package. Integrations with technologies which make sense, like iChat, Bonjour, iSight, Mail, iTunes.
The easiest way to start along the path of feeling like a great Mac application is to use Cocoa. You gain much of that Mac look & feel for free. Specific example: live resizing of windows. Resize a window with Torque today and then resize the window in my demo, you'll see the difference. Mac user's have come to expect live resize in all applications, when your application doesn't have it then it doesn't feel like a Mac app.
After the BBBG I thought I'd look into some of the available engines, get a feel for how customizable they were. My one criteria was "Could I have written the BBBG if I used this?".
I started with Unity. While a neat idea, the answer was quickly a No. At the time (this might have changed now), Unity did not provide source code, so you were basically buying a hyped up world builder application. I had other bad experiences with Unity, but that's not the purpose of this post.
Next I examined Torque, and the results of which were the original posting of this thread. Given the changes I made to Torque, I believe I could rewrite the BBBG with it. After making it into a framework, I can simply plug it into my existing application in under five minutes. Want Bonjour networking with your Torque game? Write the Cocoa code in 5 minutes, then have that code fire off a torque script to cause the game to connect and start. Done.
To make a long post short (yea, right), from my experience cross-platform-ness at the cost of degrading the user's platform experience is a bad idea. Sure, you can cast a wider net that way, but with a little extra effort you can make something that really shines. The amazing part is, your customers will notice.
#9
I'm a Mac advocate for years.
The "polished touch" makes the difference between a Mac application and a Windows one. The consistency in the interface design, with tools and rules provided by Apple, turns Mac Os in something unique.
Most of the cross platform softwares, that are trying to remain identical on all systems are losing this feeling and thus, are less appealing than specifically designed ones. Even though as a long time Torque user, I'm so familiar with it I forgot this part of the design.
I think this has an impact on our own game too, and despite the fact we are on a nested market - turn based vehicular combat game(!) -, the global Mac feeling is not present enough to attract Mac users.
Big Bang Board Games really brought my attention with the so familiar environment.
Your reply is exactly what I was expecting it to be. Thanks for your time. 8D
10/14/2007 (12:00 am)
Yes, I got your point.I'm a Mac advocate for years.
The "polished touch" makes the difference between a Mac application and a Windows one. The consistency in the interface design, with tools and rules provided by Apple, turns Mac Os in something unique.
Most of the cross platform softwares, that are trying to remain identical on all systems are losing this feeling and thus, are less appealing than specifically designed ones. Even though as a long time Torque user, I'm so familiar with it I forgot this part of the design.
I think this has an impact on our own game too, and despite the fact we are on a nested market - turn based vehicular combat game(!) -, the global Mac feeling is not present enough to attract Mac users.
Big Bang Board Games really brought my attention with the so familiar environment.
Your reply is exactly what I was expecting it to be. Thanks for your time. 8D
#10
1. How hard would it be to port this to TGB?
2. Alternatively, would it be difficult to port just the gamepad support to TGB? Last time I looked, HID Manager and HID Utilities were pure procedural C, so I'm hoping that at least that piece can be re-used.
10/19/2007 (5:30 pm)
This looks like an outstanding effort! A couple of questions though:1. How hard would it be to port this to TGB?
2. Alternatively, would it be difficult to port just the gamepad support to TGB? Last time I looked, HID Manager and HID Utilities were pure procedural C, so I'm hoping that at least that piece can be re-used.
#11
The short answer is I don't have TGB (and I don't plan on buying it anytime soon), so I can't give you a good estimate of the level of effort required. My gut feeling is that most or all of the changes I made to TGE could be made to TGB fairly quickly.
10/20/2007 (7:38 pm)
Quote: How hard would it be to port this to TGB?... just the gamepad support to TGB?
The short answer is I don't have TGB (and I don't plan on buying it anytime soon), so I can't give you a good estimate of the level of effort required. My gut feeling is that most or all of the changes I made to TGE could be made to TGB fairly quickly.
#12
Do you intend to release the source for this mod in some form? I downloaded the demo, and I like the end result. But I'm working on a 2d Robotron clone in TGB, and it *really* needs gamepad support. The native GUI support is great, but the HID support will basically make it possible to play the game on a Mac.
10/21/2007 (4:12 pm)
I have source licenses for both, and I suspect you're right - they appear to share a common set of platform* directories, which I suspect is where most of your modifications would need to be.Do you intend to release the source for this mod in some form? I downloaded the demo, and I like the end result. But I'm working on a 2d Robotron clone in TGB, and it *really* needs gamepad support. The native GUI support is great, but the HID support will basically make it possible to play the game on a Mac.
#13
I just checked for the HID modifications, and they are present in 2 places. I added a _MacCarbHIDEvent() to macCarbEvents.cc and it gets called from my HID manager code (actually, in a more round about way. My HID code posts a notification of a HID event, which the Obj-C wrapper listens for an calls _MacCarbHIDEvent(). I suppose I could have macCarbEvents listen directly for the notification though and skip out the middle man).
I doubt the HID stuff would be hard to bring over to TGB.
I've been on the fence as to whether I want to release it or not. Actually, the HID code is from a past uDevGames contest which I have already released. I'm sure I can bundle that part up and release it, if having you think having it separate will help.
10/23/2007 (2:24 pm)
Quote: I have source licenses for both, and I suspect you're right...I suspect is where most of your modifications would need to be.
I just checked for the HID modifications, and they are present in 2 places. I added a _MacCarbHIDEvent() to macCarbEvents.cc and it gets called from my HID manager code (actually, in a more round about way. My HID code posts a notification of a HID event, which the Obj-C wrapper listens for an calls _MacCarbHIDEvent(). I suppose I could have macCarbEvents listen directly for the notification though and skip out the middle man).
I doubt the HID stuff would be hard to bring over to TGB.
Quote: Do you intend to release the source for this mod in some form?
I've been on the fence as to whether I want to release it or not. Actually, the HID code is from a past uDevGames contest which I have already released. I'm sure I can bundle that part up and release it, if having you think having it separate will help.
#14
But, the games I'm working on in the short term don't have a GUI - they're just old-school fullscreen arcade shooters. The HID code though - I could use that right now, in my current project. I was thinking of digging out Apple's HID Manager and HID Utility code, and hacking something together myself.
I'm disappointed that GG doesn't include HID support for the Mac right out of the box.
10/23/2007 (8:42 pm)
As a Cocoa-head, I'd probably spend a few hours looking around. I would definitely be useful in games that have a substantial GUI component. I'm sure I'd want to do something with that sooner or later.But, the games I'm working on in the short term don't have a GUI - they're just old-school fullscreen arcade shooters. The HID code though - I could use that right now, in my current project. I was thinking of digging out Apple's HID Manager and HID Utility code, and hacking something together myself.
I'm disappointed that GG doesn't include HID support for the Mac right out of the box.
#15
Instructions are in the readme. There are a few pockets of Obj-c code in there, but you could rewrite them in Carbon if you care.
FYI, the basic HID wrapper has been in the wild since 2003, so it works on older versions of OS X and (while not perfect) it has been tested by gamers on a large number of machines.
10/25/2007 (6:59 am)
www.littlegenerals.com/TorqueHID.zipInstructions are in the readme. There are a few pockets of Obj-c code in there, but you could rewrite them in Carbon if you care.
FYI, the basic HID wrapper has been in the wild since 2003, so it works on older versions of OS X and (while not perfect) it has been tested by gamers on a large number of machines.
#16
10/25/2007 (7:04 am)
One more thing, the HID wrapper "simplifies" things by converting everything to a button. For example, it doesn't return joystick axis, it instead monitors them to see if the joystick is on which side and then returns a button event for that (the game I wrote it for didn't care about deltas).
#17
07/03/2008 (10:19 am)
I just wanted to post a quick "thank you!" I didn't end up using your code directly - as I said before, all I need is just the basic HID support, and there's quite a lot of other stuff in there that appears to be concerned with connecting HID input directly to GUI controls. But, it served wonderfully as an example of using Apple's HID Utilities, and in the process of learning how to integrate it with TGB, I learned quite a lot about Torque as well. 
Torque Owner Paul Scott
Default Studio Name
I'm actually working on cocoa support in torque this week, so I'd love to see your code.
Feel like contributing?
Something I'm curious about: why is compiling Torque as a framework a big win for you?