Androidアプリケーション、デザイナーとプログラマーのハッカソン vol2が開催されました。

Androidアプリケーション、デザイナーとプログラマーのハッカソン vol2 が開催されました。

前回に引き続き第二弾です。

従来のハッカソンではプログラマーがメインとなるイベントですが、デザイナーさんも交えてAndroidアプリを作りました。

チーム分け

事前に用意したネタごとにチームを作りました。

時計やライブウォールペーパーなど、デザイナーさんの力が光りそうなアプリがあります。

ハッカソンの様子

各チーム席をくっつけ、ハッカソンスタートです

ライブウォールペーパーを作るチームは、すでにあるライブウォールペーパーを参考にしているようです

ノートにはラフ画が書かれています

ガシガシ画像作ってます

こういうソフト使える人に憧れます！

デザイナーと意思を疎通させるためには、手書きも便利ですね

発表資料を作っているようです

発表

チーム DQN 「DQN Clock」

メンバー

• @sobachanko(プログラマー)


• @MasaMura(プログラマー)


• @_erisan_(デザイナー)

カラフルでユニークな時計を作られていました。

マスコットキャラクターのDQNちゃん（ドキュンちゃん）がかわいく手を振ります

---

チーム 小学３年生 「電卓アプリ」

メンバー

• @miracle_sakura(デザイナー)


• @shogogg(プログラマー)


• @rukiadia(プログラマー)


• @ysenba(プログラマー)

見た目は普通だけど、なんと占いまでできてしまう電卓を作られていました。

占い機能と見た目はできたけど、ハプニングにつき完成には至りませんでした。

発表者曰く、「電卓は鬼門だから次からは辞めとけ」だそうですｗ

---

チーム MemoPad「MemoPad」

メンバー

• @zaki50(プログラマー)


• @b0ner_jp(プログラマー)


• @mstssk(プログラマー)


• 匿名希望(デザイナー)

このチームは@zaki50 さんがAndroidMarketで公開されている

MemoPadのデザインを、より良くしようと集結しました。

色を選ぶUIが、より分かりやすくなりました。

さらに描いた絵をNFCを利用してSmartTagに書きこむ機能まで追加！

すごい！

---

チーム La battle 「La 合戦」

メンバー

• @95kugo(プログラマー)


• @iwata_n(プログラマー)


• @katsummy(プログラマー)


• @miroc007(デザイナー)

チーム内に歴史が好きな人がいた事と、フランス人と仲良くなりたいという人がいたので

フランス人と仲良くなるための合戦ゲームを作っていました。

こんな感じで手裏剣を投げ合って

敵の大将を倒すと…

うちとったりーと表示されます

私もフランス人と仲良くなれるよう、遊んでみたいです。

---

チーム 左官「ライブウォールペーパー -天気-」

メンバー

• @itog(プログラマー)


• @tour_cossack(デザイナー)


• @mutotaiju(プログラマー)


• @cyberspacefarm(プログラマー)


• @m_moonly(プログラマー)

チーム左官は天気を表示するライブウォールペーパーを作りました。

和風テイストでとても綺麗です。

さらに画面をタッチすると、なぜか手裏剣が空を舞います

某合戦チームの影響だそうですｗ

---

チーム オレオレ詐欺 「oreoreゲーム」

メンバー

• 匿名希望(プログラマー)


• @Yuichi_Araki(プログラマー)


• @kame0_0(デザイナー)

チームオレオレ詐欺は、さめがめというゲームを作っていました。

この短時間で基本的なゲームの部分が完成していました。素晴らしい！

石を消すと気持ちいい音が鳴るのも特徴でした。音はなかなか気づかないですが重要ですよね。

投票

全員に一人5票で投票してもらいました。

結果は…

• 1位 オレオレ詐欺 oreoreゲーム 41票


• 2位 La battle La合戦 30票


• 3位 MemoPad 27票

おめでとうございます！

その他

Androidアプリ　デザイナーとプログラマーのハッカソン vol.2 - Togetter

http://togetter.com/li/253227

参加者リスト

https://twitter.com/#!/bs_android/dpthon2

---

文責：技術部　山下 智樹

App Analytics

Are you looking for a way to learn how your users use you app, retention rate, error logging, etc?

