2018-07-03

今週のだらりんぴっく

雑記

今週（と先週）は風邪をひいてしまった関係で、だらだらがいつにも増してはかどってしまいました。たまには日記っぽいことも書いてみようと思ったので、この記事に需要があるのかはさておき、だらだらの記録を残しておきます。今週の開発の進捗はいまいちだったので、進捗報告のほうはのちほど。。。

まずはだらだらのお供にしたまんがをば。

bookmeter.com 水上先生の作品は「惑星のさみだれ」や「スピリットサークル」を読んだことがあり、とても好きなまんが家さんの一人です。放浪世界はいつか買おうと思っていたのに、本屋さんでなかなかお目にかかれず、ようやっと購入できたのでした。この単行本に収録されている「虚無を行く」というお話がすき。

sonorama.asahi.com 街中にある、ちょっと怪しいけど気になるあの店に入って堪能するはなし。私的気になりスポットの「浅草観音温泉」も載っていました。

つぎに「ポポロクロイス物語」を購入した話をば。

最近は作業用BGMとしてゲーム音楽を聴いたりすることもあります（Amazon Musicにそれなりにある）。ゲーム音楽はループして再生しておくにはちょうど良く、集中したいときにそれなりに重宝しています（といってもそのへんに詳しいわけではありませんが）。たまたまポポローグのゲーム音楽に出会ったのがきっかけでちょっと調べてみると、ジャケットの絵が好みかつ、ゲームタイトルの響きが良い感じだったので遊びたくなり、中古ゲーム屋さんでポポローグの前作に当たる「ポポロクロイス物語」を購入したのでした。

どうでもいいけど、PS1のゲームはもはや「レトロゲーム」カテゴリなんだなーと、久々に中古ゲームショップに訪れて思ったのでした。

クォータービューなRPGでかわいい感じの画面で、さほど難易度も高くなく（いまのところは）、疲れていても遊べそうなのでなんとか最後まで楽しく遊べそうです。（疲れていても遊べるというのは大事で、疲れている時期に歯ごたえのあるものを買ってしまうと高確率で積みゲーにしてしまうので... Cities Skylinesとかガンヴォルトの2作目とか、完全に買って満足してしまったので、そろそろ遊ばないと...）

ではでは。

2018-06-28

HTML5のバリテーション機能を使っておてがるバリデーションを試してみている

プログラミング JavaScript

今日も今日とてちまちまと趣味開発のほうを進めているのですが、各種値を入力->チェック->OKかどうかを確かめる実装を各所に行わなければならず、めんどい～となっていました。

たとえば以下の画面の入力欄は「編集画面のグリッド（点々）の幅を決める」ためのものですが、プログラム上では「数値かどうか」「最小値を下回っていないか」「最大値を超えていないか」を検証しなければなりません。

f:id:piyorinpa:20180628223450p:plain — グリッドサイズを変更するメニュー画面

そして、検証の結果、不正な値とみなせば、ユーザーにその旨伝えなければならないですが、そのための表示領域を設けたり、表示させたり、などなど面倒です。

そこで、HTML5のバリデーション機能を使ってこのような確認をやらせると楽だなと思い、今作っている趣味開発のものにおためしで実装したりしてみています。

例えばこんな感じ。最大値（max）最小値（min）必須入力項目（required）を設定しています。

<form id="confirm-form">
  x: <input type="number" class="size-input" min="5" max="300" required>
  y: <input type="number" class="size-input" min="5" max="300" required>
  <div class="bottom-buttons">
    <input class="button" type="submit" value="適用">
    <a class="button" href="#" @click.prevent="close">閉じる</a>
  </div>
</form>

<script type="text/javascript">
  document.getElementById("confirm-form").addEventListener('submit', function(e) {
    alert('値の検証に成功しました！');
    e.preventDefault();
  });
</script>

最小値や最大値に収まらない値を入力して「適用」ボタンを押すと、数値が間違っている旨メッセージが表示されます。このメッセージはブラウザが勝手につくって表示してくれるので、別途表示領域を設けたり、警告文を作ったりする必要がないのでらくちんです。ルールに沿った値を入力して「適用」を押せば、alertが表示されます。

