「DataBaseEditor」進捗状況②

はじめに

ツール開発担当のShickです。
「DataBaseEditor」ツールの進捗報告２回目ということで、
進捗状況をざっくりと記載します。

進捗報告１回目の記事はこちら

https://ci-en.net/creator/12715/article/664643

「DataBaseEditor」とは

「DataBaseEditor」はRPGツクールMV・MZのイベント・データベースのデータファイルに対して直接編集を行うツールです。
RPGツクールMV・MZのデータ編集機能には存在しない各データの新規挿入・削除・入れ替え等の機能を追加し、ゲーム制作の補助を行うことが本ツールの目的となっています。

対応OS

Windows・Macの両OSに対応

発売時期

2022年中に発売予定

価格

未定
※無償で体験版の配布についても考えています

進捗状況

全体的な進捗：50%ぐらい

データ編集の機能(右クリックメニューの機能)

• データリスト内で直接データの名前を変更する機能
  　完了
• 新規のデータを挿入
  　完了
• 既存のデータを削除(複数選択削除可能)
  　完了
• 既存のデータを指定した位置に移動(複数選択移動可能)
  　完了
• 上記データ編集に対しての「IDの置き換え処理」
  　未着手

操作に関する機能

• データ編集機能の各種ショートカット機能
  　完了
• Undo・Redo機能　※ExcelにあるCtrl+zとCtrl+yと同じ感じ
  　完了
• 編集したデータをファイルに保存する機能
  　未着手

その他

• バックアップ機能
  　未着手

現段階での画面のサンプル

あとがき

厳密にはもう少しコンポーネントを分けるとかコードの見直し等は残っていますが、大雑把な進捗状況としてはこんな感じになっています。

早めにそれぞれの機能を完成させてテスト・見直しに集中したいとこですが、
自分の設計・コーディングの能力が不足しており、それぞれの作業に時間がかかっている状況です。
※こうやれば出来そう⇒小さい問題が複数出てくる⇒想定より時間がかかる
　ということが多いです。

来月の進捗報告の際には大体の機能の実装を完了できればなーと思っています。
※ツールの開発のほかにもRPGツクール自体に関わった作業とかもしたいですしね。

これからも本サークルを何卒よろしくお願いいたします。

ご挨拶、及び「DataBaseEditor」進捗状況➀

ご挨拶

初めまして、ツール開発担当のShickです。
高校時代の同級生であるshunから誘われた流れで本サークルに参加することになりました。

今は「DataBaseEditor」の開発に着手しており、それが終わったらRPGツクールでの制作や別のツールの開発等を行っていこうと思っています。
※自分は絵とか文章は全く書けません！

DataBaseEditorの再構築について

ツールの作り直しについて、ちょっとだけ技術的な話を含めてお話しします。

今年の4月中旬あたりまで「Javascript」の「jQuery」というライブラリを使用して開発を進めていたのですが、それを止めて「React」という流行りのライブラリとそのUIライブラリである「MUI」を使用して作り直すことになりました。
以下に各ライブラリの利点・変更した理由等を記載します。

Reactの主な利点

• コンポーネントベース(部品毎に分割)で開発が出来、管理・改修がやりやすい
• 画面を再描画する際に、変更された箇所だけ処理される為パフォーマンスが良い
• 画面で使用しているデータが変更された際に、自動で再描画してくれる機能がある
  ⇒通常はコードを細かく書いて制御することになるので開発が大変・バグが出やすい

MUIの利点

• 一からコンポーネントやレイアウトを作る必要がない
• 機能の拡張、レイアウトの変更が容易

まとめ

• 開発の工数を抑えて管理もしやすくなる
• 「DataBaseEditor」を一度リリースした後も機能を拡張しやすくなる
• 別のツールを開発する際にも経験が生きて将来性もある

ツールの機能について

「DataBaseEditor」はRPGツクールMV・MZのデータファイルに対して直接編集を行うツールであり、機能としては現状以下を考えております。

データ編集の機能(右クリックメニューの機能)

• データリスト内で直接データの名前を変更する機能
• 新規のデータを挿入
• 既存のデータを削除(複数選択削除可能)
• 既存のデータを指定した位置に移動(複数選択移動可能)
• 上記データ編集に対しての「IDの置き換え処理」
  ⇒イベント等で使用しているデータのIDも自動的に置き換えする機能

操作に関する機能

• データ編集機能の各種ショートカット機能
• Undo・Redo機能　※ExcelにあるCtrl+zとCtrl+yと同じ感じ

現段階での画面のサンプル

※色等は現段階では仮置きで作っています。

進捗状況

全体的な進捗としては現状20～30%程度かなと思っています。
「操作に関する機能」がまだ未着手で、何より「IDの置き換え処理」がどれぐらいの期間でできるかの見込みがたっていません。

最後に

