jesterxl at jessewarden.com
Fri Sep 30 19:28:48 CEST 2005
Awesome music! I broke my desk I got so excited, but it was worth it.
----- Original Message -----
From: "Austin Haas" <austin at pettomato.com>
To: "MotionTwin ActionScript2 Compiler List" <mtasc at lists.motion-twin.com>
Sent: Friday, September 30, 2005 12:59 PM
Subject: [mtasc] testimonial
We just finished our first client project using MTASC and I thought that
some newcomers might be interested to hear our thoughts and opinions.
The finished project can be seen here: http://pettomato.com/CN/transformers/
Please note that all the media was still made and incorporated using
MMC. We would simply compose a swf of assets and use MTASC to inject the
We've been making games with Flash for the past 6 years. I have been the
main coder on about 8, and the usual development cycle is 1-3 months.
Basically, our opinion is highly favorable. Now that I have been using
MTASC, I don't think I could go back to MMC. Here is a list of the major
strengths that I found:
* Ability to integrate into your coding environment *
I use Emacs. I was able to map F4 to run a build script, which included
MTASC. Likewise, I pulled 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 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
* 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, we only had to export the assets about one time
for every 50 that we made code changes. Compiling the code with 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, we were able to include compilation in a larger build script that
included a 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 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 Linux, which is our preferred
OS. Alternatively, we had MTASC running on our PC, too, in case we
wanted to compile on the same machine that was running the Flash IDE.
Finally, one thing that I learned pretty quickly, if you want to develop
with MTASC, then you have to join the mailing list. I guess I'm
preaching to the choir, but in case anyone is reading the archives...
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 (although, they are usually fixed with 24 hours of being
reported!), but in my experience the net gains of using 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.
Pet Tomato, Inc.
MTASC : no more coffee break while compiling
More information about the mtasc