This website introduce 7 different solutions. Personally, I only have experience with Flurry and Google Analytics. I'm very pleased with Flurry and even though some of the other services also look good, I feel no need to try them. (This is not a review, only a recommendation...)

Flurry Analytics

Flurry can be used in iOS, Android, Blackberry, Windows Phone, JavaME and HTML5.

The API is super easy to install and use and compared to Google Analytics which is originally made for webpages and not really adapted to mobile apps, Flurry is designed for mobile apps. For example, if you use a UITabBarController or UINavigationController, you can with one line of code in your app delegate track all "page" views controlled by that controller.

The free analytics package is all you need to get all plenty of feedback on how your app is doing out there.

Check the webpage by clicking the logo above for more information.

Objective-C and iOS - Online learning resources

If you have some experience with objective oriented languages and want to learn Objective-C, or if you already started learning Objective-C but want to learn more from a great instructor, I have a tip for you.

Stanford University publishes their iOS App Development lectures on iTunes U, for anyone to download. Both HD videos and lecture notes are available.

There is material available from older quarters if you want to go for Xcode 3 and iOS 4. New material from 2011 is also available, which includes iOS 5, Xcode 4, Storyboard, iCloud and other new features of iOS 5.

The instructor is Paul Hegarty. He explains very well and makes the videos enjoyable to watch. You will learn not only the technical part of iOS and Objective-C but also how to create user friendly apps, what to avoid and best practices. One of the best instructors you can get.

I've watched all videos from both quarters below and even if you've seen Fall 2010 I highly recommend Fall 2011 because there is plenty of new information about the new features of iOS 5.

For iOS 4, please look at: Fall 2010

For iOS 5, please look at: Fall 2011

If you're looking for a good book, I can recommend this one. It explains in detail how Objective-C works and will give you a good insight into the language. -Link to Amazon-

キーガード中のNFC動作 GingerBread と Ice Cream Sandwichの違い

Nexus SをAndroid 4.0.3にUpdateしました。
波形をとりながら動作確認中を行ったところ、面白い発見をしたので記事にしました。


キーガードロック画面のNFC動作
まずはAndroid2.3.6 GingerBread版Nexus Sの波形です。

電源キーによりスクリーンOFF → ONを行いキーガードロック画面を表示しました。
スクリーンON中はNFC電源ONになり、その波形が現れています。
約5秒後、再びスクリーンOFFになりました。


次はAndroid4.0.3 Ice Cream Sandwich版Nexus Sの波形です。

同じ操作でキーガードロック画面を表示しました。
しかし、スクリーンONになってもNFC電源ONの波形が現れません！

どうやら、ICSの変更でキーガードロック中はNFC電源が入らないように修正されているようです。


プログラムを確認してみましょう。
まずは、Android2.3.6 GingerBreadのプログラムです。
スクリーンON/OFFの動作処理を行っているのは以下のファイルです。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

private class EnableDisableDiscoveryTask extends AsyncTask {
        @Override
        protected Void doInBackground(Boolean... enable) {
            if (enable != null && enable.length > 0 && enable[0]) {
                synchronized (NfcService.this) {
                    mScreenOn = true;
                    applyRouting();
                }
            } else {
                       :
            }
            return null;
        }
    }

    private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
                       :
            } else if (intent.getAction().equals(Intent.ACTION_SCREEN_ON)) {
                       :
                new EnableDisableDiscoveryTask().execute(new Boolean(true));
            } else if (intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
                       :
        }
    }

以下の処理により、電源ONになりNFCタグ受信待ち状態となります。

1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
2. EnableDisableDiscoveryTask().execute()をコール
3. applyRouting()をコール
4. mManager.enableDiscovery(DISCOVERY_MODE_READER)をコール

つぎは、Android4.0.3 Ice Cream Sandwichのプログラム確認。
\packages\apps\Nfc\src\com\android\nfc
- NfcService.java

