まるまるこふこふ

数々の次元が崩壊し、全ての生命が塵と化すのを見てきた。私ほどの闇の心の持ち主でも、そこには何の喜びも無かった。

emscripten で DOSBox をブラウザで動かしてみた。

はじめに

f:id:sairoutine:20170731020004p:plain

Emscriptenとは C/C++言語からLLVMを生成し、それをJavaScriptに変換するコンパイラのことです。
DOSBoxは、PC/AT互換機のMS-DOS環境を再現するエミュレータです。

結果

上記ツイート内動画のように、DOS向け Bad Apple!! をブラウザで再生することができました。

再生

皆様のブラウザでも、以下のURLから再生することができます。

https://sairoutine.github.io/BadAppleJS/

起動すると「Choose sound device」と聞かれるので「3」を押して Enter してください。ロードに成功すると、「Press enter to start」と言われるので、Enter を押してください。再生が始まります。

※「Exception thrown, see JavaScript console」と表示されたらリロードしてみてください
※音ズレが発生しているのは勘弁

過程

em-dosbox という DOSBox の emscripten 移植が存在するので、それを利用しています。

https://github.com/dreamlayers/em-dosbox

DOS 向け Bad Apple!! は以下のサイトからダウンロードできます。

http://abaduaber.ru/Prog.htm

(ロシア語でわかりづらいですが、「Bad Apple, ДОС - версия」という項目がソレです。)

事前にダウンロードして解凍し、のちのち git clone してくる ./em-dosbox/src 配下に移動させておきます。

コンパイル手順は基本的に em-dosbox レポジトリの Readme に書いてある通りです。環境は、MacOS X EI Captain 10.11.6 です。

なお、emsdk を利用しています。

# emsdk のセット
git clone git@github.com:juj/emsdk.git
cd emsdk-portable
./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh 

# em-dosbox のダウンロード
cd ../
git clone git@github.com:dreamlayers/em-dosbox.git

cd em-dosbox

# configure ファイルの生成
./autogen.sh

# emscripten 用 Makefile の生成
emconfigure ./configure --without-sdl2

# コンパイル
make

# DOS 向け Bad Apple!! の実行ファイルを emscripten 向けにパッケージング
./packager.py badapple badapple BADAPPLE.EXE

# http-server を起動
python -m SimpleHTTPServer 8000

# ブラウザでアクセス
open http://localhost:8000/badapple.html

以上です。

ちょっと解説

emconfigure ./configure --without-sdl2

em-dosbox はデフォルトで、SDL2 を利用してコンパイルするが、 私のMac には SDL1 しか入ってなかったので、オプション指定して SDL1 を利用しています。

SDL2 が入っていないと、以下のようなエラーになる。

f:id:sairoutine:20170731020014p:plain

./packager.py badapple badapple BADAPPLE.EXE

packager の第一引数にはパッケージ後のファイル名を、第二引数にはパッケージ対象のディレクトリを、第三引数には、DOSBox をブラウザで開いた際に、最初に起動する実行ファイル名を指定します。

なお、実行ファイルが1つしか存在しない場合、以下のように、第二引数に直接実行ファイル名の指定もできます。

./packager.py badapple BADAPPLE.EXE

終わり

描画が追いついておらず、音ズレが発生しているのは、WebAssembly を有効にすれば 解決するかもしれない。次回やってみる。

Bad Apple !!だけでなく、DOSBox では例えば Win3.1 や Windows 98 も起動できるみたいなので、うまくやれば、ブラウザ上でそれらも動かせるかもしれない。

RPG アツマールに RPG ツクール MV 製ではないゲームをアップロードしてみた

弊サークル作品の「紫と霊夢の終わらない夏」の体験版を RPG アツマールに投稿できたので、アップロードにあたって、やったことをまとめます。

ゲームの概要

「紫と霊夢の終わらない夏」は PC向け 2D アクションパズルゲームです。RPGでもなければ、RPG ツクールMV 製でもありません。