「DataBaseEditor」に関しての記事が大分空いてしまい申し訳ありません！
再構築する際に色々詰まってしまい、進捗が上がらず記事が書けませんでした。
少しずつですが「React」の書き方に慣れてきており、これからはもう少し定期的に進捗を報告できると思います。

これからも本サークルを何卒よろしくお願いいたします。

開発環境を整える VSCode と Text2Frame のご紹介

はじめに

シナリオを執筆する際、ツクールのエディタに直接記述している方とテキストエディタで文章を書いてから後でエディタにコピペする方、大きく分けてこの二通りの作り方があると思います。

今回は先にテキストエディタで記述している方に向けて便利なツールを紹介する記事となっています。

導入するツール（プラグイン）は 2 つ 「Text2Frame」と「Visual Studio Code」です。それぞれのリンクを張っておきます。

• Text2Frame
  https://github.com/yktsr/Text2Frame-MV

• Visual Studio Code
  https://azure.microsoft.com/ja-jp/products/visual-studio-code/

Text2Frame

外部のファイルに記述したテキストをツクールのエディタに読み込んでくれるプラグインです。専用のタグを記述することでメッセージ以外のコマンドも読み込むことができます。

言葉だけでは分かりづらいので実際に使用しているところを動画に撮影しました。

便利ですね！だけどタグを打ち込むのが面倒くさい！と思った方も多いハズ
そこで Visual Studio Code （以下 VSCode）の出番となるわけです。

Visual Studio Code

プラグインの開発からデバッグ、ツクールのプラグイン開発に関わらずありとあらゆる分野で活用されているプログラマー向けのコードエディタですが、高機能なメモ帳としても活用できます。

今回は高機能なメモ帳として活用していくための機能を少し紹介したいと思います。

どんなことができるのか

すごい使い方をしている人では藤井太洋さんというSF作家さん。
こちらの方は小説執筆用にかなりカスタマイズをして使用されているみたいです。

https://twitter.com/t_trace/status/1536875267615993856?s=20&t=xBBG4mY6NwklXkAOEFyvzA

関連記事
https://forest.watch.impress.co.jp/docs/review/1417878.html
https://logmi.jp/tech/articles/325715

ここまでのことをするには VSCode の拡張方法を詳しく知る必要がありますし、自分もそのあたりのことは詳しくありませんので紹介するに留めさせていただきますが、こんなこともできるんだ！という可能性を感じていただければなと思います。
（ツクールのシナリオの記述がしやすくなる拡張、誰か作ってくれないかなぁ）

入力補完（コードスニペット）

VSCode の強力な機能として入力補完を行うコードスニペットを独自に定義することができることです。コードスニペット？なんのことやらという感じだと思いますが一般的にはスニペットとは断片という意味で、辞書登録機能のようなものです。

辞書登録と違うのは完全に入力して変換をするというわけではなく、一部の文字を入力するだけで、補完される候補として提案してくれるということです。

これも言葉では伝わりづらいため動画にしました。

また、あくまでVSCodeのワークスペース（ツクールのプロジェクトみたいなもの）にしか影響が無いということです。これによってゲームのプロジェクトごとに固有の設定をすることが可能です。

たとえば登場するキャラクターはゲームによって異なってきます。
プロジェクト固有のプラグインやコモンイベントを呼び出すこともあるでしょう。

それを辞書登録してしまうと、他のプロジェクトでゲームを作るときに邪魔になります。
個別のプロジェクトごとに設定できたほうが都合がいいわけです。

コードスニペットの定義方法

.vscode フォルダの中に任意の名前で拡張子 .code-snippets というファイルを置きます。中身は次のように記述します。

{
	"unique name":{
		"prefix": "namebox",
		"body": "<Name:$1>",
		"description": "名前欄の指定"
	},
}

• unique name
  任意の文字列です。スニペットを識別するために被らない名前である必要があります。

• prefix
  ここに記述された文字列を入力した際に、候補として提案されるようになります。

• body
  ここの内容が、スニペットを選択した際にエディタに記述されます。

• description
  スニペットの説明です

説明されただけでは分かりづらいと思いますので、コードスニペットの定義ファイルを含め、Text2Frame の設定も行っているプロジェクトを配布します。試しに使ってみてください。

.vscode というフォルダがある場所を、VSCode で開くだけでOKです。
インストール方法などは特に難しいことは無いと思いますので割愛します。わからなかったら調べてみてくださいね。

ゲーム開発する上で VSCode は様々な事に活用することができます。
今回は Text2Frame との連携についてでしたが、以前記事にした git と連携することも可能です。開発環境を整える第一歩として VSCode の導入はいかがでしょうか。

それではよいツクールライフを！

【ルイコでもわかる】二週目開始処理のつくりかた

はじめに