/**
     * Read mScreenState and apply NFC-C polling and NFC-EE routing
     */
    void applyRouting(boolean force) {
        synchronized (this) {
                       :
            // configure NFC-C polling
            if (mScreenState >= POLLING_MODE) {
                if (force || !mNfcPollingEnabled) {
                    Log.d(TAG, "NFC-C ON");
                    mNfcPollingEnabled = true;
                    mDeviceHost.enableDiscovery();
                }
            } else {
                if (force || mNfcPollingEnabled) {
                    Log.d(TAG, "NFC-C OFF");
                    mNfcPollingEnabled = false;
                    mDeviceHost.disableDiscovery();
                }
            }
        }
    }



    class ApplyRoutingTask extends AsyncTask {
        @Override
        protected Void doInBackground(Integer... params) {
            synchronized (NfcService.this) {
                if (params == null || params.length != 1) {
                    // force apply current routing
                    applyRouting(true);
                    return null;
                }
                mScreenState = params[0].intValue();

                boolean needWakelock = mScreenState == SCREEN_STATE_OFF;
                if (needWakelock) {
                    mWakeLock.acquire();
                }
                applyRouting(false);
                if (needWakelock) {
                    mWakeLock.release();
                }
                return null;
            }
        }
    }

    private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
                       :
            } else if (action.equals(Intent.ACTION_SCREEN_ON)
                    || action.equals(Intent.ACTION_SCREEN_OFF)
                    || action.equals(Intent.ACTION_USER_PRESENT)) {
                // Perform applyRouting() in AsyncTask to serialize blocking calls
                int screenState = SCREEN_STATE_OFF;
                if (action.equals(Intent.ACTION_SCREEN_OFF)) {
                    screenState = SCREEN_STATE_OFF;
                } else if (action.equals(Intent.ACTION_SCREEN_ON)) {
                    screenState = mKeyguard.isKeyguardLocked() ?
                            SCREEN_STATE_ON_LOCKED : SCREEN_STATE_ON_UNLOCKED;
                } else if (action.equals(Intent.ACTION_USER_PRESENT)) {
                    screenState = SCREEN_STATE_ON_UNLOCKED;
                }
                new ApplyRoutingTask().execute(Integer.valueOf(screenState));
            } else if (action.equals(ACTION_MASTER_CLEAR_NOTIFICATION)) {
                       :
        }
    }

以下のように処理が変更され、スクリーンONでは電源ONとなりません。

1. スクリーンONのIntentであるIntent.ACTION_SCREEN_ONを受信する
2. mKeyguard.isKeyguardLocked()でキーガード状態かどうか確認する
3. キーガード状態の場合、SCREEN_STATE_ON_LOCKEDを引数としてApplyRoutingTask().execute()をコール
4. applyRouting(false)をコール
5. mScreenStateがSCREEN_STATE_ON_LOCKEDなので、mDeviceHost.enableDiscovery()はコールしない

電源ONとなるタイミングはIntent.ACTION_USER_PRESENTを受信した時、
つまり、キーガードが解除された時に電源ONとなります。

Lion + Kaspersky + Xcode = Trouble...

Kaspersky Endpoint Security, which claims to be compatible with Lion, apparently is not.

