サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「かわいい」
someiyoshino.info
導入 TwitterのTLでヤスハラユウジさんのポッドキャストが流れてきたので聞いてみました。 voicy.jp 「ゲームプログラミングでは例外処理の実装は不要なのでは?」というお題で、興味深く拝聴しました。7分弱の音源なのでみなさんも是非お聞きください。 内容について直接の意見はありません。土屋もUnityでコード書いている時にtry-catchを書く事は無いと思います。秒間60フレームで処理してる時にメモリ確保に失敗して例外が送出された時、対応しようがあるとはちょっと想像できません(例外処理してもしなくてもアプリは落ちるんじゃないかと思います)。 ただ、「try-catchを書かない事」と「例外処理をしない事」は別の話です。try-catchは例外処理という機構の一部に過ぎず、我々ゲームプログラマも日常的に例外処理コードを書いているんだよという話を書いておこうと思います。 例外処理≒実
2022年11月12日に公開2日目の「すずめの戸締まり」を鑑賞してきました。響きすぎて終盤でボロ泣きしました。人によってはとても苦しい映画かもしれないけど、出来れば前情報無しで見に行って欲しい作品です。 映画を観ていて、以前から思っていた新海誠監督の「表現に対する自覚」を再確認しました。これについては伏せったーでちょっと書いたのでこちらもどうぞ。「すずめの戸締まり」の完全ネタバレなので注意。 「すずめの戸締まり」での表現に対する自覚についてのメモ。鑑賞直後に感じた事を残して起きたいので初めて伏せったー使う。ほとんど推敲してないのでニュアンスだけ伝われば。完全にネタバレなのでまずは今すぐ見に行ってください頼む。https://t.co/DzbaxNqVyD— 土屋つかさ (@t_tutiya) 2022年11月12日 この伏せったーの文章を書いている時、同じ事を「天気の子」公開時にも書いた筈
近年の大規模プログラム開発環境では、ソースコードを共有する前に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でローカルにセーブデータファイルを保存したい時に、毎回やり方を失念してしまい、「あれ? どこに保存すればいいんだっけ? APIは何を使うんだっけ?」となってネットを漁ることになり非効率なので、また忘れても大丈夫なように、ここに「Unityセーブデータ実装3原則」を残しておきます(実際にどんなデータを保存するのかはまた別の話なので触れてません)。 あくまで土屋が考えている原則で、より正しい/より効率的な手法があるかもしれません(あったら是非コメントで教えてください)。 原則1:セーブデータの保存目的ではPlayerPrefsは使えない 多くのUnityの記事では、ゲームデータのセーブにPlayerPrefsを使うように書いてあるものが多いかと思いますが、PlayerPrefsは大規模なゲームデータの保存目的には適していません。 適さない理由は「Windows環境ではPlayerPr
UnityにおけるGI(Global Illumintaion. 大域照明)は、"Baked GI"という、ビルド時(あるいはもっと前)にシーンの間接光を計算し、そのカラー値をライトマップと呼ばれるテクスチャに書き込む(「ベイクする(焼き付ける)」と言います)物を指します。間接光の計算には膨大な演算が必要で、毎フレーム計算するのは無理ゲーなので、ビルド前にベイクしておくわけです。 とはいえ、ベイクしたライトは当然動かせないので、これでは「間接光を生み出すが、動く光源」を上手く表現できません(よく例で出されるのは太陽です)。そこで、UnityではEnligten(※1)というミドルウェアを使用する"Precomputed Realtime GI"というモードがあり、制限はあるものの、リアルタイムでの間接光計算を提供しています。「事前計算されたリアルタイムGI」と訳されます。 「毎フレーム計算
これまで食わず嫌い的に3Dプログラミングを避けて通ってきたこともあって、「こういう処理は3Dプログラミングでは通常こういうアプローチを取る」というのがわからず、難しいことではないのに解法にたどりつけない事がよくあります。今回もそのパターンの一つ。 キャラモデルの肌のテクスチャに、例えばホクロとかタトゥーとかを重ねて表示したい時があります(ありますよね?)。このような描画処理のことを「デカール」といいます。このデカール処理をUnityで実現するにはどうすれば良いでしょうか。 UnityのスタンダードシェーダーにはSecondery Mapsというパラメーターを使って2枚目のテクスチャを指定する機能があります。しかしこの機能はDetail map(詳細マップ。肌の質感などを表現するためにディティール用のテクスチャを重ねる技法)での使用が前提とされていて、設定できるテクスチャマップに制限がありま
tsukasaスクリプトをC#コードに変換するトランスパイラを作っています。当初はrubyのparsletで書こうと思っていたのですが、parsletが気軽に動かせる代わりに字句解析器と構文解析器が分離していない点や、C#のプロジェクトに統合できない点から中止し、ANTLR4を使うことにしました。 ANTLR4はJava製のパーサージェネレーターで、C#用のコードも生成できる上に、VisualStudio上でシームレスに動作させるプラグインまで用意されています。これは簡単! ……という感じにはいかず、ひとまず動くまでかなり苦労したのでメモ(いずれちゃんと一つの記事にします)。 基本はこちらの記事の流れでいけば動きます。 (01)ANTLR4をC#で使ってみる https://sites.google.com/site/hobbyprogrammingroom/game/gamescript
10月22日に開催される技術書オンリー即売会「技術書典3」にて、「Unityシェーダープログラミングの教科書 ShaderLab言語解説編」を初頒布します。表紙は盟友のふゆの春秋さんに描いて頂きました。「若者(学生)が武器(Unity)を手にした」というモチーフとのことです。 また、「地方で技術書典に参加できないが欲しい」という要望を多数いただいたので、BOOTHにてPDF版の頒布を行うことにしました(期間限定の予定です。終了日は今のところ未定)。こちらは先行して公開を開始しており、下記サイトで購入&DLできます。 https://s-games.booth.pm/items/660001 何度か書いていますが、シェーダープログラミングは前提として必要な知識が非常に多く、それもあって本書は初心者向きとは言い難いです。また、読み終えたらすぐにシェーダープログラミングが出来るようになるという類
前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話( http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 )」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案1:マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理A } "1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑
土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード1行ごとにコメントを書きたいくらいです(本当は、識別子を全部日本語で書きたいと思っているのですが、これはまた別の話)。 これは土屋がPDL(Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... )開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日本人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より本質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき(≒正しく実装されたコードであれば、コメントは最低限になる)」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「本質的
土屋つかさが書いた「ゲームプログラミングにユニットテストを導入する本」PDF版を無料公開します。以下のURLからどうぞ。 ゲームプログラミングにユニットテストを導入する本(土屋つかさ著/B5/本文26ページ) http://someiyoshino.main.jp/file/tsukasa/game_programming_and_unit_test.zip 本書は、2017年4月9日に開催される技術書オンリー即売会「技術書典2」にて頒布する予定の物のPDF版になります。 昨年末から延々やっていた司エンジンにテスティングフレームワークを導入する作業をまとめなおし、一般的なゲームプログラミングに対象を広げ、ユニットテストを知らないプログラマにも分かるように書き直した物です。短いのでさくっと読めるんでないかと思います。 調査時間が足りず書けなかったネタ(ファクトリーモデルとかCIとかより実践的
ツイッターの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日 タスクシステムとはなにか 「タスクシステム」というのは、最初期の商業アーケードゲームにおいて使われていたゲームアーキテクチャです。当時はアセンブリ言語でゲームが作られていて、当然オブジェクト指向のような考えもなかった中、画面上に何十個
(思っている事を書いていたら多少の長さになったので貼っておきます。仮にコメントが荒れて、土屋に制御しきれそうになくなったら、エントリごと削除するつもりです。予めご了承下さい) 昨日行われた第三回電王戦第2戦「やねうら王VS佐藤紳哉六段」は、人間の凄まじさを肌で感じられる戦いで、ルールを知っている程度の将棋素人である自分も、手に汗握る攻防を楽しませてもらった。事前の騒動がなければもっと盛り上がっていた筈であり、その点についてはとても残念だ。 やねうら王の開発者であるやねうらおさん(以下やね氏)は、SE時代にネット上とはいえ個人的に親しくさせて頂いた事もあり、今回の事件でやね氏がバッシングされているのが結構つらかった。なので、ソフトを戻しての対戦となったのは正直ほっとしていた。その上で佐藤六段に勝って欲しかったのは個人的な心情である。 やね氏は土屋の考える所の天才の一人であり、我々常人の考えが
DXRuby Advent Calender 2013 12日目です。 11日目はfourxzさんのRuby使ったことない人がDXRubyでゲームを作りたいのでIDE3つインストールしましたでした。RubyにはWindows用のまともなIDEは無い物と思い込んでいたので、こんなに選択肢があるとは意外でした。これを機会に、試用してみたいと思います(デバッグトレースをCUIでやる気にはなれなくて……)。 さて12日目です。当初は別のエントリをアップする予定でしたが、DXRuby Advent Calenderのイベントを通じて、「ゲームプログラミング初心者は、意外とこういう所で躓くんじゃないか」と思い、2Dアクションゲームにおける衝突判定、特に、自キャラと障害物との衝突判定について、ざっくりまとめてみることにしました。 あくまで基本概念の説明であり、近代的なゲームプログラミングでは物理演算含め
ゲーム開発において、プロの現場と同人チームで大きな差があるとしたら、エフェクトとサウンド(BGM/SE)の分野ではないかと土屋は思っています(3Dだとまた違うんだけども、ここでは置く)。というのは、シナリオ/プログラム/イラストは、それぞれが独立したホビーとして成立していますが、エフェクトやサウンドは専門職な為、それをホビーとしている人がおらず、人を集めにくい/育てにくいからです。 その為、エフェクト/サウンドについては、ゲーム会社内でノウハウが蓄積され、書籍やネットの情報として社外に出ることが少ないのかなという印象があります。エフェクトについてはまた次の機会に書くとして、今回はサウンドの中の「ボイス収録」の話です。 今やノベルゲームでは必須となりつつあるボイスの収録というのもプロ特有のノウハウがありまして、というのも、ノベルゲームをフルボイスにすると、収録する台詞の数が数千に及ぶため、ち
2024-05-07 #UEFN #Verse 失敗許容関数内では明示的なreturnが出来ないルールについて UEFN Verse ゲーム開発 Unreal Engine 現在、5月25日から始まる技術書典に向けてVerse本の紙版リリースの準備を進めているのですが、無限に続く寒暖差のせいで体調が思わしくなくピンチでやばばです。頑張ります。 今回はそのVerse本に追記しようと思っているネタです。 問題編 キッカケは、ご… 2024-04-13 #UEFN #Verse 3/28の"Ask Epic: Verse"で面白かった回答ピックアップ(延長戦1:型システム編) UEFN Verse ゲーム開発 ゲームエンジン Ask Epic:Verse回答祭りの延長戦です。今回紹介する2つの質問は「この機能は採用予定がありますか?」「ないです。何故なら……」という物で、コーディングにおいて直接
このページを最初にブックマークしてみませんか?
『土屋つかさの技術ブログは今か無しか』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く