f:id:piyorinpa:20180628223748p:plain — 数値がルールから外れたまま「適用」ボタンをおすとメッセージが表示される（Chromeの場合）

（表示はブラウザによって異なります。上記はGoogle Chromeの場合）

form要素とsubmitボタンを置くことでバリデーションをさせることができますが、検証に成功するとページ遷移してしまいます。ふつうにFormでPOST送信する場合はそれでもいいですが、JavaScriptで入力された値を使ったり、Ajaxで値を取りに行くような実装にしたいときは困ります。そこで、e.preventDefault() をしてあげることでデフォルトの挙動を停止し、ページ遷移を防ぐことができます。

Vue.jsで同様のことをする場合は、 @submit.prepend としてあげることで、「適用」ボタンが押されてもフォーム送信によるページ遷移を防ぐことができます。（唐突にVue.jsが出てきたのは、今作っている趣味開発のものがVue.js製のためです）

以下のような記述をした場合、検証に成功したら @submit で設定したメソッド（以下の場合だと appendSettings）が呼ばれます。

<form @submit.prepend="appendSettings">
   x: <input type="number" class="size-input" min="5" max="300" required>
   y: <input type="number" class="size-input" min="5" max="300" required>
  <div class="bottom-buttons">
    <input class="button" type="submit" value="適用">
    <a class="button" href="#" @click.prevent="close">閉じる</a>
  </div>
</form>

さきほどの「グリッド間隔を変更するメニュー」画面に適用するとこんな感じになりました。「適用」ボタンが隠れてしまっていますが、値を再入力することで警告ふきだしは消えます。

f:id:piyorinpa:20180628224704p:plain — グリッド間隔を変更しようとして失敗した様子

警告文を示す吹き出しはブラウザが勝手に作ってくれる分、警告文の文言や表示位置、デザインに融通を効かせたい場合は不都合ですが、おてがるな点が良いと思っています。

ちなみに、ブラウザによっては、この手のバリデーションに対応していなかったりしますが、趣味開発なので気にしないことにしています。

ではでは～

2018-06-21

趣味開発にタスク管理ツールを使ってみている

製作報告

最近、趣味開発にタスク管理ツールを取り入れてみたりしています。とりあえず以前に使ったことのあるTrelloで、現在行っている趣味開発作業に関するタスクを2週間くらい管理してみました。

Trelloは一部機能を除き概ね無料でつかえます。

trello.com

趣味開発は締め切りなどがないことが多く、また開発のやる気維持も結構大変のため、エターナってしまう※1リスクが常に付きまといますよね。というわけで、少しでもそのようなリスクを減らすために、普段している作業を細かく「タスク」として分割して、進捗どうなっているの？とか、今何やっているの？とか、これから何やればいいの？を見える化してみようと思ったわけです。

実際に趣味開発に使ってみて、たとえばフリーゲーム作者の方など、比較的開発に時間がかかるような作品を手掛けている方なら、趣味開発でもタスク管理するとよさそうだなという気持ちになりました。

でも、「タスク管理」というと大げさな響きもします。そこで、こんないいことがあったよ！とか、こんな感じに使っているよ！などを書いてみようと思います。

（Trelloについてはググればたくさん使い方が載っていると思うので、ここではツールの使い方には触れません）

（※1：作品が未完になってしまうの意）

どのようにつかっているの？

普段している作業を細かく分割し、「カード」に書き込み「リスト」に追加していきます。私の場合は、「Backlog（いつかやるタスク）」「Todo（次にやるかもしれないタスク）」「In Progress（作業中）」「Done（作業完了）」という感じでリストを切って、カードを移動しながらタスクを管理してみています。

f:id:piyorinpa:20180621233556p:plain — 作業を「カード」に書き出して「リスト」に登録する

どんな良いことがあるの？

タスクの見える化によって以下のような良いことがあります。

その日にできるタスクを適切に選ぶことができる

時間がない～とか、今日は疲れたけどちょっとだけ作業しようかな、とか、趣味開発の場合は日々の生活をこなしながら行っていくので、その日その日で進めることのできるタスク量には限りがあると思います。そこで、予めタスクをそこそこ登録しておけば、時間や体力、気力と相談して、その日にこなせそうなタスクを処理することができるようになります。

