Amazon の再購入リストを開いたら面白かったのでついでにマイ日用品を紹介する話。

雑記

f:id:eiki_okuma:20190504204815p:plain

　https://www.amazon.co.jp/gp/buyagain

　まず、上のＵＲＬを開いてみてほしい。大丈夫、怪しいリンクではない。このリンクは、Amazon の再購入リストのリンクである。Amazon のアカウントメニューの「もう一度買う」という所でも同じものが見れる。

　Amazon の再購入リストはなかなか性能が高く、普段繰り返し購入しているもののうち、しばらく購入していない（そろそろ購入サイクルが来る）製品を優先的に表示してくれる。いわば、日用品リストだ。このリストを眺めるだけで、その人が普段どんな暮らしをしているのか、少し理解することができる。人の日用品リストを眺める機会はそう無いし、リスト化するのも本来面倒なものなのだが、こうしていざ一覧になっていると何とも面白いものだ。一つ一つにそれを選んだ理由もあるし、これを紹介するだけでも立派なヒトネタになりそうだと思い立ったわけである。

　社会人生活も七年ほど過ぎると皆日用品も最適化されていく。最近社会人になったばかりの人は是非参考にしてほしいし、長く社会人生活を営んでいる人も「ああ、これ使ってる」とか「こんなものがあったのか」なんて共感や気付きを得てほしい。そして、願わくば他人のリストも見てみたいので、Twitter に貼ったり同じテーマでブログを書いてみてほしい。

2019-04-21

Apple Arcade は我々ゲーム開発者に何をもたらすのか？

雑記

f:id:eiki_okuma:20190421115111j:plain — (c) Apple, Inc.

　Apple Arcade が話題だ。ユーザにとっては念願の遊び放題サービス、しかも従来の「散々遊びつくされた過去作が放流されるサブスクリプション」ではなく、完全新規・独占タイトルが多数用意されているのだから、コアなゲームユーザにとっては垂涎モノの新サービスと言うほかない。

　一方でぼくなどは天邪鬼なのでこうも歓迎ムードで迎えられると逆張りしたがる愚かな生き物であり、実際 Apple Arcade には Twitter で散発的に書いているように幾つかの重大な懸念点が存在する。大体の個人開発者は Apple の審査や規約周りにに苦汁を舐めさせられているので、皆いまいち信用できないんだろうなあという空気も節々から感じている。

　実際にどう運ぶかはリリースされ、一年ないし二年程度経たないと分からない部分も多いのだが、ゲーム開発者という視点からこの Apple Arcade が何をもたらすのか、メリットデメリットを並べてみたいとおもう。*1

Apple Arcade のメリット
- 新たなマーケットが生む第三の販売形態
  - 旧来の販売形態とその欠点
  - 第三のマーケット、第三の販売形態
- Apple の意志。良質な有料ゲームが再び復権するか？
Apple Arcade のデメリット
- プラットフォームが力を持ちすぎる。
- 選ばれなかったゲームはどうなるのか？
- ゲームの価値は本当に維持されるのか？
- 業界の外にゲームが広がっていくか？
まとめ

*1:ユーザー視点？最高に決まってるだろ、そんなの！

2019-03-15

プロが教える、ゲーム企画書の作り方【就活/会社】

ゲームデザイン雑記開発TIPS

　 f:id:eiki_okuma:20190315090101j:plain

プロが教える、ゲーム企画書の作り方

　という有料記事を note にアップロードしました*1。500円で就職や会社での活動にダイレクトに響く実践的なノウハウが入手できます。

　何故有料にしたかというと、普段ブログに書いてる「読み物」と違って実践的な内容しか書いてないので、頭の中であれこれ考えながら真面目に読まないと意味がないからです。業務や制作の中で学んだ多くの経験・知識を詰め込んでいるので、流し読みしてほしくないなあ、というのも一つです。

　まあ、実験的な試みですが、後悔させない内容にはなっているので良ければ読んでみてください。途中まで試し読み可能です。

note.mu

*1:はてなブログにも有料記事機能がつけばいいのに……

2019-02-19

秒でオーディオを実装する

Unity プログラミング

とりあえず一日～二日で作ったプロトタイプに音を付けたい時に使うスクリプト。

//--------------------------------------------------------------------------------
//	- AudioManager -
//--------------------------------------------------------------------------------
//
//	オーディオ全般
//
//--------------------------------------------------------------------------------

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public enum ESeID
{
	None,

	Decide,
	Cancel,
	Select,
	Bomb,
	Dash,
	
	Max
}

//--------------------------------------------------------------------------------
public class AudioManager : MonoBehaviour
{
	AudioSource	mBGM = null;
	AudioSource [] mSEList = new AudioSource[cSEMax];

	const int cSEMax = (int)ESeID.Max;

	//----------------------------------------------------------------------------
	void Awake ()
	{
		DontDestroyOnLoad( gameObject );
		var t = transform;

		mBGM = GetComponentSafe<AudioSource>( t, "BGM" );
		for( ESeID e = ESeID.None+1; e < ESeID.Max; e++ )
		{
			mSEList[(int)e] = GetComponentSafe<AudioSource>( t, e.ToString() );
		}
	}
	
