Rack 'em Up Road Trip
by Robert Blanchet Jr. · 10/02/2006 (12:40 pm) · 34 comments
Today I am going to let everyone in on a little secret, one that involves a small dedicated team here at GarageGames working on a project that has been kept under wraps for a little while now. Rack 'em Up Road Trip is a Torque Game Builder based game that I have been working on as the lead programmer with the direction and insight of Joe Maruschak as project manager, Justin DuJardin, Mark McCoy, and Zachary Zadell comprised the core team.
Rack 'em Up Road Trip is a product GarageGames has been collaborating with Oberon Games for their casual games space, and as you can probably guess from the name, it is a pool game. Rack 'em Up Road Trip was built on a pre-1.0 build of the then Torque 2D engine, now Torque Game Builder and marks the first time GarageGames had to "eat their own dog food" on the TGB suite of technologies. After the first month of development one of the more important decisions we had made was to bring Justin on the project to help him eventually carry over some of the experiences he would be having developing the game into the work he was doing on Torque Game Builder.
I know what some of you may be thinking, "Why is GarageGames making games when they should be fixing their tech so I can make my game?". The short answer is that our tech isn't broken, at least not to the point of being unable to make games with it. The long answer is that in order to find what is wrong with our technology we must be allowed to experience it ourself, in the same manner that any other community member would use it, and that is to make games with it. By doing so not only do we find areas our tools and technology need to improve upon, but we also find the strengths of our technology, which is just as important.
Designing and building games is an extremely iterative process. At the end of it all that 100 page document on the look and feel of a game will more than likely not resemble the final product. This iterative process is most evident in the art but involves all aspects of the game from the flow of the user interface to the difficulty of AI players and feel of the physics. For anyone who has finished a game this process is understood and accepted. I emphasize finished because it is easy to say you've made a game, but it is something entirely different to make a game that hundreds or even thousands of people will play, and hopefully enjoy. Even the most seemingly trivial of things can make a huge difference to the overall enjoyment a person gets from the game. Literally no stone is left unturned.
It's also important during this process to be able to recognize when something is just good enough. Some feature or art can be changed and tweaked, and maybe each time it gets better. But the cost of implementing or changing those features gets higher as the project carries on. There is an excellent plan that touches on this, The Complexity Barrier by Dan MacDonald.
I think an excellent example of this iterative process from Rack 'em Up Road Trip is the entire GUI system that we eventually settled on. It seems funny to mention the GUI's as an example of this, after all it is just a GUI and there are many other examples: ai, quest, physics, just to name a few. But with the GUI system it is immediately obvious, looking back over the various incarnations, what it is I'm talking about. What we eventually ended up with really seems like a little mini-game, the way the GUI's transition from screen to screen, etc. It is very enjoyable.
For Rack 'em Up Road Trip our GUI went largely ignored for the first few months of development. During this time our main focus was on the pool table. How big was the table, how big are the balls and what does the physics feel like. Finally, and probably most importantly, how does the player interact with the table - what is the control scheme like. However, we still needed a way to get in and out of games, so during this duration the GUI was slapped together as quickly as possible with whatever the artists could conjure up. Doing this also lets us explore what the GUI flow will be like, what buttons should take the user where and why or why not provide them. All very important things to consider when designing the game because the first thing a user sees when they launch your game executable is your GUI, so it is important that initial reaction is a good one.
Initially we used the GUI controls that are provided by default from the engine, replacing skins and art where necessary to help convey the theme that we had finally decided upon, a road trip theme. Over the course of several months however, focus was gradually shifted over to utilize the TGB objects instead: static sprites, animated sprites, etc. This facilitated a need to be able to know when the mouse pointer has entered or left a particular 2d scene object which Melv May was able to put together for us as well as some other extra goodies like the ability to mount UI objects to TGB objects. All of these features have since made it into the core TGB tech.
The GUI design was constantly changing to meet particular needs, usability standards, and the bling factor. When a part of a game is in a rapid stage of development like this, it is important to communicate. I think the best form of communication is visual. Words on a page can be skimmed over and easily ignored or forgotten. A picture, diagram, or mockup more easily expresses ideas and encourages the imagination. Mark McCoy's UI mockups did more to advance the design of this game than a thousand pages of words. And the added bonus was the time and art that was involved in those mockups could then be reused, recycled, and put into the actual game. Even the time and effort that went into scripting the GUI was positively effected by having mockups laying around to look at.
Having just interned my second time at GarageGames from college I had very little experience with making and producing games. Some may know me well enough to know that a lot of my experience with Torque came from working on a Tribes inspired community project called Legends. Before then, all of my Torque Script experience came from having played Tribes and Tribes 2 for years.
One of the things I've found when working on Torque is that it is such a huge code base that when I learned an area of the engine really well, I began to forget things about other areas of the engine. For instance, working on the GUI systems for a couple weeks I started to become really familiar with the little quirks and details of it but then forgot little details about some other area. This isn't to say no one can become an expert with Torque, because I don't think being an expert includes knowing every single detail about Torque.
Torque is like a city. Like any city a person must get lost a few times before they can become familiar with the place. Road signs help us along the way and one can get a tour guide but in the end it is really just up to ourself to commit to finding our own way around. That tour guide is our Torque expert. They know their general way around, and they may know where some of the more significant shops and places are located, but they too have to look things up once in awhile.
I'm a product of this community. Everything I didn't know about Torque I learned with help from this community and my willingness to get my hands dirty and find the answers myself. When I was hired by GarageGames no one sprinkled magic fairy dust on my head. Correction, Ben Garney tried to sprinkle fake magic fairy dust on my head and Jay Moore mentioned something about Kool Aid. But I didn't walk into the GarageGames office door and suddenly become some kind of Torque demi-god. In fact I came across a couple of issues when working on Rack 'em Up Road Trip that I turned to the community for help, mostly by searching through our forums.
Rack 'em Up Road Trip was completed because the team working on it was dedicated to seeing it through. Granted, we may know Torque like the back of our hand, but knowledge only gets a project so far. It takes hard work and passion to cross the finish line. I know these are things the people in our community possess. There are some things we had to create for this game that will not make it back into Torque Game Builder. A very good example of this is the 3D-like ball physics. But let me make something absolutely clear, our ball physics for the game are just an extension of what is already available in TGB. We didn't have to rewrite the core TGB physics to get the results you see in the game, our technology is built to be extendable. The Rack 'em Up Road Trip ball physics was built on top of that framework, it did not replace it. Please don't let little things, like the exclusion of pool ball physics from the TGB core, stop you from creating your game. The tools and technology is there, and getting better, use its strengths and express yourself.
You can play Rack 'em Up Road Trip now at MSN Zone.
Rack 'em Up Road Trip is a product GarageGames has been collaborating with Oberon Games for their casual games space, and as you can probably guess from the name, it is a pool game. Rack 'em Up Road Trip was built on a pre-1.0 build of the then Torque 2D engine, now Torque Game Builder and marks the first time GarageGames had to "eat their own dog food" on the TGB suite of technologies. After the first month of development one of the more important decisions we had made was to bring Justin on the project to help him eventually carry over some of the experiences he would be having developing the game into the work he was doing on Torque Game Builder.
I know what some of you may be thinking, "Why is GarageGames making games when they should be fixing their tech so I can make my game?". The short answer is that our tech isn't broken, at least not to the point of being unable to make games with it. The long answer is that in order to find what is wrong with our technology we must be allowed to experience it ourself, in the same manner that any other community member would use it, and that is to make games with it. By doing so not only do we find areas our tools and technology need to improve upon, but we also find the strengths of our technology, which is just as important.
Designing and building games is an extremely iterative process. At the end of it all that 100 page document on the look and feel of a game will more than likely not resemble the final product. This iterative process is most evident in the art but involves all aspects of the game from the flow of the user interface to the difficulty of AI players and feel of the physics. For anyone who has finished a game this process is understood and accepted. I emphasize finished because it is easy to say you've made a game, but it is something entirely different to make a game that hundreds or even thousands of people will play, and hopefully enjoy. Even the most seemingly trivial of things can make a huge difference to the overall enjoyment a person gets from the game. Literally no stone is left unturned.
It's also important during this process to be able to recognize when something is just good enough. Some feature or art can be changed and tweaked, and maybe each time it gets better. But the cost of implementing or changing those features gets higher as the project carries on. There is an excellent plan that touches on this, The Complexity Barrier by Dan MacDonald.
I think an excellent example of this iterative process from Rack 'em Up Road Trip is the entire GUI system that we eventually settled on. It seems funny to mention the GUI's as an example of this, after all it is just a GUI and there are many other examples: ai, quest, physics, just to name a few. But with the GUI system it is immediately obvious, looking back over the various incarnations, what it is I'm talking about. What we eventually ended up with really seems like a little mini-game, the way the GUI's transition from screen to screen, etc. It is very enjoyable.
For Rack 'em Up Road Trip our GUI went largely ignored for the first few months of development. During this time our main focus was on the pool table. How big was the table, how big are the balls and what does the physics feel like. Finally, and probably most importantly, how does the player interact with the table - what is the control scheme like. However, we still needed a way to get in and out of games, so during this duration the GUI was slapped together as quickly as possible with whatever the artists could conjure up. Doing this also lets us explore what the GUI flow will be like, what buttons should take the user where and why or why not provide them. All very important things to consider when designing the game because the first thing a user sees when they launch your game executable is your GUI, so it is important that initial reaction is a good one.
Initially we used the GUI controls that are provided by default from the engine, replacing skins and art where necessary to help convey the theme that we had finally decided upon, a road trip theme. Over the course of several months however, focus was gradually shifted over to utilize the TGB objects instead: static sprites, animated sprites, etc. This facilitated a need to be able to know when the mouse pointer has entered or left a particular 2d scene object which Melv May was able to put together for us as well as some other extra goodies like the ability to mount UI objects to TGB objects. All of these features have since made it into the core TGB tech.
The GUI design was constantly changing to meet particular needs, usability standards, and the bling factor. When a part of a game is in a rapid stage of development like this, it is important to communicate. I think the best form of communication is visual. Words on a page can be skimmed over and easily ignored or forgotten. A picture, diagram, or mockup more easily expresses ideas and encourages the imagination. Mark McCoy's UI mockups did more to advance the design of this game than a thousand pages of words. And the added bonus was the time and art that was involved in those mockups could then be reused, recycled, and put into the actual game. Even the time and effort that went into scripting the GUI was positively effected by having mockups laying around to look at.
Having just interned my second time at GarageGames from college I had very little experience with making and producing games. Some may know me well enough to know that a lot of my experience with Torque came from working on a Tribes inspired community project called Legends. Before then, all of my Torque Script experience came from having played Tribes and Tribes 2 for years.
One of the things I've found when working on Torque is that it is such a huge code base that when I learned an area of the engine really well, I began to forget things about other areas of the engine. For instance, working on the GUI systems for a couple weeks I started to become really familiar with the little quirks and details of it but then forgot little details about some other area. This isn't to say no one can become an expert with Torque, because I don't think being an expert includes knowing every single detail about Torque.
Torque is like a city. Like any city a person must get lost a few times before they can become familiar with the place. Road signs help us along the way and one can get a tour guide but in the end it is really just up to ourself to commit to finding our own way around. That tour guide is our Torque expert. They know their general way around, and they may know where some of the more significant shops and places are located, but they too have to look things up once in awhile.
I'm a product of this community. Everything I didn't know about Torque I learned with help from this community and my willingness to get my hands dirty and find the answers myself. When I was hired by GarageGames no one sprinkled magic fairy dust on my head. Correction, Ben Garney tried to sprinkle fake magic fairy dust on my head and Jay Moore mentioned something about Kool Aid. But I didn't walk into the GarageGames office door and suddenly become some kind of Torque demi-god. In fact I came across a couple of issues when working on Rack 'em Up Road Trip that I turned to the community for help, mostly by searching through our forums.
Rack 'em Up Road Trip was completed because the team working on it was dedicated to seeing it through. Granted, we may know Torque like the back of our hand, but knowledge only gets a project so far. It takes hard work and passion to cross the finish line. I know these are things the people in our community possess. There are some things we had to create for this game that will not make it back into Torque Game Builder. A very good example of this is the 3D-like ball physics. But let me make something absolutely clear, our ball physics for the game are just an extension of what is already available in TGB. We didn't have to rewrite the core TGB physics to get the results you see in the game, our technology is built to be extendable. The Rack 'em Up Road Trip ball physics was built on top of that framework, it did not replace it. Please don't let little things, like the exclusion of pool ball physics from the TGB core, stop you from creating your game. The tools and technology is there, and getting better, use its strengths and express yourself.
You can play Rack 'em Up Road Trip now at MSN Zone.
About the author
#2
The ball physics are not controlled via script, there was modifications made to the C++.
Torque Game Builder comes with several physics capabilities that cover a large array of general purpose uses. No game engine is going to let you do everything imaginable, out of the box. And I wouldn't want to use a game engine that tried. Imagine how confusing it would be for an engine to have hundreds of different physics functions for every concievable scenario?
However, Torque Game Engine is built to be extendable. Sometimes that can be achieved in Torque Script, sometimes it can not. On the source code side I strongly believe Torque is the easiest game engine to change and extend. We proved that with Rack 'em Up Road Trip. It is entirely possible for you to duplicate what we have by creating just a single class that inherits from the stock 2d scene object and writing in your own custom physics calculations inside functions that are provided for you!
No magic dust is required. Just determination.
10/02/2006 (1:21 pm)
Jeremy,The ball physics are not controlled via script, there was modifications made to the C++.
Torque Game Builder comes with several physics capabilities that cover a large array of general purpose uses. No game engine is going to let you do everything imaginable, out of the box. And I wouldn't want to use a game engine that tried. Imagine how confusing it would be for an engine to have hundreds of different physics functions for every concievable scenario?
However, Torque Game Engine is built to be extendable. Sometimes that can be achieved in Torque Script, sometimes it can not. On the source code side I strongly believe Torque is the easiest game engine to change and extend. We proved that with Rack 'em Up Road Trip. It is entirely possible for you to duplicate what we have by creating just a single class that inherits from the stock 2d scene object and writing in your own custom physics calculations inside functions that are provided for you!
No magic dust is required. Just determination.
#3
Implementing a full pool physics system is not as easy as you are making it out to be.
-Jeff Tunnell, GG
10/02/2006 (1:39 pm)
@Jeremy: Sounds like you are essentially demanding that we include game specific code in a general game engine. You, as well as anyone, should understand how hard it is to make a game even with an engine. This game would not have been possible without T2D/TGB, but even with that some of the game is propietary and not appropriate to go back into the engine. We did the same thing on TGE, for instance, we still have not given out or rolled back in the marble physics code in Marble Blast. Similarly, we do not intend to give out the physics code that allows a specific implementation of pool.Implementing a full pool physics system is not as easy as you are making it out to be.
-Jeff Tunnell, GG
#4
I do agree with Jeremy though. If a major motivation for doing this project was to validate TGE/TGB or whatever as a viable toolkit for doing such a project, and you found yourself writing tons of C++ code to accomplish it, then I'm not sure what you really validated. Seems to me like what you mainly did is identify lots of areas where the toolkits may be deficient.
10/02/2006 (1:47 pm)
First, congrats on getting a finished game out the door. Every Indie's dream right?I do agree with Jeremy though. If a major motivation for doing this project was to validate TGE/TGB or whatever as a viable toolkit for doing such a project, and you found yourself writing tons of C++ code to accomplish it, then I'm not sure what you really validated. Seems to me like what you mainly did is identify lots of areas where the toolkits may be deficient.
#5
10/02/2006 (2:02 pm)
I agree with Jeremy and Arthur, a pool game is not that hard to make. TGB core should be able to handle the physics and you just script the game. Not to upset anyone but I did pool game in Game Maker that did not require any C++. I think this get toss out to quickly include game specific code in a "general game engine". Some people may not want to touch c++. You call it general game engine but you have it without the source code to buy, that may lead people in thinking that you can build all types games without touch C++. But nice game I like it. 
#6
If they found that in order to add appropriate ball physics it required a large rewrite of TGB's internals, then warning bells should be sounding that something is wrong with the core of TGB and development time spent on resolving it.
If however they found that so long as you have an understanding of the core that you can extend the functionality and plug in a new ball physics sim without fighting the core, then that would be a good validation of TGB.
GG do not have to release code for everything they do with their own tech and as a community we shouldn't expect it either.
That said, I think one thing the TGB community would find useful is if whoever was involved with the physics side of this knocked up (ok I make it sound like a quick thing and I know it's not ;) ) a TDN article for TGB pro owners that covered how they went about adding a game specific feature into the core.
How indepth an article obviously would depend on the spare time available and the physics code does not have to be direct from the pool game, more the process of how you went about extending TGB than exactly what sim you used, even a rough coverage would be great. I'm sure there are other examples of how TGB can be extended internally, I just picked physics since it's kinda fit the blog replies above :)
Anyhow congrats on the release, I'm heading off to MSN Zone to check it out :)
10/02/2006 (2:11 pm)
Arthur: The validation would be whether they were able to easily extend TGB to accomplish their specific goals rather than having to rip out and rewrite huge sections. If they found that in order to add appropriate ball physics it required a large rewrite of TGB's internals, then warning bells should be sounding that something is wrong with the core of TGB and development time spent on resolving it.
If however they found that so long as you have an understanding of the core that you can extend the functionality and plug in a new ball physics sim without fighting the core, then that would be a good validation of TGB.
GG do not have to release code for everything they do with their own tech and as a community we shouldn't expect it either.
That said, I think one thing the TGB community would find useful is if whoever was involved with the physics side of this knocked up (ok I make it sound like a quick thing and I know it's not ;) ) a TDN article for TGB pro owners that covered how they went about adding a game specific feature into the core.
How indepth an article obviously would depend on the spare time available and the physics code does not have to be direct from the pool game, more the process of how you went about extending TGB than exactly what sim you used, even a rough coverage would be great. I'm sure there are other examples of how TGB can be extended internally, I just picked physics since it's kinda fit the blog replies above :)
Anyhow congrats on the release, I'm heading off to MSN Zone to check it out :)
#7
10/02/2006 (2:18 pm)
---Edited by Jeff---
#8
@Pat Whatever Pat. Sounds like you guys may be well on your way to doing that anyway, especially with an attitude like that. You guys are not the only engine out there, so do whatever you gotta do.
10/02/2006 (2:27 pm)
@Gary I agree, but we're splitting hairs here. I said "tons of C++" and you said "easily extend", so we're talking about the same thing here.@Pat Whatever Pat. Sounds like you guys may be well on your way to doing that anyway, especially with an attitude like that. You guys are not the only engine out there, so do whatever you gotta do.
#9
Just like with MBU and our other games, there are some things that don't make it back. Some are VERY project specific (like integrating with a custom backend system), or legally encumbered (many publishers have clauses disallowing you from releasing a competing product right away, and often they restrict the code rights as part of that). Some are good experiments that aren't ready for primetime (like the fast mission loading code in MBU - very 360 specific, and difficult to work with).
You guys don't contribute back every line of code from your projects to the community... and neither do we. But we do try to make sure that the lessons learned are applied to our products (and TGB has definitely improved from it), and that where it does make sense the actual code moves over, too. More often we find it makes more sense to take those lessons and use them in the design of real, bullet proof systems, rather than the minimal systems needed to ship a game.
Would you rather have a situation like TGE, where there's tons of code that came from a real game and does whatever it does, or a situation like TGB is now, where the code that IS in there is documented, tested, and is pretty much useful for whatever? :)
10/02/2006 (2:28 pm)
TGB's architecture is definitely evolving due to lessons learned from the Billiards project.Just like with MBU and our other games, there are some things that don't make it back. Some are VERY project specific (like integrating with a custom backend system), or legally encumbered (many publishers have clauses disallowing you from releasing a competing product right away, and often they restrict the code rights as part of that). Some are good experiments that aren't ready for primetime (like the fast mission loading code in MBU - very 360 specific, and difficult to work with).
You guys don't contribute back every line of code from your projects to the community... and neither do we. But we do try to make sure that the lessons learned are applied to our products (and TGB has definitely improved from it), and that where it does make sense the actual code moves over, too. More often we find it makes more sense to take those lessons and use them in the design of real, bullet proof systems, rather than the minimal systems needed to ship a game.
Would you rather have a situation like TGE, where there's tons of code that came from a real game and does whatever it does, or a situation like TGB is now, where the code that IS in there is documented, tested, and is pretty much useful for whatever? :)
#10
not quite.
When this was mocked up, it was basically the old pool demo that was playable when t2d first came out. the basic implementation was done in t2d.. WAY back in the day.
after a while, the physics did not do what we wanted them to do, and did not offere the control that I wanted over the feel.
What we wanted was to have control over the speed of the balls, topspin and sidespin and how they interact with rails, and with other balls, and how they transfer spin in all these conditions. We separated all of these out into seperate components. In a simple sense, balls rolling and colliding is not hard..but with felt friction and bumper and ball resitution and spin transfer and separating the draw/follow from the side spin... it is actually very specific and not straightforward.
having been the one that did the physics tweaking, my opinion is that this functionality would not be a good candidate for a general purpose solution, unless you wanted to make a pool game, and you wanted to make it feel exactly like this one.
We had other things we wanted to do as well, like switching out the ball skins on the fly, and little lighting things (note that all the lighting and shadows is not 3d.. it is a 2d effect, control over the edge aliasing.. the list goes on)
so, it is not that ball physics are the hardest thing in the world to do.. but getting exactly what we wanted, with control over the tweaking was something that required a custom solution.
we could have worked to do this in TGB, and we could have used what was in there, but we were pushing hard to make this the best game we could make, and the path of least resistance was to roll our own.
At some point, all developers have to make the decision about how to complete their project. The decision was made to roll our own, and for several reasons. The specific requirments of our game defined the need for us, and if released, it would not perform well other than the application of a pool type game.
If released, I can imagine the complaints that would come about when people tried to repurpose them for something else and have them not work as they desire.
As for the things not specific to this game that have made it back into the engine.. no sense asking when they will be released, as most are already there. Justin DuJardin worked on pool before taking lead on TGB, and his experience and specfic fixes for pool made it back into the engine a LONG time ago.
As for adding a resource about how to do this, that is already on the list of things the docs and demos team has to work on.. but it is not the highest priority item on the list at this moment.
10/02/2006 (2:33 pm)
Quote:but we are talking pool here, it's got to be the easiest physics simulation there is
not quite.
When this was mocked up, it was basically the old pool demo that was playable when t2d first came out. the basic implementation was done in t2d.. WAY back in the day.
after a while, the physics did not do what we wanted them to do, and did not offere the control that I wanted over the feel.
What we wanted was to have control over the speed of the balls, topspin and sidespin and how they interact with rails, and with other balls, and how they transfer spin in all these conditions. We separated all of these out into seperate components. In a simple sense, balls rolling and colliding is not hard..but with felt friction and bumper and ball resitution and spin transfer and separating the draw/follow from the side spin... it is actually very specific and not straightforward.
having been the one that did the physics tweaking, my opinion is that this functionality would not be a good candidate for a general purpose solution, unless you wanted to make a pool game, and you wanted to make it feel exactly like this one.
We had other things we wanted to do as well, like switching out the ball skins on the fly, and little lighting things (note that all the lighting and shadows is not 3d.. it is a 2d effect, control over the edge aliasing.. the list goes on)
so, it is not that ball physics are the hardest thing in the world to do.. but getting exactly what we wanted, with control over the tweaking was something that required a custom solution.
we could have worked to do this in TGB, and we could have used what was in there, but we were pushing hard to make this the best game we could make, and the path of least resistance was to roll our own.
At some point, all developers have to make the decision about how to complete their project. The decision was made to roll our own, and for several reasons. The specific requirments of our game defined the need for us, and if released, it would not perform well other than the application of a pool type game.
If released, I can imagine the complaints that would come about when people tried to repurpose them for something else and have them not work as they desire.
As for the things not specific to this game that have made it back into the engine.. no sense asking when they will be released, as most are already there. Justin DuJardin worked on pool before taking lead on TGB, and his experience and specfic fixes for pool made it back into the engine a LONG time ago.
As for adding a resource about how to do this, that is already on the list of things the docs and demos team has to work on.. but it is not the highest priority item on the list at this moment.
#11
10/02/2006 (2:35 pm)
Wow Pat that was quick, you edit that right out. I am not say I dont like GG or TGB or any of the engine I do like them and GG, If not we would not be spend our money here. Somethings TGB should be able to do and throw things out it general engine is not helping. I like TGB and think GG did outstanding job with it. I have only play with it so far I am wait for some fixs to come threw than I am moving over to it but until then stay with the engine I am currently using now.
#12
I don't think we are splitting hairs. You could write tons of C++ code for a TGB game in order to do physics, ai and anything else without that indicating any problems at all with the TGB core.
How much code goes into a game is not really a good indication of how well the engine it's based on handles, it's how "easy" the core deals with having code added on. With "easy" been a fairly relative term. The devs that worked on this game will now have a firm understanding of any areas that TGB may have been lacking, I'm not saying there are any, but if there are, they'll have a good idea where those problems are. That understanding is bound to find it's way back to the community in the form of changes/updates to TGB.
I doubt the level editors sprang up out of thin air, but rather came about due to GG working with the engine themselves and realising a way to improve things. I'm speculating of course, it may have been a brainstorm, who knows :) We may not have seen the code GG were working on which led to that improve but we still reaped the benefits in other ways.
There is no need for GG to give out the physics code for this game, I can understand people wanting to see it, I'd like to see the code in many games, but I don't understand why you feel we "need" it or have a right to it. We'd benefit more from advice/articles on how to extend TGB rather than any form of code dump imo.
10/02/2006 (2:48 pm)
Quote:@Gary I agree, but we're splitting hairs here. I said "tons of C++" and you said "easily extend", so we're talking about the same thing here.
I don't think we are splitting hairs. You could write tons of C++ code for a TGB game in order to do physics, ai and anything else without that indicating any problems at all with the TGB core.
How much code goes into a game is not really a good indication of how well the engine it's based on handles, it's how "easy" the core deals with having code added on. With "easy" been a fairly relative term. The devs that worked on this game will now have a firm understanding of any areas that TGB may have been lacking, I'm not saying there are any, but if there are, they'll have a good idea where those problems are. That understanding is bound to find it's way back to the community in the form of changes/updates to TGB.
I doubt the level editors sprang up out of thin air, but rather came about due to GG working with the engine themselves and realising a way to improve things. I'm speculating of course, it may have been a brainstorm, who knows :) We may not have seen the code GG were working on which led to that improve but we still reaped the benefits in other ways.
There is no need for GG to give out the physics code for this game, I can understand people wanting to see it, I'd like to see the code in many games, but I don't understand why you feel we "need" it or have a right to it. We'd benefit more from advice/articles on how to extend TGB rather than any form of code dump imo.
#13
Like I said, this game would not have been possible without TGB in the time frame that we did it. We are making more commercial games and we are starting with TGB and TSE. You guys can choose to make games, too.
Our game engines come with C++ source, and we expect people to use it. You can learn a lot about game development and even make complete games without the source code using the binary version of TGB (for instance Puzzle Poker only had a very minor, non-essential C++ change). We have included a source code option for professionals so you don't have to beg us for every change that you think should go into the engine. You can choose to code your own "barrier to entry" for your game. You can add your own value to the engine so that others do not have complete access to every feature you do.
Any of you can choose to do this. We cannot make your games for you and we cannot debate every issue that comes up. Our engines can help you achieve your goals of bringing games to market. I know I am going to keep making games, and my games will start on GG engines. As a game maker, I face the exact same set of problems you do, and I can tell you there is no better choice for your dvelopment. This can sound like a load of crap coming from a GG founder, but I can tell you that once I put my game producer hat on, if the engine is getting in the way, I would not use it.
-Jeff Tunnell, GG
10/02/2006 (2:49 pm)
I think we have a major disconnect about what a game engine should be capable of. If you think a pool game written in Game Maker is viable for the commercial market, then you should be submitting that game to the portals. Sounds like an easy way to make money:)Like I said, this game would not have been possible without TGB in the time frame that we did it. We are making more commercial games and we are starting with TGB and TSE. You guys can choose to make games, too.
Our game engines come with C++ source, and we expect people to use it. You can learn a lot about game development and even make complete games without the source code using the binary version of TGB (for instance Puzzle Poker only had a very minor, non-essential C++ change). We have included a source code option for professionals so you don't have to beg us for every change that you think should go into the engine. You can choose to code your own "barrier to entry" for your game. You can add your own value to the engine so that others do not have complete access to every feature you do.
Any of you can choose to do this. We cannot make your games for you and we cannot debate every issue that comes up. Our engines can help you achieve your goals of bringing games to market. I know I am going to keep making games, and my games will start on GG engines. As a game maker, I face the exact same set of problems you do, and I can tell you there is no better choice for your dvelopment. This can sound like a load of crap coming from a GG founder, but I can tell you that once I put my game producer hat on, if the engine is getting in the way, I would not use it.
-Jeff Tunnell, GG
#14
that is what I am endevouring to do with the docs and demos team. We are making demos that we intend to be good examples for people to pick apart, and offer up specific examples of how to solve certain problems.
My goal is to provide all the things someone one need to create an implementation of something, but I am trying to stop short of actually having the team provide 'implementations'. This is often not possible to totally divorce the tool from an implementation, but that is the goal.
10/02/2006 (2:53 pm)
@Gary, that is what I am endevouring to do with the docs and demos team. We are making demos that we intend to be good examples for people to pick apart, and offer up specific examples of how to solve certain problems.
My goal is to provide all the things someone one need to create an implementation of something, but I am trying to stop short of actually having the team provide 'implementations'. This is often not possible to totally divorce the tool from an implementation, but that is the goal.
#15
10/02/2006 (2:58 pm)
FYI: Robert is an unstoppable coding machine. Just don't ask him to peal fruit. 
#16
I definitely wouldn't want the extra code on this game rolled into TGB. No way. I've used TGB for a couple of professional games now and I like how non game type specific it is. I might as well code my own 2D game engine if TGB is going to start getting too specific. Like Ben Garney said above... do we want another TGE that is completely designed to be an optimized multiplayer first person shooter game. No. I don't. That's one of the best things about TGB in my opinion. It's a tool for arcade games of all types.
Damn I love this pool game!! My favorite game to play in a long time.
10/02/2006 (3:04 pm)
I love this game. It's really captured the feeling off being able to play that relaxing or challenging game of pool whenever I want without having to go to the pool hall. I really love pool but I never get to play. I grew up with a pool table at home but there's no room in our apartment. :(I definitely wouldn't want the extra code on this game rolled into TGB. No way. I've used TGB for a couple of professional games now and I like how non game type specific it is. I might as well code my own 2D game engine if TGB is going to start getting too specific. Like Ben Garney said above... do we want another TGE that is completely designed to be an optimized multiplayer first person shooter game. No. I don't. That's one of the best things about TGB in my opinion. It's a tool for arcade games of all types.
Damn I love this pool game!! My favorite game to play in a long time.
#17
Pool physics are not two dimensional...they are three dimensional. One of the most fundamental aspects of pool table physics is the effect of gravity pushing the ball against the table (in addition to rotational and translational frictions, from sliding to static and many points in between), and some very subtle but extremely complex interactions between the angle of the pool cue, the force impulse of the cue hitting the ball, and most importantly the ball striking the table, causing extensive third dimension physics effects. There are even aerodynamic physics involved in a real pool game, from boundary layer penetration to impact compression effects as the ball skips over the table on a hard shot (which causes the ball to bounce on and off the felt repeatedly in an extremely subtle manner).
Torque Game Builder's physics engine is a two dimensional physics engine. It's one of the most advanced two dimensional engines available, especially for the price point--including swept poly collision implementation that is amazingly fast and efficient.
As a two dimensional physics simulation however, it's not going to implement a third dimension for you out of the box....and as a two dimension focused product, Torque Game Builder isn't going to include a three dimensional physics implementation. It is however going to allow you to easily integrate your own (possibly extremely difficult and complex) physics simulation for your own projects in a highly efficient manner with a Torque Game Builder Pro (source code) license...and it will let you create a vast variety of true two dimensionally designed games very quickly.
10/02/2006 (3:16 pm)
I've been dealing with the whole "TGB should do pool physics!" request for more than a year now, and the one thing that I point out every single time, and that no one ever seems to get:Pool physics are not two dimensional...they are three dimensional. One of the most fundamental aspects of pool table physics is the effect of gravity pushing the ball against the table (in addition to rotational and translational frictions, from sliding to static and many points in between), and some very subtle but extremely complex interactions between the angle of the pool cue, the force impulse of the cue hitting the ball, and most importantly the ball striking the table, causing extensive third dimension physics effects. There are even aerodynamic physics involved in a real pool game, from boundary layer penetration to impact compression effects as the ball skips over the table on a hard shot (which causes the ball to bounce on and off the felt repeatedly in an extremely subtle manner).
Torque Game Builder's physics engine is a two dimensional physics engine. It's one of the most advanced two dimensional engines available, especially for the price point--including swept poly collision implementation that is amazingly fast and efficient.
As a two dimensional physics simulation however, it's not going to implement a third dimension for you out of the box....and as a two dimension focused product, Torque Game Builder isn't going to include a three dimensional physics implementation. It is however going to allow you to easily integrate your own (possibly extremely difficult and complex) physics simulation for your own projects in a highly efficient manner with a Torque Game Builder Pro (source code) license...and it will let you create a vast variety of true two dimensionally designed games very quickly.
#18
c++ Source code is provided as part of your license, why would you not utilize that if necissary?
10/02/2006 (4:34 pm)
What is the big deal?c++ Source code is provided as part of your license, why would you not utilize that if necissary?
#19
10/02/2006 (5:00 pm)
Love the progression screenies Robert, thanks for shareing them. I really like seeing the design process in action and nothing shows that like a nice set of images showing their progression. 
#20
10/02/2006 (5:19 pm)
I played the demo until my fingers were blue, and i loved it! The only physics problem i had were on break... i could never get a good break, but the AI could... go figure. 
Torque Owner Jeremy Alessi