技術的には、HTML5 + javaScript で開発されており、 Electron を使って、PC 向けにビルドして頒布しております。

アップロードのやり方

RPG アツマールは RPG ツクール製のゲームがアップロードできるサイトです。PRG ツクール製ゲームのアップロードに向いていますが、Web の技術で作られたゲームであれば、RPGツクール製でないゲームでもアップロード可能です。

RPG アツマールの仕様やアップロードの仕方については、 先人の方がいて、すでにまとめられてますので、以下のURLをご参照ください。

http://qiita.com/hajimehoshi/items/2a28b16a2e587c82ac5d

やったこと

Web ブラウザ上で動くゲームならそのままアップロードできるはずですが、 アツマールの仕様上、「紫と霊夢の終わらない夏」では以下の対応を行いました。

音楽ファイルを wav から m4a と ogg に変換

RPG ツクールMVが、m4a や ogg といった音楽ファイルしか使用できない制限のため、RPG アツマールでは、wav などの一部の音楽ファイルのアップロードが制限されています。

よって、wav ファイルを m4a と ogg の両方に変換し、ゲーム側で、 ogg あるいは m4a を再生しわけるように修正しました。

(Chrome では ogg が再生できますが、safari では ogg が再生できないので、m4a を使用します。)

index.htmlに埋め込みでjavascriptが書けない

セキュリティ上の理由で、index.html に javascript を記述できないので、javascript コードは全て js ファイルに記述して、script タグで読み込むように修正しました。

safari でフォントの読み込みが終わらない

これはRPGアツマールの仕様というより、Safari の挙動が怪しい話です。 弊ゲームでは以下のようなコードで、ゲームで使用するフォントの読み込みが完了するまで、ゲームをローディング画面で待機させています。

しかし、Safari のみ、loadingdone イベントが発火しません(バージョンは10.0)

 // フォントの読み込みが完了
    if(document.fonts) {
        document.fonts.addEventListener('loadingdone', function() { game.fontLoadingDone(); });
    }
    else {
        // フォントロードに対応してなければ無視
        game.fontLoadingDone();
    }

これは、以下のように safari だけブラウザ判定して、 フォント読み込み待ちをしないことで修正しました。

 // フォントの読み込みが完了
    if(document.fonts && !navigator.userAgent.toLowerCase().indexOf("safari")) {
        document.fonts.addEventListener('loadingdone', function() { game.fontLoadingDone(); });
    }
    else {
        // フォントロードに対応してなければ無視
        game.fontLoadingDone();
    }

.gitkeep が含まれていてアップロードできない

RPG アツマールにアップロードできるファイルは、 非常に限られており、未対応のファイルをアップロードすると、 アップロードした時点で、どのファイルが未対応か教えてくれます(便利)

私の場合、.gitkeep ファイルが残ったままだったのでアップロードに失敗しました。 これは、.gitkeep を全て削除して解決しました。

おしまい

RPG アツマールでは、特に規約上でもRPG ツクールMV 製でないゲームのアップロードは禁止されていません。

「紫と霊夢の終わらない夏」のようなオリジナルゲームエンジン製のゲームをアップロードすることもできますし、例えばティラノスクリプト製のノベルゲームをアップロードすることもできます。

みんなも Let’s try!

追記

RPGアツマールのスクリーンショット機能や、画面最大化機能が使えない。canvas DOM に振ったIDが悪い気がするので調査する

初めての個人ゲーム制作の振り返り

2016年12月29日のC91冬コミにて、東方Project の二次創作シューティングゲーム 「宇佐見蓮子の大事な約束」を頒布しました。 (DLsite でまだ DL購入できるので、興味ある方はぜひ購入してみてください。)

初めての個人ゲーム制作ということもあり、まずは「エターナらない」ことを目標に制作しました。

