1read 100read
2013年04月プログラム67: 任天堂「今後C++は捨てJavaScriptで開発していく」 (494) TOP カテ一覧 スレ一覧 2ch元 削除依頼
出されたお題をコーディングして罵られるスレ (251)
ふらっとVisual C#,C♯,C#(初心者用) Part103 (793)
Eclipse統合M34【Java/C++/Ruby/Python/Scala】 (309)
【JS,PHP,Python】スクリプト,バトルロワイヤル30【Perl,Ruby】 (1001)
Regular Expression(正規表現) Part11 (241)
スレ立てるまでもない質問はここで 126匹目 (367)

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


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

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

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

4 :
泥沼になりそう

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

6 :
速度出ないだろ

7 :
ソフトウェアの進化というのは
開発効率が高い遅い言語で
作りなおすことで進化しているのです。
どんどん遅い言語で作られるようになりますが
それこそ進化なのです。

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

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

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

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

12 :
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
                  京都大学霊長類研究所

13 :
開発効率そんなに違うか?

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

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

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

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

18 :
PHPde開発しようZE

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

20 :
JSエンジンが裸で載ってたらデバッグでRるな

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

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

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

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

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

26 :
>>23
またまたw

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

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

29 :
C#のが生産性高い

30 :
>>11
>HTML5のグラディウス完璧だったしな
コナミ社員の自作自演?w

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

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

33 :
小島はMSXユーザーw

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

35 :
>>1に釣られる間抜けな馬鹿に言っておくけど、
JavaScriptで開発をするとは書いてあるけど、
C++を捨てるなんて書いてないからねw
速度が必要なところだけC++を使えばいい。
それにJavaScriptのエンジンはオープンソースの速いやつを使うだろ。
JavaScript実行環境はオープンソースにしないといけないけれど、
それで動かすアプリはクローズドでいいわけだし。

36 :
これは極端な例だけどJSがダントツで早い状況もある
http://nothingcosmos.blog52.fc2.com/blog-entry-155.html
最近のJSエンジンは本当に凄い
JSの数値は64bit浮動少数だけどint型で扱える範囲の時はそれで計算するとかはもう普通
配列も入っている型やばらつきによってそれぞれ最適化される
もう単純演算じゃあ差は出ない
正規表現とか高級言語の方が扱いやすいものもある
当然WEBとの相性はいい
反対に苦手なのがバッファを弄る処理
まあ苦手と言ってもCほどトリッキーなことはできないレベル
元々JSはIO全般と相性が悪かったけど最近はマシになってきた

37 :
JSの速度のことを指摘している人は検討違い
JSの言語自体の問題は無い
あるのはアウトプットをどうするかということ
正直今のWeb技術はバリバリのゲームなんか想定してない
WEBにはオーバースペックだと度々言われるWebGLだって
コンシューマ機として考えたらOpenGL ES 2.0だからしょぼすぎる
WiiUのGPUとマッチしてないと思う
2DゲームだってCanvas2D+CSSだけじゃあ寂しすぎる
エフェクトとかがかけづらいからほとんどWebGL使うと思う
本気でやるんなら新しいCanvasのコンテキストを用意するのはもちろん
リアルタイムオーディオ系API、今ChromeとFirefoxで全然別なのが乗ってて合併中だけどそれをどうするのかも決めないと
細かいとこだけどHTML5のテンプレートとかCSSのシェーダーとか
今実験段階の機能も載せないとダメだと思う
WiiUがスタンダードを決めるくらいの勢いでいかないと成功しない
でもあくまでWeb技術だから無茶もダメ、
ブラウザはもちろん、今年から出てくるMobileWebOSのベンダー何かとも相談する必要あると思う
そういうことが任天堂にできるよう体制考えていくのかっていうのが大事
任天堂の一大プロジェクトとして頑張ってくれ

38 :
>>37
何いってんだお前?
ライブラリさえ用意すれば、JavaScriptから
ファイルアクセスだってDirectX(Windowsの場合)だって
使えるんだよ。
Nodeなんかそうじゃん。言語はJavaScript
ライブラリはウェブ標準ではない。
JavaScript使うからってウェブ標準にする必要はない。

39 :
>>30
え?お前何言ってんの?

40 :
うわっ、コナミ社員w

