任天堂「今後C++は捨てJavaScriptで開発していく」
任天堂のゲームはこれまで,CやC++といったプログラミング言語で開発されており,
そのため高いパフォーマンスを発揮していたが,反面,開発に時間がかかっていたという。
このセッションではそれ以外の方法,つまりHTMLやJavaScriptを使ってWii Uの全機能にアクセスしつつ,
より手軽にゲーム開発を行う方法が説明されるようだ。
http://www.4gamer.net/games/999/G999905/20130316001/ JavaScriptはC言語の皮をかぶったマクロの無いLisp ソフトウェアの進化というのは
開発効率が高い遅い言語で
作りなおすことで進化しているのです。
どんどん遅い言語で作られるようになりますが
それこそ進化なのです。 HTMLとJavascriptで新作マリオ出してくれたら信用する 捨てるとは書いてないべ
Javascript のインタフェースを用意してみたんだけど使ってみてくんない?
って感じじゃないのか
モバグリの開発者を囲い込む戦略なんじゃね HTML5のグラディウス完璧だったしな
そこそこの物は作れるんじゃないか このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所 レスポンス返って来なかったりメモリ不足がほぼ出ないようなシステムなら問題ないんだけどな 任天堂のゲームでそんなに高いパフォーマンスが必要だったものあったっけ
Cでマリオ作るの非効率だからやめるよ!ってだけの話じゃないの C++とJavascriptだったら
どっちが開発し易いか微妙なレベル
速度は確実にC++だけど Javascriptでインタープリタなテスト工程を経て、
C/C++に落としてくれる環境ならば賛同する。
(本番はCPUに近いNativeで。) ビックリするかもしれないけどいまやJavaScriptのコードは平均してJAVA並の速度なんだよね
ループ内のコードを外に出したり、ハイコンテキストなのを逆に利用して効率のよいマシン語にすることができる まぁ開発効率は高いわなぁ。スクリプトエンジンはどんどん高速になってるし ブラウザ戦争のお蔭でとんでもない速度で最適化が進んだからなあ 早いって言ってもスクリプトエンジン次第だぞ?
任天堂自前で作るのか? >>23
全然びっくりしないかもしれないけど
速いJavascriptエンジンはC++で書かれてるんだぜ >>11
>HTML5のグラディウス完璧だったしな
コナミ社員の自作自演?w ブラウザゲームに速度は必要ないし良い判断だろ
ブラウザゲームに特化するのは良い判断とは思えないけどな >>1に釣られる間抜けな馬鹿に言っておくけど、
JavaScriptで開発をするとは書いてあるけど、
C++を捨てるなんて書いてないからねw
速度が必要なところだけC++を使えばいい。
それにJavaScriptのエンジンはオープンソースの速いやつを使うだろ。
JavaScript実行環境はオープンソースにしないといけないけれど、
それで動かすアプリはクローズドでいいわけだし。 これは極端な例だけどJSがダントツで早い状況もある
http://nothingcosmos.blog52.fc2.com/blog-entry-155.html
最近のJSエンジンは本当に凄い
JSの数値は64bit浮動少数だけどint型で扱える範囲の時はそれで計算するとかはもう普通
配列も入っている型やばらつきによってそれぞれ最適化される
もう単純演算じゃあ差は出ない
正規表現とか高級言語の方が扱いやすいものもある
当然WEBとの相性はいい
反対に苦手なのがバッファを弄る処理
まあ苦手と言ってもCほどトリッキーなことはできないレベル
元々JSはIO全般と相性が悪かったけど最近はマシになってきた JSの速度のことを指摘している人は検討違い
JSの言語自体の問題は無い
あるのはアウトプットをどうするかということ
正直今のWeb技術はバリバリのゲームなんか想定してない
WEBにはオーバースペックだと度々言われるWebGLだって
コンシューマ機として考えたらOpenGL ES 2.0だからしょぼすぎる
WiiUのGPUとマッチしてないと思う
2DゲームだってCanvas2D+CSSだけじゃあ寂しすぎる
エフェクトとかがかけづらいからほとんどWebGL使うと思う
本気でやるんなら新しいCanvasのコンテキストを用意するのはもちろん
リアルタイムオーディオ系API、今ChromeとFirefoxで全然別なのが乗ってて合併中だけどそれをどうするのかも決めないと
細かいとこだけどHTML5のテンプレートとかCSSのシェーダーとか
今実験段階の機能も載せないとダメだと思う
WiiUがスタンダードを決めるくらいの勢いでいかないと成功しない
でもあくまでWeb技術だから無茶もダメ、
ブラウザはもちろん、今年から出てくるMobileWebOSのベンダー何かとも相談する必要あると思う
そういうことが任天堂にできるよう体制考えていくのかっていうのが大事
任天堂の一大プロジェクトとして頑張ってくれ >>37
何いってんだお前?
ライブラリさえ用意すれば、JavaScriptから
ファイルアクセスだってDirectX(Windowsの場合)だって
使えるんだよ。
Nodeなんかそうじゃん。言語はJavaScript
ライブラリはウェブ標準ではない。
JavaScript使うからってウェブ標準にする必要はない。 >>38
だからそのライブラリを用意するのがものすごく大変だと言っている
せっかくWeb技術を使うんだからそれと全くかけ離れたものを作ってもしかたない
Node.jsはWeb技術(HTML)じゃない、JSだけ
それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている
それでもここまで来るのに何年もかかった
だけどまだNodeはバージョン0.10
フラッシュアップするのにもう1年はかかりそう
それほど大変
そんな中ゲームサイドを作ろうとしたらライブラリ作ればいいじゃすまない
任天堂だけの手におえないし、おってはいけない
それこそ仕様ができた頃にはWiiUの次がでてるようなことになる
それはさすがに無理だからWEB技術を中心に採用することにしたんだろう
でも採用するといっても使えそうな技術は実験段階だったり
標準化に手間取ってたりする
それを待ってるとやっぱりWiiUには間に合わない
でも既存のWEB技術だけじゃあ残念すぎる
なんとかそこら辺を上手くやらなくちゃいけない
じゃないともったいない > だからそのライブラリを用意するのがものすごく大変だと言っている
今あるC++のライブラリのラッパーを作れば良い。 > それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている
CommonJSはオワコンで
参考にはするが、そんなのには従わないと
言ってるんだが知らないの? HTML5のグラディウスがコナミだとか
スーパーマリオ知らんってどんだけ情弱なんだよw >>42,43
今はCommonJS関係ないよ
でもそれが種だった
じぶんはv0.1代の頃から知ってたからよく分かる
それに少し考えてご覧
ほぼストリームのIOだけ提供すればいいサーバーサイドとはスケールが違い過ぎる
絵も音も出さなくちゃいけない
それらはバッファやストリームのラッパーを作ればいい次元じゃない
既存のを使えばいいとか無茶ぶりすぎる
それならそもそもなんのためにJavaScriptを使うのか
仮に既存のCのラッパー大量に用意してはいどうぞ
はて、Cで開発していた頃と何が違うのか
既存のWeb技術を利用でき既存のWebアプリ開発者でも参入できるからいいんじゃないか
それに仕様ってのは作ったはい終わりじゃすまない
それで済むのならHTML5だってもめてない
長い時間をかけて改善を繰り返さないと完成しないもの
そこまでしてゲームサイドJS環境を作れたとしてどんな意味があるのだろうか でもそれが種だった
でもそれが間違いだってわかった。
二度と同じ事を繰り返すことはないだろう。 > それらはバッファやストリームのラッパーを作ればいい次元じゃない
え? なんで?
根拠が無いなぁ(笑) 実行効率じゃなくて開発効率が悪いからかんべんしてほしいわ。
function hoge(x) {
x.maxLength = 100;
}
↑これをスペルミスで
function hoge(x) {
x.maxlength = 100;
}
↑と書いてもエラーにならないで、なんとなく動いちゃう言語。 時間がかかるのは標準技術だから
独自技術なら時間はかからない。
現にゲーム業界の速度は、標準技術を確立する速度を超えている。 JavaScriptつーかECMAScriptでstrictモード対応なら>>49みたいな心配はいらないんだけどなぁ C++を捨てる、なんてどこにも書かれてないな。
こういう釣りは、ゲハとかそっちの方面でやってくれ。 >>51
>>49の例はstrictモードでも防げないだろ そもそも>>49はhoge()がオブジェクトxの実装詳細を知っているのが前提という糞設計なのが問題 実装詳細ってなんだ?
公開プロパティだろ?
それともメソッドにすれば解決する問題だと思ってるのか? >>55
> 公開プロパティだろ?
Javascript知らないのがバレバレ メソッド(setter/getter)にすれば、少なくとも「なんとなく動いちゃう」は防げるだろ
ただし、それがJavaScript的なお作法に適合するのかどうかはわからんが あ、typoが問題じゃ無くて、外部から新たなプロパティを設定できてしまうのが問題なのか
だったら、俺はその防ぎ型を知らんわ >>55
他言語だって、変数を公開して、外で自由に触らせるのは良くない設計だよ? こういう時のために、Object.seal()があるんだよ
無知どもめ。 いまどきメモ帳でコード書くわけじゃあるまいし
最底辺プログラマが書くC++よりは安全だろう IDEのサポートが弱いのもダメだな。
動的型.vs.静的型の議論で「動的は簡単に書けて生産性が高い、
静的は安全に書けます。適材適所で使いましょう」みたいな大人の
意見を言うやつがいるけど、ぜったい動的は生産性低いだろ。 >>61
seal()で、どうやって>>49の問題を防ぐつもりなの? >>65
そういうのが出るってことは、やっぱ動的型の言語に問題感じてる人は多いんだろうな。 >>66
> >>49の問題って何?
まんまその通りだけど。
・スペルミスしたときに
・と書いてもエラーにならない
・なんとなく動いちゃう >>69
今度は、Object.seal()の機能をここにコピペしてみてよ。 >>71
Object.seal()の機能は知ってるから、どうやって>>49の問題を防ぐつもりなのかだけ教えてくれればいいから。 正直ゲームなんて多少変な挙動あっても適当に動いてりゃ許されるだろ
バグまみれでも大して問題にならないのってゲームプログラムだけだよね >>73
ゲームの方が、(精神的な)子供が多いから大問題になる気がするが >>72
Object.seal()の機能に、
>>69の問題を防ぐって書いてあるじゃん。
読んでないだろお前。 >>76
> Object.seal()の機能に、
> >>69の問題を防ぐって書いてあるじゃん。
そうは思えないから、どうやって防ぐのか質問してるんだけど。
コード書いてよ。 >>45
>HTML5のグラディウスがコナミだとか
>スーパーマリオ知らんってどんだけ情弱なんだよw
もうみんなすごーいんだよーーー
↓
ムダな努力w コナミがここまでグラディウスに執着してるとは思わなかったなw 断続的にガクガクになるのは、俺のPCがしょぼいせいか? >>36
なぜ?という部分を解明してないと
学術論文的な所では確実に無視される
その程度の内容
そもそも、まともなソースコードすら示していないいw >>81
是非とも横スクロール・オプション・レーザー付シューティング製作を! パフォーマンス的にやば過ぎるなこれ
こんなの客に出したら社会問題になるな >>85
1985年から28年間独裁してるから倒さなきゃな。 俺の知ってるニンテンドーのOSはCOMライクな作りでJSインターフェース持ってたよ。
それでブラウザ独自実装してたぞ。 >>85
>是非とも横スクロール・オプション・レーザー付シューティング製作を!
コナミの真似をすれば馬鹿と思われるから誰もしないだけw 本物グラディウスのソースリストいる?
C言語ソースと68000ライブラリ。 >>95
それって、今から読んでもちゃんと読める?っていうか、アホでもよめる??
あと、著作権大丈夫? >当時の革命的なシューティングゲームとして1980年の『ディフェンダー』と並び称される歴史的作品。
並ばねーよw
ディフェンダーに失礼。 グラディウスのストーリー自体はスターウォーズだな。
陳腐だけどw >>99
おれ、釣られたの?
某社のOSはオプソだから知ってるんだよ。