2016年12月23日金曜日

知人の企業サイトの更新

本職は(たぶん)ゲームプログラマですが、まあ途中色々あって、
Webサイト運営だとか、校閲だとか、デジタルサイネージだとか。

最近、同僚から、経歴が謎すぎると言われたばかりですが。


知人の会社のオフィシャルサイトの制作・運営をやっていたりします。
昔お世話になったので、運営費などは頂いていません。

なので、空いている時間に更新するスタンスで、即反映とはいきませんが、制作はしっかりとやっています。

PC/スマホ、それぞれレスポンシブルデザインで見やすくしたり、
スマホで会社の地図を見たとき、ページスクロールがそこで停止しないとか(笑

ホームページの制作・更新というビジネスは今どうなってるんですかね。
当時は、初月(デザイン込み)30万円~、毎月の更新5万円~とかだった気がする。

で、知人のサイトは、以前は WordPressで作成されていたんですが、作成した人が田舎に帰ったか何かで居なくなりまして。
私が後を引き継いだわけですが、もうどうやって作ってるのかサッパリ分からず

1から作り直しました。

以前作られていたものは、管理サイトにログインすれば、記事を作成でき、画像を追加でき、最後に本番サイトに公開すればOK、と一通り機能ができてはいたのですが、それをやるのが知人なのです。

知人は、そういうことが一切分からない

いわゆるエンジニアがサイトを作るとこうなっちゃうんですよね。
枠は作った!後はどうぞ、的な。

いや、更新することを考えようよ。
更新する人にHTMLタグの知識を要求するのは酷だよ…。

というわけで、1から作り直すに辺り、以下のように設計。


・サイトは作り直すが、個々の商品のURLは踏襲。(他からのリンク切れを防ぐ)
・更新をしやすくする (どうせ私が更新するんだし、楽なほうがいい)

という2点。

さらにいうと、そのサイトは、平均して月に1つ、商品が追加になるかどうか、という頻度。
放っておくと、私が更新の仕方を忘れる可能性があるw
という点からも、構成は簡潔にすべき。

結果、本来データベースに格納する商品データを全て、最初から変数で保持。
Javaで言うと、public static final String hoge = "100円"; みたいな
必要な商品画像とレイアウトのテンプレートファイルを、商品番号のフォルダに入れるだけでOK、という形になった。

そして必要に応じて、お知らせや、ピックアップなども、同じように追加していけばいいだけ。

知り合いから、商品画像と商品説明のテキストがメールで送られて来たら、
画像のサイズ加工、商品データ追加で、10分もあれば終了。

こうしてみると、やっぱ色々な知識がいるな!

2016年12月21日水曜日

Google Consoleを導入のその後

結局、最近の検索は、Googleだけでなく、Yahoo、Bing、どれも httpsを使用しているので、キーワード取得できないね…。

GoogleConsole導入しても全く関係なかった。

今まで忍ツールズのアクセス解析で取得できていたものも、どこかに残っている、http: の検索からの分しか取得できていない。

検索ワードって、別に個人を特定できるものではないし、そこまで保護するものじゃ無い気がするんだけど。

そもそも、親玉である Googleとか、もっと色々情報抜いてるだろ…。

Android端末持ってて、位置情報ONにしてたら、
Googleタイムラインみると、驚愕するぞ。
https://www.google.co.jp/maps/timeline

移動経路や移動手段、立ち寄った場所とか、そこそこ正確に取得できてるし、
Googleフォトの写真バックアップを利用していたら、それもすべて張られてるぞ。


2016年12月20日火曜日

MOVERIO カメラアプリを真面目に考えてみる

今年こそは、Google Playに何か公開するぞー、と正月くらいに言った気がするが、もう12月も終わりだ。

Google Playにあるフリーのアプリも充実してきているので、色々なアイディアを詰め込まないと、目に留まる事すらないだろうな。

今回趣味で、エプソンのMOVERIO BT-300を購入したのだが、アプリが非常に少ない。
プリインアプリも少ないし、専用の AppStoreにも、アプリは少ない。

 ←これ

さらに操作しにくいなどの問題もあるので、たとえ、AmazonAppをインストールしても、
普通のアプリをするのにも、正直向かないと思う。

ガジェットのブログで、MOVEIRO BT-300 のレビューを書いていて、
http://latache-gadget.blogspot.jp/search/label/MOVERIO

そこでも解説しているとおり、プリインのカメラアプリがいけてない

現在、MOVERIO App Store にある、普通のカメラアプリは、PIPカメラくらいしかない。
これは、写真に任意の画像を重ねて撮影できるというもの。

ホワイトバランスなどの一部の機能は使えるようになっているが、撮影操作や、画面UIなどに一部気になる点がある。

というわけで、これらを踏まえ、ふつーのカメラアプリを AppStore で公開することを目標として、企画(仕様)を考えてみよう。
今回、動画の撮影については、対象外とする。

まず、カメラアプリに必要な機能と、操作、MOVERIOの実際のスペックなどをリストアップする。

必要な機能
 写真を撮影する操作
 ズーム
 メニュー(設定)を呼び出す操作
 アプリを終了する操作

カメラのプレビュー映像が表示されている、アプリの基本画面で必要な操作は、この4つ。
メニューの中にアプリ終了を内包してもいいが

メニュー詳細
 ホワイトバランス切替
 シーン切替
 エフェクト切替
 設定
 戻る


これらを誤動作しないようなUIで操作したい。

使用できる機能
 コントロールボックス
  ボタン3つ
  タッチパッド
  十字ボタン
 ジャイロ
 ミュートタップ

このうち、ミュートタップは使えたものではないので、却下。
やっぱり、タッチパッドか…。

2016年12月19日月曜日

Google Consoleを導入してみる

前回、フィルタを設定することにより、リンク元のフルパスを取得できる、という設定をしてみた。

勘違いしていたのだが、これは、あくまで、リンク元のURLを記録するだけらしい。

Google検索などで、

 url?keyword=検索ワード 

という感じで、検索ワードがURLに付加されるのだが、これはフルパスには含まれない。
そもそも、 Google Analytics では、キーワードは取得できないんだそうな。

え、それでいいの?
検索ワードって結構重要だと思うんだけど。


というわけで、色々調べた結果、Google Console を導入したら、
検索ワードがすべて分かるらしい。

ので、早速導入してみた。
ただし、結果が表示されるようになるには、しばらく掛かるらしいので、気長に待ってみる。

これらがうまくいって、初めて 忍者ツールズのアクセス解析タグが外せる。
面倒だな >Google

----追記

ちょうど1日経過したくらいに、エラーが出なくなった。
これが正常動作と思われるが、検索で来たログが無いので、
正しい動作かは、確認取れず。

ゲームのレベルデザイン

知り合いがFacebookで紹介していたから購入してみたんだけど。
「レベルデザイン 徹底指南書」 大久保 磨 著

 

さすがに業界に20年以上いる私には、それは知っているよ…というものばかりです。
まだ、5章のRPGまでしか読んでいませんが!

おそらくは、学生やこれからプランナー始めるぜ、という人向けなのだと思います。
ですが、徹底指南書というには、少し物足りない気がします。

こういう解説本も需要があるということで、せっかくのプログラム・ブログなので、この本の様に、私なりのレベルデザインについても、書いていくのもありなのかも。

というわけで、RPGの項目に書いて無くて、ちょっと残念だった、パラメータの概念とエンカウントについて、書いてみることにしました。


まず、パラメータについてですが、敵に与えるパラメータとして、攻撃力という数値パラメータがあったとしましょう。
当然、数値があがるほど、与えるダメージは大きくなります。

RPGの装備品の特徴として、パラメータ補正があります。
この剣を装備すると、攻撃力+10
などがそれで、見たことある人も多いはず。

この補正値には、大きくわけて、2種類あります。

「攻撃力+10」
「攻撃力×2」

足し算か、掛け算か、という違いですが、用途がまったく異なります。

たとえば、レベル1から、レベル99まで上がるRPGがあったとして、
 レベル1のときの素手の攻撃力が5
 レベル99のときの素手の攻撃力が1000
まで上がるとしましょう。

レベル1のとき、
 「攻撃力+10」を装備すると、攻撃力15となり、3倍です。
 「攻撃力×2」だと10で、2倍になります。

大した違いに思えないかも知れません。
しかし、レベル99を見ると。

 「攻撃力+10」を装備すると、攻撃力1010で、ほとんど効果がありません。
 「攻撃力×2」だと2000で、数値的には2倍ですが、レベルで換算すると、
レベル200くらいと等価になります。

武器の様に装備していると常に効果があるものに、×2のような効果をつけてしまうと、
バランスブレイカーと呼ばれる装備品になりえます。

一般的に、+10などの加算パラメータは、装備品など、次々に新しいものに替えていくものに付加することが多く、x2などの乗算(倍率)パラメータは、スキルなどのように、別パラメータを消費するなどの制限下で、一時的に効果を発揮するものに設定することが多いです。

上で書いたように、その効果をレベルに換算してみるのも1つの指標になります。


そして、エンカウント
ランダムエンカウントですが、こちらは、一歩進むごとに、確率で、敵が出るかどうかの判定を行うというものですが、いまだに、一歩ごとに同じ確率で計算していると思われるRPGがリリースされています。
プレイした感じでそう思う、というだけですが

どういうことかというと、1歩ごとの判定で、1/10 (10%) で敵が出るとしましょう。

一歩目で敵がでる確率:10%
二歩目で敵がでる確率:90% × 10% = 9%
三歩目で敵がでる確率:90% × 90% × 10% = 8.1%
四歩目で敵がでる確率:90% × 90% × 90% × 10% = 7.3%
 :
 :
という様に、歩き始めて、一歩目で敵が出る確率が一番高くなり、ほとんど進まないうちに、敵が次々と出てくる、ということが多くなります。
こころ当たりのあるゲームはありませんか?

これでは、エンカウントでストレスが溜まります。
こういうのを調節するのも、レベルデザインの1つですが、インターフェースなどと違って、見た目ではわからないのが、やっかいな点です。

ちなみに、解決方法としては、次に敵とエンカウントする歩数を乱数で決める、最低20歩は敵とエンカウントしないようにする、などが挙げられます。


2016年12月17日土曜日

Google Analytics を導入してみる。

忍者アクセスツールだと、モバイルで閲覧した際に、画面下部の誤タップを狙った広告が出るので、別のツールに変えよう。

と考えつつ、結局 Google Analytics しかないので、導入にチャレンジ。


Googleアカウントがあれば、Analyticsにはそのままログインできた。
プロパティというのを作成して、トラッキングID さえ発行できれば、Bloggerでの設定は楽にできた。

(管理画面 ⇒ 設定 ⇒ その他 に、トラッキングIDを入力するだけ)

ブログを移行したばかりだし、(元から)アクセスは少ないので、自分以外のログがほぼありませんが。

まず、このログ確認がむずかしい。

Google Analytics の管理画面
  ↓
"レポート"タブ
  ↓
ユーザー
  ↓
サマリー

多分ここにあるのが、時間帯別アクセス数だと思われる。
もっとも重要な、リンク元検索キーワードは…どこにあるのか。


さすが、サポート掲示板で質問しても、答えが全く返って来ないくらい、クソなシステムを作るGoogleだ。
全く分からねぇ。

というわけで、検索。
Google Analytics の管理画面
  ↓
"レポート"タブ
  ↓
集客
  ↓
サマリー
  ↓
すべてのトラフィック
  ↓
参照サイト
ここにあるのが、参照元サイト(リンク元)らしい。
だが、キーワードらしきものは見当たらない。


そんな中、Twitterから移動してきと思われる、貴重なログが1件。
だが、twitter.com としか書かれていない。

調べたところ、Bloggerのデフォルト仕様では、参照元は、ドメインまでしか記録されないらしい。
なんという無意味な情報!

だが、それを改良するための親切な解説サイトを発見。

Analytics。リンク元のURLが知りたい!そんな時(応用編)
http://www.wasabi3.com/2013/05/analytics_link_ouyou/


通常状態でのグーグルアナリティクスではリンク元のドメインレベルまでしか分かりません。フルパスを知りたい場合はカスタマイズが必要になりますのでご紹介致します。

とのことで、ここにある通り設定してみました。
2013年の記事なので、管理画面が現在と多少違いますが、設定方法は同じでした

ただ、それ以降、アクセスが無いので、この設定でOKなのかどうか、検証できていません(笑)

2016年12月16日金曜日

GLSurfaceViewを使ってみる3

ゲームの演出に必要なので、テクスチャを回転させてみる。

ポリゴンの回転は普通にできたのだが、それにテクスチャを張ると、絵柄が潰れてしまった。

縦長の画像を張って90°回転したのだが、微妙に潰れたのだ。

その潰れ方の比率からすると、おそらく、ディスプレイのアスペクト比の問題だろう。
OpenGL系では、座標はピクセル単位ではない。

F-10Dのディスプレイサイズは、720x1280 だが、
それを -1.0~1.0 という数値で指定する。

その辺りを考慮して、ビューポートの設定をしてみた。

gl.glViewport(0, 0, H, H);

H:画面の縦ピクセル数

この設定で回転させると、90°でも、ゆがまずに回転した。

それはそれで良かったのだが。

今回用いたのは、128x512 という縦長の画像。
ところが、他の解説サイトを見ていたら、次の一文が載っていた。

「OpenGL ESでは、正方形の画像データしかテクスチャマッピングの元画像として受け入れてくれない。」

表示できているけども…?

----追記

上記のビューポート設定だと、横画面(Landscape)の時に座標が狂ったので修正。

if ( landscape ) { // 横画面 (LandScape)
gl.glViewport(0, H -W, W, W);
} else { // 縦画面 (Portrait)
gl.glViewport(0, 0, H, H);
}

 W:画面の横ピクセル数
 H:画面の縦ピクセル数

2016年12月15日木曜日

タグのカスタマイズ

テンプレートを修正して、見やすくしたい。
ありがちだけど、見出しにL字型のラインを入れて区切りを表現してみる。

アクセス解析のときにしたように、HTMLの編集をしてみたのだが、
動作がおかしい。

ここから、HTML編集を選択。

投稿のタイトルを装飾するcssタグ、h3.post-title に手を加える。

単純な修正として、改行を1つ入れてみる。
そして適用すると…。

モバイル用のテンプレートが真っ白に!
こうなると、上の手順で追加した改行を削除して元に戻しても、真っ白のまま。

という理由により、HTML編集はあきらめ、カスタマイズで、CSSを追加することに。

既存の、h3.post-title を変えると色々面倒なので、H3タグを直接操作。
これで、モバイルの方にも、問題なく適用された。


ついでに。
ブログのトップページだと、複数の記事が羅列されており、各タイトルから個別の記事へリンクされている関係で、タイトルはリンクカラーで表示される。
だが、各記事は通常のテキストカラーでの表示となり、色が変わって違和感がでるので、リンクカラーに合わせておいた。

このくらい、最初から合わせておいて欲しいなあ。


ブログのテンプレート修正

修正したい箇所はたくさんありますが、
まずは、ガジェットの項目のうち、

リンクリスト
アクセス解析

この2つをモバイルでも表示されるようにしたい。

Bloggerユーザーは多いので、検索すると、すぐに解決方法が見つかりました。

 P--Q「モバイルサイトでラベルリストを表示
 https://p--q.blogspot.jp/2013/05/4.html

こちらを参考にしました。
2013年の記事ですが、現在でも有効です。

HTMLの知識があれば、手順としては、簡単です。

 Bloggerの管理画面
  ↓
 テンプレート
  ↓
 HTMLの編集

と移動して、HTMLのソースコードの中から、編集したいガジェットの開始タグを見つける。
そのタグに、

 mobile='yes'

属性を付ける。
ソースコードの修正はこれだけ。

その後、再び、

 Bloggerの管理画面
  ↓
 テンプレート

と移動して、モバイルの方の下にある、歯車アイコンをクリックし、
表示されるプルダウンメニューの一番下にある、「カスタム」を選択して保存。

これだけでOKでした。

…OKだったんですが!
今、アクセス解析に使用しているのは、忍者アクセス解析なんですよ。

最近はモバイルのアクセスも多いだろうから、モバイルにも解析を付けたかったんですが、
当然と言えば同然ですが)広告が表示されるようになった…。