41 :
>>38
だからそのライブラリを用意するのがものすごく大変だと言っている
せっかくWeb技術を使うんだからそれと全くかけ離れたものを作ってもしかたない
Node.jsはWeb技術(HTML)じゃない、JSだけ
それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている
それでもここまで来るのに何年もかかった
だけどまだNodeはバージョン0.10
フラッシュアップするのにもう1年はかかりそう
それほど大変
そんな中ゲームサイドを作ろうとしたらライブラリ作ればいいじゃすまない
任天堂だけの手におえないし、おってはいけない
それこそ仕様ができた頃にはWiiUの次がでてるようなことになる
それはさすがに無理だからWEB技術を中心に採用することにしたんだろう
でも採用するといっても使えそうな技術は実験段階だったり
標準化に手間取ってたりする
それを待ってるとやっぱりWiiUには間に合わない
でも既存のWEB技術だけじゃあ残念すぎる
なんとかそこら辺を上手くやらなくちゃいけない
じゃないともったいない

42 :
> だからそのライブラリを用意するのがものすごく大変だと言っている
今あるC++のライブラリのラッパーを作れば良い。

43 :
> それに完全独自じゃなくて他のサーバーサイドJS環境とともに標準仕様を決めている
CommonJSはオワコンで
参考にはするが、そんなのには従わないと
言ってるんだが知らないの?

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

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

46 :
>>42,43
今はCommonJS関係ないよ
でもそれが種だった
じぶんはv0.1代の頃から知ってたからよく分かる
それに少し考えてご覧
ほぼストリームのIOだけ提供すればいいサーバーサイドとはスケールが違い過ぎる
絵も音も出さなくちゃいけない
それらはバッファやストリームのラッパーを作ればいい次元じゃない
既存のを使えばいいとか無茶ぶりすぎる
それならそもそもなんのためにJavaScriptを使うのか
仮に既存のCのラッパー大量に用意してはいどうぞ
はて、Cで開発していた頃と何が違うのか
既存のWeb技術を利用でき既存のWebアプリ開発者でも参入できるからいいんじゃないか
それに仕様ってのは作ったはい終わりじゃすまない
それで済むのならHTML5だってもめてない
長い時間をかけて改善を繰り返さないと完成しないもの
そこまでしてゲームサイドJS環境を作れたとしてどんな意味があるのだろうか

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

48 :
> それらはバッファやストリームのラッパーを作ればいい次元じゃない
え? なんで?
根拠が無いなぁ(笑)

49 :
実行効率じゃなくて開発効率が悪いからかんべんしてほしいわ。
function hoge(x) {
x.maxLength = 100;
}
↑これをスペルミスで
function hoge(x) {
x.maxlength = 100;
}
↑と書いてもエラーにならないで、なんとなく動いちゃう言語。

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

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

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

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

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

55 :
実装詳細ってなんだ?
公開プロパティだろ?
それともメソッドにすれば解決する問題だと思ってるのか?

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

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

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

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

60 :
>>56
恥かいたのはお前だったなw

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

62 :
いまどきメモ帳でコード書くわけじゃあるまいし
最底辺プログラマが書くC++よりは安全だろう

63 :
IDEのサポートが弱いのもダメだな。
動的型.vs.静的型の議論で「動的は簡単に書けて生産性が高い、
静的は安全に書けます。適材適所で使いましょう」みたいな大人の
意見を言うやつがいるけど、ぜったい動的は生産性低いだろ。

64 :
>>61
seal()で、どうやって>>49の問題を防ぐつもりなの?

65 :
>>63
つ TypeScript

66 :
>>64
>>49の問題って何?

67 :
>>65
そういうのが出るってことは、やっぱ動的型の言語に問題感じてる人は多いんだろうな。

68 :
javascriptが速いのはx86とarmだけ

69 :
>>66
> >>49の問題って何?
まんまその通りだけど。
・スペルミスしたときに
・と書いてもエラーにならない
・なんとなく動いちゃう

70 :
それ以外はwebいらないってことで

71 :
>>69
今度は、Object.seal()の機能をここにコピペしてみてよ。

72 :
>>71
Object.seal()の機能は知ってるから、どうやって>>49の問題を防ぐつもりなのかだけ教えてくれればいいから。

73 :
正直ゲームなんて多少変な挙動あっても適当に動いてりゃ許されるだろ
バグまみれでも大して問題にならないのってゲームプログラムだけだよね

74 :
もうおしまいだ〜!!
C++はおしまいだ〜〜!!

75 :
>>73
ゲームの方が、(精神的な)子供が多いから大問題になる気がするが

76 :
>>72
Object.seal()の機能に、
>>69の問題を防ぐって書いてあるじゃん。
読んでないだろお前。

