2014/02/19(水) [n年前の日記]
#1 [movie] うさぎドロップ実写版を視聴
昨日TV放送されてたので一応録画、していたので視聴。
自分、原作→アニメ版の順で既に見てしまっているので、どうしてもそれらと比較しちゃって評価は悪くなるわけだけど。また、キャラ設定が原作から変更されたと聞いていたので、これはかなりダメなんじゃないかなーと期待せずに一応見始めたのだけど。
意外と原作通りの台詞が多くて、脚本の人はちゃんと原作を読んだ上で書いてるっぽいなと感心。や、失礼ながら実写畑って、原作すら読まずに脚本書いてるんじゃないの？ と首を捻る時もたまにあったりするので…。そういう事例と比べれば、まだ、原作を尊重してるほうかもしれないなと思えたり。
とはいえ、モデル設定はやっぱり謎。何を考えてたんだろう…。意図が見えない…。あるいは、どんな大人の事情があったのだろう…。まあ、この映画から入る人にとっては、この設定でも別に問題無いかも、という気もするのですが。
漫画原作は、主人公の心情・思考をことごとく _モノローグ ？ _傍白 ？ で説明していたので、ほとんどのシーンの意味合いが伝達できていたわけだけど。アニメ版は、そういった手法を結構排除していたし、特に実写版は徹底的に排除していたので、そのあたりの変換作業が興味深かったり。「これで伝わるのか…？」「ああ、ここは上手いなあ」とチラチラ思ったりして。
りん役の子役さんがリアル幼女なので、見てるだけで可愛いなと。もっとも、原作が活用していた漫画の記号的表現は一切使えないわけで、そっち方向の可愛らしさは提示できるわけもなく。また、生きている役者さんが演じることで発生する説得力という面もあって、実写ならではのメリット・デメリットを各所で感じたり。
最後のあたりでオリジナル展開を入れたのは、となりのトトロあたりと似た効果を狙って入れてきたのかしら。「このままじゃさっぱり盛り上がらずに映画が終わってしまう…どうしよう…」てな悩みは、例えば宮崎駿監督も毎回抱えて、結果ああなってしまうらしいし…。映画の脚本って大変だなと。
総じて、「これは見るべき」とまでは言えないけれど、「まあ…フツーに見れるよ」と言えそうな映画になっていた気もしたり。もちろんそれは、この映画から入るなら、という前提で。原作やアニメ版を見てる人には、ちとオススメできないかもしれず。細かい部分の改変理由がうっすら見えるならまだしも…。
実写版→アニメ版→原作、の順で見ていけば、楽しめるかもしれない、と思えました。自分は一番損をする順番で見ちゃったので、ちと失敗。
自分、原作→アニメ版の順で既に見てしまっているので、どうしてもそれらと比較しちゃって評価は悪くなるわけだけど。また、キャラ設定が原作から変更されたと聞いていたので、これはかなりダメなんじゃないかなーと期待せずに一応見始めたのだけど。
意外と原作通りの台詞が多くて、脚本の人はちゃんと原作を読んだ上で書いてるっぽいなと感心。や、失礼ながら実写畑って、原作すら読まずに脚本書いてるんじゃないの？ と首を捻る時もたまにあったりするので…。そういう事例と比べれば、まだ、原作を尊重してるほうかもしれないなと思えたり。
とはいえ、モデル設定はやっぱり謎。何を考えてたんだろう…。意図が見えない…。あるいは、どんな大人の事情があったのだろう…。まあ、この映画から入る人にとっては、この設定でも別に問題無いかも、という気もするのですが。
漫画原作は、主人公の心情・思考をことごとく _モノローグ ？ _傍白 ？ で説明していたので、ほとんどのシーンの意味合いが伝達できていたわけだけど。アニメ版は、そういった手法を結構排除していたし、特に実写版は徹底的に排除していたので、そのあたりの変換作業が興味深かったり。「これで伝わるのか…？」「ああ、ここは上手いなあ」とチラチラ思ったりして。
りん役の子役さんがリアル幼女なので、見てるだけで可愛いなと。もっとも、原作が活用していた漫画の記号的表現は一切使えないわけで、そっち方向の可愛らしさは提示できるわけもなく。また、生きている役者さんが演じることで発生する説得力という面もあって、実写ならではのメリット・デメリットを各所で感じたり。
最後のあたりでオリジナル展開を入れたのは、となりのトトロあたりと似た効果を狙って入れてきたのかしら。「このままじゃさっぱり盛り上がらずに映画が終わってしまう…どうしよう…」てな悩みは、例えば宮崎駿監督も毎回抱えて、結果ああなってしまうらしいし…。映画の脚本って大変だなと。
総じて、「これは見るべき」とまでは言えないけれど、「まあ…フツーに見れるよ」と言えそうな映画になっていた気もしたり。もちろんそれは、この映画から入るなら、という前提で。原作やアニメ版を見てる人には、ちとオススメできないかもしれず。細かい部分の改変理由がうっすら見えるならまだしも…。
実写版→アニメ版→原作、の順で見ていけば、楽しめるかもしれない、と思えました。自分は一番損をする順番で見ちゃったので、ちと失敗。
◎ どうしてモデル設定がしっくりこないかと言うと。 :
以前、漫画家の渡辺多恵子先生が、「作品中で、一つの大きな嘘を成立させるためには、たくさんの事実を積み重ねないといけない」てな話をどこかで書いていて。自分も、その考え方というか、手法に同意するのですけど。
独身男が幼女を引き取って育てる、てのは、かなり大きな嘘だと思うわけで。その嘘を成立させるためには、周りは「リアル」で固めておかないと。そこに、モデル設定という大きな嘘を、また一つ入れてる余裕はないんじゃないの？ と思ったわけです。身近にモデルさんが居るなんて、見てるこっちにとってはファンタジーなので。ファンタジーだらけにしたら、この作品の、(前半の)魅力は弱まるのではないか、と。
でも。りんの母親も、 漫画家設定だったか…。フツー、身近に 漫画家なんて居ないよな…。りんの出自にしても…。原作からしてファンタジー設定だらけ、だよなあ…。そう考えると今更かもしれず…。
それに、映画関係者にとっては、身近にモデルさんが居ることなんて、ファンタジーでも何でもなくて「リアル」だろうし。ただ、そういう感覚で改変したのだとしたら、ちとマズイのかも。お客さんにとっての「リアル」が見えなくなってる・想像できなくなってる状態で、ウケる娯楽作品を作れるものだろうか、という疑問も。あまりいい傾向ではないのかもしれず。
もっとも、「設定を変えることで、こういう効能が期待できる」「この部分を強化できる」等の理論武装がそこにあったのかもしれないし。その理論武装を知れば、自分の印象は変わる可能性もあるのですが。いや、意図が見えてこない時点で、その理論武装は外してた可能性もありそうですけど。
でもまあ、他のドラマや映画に比べたら、「リアル」を比較的混ぜていた方だろうし。このくらいなら許容範囲なのかなあ…。どうなんだろ。
変えることで面白くなるなら、全然OKなんですけど。「これは面白くなったのか？」と悩むソレだからアレなわけで。かといって、メディア自体が異なっている原作のソレをトレースして、映像作品として面白くなるかというと、悩んでしまうわけで。
なんでもそうだろうけど、こういった「見極め」って難しいですな。
独身男が幼女を引き取って育てる、てのは、かなり大きな嘘だと思うわけで。その嘘を成立させるためには、周りは「リアル」で固めておかないと。そこに、モデル設定という大きな嘘を、また一つ入れてる余裕はないんじゃないの？ と思ったわけです。身近にモデルさんが居るなんて、見てるこっちにとってはファンタジーなので。ファンタジーだらけにしたら、この作品の、(前半の)魅力は弱まるのではないか、と。
でも。りんの母親も、 漫画家設定だったか…。フツー、身近に 漫画家なんて居ないよな…。りんの出自にしても…。原作からしてファンタジー設定だらけ、だよなあ…。そう考えると今更かもしれず…。
それに、映画関係者にとっては、身近にモデルさんが居ることなんて、ファンタジーでも何でもなくて「リアル」だろうし。ただ、そういう感覚で改変したのだとしたら、ちとマズイのかも。お客さんにとっての「リアル」が見えなくなってる・想像できなくなってる状態で、ウケる娯楽作品を作れるものだろうか、という疑問も。あまりいい傾向ではないのかもしれず。
もっとも、「設定を変えることで、こういう効能が期待できる」「この部分を強化できる」等の理論武装がそこにあったのかもしれないし。その理論武装を知れば、自分の印象は変わる可能性もあるのですが。いや、意図が見えてこない時点で、その理論武装は外してた可能性もありそうですけど。
でもまあ、他のドラマや映画に比べたら、「リアル」を比較的混ぜていた方だろうし。このくらいなら許容範囲なのかなあ…。どうなんだろ。
変えることで面白くなるなら、全然OKなんですけど。「これは面白くなったのか？」と悩むソレだからアレなわけで。かといって、メディア自体が異なっている原作のソレをトレースして、映像作品として面白くなるかというと、悩んでしまうわけで。
なんでもそうだろうけど、こういった「見極め」って難しいですな。
[ ツッコむ ]
#2 [prog] HSPはどうなんだろうと思ってしまった話
_テラシュールウェア 「ゲーム 作り方」
という、大変グッドな記事を眺めていたのですが。
記事中で、
こういう場面でHSPの名前を出すのは分かる。ていうか自分も、その手の記事中では一応HSPの名前も出しておくべき、と思うのだけど。しかし、本当にそれでいいのだろうかと不安になってきて。
まあ、件の記事はUnityを薦めてるし、自分もUnityを薦めるべきと思ってるので、本筋とは関係ない話なのですが。以下は、ただの思考メモです。
他にアレコレ、とりとめなくメモ。
気軽に使えるという点では、DXRuby が個人的に一押しで。まあ、これは再三書いてますけど。
記事中で、
Unity以外の場合はHSP3やenchant.jsをお勧め。とにかくセットアップが簡単で成果物が即見れるものが良い。という一文を見かけて、件の記事の本筋とは全く違う部分で、なんだかもやもやと考え始めてしまったり。
こういう場面でHSPの名前を出すのは分かる。ていうか自分も、その手の記事中では一応HSPの名前も出しておくべき、と思うのだけど。しかし、本当にそれでいいのだろうかと不安になってきて。
まあ、件の記事はUnityを薦めてるし、自分もUnityを薦めるべきと思ってるので、本筋とは関係ない話なのですが。以下は、ただの思考メモです。
◎ HSPについてもやもやする部分。 :
HSPは、言語仕様がアセンブラライクというかBATファイルライクなので…。
「21世紀にもなって、今から新たに学ぶべき言語なのですか？」
「これを初心者に教えてしまっていいのですか？」
と自分に問うてみると、さて、どうなんだろうなー、と。
HSPって、習得・習熟しても他に応用が利かないよなと。実際、HSPでプログラミングを覚えちゃった人は、えてしてなんでもHSPで作ろうと頑張ってしまう傾向があるように思えていて。それって、ステップアップを無駄に阻害する、ヤバイ何かを内包してんじゃね？ と。そんなもんを今時オススメしちゃっていいのだろうか、と。 *1 *2
例えば、最初に覚える外国語として、古代ギリシャ語とかラテン語とかを覚えてみても虚しいわけですよ。特定分野では使えるけど、他で使えない。まずは、世界中で広く使われている英語あたりを覚えたほうが後々美味しいのではあるまいかと。
プログラミング言語も同じで、真っ先にマイナー言語？ 古代語？ に触れてしまって、しかもそこで止まっちゃうのは、どうなのだろうと。
そう考えると、HSPの名前を出す時は、一緒に、DXRuby や PyGame 等、現代風の言語を使うこと前提のライブラリも併記しておくべき、かもしれないなと。「どれを選ぶかは君の自由だが、こっちはとりあえず紹介はしたぞ」「HSPがとにかくオススメなんて言ってないぞ」「選択肢の一つ、ぐらいに捉えてくれ」みたいな。
これがもし、Ruby や Python あたりなら、言語として筋がいいので、学んだことが無駄にならないはず。「Ruby(Python)ではこう書いたけど、○○ではこう書くのか」と、覚えた概念が後に使い回せる場面が多々あるだろうと。
特に Python は、「初心者にプログラミングを学ばせるなら」という視点で言語仕様が決められてる面もあるし。また、CG関連ソフトでは、「アプリにスクリプト言語も一緒に載せるならとりあえずPythonでしょ」てなムードで普及しつつあるので…。ゲームに興味がある≒映像表現にもそこそこ興味がある＝CG関連ソフトに触れる機会が多い＝Pythonを覚えておくと役に立つ、というメリットもありそうで。
とは言え。そのあたりを考えていくと、JavaScript を学習できる enchant.js は、HSPのマズいところをカバーしてくれるだろうから、HSP と enchant.js を併記するだけでも充分かな、とも思えてきました。HSPしか紹介していない、という最悪(?)の事態さえ回避しとけばOKなのかもしれないなと。
まあ、どう考えても、ゲームを作りたくて今から何かを学ぶなら、Unity ですわな…。
ということで、件の記事では Unity を薦めてるけど、それは実に正しいなと。今なら Unity ですよねえ。と思ったのでした。
「21世紀にもなって、今から新たに学ぶべき言語なのですか？」
「これを初心者に教えてしまっていいのですか？」
と自分に問うてみると、さて、どうなんだろうなー、と。
HSPって、習得・習熟しても他に応用が利かないよなと。実際、HSPでプログラミングを覚えちゃった人は、えてしてなんでもHSPで作ろうと頑張ってしまう傾向があるように思えていて。それって、ステップアップを無駄に阻害する、ヤバイ何かを内包してんじゃね？ と。そんなもんを今時オススメしちゃっていいのだろうか、と。 *1 *2
例えば、最初に覚える外国語として、古代ギリシャ語とかラテン語とかを覚えてみても虚しいわけですよ。特定分野では使えるけど、他で使えない。まずは、世界中で広く使われている英語あたりを覚えたほうが後々美味しいのではあるまいかと。
プログラミング言語も同じで、真っ先にマイナー言語？ 古代語？ に触れてしまって、しかもそこで止まっちゃうのは、どうなのだろうと。
そう考えると、HSPの名前を出す時は、一緒に、DXRuby や PyGame 等、現代風の言語を使うこと前提のライブラリも併記しておくべき、かもしれないなと。「どれを選ぶかは君の自由だが、こっちはとりあえず紹介はしたぞ」「HSPがとにかくオススメなんて言ってないぞ」「選択肢の一つ、ぐらいに捉えてくれ」みたいな。
これがもし、Ruby や Python あたりなら、言語として筋がいいので、学んだことが無駄にならないはず。「Ruby(Python)ではこう書いたけど、○○ではこう書くのか」と、覚えた概念が後に使い回せる場面が多々あるだろうと。
特に Python は、「初心者にプログラミングを学ばせるなら」という視点で言語仕様が決められてる面もあるし。また、CG関連ソフトでは、「アプリにスクリプト言語も一緒に載せるならとりあえずPythonでしょ」てなムードで普及しつつあるので…。ゲームに興味がある≒映像表現にもそこそこ興味がある＝CG関連ソフトに触れる機会が多い＝Pythonを覚えておくと役に立つ、というメリットもありそうで。
とは言え。そのあたりを考えていくと、JavaScript を学習できる enchant.js は、HSPのマズいところをカバーしてくれるだろうから、HSP と enchant.js を併記するだけでも充分かな、とも思えてきました。HSPしか紹介していない、という最悪(?)の事態さえ回避しとけばOKなのかもしれないなと。
まあ、どう考えても、ゲームを作りたくて今から何かを学ぶなら、Unity ですわな…。
- C# と JavaScript、好きな方を選べるし。(UnityのJavaScriptは真のJavaScriptじゃねえ、という意見もあるけど。)
- 描画も処理も早いし。
- Windows、Mac、Linux、iOS、Android、ブラウザ上でも動いちゃうし。
- ユーザ数も多いし。何せ全世界で使われているし。
- 商品レベルのゲームも作れるし。
ということで、件の記事では Unity を薦めてるけど、それは実に正しいなと。今なら Unity ですよねえ。と思ったのでした。
◎ 各環境の一覧も書いてみたり。 :
このままだと、「コイツ、HSPばかりdisってやがる。許せん！」と叩かれそうなので、もう少し、他の面もメモしておこうかなと…。初心者の自分が、それぞれ触ってみた印象は、下のような感じだったりするのですが。(感想には個人差があります。)
HSPは、言語仕様はアレだけど、表で示したとおり、他に強みがたくさんあって。個人的には、低スペックPCでも結構な速度で動いたり、多様なハードウェアの制御までできちゃうあたりが凄いなと。めちゃくちゃ非力な、Intel Atom搭載ネットブック上でも、他のアレコレと違ってHSPだけはそれなりの速度で動いてしまって、かなり感心した記憶もあり。もっとも、そのために言語仕様がアレになってる部分もありそうで、いわゆるトレードオフってヤツなのかしら、と想像しているのですけど。
しかし、こうして表にしてみると、Unity と FLASH(Adobe AIR)は強いなあ…。隙が無い…。
ただ、FLASHは、導入が…。「Starling 使うにはどうしたらいいの？」「FlashDevelopのアップグレードはどうすりゃいいの？」みたいなところで、ちょっとハマった記憶が。FLASH は、描画速度も処理速度も比較的速いし、どこでも動くので、個人的には好きなのですけどねえ…。
「enchant.js なんて劇遅ライブラリを引き合いに出すなや。爆速の _tmlib.js や _Pixi.js を出せや」
「Cocos2D系は？ 今はアレが一番ホットでしょ？」
という意見もあるのだろうな。自分、そのへんは触ったことがないので、どんな感じなのか分からなかったり。 *3
_Scratch も一見良さそうだけど、アレは1命令が1フレームで動くから、リアルタイムゲームが作りづらくて。プログラミングを学ぶ入り口としてはグッドだけど、リアルタイムゲームを作るための環境としては、とってもバッドな印象。
ということで、「ゲームを作りたい？ だったら Unity かなあ」てのが鉄板だよなと。Unity 4.3以降は、2Dゲームも随分作りやすくなりましたし。
ただ、Unityは、学習コストがちと微妙な印象で。「俺はゲームを作ってるのか？ それともUnityの使い方を勉強してるだけなのか？」と迷う時が。MS Office製品の使い方を勉強してる感覚に近いというか。…高機能と学習コストはトレードオフだから、仕方ないですけど。
| Unity | HSP | enchant.js | DXRuby | PyGame | FLASH(Adobe AIR) | |
|---|---|---|---|---|---|---|
| 導入が簡単 | ◎ | ◎ | ？ | ○ | ○ | △ |
| ユーザ数の多さ | ◎ | ◎ | ○ | × | ○ | ○ |
| ライブラリの充実 | ◎ | ◎ | ？ | ？ | ？ | ○ |
| 描画速度・処理速度 | ◎ | ○ | × | ○ | × | ◎ |
| 更新されているか | ◎ | ○ | ○ | ○ | × | ◎ |
| 言語仕様 | ○ | × | ○ | ○ | ◎ | ○ |
| 英語圏でも使われてる | ○ | × | △ | × | ○ | ○ |
| ブラウザ上で動作 | ○ | × | ◎ | × | × | ◎ |
| exe化可能 | ○ | ○ | × | ○ | ○ | ○ |
| Windows/Mac/Linuxで動く | ○ | × | ○ | × | ？ | ○ |
| スマホ等でも動く | ○ | △ | △ | × | × | ○ |
| ジョイスティック対応 | ○ | ○ | × | ○ | ○ | ○ |
| 2Dゲーム制作可能 | ○ | ○ | ○ | ○ | ○ | ○ |
| 3Dゲーム制作可能 | ○ | ○ | △ | × | × | ○ |
HSPは、言語仕様はアレだけど、表で示したとおり、他に強みがたくさんあって。個人的には、低スペックPCでも結構な速度で動いたり、多様なハードウェアの制御までできちゃうあたりが凄いなと。めちゃくちゃ非力な、Intel Atom搭載ネットブック上でも、他のアレコレと違ってHSPだけはそれなりの速度で動いてしまって、かなり感心した記憶もあり。もっとも、そのために言語仕様がアレになってる部分もありそうで、いわゆるトレードオフってヤツなのかしら、と想像しているのですけど。
しかし、こうして表にしてみると、Unity と FLASH(Adobe AIR)は強いなあ…。隙が無い…。
ただ、FLASHは、導入が…。「Starling 使うにはどうしたらいいの？」「FlashDevelopのアップグレードはどうすりゃいいの？」みたいなところで、ちょっとハマった記憶が。FLASH は、描画速度も処理速度も比較的速いし、どこでも動くので、個人的には好きなのですけどねえ…。
「enchant.js なんて劇遅ライブラリを引き合いに出すなや。爆速の _tmlib.js や _Pixi.js を出せや」
「Cocos2D系は？ 今はアレが一番ホットでしょ？」
という意見もあるのだろうな。自分、そのへんは触ったことがないので、どんな感じなのか分からなかったり。 *3
_Scratch も一見良さそうだけど、アレは1命令が1フレームで動くから、リアルタイムゲームが作りづらくて。プログラミングを学ぶ入り口としてはグッドだけど、リアルタイムゲームを作るための環境としては、とってもバッドな印象。
ということで、「ゲームを作りたい？ だったら Unity かなあ」てのが鉄板だよなと。Unity 4.3以降は、2Dゲームも随分作りやすくなりましたし。
ただ、Unityは、学習コストがちと微妙な印象で。「俺はゲームを作ってるのか？ それともUnityの使い方を勉強してるだけなのか？」と迷う時が。MS Office製品の使い方を勉強してる感覚に近いというか。…高機能と学習コストはトレードオフだから、仕方ないですけど。
◎ 補足・余談。 :
- 導入が簡単、てのは、セットアップファイルを実行するだけでインストールできるかどうか。中には、それをインストールするだけで、エディタまでついてくる便利なものもある。(Unity、HSP等。)
- ユーザ数が多いと、情報を探しやすい。
- ライブラリが充実してると、やりたいことは、まず大体できる。例えばHSPは、PCに繋いだモーターの制御までやれたりする。(enchant.js、DXRuby、PyGame は、ソレ自体がライブラリなので「？」にしました。)
- 英語圏でも使われてると、スーパーハカーが参加してくれる確率が上がるので、有意義な情報が出てきやすい・拡張機能が揃いやすい。英語の勉強にもなる。作ったものを世界に向けて見せることもできる。
- ブラウザ上で動作すると、誰にでも気軽に見せてプレイしてもらえるので、学習モチベーションが維持しやすい。
- 言語仕様は…。自分は、Python が最も初心者向けじゃないかと思ってるので…。このあたりは反論がたくさんありそうですけど。
他にアレコレ、とりとめなくメモ。
- PyGame は開発が終わってるし、描画が遅いので、今現在は、ちとオススメできない感じ。
- PyGame 後継の PySDL2は、仕様がガラリと変わってしまったので、PyGame が持っていた手軽さ・気軽さは、もう無いなと。
- pygletもヨサゲですが、そっちも開発が止まってないか？ という不安が。ていうか pyglet は Radeon 上で描画がバグるから選択肢としては無しかな…。Radeon の OpenGL が腐ってるせいですが…。
気軽に使えるという点では、DXRuby が個人的に一押しで。まあ、これは再三書いてますけど。
- ゲーム制作に必要最低限な基本機能だけを提供するスタンスで作られてる。覚えなきゃいけないことが少なくて済む。
- メインループが超シンプルに書ける。お手軽な実験・プロトタイプ作成に最適。
- DirectX を使ってるので描画が速い。BGを数枚描画しただけでガクガクしちゃって頭を抱える、等の余計なトラブルは回避できる。(でも、DirectXがそもそも遅いPCでは、目も当てられないことになるのですが、今時そういうPCは少数派かなと…)
*1: もっとも、「やりたいことが、その道具を使ってちゃんとできているのだから、全然マズくねえよ。とにかく動けばいいんだよ！」「ステップアップ？ 余計なお世話だ！」という意見もありそうで。それもそれで一理ある。ような気も。色んな道具を使えるけど、何も完成させられないより、一つの道具でアレコレ完成品を作っていく人のほうが偉いよね、みたいな。
*2: そもそも、HSPの作者様が、「言語を作ってるつもりはない」と、どこかで明言していた記憶もあり…。「言語仕様」云々は、HSPに対しては頓珍漢な見方なのかもしれないと思えたりもして。
*3: ちなみに enchant.js は、学習用として中身を分かりやすく、と意識して書かれてるらしいので、そこもトレードオフ、でしょうから遅い遅いとdisらないで欲しい…。とは言え、手持ちのAndroid機で動かしたら紙芝居だったのは泣けました。それが理由で学習意欲も萎えました。古くてヘボいAndroid機なので仕方ないのですけど。
*4: でも、「Ruby対応のグッドなエディタ・IDEって無いよね」てな意見も出てきそうな。たしかに、作業効率を高めようとすると、Rubyは環境整備に苦労しますな…。メモ帳＋αのエディタで、ちょこっと書く分にはいいのですけど。
*2: そもそも、HSPの作者様が、「言語を作ってるつもりはない」と、どこかで明言していた記憶もあり…。「言語仕様」云々は、HSPに対しては頓珍漢な見方なのかもしれないと思えたりもして。
*3: ちなみに enchant.js は、学習用として中身を分かりやすく、と意識して書かれてるらしいので、そこもトレードオフ、でしょうから遅い遅いとdisらないで欲しい…。とは言え、手持ちのAndroid機で動かしたら紙芝居だったのは泣けました。それが理由で学習意欲も萎えました。古くてヘボいAndroid機なので仕方ないのですけど。
*4: でも、「Ruby対応のグッドなエディタ・IDEって無いよね」てな意見も出てきそうな。たしかに、作業効率を高めようとすると、Rubyは環境整備に苦労しますな…。メモ帳＋αのエディタで、ちょこっと書く分にはいいのですけど。
[ ツッコむ ]
以上、1 日分です。