2010年07月06日

Flash8以降の「線の拡張機能」について

Flash8以降には「線の拡張機能」というのがあります。

通常のFlashオーサリング時に意識して使うような明示的な機能ではありません。
これを意識するのは、Illustratorからパスデータを読み込ませてムービープレビュー/パブリッシュするときに次のようなワーニングが出力されたときです。
このプレーヤーでは、線の拡張機能はサポートされていません

■「線の拡張機能」は明示的なメニューやコマンドではない

FlashIDE自体がバージョン8以降だと、この「線の拡張機能」を使ってオーサリング出来ます。
前述の通り、コマンドやメニューに明示されている機能ではありません。知らず知らずのうちに作業者はこの機能を使っています。

一方、出力するターゲットプレイヤーのバージョンがFlashLite1.1やFlash7以前だと、この「線の拡張機能」は使えません。

だから、気付かずにこの機能を使ったままパブリッシュした時に、「バージョンが古くて、この新しい機能は使えないけど大丈夫?」と注意されてしまうわけです。

この記事では、この「線の拡張機能」とは具体的にどういうものなのか、予想されるトラブルと解決方法を説明していきます。


>> 続きを読む

このエントリーをはてなブックマークに追加
posted by taichistereo at 10:55 | Comment(0) | Adobe Flash/action script

2009年10月28日

wonderflのBP貼ってみるテスト


このエントリーをはてなブックマークに追加
posted by taichistereo at 09:50 | Comment(0) | Adobe Flash/action script

2009年03月24日

「Amebaモバイル」のPC向けFLASHがよくできてる

ameba_cap.gif

図は、アメブロのモバイル版「amebaモバイル」の任意のURLにPCからアクセスすると、ケータイサイトだからケータイで見てね、と誘導するスプラッシュ(というか行き止まり)のFLASHが表示されます。

このFlashアニメーション、グラフィックデザイン的にとてもよくできていて、「おおっ」と感心しました。(それで誰かに教えたくなったのでこの記事に書いているという訳です。)


普通に考えれば、SEO的な観点から、Flashなんかではなくいろんなグループサイトへのリンクを盛り込んだXHTMLページを設置しておくべきところだと思われます。

しかしながらサイバーエージェントは、そういうシナジー状態を形成していた相互リンク網のページ作成(HTML記述)手法に関して、googleから「リンクファームだよね」と判断されて検索結果からハブられたことがありました。
そういうこともあって、Flashにしているのかもしれません。

あるいは、Googleのクローラーがアクセスすると普通にモバイル版の表示が返されているのかもしれません。


そんなせせこましいSEOの話はおいとくとして、このアニメーションはいいわ。
多分間違いなく、FLASHerがデザインからイラレで起こしてますよね。
イラレの時点から、きちんとした動きをビターッと頭の中に構成してから取り組んでいるのがよくわかります。ペンキが垂れてるような表現はFlash上で後付けしたのかな?なんて思えるところも、とても好感が持てます。
スクリプトを使ってないのはもちろんのこと、非常に省エネな作業でとてもよい成果物が出来ていると思います。

個人的にはモーションブラー表現みたいなのはなくてもいいかもなと思いましたが、ま、たぶん普通にやるとチラチラ汚く見えちゃうんでしょうね。

とてもよい。


■ この他のFlash関連TIPS

このエントリーをはてなブックマークに追加
posted by taichistereo at 18:13 | Comment(0) | Adobe Flash/action script

2009年03月05日

バイナリハック

今日は久しぶりに仕事でperlを書いた。やっぱり僕はperlという言語が好きになれない。

顧客に指定されたので仕方なくだ。

やったことは、perlによるバイナリレベルでのswf内部の変数上書き。こう書くと大層に見えるが、別にたいした芸当でもなかったりする。

でも微妙にマイナーなテクニックだしそのへんのFLASHerにはできねーことなので、むりやり難読化かけておいた。

意味ないかもしんないけどね。