エターならないようにするには「ちまちまとでも作業を進める」ことが大事かなと思っている私にとっては結構よい使い方だなと思っています。

やったことが自動的に記録されていく

「今週はあまり進まなかったな...」という気持ちが長く続くと、先が見えない感が出てきて開発が止まってしまうことがありますが、案外作業量としてはこなしていたりもするものです。

タスク管理ツールをうまく使えば、行った作業が記録されていくので「実は結構作業しているんだな～」とか、「あとはこれだけやればよさそう」という作業の実態が可視化され、先の見通しがしやすくなり、やる気の維持につながると思います。

（一方で、タスクの見える化によって、Todoにたまった膨大なタスクを目の前にし、「これいつ終わるんだ...」という気持ちになる副作用もあります。そういう気持ちとうまく付き合う必要もあります）

なんかやっているな～感がでる

「ちゃんと作業しているじゃん」という気持ちになることは、孤独な個人開発にとってはとても重要だと思います。タスクを細かく切って、こまめにカードを移動すれば、適度な「やっている感」を得ることができます。

まとめ

割と長めの趣味開発をされている方々なら、作業計画を頭の中で見積もったり、紙に書き起こしたりすることがあると思いますが、ツールを使うと捗るよという話でした。今回は利用経験のあるツールを使ってみましたが、様子を見ながら別のツールも使ってみてもいいかもなと思っています。

私もエターならないようにがんばらないとな。。。

ではでは～

2018-06-17

開発報告（6/17）とだらりんぴっく

製作報告みんなでつくるダンジョン

みんなでつくるダンジョンの開発報告

まずはいつもの開発報告をばをば。大体以下のようなことをやっていました。そういえば最近、Trello（タスク管理ツール）を趣味開発でも使ってみているのですが、そのおかげで「先週何をやったか」が記録できているので、このような記事が書きやすくてよいなーと思ったのでした。

とにかくひたすらバグを取る

現時点で、「マップを読み込んで保存する」「マップ間を移動する」「アバターを作る」「マップ間を移動する」など、あらかたの動作が（雑ではあるけど）できてきつつあるので、動かしながらバグを取る作業をしていました。まずは安定性を一定部分まで上げて、人に見せられるような状態にしたいなと思ったのでした。

（こんなの作っているんですよー。シュッ(~o~)っみたいな感じにできたらよいなーという気持ち）

バグを洗い出すには、「ひたすら動かす」と「テストコードを書く」な手段があると思いますが、重要な部分はテストを書き、そうでもない部分やリアルタイム性が重要な部分はひたすら動かす、みたいな感じで進めていきたいなーと思っています。テストプレイを自分以外の人に一度やってもらったほうがよさそうだな...。

テストコードについては、以前の記事でちょっとお試ししたJestを様子を見ながら取り入れていきたいなと思いながらつくっています。

マップサイズが変更できるようになった

マップサイズが変更できるようになりました。今までは1500px四方固定だったのですが、面積が1500×1500px²となることを条件として可変できるようにしてみました。

これで縦長や横長のマップが作れるので、よりダンジョンっぽくできるかなーと思っています。

マップ上のアイテムの位置や大きさを固定できるようにした

実際に使ってみてつらかったのが、マップ上のアイテム（壁床などなど）を意図せず触れてしまい、移動してしまうことでした。いまのところアンドゥ機能を付ける予定がないので、このままではちと辛すぎる～ということで、マップ上のアイテム位置や大きさを固定できる編集オプションを作りました。

f:id:piyorinpa:20180617190957p:plain — 鍵マークを押すと位置や大きさを動かさないようにできる

（マップチップはbunaguchiさんからの借り物です）

こんなかんじで、実際に触ってみて追加すべき機能を検討しながら作っています。

そのほか

そのほかには以下のような機能を実装・調整していました。

背景設定機能（まだまだ調整が必要そう...）
コネクタ間移動のときのアバター（プレイヤーキャラクター）の移動位置の調整
各種編集インタフェースの調整などなど

そういえば、マップ編集やテストプレイの実装ばかりすすめているけど、実際にマップを移動してあそぶ機能（というか導線）をちゃんと作っていないなーと思ったのでした。その辺にそろそろ手を付けないとな...。