Before upgrading to Lion I had no problems with Xcode or other application freezing and becoming "not responding". After upgrading, Xcode, which I use all day in my work, often freezes, sometimes other applications too. Usually it returns to normal state if I wait 1-5 minutes, but sometimes not and unsaved data is lost when I have to force quit Xcode (before I discovered how to quit Kaspersky's process). The really bad thing is that it's when saving that Kaspersky locks up the saving application so the chances of loosing valuable work is high.

If you are required to run Kaspersky on your Mac, I recommend that you do not upgrade to Lion until Kaspersky has fixed to support Lion's Autosave and Versions.

If Xcode or any other application locks up, open "Activity Monitor" and quit the process "kav". This will release the lock on the frozen application but (it looks like) Kaspersky will automatically restart so you have to repeat this every time an application freezes when saving data.

I'm not alone:

From Kaspersky Forum 1 

From Kaspersky Forum 2

Cocoabuilder.com: Xcode4 and Lion causes freezes when saving
Stackoverflow.com: Xcode is very slow to save a file frequently beach balls

Waiting for a fix...

Auto incrementing build number in Xcode

In one of my apps I have data as csv files in the bundle and at when the app is run for the first time I parse these files and create a database using Core Data. During development I often added more data to the csv files, adjusted the Core Data classes and so on, so I needed a smooth way of telling whether the app was run for the first time or not since the last build so I can reconstruct the database.

I first tried another solution that didn't require the target name "MYTARGET" in the script which means you don't have to customize the script for every project but I couldn't get that to work in Xcode 4.2 but here is a script that works great for me. I will link to the source if I remember it later.

In the project navigator, select your project and then your target to the right.
In the "Info"-tab, create a new "Custom iOS Target Property" called "BuildNumber" and let it be a string.
Select the tab "Build Phases" and "Add Build Phase" down to the right.
Select "Add Run Script" and set the shell to "/bin/bash"
Paste in this script: (replace MYTARGET with the name of your target (usually same as name of project)

#!/bin/bash

buildNumber=$(/usr/libexec/PlistBuddy -c "Print BuildNumber" MYTARGET/MYTARGET-Info.plist)

buildNumber=$(($buildNumber + 1))

/usr/libexec/PlistBuddy -c "Set :BuildNumber $buildNumber" MYTARGET/MYTARGET-Info.plist

bundleShortVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" MYTARGET/MYTARGET-Info.plist)

bundleVersion=$bundleShortVersion"."$buildNumber

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" MYTARGET/MYTARGET-Info.plist

Now, each time you build your app the variable "BuildNumber" will be increased by 1 and your bundle version will be set to Version.BuildNumber. That is, if your app version is 1.0 and your on build number 8, the bundle version will be 1.0.8.

If you, in your app delegate or elsewhere, want to check if the "BuildNumber" has changed since the last run by comparing it with the last value, stored in NSUserDefaults, do something like:

int thisVersion = [[[[NSBundle mainBundle] infoDictionary] objectForKey:@"BuildNumber"] intValue];

int lastVersion = [[NSUserDefaults standardUserDefaults] integerForKey:@"lastVersion"];

[[NSUserDefaults standardUserDefaults] setInteger:thisVersion forKey:@"lastVersion"];

BOOL appIsNewVersion = lastVersion != thisVersion;

And there, you have a smooth, automated way of telling if you're on a new build and do the proper initializing, etc.

First post, logging.

My first post. I guess it would be a good a idea to share what I do whenever I start a new project in Xcode.

It has kind of become a habit of mine to log to console at almost every method for easy bug tracking. However, using NSLog doesn't show you what method unless you do something like:

NSLog(@"MyViewController:viewDidLoad");

Which is rather cumbersome when you add logging to many methods. This is where my savior comes into the picture.

By adding the following to your "MyApp-Prefix.pch" file in the "Supporting Files"-group

// DLog is almost a drop-in replacement for NSLog

// DLog();

// DLog(@"here");

// DLog(@"value: %d", x);

// Unfortunately this doesn't work DLog(aStringVariable); you have to do this instead DLog(@"%@", aStringVariable);

#ifdef DEBUG

# define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

#else

# define DLog(...)

#endif

// ALog always displays output regardless of the DEBUG setting

#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

you can use ALog (always log) and DLog (debug log) for a rich debug logging.
Simply putting DLog(); in your viewDidAppear method will output something like:

[MainViewController viewDidAppear:] [Line 169]

Even showing the line number where in your source code the line was executed. And don't worry about performance or similar, when compiling for release DLog(); is defined to nothing so there will be no logging going on.

The blog post where I found this information is >>here

標準ブラウザ

省電力評価
★★☆☆☆



アプリケーション概要
Android端末に標準に搭載されているブラウザアプリです。

Android Market : 登録なし
Version : 2.3.6



計測条件
・SIMカード：なし (3G通信なし)
・壁紙設定：壁紙
・Wi-Fi設定：ON
・Bluetooth設定：OFF
・GPS設定：OFF
・NFC設定：OFF
・バックグラウンドシンク設定：OFF
・現在地情報：無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数

プロセス	?
サービス	?

※(別途、調査します)


アプリケーション起動中の使用機能

機能	使用
ネットワーク通信	○
GPS	○
WIFI制御	×
バッテリー情報取得	×
Bluetooth	×
カメラ起動	×
NFC	×
WakeLock使用	○

アプリケーション起動時の電力測定
ブラウザ起動後、通信を行っていない状態の波形です。

ブラウザ起動後、スクリーンOFF状態の波形です。

ブラウザ起動後、無通信状態ではHome画面表示中とあまり変わりませんでした。


次はブリリアントサービスのHPを表示させたときの波形です。
(※WiFi通信)
通信を行い画面更新が完了するまでの約3秒間、消費電量が上昇していることがわかります。

Google検索の結果画面で上下に激しくスクロールを行いました。



　




次はGoogle画像検索の結果画面で上下に激しくスクロールを行いました。

　
　


Google検索結果画面は 約0.2～0.4A、
Google画像検索結果画面は 約0.3～0.45A、
と、画像表示あり/なしで消費電力に差異がありました。



考察
スクロールを行う際、画像の有無で省電力に差異があることがわかりました。
標準ブラウザの計測データを基に、他のブラウザアプリと消費電力の比較を行います。

モバイルGoogleマップ

省電力評価
★☆☆☆☆



アプリケーション概要
スマートフォンといえば、Googleマップ。このアプリのお陰で迷子にならなくなりました。
家に居ても、3Dマップ表示で世界中旅するのも楽しいです。
ただ、外出中に使用することが多く、どうしても電池の消費が気になりますね。

Android Market : http://market.android.com/details?id=com.google.android.apps.maps
Version : 5.12.0



計測条件
・SIMカード：なし (3G通信なし)
・壁紙設定：壁紙
・Wi-Fi設定：ON
・Bluetooth設定：OFF
・GPS設定：OFF
・NFC設定：OFF
・バックグラウンドシンク設定：OFF
・現在地情報：無線ネットワークを使用 ON、GPS機能を使用 OFF



プロセスとサービスの使用数

プロセス	1
サービス	2

アプリケーション起動中の使用機能

機能	使用
ネットワーク通信	○
GPS	○
WIFI制御	○
バッテリー情報取得	×
Bluetooth	×
カメラ起動	×
NFC	○
WakeLock使用	○

アプリケーション起動時の電力測定
Google マップ起動中の波形です。
WiFi設定ON中の待ち受け画面 よりも波形が乱れ、一定間隔で0.300Aを超えていることがわかります。

現在地表示中の波形です。
通常マップ表示中とあまり変わりませんでした。

現在地でかつ3D表示中の波形です。
常に0.300Aを超え、明らかに消費電力が上がっていることがわかります。
端末を持つ手が少しでも揺れると、画面も揺れてしまいます。
3D表示を行うために、センサー系がフル稼働していることも原因の一つだと考えられます。

スクリーンOFF時の電力測定
Googleマップ起動中にスクリーンOFFした波形です。
通常マップ表示、現在地表示、現在地3D表示ともに以下のような波形でした。

考察
オシロスコープの波形をみると、マップの現在地3D表示中の消費電力が明らかに高いことがわかりました。
XYZの3軸の値からマップ表示を行う際、計算量が増加するのに加え、頻繁に画面更新しているのが原因の１つだと考えられます。
ただ、スクリーンOFFになるとWiFi設定ON中の波形と変わらないことから、無駄な電力消費を行っていないのはさすがGoogle純正アプリだと思いました。

外出中の「3D表示」には気をつけよう。

魔王再臨『Android Make Days』にNFC QUESTを出展します

魔王、またblog執筆。

NFC QUEST 広報兼魔王の、魔王です。

そうです また私です。なんだか魔王業よりも広報の方が本業なんじゃないか？

とじっと掌を見つめるような気持ちにもなっていました が ところがどっこいですよ！

2011/11/11(金)-12(土)に福岡で開催されるAndroidとモノづくりの祭典『Android Make Days』に「NFC QUEST」を出展することになりました！

そうです 再び皆様と 滅ぼし滅ぼされることができるのです！

福岡の皆様 わたし心を込めて豪腕を振るい 皆様を滅ぼします。

皆様もわたしをたくさん滅ぼしてくださいね！魔王との約束です。

そしてそして ついでと言っては何ですが

なんとNFC QUESTのyoutube動画ができました！

誰ですか？こんな素敵な動画をつくったのは？…ふふふ なんてね そうです。わたしです。

思わず自作自演をしてしまいましたが、わたしの勇姿（時に滅ぼし時に滅ぼされ…）

がばっちり写っていますので、是非みなさん見てみてください。

以上 魔王でした。

（*NFC QUESTスタッフ注）

『Android Make Days』当日はカードとGoogleアカウントの連動登録と

魔王と戦えるバトルゲームのみの縮小DEMO出展となります。

会場内でのチェックポイントを探してのレベルアップシステムは今回は用意しておりませんので

あらかじめご了承下さい。

職業毎に用意したスタッフカードと組み合わせゲームクリアができるように調整しておりますので

組み合わせパターンでの変化をお楽しみ下さい。

NFC設定ON/OFFの違いを確認する

NFC設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件：
・壁紙設定：壁紙
・Wi-Fi設定：OFF
・Bluetooth設定：OFF
・GPS設定：OFF
・NFC設定：ON/OFF
・バックグラウンドシンク設定：OFF

1.Home画面

NFC設定OFFの波形です。
約0.10Aでした。

NFC設定ONの波形です。

一定間隔で約0.15Aを超えていることがわかりました。

2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
NFC設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。

NFC設定ONの波形です。

設定OFFの波形と変化が見られませんでした。
(※少しノイズが混じっているようにも見えますが誤差の範囲だと思います)

3.まとめ

NFC設定をONにしていると、スクリーンON中はNFCチップの電源が入りっぱなしのため、消費電力が上がっているようです。
ただ、スクリーンOFF中はNFC設定ON/OFFどちらも消費電力に違いが見えませんでした。
スクリーンOFF中は誤作動防止＆省エネのため、NFCのチップの電源をOFFに切り替えていると考えられます。

NFC利用時のみ、設定をONにすれば電池持ちが良くなると思います。
NFC設定切り替えウェイジェットがあれば便利かも！！

『NFC QUEST』 @ Google Developer Day 2011Japan リポート

魔王、blogデビューです。

NFC QUEST 広報兼魔王の、魔王です。

役目を終えてきえる…などと言っておきながらまた現れてしまいました。

ごめんなさい。きえるきえる詐欺してしまいました。

まさかのblogに召喚されてしまい…いや、違いますね。

再びみなさんと会えた事を素直に喜びましょう！ここは！

ヤッホー！みなさんこんにちは。魔王です！はじめましての方ははじめまして。

私、ふだんは人々を滅ぼしたり逆に勇者に滅ぼされたりすることを生業にしています。

しかし今日は、私が降臨したGoogle Developer Day 2011(以下GDD)でのNFC QUESTの様子をリポートしたいと思います。

当日は私の下僕が、朝8時から設営に入りました。

画面を見てお判りの通り、私はAndroid界を征服しております。

具体的にはシャープ様のNFC搭載タブレット「RW-T107」を使用させて頂きました。

これらがGDDの会場に散りばめられたチェックポイントです。

これをタッチしていくと、みなさんのレベルが上がり、そして私は滅ぼされる。

と、こういう寸法なわけですね。

さて、みなさんはどれぐらいレベルをあげてくれるのでしょう？

果たしてわたしは滅ぼされるのか？

私、滅ぼされなかったらどうしよう。

空気読めずに勝ち続けちゃったらどうしよう…などと思っていました。

この時は、まだ。

そして、設営完了！ついにみなさんとの対面です。

わたしはロゴの裏に待機していますよ。

チラリと見えますね。

しかし今だから言いますが、魔王ドキドキし過ぎてて足が震えていました。

これがゲーム中の私です。どうですか？強そうでしょうか。

普段とは違い、かなり相当かんじの悪いセリフをみなさんに浴びせていましたよね。

「見積もりが甘い！」とか。

でも、みなさんはひどいセリフほど喜んでました。

なぜでしょう？人格者過ぎます。

GDDの休み時間には、大勢の方が私に会いに来てくれました。

今だから言いますが、正直私やスタッフ達の予想を大幅にこえる盛況ぶりだったのです！

こんなに遊んでもらえるなんて、魔王感無量です。

みなさんのレベルも想定よりずっとずっと高く、私あっというまに滅ぼされてしまいました。

いささかカンタンにやられ過ぎの感も否めませんでしたが…

歯ごたえのない魔王で申し訳ありませんでした。精進します。

最終的には580人の方に登録いただけました。

3桁いけたらいいほう、などと言っていたのは誰ですか？…私ですね。

なめてました。

勇者なめてました。

見積もり甘いのはどっちだ！って話ですよね。

ともかく、皆さんたくさん私と戦ってくれて、ほんとうにほんとうにありがとうございました！

いかがでしたでしょうか『NFC QUEST』楽しめていただけましたでしょうか？

平和に退屈した民たちの魔王・待望コールの高まりいかんによっては、再び召喚される日もあるやもしれません。

その時はまた私を滅ぼしてくださいね。

魔王も大魔王ぐらいにはなれるよう、がんばります。

以上、魔王が報告いたしました。

@nfc_quest