rubyから入っちゃえばperlぎらいも直るかな?
このエントリーをはてなブックマークに追加
posted by taichistereo at 23:25 | Comment(0) | Adobe Flash/action script

2008年10月20日

変数名が中国語

fangbei =
とか。

trace(bei)
とか。

読めねーよ!

他にも
default_***とかいうメソッド(モードとかシーンらしい)があったかと思えば
defaylt_***とかもいろんなとこにあって、
バグなしで動いてやがる。

なんなんだこれは!

前も同じ中国人PGの書いたプログラムの改修でひどい目に合ったんだよね。。。

sorceっていうインスタンスがあるんだけど、どうみても得点を扱ってます。
scoreと書きたかったんですね、わかります。
でも数十カ所もよく間違え続けられるなぁ。。。
中国の人って一般的に英語がものすごい苦手だったりするんだろうか?


おまけに、パブリッシュ後のバイナリ容量にも十分余裕があるのにコメントがほとんどなくって、たまに見つけたと思ったら完全に常用外漢字。

海外の翻訳サイトで英語に翻訳してもよくわからなかったけど、
せっかくなので全部英語にしといた。

これからは自分もコメント極力英語にしよう。。。

基本日本語は使わないようにしてるけど、
うまい英文にならなそうなときは「ないより全然マシ」なので日本語でコメント書いてました。

グローバルな時代だから、中国のひとを攻める前に
自分たちから率先して日本語やめていこう。
このエントリーをはてなブックマークに追加
posted by taichistereo at 19:47 | Comment(0) | Adobe Flash/action script

2008年05月06日

ケータイFlashコンテンツの容量を激減させるチェックリスト

本エントリを加筆・訂正した記事が、Adobe デベロッパーコネクションで公開されています。
よりわかりやすく正確な内容になっていますので、是非ご覧下さい。

デベロッパーセンター|Flash Lite 作業効率化&ファイル容量軽量化テクニック
http://www.adobe.com/jp/devnet/flash/articles/flashlite_koekatamarin_tips.html
(2010年5月7日公開)


自慢じゃないが、ケータイ向けFlashコンテンツにだいぶ自信がついてきたぞ。

swfの容量を100KBにおさえる工夫がかなり板についてきて、
「よくこれが100KBにおさまったなぁ!」と我ながら感心してしまう。

いくつかTipsを。

パブリッシュ時にサイズレポートを吐き出しておいて、それをブラウザで読み込んでおいてF5でリロードすると便利です。

イラレのデータは一度Fireworksで読み込んでからFlashに貼付けると
Flash liteでサポートされていない線の拡張機能をすべて解除してくれます。

Fireworksからのデータはぜんぶ「そざい.fla」とかに読み込んでおくと
ウィンドウの切り替えがラク。


以下、思い出しながら、容量を軽くするためのポイントを書いておきます。


■ ライブラリにあってステージに配置していないインスタンスはパブリッシュ時に使用されない

常識ですが、ステージにおいてない限り
ライブラリのインスタンスはパブリッシュ後の容量に影響しません。
これがすべての基本、と言える、かな?


■ オブジェクトをインスタンス化してひたすら再利用

できるだけオブジェクトを共通化していくことで劇的に容量は減っていきます。
特に、どんな細かな共通部分も見逃さず、どんどんシンボルをネストしていくことを恐れないのがポイント。
ただし単純な円や長方形などのシェイプ一個とかの場合はインスタンス化することでかえって重くなるので、あまりにもミニマルな単位のオブジェクトは再利用しない。

ネストが多くなってくるとインスタンスの命名規則も大切。


■ 同じ形で色違いのオブジェクトは、インスタンスを再利用して「着色」

「着色」では容量はほとんど増えません。
色が違うだけで形状がおなじオブジェクト同士は、ひとつのインスタンスにするべきです。


■「描画オブジェクト」よりも「グループ」の方が軽い