「エターナル」（英語の形容詞eternal:永遠の、果てしない）を動詞化させた造語。 ツクラー（ここでは主にPC用のRPGツクールのユーザー）の間で生まれた。 未完の大作「エターナルファンタジー」からとも。参考 作者が諸般の事情によりゲーム製作を途中で放棄すること、またはその状態を表す。

エターナるとは (エターナルとは) [単語記事] - ニコニコ大百科 より引用

ゲーム制作がエターナる原因は、主に以下のものがあります。

  • ゲームの構想が大きい
  • モチベーションが維持できない
  • 制作に当てる時間がない

「宇佐見蓮子の大事な約束」では、これらを避けるために、 以下の方針で制作しました。

  • 大きなチャレンジをしない
  • モチベーションを折らない仕組み作り
  • 制作に必要なタスクを外部に委譲

大きなチャレンジをしない

「宇佐見蓮子の大事な約束」は全5面のいわゆるオーソドックスな縦シューティングゲームであり、 プレイ時間 1時間もかからない程度のボリュームです。

いわゆる超大作になりがちなゲームジャンルや、あるいはプレイ時間の長さを目指すことによる 「作りきれない」を避けています。

また技術的には自分の得意な HTML5 を利用して制作しました。

「宇佐見蓮子の大事な約束」はジャンルとしては、弾幕シューティングゲームであり、 PC向けシューティングゲームであれば、C++ と DirectX を使ったり、あるいは東方弾幕風といった シューティングゲーム制作スクリプトを使うのが一般的です。

ですが、1から学習をしないといけないため、学習にかかる時間が見積もりしづらいことと、 学習に対するモチベーションが続くか不明だったため、自分の得意分野である HTML5 を利用しました。

とはいえ、HTML5 においても GamePad API (ゲームコントローラの入力の取得) や FullScreen API (画面最大化)といった技術的なチャレンジはしていますが、 これらはおおよそ学習や調査の工数が見積もりやすいものです。

なお HTML5 で弾幕シューティングゲームが作れることは toho-like-js が既に存在するのでわかっていました。

モチベーションを折らない仕組み作り

複数人での開発(コアメンバーが自分含めて 2名、加えて外部の方に手伝って頂いております) だったため、 自他のモチベーションを維持するため、以下のことをやっていました。

適切な情報共有

Google Drive を利用し、制作した素材や、あるいは制作において決めたこと、共有したことを全てそこに集めるようにしました。 また現状の進捗がわかるように、ゲームをすぐに遊べる状態にしておきました。 (これは HTML5 で制作していてビルドの概念がないので、ある URL にアクセスすればいつでもすぐ遊べるようにできました。)

意思決定に参加してもらう

文字でのやり取りももちろん、なるべく口頭での相談、進捗擦り合わせを心がけました。

制作に必要なタスクを外部に委譲

主にドット絵やBGMなどを外部の方に制作をお願いさせていただきました。

6ヶ月という短いスパンで制作ができたのは、 1人で全て制作するのではなく、複数人で制作できたからだと思います。

また自分以外の人がゲームに関わることで、完成に対する責任感もできました。

完成版を頒布して良かったこと

当たり前のことですが、自分の作品を色んな方々に遊んでもらうことができました。 Twitterで感想を書いてくださる方もあり、自分だけでは気づかなかったゲームの課題なども知ることができました。

またニコニコ生放送などで実況プレイをしてくださる方もいました。 こちらは、実際にプレイしてくださる方が、ゲーム上のどの場面でどういう反応をするのか知ることができて、 本当に勉強になりました。

課題

「ゲームにおける面白いとは何か？」「その面白いを実現するためには？」といったことへの 考えが足りなかったと思います。

シューティングゲームのなにが面白いのかという理解が足りず、 レベルデザインのミスや、あるいは快適なプレイ感がなかったという反省があります。

また制作の方針としても、そもそものゲームのコンセプト(こういう点が今回のゲームの魅力的なところだ)ということが ボヤケていて、制作が進んでいく中で発生する意思決定にブレがあり、 制作に手戻りを発生させて、人に迷惑をかけたこともありました。