しかも一番下にひっそりと表示される、アレ。

アクセス解析つけなければ出ないので、もう少し、Bloggerに慣れたら、別の解析に変えよう。
まあ、選択肢は、 Google Analytics しかないでしょうが。


2016年10月20日木曜日

GLSurfaceViewを使ってみる2

私が使用しているスマホが、4年前のF-10Dなので、OpenGL ES 1.0 にしか対応していない。
今時、1.0で作るのもどうかとは思うが、テストで作ってるだけだし。

でもソースコードに、

GL10

という記述をしているため、あとでバージョンを上げると、この辺りを全部差し替える作業が発生するな…。

などと思いつつ、背景部分の移植完了。
背景は、良く使う手として、小さい画像をタイル状に敷き詰めて、スクロールさせている。

Canvasを用いた描画では、画像を何枚も並べて描画していたが、GLを用いると、1枚のポリゴンに、UVを設定するだけでいい。

具体的には、u = 0.0 ~ 1.0 とすれば、1枚分が表示されるが、
u = 0.0 ~ 5.0 にすれば、5枚分が表示される。

ところが、パターンが細かい画像を使用したので発覚したのだが、フルスクリーンのうち、数か所がたまにちらついて見える。

これは…いわゆる、ダブルバッファを使わないといけない案件か?
しかし、OpenGL ES1.0には、フレームバッファはなく、
1.1のextensionを使わないといけないらしい。