お久しぶりです。気を抜くとすぐに一月経ってしまいますね。
4月は全く更新できなかったので5月はあと2回くらいは更新したいなと思ってます。

今回はプラグインを使わずにスクリプトを1行（条件分岐と合わせると2行）書くだけで簡単に二週目を開始する処理を作っていきます。

まずは実際に作ってみたものを動画にしたのでご覧ください。

つくりかた

作り方は非常に簡単です。

セーブ画面を開く前に次のスクリプトを記述。

$gameTemp.toTitle = true;

条件分岐：スクリプトに次のスクリプトを記述するだけです。

$gameTemp.toTitle

ちなみにですが toTitle の部分は条件分岐とスクリプトで一致していればどんな名前でも大丈夫です（他の変数名に被らない限り）

実際に使用する際には、動画でお見せしたようにセーブ後に確認のメッセージがあったほうが親切だと思います。それらの処理が追記されたものが次の画像です。

簡単ですね。

セーブの表示にクリアデータなどと追記できるプラグインなどを活用するとよりわかりやすくなるのではないでしょうか。

なぜこうなるのか

通常、イベントコマンド「セーブ画面を開く」を使用してセーブを行った場合、ロードをすると直後のイベントコマンドから実行されることになります。その為、「セーブ画面を開く」と「タイトル画面に戻す」を続けた場合、ロードしてもすぐにタイトルに戻ってしまいます。

$gameTemp という変数は一時的な保存先として使用されることを想定したグローバル変数です。例えばマウスクリックしたときの目的地等に使用されています。ちなみにですが Temp というのは Temporary の略で「一時的」という意味の英単語です。

$gameTemp は ニューゲームとロードゲームの際に初期化されます。
最初の一回はセーブの前に $gameTemp.toTitle を true にしているため条件分岐の中の処理を通過することができますが、一度タイトルに戻りゲームをロードしたときには $gameTemp.toTitle は初期化され false となっているため条件分岐の中の処理がされることはありません。
（正確には toTitle は undefined になっています）

おわりに

今回は趣向を変えて開発TIPSの紹介でした。
同じ処理をつくる場合でも様々なアプローチがあります。このやり方が絶対に正しいという事はありませんので、色々試してみるといいのではないかと思います。

もし、この処理はどう作ればいいんだろうという質問がありましたらコメントをお願いします。試しに作ってみて記事にするかもしれません。（必ず返答できるかはわかりません、時間もかかりますので急ぎの場合は他のコミュニティで質問してください）

次回は VSCode と Text2Frame を導入して開発効率を上げることをテーマにした記事の作成を予定しています。

バックアップをとろう Git のすゝめ

はじめに

本記事は一切バックアップを取っていない人、バックアップを取っているが毎回手作業でやっていたり、Google Drive や Drop Box といったクラウドストレージサービスを利用している方に向けて git の有用性を伝えるための記事になっています。

git についてご存じで利用されている方はネット上に git に関する記事がいくらでもありますので、あえて記事にする必要がないと思われるかもしれません。ただ既に git をご存じの方はお仕事でプログラマーをされている（いた）、もしくは近しいお仕事をされている方ではないでしょうか。

これまで git というツールを知る機会がなかった方のために git を知ってもらうきっかけになればと思い記事を作成しました。

今回は導入や操作方法には触れません。あくまで git を知ってもらうということを目的としています。

導入については近いうちに別の記事にしたいと思いますが、この記事を見て今すぐにでも導入したいという方はご自身で調べてみてください。

git の利用に向いている方

• 単純なバックアップ以上の機能を求めている方
  （バージョン管理がしたい方）
• ローカル環境でのみバックアップをする必要がある方
• 複数人数で開発をしている方

単純なバックアップ以上の機能を求めている方

git には様々な機能や特徴があります。以下に例を挙げます。

• 作業の巻き戻しが簡単でわかりやすい
• 不必要な変更履歴を作らない
• バグ修正と並行してバージョンアップなどの対応ができる

作業の巻き戻しが簡単でわかりやすい

git では変更とあわせてコメントを残すことができます（というかその手順がセットになっています）。それによってどの時点まで戻せばいいのかわかりやすくなっています。

また、変更内容に関係するファイルが複数ある場合でも一度の操作で関係する複数のファイルをまとめて巻き戻しが可能です。

巻き戻した後からさらに最新の状態にすることも簡単にできます。

どのくらい簡単かというと巻き戻すのに必要なクリック数はわずかに３、４回です。（クライアントツールを利用した場合）

これができるとどうなるのという話なのですが、次の経験はないでしょうか。

以前までは問題がなかったのにいつの間にかバグが発生していた

原因となりそうな変更がすぐにわかればいいのですが、全く見当がつかないこともあります。その場合、適当に履歴をさかのぼってどの変更によって問題が発生したのかを確認することで原因の究明につなげることができます。

