メッセージベースによるゲーム駆動
みなさま、こんにちは！ Cygames Research 所属、エンジニアの和泉澤と申します。 ゲーム業界歴20数年。メガドライブの時代よりゲームプログラミング一筋です。 時折、幾つかの知見をご紹介させて頂けましたらと思います。 ゲーム制作における内部実装には、古今東西、様々な方法論が存在しています。 アクション、RPG、カードゲームやアドベンチャーゲーム等、そのジャンルにより採択される方法は多種多様でありますが、制作するゲームの持つ特徴を良く理解し、そのゲームに適した設計を行うことは、ある種、ゲームプログラミングにおける醍醐味とも言えましょう。 アクションならばこの実装方法、RPGならばこれ、等といったような一意の方法論は勿論在りません。しかしながら、ゲーム業界黎明期より無数に生み出されたゲーム制作の歴史の上に、効率的な方法論というものは、ある程度通例として積み上げられています。 極シン
プログラムの依存関係とモジュール構成のこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさん、メンテナンスしやすいプログラムにするための設計に苦労してませんか？ 次々と現れるフレームワークやデザインパターンに振り回されてませんか！？ プログラムの設計については、パターン周りを中心に長い間多くの人を悩ませているように見えます。例えば MVC などは 1980 年代からあるものなのに、未だに定期的に議論に上がったり改善されたパターンなどが提案されたり、それを元にしたフレームワークが現れたりします。 僕もそういった設計に悩んだ(でる)一人なのですが、最近は新しいパターンも大事とは思いつつも単純に依存関係をきちんとコントロール
小さく始める isomorphic module pattern - Qiita
せっかく window や node/io の標準モジュールに依存していないロジックであれば、 ブラウザでも node/io で動くようにしておくと色々嬉しい。が軽視されている感がある。 俗に isomorphic な JavaScript と呼ばれている。 それを npm と bower で公開するのであれば、問題はモジュールシステムだ。 最小の isomorphic module pattern 一番シンプルで負荷の少ない方法。 まず、ライブラリを以下のように書く。 // lib.js function Lib() { // 変数は外に出さない } Lib.prototype.foo = function(){ return "foo"; }; this.Lib = Lib; // point
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