	//----------------------------------------------------------------------------
	public void playSE ( ESeID id )
	{
		if ( mSEList[(int)id] != null ) mSEList[(int)id].Play();
	}
	
	//----------------------------------------------------------------------------
	public void startBGM()
	{
		if ( !mBGM.isPlaying ) mBGM.Play();
	}

	//----------------------------------------------------------------------------
	// コンポーネントの取得
	private Type GetComponentSafe<Type>( Transform parent, string gameobject_name )
	where Type : Component
	{
		Transform temp = parent.Find( gameobject_name );
		if ( !temp ) return null;
		return temp.GetComponent< Type >();
	}
}

使い方：

f:id:eiki_okuma:20190321000711j:plain

"Audio"と名前の付けた空のゲームオブジェクト*1に、"BGM"と名前の付けたゲームオブジェクトと、 ESeID の中で指定した SE の名前のゲームオブジェクトをぶら下げる（"Decide"とか"Dash"とか）。BGM と SE にはそれぞれ AudioSource を追加しておく。
"Audio" にこの AudioManager を追加する。
後は適当なところから playSE や startBGM を呼ぶ。

*1:この名前は別になんでもいい

2018-11-01

物事のパッケージング - 自己満足が争いを生む本当の理由

雑記

f:id:eiki_okuma:20181101211103j:plain

　こんな記事が先週話題になっていた。

　流し読みすると一見よくある「妻の言うことを聞いてばかりでも不満が溜まっていくだけだった！」みたいな内容なのだが、実は本質はまったく別の所にある。その正体は、現代社会において度々発生する物事のパッケージング問題だ。たとえば、以下のようなケースをよく耳にしないだろうか。

自分は率先して家事をやったのに、妻の小言が増える一方だった。（今回のケース）
積極的に育児に関わってきたはずなのに、妻からはそう思われていない。それどころか、子供も妻に懐いている。
先陣を切って精力的に仕事をやったのに、上司や同僚からの評価が低い。あいつらはちゃんと俺を見ていない。
閑散期に深夜まで残っているプログラマーがいる一方で、定時に帰宅しているプログラマーもいる。しかも、前者の方が優秀なプログラマーなのに。
彼はよく家事を手伝ってくれるけど、どうも思いやりが足りない。（逆のケース）
あのディレクター、対外的に偉そうなこと言ってるけど、現場では迷惑な言動ばかりでプロジェクトがめちゃくちゃだ。（逆のケース）

　これらは全て、当事者間の物事のパッケージングが上手く擦り合わさってないことに起因する。あらゆる現代人を悩ませるこの物事のパッケージング問題とは何か、詳しく説明していく。

2018-10-22

【Unity】iOS / Android でレビューを促す。（2018年10月版）

プログラミング Unity 開発TIPS

　 f:id:eiki_okuma:20181022194328p:plain

　ちょっと目を離してる隙にどんどん仕様が変わっていくよ！！

iOS

if ( !UnityEngine.iOS.Device.RequestStoreReview() )
{
	yield return Ask();        // レビューするかどうか聞く
	if ( answer == 0 ) { 
		string url = "itms-apps://itunes.apple.com/jp/app/idXXXXXXXX?mt=8&action=write-review";
		Application.OpenURL(url);
	}
}

　「XXXXXXXX」はアプリごとに変える部分。（AppStoreのURLより）
　iOSは10.3から専用のネイティブダイアログが強制されるようになったが、全ての端末が10.3以上であるとは限らないので、 RequestStoreReview() で分岐する必要がある。このネイティブダイアログは「レビューしてください！→☆☆☆☆☆　ＯＫ/キャンセル」というものなので、これが使える場合はレビューするかどうか聞く必要はない。

　false が返ってくる場合は未対応端末なので、アプリ側でレビューするかどうかを聞く。

RequestStoreReview()の諸注意

呼び出した後、出てくるかどうかは OS 側で調整する。例えば、前回「いいえ」を押した場合はしばらく出てこなくなる。この設定はユーザ側も変えられる。
故に会話中にダイアログを出したい場合、文言に気をつけないと不自然になる。
戻り値は「レビューしたかどうか」には関係ない。
Apple 側の想定としては、ゲームの合間に適当に何回も呼んでね！　という感じだと思われる。

Android

yield return Ask();        // レビューするかどうか聞く
if ( answer == 0 ) { 
	Application.OpenURL( "market://details?id=XXXXXXXX" );
}

Android はシンプルに URL を開くだけ。「XXXXXXXX」はアプリごとに変える部分。（パッケージのID - com.illucalab.ham など）

まとめると

#if UNITY_IOS
if ( !UnityEngine.iOS.Device.RequestStoreReview() )
#endif
{
	yield return Ask();        // レビューするかどうか聞く
	if ( answer == 0 ) {
#if UNITY_IOS
		string url = "itms-apps://itunes.apple.com/jp/app/idXXXXXXXX?mt=8&action=write-review";
#else
		string url = "market://details?id=XXXXXXXX";
#endif
		Application.OpenURL(url);
	}
}