比較的小さな差なのですが、文字などを「描画オブジェクト」としておくよりも「グループ」にしたほうが軽くなります。
ちりも積もれば何とやら。
一つのコンテンツ中で、数KBは変わってきます。


■なるべく「グループ」よりも「インスタンス」

インスタンスにすることで、サイズレポートでシンボル別に容量を確認することが出来ます。

逆に、サイズレポートの必要もなく、再利もしないオブジェクトは「インスタンス」よりも「グループ」のほうが好ましいです。

わずかながら、「インスタンス」は「グループ」の状態よりも容量を食います。


■「線を塗りに変換」を行うと重くなる

イラレでアウトラインとった文字の、フチ線の部分はFlashでも「線」になります。
一見、文字の本体とまとめて一個のシェイプにした方がパスの情報が減って軽くなりそうな気がしますが、実際にはイラレそのまんまの状態の方が軽い。

こちらも、前述の通り「描画オブジェクト」ではなく「Ctrl+B」してから、文章単位で「Ctrl+G」グループ化しておきましょう。


■ タイムラインのキーフレームの量とかはほとんど関係ない

タイムラインが空のキーフレームだらけであろうとレイヤーが多かろうと、ほとんど差はないみたいです。

ちなみに、サイズレポートではなんの処理もないフレームでも2バイト使用しているようです。
タイムラインがきれいで無駄のない状態であるのにこしたことはありませんが、大してナーバスになる必要はありません。


■ 微妙にヨレた感じのラフな曲線などは「最適化」してやる

フォントなどによっては、周囲の線がラフな感じのものがあったりしますが、見た目が大きく変わらない範囲内で線を最適化しておくべきです。

パスのアンカーポイントが減って、軽くなります。


■ 微妙な曲線は「まっすぐに」

ほんとにわずかな差ですが、見た目直線系のフォントのアウトラインなんかでも、「まっすぐに」を処理してやると軽くなったりするものがあります。
ほんとにちょっとだけの差なので、最後の手段といったところか。


■ デバッグ用、作業用のオブジェクトは既存のインスタンスを再利用
■ デバッグ用、作業用のオブジェクトは「線をまっすぐに」


見えないところもきちんと無駄を省いていきましょう。
デバッグ用の数字オブジェクトなんかも、極限までアンカーポイントを減らしてしまいましょう。


■ 変数名は短く
■ flaファイルに日本語は書かない


このことはよく言われる、基本中の基本です。
「変数名」はプログラム内部で繰り返し展開されることになる文字列ですから、短くするべきです。

インスタンス名も短くしておきましょう。

「game_mc」「title_txt」とするよりも、
「gameMc」「titleTxt」とする方がアンダーバーの分短く済みます。

ネストするオブジェクトと命名規則が衝突しないのであれば、さらに
「game」「title」としたほうがいいです。

さらに、煩雑にならない限りにおいて「g」とか「t」とかしてしまうのも手です。

これらの小さな努力で、数KBは軽くなっているんでしょう、おそらく。


■ 最終パブリッシュ前にtrace文は手で取る

これ、数字で確かめた訳ではないけど、「traceを省略」よりも手で取った方が軽くなると思います。




いま思い出せる限りでは、以上です。

インスタンスの再利用をどれだけ徹底できるか、っていうのが
一番大きいと思います。

たまに、容量削減のためにGIFなんかの画像ファイルをつかっちゃってるソースを見たりしますが、
ナンセンスだと思います。
きっちりやればちゃんと軽くなる。

これ以上無理!と壁にぶつかっても、
多少形状の違うものや線の太さの異なるものを思い切って共通化してしまうとか、
ンカーポイントを減らすとか、細かい修正の余地はまだあるはずです。

共通部分があまりに少ないデザインは、デザイナーにお願いして修正してもらいましょう。
自分がデザインもする立場の場合は、いかに再利用できるかを考えながらイラストなどを構成するべきです。


(・ω・)


■ この他のFlash関連TIPS