これらの反省を踏まえて、次回作では、このゲームはなにが面白いのかということをきちんと考えた上で コンセプトを決めて、そこをブレさせないことや、あるいは 自分以外の人にもっとたくさんテストプレイしてもらって、 ゲーム上での不快感を潰すことを行おうと思います。

最後に

f:id:sairoutine:20170625153122p:plain

(「宇佐見蓮子の大事な約束」のいわゆるトゥルーエンドで使用した画像)

ゲーム制作は楽しかったです。複数人で 0 からモノを作っていくことは楽しいです。 そうした楽しさは、自分もそうだし、あるいは今後自分のゲーム制作に関わってくれる人にも感じて頂けるよう努力します。

一方で、ゲームをプレイしてくれたプレイヤーを楽しませるための視点や知識、経験はもっと養っていきたいです。 今後も向上させていけるよう努めます。

作ることを制作者が楽しめて、そして作ったものでプレイヤーが楽しんでくれることが、 個人ゲーム制作の醍醐味だと思います。

台湾 例大祭の一般参加した時のメモ

第二回博麗神社例大祭 in 台湾に一般参加してきました。 日本国外である台湾での開催ということで、なかなかハードルが高いと思われがちですが、 案外アッサリ行ってこれたので、どんな準備をしたかを書こうと思います。

f:id:sairoutine:20170529184215j:plain

画像は台湾例大祭で購入した公式グッズ(おみやげ？) であるところのパイナップルケーキです。

パスポートを取得する。

これは自分は既にパスポートを取得してたので、今回は特になにもしてませんでした。 ググれば、パスポートの取得の仕方はノウハウが見つかるので、そちらを参照頂ければと思います。

Visa は不要

日本のパスポートがあれば、台湾への渡航に Visa は不要です。

飛行機のチケットの取得

LCC(格安航空券)を使うと安いと思います。 私は行こうと決めた時期が遅く、LCCがほぼ売り切れだったので、 China Airlines でチケットを購入しました。往復 6万円くらい。 LCCであれば、3万円くらいで行けると思います。

ホテルの予約

