まいにち、いっぽ

物事を理解するための出力装置

スマホアプリのサーバーサイド構築 その2 セットアップ

終了地点

  • flask が動いている事が分かる

 ※静的ファイルは flask じゃなくて nginx で行うのが負荷的に良いらしい。
  nginx には何時辿り着けるのだろうか?

環境

  • windows10

flask のインストールからサーバーが動く所まで

  1. python をインストールする。3.x.x を使いました。
    www.python.org
  2. 環境変数を設定してパスを通す。以下は私のPCのパス
    python 自体のパス設定
    C:\Users(ユーザー名)\AppData\Local\Programs\Python\Python36-32
    pip を使うためのパス設定
    C:\Users(ユーザー名)\AppData\Local\Programs\Python\Python36-32\Scripts
  3. PCの再起動
  4. コマンドプロンプトで flask をインストール
    pip install flask
  5. サンプルの hello.py ファイルを作成する。
    pythonソースコードなので、新規テキストを作成して拡張子を変えてしまってOK。
  6. hello.py にサンプルコードを書く。以下が中身。
    http://flask.pocoo.org/
    from flask import Flask
    app = Flask(name)  <- ブログだとアンダーバー2本が太文字になってしまう。公式サイトのサンプルを見てください。
    @app.route('/')
    def hello():
      return "Hello World!"
  7. コマンドプロンプトで hello.py を保存したフォルダまで移動する
  8. コマンドプロンプトで実行するファイルを設定する(以下の命令を実行)
    set FLASK_APP=hello.py
  9. コマンドプロンプトで flask を動かす
    flask run
    
  10. ウェブブラウザで http://localhost:5000/ にアクセスして動く事を確認

備考

自分自身で設定している時は、いっっっっっっっぱいミスをしたりインストールしたりしたので、
何かインストール漏れがある可能性もあります。

日頃対応してくれているサーバーエンジニアさんには敬意を払うと共に感謝します。

スマホアプリのサーバーサイド構築 その1 知識をつける

概要

python の flask を使ったサーバーを作る為の内容をまとめます。 私は今までサーバーサイドを作った事がなく、完全なド素人が何とか進むための物です。 間違っている個所があれば教えて頂けると非常に助かります。

※このページだけでは構築は終了しません。覚えた物をまとめてきますので、記事が続いていきます。

実装したい内容

  • ゲームのリソースのダウンロード(必須)
  • 各ユーザーのログイン時間を把握して、ログインボーナスを渡す

疑問 flask ってなに?

python を使った web アプリケーションを作るためのマイクロフレームワークらしいです。 Welcome | Flask (A Python Microframework)

以前 python を触った事があり flask の本が売っているのを見かけた為、何とかなるんじゃないかと思って選択しました。 最終的に flask を使うかは別として、まずは flask を使っています。

疑問 web サーバーとかweb アプリケーション って何が違うの?

  • 役割(機能)の違い、らしい
  • 使う言語やフレームワークによって長所と短所があり、いい感じに使うために役割を分けているようだ
  • web サーバー、webアプリケーション、データベースに分かれている

web サーバー?

  • ブラウザなどから最初にアクセスされるサーバー
  • アクセスする内容によって、web アプリケーションに処理リクエストを送ったりする
  • apache, nginx が該当するらしい
  • nginx を今後調べていく予定
  • ロードバランサ機能はココで実装(設定?)していくみたい

web アプリケーション?

  • phppython などを使って、リクエスト内容に合わせて処理を行って返す所
  • 今回使用する flask が該当するらしい

データベース?

  • 名前道理、ユーザーのデータやアプリケーションが保持するデータなどの事、らしい
  • My SQL, SQlite とかの事らしい(名前しか知らない...)

疑問 何て単語で検索すれば思った機能が見つかるのか?

言語やフレームワーク名+機能の名前で検索していくのが良さそうです。 実際に使った検索ワードは以下の通りです。 - python + インストール - pip + 設定 (pip install flask が出来なくて調べていた) - Flask + 静的ファイル

知りたいフレームワークを絞る事で狙った情報を探しやすくなると思います。 まずは公式HPの クイックスタートを読んでみて、使えそうな物を片っ端から調べるのが速いです。

次の予定

  • 環境設定をまとめる予定です。
  • 素人には環境を作る事も凄い難しいと感じるのです...

iOS版「聖剣伝説2」の操作性を考えてみる

ページ概要

懐かしいゲームを遊んでいるので、操作性について考えてみました。 覚書のようなものです。

対象となる物

聖剣伝説2

聖剣伝説2

操作性の概要

  • 移動を左側のパッド
  • 攻撃とダッシュボタンが右下
  • ショートカット用ボタンが右上に3つ
  • 画面左上にメニュー開閉用のボタン
  • 画面下のキャラクターアイコンをタップでキャラクター切り替え
  • 画面下のキャラクターアイコンを上にドラッグ&ドロップで個人メニューを開く