しかも extensionだから、どの端末でも実装されているという保証はない。
いやまあ、1.0で作ってるのが悪いんだけど。

ところが、だ。
テストを重ねると、どうやら、描画が追い付かずにちらついているわけではないらしい。

スクロールさせるために、uvをそれぞれ、0~1の範囲で動かしているわけだが、

u= 0.184f;
v = 0.816f;

と設定すると、描画が崩れる。

これは…単なる float誤差か?

しかも、全体の一部の描画のときだけ??

面倒くさいのきたー。

2016年10月14日金曜日

GLSurfaceViewを使ってみる1

基本、2Dのゲームしか作らないので、ずっとSurfaceViewを使っているが、実行速度を上げようと思い、試しにOpenGLを使ってみることにした。

ネットを見てみると、SurfaceViewとViewの速度について、ハードウェアアクセラレーションやら GPU使用やら、条件でどちらが速いか変わるし、デフォルトの設定がどうなっているかも機種によって違うとか何とか。
面倒くさいのう。

手持ちのメイン機種 F-10D (4年前のモデル)では、SurfaceViewの方が速かった。
GPUのON/OFFでも比べたが、OFF(デフォルト)の方が速い。

SurfaceView では、40FPS程度のものが、GPU使用使用にすると、30FPSくらいに落ちる。
ほぼ何も表示しない状態でも、50FPSを超えるかどうか、というのが最速。

それに対し、それよりももっと負荷が高い表示(128x128の画像100個)でも、GLSurfaceViewは、60fps前後を維持できた。
やはり高速だ。

ただ問題もあって、GL系だと、フォント表示が面倒になる。
そもそも、画像1枚表示するにも、テクスチャバッファ作って、頂点バッファ作って…とか、色々面倒だし。

この辺りの手順、どうせ誰が作っても一緒なんだし、そろそろスマートになってもいいと思うんだけど…ならないねぇ。

逆にGLで楽になるのは、タイルパターンの描画かな。

通常のdrawBitmapでタイルペイントすると、始点の変更ができないが、GLだとuvをいじるだけで表現できるしね。