任天堂「今後C++は捨てJavaScriptで開発していく」

**デフォルトの名無しさん** · 2013/03/20(水) 13:07:40.60

任天堂のゲームはこれまで，CやC＋＋といったプログラミング言語で開発されており，
そのため高いパフォーマンスを発揮していたが，反面，開発に時間がかかっていたという。
このセッションではそれ以外の方法，つまりHTMLやJavaScriptを使ってWii Uの全機能にアクセスしつつ，
より手軽にゲーム開発を行う方法が説明されるようだ。
http://www.4gamer.net/games/999/G999905/20130316001/

**デフォルトの名無しさん** · 2013/03/20(水) 13:09:11.52

JavaScriptは開発効率高いからな。

**デフォルトの名無しさん** · 2013/03/20(水) 13:10:03.88

JavaScriptはC言語の皮をかぶったマクロの無いLisp

**デフォルトの名無しさん** · 2013/03/20(水) 13:11:39.86

泥沼になりそう

**デフォルトの名無しさん** · 2013/03/20(水) 13:14:14.64

Javaと勘違いしてる輩が乱入、に1ペリカ。

**デフォルトの名無しさん** · 2013/03/20(水) 13:14:38.07

速度出ないだろ

**デフォルトの名無しさん** · 2013/03/20(水) 13:15:55.26

ソフトウェアの進化というのは
開発効率が高い遅い言語で
作りなおすことで進化しているのです。

どんどん遅い言語で作られるようになりますが
それこそ進化なのです。

**デフォルトの名無しさん** · 2013/03/20(水) 13:21:28.27

HTMLとJavascriptで新作マリオ出してくれたら信用する

**デフォルトの名無しさん** · 2013/03/20(水) 13:32:02.93

過去ソース使えねえな
移植効率悪そう

**デフォルトの名無しさん** · 2013/03/20(水) 13:56:05.94

捨てるとは書いてないべ
Javascript のインタフェースを用意してみたんだけど使ってみてくんない？
って感じじゃないのか
モバグリの開発者を囲い込む戦略なんじゃね

**デフォルトの名無しさん** · 2013/03/20(水) 15:28:30.40

HTML5のグラディウス完璧だったしな
そこそこの物は作れるんじゃないか

**デフォルトの名無しさん** · 2013/03/20(水) 15:34:12.88

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

**デフォルトの名無しさん** · 2013/03/20(水) 17:33:33.34

開発効率そんなに違うか？

**デフォルトの名無しさん** · 2013/03/20(水) 18:38:38.33

レスポンス返って来なかったりメモリ不足がほぼ出ないようなシステムなら問題ないんだけどな

**デフォルトの名無しさん** · 2013/03/20(水) 19:56:32.10

任天堂のゲームでそんなに高いパフォーマンスが必要だったものあったっけ
Cでマリオ作るの非効率だからやめるよ！ってだけの話じゃないの

**デフォルトの名無しさん** · 2013/03/20(水) 20:15:20.73

C++とJavascriptだったら
どっちが開発し易いか微妙なレベル
速度は確実にC++だけど

**デフォルトの名無しさん** · 2013/03/20(水) 20:16:04.23

まだアセンブラだと思ってた

**デフォルトの名無しさん** · 2013/03/20(水) 20:45:31.85

PHPde開発しようZE

**デフォルトの名無しさん** · 2013/03/20(水) 22:00:44.49

>>16
そう思っててくれたほうが助かる。

**デフォルトの名無しさん** · 2013/03/20(水) 23:03:18.02

JSエンジンが裸で載ってたらデバッグで死ねるな

**デフォルトの名無しさん** · 2013/03/21(木) 02:27:50.15

Javascriptでインタープリタなテスト工程を経て、
C/C++に落としてくれる環境ならば賛同する。
(本番はCPUに近いNativeで。)

**デフォルトの名無しさん** · 2013/03/21(木) 05:29:51.19

アセンブラでマリオ作ろう

**デフォルトの名無しさん** · 2013/03/21(木) 06:03:03.23

ビックリするかもしれないけどいまやJavaScriptのコードは平均してJAVA並の速度なんだよね
ループ内のコードを外に出したり、ハイコンテキストなのを逆に利用して効率のよいマシン語にすることができる

**デフォルトの名無しさん** · 2013/03/21(木) 06:09:40.04

まぁ開発効率は高いわなぁ。スクリプトエンジンはどんどん高速になってるし

**デフォルトの名無しさん** · 2013/03/21(木) 06:18:14.60

ブラウザ戦争のお蔭でとんでもない速度で最適化が進んだからなあ

**デフォルトの名無しさん** · 2013/03/21(木) 07:10:15.23

>>23
またまたｗ

**デフォルトの名無しさん** · 2013/03/21(木) 07:19:50.47

早いって言ってもスクリプトエンジン次第だぞ？
任天堂自前で作るのか？

**デフォルトの名無しさん** · 2013/03/21(木) 07:43:25.78

>>23
全然びっくりしないかもしれないけど
速いJavascriptエンジンはC++で書かれてるんだぜ