印象

  • 移動の誤作動が多い
  • 「斜め攻撃」がシステム上存在しない為、移動の誤操作で攻撃を当てるのが難しい
  • チャージ攻撃をどうやるか気になっていたけど、移植前と同じ、攻撃ボタンの長押し
  • 物理パッドを使うのが良い。バーチャル操作は非常に辛い……(´・ω・`)
  • 武器の切り替えの手間が大きい
  • メニューのリングの反応が鈍い
  • メニューのリングのどこを選択しているか分かり辛い

移動の問題点と解決案の妄想

移動が「 移動用パッドの中心位置からどの角度をタッチしたか」で判断されており、従来の十字キーを操作する感覚には程遠い。聖剣伝説1の移動と同じように、タップした位置からの相対位置にするのが正しいと思われる。

中心位置が固定されている場合、移動用のタッチ位置を常に意識して正確に行わなければならず、アクションゲームで戦っている際は機敏な操作が出来ずにダメージを受けやすく、ダメージを与え辛い。 中心位置を固定化する場合、中心位置を明確にして、中心位置付近の移動の判定に遊び領域が必要だと思われる。遊び領域が多いと斜め移動の判定がシビアになりそうだが、誤操作を招くよりはずっといいはず

攻撃時に多少の向き補正を付けることで、移動のストレスを軽減できるかもしれない。

リングメニューの問題について

原作道理リングメニューが多層になっているが、次のリングへの操作が画面中央のフェイスアイコンの上下スライドが非常に分かり辛い リングメニューの1つを考えた場合、余白が多くあるのだがリングを回す操作感度が悪くタッチしたエフェクト等が出ず、うまく操作出来ているか分かり辛い。 リングの回転の速度が遅く、回転させるにしても選択しているアイテムが分かり辛い。

結論

聖剣伝説1のリメイクの操作性の良さがよくわかりました。 リングメニューはもう少し使い勝手が良くできそうな感じがあり、基本的な矩形のメニューよりも楽しく見えるので使ってみたい所

Legend of Grimrock をプレイ開始

プレイ開始したもの

Legend of Grimrock

Legend of Grimrock

  • Almost Human ltd.
  • ゲーム
  • ¥600

どういう経緯で知ったか

Store で偶々見つけて面白そうだった為。Store で見ただけで買うのは久しぶり。 2015 年リリースなのにおススメの上位にいたし、定期的に売れているのだろうか?

どんなゲーム?

薄暗いダンジョンをサバイバルしながら進むゲーム。戦闘はリアルタイムのアクション。ローグ系と言えば分かり易いのだろうか、灯りとなる松明が時間によって燃え尽きてしまったり、キャラクターのお腹が減ったりする。
壁のスイッチを探すために結構画面を凝視しているので、いきなり攻撃されると本当にびっくりします(´・ω・`) 2012 年に発売されていたようで、2作目も Steam で販売されていた。…… Steam 版買えばよかったと思わなくもない。 やっと4Fに到達しました。

遊んでみて面白いか?

ダンジョンの中をうろうろして、ギミックを解き、壁のスイッチを探しながら攻撃される。アイテムを整理しながら英語のアイテムを首をかしげながら進んでいく。

いやぁ……超面白い(`・ω・´)
ダンジョンを進むのが好きな人にはお勧めできる。

タッチ操作がかなり快適でダンジョンを見渡せるのは気持ちい。移動のタッチミスで窮地に立たされたりして、結構スリリングな部分もある。参考にしよう。

戦闘は命中率が意外と低くて、ストレスがたまる印象。敵の攻撃時に合わせて攻撃すれば、命中率上がったりするのかな?よく分からない。

備考

  • 全て英語のため、ヒントの内容が頭に入ってこなかったりアイテムを上手く認識できないときがあります。それでも楽しい。むしろ楽しい。

少し見ただけで人を魅了する「ドラゴンボール ファイターズ」の良さを考えてみた

動機について

今更ながら動画を初めて見て、非常に綺麗で魅了されたので
どういう所が良かった、気になったかをまとめてみました。

実際に見た動画

www.youtube.com

気になったポイント

キャラクター周り

  • キャラクターたちのアウトラインの綺麗さ。細くきれいに入り過ぎてちょっと不安を感じる時もある。
  • キャラクターへの動的な影の入り方の綺麗でイラストチック
  • 対戦開始時の入りの演出がカッコいい。 立ちポーズで始まる格ゲーより、対戦開始時の入りの気持ち良さを感じる
  • 演出時の漫画的なパース変更で漫画を読んでいる時の迫力感を感じる(前に表示される腕が異常に大きい)
  • 超必殺系のキャラクターの表情表現が豊か
  • 超必殺時のアップ用モデルも入っている感じがする どれだけモデルが入っているのだろうか
  • フリーザの攻撃時のしっぽの太さが変わっている気がする。これもモデル変更?
  • 瞬間移動時、キャラクターが一時的に2体になるっぽい。同時に何体出せるのだろう?
  • 勝利演出等だと背景とキャラが馴染んでいない気もする。アニメと実写を混ぜたときの違和感に近い

攻撃、エフェクト周り

  • 攻撃の軌跡の綺麗さ(漫画っぽさ) ギルティだと専用の軌跡モデルも用意してたと思う
  • 汎用的なエフェクトのイラスト感、特に綺麗な方向性を持つ火花系
  • 攻撃による相手へのライトの影響(多分攻撃ライトに切り替わるっぽい。色が混ざってない綺麗な感じ)
  • 爆発の派手さ
  • エリアル開始時などの移動の軌跡のドラゴンボールっぽさ
  • 戦った影響がステージに残っていくのは雰囲気づくりに重要
  • エフェクトの多くはキャラクターの後ろかな?
    加速時、攻撃時の線などの特融の軌跡、超必、爆発系の画面を覆うものは前
    ランク付けされている感じがする
  • 爆発系のエフェクト、ギルティで見た事ある気がする。違和感はない
  • HPバーは結構表示順番が後ろっぽい、UIの順番変えてそう
  • カメラワークかっこいいけど、見ていると酔ってもくる。でもかっこいい

最後に

ギルティギアを見ている時も良く思いますが、演出がカッコ良いし綺麗です。
さすがのアークシステムワークス様ですε= (´∞` )