素材募集のおしらせ

このようなブログ記事に載せるためのゲームっぽい画像素材を探しています。私の使っていいよ！という方はぜひぜひお気軽に Twitter もしくはブログのコメントにてお声かけください！（お声掛けいただけると開発のモチベーションがとっても上がります。）素材を利用させていただく条件はこちらに記載しています。

雑記（だらりんぴっくについて）

家でも会社でもPCを触っていると電池切れしちゃう～という話を以前しましたが、最近は「この日はまったくPCを触らないぞ」という日を設けて、ひたすらだらだらしたりしながらバランスをとったりしています。（私は勝手に「だらりんぴっく」と称しています）

というわけで、だらりんぴっくのお供にしたまんがをぺたり。（特に感想とかは書いていないですが...）

tonarinoyj.jp

中世ファンタジー風の世界のおしごとまんが。中世欧州こじつけコラム「行末ファンタジア」が各話の間に掲載されているのですが、これが個人的に好きです。

sonorama.asahi.com

先ほどのまんがと同じ作者のまんが。世界中の雑兵がとあるアパートに集結するお話。

afternoon.moae.jp

ひさびさに本屋で表紙買いしました。（この作者の他の作品を月刊誌で読んでいたことがあったのですが、絵がきれいだなーと思っていたのでした。お話もおもしろかったので早く続きが読みたい...）

ではではー。

2018-06-12

ちょっっとだけJestをつかってみた

プログラミング JavaScript

こんにちはこんにちは。きょうはちょっとだけJavaScriptのテスティングフレームワークJestをお試しでつかってみました話をば。

趣味開発なので、がっつりテストプログラムを書くつもりはないのですが、それでも重要な部分（データを更新したり、読み込んだりなど）はテストがあったほうが安心できていいなーと思ったのでした。サーバ側ではRSpecを使ってテストを書いているのですが、JavaScript はどうしようかなーと思っていたので、今回はJestを素振りしてみることにしました。

インストール

インストールは基本的に公式のチュートリアル通りにやればよさそうなので、以下のページを参考にインストールしてみます。

facebook.github.io

まずはインストール。プロジェクトディレクトリで以下を実行します。

npm install --save-dev jest

適当にテストを書き（書いたテストについては後述）、テストを npm test で実行しようとしたら怒られてしまいました。

 This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.
 By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

ES201xな記述だと、どうやらそのままではテストできないみたい（import で構文エラーになってしまった）なので、babelをインストールします。

 npm install  --save-dev babel-jest babel-core regenerator-runtime
 npm install babel-preset-env --save-dev

あとは、.babelrcを以下のように設定します

// .babelrc
{
  "presets": ["env"]
}

package.jsonに以下を追加します

"scripts": {
    "test": "jest"
}

あとは npm test を実行してあげれば、テストを実行することができました。インストールはとても簡単でした。

簡単なテストを書いてみる

いまつくっているプログラムのテストを部分的に書いてみます。以下のプログラムは、与えられた文字列が意図した数値であるかを確認するためのものです。（開発中なので、このプログラムの良し悪しについては目をつぶっていただきたく...）

具体的には、次のような確認をします。

文字列が数値かどうか
整数値であることが条件の場合は整数値であるかどうか
最大値が設定されている場合は最大値以下か
最小値が設定されている場合は最小値以上か

関数は、意図した数値であれば数値自体を戻り値として返し、意図せぬ数値であれば例外をスローします。

// validateHelper.js

import * as Errors from './errors.js'

