Rack 'em Up Road Trip

Submit your own resources!

Jeremy Alessi   (Oct 02, 2006 at 20:06 GMT)   Resource Rating: 5

So are the ball physics then controlled via script? Anything you guys do to extend the C++ code should be included in TGB in my opinion otherwise it's not a case of "eat their own dog food" because you opened the fridge and got whatever you wanted. Sure there's the source version of TGB but come on, if you can't even do a pool simulation without changing the physics C++ side that's pretty sad. Mind you I'm not saying that all your algorithms should be laid out in the open, obviously a game you guys create has to have its nifty little 'how'd they do that' aspects but we are talking pool here, it's got to be the easiest physics simulation there is and core TGB should be capable of doing that with just some scripting involved. I don't see why it would need C++ side mods as I can think of script solutions right now but perhaps I'm wrong.

Robert Blanchet Jr.   (Oct 02, 2006 at 20:21 GMT)   Resource Rating: 5

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.

Jeff Tunnell   (Oct 02, 2006 at 20:39 GMT)

@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

Jeppie   (Oct 02, 2006 at 20:47 GMT)

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.
Edited on Oct 02, 2006 20:51 GMT

Fucifer   (Oct 02, 2006 at 21:02 GMT)

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.
Edited on Oct 02, 2006 21:05 GMT

Gary Preston   (Oct 02, 2006 at 21:11 GMT)

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 :)

Pat Wilson   (Oct 02, 2006 at 21:18 GMT)

---Edited by Jeff---
Edited on Oct 02, 2006 21:25 GMT

Jeppie   (Oct 02, 2006 at 21:27 GMT)

@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.

Ben Garney   (Oct 02, 2006 at 21:28 GMT)

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? :)

Joe Maruschak   (Oct 02, 2006 at 21:33 GMT)   Resource Rating: 5

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.

Fucifer   (Oct 02, 2006 at 21:35 GMT)

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.
Edited on Oct 02, 2006 21:38 GMT

Gary Preston   (Oct 02, 2006 at 21:48 GMT)

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.

Jeff Tunnell   (Oct 02, 2006 at 21:49 GMT)

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

Joe Maruschak   (Oct 02, 2006 at 21:53 GMT)   Resource Rating: 5

@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.

Mark McCoy   (Oct 02, 2006 at 21:58 GMT)

FYI: Robert is an unstoppable coding machine. Just don't ask him to peal fruit.

Anton Bursch   (Oct 02, 2006 at 22:04 GMT)

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.

Stephen Zepp   (Oct 02, 2006 at 22:16 GMT)

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.
Edited on Oct 02, 2006 22:27 GMT

AndrewOsborne   (Oct 02, 2006 at 23:34 GMT)

What is the big deal?

c++ Source code is provided as part of your license, why would you not utilize that if necissary?

Dan MacDonald   (Oct 03, 2006 at 00:00 GMT)

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.

Andrew Hull   (Oct 03, 2006 at 00:19 GMT)

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.

wingman   (Oct 03, 2006 at 00:34 GMT)

Awesome job on this game guys. Me, my wife, and my 11 year old son ALL love it.

@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".

Christopher McArthur   (Oct 03, 2006 at 02:38 GMT)   Resource Rating: 5

Very interesting read. I will definately check this game out!

Steve Miles   (Oct 03, 2006 at 03:10 GMT)

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...

Adam deGrandis   (Oct 03, 2006 at 03:42 GMT)

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. :)

Jeremy Alessi   (Oct 03, 2006 at 04:30 GMT)   Resource Rating: 5

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.

Mark McCoy   (Oct 03, 2006 at 07:25 GMT)

@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.

Tom Spilman   (Oct 03, 2006 at 08:00 GMT)

@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!"

Stephen Zepp   (Oct 03, 2006 at 09:02 GMT)

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).
Edited on Oct 03, 2006 09:07 GMT

Leroy Frederick   (Oct 03, 2006 at 12:32 GMT)   Resource Rating: 5

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.

Joe Maruschak   (Oct 03, 2006 at 14:49 GMT)   Resource Rating: 5

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.

Jeremy Alessi   (Oct 03, 2006 at 16:44 GMT)   Resource Rating: 5

@Joe

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.

Devon Ly   (Oct 04, 2006 at 09:48 GMT)

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".
Edited on Oct 04, 2006 23:35 GMT

Tank Dork   (Oct 07, 2006 at 02:24 GMT)

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!

Geoff \'Got Haggis?\' Rowland   (Oct 20, 2006 at 17:52 GMT)

Needs more jetpack ;)

You must be a member and be logged in to either append comments or rate this resource.

Home | Products | Solutions | Downloads | Support | Search | About Us
Copyright © GarageGames.com 2000 - 2008 All Rights Reserved