Toru Hisai boosted

This is a photo of a crashed kiosk advertising the menu and offers at a popular Norwegian pizza restaurant chain. It shows that the kiosk was running facial recognition and basic sentiment analysis on the people looking at it.

Based on the number of people who sent me this on Twitter, it’s clear that people care and are unhappy with corporate surveillance.

The worst bit? Compared to what Google and Facebook do daily and at scale, this is a toy.

mastodon.ar.al/media/OFTGkS78V

分散型でデータの実体も分散させて持つ場合、他のサーバにある内容を書き換えたいときに負荷が特定のサーバに集中する問題が出る。

ひとつの解決法は、即時に反映されなくても怒らない事。変更内容は独立したリクエストとして相手サーバに送るけど、返事を待たない。複数の人が矛盾するリクエストを投げる場合もあるので、衝突した時のエラーリカバリを考えておく。SMT みたいな感じで。これもやはりサーバ側で処理のタイミングをスケジュールできる。

分散型サーバアーキテクチャは男のロマンだと思う。

サーバ間の相互作用がないなら単にサーバを増やせばいいだけで簡単だけど、そうでない場合に負荷のアンバランスな状態をどうやって乗り切るかが面白いところ。Mastodon のアーキテクチャは実はよく知らないのであれなんですが、なんかいっぱいいっぱいらしい。

ウェブの場合は基本的に接続を維持しないので、リクエスト→高負荷でエラーかタイムアウト、またはユーザが能動的にリロード→更に高負荷に、という美しい足の引っ張り合いがはじまる。この時、実はクライアントとの接続は既に切れていても、サーバはそれと知らずに一生懸命仕事をする事もあり、理論的な性能をはるかに下回る事もありうる。

サーバのインフラにお金をかけずに解決するには、時間とのトレードオフを上手く持ち込む事だと思う。

ひとつの解決法は、高負荷の時はクライアントに対して整理券のようなものを配って、リクエストは受け付けましたのでこの時刻にまた来て下さい、というもの。サーバ側はユーザの種類に応じてリクエストに優先度付けする事もできる。

Toru Hisai boosted

不定期【宣伝】
兵庫鯖、mstdn.hyogo.jpを運営してます!
兵庫県民以外も大歓迎、新規登録受付中!
是非ご登録ください!

キヌガサは面白かったと思うけど、なんかスタッフの人のアカウントがいかにも俺いけてるでしょ、お前だれ、ここは田舎もんの来るところじゃないよみたいな態度でちょっと冷めてる間に亡くなってしまった。

Toru Hisai boosted
Toru Hisai boosted

Have
Have you
Have you heard
Have you heard the
Have you heard the one
Have you heard the one about
Have you heard the one about traceroute?

イースター終わったけどまだ休暇中なので痛い書き込みの続き。といってもだいたい書きたいことは書いたかもしれない。

とりあえず最初に作りたいゲームは、アドベンチャーゲームです。はじめは iPad で遊びやすいようなポイントアンドクリック型を考えてたけど、コントローラーでキャラを歩かせる方が作りやすいかも。
とりあえずゲームエンジンは UE4 を使って、アセットはできるだけマーケットプレイスで売ってるやつを使う。
それでもオリジナルで必要なのが、シナリオとキャラクターのモデリングなので、ここをお願いできる人を探すところから始める。
前の職場では小さな子供のいる人がたくさんいて、保育園のお迎えとかで早く帰ったりするのが大変そうだったので、子連れ出勤できる体制を作るとかして、子持ちの人が働きやすい環境にしたい。具体的にどうするのがいいのかは今は分からないけど。

The Demae Ramen in Europe is awesome. Even better than Japanese one. 🍜

おねがいマストどん(砂の妖精的な)。

人が遊んでいるのを見て直感的にゲームを評価するだけだと、どうしても近視眼的になってしまうので、それを補うものとして各種メトリクスの計測を徹底したい。何パーセントの人がこの操作をしたか、そのうちの何パーセントが目的を達成したか、何パーセントの人がこのトラップをクリアしたか、何パーセントの人が諦めたか、あるいは飽きたか。
出典や参考文献を挙げ始めると面倒になるのでアレですが、計測の重要性は『リーン・スタートアップ』で読んでそれ以降ずっと頭の中に引っかかっています。さらに元をたどると『HIGH OUTPUT MANAGEMENT』に書かれていて、この本もとても面白いし勇気付けられます。
チーム内でみんなで遊んでいるうちはお互いの顔も見えるけど、少し大きめのベータテストなんかでは数値で判断するしかない。アーティストの中には数値で評価される事を嫌う人もいるかもしれないけど、そういう人にどうやって納得してもらうかが課題になりそう。

さっきから痛い書き込みを続けていますが、ドイツはイースター(復活祭)の月曜日でもうすぐお昼ですので許してください。
それぞれの人が作ったものをお互いに見せ合う場として、週一くらいの定期的なビルドレビューの会をやりたい。ここで特に、通常プレイでハマる場所や UI で迷う場所を確認したい。
ぼくはよくゲーム内で UI の記号の意味がわからなかったり、ゲーム内の指示を誤解して明後日の方向に進んでしまったりする事があるけど、そういう事を指摘すると大抵は「お前がアホなだけや」で済まされてしまう。
たとえば「グレーのボタン」は、ぼくには「無効化」されたものに見えるけど、人によっては「選択済みでない」(つまり押せる)ことを意味することがあるらしい。
でもみんなで遊んで見て 5 人中 2 人が同じところでハマるとかいう状況になれば、そういう言いにくいことも言えるようになるんじゃないか。
ゲームを作る方は、その人がそれまでに遊んだゲームなどに無意識レベルで強い影響を受けてしまうので、間違いや勘違いをする人のことが理解しづらい。そこを、作る方も遊ぶ方も新鮮な気持ちで失敗の体験を共有したい。