楽天トラベル(http://travel.rakuten.co.jp/)を利用して、現地のホテルを予約。 例大祭の会場が、台北市大同区だったので、"大同区"で検索して、 なるべく会場に近いホテルを予約した。 予約したホテルはビジネスホテルで、1泊 6000円くらいでした。

持ち物

パスポート、クレジットカード、現金、PC、スマホ、充電器、着替えだけ持っていった。 最悪、パスポート・クレカ・スマホさえあればなんとかなるので、 それらだけは絶対に忘れずに。

充電器は日本のものがそのまま使えるので、変圧器などは不要。

空港

関空から台湾 桃園国際空港まで飛行機でだいたい片道3時間くらい。 搭乗手続きに時間がかかるので、離陸時刻の1時間前には、 空港のカウンターでチェックインするくらいの時間感覚で、空港に来ること。 空港での手続きまでは、日本語が通じる。大丈夫。

両替

空港にて、日本円を台湾ドルに両替。空港が一番交換レートが良いと聞いた。 交換手数料が 30台湾ドル(約120円くらい)かかる。

僕は 7万円両替して 18000台湾ドル手に入れたが、結局 現地では 7000台湾ドル(約26000円)くらいしか使わなかった。

空港からホテルへの移動

桃園国際空港から台北市まで距離があるので、電車あるいはタクシーで移動することになります。 私はタクシーを使ったので、タクシーの話をします。 だいたい空港から台北市まで、タクシーでだいたい40分くらい。料金は約1000台湾ドル(約4000円)。

タクシーのおっちゃんは、日本語も英語も通じないことが多いので、 スマホとかに、行き先の住所をメモして見せると良い。

ホテルからイベント会場への移動

これもタクシー。市内であれば、100〜200台湾ドル(500円~1000円くらい)で移動できる。 大きな通りであれば、タクシーはめちゃ流れてるので、簡単に捕まえられる。 日本のタクシーと違って、台湾のタクシーは自動でドアが開かないので、自分で開けること。

イベント会場

今年の会場は以下でした。

会場名：卡市達創新基地(圓山店)
住所：台北市大同區承德路三段232號B2

以降の開催も同じ場所である保証はないので、今後の台湾例大祭がどこで開催されるかは、 公式サイトを必ずご確認ください。

基本的にはイベント会場での注意事項は日本と同様です。

列形成のイベントスタッフは台湾語の人ばかりで、そこだけ面食らうかもしれません。 10時半開催のところ、私は10時に来たのですが、だいぶ列が出来てました。

列で並んでるとスタッフが参加者の手にスタンプを押し始めます。 カタログを事前購入していない人は、ここで100台湾ドル払って、スタッフにスタンプを手に押してもらいます。 入場は、カタログあるいは手のスタンプを会場スタッフに見せることで入場できます。

カタログは200台湾ドルですが、会場でカタログを購入する場合に、 手のスタンプを見せると、100台湾ドルでカタログが購入できます。

会場は人も多いし、熱気が凄かった。

FAQ

台湾って日本語は通じるの？

あまり通じないって聞いてます。ホテルは高いホテルだと通じるかも。 イベント会場では、台湾のサークル主の方は、簡単な日本語であれば通じる人もいました。

台湾って英語は通じるの？

タクシーはほぼ通じない。 ホテルは簡単な英語なら通じるといった感じでした。

Wi-Fi状況は？

ホテル／空港はほぼほぼFree Wi-Fi。 さすがに道端とかで フリー Wi-Fi は飛んでいないので、 お店とかに入る必要がある。

会場での同人誌のお値段

漫画本だと、100台湾ドル(約400円)〜150台湾ドル(約600円)くらい。 イラスト本だと 300台湾ドル (約1200円)とかが多かった。

Electron で手動GCを行う

さいです。
JavaScript と Electron でPC向けの弾幕シューティングゲームを作っています。
C++ と違って JavaScript はGarbage Collection (以降GCと呼称)がある言語なので、
ゲームプレイ中に不定期にGCが発生して、ゲームのパフォーマンスが悪化することがあります。

Object pooling を使って、GCの回数は減らす努力はしているのですが、
それでも(恐らく)GCの発生によって、古いPC等では露骨に画面が止まることが
あるので、Electron上で GCのタイミングを調整したいなぁと思いました。

Electron は Chromium ベースのプラットフォームであり、
Chromium は v8 エンジンを使用しています。
v8 エンジンのGCは Mark-Sweep 方式でのGCです。

v8 エンジンが自分で判断して行うGCを止める方法は
調べたのですが、無さそうです。

よって仮説として、メモリが潤沢にある環境であれば、オブジェクトが必要なくなってもすぐにオブジェクトへの参照を切らずにしておき、リザルト画面などのタイミングで不要なオブジェクトへの参照を切って、それからすぐに手動でGCを発生させることで、ゲームプレイに支障が出る場面でのGCをなくせそうです。

というわけでやっとこの記事の本題に入りますが、Electron 上で
手動GCを行う方法を書きたいと思います。

–expose-gc フラグを立てる

const electron = require('electron');
const app = electron.app;
app.commandLine.appendSwitch('js-flags', '--expose-gc');

app.on('ready', () => {
  // Your code here
})

app.commandLine.appendSwitch('js-flags', '--expose-gc'); を実行することで、Electron のレンダラプロセス上で global.gc() 関数を実行することができるようになります。

メインプロセス上のコードで app に対して、ready イベントが発火するまえに、app.commandLine.appendSwitch() を実行することで、
js-flags に引数を渡すことで、Electron の v8 エンジンに対して--expose-gc フラグを渡すことができます。

この辺は、公式の docs に記載されている。

github.com

global.gc() の実行

上記の方法で、v8 エンジンに --expose-gc フラグを渡すことで、
Electron のレンダラプロセス上で、global.gc() が実行できるようになります。

// 手動GCの実行
if (global.gc) {
    global.gc();
}

サンプルコード

サンプルコードを書いて、GCが行われているか確認してみます。

メインプロセス

// electron エントリポイント
'use strict';
const electron = require('electron');
const app = electron.app;
const dialog = electron.dialog;
const BrowserWindow = electron.BrowserWindow;
const globalShortcut = electron.globalShortcut;

app.commandLine.appendSwitch('js-flags', '--expose-gc');


let mainWindow;

function createWindow () {
        mainWindow = new BrowserWindow({
            "width":          640,
            "height":         480,
        });

    mainWindow.loadURL(`file://${__dirname}/index.html`);
    // Open the DevTools.
    mainWindow.webContents.openDevTools();

    mainWindow.on('closed', function () {
        mainWindow = null;
    });
}

app.on('ready', createWindow);

app.on('will-quit', () => {
    // Unregister all shortcuts.
    globalShortcut.unregisterAll();
});

app.on('window-all-closed', function () {
    if (process.platform !== 'darwin') {
        app.quit();
    }
});

app.on('activate', function () {
    if (mainWindow === null) {
        createWindow();
    }
});

レンダラプロセス

'use strict';

var Game = function() {
    this.frame_count = 0;

    this.bullets = [];
};
Game.prototype.run = function() {
    requestAnimationFrame(this.run.bind(this));

    this.frame_count++;

    // create
    for (var i = 0; i < 100000; i++) {
        this.bullets.push(new Bullet());
    }
    // run
    for (var j = 0; j < this.bullets.length; j++) {
        this.bullets[j].run();
    }

    // reset
    this.bullets = [];

    if (this.frame_count % 600 === 0) {
        if (global.gc) {
            console.log("done gc");
            global.gc();
        }

        console.log(process.memoryUsage().heapUsed);
    }
};

var id = 0;
var Bullet = function() {
    this.id = id++;
    this.frame_count = 0;
};
Bullet.prototype.run = function (){
    this.frame_count++;
};

window.onload = function() {
    var game = new Game();
    game.run();
};

レンダラプロセスは、1フレーム毎に、Bullet オブジェクトを10万個生成しては、その場で破棄しています。
また10秒に1度、GC を実行して、それからヒープ領域の使用量を console.log で出力しています。

f:id:sairoutine:20170513220817p:plain

上記が実行結果です。10秒ごとに GC が実行されているため、
そしてGC 実行後のヒープ領域は常に最小になっています。

f:id:sairoutine:20170513220823p:plain

こちらが、js-flags を追加しなかった場合です。
追加しなかった場合、レンダラプロセスには global.gc() 関数は存在しないので、
GC は実行されずに、ヒープ領域の使用量も不定(レンダラプロセス側の v8 エンジン任せ) となっています。

最後に

この記事を書いていて思ったのですが、メモリ解放対象のオブジェクトがなくとも、
GC時のルートオブジェクトからマーク済みオブジェクトを探索していく処理が、
ゲームに影響を与えるレベルの処理だと上述の方法は意味ないですね…

v8 エンジンが何を持ってGCを走らせてるのか知りたいなと思いました。

告知ツイートをするときに気をつけていること／考えていること

こういった同人誌即売会において、 Twitter 告知をする際に、僕が気をつけていること／考えていることを 言語化して文章にまとめておきます。

僕は同人ゲームを作る人なので、同人ゲームの頒布の際の告知という前提があります。

メッセージ

入れなくちゃいけないもの

  1. いつ頒布するの？
  2. どのイベントで頒布するの？
  3. スペース番号
  4. 作品名
  5. 体験版 or 完成版？
  6. ゲームを一言で表す紹介文

なるべく入れた方がいいもの

  1. 委託があるかどうか
  2. (あれば)特設サイトURL

やるべきこと

  1. 関わってくれた人の名前を上げる

イラストや音楽を他の人に依頼したならば、その旨を、告知へのリプライなどで書きます。 作ってくださった方および、その方達のファンへの敬意を込めて。

告知時間

18~23時くらいに告知ツイートするのが、一番人がTwitterを見ている時間だと思うので、効果的だと思います。

ただ、休日はみんな外出しているからか、その時間はあまり皆Twitterを見ていないイメージ。

また、平日の12時も案外効果的(お昼休みで皆Twitterを見る)

というわけで告知時間は、平日の12時と、18~23時くらいが良さそう。

最初の告知日

イベント開催日からあんまり事前に始めても、みんなまだサークルチェックを行っていないので、 RTとかしてもらえないイメージ。

例大祭(東方Projectオンリー同人誌即売会)であれば、イベント日の3週間前から ちらほらと告知ツイートを見始め、2週間前〜1週間前くらいが告知ツイートの ピークのように見えます。

というわけで、イベント日の2週間前〜1週間前くらいには、 告知ができるようなスケジュールで制作を進められるといいですね。

告知頻度

あまりうっとおしくならないよう、1日1度、告知ツイートをセルフRTする。

サンプル画像

表紙 or パッケージに使うタイトル画像1枚 + ゲームのサンプル画像3枚。

同人ゲームは「中身のわからないものは買いたくない」というのが顕著なコンテンツなので、ゲーム内容についてはネタバレを極力恐れず、惜しみなく画像を提供する。

観点として、 1. どういうプレイをするゲームなのか？ 2. どういう点が魅力なのか？

がわかるように画像を選定します。

RT先の反応を見る

僕は、RTされたら、その人のホームを見に行っています。 何かしら告知ツイートに言及がされてるとスゴク嬉しいです。

RTやfavの反応があると、もっと反応が欲しいなあと思うし、 反面、ガッカリされないように頑張ります。

人からの反応を確かめるのは、こうしたコンテンツ制作における 心の栄養だと思います。

一方で、こうした承認は麻薬にも近く、 告知ってツイートしてからその日中、ちょくちょくRTやfavの反応があるので、 ついついTwitterを見てしまって作業が止まりがち・・・。これは反省。

告知は所詮告知

結局告知がどうだろうがゲーム本体の魅力がちゃんとないと、 ゲームは手にとってもらえません(当たり前ですが)。

他の人にもシェアしたくなるコンテンツというのは、 単純なクオリティの高さも一つの指標だと思いますし、 今のトレンドに沿っているとか、あるいは今までに無かった斬新さもあるでしょう。

告知は所詮告知。

最後に

これらは全て僕の所感であり、僕がただやってることに過ぎません。 もしもっとよりよい方法や知見があれば、教えて頂けますと幸いです。

ストレングスファインダーをやってみた

こんにちは、さいです。
ストレングスファインダーというツールがあります。
「あなたの強みを分析しましょう！」というツールです。
皆さんの中にも就職活動の際に、「あなたの強み分析」「適職診断」とかで
そういうのをやった人もいるかと思います。

ストレングスファインダーは、ああいったツールの、
もうちょいいい感じのアドバイスなり情報をくれるツールです。

さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす

さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす

上記の本を購入するとアクセスコードを手に言れることができて、
34の強みからあなたの強みTOP5を分析しますという診断が行える(アクセスコードは1度しか使えないので中古じゃダメだよ)。
さらに8000円ほど払うと、34の強みランキング全部見られる。

僕の診断結果は以下でした。

  1. 指令性
  2. 競争性
  3. 内省
  4. 収集心
  5. 達成欲

指令性

「指令性」という資質によって、あなたは主導権を握ります。ほかの人と違い、あなたは自分の考えを他人に強く主張することを苦痛とは感じません。それどころか、ひとたび考えが固まると、あなたはそれをほかの人に伝えずにはいられません。そしてひとたび目標が定まると、あなたはほかの人をそれに同調させるまで安心できません。あなたは対立に怯えることはありません。むしろ、対立は解決策をみつけるための第一歩であることを知っています。ほかの人は不愉快な状況に立ち向かうことを避けようとするかもしれません。ところが、「事実」や「真実」がどれだけ不愉快なことであろうとも、それを示さなければならないと感じます。あなたは、課題が人々の間で明確に理解されていることを求めます。従って、あなたは人に、偏った考えを持たず正直であることを要求します。あなたは彼らにリスクに挑戦することを迫ります。彼らを怖がらせることすらあるかもしれません。これを嫌って、あなたのことを頑固と呼ぶ人もいるかもしれませんが、一方で、進んであなたに主導権を握らせることもしばしばあります。人々は、立場をはっきりと示し、周りの人にもある特定の方向に向けて行動するように求める人に魅力を感じます。だから、人々はあなたに惹きつけられるでしょう。あなたには強い存在感があります。あなたは「指令性」を備えた人です。

おぉ、すごい、自分で自覚してたパーソナリティとピッタリ！
僕は周囲の人間より自分が一番確度の高いことを知ってる／決められるとかいう
だいぶ傲慢なことを思ってる人間なので、この「指令性」が高いというのは納得。

診断結果から、各強みの詳細な情報が見られるんだけれど、
そこで「指令性」について以下のように述べられてる。

指令性という資質を持つ人には、強い存在感があります。状況の主導権を握り、決断を下します。 危険に遭遇したときにも対処できる才能を持っていることを知っています

あーそうそう。現在／未来が不確定でも、確度を高く「決め」と「行動」が出来るのは 指令性が高い人の強みの一つだと思います。実は世の中の人の多くは、わからないことに対して、 「自分が決定を下して責任を追いたくない」「確実でないことに不安になる」といった思いを持っています。 そういった人たちに対して「こうすればうまく行くよ！」と、方針を立てて導けるのは「指令性」の高い人の強みの一つだと思います。

言った内容や言い方によっては、他の人を怖がらせることがあります。おそらくこの効果を利用して、他の人を動かして自分の要求を通しているでしょう。

そうそう。自分の言うことを相手に正しいと思わせるために、自分の影響力を高めようとするんですけど、 それは時として相手を萎縮させてしまうんですよね。正しいことは頭でわかってるんだけれど、身体で実行できないという心情が人間は往々にしてあるので、それに対する共感とか尊重は必要です。

自ら進んで障害を解消してください。他の人は物事を進めるために、あなたの自然な決断力に頼ります。 あなたが障害物を取り除くと、あなたなしではありえなかった新しい機運と成功を生み出すことも珍しくありません。

これは今まで自分は出来てなかったことだなって思います。「決定」が出来て、人をその方向に向かせることができること、そして「決定」を実行するに当たって邪魔な障害を取り除くことは大切にしていきたい。

大義を掲げ、それを貫きます。 抵抗勢力の中で大義を守り抜くという場面で優れた能力を発揮するでしょう。

これも自分は出来てなかったこと。大義を掲げるに当たって、人々が共感できる大義を作ることはとても大切なのですが、自分は出来ていないので、大義を掲げていきたい。

「指令性」に関するいくつかの文章を抜粋しましたが、まだまだたくさんあります。
読みながら、自分が出来ていること／出来てないことが明確になっていきます。

ちなみに、私の強みTOP5のうち、「指令性」以外の、4つですが、
「競争性」は人と切磋琢磨すること、「内省」は考えたり議論したりすること、「収集心」は、知識を求めること、「達成欲」は、多忙で生産的であることですね。

ソフトウェアエンジニアなので、「内省」「収集心」が高いことは納得なのですが、
「競争性」「達成欲」は、どちらかと言えば営業職とかそういうタイプっぽいのが面白いです。

というわけで、ストレングスファインダーの紹介でした。
全ての能力において万能な人はいません。自分の弱い部分は他人に補ってもらって、
自分の強い部分をより伸ばしていくことが、結果的に社会全体の効用最大化に繋がるのではないでしょうか。