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
#22
10/02/2006 (7:38 pm)
Very interesting read. I will definately check this game out!
#23
10/02/2006 (8:10 pm)
This is definitely a polished, great looking game with good physics. I understand garagegames develops their own games and wouldn't expect the custom code to be supplied to us, however, in this case a billiards game was advertised as a demo that was to be released as part of TGB. You can't imagine how many times I kept checking back for that billiards demo to be released - and now it never will! I guess I'll have to come up with my own solution now. The question is, *could* a top-down ball game even be developed with Torquescript only? Is it just easier, or necessary, to do it in C++? I was interested in making a Zuma-like game and was looking forward to some ball examples - like how you got the image on the ball to roll with it...
#24
Bravo, billiards team. :)
10/02/2006 (8:42 pm)
Robert. Excellent job on the screens. I always enjoy seeing process for any given project, and this satiated my seeing-progress-lust. Its a nice way to cap a project; taking the time to see where you started and followibg the run on sentence of development to the huge exclamation point at the end. Bravo, billiards team. :)
#25
As far as the simulation is concerned I thought about how complex you might have taken it (I assumed you went into full 3D immediately after playing it). I actually wouldn't assume you would include that with TGB, but I would expect that I could make a good 2D pool game with the tool by hacking in some values to simulate the 3D effects. For example normal force * felt friction * angular velocity can easily be hacked as a 2D vector opposite the velocity. I suppose that's not the best way to handle it ... maybe you tried it and it just didn't feel right or maybe you guys just had the ability and so you took it to another level.
Anyway, I'm pretty confident someone could do a pool simulation with TGB without going into the depth that was utilized here. Sorry to come off offensively. I'm using the Torque platform for a reason, because it actually does yield you the greatest opportunity for success both technically and financially.
10/02/2006 (9:30 pm)
I sent some thoughts to Jeff ... As far as the simulation is concerned I thought about how complex you might have taken it (I assumed you went into full 3D immediately after playing it). I actually wouldn't assume you would include that with TGB, but I would expect that I could make a good 2D pool game with the tool by hacking in some values to simulate the 3D effects. For example normal force * felt friction * angular velocity can easily be hacked as a 2D vector opposite the velocity. I suppose that's not the best way to handle it ... maybe you tried it and it just didn't feel right or maybe you guys just had the ability and so you took it to another level.
Anyway, I'm pretty confident someone could do a pool simulation with TGB without going into the depth that was utilized here. Sorry to come off offensively. I'm using the Torque platform for a reason, because it actually does yield you the greatest opportunity for success both technically and financially.
#26
But the advantage of TGB (Pro at least) is that you don't have to do it in script.
10/03/2006 (12:25 am)
@Steve: Top down pool games have been written in other scripting languages in engines that have no built in physics or collision detection. All of it done it script. Personally, I don't see why someone couldn't do the same in TorqueScript. It wouldn't be the most advanced or best performing ball physics in the world, but it likely could be done. But the advantage of TGB (Pro at least) is that you don't have to do it in script.
#27
The first one to make a simple pool game tutorial would get a lot of indie street cred... stop bitching and take the initiative people!
"World Domination Through Collaboration!"
10/03/2006 (1:00 am)
@GG - This game is addicting... i must put it down and get back to work!The first one to make a simple pool game tutorial would get a lot of indie street cred... stop bitching and take the initiative people!
"World Domination Through Collaboration!"
#28
Full top follow (english), straight on the headspot (don't even move the cue ball), drive it right into the rack. Works even better in the 9 ball rack!
Absolutely you could mimic some basic pool physics in this manner, and there isn't anything stopping you. At a certain point however, you start fighting your built in physics engine, instead of leveraging it...and as in any game, that's when you move to custom code. That's what GG did with Rack 'em Up, and it's honestly exactly what we expect our customers that want full control over the presentation of their game to do as well--it's why source code has always been an important part of the GG offerings, and why there is a TGB Pro licensing option.
I don't think I'm revealing any company secrets here...one of the initial design concepts that was prototyped out of the game was having a t2dSceneObject as the "ball", and mounting a t2dShape3d dts ball to it, with animated rolling action. Now, obviously when you think that through, it's both relatively hard to make a really nice sphere with dts, and thinking it even further, there actually isn't any "animation" to a rolling ball...so that solution was removed in favor of custom rendering code, which turned out if I understand it correctly to be somewhat similar to what we did with the marbles in MBU (I wasn't on the dev team for either game, so I'm not 100% sure on that).
10/03/2006 (2:02 am)
Quote:
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.
Full top follow (english), straight on the headspot (don't even move the cue ball), drive it right into the rack. Works even better in the 9 ball rack!
Quote:
For example normal force * felt friction * angular velocity can easily be hacked as a 2D vector opposite the velocity
Absolutely you could mimic some basic pool physics in this manner, and there isn't anything stopping you. At a certain point however, you start fighting your built in physics engine, instead of leveraging it...and as in any game, that's when you move to custom code. That's what GG did with Rack 'em Up, and it's honestly exactly what we expect our customers that want full control over the presentation of their game to do as well--it's why source code has always been an important part of the GG offerings, and why there is a TGB Pro licensing option.
Quote:
was looking forward to some ball examples - like how you got the image on the ball to roll with it...
I don't think I'm revealing any company secrets here...one of the initial design concepts that was prototyped out of the game was having a t2dSceneObject as the "ball", and mounting a t2dShape3d dts ball to it, with animated rolling action. Now, obviously when you think that through, it's both relatively hard to make a really nice sphere with dts, and thinking it even further, there actually isn't any "animation" to a rolling ball...so that solution was removed in favor of custom rendering code, which turned out if I understand it correctly to be somewhat similar to what we did with the marbles in MBU (I wasn't on the dev team for either game, so I'm not 100% sure on that).
#29
On the physics debate, i think gg should take a hint, sounds like a potentially profitable product opportunity to me. ;0)
-- New Release Torque Game Builder: Pool Physics pack SRP ---
Other then that, i'd say don't be afraid of C++, it's a very handy language to know, and learning torquescript is good baby steps towards engine code hacking (not talking from experience, i've yet to have to modify the engine)
If you don't want to play with C++, work with the engines strengths, not focus on it's weaknesses and constantly wait for gg to add stuff to it for that 'daddy project'. Think along the lines of projects that would be fun to make, yet resonably easy/achievable to do in TGB's current state.
10/03/2006 (5:32 am)
Great stuff, love the look of the game. On the physics debate, i think gg should take a hint, sounds like a potentially profitable product opportunity to me. ;0)
-- New Release Torque Game Builder: Pool Physics pack SRP ---
Other then that, i'd say don't be afraid of C++, it's a very handy language to know, and learning torquescript is good baby steps towards engine code hacking (not talking from experience, i've yet to have to modify the engine)
If you don't want to play with C++, work with the engines strengths, not focus on it's weaknesses and constantly wait for gg to add stuff to it for that 'daddy project'. Think along the lines of projects that would be fun to make, yet resonably easy/achievable to do in TGB's current state.
#30
@Jeremy,
what we have is something inbetween. They are not 'realistic' physics in that they do not accurately do all the things that one one expect of a pool ball in the real world. The are insanely tweakable, meaning that the top spin and side spin can be tweaked separately, and ball to ball spin transfer can be controlled separately, as can bumper restitution and felt friction effects (controlled through simple falloffs).
the tweaking of the physics took a long time to get right, and judging by the positive reactions of some of the comments here, the effort we put in was not in vain.
Those who work with me know that I am sometimes an obsessive tweaker of values, and that I often make requests for control over certain things in certain ways.
both the physics and the AI required a lot of 'tweakable' values that I could control easily. As a designer, I need this sort of control to fine tune the game to a level where the experience in game becomes seamless.
I suppose some of this is seat of the pants 'feel' designing.. but the process for getting this sort of control is not seat of the pants. The team would sit down and I would talk about what kind of control I wanted and why I wanted that control.
I am positive that one could write a pool simulation that did not go to the depth we went to. Having played a TON of pool games while researching the design, I am also confident that all pool simulations are not created equal.
I was provided with the tweaking power I wanted. The goal of the team was to give me the control I thought we needed over the physics. note that my goal was not 'realistic' physics, but physics that felt like what the end users expectations of what a pool game should feel like.
there are instances all over the scripts of 'tweakables' that I requested to adjust the timing of button speeds, blink speeds, how fast or slow something animates.. out of context, someone looking at the scripts would not be able to max sense of some of the 'why' things were set up like they were.
it is difficult, as the contextual headspace of the problem needing solving and the team solving it sometimes leads to implementations that, taken out of context, can seem strange.
looking at some of the 'physics' settings in dRacer would probably produce similar confusion.. rotational interia falloff? rotationial interia delay?
for me, I try not to get wrapped up in the technology and instead look to the results.. what is the end user experiencing while playing the game? what sort of control do I want over that experience? what needs to be created to offer me that control?
the implementations may well be specific to my style, which is.. I really don't care what is going on under the hood in terms of how we get the end result, as long as it gets me what I want and I am able to have the control to fine tune it. Having done now a fair share of tweaking to get things feeling 'right', I am not a fan of realism, as I have learned that tweaking the camera FOV can have disasterous (or fortunate) implications when it comes to the end users perception of what is going on.
realistic physics in dRacer would not be something that would be all that much fun. Those that play dRacer say that it feels great. The speedometer says you are going 150.. the actual speed of the cars is well over 300mph, and the tire grip is more like crazy glue than rubber. From a realistic sense, the values are all out of whack.. from a end user experience perspective, it feels good.
I keep my focus on what ends up on the screen, and what the end user experiences. The implementations are a means to that end. Out of context, the implementations, when picked apart can seem like horrible hacks.. and this is an ongoing issue that I am having to sort out while working on TGB demos and docs.. how to contextualize design decisions so that they make sense to the end user.
I am being careful that I don't make too many assumptions about how people design games and I try to keep in check my feelings about the 'right' way to do it. I have my way, and it is but one way of addressing the myriad of design issues that arise during the creation of a game.
on the custom 3d balls.. the balls are just animated rolling spheres.. they track the movement of the collision objects and 'roll' to match. These were done in code as having tons of 3d texture mapped balls was a resource hog. The balls were all mapped with a very simple planar projection on both sides, and have custom edge transparency relative to the camera to reduce aliasing. the shadows, shading, and reflection effects are all 2d sprites. the decision to do 3d balls was entirely a memory and download size decision.. that many sprites for all the balls in all their rotations would have been huge (note that one can change skins on the fly once they are unlocked)..
regardless, TGB, for the most part, did what it needed, which was stay out of the way, do what it needed to do so we could focus on the issues particular to this game.
10/03/2006 (7:49 am)
Quote:As far as the simulation is concerned I thought about how complex you might have taken it (I assumed you went into full 3D immediately after playing it). I actually wouldn't assume you would include that with TGB, but I would expect that I could make a good 2D pool game with the tool by hacking in some values to simulate the 3D effects. For example normal force * felt friction * angular velocity can easily be hacked as a 2D vector opposite the velocity. I suppose that's not the best way to handle it ... maybe you tried it and it just didn't feel right or maybe you guys just had the ability and so you took it to another level.
Anyway, I'm pretty confident someone could do a pool simulation with TGB without going into the depth that was utilized here.
@Jeremy,
what we have is something inbetween. They are not 'realistic' physics in that they do not accurately do all the things that one one expect of a pool ball in the real world. The are insanely tweakable, meaning that the top spin and side spin can be tweaked separately, and ball to ball spin transfer can be controlled separately, as can bumper restitution and felt friction effects (controlled through simple falloffs).
the tweaking of the physics took a long time to get right, and judging by the positive reactions of some of the comments here, the effort we put in was not in vain.
Those who work with me know that I am sometimes an obsessive tweaker of values, and that I often make requests for control over certain things in certain ways.
both the physics and the AI required a lot of 'tweakable' values that I could control easily. As a designer, I need this sort of control to fine tune the game to a level where the experience in game becomes seamless.
I suppose some of this is seat of the pants 'feel' designing.. but the process for getting this sort of control is not seat of the pants. The team would sit down and I would talk about what kind of control I wanted and why I wanted that control.
I am positive that one could write a pool simulation that did not go to the depth we went to. Having played a TON of pool games while researching the design, I am also confident that all pool simulations are not created equal.
I was provided with the tweaking power I wanted. The goal of the team was to give me the control I thought we needed over the physics. note that my goal was not 'realistic' physics, but physics that felt like what the end users expectations of what a pool game should feel like.
there are instances all over the scripts of 'tweakables' that I requested to adjust the timing of button speeds, blink speeds, how fast or slow something animates.. out of context, someone looking at the scripts would not be able to max sense of some of the 'why' things were set up like they were.
it is difficult, as the contextual headspace of the problem needing solving and the team solving it sometimes leads to implementations that, taken out of context, can seem strange.
looking at some of the 'physics' settings in dRacer would probably produce similar confusion.. rotational interia falloff? rotationial interia delay?
for me, I try not to get wrapped up in the technology and instead look to the results.. what is the end user experiencing while playing the game? what sort of control do I want over that experience? what needs to be created to offer me that control?
the implementations may well be specific to my style, which is.. I really don't care what is going on under the hood in terms of how we get the end result, as long as it gets me what I want and I am able to have the control to fine tune it. Having done now a fair share of tweaking to get things feeling 'right', I am not a fan of realism, as I have learned that tweaking the camera FOV can have disasterous (or fortunate) implications when it comes to the end users perception of what is going on.
realistic physics in dRacer would not be something that would be all that much fun. Those that play dRacer say that it feels great. The speedometer says you are going 150.. the actual speed of the cars is well over 300mph, and the tire grip is more like crazy glue than rubber. From a realistic sense, the values are all out of whack.. from a end user experience perspective, it feels good.
I keep my focus on what ends up on the screen, and what the end user experiences. The implementations are a means to that end. Out of context, the implementations, when picked apart can seem like horrible hacks.. and this is an ongoing issue that I am having to sort out while working on TGB demos and docs.. how to contextualize design decisions so that they make sense to the end user.
I am being careful that I don't make too many assumptions about how people design games and I try to keep in check my feelings about the 'right' way to do it. I have my way, and it is but one way of addressing the myriad of design issues that arise during the creation of a game.
on the custom 3d balls.. the balls are just animated rolling spheres.. they track the movement of the collision objects and 'roll' to match. These were done in code as having tons of 3d texture mapped balls was a resource hog. The balls were all mapped with a very simple planar projection on both sides, and have custom edge transparency relative to the camera to reduce aliasing. the shadows, shading, and reflection effects are all 2d sprites. the decision to do 3d balls was entirely a memory and download size decision.. that many sprites for all the balls in all their rotations would have been huge (note that one can change skins on the fly once they are unlocked)..
regardless, TGB, for the most part, did what it needed, which was stay out of the way, do what it needed to do so we could focus on the issues particular to this game.
#31
I do very much the same thing with my value tweaking. The smallest change in the numbers can mean a huge difference to the end user. Rack 'Em Up definitely feels good, as I said I could tell immediately the 'love' that was put into it. A lot of the extras that were done sound really slick.
10/03/2006 (9:44 am)
@JoeI do very much the same thing with my value tweaking. The smallest change in the numbers can mean a huge difference to the end user. Rack 'Em Up definitely feels good, as I said I could tell immediately the 'love' that was put into it. A lot of the extras that were done sound really slick.
#32
Nothing should stop someone who really wants to make game. I'll bet that most game programmers would not say they love programming for programming's sake but they love deveoping games. Getting good a programming was simply a by product of wanting to develop games.
On the other side of the fence however who here can say "Torque Physics Kit? Guess it's time to whip out my credit card...... again".
10/04/2006 (2:48 am)
I don't see why GG would be obligued to give or reintigrate their customised code, the question is why don't you try to make one yourself. You would find out, it's not really that easy and you'd learn alot more on a personal level than having it handed to you on a silver platter.Nothing should stop someone who really wants to make game. I'll bet that most game programmers would not say they love programming for programming's sake but they love deveoping games. Getting good a programming was simply a by product of wanting to develop games.
On the other side of the fence however who here can say "Torque Physics Kit? Guess it's time to whip out my credit card...... again".
#33
10/06/2006 (7:24 pm)
It boils down to this simple fact. GG took TGB and made a really kick ass game out of it (yes I bought it imediately and have wore my mouse out). The tools are there for anyone to make a cool game and GG has proven it. You have eaten the dog food and survived. S!
#34
10/20/2006 (10:52 am)
Needs more jetpack ;) 
Torque Owner wingman
@Robert: I got it! You are xgalaxy on tribalwar arent ya? I worked with the Legends dev team for a bit and have been an avid Tribes (one) player since release in '98. Well, now I know your GG<->Tribalwar identities, but my GG<->Tribalwar identities are still seperate, muhaha.
*Hint: vet5, starts with an "e".