週末のアプリ作成

androidアプリ個人開発者の実態を報告します。アプリの収入も公開中です♪

子供の頃に思った「FF4」や「第四次スパロボ」の疑問を考える(プログラミング)

ゲームで感じた疑問。実はプログラミング言語と深い関係があった!!

 

こんにちは、TF's appsです。

今回は【ゲーム】【プログラミング】についての記事です。

 

ふと、なつゲーのYouTubeを見ていて思い出した事があったので書いてみました。

私の少年時代はゲームそのものでした。

 

ドラクエ6をその日初めてプレイして、その日のうちにムドーを倒すところまで進めた事を未だに覚えています。朝から晩までずっとゲームしていたと思います。

 

子供の時に「何でだろう?」っと思っていた事が、今では「なるほどなぁ」と思うことがあったのです。そんな事を紹介したいと思います。

 

ファイナルファンタジー

従兄に教えてもらったアイテム増幅の裏技「た5」

特定の操作をすることでアイテムが1個→255個に増えます。

世に1本しかない聖剣エクスカリバーを「た5=255個」にして、エッジに毎回のように「なげる」コマンドを使用させ、聖剣をそこら辺の石ころのように投げ、モンスターに9999ダメージを与えていた頃を思います。

f:id:TFs_apps:20190526182950p:plain

子供の頃、なぜ255なんだろう?と思っていました。上限は99個じゃないの?

プログラムとして、アイテムの上限数は99ですが、メモリとしては「unsigned char=1byte」で確保されていたのでしょう。

 

 

第四次スーパーロボット大戦

