はてなブックマーク

近年の大規模プログラム開発環境では、ソースコードを共有する前にlinterと呼ばれるツールを使ってコード検証をするのが一般的です。linterでは決められたコーディングルールに沿っているかについて、コンパイラよりも厳格なチェックを行い、場合によっては自動的に修正してくれます。ちなみに「linter」という名称はUNIXのlintコマンドから来ていて、"lint trap（洗濯機に取り付けてある「糸くず("lint")取り」の事）"に由来しているそうです*1。 github.com textlintは、自然言語で書かれたテキスト用のlinterとして提供されているツールです*2。提供されている様々なルールを組み合わせて、テキストを検証する事が出来ます。 textlintはnode.js上で動くjavascriptのアプリで、独自のルールを作成してツールに組み込む事も出来ます。新規作成をサポー

Unity UI(≒uGUI≒Canvas)って「あるタイミングでがっつり弄って、終わるとまたしばらくは使わない」ということが多く、久し振りに触るとルールをまるっと忘れてる印象があります。 特に覚えられないのがAnchorsとPivotの相互関係で、ドキュメントを読んでもエディタで弄っても毎回腑に落ちないまま、試行錯誤してるうちに上手く行っちゃって「まあできたからいいか……」とよくなる（土屋だけ？）。 ネットでも役に立つ情報が分散してて見通しが悪かったので、今回チートシートを作りました。 #unity RectTransform(Canvas)のAnchrosとPivotの相互関係チートシート（ver2.0） 更新履歴 ver2.0 20210213 AnchorsとPivotの説明を追加。ほぼ完成形と思われる。 W Delta/H Deltaについて RectTransformを持つゲー

Unityでローカルにセーブデータファイルを保存したい時に、毎回やり方を失念してしまい、「あれ？　どこに保存すればいいんだっけ？　ＡＰＩは何を使うんだっけ？」となってネットを漁ることになり非効率なので、また忘れても大丈夫なように、ここに「Unityセーブデータ実装３原則」を残しておきます（実際にどんなデータを保存するのかはまた別の話なので触れてません）。 あくまで土屋が考えている原則で、より正しい／より効率的な手法があるかもしれません（あったら是非コメントで教えてください）。 原則１：セーブデータの保存目的ではPlayerPrefsは使えない 多くのUnityの記事では、ゲームデータのセーブにPlayerPrefsを使うように書いてあるものが多いかと思いますが、PlayerPrefsは大規模なゲームデータの保存目的には適していません。 適さない理由は「Windows環境ではPlayerPr

UnityにおけるＧＩ（Global Illumintaion. 大域照明）は、"Baked GI"という、ビルド時（あるいはもっと前）にシーンの間接光を計算し、そのカラー値をライトマップと呼ばれるテクスチャに書き込む（「ベイクする（焼き付ける）」と言います）物を指します。間接光の計算には膨大な演算が必要で、毎フレーム計算するのは無理ゲーなので、ビルド前にベイクしておくわけです。 とはいえ、ベイクしたライトは当然動かせないので、これでは「間接光を生み出すが、動く光源」を上手く表現できません（よく例で出されるのは太陽です）。そこで、UnityではEnligten（※１）というミドルウェアを使用する"Precomputed Realtime GI"というモードがあり、制限はあるものの、リアルタイムでの間接光計算を提供しています。「事前計算されたリアルタイムＧＩ」と訳されます。 「毎フレーム計算

これまで食わず嫌い的に３Ｄプログラミングを避けて通ってきたこともあって、「こういう処理は３Ｄプログラミングでは通常こういうアプローチを取る」というのがわからず、難しいことではないのに解法にたどりつけない事がよくあります。今回もそのパターンの一つ。 キャラモデルの肌のテクスチャに、例えばホクロとかタトゥーとかを重ねて表示したい時があります（ありますよね？）。このような描画処理のことを「デカール」といいます。このデカール処理をUnityで実現するにはどうすれば良いでしょうか。 UnityのスタンダードシェーダーにはSecondery Mapsというパラメーターを使って２枚目のテクスチャを指定する機能があります。しかしこの機能はDetail map（詳細マップ。肌の質感などを表現するためにディティール用のテクスチャを重ねる技法）での使用が前提とされていて、設定できるテクスチャマップに制限がありま

tsukasaスクリプトをC#コードに変換するトランスパイラを作っています。当初はrubyのparsletで書こうと思っていたのですが、parsletが気軽に動かせる代わりに字句解析器と構文解析器が分離していない点や、C#のプロジェクトに統合できない点から中止し、ANTLR4を使うことにしました。 ANTLR4はJava製のパーサージェネレーターで、C#用のコードも生成できる上に、VisualStudio上でシームレスに動作させるプラグインまで用意されています。これは簡単！　……という感じにはいかず、ひとまず動くまでかなり苦労したのでメモ（いずれちゃんと一つの記事にします）。 基本はこちらの記事の流れでいけば動きます。 (01)ANTLR4をC#で使ってみる https://sites.google.com/site/hobbyprogrammingroom/game/gamescript