原因がわかれば最新の状態に戻して修正を加えてももいいし、特定のファイルの変更が原因ならそのファイルだけを巻き戻すといったことも簡単です。

他のサービスや手動でのバックアップでも同様のことができなくはないでしょうが、git はこの操作が比較的簡単にできるという事です。

不必要なバックアップや変更履歴を作らない

1日のうちの特定の時間にバックアップを取る場合、変更がなくても全てのファイルのバックアップを取ることになります（変更があったファイルだけを保存するような仕組みでない限り）。

ファイルを更新するたびに履歴を保存する場合、空行を追加しただけで変更が入ったとみなされ、不要な変更履歴が作られます。中には変更がなくてもタイムスタンプに変更があるというだけで履歴が作られることもあるでしょう。

git の場合変更内容をコメントで残すという手間が増える代わりに、不必要なバックアップが作られることはありません。

これは手作業で細かくバックアップを取っているようなものなので、手間が増えるデメリットとも言えます。 ただ、その手順、巻き戻し操作なども含めて一つのアプリケーションで完結するためエクスプローラー上で一つ一つバックアップを取るよりは非常に楽です。

デメリットを補って余りあるメリットがあるからこそ、世界中の人が利用しているわけです。

バグ修正と並行してバージョンアップなどの対応ができる

次のアップデートの為の作業途中に急ぎ修正が必要なバグ報告が上がってきた。
今の作業を中断してバグ修正作業をしたいが、今の中途半端な状態の変更をバグ修正バージョンに含めることができない。

といった経験があるのではないかと思います。

その場合、以前にリリースしたバージョンを探してきて、そこだけ修正を加えて、アップデートバージョンにも同じ変更をくわえて…といった非常にややこしい手順を踏む必要があります。

もしくはアップデート作業が終わるまで手を付けることができないという事もあるかもしれません。

git では特定のバージョンから分岐したバージョンを複数持つことが可能です。これがブランチと言われる機能です。

巻き戻し操作などと同じ感覚で修正用のバージョン（ブランチ）とアップデート用のバージョンを切り替えることが可能です。体験版などの専用のバージョンを用意するためにも利用できるでしょう。

当然、分岐した後に一つに統合することができますし、特定の修正だけをアップデートバージョンに取り込むといった操作も可能です。

これによって同じ作業を何度も繰り返すようなことをしなくてすむようになります。

ローカル環境で開発をしている方

勘違いしやすいのですが git はローカル環境でも利用することができます。
git 自体はローカルで動作するアプリケーション（ツール）の名称です。よく名前に挙がる Github はクラウド上で git を利用するサービスの名称であって git とは別のものです。

様々な事情によりクラウドストレージサービスを利用できない方がいらっしゃるかと思います。バックアップとしての用途としては効果が限定的になりますが PC 一つでも利用できますし、ローカルネットワーク上のストレージ（NAS）を活用することも可能です。

複数人で開発をしている方

Github などのクラウドサービスの利用が必要になりますが、複数人で開発をしている方にもオススメです。誰がどういった変更を行ったのかがログを確認することで把握することができますし、同じファイルに同じタイミングで変更を加えた場合は単純な上書き操作ができなくなります。

（正確にはローカルファイル上では変更を加えることができますが、共有されるデータへの反映にひと手間かかります）

これによって意図しないファイルの巻き戻りを防ぐことができますし、誤って上書きしてしまっても変更履歴からの復元が容易です。

クライアントツールについて

git は本来キーボードでの操作しかできないツールです。ただし、それでは多くの人にとっては使いづらいために、マウスによって操作できるようにしたツールが git クライアントとよばれるものです。

ちなみにキーボードによる文字入力で操作可能なインタフェースを、キャラクターユーザーインタフェース、略して CUI といい、マウス操作などが可能なインタフェースをグラフィカルユーザーインタフェース、略して GUI といいます。そのため正確には git は CUI のツールでクライアントツールは GUI のツールになります。

今回記事にした内容はクライアントツールを使用している前提となっています。

もし git を使ってみたいという方は「git クライアント」と検索してみてください。ちなみに私は Source Tree というクライアントを利用しています。

おわりに

今回の記事では git の有用性を伝えるため、自身の開発経験をもとにして使っててよかったなぁと思うことを中心に記事にまとめました。ただ絶対に git を使用した方がいいという事ではありません。

クラウドストレージサービスは簡単につかえるという何にも代えがたいメリットがあります。現状で問題を感じていない方は無理に git を使用する必要はないかもしれません。

とくに git での管理に向かないファイルなどもあり、単純なファイル共有の為であればストレージサービスを利用する方がいいでしょう。

また git を知らない方にわかりやすく伝えることができるように git に関連する用語を極力使用せずに書いたつもりです。明らかにおかしいと思われる点についてはご指摘いただければと思います。