継続的インテグレーションをゲーム開発で使うもう一つの目的は、聞きかじり知識や表面的な理解や壮大な勘違いなどで偉そうに批評をする人の影響力を抑えることです。
「今時〇〇がないゲームは売れない」とか「リテンションのために〇〇は必須」とか、そういうのを出来上がる前から、あるいは作る前からいろいろ言ってきて、結果的に仕様が肥大化し、多くの犠牲の上に誰も遊ばないゲームができるというケースを避けたい。
人は知識や経験が増えると謙虚になるものなので、声の大きい人ほど本当なら無視すべき人なんだけど、正直に制作している人ほどビビって気にしてしまう。
でも、自分の作ったものがすぐにビルドに反映されて、目の前の人が楽しそうに遊んでいるのを見れば、あるいはどうしていいかわからずに困っているのを見れば、もっと強い確信をもって自分の仕事でやるべき事が見えてくるはずだ。

自分でゲーム開発の進行を管理する立場になったら試したいのが、徹底した継続的インテグレーションで、チーム一人ひとりの作業の結果がすぐに反映され人の目に触れるようにすることです。これによりモチベーションを保ち、また自分の作ったものを他の人が実際に触るのを見ながら、作るものの方向を修正できるようにする。
◯日後にできるはずの物を前提に自分の仕事をするのではなく、すでに存在しビルド場で実際に動くものに基づいて自分の仕事をする。
ただまあそうは言っても、お互いの作業内容が強く依存し合っていたらそういうことはできない。なのでそこはゲームエンジンをよく理解するなどして、エンジニアリングの方向で解決したい。ソフトウェアで例えると、ミューテックスやクリティカルセクションを使う代わりにイミュータブルなデータ構造とパイプラインによってマルチスレッドの機能を実装するみたいなイメージ。

あ、なんか極端な方向に行ってしまった。
もう一つ約束をしたくない理由は「待ち」の状態を無くしたいこと。◯日までにこの実装ができているはずだったのにまだ出来ていないので、〇〇の作業に手がつけられません、という状況を無くしたい。こういう時、特に納品前などのタイミングでは、待たされる方はやることがなくても夜遅くまで会社に残っていなきゃいけなくなる事があるし、待たせる方も無駄に大きなプレッシャーを感じながら仕事をしなくてはいけない。
そうやって作ったものは大抵まともに動かない。当初の想定のようにスムーズに他の部分と繋がらない。聞いた話と違う、責任者出てこい、という話になってしまう。ハシゴ外しはこういう時には必然的に起こる。
中間管理職や顧客との窓口(請負開発の場合)になる立場の人は、このような状況を生き抜くために、あらゆる方向にバッファを確保しようとする。このバッファは会社から見ても顧客やエンドユーザ(プレイヤー)から見ても無駄以外の何物でもないけど、社会人として今を生き抜くには必要な事だ。

締め切りを強いモチベーションとしていつも以上にすごい成果を出す人もいるから、一概に約束するのがダメとは言わないけど、一方で締め切りに間に合わせるために頑張りすぎて燃え尽きるケースは嫌という程見てきた。
焼畑農業型の開発も、マスターアップ後に十分な休養と報酬が約束されているならありだと思うけど、実際はリリース直後からやれ KPI だパッチ配信だ他のチームの火消しだと忙しく、休養が欲しければ退職するしかない。しかも残念なことに、たまりまくった有休消化という行為が完全にその要求を満たしてしまっている。
そういう意味で、約束はしないというポリシーを積極的に掲げるのは会社の持続性のためにも一つの解決方法なんじゃないだろうか。
そんなことビジネスでは通用しないという人もいるかもしれないけど、会社間の約束の場合、守れない場合は普通は「債務不履行」で違約金を払って終わりなので、人が死ぬようなことはない。(経営者が首を吊る場合を除く。)

イースターなので痛い書き込みの続き。
それぞれ専門性がまったく違う人達同士で仕事をする時に、お互いにいつまでにこれをやります、という約束をすることなしに、何かを作ることなんてできるだろうか?
例えば、来月までに〇〇のステージを作りましょう。そのために、プログラマはいつまでにこの仕様のプログラムを、アーティストはいつまでにこれだけの絵を、その後必要なデータ変換、テスト、デバッグを経て、〇〇日までにリリースします、みたいな約束事はうまく行けばとても機能するはずだ。
ただ、問題は、約束する内容や実際に達成される内容は、どうしても政治に影響されてしまう。無理だとわかっていても約束させられ、必要なサポートは惜しまないと言われながら、最後にハシゴを外されるというようなことは良くあるし、個人的には仕事上の約束というのは見た目ほどまともに機能しないのではないかと思います。

将来日本に帰国したらゲームスタジオを作ろうと思うんですが、それで実現したいぼくがかんがえた最強のゲーム制作。

継続的インテグレーションの徹底。
制作関係者全員がリポジトリに直接プッシュしてすぐに自動ビルド。
ゲーム内の各種メトリクスの計測を徹底して努力の成果を見える形にする。
UI については A/B テストの徹底。
プログラムは自動ユニットテストの徹底。
可能なあらゆる状態を再現できるセーブデータ。
あらゆる承認プロセスの全廃。
あらゆる締め切り、期限の設定の禁止、あるいは他人の将来の仕事への依存の禁止。
定期的に全員参加のビルドレビュー(人が遊んでいるところを見る)。
知ったかぶりの批評家に文句を言わせない。
ゲームの良さはどれだけの人がそのゲームに熱中したかで評価する。
人事考課はチームメンバーがお互いにどのくらい一緒に仕事をしたいかで評価する。

Show older
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!