**デフォルトの名無しさん** · 2013/03/21(木) 08:24:57.07

C#のが生産性高い

**デフォルトの名無しさん** · 2013/03/21(木) 08:46:25.26

>>11
>HTML5のグラディウス完璧だったしな

コナミ社員の自作自演？ｗ

**デフォルトの名無しさん** · 2013/03/21(木) 08:48:45.49

いつまでもグラディウスにすがるコナミみっともない

**デフォルトの名無しさん** · 2013/03/21(木) 08:50:15.82

MSX最大のネガキャンプロデューサー、コナミｗ

**デフォルトの名無しさん** · 2013/03/21(木) 08:50:55.03

小島はMSXユーザーｗ

**デフォルトの名無しさん** · 2013/03/21(木) 09:07:48.49

ブラウザゲームに速度は必要ないし良い判断だろ
ブラウザゲームに特化するのは良い判断とは思えないけどな

**デフォルトの名無しさん** · 2013/03/21(木) 09:50:52.62

>>1に釣られる間抜けな馬鹿に言っておくけど、
JavaScriptで開発をするとは書いてあるけど、
C++を捨てるなんて書いてないからねｗ

速度が必要なところだけC++を使えばいい。

それにJavaScriptのエンジンはオープンソースの速いやつを使うだろ。
JavaScript実行環境はオープンソースにしないといけないけれど、
それで動かすアプリはクローズドでいいわけだし。

**デフォルトの名無しさん** · 2013/03/21(木) 09:59:39.05

これは極端な例だけどJSがダントツで早い状況もある
http://nothingcosmos.blog52.fc2.com/blog-entry-155.html

最近のJSエンジンは本当に凄い
JSの数値は64bit浮動少数だけどint型で扱える範囲の時はそれで計算するとかはもう普通
配列も入っている型やばらつきによってそれぞれ最適化される
もう単純演算じゃあ差は出ない

正規表現とか高級言語の方が扱いやすいものもある
当然WEBとの相性はいい

反対に苦手なのがバッファを弄る処理
まあ苦手と言ってもCほどトリッキーなことはできないレベル
元々JSはIO全般と相性が悪かったけど最近はマシになってきた

**デフォルトの名無しさん** · 2013/03/21(木) 10:26:39.28

JSの速度のことを指摘している人は検討違い
JSの言語自体の問題は無い

あるのはアウトプットをどうするかということ
正直今のWeb技術はバリバリのゲームなんか想定してない

WEBにはオーバースペックだと度々言われるWebGLだって
コンシューマ機として考えたらOpenGL ES 2.0だからしょぼすぎる
WiiUのGPUとマッチしてないと思う

2DゲームだってCanvas2D+CSSだけじゃあ寂しすぎる
エフェクトとかがかけづらいからほとんどWebGL使うと思う

本気でやるんなら新しいCanvasのコンテキストを用意するのはもちろん
リアルタイムオーディオ系API、今ChromeとFirefoxで全然別なのが乗ってて合併中だけどそれをどうするのかも決めないと

細かいとこだけどHTML5のテンプレートとかCSSのシェーダーとか
今実験段階の機能も載せないとダメだと思う

WiiUがスタンダードを決めるくらいの勢いでいかないと成功しない
でもあくまでWeb技術だから無茶もダメ、
ブラウザはもちろん、今年から出てくるMobileWebOSのベンダー何かとも相談する必要あると思う

そういうことが任天堂にできるよう体制考えていくのかっていうのが大事
任天堂の一大プロジェクトとして頑張ってくれ

**デフォルトの名無しさん** · 2013/03/21(木) 10:41:53.37

>>37
何いってんだお前？

ライブラリさえ用意すれば、JavaScriptから
ファイルアクセスだってDirectX（Windowsの場合）だって
使えるんだよ。

Nodeなんかそうじゃん。言語はJavaScript
ライブラリはウェブ標準ではない。

JavaScript使うからってウェブ標準にする必要はない。

**デフォルトの名無しさん** · 2013/03/21(木) 10:43:35.83

>>30
え？お前何言ってんの？

**デフォルトの名無しさん** · 2013/03/21(木) 10:51:52.51

うわっ、コナミ社員ｗ

**デフォルトの名無しさん** · 2013/03/21(木) 10:58:08.26

>>38
だからそのライブラリを用意するのがものすごく大変だと言っている
せっかくWeb技術を使うんだからそれと全くかけ離れたものを作ってもしかたない

Node.jsはWeb技術(HTML)じゃない、JSだけ
それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている
それでもここまで来るのに何年もかかった
だけどまだNodeはバージョン0.10
フラッシュアップするのにもう１年はかかりそう
それほど大変

そんな中ゲームサイドを作ろうとしたらライブラリ作ればいいじゃすまない
任天堂だけの手におえないし、おってはいけない
それこそ仕様ができた頃にはWiiUの次がでてるようなことになる

それはさすがに無理だからWEB技術を中心に採用することにしたんだろう
でも採用するといっても使えそうな技術は実験段階だったり
標準化に手間取ってたりする
それを待ってるとやっぱりWiiUには間に合わない

