こんにちは、Cygames Research の多胡です。これまで10年以上コンソールゲーム開発を行ってきていて、最近ではハイエンドゲームエンジンを制作しておりました。Cygames でもハイエンドゲームエンジンの開発に携わることになりました。 ゲームエンジン開発を行う上で重要な考え方にデータ指向設計 (Data Oriented Design) というものがあります。今回はこのデータ指向設計を例を交えながら紹介させていただきます。 背景 データ指向設計の考え方は 2009年頃から有名になりました。 この 30年で CPU の性能は1万倍以上になりましたが、メモリの転送速度は10倍にもなっていません。そのため、プログラムのボトルネックはメモリ帯域となることが多くなりました。ゲームにおいても CPU はほとんどの時間がメモリからのデータの転送待ちになっています。CPU の性能を引き出すために
今日はPHP界隈で大人気のDependency Injectionと、それに関連する用語について整理しておこうと思います。 以下のような状況があるのではないか?と思ったからです。 多くのPHPユーザがDependency Injection(DI)をよくわかっていない、あるいは正確に説明できません。 そして、デザインパターンである「DIパターン」とDIをサポートするツールである「DIコンテナ」を混同しています。 また、「DIパターン」と「サービスロケータパターン」をうまく区別できていません。 Dependency Injectionとは何か? Dependency Injectionとは「Dependency」を「Injection」するというデザインパターンです。 日本語では何故か「依存性の注入」と訳されており、これが混乱の元ではないかと思います。 日本語で「依存性」と言うと、「依存性は
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
想像してください。あなたは今、オフィスにいます。周りとは仕切られた個別スペースです。今週は、近々新たに展開する予定の製品を紹介するために多くの時間を割いてきました。疲れが溜まり、不機嫌ぎみになっています。今はようやく近づいた週末が待ち遠しくて仕方ありません。 しかしその前に、新製品を紹介するホームページがWindows 10で正常に動かくかどうかを試してみなければなりません。あなたは問題ないはずだと信じています。あなたが信頼を寄せているMacには、Windowsを問題なく実行できるソフトもインストールされています。 ソフトを起動してみると、丁寧にもWindowsがポップアップ通知で可能なアップデートがあることを知らせてくれます。もちろんアップデートを開始するため、あなたは了承します。 すると、こんなものを目にするのです。 訳:何かが発生しました。 何かが発生。 新製品の準備のため期限が迫っ
それとも、”私はデザイナーなので、そんなことを知る必要はありません”と言い張るのか 私の職業はデザイナーです。私はエンジニアが好きです。ちょっと度が過ぎるくらい好きかもしれません。以前、Facebookの グループ に参加した時、かなり前からチームのメンバであるiOSのエンジニアと初めて話して、口から泡を吹いたことを思い出します。私はその時、これまでに自分がObjective-Cでコーディングしたものについて、勢い込んで話し始めました。まるで、高校の新入生が、上流階級の生徒に対して、自分が付き合う価値のあるカッコいい人間だと証明しようとしているみたいだと感じました。 デザイナーの多くが、エンジニアとの話し合い方を実はよく分かっていないと思います。もちろん、デザイナーはエンジニアと話しますが、本当の意味で関わろうとしていません。この記事を書いた理由はそこにあります。ソフトウェアエンジニアの懸
2014/10/26 UIデザイナー不要説 最近UIについてもやもやしていることがあるので書く。間違った知識もあるかもしれない。 先日UI CrunchというUIの勉強会のようなものが開催され、僕はschooの動画配信を見ていたのだが、どうも根底に「UIデザインの重要性が日本では認知されていない」という共通認識が流れているように思える発表が多かった。デザイナー生存戦略やエンジニアとうまく付き合う方法等…。 僕も前のブログ(UID Lab)でそのようなことを訴えてきたので、あぁ、やっぱりみんな不安なんだなあと思ったが、逆説的に「僕らデザイナーが信じているUIデザインの価値なんて、本当は虚像なんじゃないか?」ということを疑ってみたい。 そもそも、なぜみんな「UIデザインが重要視されていない」と感じるのだろう?自分が日頃感じることを列挙してみる。 UIデザインが重要視されていないと思う理由 1.
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
Cocoa iOS デザインパターン どうも今のインターネット※の上ではMacよりも、iOSのコードやフレームワークを前提にした話が多いせいか、“Cocoa” という言葉を見なくなってきたように見えるのは、iOS前からCocoaを書いてきた人間にとっては少し悲しいことである。 そんなことはどうでも良くて、最近他人の書いたiOSのコードをよく見るのだが、その書き方、クラスの切り方、命名規則、カテゴリの使い方、継承の使い方、デリゲートなど各種パターンの使い方などなどその差は千差万別である。最初にCocoaを使ったという人は希少で、その大半は以前にC#, Java, Ruby, Python, PHPやそれらでよく使われているフレームワークを使っているがゆえ、CocoaらしいCocoaを書いている、書けている、または意識している人は少ないかもしれない。 Cocoa的な書き方は何で正解であるかとい
A JavaScript pattern and antipattern collection that covers function patterns, jQuery patterns, jQuery plugin patterns, design patterns, general patterns, literals and constructor patterns, object creation patterns, code reuse patterns, DOM and browser patterns (upcoming). Patterns collected while developing 喜感网. General Patterns Function Declarations - creating anonymous functions and assigning t
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう? と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET/.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
比較は実はナンセンス デザイナーはコードが書けたほうが良いのか? ハイブリッドなのか専門家なのか・・・長く議論されてきているトピックのひとつです。Webデザインの分野でもデザイナーは HTML / CSS / JavaScript くらい出来た方が良いのでは?という意見がありますし、最近では UI デザイナーが Object-C や Java を学んだほうが良いのでは?という意見もあります。 デザイナーがコードの領域に踏み込めるようになることで、インタラクションや画面遷移など、見た目だけでなく細かい動きの制御の設計に直に触れることが可能になります。コードから物事が見れるようになることで、初めて視覚化・具体化できるアイデアもあるでしょう。では、コードも書けるハイブリッドデザイナーのほうが優れているのかといえば、答えは「YES」であり「NO」でもあります。多くの技能をもつということは、何でも屋
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く