77 :
>>76
> Object.seal()の機能に、
> >>69の問題を防ぐって書いてあるじゃん。
そうは思えないから、どうやって防ぐのか質問してるんだけど。
コード書いてよ。

78 :
>>45
>HTML5のグラディウスがコナミだとか
>スーパーマリオ知らんってどんだけ情弱なんだよw
もうみんなすごーいんだよーーー

ムダな努力w

79 :
http://appsweets.net/gradius/index.html
とりあえずこのグラディウスを遊んでみてくれたまへ

80 :
>>79
キーマトッリクスが不完全。

81 :
コナミがここまでグラディウスに執着してるとは思わなかったなw

82 :
断続的にガクガクになるのは、俺のPCがしょぼいせいか?

83 :
だからこれコナミじゃないってw

84 :
>>36
なぜ?という部分を解明してないと
学術論文的な所では確実に無視される
その程度の内容
そもそも、まともなソースコードすら示していないいw

85 :
>>81
是非とも横スクロール・オプション・レーザー付シューティング製作を!

86 :
ナムコナミ

87 :
1面しか遊べないジャン

88 :
パフォーマンス的にやば過ぎるなこれ
こんなの客に出したら社会問題になるな

89 :
>>85
1985年から28年間独裁してるから倒さなきゃな。

90 :
>>28
こいつ最高に低能

91 :
俺の知ってるニンテンドーのOSはCOMライクな作りでJSインターフェース持ってたよ。
それでブラウザ独自実装してたぞ。

92 :
馬鹿丸出しw

93 :
俺?

94 :
>>85
>是非とも横スクロール・オプション・レーザー付シューティング製作を!
コナミの真似をすれば馬鹿と思われるから誰もしないだけw

95 :
本物グラディウスのソースリストいる?
C言語ソースと68000ライブラリ。

96 :
>>95
それって、今から読んでもちゃんと読める?っていうか、アホでもよめる??
あと、著作権大丈夫?

97 :
>当時の革命的なシューティングゲームとして1980年の『ディフェンダー』と並び称される歴史的作品。
並ばねーよw
ディフェンダーに失礼。

98 :
グラディウスのストーリー自体はスターウォーズだな。
陳腐だけどw

99 :
>>96



100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
【JS,PHP,Python】スクリプト,バトルロワイヤル30【Perl,Ruby】 (1001)
【JS,PHP,Python】スクリプト,バトルロワイヤル30【Perl,Ruby】 (1001)
Win32API質問箱 Build114 (232)
ふらっとVisual C#,C♯,C#(初心者用) Part103 (793)
Regular Expression(正規表現) Part11 (241)
Win32API質問箱 Build114 (232)
--log9.info------------------
【ラブライブ!】南ことりちゃんはとさかが可愛い4本目 (670)
【ガールズ&パンツァー】西住みほは実力があります可愛い6輌目 (544)
【宇宙兄弟】アポは宇宙犬かわいい【アポロ1号】 (346)
【たまゆら】沢渡楓は、なので可愛い #3 (974)
【ソ・ラ・ノ・ヲ・ト】クレハは百発百中スナイパー6 (284)
【聖闘士星矢Ω】ユナは女聖闘士5 (292)
【咲-Saki-】松実玄はわきわき可愛い ドラ10【阿知賀編】 (362)
【DBZ】伝説の超サイヤ人ブロリー123【うわへへ】 (1001)
ToLOVEる-とらぶる-モモ・ベリア・デビルークに萌えるスレ3 (419)
【僕は友達が少ないNEXT】高山マリアはポテチ大好きかわいい (301)
【ラブライブ!】星空凛は2スレ目で感動できるなんて羨ましいにゃ〜 (638)
【咲-Saki-】松実宥はメガネも可愛い5枚目【阿知賀編】 (785)
【遊戯王ZEXAL】トロン一家XWV【名74さん、潰れちゃいな】 (1001)
【超速変形ジャイロゼッター】稲葉りんねはイナバウワー可愛い (878)
【スマイルプリキュア!】星空みゆき/キュアハッピー42 (370)
【ストライクウィッチーズ】エイラは本国からも祝われ愛され娘ワイイ111 (383)
--log55.com------------------
スノーボードブーツ総合スレ☆5
【悲報】平野歩夢が風評被害
【S-air】ウォータージャンプ総合【O-air K-air】
【上級者の】SAJ2級受験スレ13【入り口】
【チヤーン規制】 関越高速道路 20
[快適] FFヒーター総合 - 2泊目 [車中泊]
【100mm】最強のファットスキーを語れYo!37【Over】
バックカントリースキーの装備 14