でも既存のWEB技術だけじゃあ残念すぎる
なんとかそこら辺を上手くやらなくちゃいけない
じゃないともったいない

**デフォルトの名無しさん** · 2013/03/21(木) 11:00:53.73

> だからそのライブラリを用意するのがものすごく大変だと言っている

今あるC++のライブラリのラッパーを作れば良い。

**デフォルトの名無しさん** · 2013/03/21(木) 11:02:41.38

> それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている

CommonJSはオワコンで
参考にはするが、そんなのには従わないと
言ってるんだが知らないの？

**デフォルトの名無しさん** · 2013/03/21(木) 11:21:23.46

C++はもうお荷物になってきたか

**デフォルトの名無しさん** · 2013/03/21(木) 11:22:04.14

HTML5のグラディウスがコナミだとか
スーパーマリオ知らんってどんだけ情弱なんだよｗ

**デフォルトの名無しさん** · 2013/03/21(木) 11:26:22.34

>>42,43
今はCommonJS関係ないよ
でもそれが種だった
じぶんはv0.1代の頃から知ってたからよく分かる

それに少し考えてご覧
ほぼストリームのIOだけ提供すればいいサーバーサイドとはスケールが違い過ぎる
絵も音も出さなくちゃいけない
それらはバッファやストリームのラッパーを作ればいい次元じゃない

既存のを使えばいいとか無茶ぶりすぎる
それならそもそもなんのためにJavaScriptを使うのか
仮に既存のCのラッパー大量に用意してはいどうぞ
はて、Cで開発していた頃と何が違うのか
既存のWeb技術を利用でき既存のWebアプリ開発者でも参入できるからいいんじゃないか

それに仕様ってのは作ったはい終わりじゃすまない
それで済むのならHTML5だってもめてない
長い時間をかけて改善を繰り返さないと完成しないもの

そこまでしてゲームサイドJS環境を作れたとしてどんな意味があるのだろうか

**デフォルトの名無しさん** · 2013/03/21(木) 11:36:14.49

でもそれが種だった
でもそれが間違いだってわかった。
二度と同じ事を繰り返すことはないだろう。

**デフォルトの名無しさん** · 2013/03/21(木) 11:36:52.80

> それらはバッファやストリームのラッパーを作ればいい次元じゃない

え？なんで？
根拠が無いなぁ（笑）

**デフォルトの名無しさん** · 2013/03/21(木) 11:59:19.32

実行効率じゃなくて開発効率が悪いからかんべんしてほしいわ。

function hoge(x) {
x.maxLength = 100;
}
↑これをスペルミスで

function hoge(x) {
x.maxlength = 100;
}
↑と書いてもエラーにならないで、なんとなく動いちゃう言語。

**デフォルトの名無しさん** · 2013/03/21(木) 12:00:12.97

時間がかかるのは標準技術だから
独自技術なら時間はかからない。
現にゲーム業界の速度は、標準技術を確立する速度を超えている。

**デフォルトの名無しさん** · 2013/03/21(木) 14:05:14.51

JavaScriptつーかECMAScriptでstrictモード対応なら>>49みたいな心配はいらないんだけどなぁ

**デフォルトの名無しさん** · 2013/03/21(木) 14:07:44.88

C++を捨てる、なんてどこにも書かれてないな。
こういう釣りは、ゲハとかそっちの方面でやってくれ。

**デフォルトの名無しさん** · 2013/03/21(木) 14:39:13.62

>>51

>>49の例はstrictモードでも防げないだろ

**デフォルトの名無しさん** · 2013/03/21(木) 14:42:39.98

そもそも>>49はhoge()がオブジェクトxの実装詳細を知っているのが前提という糞設計なのが問題

**デフォルトの名無しさん** · 2013/03/21(木) 14:45:41.46

実装詳細ってなんだ？
公開プロパティだろ？

それともメソッドにすれば解決する問題だと思ってるのか？

**デフォルトの名無しさん** · 2013/03/21(木) 14:49:40.74

>>55
> 公開プロパティだろ？
Javascript知らないのがバレバレ

**デフォルトの名無しさん** · 2013/03/21(木) 14:54:09.76

メソッド(setter/getter)にすれば、少なくとも「なんとなく動いちゃう」は防げるだろ
ただし、それがJavaScript的なお作法に適合するのかどうかはわからんが

**デフォルトの名無しさん** · 2013/03/21(木) 14:55:28.39

あ、typoが問題じゃ無くて、外部から新たなプロパティを設定できてしまうのが問題なのか
だったら、俺はその防ぎ型を知らんわ

**デフォルトの名無しさん** · 2013/03/21(木) 15:09:05.85

>>55
他言語だって、変数を公開して、外で自由に触らせるのは良くない設計だよ？

**デフォルトの名無しさん** · 2013/03/21(木) 15:24:26.71

>>56
恥かいたのはお前だったなｗ

55 · 2013/03/21(木) 15:29:18.67

こういう時のために、Object.seal()があるんだよ
無知どもめ。