このエントリーをはてなブックマークに追加
posted by taichistereo at 03:02 | Comment(0) | Adobe Flash/action script

2008年01月09日

AS3.0がWebデザイナーにもたらす世界

ActionScript3.0は本当にたのしい!

新しい言語、新しい考え方、新鮮な感覚。

ActionScript2.0以前的な書き方でももちろん動くモノは作れます。
だからどこぞの巨大掲示板で嘆いているように「3.0なんて無理」とか言わなくても平気です。
ここのところは非常に重要だと思います。
コンパイラに「それ2.0までの書き方だからw」とか怒られながらも、すぐに3.0に移行することは出来ます。
それでAVM2の恩恵にとりあえずあやかれます。

でも、本格的なゲームを作っていると、
こりゃあ手続き型のプログラミングではやってられん、という感じになってきました。
この考え方のままではあぶない、という「不吉な匂い」をかんじたときが、「手続き型」から「オブジェクト指向」にスイッチするタイミングなのだと思います。

これまでのActionScriptで「とりあえずきちんと動くモノ」を作ってきた経験をすてて、
もっと広い視野で「プロジェクトを進める上で、ベストな設計・ベストな書き方はなんだろう」
「最も優れたプログラマーであれば、ここはどうやって組み上げるだろう」と考えながら
3.0という新しいスタンスに自分自身をアップデートするチャンス。

なんとも大げさな感じだけれど、
デザイナーがJAVAを書けるようになるというのはすごいことだと思います。


「3.0はなんでこんなにかわっちまったんだ」「互換性ねぇのかよ」「JavaScriptがJavaになったみたいだ」みたいなことは、みんな思ったわけです。

でも、1.0、2.0、3.0とASを書いてきた結果として
普通のWebデザイナーにはうかがい知ることの出来なかったWEB開発の一面が見えてきます。

「これが本当のプログラマーの仕事か!」


「これまでなんとなくAS2.0、なんとなくPHP5で顧客に満足してもらえるモノは納品してこられたけれど、
なんとなくいまいちいけてないんじゃないかなぁ。。。」
それは要するに、どちらも中途半端なオブジェクト思考っぽいことができる言語のうえで
基本はVBみたいなことを延々書いていたに過ぎないのだな、と思います。
なんかすげー特殊なことをしていたのだな。


AS3.0で作り、考えていると、
そういう特殊かつローカルな世界の方言ではなくて、
純粋でグローバルな開発の世界でつうじる公用語でもって世界を語り直せるのだね。

これも大げさで誤解を招きそうな表現だけれど。


でも、これが楽しくないわけがない。
今まで作れなかったモノが作れる。
今まで話せなかった人と話せるかも知れない。
今まで見えなかった世界が見える。

これが楽しくないわけがない。


デザイナーに「テストケースを書け」といってもそれは無理な話じゃない?本来。
でもそういうことができるようになって、SEになるデザイナーも出てくるかも知れない。

もしそんなことになってきたら、とっても不思議な現象です。
Flashの周りでしか起こりえないことだと思います。

