====== Success Story: Pet Tomato, Inc. ======

We just finished our first client project using [[mtasc:|MTASC]] and I thought 
that some newcomers might be interested to hear our thoughts and opinions.

Edit: I've removed the broken link to the game, as it's no longer live. Here is an example of a more recent game that we've made using mtasc: [[http://www.cartoonnetwork.com/games/action/reanimated/fittobepied/index.html|Click here.]]

Please note that all the media was still made and incorporated using MMC. We 
would simply compose a swf of assets and use [[mtasc:|MTASC]] to inject the code.

Basically, our opinion is highly favorable. Now that I have been using [[mtasc:|MTASC]], 
I don't think I could go back to MMC. 

===== About Us =====
We've been making games with Flash for the past 6 years. I have been the main 
coder on about 8 games, and the usual development cycle is 1-3 months.

===== Benefits from using MTASC =====

==== Ability to integrate into your coding environment ====

I use [[http://www.gnu.org/software/emacs/emacs.html|Emacs]] to edit code. I was able to map F4 to run a build script, which included [[mtasc:|MTASC]]. 
Likewise, I pulled [[mtasc:|MTASC]] error messages, and all of my trace output back into an 
Emacs buffer. This is an enormous gain over switching back and forth to the Flash 
IDE, exporting, using the Flash output window, etc.

==== Better error messages ==== 

Getting the exact line and column number of an error is tremendous. I coded [[http://www.gnu.org/software/emacs/emacs.html|Emacs]] 
to open the correct file and highlight the characters where the error occurred. 
Not only is this a bit of time-saver, but I believe the bigger issue is that it 
prevents programmer fatigue and a break in concentration.

==== Quicker code - test - debug round-trips ==== 

Based on my setup described in the preceding comments, it was lightning quick to 
compile, find an error, and compile again. An average case might take all of 5 
seconds.

==== Separation of code and assets ==== 

One of the biggest pains about using the Flash IDE is that it has to compress all 
of your sound files and bitmaps every single time you want to export. At the end of 
a large project, this can take a minute or more. It becomes very painful when you 
are trying to fix small bugs at the end. Using [[mtasc:|MTASC]], we only had to export the 
assets about one time for every 50 that we made code changes. Compiling the code 
with [[mtasc:|MTASC]] usually took about 1 second.

==== Ability to integrate into a build process ==== 

I'm not aware of any decent way to do this with the Flash IDE. With [[mtasc:|MTASC]], we were 
able to include compilation in a larger build script that included a [[http://gcc.gnu.org/onlinedocs/cpp/|preprocessor]], 
and uploading the project to a remote server. The whole process was mapped to a 
single key on the keyboard. (I definately recommend trying a [[http://gcc.gnu.org/onlinedocs/cpp/|preprocessor]] if you 
haven't. I wouldn't give that up even if I had to use the Flash IDE.)

==== Linux ==== 

We were able to do 100% of the coding on [[http://www.gnu.org/|GNU]]/[[http://www.gentoo.org/|Gentoo Linux]], which is our preferred OS. 
Alternatively, we had [[mtasc:|MTASC]] running on our PC, too, in case we wanted to compile on 
the same machine that was running the Flash IDE.

===== Mailing List =====

Finally, one thing that I learned pretty quickly, if you want to develop with [[mtasc:|MTASC]], 
then you have to [[http://lists.motion-twin.com/mailman/listinfo/mtasc|join the mailing list]]. [[mtasc:|MTASC]] is being very actively developed and you have to watch the list for changes and bug-fixes. There are still some minor bugs being 
worked out in [[mtasc:|MTASC]] (although, they are usually fixed with 24 hours of being reported!), 
but in my experience the net gains of using [[mtasc:|MTASC]] far outweighed any problems that we had.

I'm sure there are other great things that I forgot, too. I'll add them as I remember.

-austin

Austin Haas\\
Pet Tomato, Inc.\\
http://www.pettomato.com