「なるはや」の危険性と対策について

検討した理由

身の回りで「なるべく早く」「出来るだけ早く」「うーん、なるはやで!」といった言葉が良く聞こえるようになったため

「なるはや」は何故危険なのか

まず仕事は早く終わる事が良いという事。
人を雇っている間は人件費がかかる為、極端な話をすれば何事も早くできるに越した事はない。

では何が危険なのか、以下に列挙してみた。

  • 仕事の優先順位が分からなくなる
  • 仕事の期限が曖昧になる
  • スケジュールが壊れる\(^o^)/

チームで業務を行っていくにはアジャイル開発であっても、スケジュールが必要となってくる。 「なるはや」と聞かされ続けたメンバーはスケジュールを軽視し、最終的には更新されなくなった謎スケジュールが残る。
正直そんなチームには誰も入りたくないし、仕事の効率は下がる一方である。

では何故「なるはや」と言ってしまうのか

何名かを観察した結果として、原因をまとめてみた。

  • 仕事を出す人がスケジュールを把握していない、もしくは軽視している
  • 仕事の優先順位が付けれず手に取った物を「なるはや」で処理しようとしている
  • 仕事量があふれている、残業が続いている、など体力面での低下でスペックが下がっている
  • 仕事の発端の人が「なるはや」を使っていた為、「なるはや」と言ってしまう

スケジュールが全てではないが、悪循環を起こしているのは間違いない。 1回回り始めてしまった悪循環を変えるのは容易ではなく、残業が続けば体力気力が減り、思考力が低下してしまう。

底なし沼へようこそ(´・ω・`)

どうやって「なるはや」の悪循環から生き残るか

状況を正しくしようと思えば、誰かがリーダーシップをとり関係者全員を巻き込んで現状に対する認識を合わせ、変えようと声を大にして言うしかない。

注意する点は以下の通り。

  • 事実や分析結果に基づいた認識を合わせ、感情論では無い事を伝える
  • 口論をしない
  • 相手の話を聞く
  • 自分の意見を伝え、意見をすり合わせる
  • 社外の人に相談する場合は、NDA に気を付ける
  • 自分を大事にして、無理をしない

日々続いている慣習、状況を変えたいと言うのは並大抵の気持ちでは行えない。
実際に「誰か」が現れる事はなく、気づいた人自身がリーダーシップを取って行動するしかない。
誰も面倒な事はやりたくはない、疲れていれば猶更である。

最後に

何かを変えるには代償が必要になる。自分の時間、立場、心など失う物もある。
辛い物、面倒な物を見て見ぬふりをするのは悪い事だけど、普通の事

でも本当に変えたいと願うなら、自分を信じて行動する事が大事だと思います。

TDDの本を読んでみた

読んだ本

bookwalker.jp

本の概要

  1. TDD についての説明
  2. 実際に pact を使っての説明

読んだ経緯

Unity でゲームを開発する上でデバッグにかかる工数が年々増加傾向にあり、工数を短縮したい状態になっていました。ゲームのテストコードを殆ど書いたことがなかったためTDD自体をよく知らないため、知識をつけるために読みました。

所感

TDD(テスト関係)は必要ない、私の所には適用できないって言う人は読んでみて欲しい。 「仕様のテスト」か「実装のテスト」か、何がプロジェクトに有効かを考える切欠になりました。 ページ数は少ないですが、少ないからこそ気軽に読めると思います。(事実私は気軽に買って読みました)

実際に自身が使うと考えてみて、部分的に導入するのは良さそうに感じました。明確な意図を持って作られるツールやライブラリの類なら工数の短縮は出来るかもしれない。ゲームのような曖昧な物にこそテストを作りたいが、作りなれていないとメンテナンスコストだけが膨れ上がってしまう。

「テスト」のテストをしても恐らく実感がわかないと思うので、次に作成するツールで部分的に試してみようかと思います。上手くいったら記事にします(^ω^)