本当にそんな人材がビジネスの世界に大量に必要だとも思えませんが、
少なくとも人間の可能性の話として、とてもおもしろい(笑。
このエントリーをはてなブックマークに追加
posted by taichistereo at 02:12 | Comment(0) | Adobe Flash/action script

2008年01月08日

FLASHerにとってのWEB開発とゲーム開発の違い

80年生まれの、プログラムも書けるデザイナー。
いろいろやるけど結局いちばんわかりやすい肩書きは「FLASHer」。

そんなWeb開発者にとって、
「Webの世界」と「ゲームの世界」とのちがいは予想以上に大変なものがあると気付かされています。

まだまだプロジェクトの序盤ではありますが、
FLASHerがActionScript3.0で本格的なゲーム開発に取り組むなかで
いま感じていることを書いておこうと思います。



まず以下は聞いた話。

少なくとも国内において、ゲーム開発の現場において
「デザインパターン」というものはあまり考慮されてこなかったそうです。

そもそもオープンな考え方ではじまって今に至るWebプログラミングと違って、
ゲームの世界はそれぞれのソフトハウスが
「如何に低級に書いて、如何に高速に処理するか」を独自のノウハウとしてきている、
という経緯があるみたいです。

低級に書く、ということは
便利で高度なライブラリがあったとしても使わずに、
プログラマがその都度がりがりアセンブラでスクラッチで実装する、
ということ。

ソフトハウスのノウハウ、というよりは
個別のプログラマのノウハウ、といったほうがよさそうです。
(そういう技術者が複数年間集まっているところがソフトハウスだった、とも言えるかもしれません)

ゲーム開発の現場の多くでは、複数人での実装を前提とした「コーディングルール」さえあまり存在しない(かった)らしい。。。
Webの世界では比較的少数のメンバーによる小規模な開発でもコーディングルールを渡されたりします。
たかがHTMLメールなんかに至るまでコーディングルールでがんじがらめということも。


ゲーム開発においてPS1以降にようやく「ゲームエンジン」、つまりWebでいうところの「フレームワーク」といった形で個別のプログラマ、個別のプロジェクト・タイトルの枠を超えて資産(ノウハウ)を共有し活用するようになったのは、PS1以降の開発言語がC++になったから。
smalltalk以降のオブジェクト指向の考え方がようやくゲーム開発にも登場したというわけだ。

「デザインパターン」というのも考えればオブジェクト指向以降のコンセプトなので、
まだあまり定着していないというのもうなずける話です。
(PS1もインターネットもだいたい同時期に普及を始めているので微妙な話ではありますが。。。)


さて、我々FLASHerが愛してやまなかった(?)FlashもActionScript3.0になり、
抽象クラス(abstract)の有無など多少の差はあっても
「ほとんどJava」な開発環境になったので、
ゲームらしいゲームが作れる。。。はずなんだけど、
肝心の作る人間のほうがですね、
「FLASHer」なんて呼ばれる人間は所詮Webの世界しかしらない子供なわけで、
なかなか本格的なゲーム開発の文化になじみにくいものがあります。

JAVAやC++でのゲーム開発経験があれば言語的な壁はほぼないと思いますし、
その他の言語(Cなど)でのゲーム開発経験があれば
オブジェクト指向の壁があったとしても
プロジェクトがどのように進むのかは経験的に見通しが効くとおもいます。

しかしながら哀れなFLASHerは!
オブジェクト指向の壁にぶつかり、同時に
Webの世界ではあり得ない「仕様は、実際につくって動かしてみないとわからない」という恐ろしい壁にもぶつかります。

今まさにこの壁にぶつかっています。
(しかも3Dプログラミングというオマケつき!)


「仕様が決まらない」というのは、Webにしろイントラにしろ、業務系システムではままあることです。
顧客企業のビジネスを洗い、要件を定義していくのに困難が伴うのは、
「そのビジネスがいま一体どのようであるのか」最適なソリューションを用意することの困難さに起因するとおもいます。

コンシュマー向けのWebサイトやSaaSの場合は、
顧客の要求がマーケティングなどに裏打ちされた企画ドリブンであるためにこのような混沌は比較的少なく、
「がちっと仕様を固めてから」「とりあえず仕様通り作ってみよう」が通用します。
そのあとで「やっぱりこうしよう」というのはあっても、
そもそも仕様が決まらないということはあまりない。


一方でゲーム開発の場合に「仕様が決まらない」のはなぜか?
いまのところ僕はその理由を、
ゲームというプロダクトが 広義の「メディアアート」だからなんだと思っています。

美術作品らしきものをつくっていた学生時代を思い出せば、
納得するモノに落ち着くまでの試行錯誤といったらなかった。

そもそも、どんな結果で自分が納得するか、それがわからない。だから作る。

ゲーム開発もこういうところがあるんじゃないかなぁと思います。


Web開発の現場に慣れてきていた自分には、
いかに合理的に開発を進めるか、効率的にプロジェクトを結果に導くかが
すべての開発者のプロジェクトの命のように思えていました。

だからこそ、可能な限り高級な技術でもって
再利用性や可用性・仕様変更に耐えうる実装を目指す。
(僕自身はオブジェクト指向では開発していなかったものの、そういうことが大切だとは思っていました。)

技術的に試行錯誤することはあっても、その前の仕様や企画はブレない。
ブレるような仕様や企画は、それを書いた人間が悪い。
それが基本的なスタンスになっていました。

でもそれだけが開発ではないんだな、
ということをゲーム開発のプロジェクトに参加させていただく中で感じるようになりました。

デザインの作業に近い気もしますが、
積み重ねる作業量が全然違う。
これがゲーム開発なのかなぁ、などと考えながら格闘しています。

もしあなたが口先だけでなく、本当に新しい価値のために努力できるFLASHerなら、
いまこの時期に十分楽しんで取り組める分野だと思います。


自分も、口先だけでなく常に新鮮な価値のために努力を続けられるようでありたいと思います。
結果やいかに。。。

このエントリーをはてなブックマークに追加
posted by taichistereo at 02:47 | Comment(1) | Adobe Flash/action script

2007年12月31日

「プログラムも書けるデザイナー」のためのAS3.0課題図書 3冊+1

30日の夕方ごろ、「あーなんか疲れたな」と思って、
とりあえず新幹線にとびのってきました。

なんかすごい何も考えずに行動していたっぽくて、
自分の姿が新大阪駅の大きなガラスの扉に映っているのを見て
「あっぼく大阪にいるんだ!!」とそのときやっと気付きました。

自分が何者でもなくなったような感じはひさしぶり。
「Freerance is freedom」などと言いながらも、
意外と しがらみ みたいなものを感じつつ生活していたようです。


新幹線に乗る前、書店で
この休みに読んでおく本を買っておきました。

ずばりテーマは、いま抱えているプロジェクトの要である「ActionScript3.0」。
ついでにFlashIDEを含め、今後のためにAdobe CS3による開発環境のアップデートも。


ほんとは「Java言語で学ぶデザインパターン入門」一冊だけあれば十分だと思っていたのだけれど、
運悪く書店になかったので以下の4冊にしました。


ちなみに僕のステータスは

・LightweightScriptiにおいては実務上問題がない
・Javaの入門書を何冊か読んできている
・OOP入門書も何冊か読んでいる

・AS2.0までは特に業務に支障がなかった
・けれどclassをガリガリ書いたりはしたことがなかった

・さいきんAS3.0でガリガリ書けるようになりつつある
・けれどいまいちしっくりこなくて、なんかすげー仕事が遅い気がする


というところです。

いままでの使用言語は
・ActionScript3.0
(・Flash lite1.0/1.1)
・Python
・PHP5
・ActionScript2.0
・PHP4
・ActionScript
・Lingo

(新しいものがうえです)



「Adobe CS3 Web Premium Essential Book」 オブスキュアインク、大津真、など

3200円の本だけれど、
オールカラーの美しさに3000円、内容は100円、のこりの100円は本屋に募金、といったところ。

MX以降のいわゆる「ラウンドトリップ編集」スタイルについての解説本といえますが、
個別のTIPSっぽい項目は本当に役に立たない。
CS3 Web Premiumのすべてのソフトをすでに使っているユーザーにはぜんぜん意味がないと思われます。
(特にFlashまわりはばかばかしい!)

けれど、
CS3で新しく提供された「Bridge」「Device Central」とはなんぞや?とか、
「DreamWeaverはMX時代に切り捨てたけど、また使ってみようかな」
「顧客に提案する材料として、Contributeのこと知っておこうかな」
「PS、IL、FW、FL相互でのオブジェクトの持ち回りは、AdobeのMacromedia買収後どうなったのか」
などといったことはさくっと理解できて便利です。

財布に余裕があれば買っておいても良いと思います。読むの30〜60分くらいだし。

イラレやフォトショからDevice Centralを利用する、なんてのはたぶんこれを読まないとしばらく気付かなかっただろうなぁ。
Bridgeの設定でWebPremium全体のベーシックなカラーマネジメントを行うだとかも。

Device Centralってば「ああ便利になったねぇ」ぐらいにあなどっていたけど、
かなり見所のあるツールみたいです。



「Java言語で学ぶリファクタリング入門」 結城浩

同じ著者の「デザインパターン入門」がおいてなかったので、とりあえず買っておきました。
「マルチスレッド編」はどうもJavaに寄りすぎていてActionScript3.0には適用できないのでは?と思って見送ったのですが、あとでAS3のヘルプをみるとやはり「マルチスレッド」のワードではヒットしない。「スレッド」「thread」でも同じ。
AS3.0でも外部ライブラリで可能になることなのかも知れないので(よくわかってない)
いちおう海外のライブラリをググっておこうと思いますが、
差し迫ってこのへんのことが現実の仕事に影響することはないのではないかと。

「リファクタリング」ですが、もちろん書き上がっていないコードはリファクタリングの対象にはならない。
けれど、どう書いていれば美しいのか、後で失敗しないのか、ということを絶えず考えているためにも
手元に置いておくと無駄にならないと思います。
長いスパンでちょくちょく読んでいくことになると思いますが、正月のウチに読めるトコ(理解できるトコ)だけでも目を通しておくと、年明け1行目に書くコードが良い方向に向かうような気がします。。。!



「ゲーム開発のための数学・物理学入門」 Wendy Stahler

ActionScript 3.0 アニメーション」はきちんとActionScript3.0のソースが書ききられていて便利だけれど、
数学の話をすっとばすことでコードに紙幅を割いていました。
こちらは逆に、言語に固有のところはおいといて、プログラミングするうえで汎用的に参照できる
高校数学・物理を説明しているようでした。
仕事している中で「プログラマは理系よりも実は文系の向いてるんだよ」なんて話がたまに出たりしますが、
理系の教育になじんでいない文系に欠けているのはまさにこういった基本的な部分だと思います。
文系PGにとって理系PGのアドバンテージは、こういった本で十分取り返せると思うのです!



「基礎からのJava」 宮本信二

わかりやすい本です。
プログラム初心者は前半から順に読んでいくと良いと思います。
僕はいちおう
・LightweightScriptiにおいては実務上問題がない
・Javaの入門書を何冊か読んできている
・OOP入門書も何冊か読んでいる

というかんじなので、後半移行のクラス・継承・カプセル化・ポリモーフィズムの解説が役に立っています。

OOPの主流であるJava言語で記述ルールを学習しながら、
「これはActionScript3.0ではどう書くのか」「AS3.0に存在するのか」といったことを確かめていくというステップがActionScript3.0習得には不可欠だと思います。

特に文系PGであり「プログラムの書けるデザイナー」である自分のような人間にとっては
書籍が充実しているJava言語について学習するというステップを踏まえることが
結局のところAS3への近道になると思っています。


 
このエントリーをはてなブックマークに追加
posted by taichistereo at 03:13 | Comment(0) | Adobe Flash/action script

2007年11月07日

Flash CS3ヘルプ「例 : 基本的なアプリケーションの作成」修正版

Adobe Flash CS3のヘルプ中「ActionScript 3.0 のプログラミング 」の中の「例 : 基本的なアプリケーションの作成」には、3.0のファーストステップとなるようないわゆる「hello world」的なスクリプトが解説されています。

しかしながら、
その通りにやってもエラーが出てしまうのだ!

続きを読む
このエントリーをはてなブックマークに追加
posted by taichistereo at 19:59 | Comment(0) | Adobe Flash/action script
Blog Widget by LinkWithin