export default class ValidationHelper {

...

static isValidNumber(num, param = {}) {
  if( (typeof param.defaultValue !== 'undefined') && (typeof num === 'undefined') ) {
    return param.defaultValue;
  }

  if( param.isInt ) {
    if( !(/(^-?\d+$)/g.test(String(num))) ) throw new Errors.WrongIntValidationError('the string is including characters');
  } else {
    if( !(/(^-?\d+(\.\d+)?$)/g.test(String(num))) ) throw new Errors.WrongNumberValidationError('the string is including characters');
  }

  if( typeof param.maxValue !== "undefined" ) {
    if( num > param.maxValue ) throw new Errors.WrongNumberValidationError('given number is over than maximum');
  }

  if( typeof param.minValue !== "undefined" ) {
    if( num < param.minValue ) throw new Errors.WrongNumberValidationError('given number is less than minimum');
  }

  return Number(num);
}

こんな感じに使うことを想定しています。

// 与えられた文字列が数値かどうか
let hoge = Validate.isValidNumber(fuga);
// 与えられた数値が整数値でかつ、10以下か
let hoge = Validate.isValidNumber(fuga, {isInt: true, maxValue: 10});

とりあえず、まずは「文字列が数値である」という判定が正しく行われるかを確認するテストを書いてみます。describeでテスト条件によって適切にグループ化し、test内で確認をします。（後で知ったのですが、itもtestのエイリアスとして使えるみたいです(参考)。個人的にはitのほうが好きだなーと思ったのでした。）

今回テストしたい関数は「意図した数値であれば数値自体を戻り値として返す」仕様になっているので、数値が与えられたときに正しく数値が返されるかどうかを確認します。

テストのMatcher（判定器という感じかな？）は公式ドキュメントを見るのがよさそうなので、都度確認します。値が同一かどうかを確認するには toEqualが使えそうなので、これを使います。書いたテストは以下の通り。

import ValidateHelper from './validateHelper.js' 

describe('when number is given', () => {
  test('return number', () => {
    // 数値を渡したら数値が返される
    expect(ValidateHelper.isValidNumber(1234)).toEqual(1234);
  });

  test('return number when type of string', () => {
    // 文字列型でも数値が返される
    expect(ValidateHelper.isValidNumber('1234')).toEqual(1234);
  });

  test('return number when the given number is less than zero', () => {
    // 負号が付いていても数値が返される
    expect(ValidateHelper.isValidNumber('-1234')).toEqual(-1234);
  });

  test('return number when the given number includes a decimal point', () => {
    // 小数点があっても数値が返される
    expect(ValidateHelper.isValidNumber('12.34')).toEqual(12.34);
  });
});

つぎに、「最大値が設定されている場合は最大値を超えたら例外をスロー」が正しく動くかを確認してみます。書いたテストは以下の通り。

import ValidateHelper from './validateHelper.js' 

describe('maximum value is given', () => {
  test('throw error when given number is over than maximum value', () => {
    expect(() => ValidateHelper.isValidNumber('12', {maxValue: 10})).toThrow(/maximum/);
  });

  test('return number when given number is less than maximum value', () => {
    expect(ValidateHelper.isValidNumber(1, {maxValue: 2})).toEqual(1);
  });
});

「最大値が与えられた場合、最大値より大きな値が与えられた場合は例外を発生する」「最大値以下の場合は数値を返す」が仕様なので、それらを確認できるように書きます。例外が発生することを確認するには toThrow をつかいます。expect で例外を捕捉するには、functionでラップする必要があることに注意です。

ちなみに、toThrow には例外クラスを引数に取ることができるとドキュメントには記載されているのですが、なぜかうまくいかず。。。どうやら以下のリンク先と同様の事象なのかもという感じですが、具体的な解決策はもうちょっと調べないとわからないかなという感じです。

toThrowError not working with custom errors and Babel · Issue #2123 · facebook/jest · GitHub

ひとまずエラーメッセージを引数に取ることもできるようなので、今回はエラーメッセージを確認するテストとしました。

あとは同じようにテストを書いていきます。最終的に書いたテストはこちら。

// validateHelper.test.js

import ValidateHelper from './validateHelper.js' 

describe('#isNumber', () => {
  describe('optional parameter is not given', () => {
    describe('when number is given', () => {
      test('return number', () => {
        expect(ValidateHelper.isValidNumber(1234)).toEqual(1234);
      });

      test('return number when type of string', () => {
        expect(ValidateHelper.isValidNumber('1234')).toEqual(1234);
      });

      test('return number when the given number is less than zero', () => {
        expect(ValidateHelper.isValidNumber('-1234')).toEqual(-1234);
      });

      test('return number when the given number includes a decimal point', () => {
        expect(ValidateHelper.isValidNumber('12.34')).toEqual(12.34);
      });
    });

    describe('when the string includes invalid characters', () => {
      test('throw error', () => {
        expect(() => ValidateHelper.isValidNumber('123hoge')).toThrow(/including characters/);
      });
    });
  });

  describe('allow only integer', () => {
    test('throw error when given number includes a decimal point', () => {
      expect(() => ValidateHelper.isValidNumber('123.45', {isInt: true})).toThrow(/including characters/);
    });

    test('return number', () => {
      expect(ValidateHelper.isValidNumber(1234)).toEqual(1234);
    });
  });

  describe('maximum value is given', () => {
    test('throw error when given number is over than maximum value', () => {
      expect(() => ValidateHelper.isValidNumber('12', {maxValue: 10})).toThrow(/maximum/);
    });

    test('return number', () => {
      expect(ValidateHelper.isValidNumber(1, {maxValue: 2})).toEqual(1);
    });
  });

  describe('minimum value is given', () => {
    test('throw error when given number is over than maximum value', () => {
      expect(() => ValidateHelper.isValidNumber('0', {minValue: 1})).toThrow(/minimum/);
    });

    test('return number', () => {
      expect(ValidateHelper.isValidNumber(10, {minValue: 1})).toEqual(10);
    });
  });
});

つかってみて

インストールが簡単でよいなと思いました。とりあえず今作っているものでテストしやすそうなものを引っ張ってきて書いてみたので、今度はモックとかスタブとかを使いそうなものを使って書いてみようかなという気持ちです。また、Webpackとの組み合わせとか、Vue.jsのテストを書くには？みたいなところをクリアできればよさそうなので、引き続きお試ししてみようかなと思っています。

github.com

なにか進捗があれば書いていこうと思っております。ではでは。

2018-06-07

（開発報告）マップ接続UIつくっているよ！なはなし

製作報告みんなでつくるダンジョン

いつもの進捗報告

恒例のみんなでつくるダンジョンの進捗報告をばをば。いまは「マップ同士の接続をするためのユーザーインタフェース」をつくっています。（以前にも軽く紹介したかもですが、ただいまちゃんと使えるように作りこんでいる段階です）

マップ同士をつなくパーツを「コネクタ」と呼んでいますが、こんな感じに「どのコネクタと接続するか？」を画面上で選んでいきます。

f:id:piyorinpa:20180607225732p:plain — コネクタをみつける

まずは読み込むマップを選択し、表示されるマップからコネクタを選択します。マップが広いと画面に収まりきらないので、コネクタの存在場所を示す矢印が現れます。矢印のほうに向かってスクロールするとコネクタが現れるので、そいつを選択してやれば接続完了といった具合です。

とりあえずこんなかんじに作っておいて、あとは様子をみながら改良するとかしないとかをしていけたらなーと思っています。

f:id:piyorinpa:20180607232823p:plain — 矢印の向き計算と画面とコネクタのあたり判定

ちょっとだけ実装の話をば。矢印の向きはCSSの transform: rotate で指定してあげています。コネクタの中心座標と矢印画像の中心座標を結ぶ直線のなす角が回転角度になるので、距離 (x, y) を計算してJavaScriptのatan2 関数を使い、 回転角度 = Math.atan2(y, x) * 180 / Math.PI としてあげれば簡単に矢印回転角度を求められます。あとは transform: rotate(回転角度deg) を矢印画像のスタイルとしてあててあげれば、コネクタの位置を向くように矢印の角度を決定することができます。（CSSの画像変形は実装が楽でよいですね。）

ここで、ディスプレイ座標系はY軸が下を向くので、CSSで指定する回転角は時計回りが正の方向になるのですが、それをすっかり忘れていて1時間くらいつぶしてしまったのでした。また、右向き矢印の画像を用意しておくと、計算した角度をそのまま回転角度と出来て楽でよいです。

コネクタが画面内に表示されているときは矢印を出したくないので、画面とコネクタのあたり判定もします。 Ps1(x) > Pc2(x) Ps1(y) > Pc2(y) Ps2(x) > Pc1(x) Ps2(y) > Pc1(y) の条件をすべて満たせばコネクタ矩形が画面内に入っているということになるので、このときは矢印画像を表示しません。

これらの処理をマップをスクロールするごとに行えば、矢印がいい感じに動いたり表示されたりされなかったりするようになります。

雑記

昼間はおしごとでプログラミングをし、夜はこつこつと趣味開発を続けていますが、たまにパソコンから離れないと電池切れになってしまい、PC作業系についてはなにもしたくなくなってしまうことがあります。ということで、それを防止するために今週末はまんが大会と称して積みマンガを消化していたりしました。気が付いたころに電池切れになって開発がエターなってしまう、みたいなことにならないように気を付けたいなと思ったのでした。

ではでは。

2018-05-31

開発報告（6/1版）

製作報告みんなでつくるダンジョン

前回の開発報告から日が開いてきたのでひさびさの報告をばをば。とはいいつつも、サーバ側で処理するあれやこれやを実装していたりしたので、派手な成果はないのでした。

とりあえず現状のマップエディタを使ってみた

作ってばっかりいると、ついつい使うのを忘れてしまうのですよね。というわけで、ちょっとマップを作ってみました。画像は墨cm様からお借りしたものを使います。マップチップを置くとそれっぽくなったなぁとうれしくなりつつ、マップに使えそうな画像一式を送っていただきありがたいなぁと思いました。

（このようなサンプル画像に使っていい画像を募集しているので、「つかっていいよ！」という方はお声かけください！利用条件などはこちらです。ただし、作者は気まぐれなのでいつ利用させていただくかはわかりません...）

f:id:piyorinpa:20180531225118p:plain — マップを描いてみたよ！

やっぱり実際に使ってみるの大事ですね。アイテムなどの配置のしづらさや微妙なあたり判定バグなどがいろいろ出てきて、まだまだいろいろ作りこまないとなぁと思ったのでした。道のり険し...

レイヤー機能を実装した

先ほどの画像で樽や看板が草に隠れている場面が映し出されていますが、このような表現を実現するために「レイヤー機能」を実装していたりもしました。画像エディタとか、ツクールとかウディタとか使っている人にはおなじみのやつですね。マップチップに前後関係を持たせることができるようになるので、ちょっとだけ表現の幅が広がりました。ちょっとだけ実装のお話をすると、（描画にはPixiJSを利用していますが、）PixiJS単体ではレイヤー機能はありませんが、拡張ライブラリを入れることでレイヤー機能を簡単に利用できます。公式のサンプルはこちら。 https://pixijs.io/examples/#/layers/zorder.js

f:id:piyorinpa:20180531225740p:plain — レイヤー番号を指定して所属レイヤーを決めます

PixiJSはV5が開発中のようですが、楽しみである一方、アップデートがスムーズにいくといいなぁとちょっとだけ恐々としています。色々見こしてレンダラまわりはある程度融通がきくように作ってはいるつもりですが...

そのほか

あとは概ね以下のようなことをしていました。（主に開発環境の構築まわりとかのお話なので、「へぇー」程度に眺めてください）

Webpackのアップデートなど、開発環境まわりの整備
コネクタまわりの公開設定などまわりの実装（このあいだのブログ記事に書いたこいつを実装している最中）
サーバ側のアプリケーションのテストコード書く準備など
- サーバ側アプリケーションにはRuby on Railsを利用しています
- とりあえずRSpecとfactory_botを入れてテストコードが書けるようになりました
- 今回はサーバ側もちょっと複雑になりそうと思ったので、テストは書かないとなぁとおもいまして...
- フロントエンド側のテストどうするかなぁ...

雑記

作っているとやっぱり見た目は大事だよねと思うわけです。この間、開発環境一式をつめこんで4KディスプレイなPCに接続してみたら、「あれ？なんか違うなぁ...」となってしまい、ちょっとだけ落ち込んだのでした。ディスプレイによって色味や解像度が違うので、いつも使っているPC以外に接続してみた目を確認するのは必要かもなという気持ちになりました。

また、見た目がよろしくなると「うぉーつくっているぞー」感が出てやる気が上がったりするので、もうちょいとその辺頑張りたいなと思ったのでした。

さいきんはウェブ上にすてきなアニメーション効果などをふんだんに使ったサイトをたくさん見られるので、その辺を参考にしながらいい感じにしていければよいですね。（最近は、そういうサイトを見ていると「いいなぁーこういうのをつくりたいのよなー」という気持ちになったりしています）

ではではー。