１０月２２日に開催される技術書オンリー即売会「技術書典３」にて、「Unityシェーダープログラミングの教科書 ShaderLab言語解説編」を初頒布します。表紙は盟友のふゆの春秋さんに描いて頂きました。「若者（学生）が武器（Unity）を手にした」というモチーフとのことです。 また、「地方で技術書典に参加できないが欲しい」という要望を多数いただいたので、ＢＯＯＴＨにてＰＤＦ版の頒布を行うことにしました（期間限定の予定です。終了日は今のところ未定）。こちらは先行して公開を開始しており、下記サイトで購入＆ＤＬできます。 https://s-games.booth.pm/items/660001 何度か書いていますが、シェーダープログラミングは前提として必要な知識が非常に多く、それもあって本書は初心者向きとは言い難いです。また、読み終えたらすぐにシェーダープログラミングが出来るようになるという類

前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（ http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 ）」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案１：マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理Ａ }　"1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑

土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード１行ごとにコメントを書きたいくらいです（本当は、識別子を全部日本語で書きたいと思っているのですが、これはまた別の話）。 これは土屋がPDL（Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... ）開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日本人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より本質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき（≒正しく実装されたコードであれば、コメントは最低限になる）」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「本質的

土屋つかさが書いた「ゲームプログラミングにユニットテストを導入する本」ＰＤＦ版を無料公開します。以下のＵＲＬからどうぞ。 ゲームプログラミングにユニットテストを導入する本（土屋つかさ著／Ｂ５／本文２６ページ） http://someiyoshino.main.jp/file/tsukasa/game_programming_and_unit_test.zip 本書は、２０１７年４月９日に開催される技術書オンリー即売会「技術書典２」にて頒布する予定の物のＰＤＦ版になります。 昨年末から延々やっていた司エンジンにテスティングフレームワークを導入する作業をまとめなおし、一般的なゲームプログラミングに対象を広げ、ユニットテストを知らないプログラマにも分かるように書き直した物です。短いのでさくっと読めるんでないかと思います。 調査時間が足りず書けなかったネタ（ファクトリーモデルとかＣＩとかより実践的

ツイッターのTLを眺めていたら、mirichiさんがVSCodeでrubyを動かしているのを見て「俺もやりたい！」となって試しにデバッグ出来るところまでやってみました。結構大変だったので試行錯誤の過程を記録しておきます。 Visual Studio Code、通称VSCodeはオープンソースで開発されているソースコードエディタです。 Visual Studio Code（via wikipedia） https://ja.wikipedia.org/wiki/Visual_Studio_Code 【注意！】下記記事を読んでいる事が前提です インストールに辺りこちらのサイトの2016年04月19日の記事を主に参考にさせて頂きました。ありがとうございます。 Visual Studio CodeによるRubyのデバッグ（via Developers.IO） http://dev.classmet

以前から気になっていたことの一つに「タスクシステムがギャラクシアン発祥というのは史実なのか？」という事があります。 https://twitter.com/t_tutiya/status/769879384811446272 そう言えば、アーケードゲーム初期にプログラミングで採用されていたアーキテクチャであるタスクシステムはギャラクシアンで初めて採用され、その後業界に広がったという話があるのだけど、実際ギャラクシアンを逆アセンブルしてもタスクシステムが出てこないという説もあって正確な歴史がわからない— 土屋つかさ (@t_tutiya) 2016年8月28日 タスクシステムとはなにか 「タスクシステム」というのは、最初期の商業アーケードゲームにおいて使われていたゲームアーキテクチャです。当時はアセンブリ言語でゲームが作られていて、当然オブジェクト指向のような考えもなかった中、画面上に何十個

DXRuby Advent Calender 2013 １２日目です。 １１日目はfourxzさんのRuby使ったことない人がDXRubyでゲームを作りたいのでIDE3つインストールしましたでした。ＲｕｂｙにはＷｉｎｄｏｗｓ用のまともなＩＤＥは無い物と思い込んでいたので、こんなに選択肢があるとは意外でした。これを機会に、試用してみたいと思います（デバッグトレースをＣＵＩでやる気にはなれなくて……）。 さて１２日目です。当初は別のエントリをアップする予定でしたが、DXRuby Advent Calenderのイベントを通じて、「ゲームプログラミング初心者は、意外とこういう所で躓くんじゃないか」と思い、２Ｄアクションゲームにおける衝突判定、特に、自キャラと障害物との衝突判定について、ざっくりまとめてみることにしました。 あくまで基本概念の説明であり、近代的なゲームプログラミングでは物理演算含め