主人公(Lv90)をスーパーロボット系にして、精神「奇跡」を使用し、最終強化した計都羅睺剣・暗剣殺(けいとらごうけん・あんけんさつ)を使用してラスボスに65535ダメージ(カンストを与えたことを覚えています。

 

f:id:TFs_apps:20190526183030j:plain

子供ながら、なぜ65535という中途半端はダメージなのか?99999ではないの?

おそらくダメージは「unsigned int=2byte」でメモリ確保されているのでしょう。

 

どちらもスーパーファミコンのソフトです。

スーパーファミコンは16bitのCPUマシンです。

 

私の本業は組み込み系のソフト技術者です、15年程前の低スペックマシンのプログラムを実装する場合は、メモリを最小限に抑える事や、全体のプログラム容量を抑えることに気を遣いながら設計しています。union(共用体)を駆使して1bit単位にメモリ定義したものです。

 

今はそんな心配をしなくて良いような時代が来ていますが....

 

今となっては当たり前のように感じることですが、上記2つはどちらも子供の頃は不思議で不思議でどこからその数字が来るのか?と思っていました。

大学生になりプログラミングを覚えると、あ~なるほどと感じたことを今でも覚えています。

 

子供頃にプレイしたなつゲープログラマー目線でプレイしてみると、意外とまだまだ裏技が出てくるのかもしれませんね(笑)

 

ではまた次回お会いしましょう♪

 

 

 

 

 

 

 

 

 

アプリ収入 広告 Google

こんばんわ、TF's appsです。

今回の記事はGoogle様から2度目の入金がありましたのでその報告をいたします。

 

なんとその額・・・

¥9,068-

f:id:TFs_apps:20190521224135p:plain

 

↓↓関連記事です(初給料)

www.tfsappsone.com

 

いや~

やっぱ嬉しいですね

 

アプリを作ろうと決意して2年9カ月(=33カ月)・・・

 

今までの総収入と開発期間で算出すると、

¥18,055 ÷ 33カ月 = 月収¥547- 

 

う~ん・・・

まぁ私の実力ではこんなものでしょう(汗)

 

因みに本業との月収差は歴然たるものです(涙)

 

しかし~

ここ数カ月のアプリ収入は右肩上がりの傾向です。

これからもしばらく成長すると読んでいます。

 ↓↓詳しくは下記の記事です(月収推移)

www.tfsappsone.com

 

アプリ収入の一つの特徴として

DL数が増えていくとじわじわ広告収入も増えていきます。

いかにアクティブ端末数を持続して確保しておくかだと思います、だから私はツール系アプリを公開しています。ツールアプリはその人の生活において必要だからDLされます、ゲームアプリのようにクリアしたから、飽きたからという理由ではアンインストールされない傾向です。

 

個人的な見解ですが、ツール系アプリの開発をお勧めします♪

(ゲーム系アプリの良さも勿論あります、やっぱ作るのが楽しいです!!)

 

 

う~ん早く次のアプリをリリースしないとなぁ

次の種を早期に蒔けるように今後とも週末のアプリ作成を進めていきます。

今後も継続してアプリ収入の実態報告をしていきます。

 

では、また次回お会いしましょう♪

アプリ収入 広告

こんばんわ、TF's appsです。

さて今回は【アプリ収入】について紹介します。

 

あるアプリにスポットを当てたいと思います。

 

ちなみに私の作成したアプリで一番の広告収入を叩き出している「価格比較 どちらがお得」アプリの推移はこちらの記事で紹介しています。興味のある方はこちらも覗いて下さいね♪

www.tfsappsone.com

 

今回紹介するアプリはこちらです!!

【獣対策 ※熊よけ(熊鈴)、猪よけ、猿よけ】

play.google.com

 

熊鈴アプリです。

Google Play「熊鈴」と検索すれば1位でヒットされます。

他の類似アプリと違うところは、単に鈴を鳴らすだけでなく、雷鳴や銃声も鳴らすことができます。また、万が一獣と睨めっこ状態となった時、携帯を振れば雷鳴とLEDを光らせ、獣を驚かすことができる点です。

 

前置きが長くなりましたのでそろそろ本題にいきます。

そんな熊鈴アプリの広告収入インストール数を紹介します。

 

↓下記グラフが単月当たりの広告収入とDL数の推移です

f:id:TFs_apps:20190520220628p:plain

 

◆傾向分析

広告収入    ▶▶ 春から秋に活発

インストール数 ▶▶ 春から秋に活発

 

◆累積

広告収入    ▶▶ ¥4,847-

インストール数 ▶▶ 2,332 (DL)

 

リリースしてから約2年です。

広告収入とインストール数が多いか少ないかと言われると読者の皆様にお任せします。

このアプリは登山シーズンとマッチして推移します。春から秋にかけて広告収入もインストール数も増える傾向がグラフからも分かります。

 

二年でこんなものかぁって感じと思われる方もいらっしゃると思いますが、昨対比注目すると凄いことになります。

 

◆広告収入 昨対比(%)

2019年3月 ¥230-

 ▶▶▶ 1,277%

      (2018年3月:¥18-)

 2019年4月 ¥429-

 ▶▶▶ 2,383%

      (2018年4月:¥17-)

2019年5月 ¥723- 途中

 ▶▶▶ ,016%

      (2018年5月:¥40-)

 

私もこの記事を書きながら今後を期待しています。

 

私の作るアプリはスペシャルなものではありませんので、地道に少しずつ成長する傾向が多いです。じわじわ伸びていくのでこれからも楽しみです。

 

私の実体験です。やはりリリースしてすぐにヒットするのは難しいです。

 

これからも定期的にアプリ収入とインストール数を紹介していきます。

ではまた次回お会いしましょう♪

 

 

アプリ作成 テスト 効率的な評価

こんばんわ、TF's appsです。

今回の記事は【テスト】について紹介します。

 

本業でもそうなんですが、実はわたし・・・・

テストが大っ嫌いです(汗)

 

f:id:TFs_apps:20190517221717p:plain

デバッグレベルで動作確認するのは好きなんですがねぇ

 

でも【テスト】が十分でなければ、品質は落ち、ユーザーに満足に使ってもらえないですよね?つまりはユーザー離れに繋がります。

 

そうだから【テスト】はとても大事です!!

 

でも・・・

一般的に設計者は自分が作成したソフトの評価は弱いと言われています。

個人開発者であれば「なおさら」だと思います。

 

そのソフトに一番詳しい人がなぜ弱いのか?

それは「一番詳しいがゆえに甘くなる」と言ったら良いでしょう♪

 

 

◆中身をよく知っているため

1.テストケースが最小パターン

 (こことここを見たら大丈夫と思いがち)

 

2.客観性が乏しい

 (使い方が自分視点となり、自分の操作視点で評価する)

 

3.品質基準が妥当でない

 (自分の品質基準でOKと判断してしまう)

 

・・・などなどが考えられます。 

 

私個人の見解ですが、個人開発者はQCDというと「D(納期)」最優先で活動していると思います。

f:id:TFs_apps:20190517221757j:plain

ある意味、最小の設計コストで最大の成果物を世に出しているわけで「D(納期)」視点で考えると最良と言えます(^^v)

 

・・・

しかし

・・・

 

「Q(品質)」視点で考えると、最悪と言えます。

 

ここで私なりの評価術を紹介します。

(1)評価にはカバレッジ(コード網羅率)を意識する!!

(2)リリース前に友人や家族に使ってもらい意見を聞く!!

 

 

(1)カバレッジ?コード網羅率?

すごく簡単に紹介しますと、if文とelse文の両方を必ずみるという事です。分岐があれば少なくとも両方を通るパターンは最低見るというものです。

 

(2)第三者評価

レビューはすごく大事です。どんなスーパーマンでも必ず欠陥があります、だからこそ人が造るこの世界は科学が発展してきたとも言えます。色んな人の意見が詰まったソフトは鉄から鋼のように堅牢となり、安心のできる品質になります。

 

如何でしたでしょうか?

今回は効率的な評価に触れてみました。参考になるところがあればぜひ取り入れて下さい。では次回またお会いしましょう!!

アプリ素材

こんばんわ、TF's appsです。

ここしばらくは別記事の投稿が多くありましたので本業の記事に戻ります♪

今回は【アプリ素材】について紹介します。

 

最近のブログテーマは【プログラミング教育】でした。こちらも興味のある方は覗いて下さいね↓↓

tfs-apps.hatenablog.com

 

アプリを作成するには・・・

まず必要となるのはそのアプリの顔となる【アイコン】がありますよね?

ゲームであればキャラクターや敵などの【素材・絵】が必要ですし、音を使うのであれば効果音やBGMなどの【素材・音】が必要です。

 

全て自作は辛いですよね?

世にある素材(無料or有効)を効率良く使用することが、良いアプリになるには必須といえるでしょう。

 

世の中には良い素材が溢れています、自分の目的にあった素材を探すのも、アプリ開発者にとって非常に重要な設計の一部と言えます。

 

デザインの良し悪しでDL数も大きく影響します。

 

とは言え本当に必要な場合は自作するしかない!!

欲しいデザインがなければ作るしかないので(汗)

 

私のアプリ処女作となった【防犯アラーム&助けメール送信(現在地付き) 災害や犯罪対策】アイコンは自身で作成しました(笑)

<作成したアイコン>

f:id:TFs_apps:20180603133320p:plain

真っ白なキャンバスから作成したので個人的には一番印象に残っているアイコンです。windowsOSならプレインストールされている「ペイントソフト」を使用して作成しています。1ドットずつ色を塗っていったのを覚えています。

↓↓作成秘話はこちらの記事で。

tfs-apps.hatenablog.com

 

また私のゲームアプリ処女作【ミサイル シューティング (育成 弾幕 シューティングゲーム) Barrage Fighter】機体や弾丸(ミサイル)はフリー素材をベースにして作成しています。爆発絵に関しては自作です。

<作成した各種ゲーム素材>

 ------------------------

機体

f:id:TFs_apps:20190512214803p:plain

------------------------

ミサイル

f:id:TFs_apps:20190512214816p:plain

------------------------

爆発

f:id:TFs_apps:20190512214831p:plain

 ------------------------


↓↓ゲームアプリ作成秘話を公開

tfs-apps.hatenablog.com

 

 ゲームプログラミングしているよりも、素材を作成する方が楽しくて、夢中になった事を覚えています。これらも基本ペイントソフトで作りました。

 

さすがに音の作成は今のところ無しです。個人的には興味はあるのですがねぇ。

 

下記はお世話になっているフリー素材の提供元です。

いつも利用させて頂いています。ありがとうございます。

 

如何でしたでしょうか?

今回はアプリ素材についての紹介でした。

 

ではまた次回お会いしましょう♪

 

プログラミング教育

こんにちは、TF's appsです。

引き続き【プログラミング教育】に紹介します。

今回は【仕様設計】についてです。

  

↓↓興味のある方は関連記事があります

tfs-apps.hatenablog.com

 

tfs-apps.hatenablog.com

 

では本題に入ります。

【仕様】とは・・・

特に、作るものに関し要求する、特定の形状・構造・寸法・成分・精度・性能・製造法・試験方法などの規定。

 

プログラミングの世界においても同様で「要求」に対するソフトの性能と言えるでしょう。

 

 

「ソフトの性能?」

作り手の立場からしたらここまでの性能は保証するというものです。

つまりは品質を保証する条件提示と言えます。

 

使い手の立場からしてみたら安心だと思う条件であり、時には不満と思う条件にもなります。

 

<例1:気に入ったPCゲームがありインストールしようとしたが、説明文を見ると対象OSがwindows8となっている。>

◆作り手の立場

「ゲームが正常に動作できるのはwindows8」までと条件付けをした。

■使い手の立場

安心「windows8ユーザーの場合は動作保証内だ」

不満「windows10ユーザーの場合はなんだゲームできないんだ」

 

<例2:ソーセージを購入。賞味期限が2週間後となっている。>

◆作り手の立場

「美味しく食べれる期間は今日から二週間」までと条件付けをした。

■使い手の立場

安心「二週間までは美味しく食べれる」

不満「1カ月は食べれると思っていた」

 

いずれにしても「仕様」は 製品としての性能を提示する大事なものです。

ここで重要なことはソフトにおいて「仕様範囲内」であるのにその性能を満たさないものは「バグ」となります。

では「仕様範囲外」であるものに対してその性能を満たさないものは「性能?バグ?」どちらでしょうか?

 

仕様範囲外の性能をいかに「仕様設計」するかで性能にもなるし、バグにもなると言えます。

f:id:TFs_apps:20190512093454p:plain

 

では具体例をどうぞ 

 

<例3:デジタル気温計を作って下さい>

(仕様)-10~40度まで計測が可能です

→ 20度で稀に正常に気温が表示できない場合ある(バグ)

→ 41度の時「-41度」と表示してしまう(性能?バグ?)

あなたが作り手だった場合、仕様範囲外だし、41度は「-41度」になっても仕方がないと、使い手に説明できるでしょうか!? 

できませんよね?常識的に考えたらバグになりますよね?

 

<例1>でwindows10ユーザーが誤ってwindow8のソフトをインストールし、以降、PCが全く起動できなくなったら怒りますよね?

 

<例2>で賞味期限2週間のソーセージを15日後に食べて、大病になったら怒りますよね?

 

<例3:デジタル気温計>はどう仕様設計すれば良かったのか?

(要求)デジタル気温計を作って下さい

(仕様)-10~40度まで計測が可能です、範囲外は「ERR=エラー」と表示します。

 →使い手は41度で計測した場合「ERR」と表示され納得できますよね

 

仕様設計においては、性能保証する条件を決定することは勿論大事ですが、性能範囲外をどれだけ想定し設計するかも非常に重要だという事です。

 

仕様はバグと表裏一体と言えます。

 

作り手はいかに仕様設計の段階で「想定外を想像し設計できるか」、これがその製品の性能に大きく関わってきます。

私の経験上、設計者の力量によって大きく変わってくるところです。一人の力で無理なら二人、三人・・・の力を合わせて仕様設計する。これが重要だと考えます。

 

 

如何でしたでしょうか?

今回の記事も【プログラミング教育】について考えて観ました。

 

ではまた次回お会いしましょう♪ 

プログラミング教育 子供 第二弾

こんばんわ、TF's appsです。

今回の記事は【プログラミング教育】【子供】に関する第二弾です。

 

↓↓第一弾の記事も興味があれば見て下さい

tfs-apps.hatenablog.com

 

では早速本題に入ります。

 

ここで1つの問題です。

 

「歩行型ロボットが道路を直進歩行しています」

「この先に十字路があります」

「交差点の向こうまでいけばゴールです」

 

<問題>

ロボットへの命令を列挙せよ

 

f:id:TFs_apps:20190508230120p:plain

 

 

◆皆さんはどれだけシーンを想像できましたでしょうか?

◆目的達成(交差点を超えたゴール到達)までにはどれだけの手順が必要でしょうか?

◆どこまでイレギュラーを想定できますでしょうか? 

if 文を何個作りますか? 

 

【以下一例】

・ロボットは直進できるのか?

・交差点で一時停止するのか?

・正面から障害物は来ないか?

・交差点を超えてどれだけ進めばゴールとするか?

・ロボットの状態は正常(=健康)であるか?

・途中でエネルギー切れはしないのか?

・空から何か降ってこないか?

・道路は歩行できる状態か?

・ゴールまでの時間の制限はないのか?

・・・・などなど

 

・・・

「ん!?」

・・・

 

何が言いたいのか!?

アルゴリズムは無限にある

それがプログラミングの世界

 

最適な手段(=解)は何か?

まずは要求を満たすか否か

要求が曖昧であれば明確に定義する

明確に出来なければ保証できる条件を提示する

 

プログラミングの世界で最も重要なファクターの1つは要件定義であるという事です。つまりは、今回の記事で一番伝えたい事です。

 

色んな事が想定できてもif文の化け物となるプログラム最適とは言えない!!

目的達成までに最低限でかつ最高スペックを想定ができるプログラム(if文の数が最適)ベストであるという事です。

 

上記で プログラミングの世界でと言いましたが...

どんな事でも「人は目的が明確でないと正確な行動はできない」ですよね!?

 

逆に目的(=要求)が明確であれば無駄な行動はしなくて済む。

無駄な行動は排除できて、達成するまでの時間も短くなる。

 

 

ぜひとも学校教育でスタートするプログラミング教育においても「この要件定義の大切さを伝えて欲しい」と切に願う!!

 

なぜ私が最近「プログラミング教育」に関して記事を書くか?

今はまだ幼い自分の子供たちへの未来のメッセージにしたい^^v

 

今、父親として伝えたいことは下記の事である。

「常に目的を意識せよ」

「目的を自身の中で腹落ちせよ」

 

如何でしたでしょうか?

プログラミング教育について考えてみました。

まだまだ伝えたい事は山ほどありますが今回はこれまでとします。

 

それではまた次回お会いしましょう♪