ゲームを作っているとどうしてもデータというのは作らざるを得なくなるわけですが、
このデータをソースに直接打ち込むのは面倒だしあまりスマートではない。

たまに凄い配列を作ってそこの1番目の数値がなんぼで～番目の数値が…とやる人もいますが、
学生なら時間がたくさんあるからそれでも問題ないけど、仕事でやっていると期間は限られているのでそんなやり方は非効率的です。
というかプログラマーという存在がいなくても、プログラムをよく知らない人しかいなくても手っ取り早くデータが作れる、
くらいのシステムをあらかじめ作っておく方が望ましいのです。

まぁそういう楽をしたがる人間が多いからこそ、
「プログラムを生成するプログラムを書く」みたいな概念も出てきているわけなのですが…


そんなこんなで会社の仕事を楽にするためにゲーム作成エディタを作っておりました。
毎度お馴染みC#言語でのフォームアプリケーション開発。
フォームアプリは初めて使いますがAndroidのプログラミングに慣れてればどうにかなります。
グラフィックはC#版DXライブラリを使用。
しかしあとで描画周りだけUnityに差し替えなければ…



こういうのを開発しているとやっぱりC#は偉大だなぁと実感してしまいます。
GUIとオブジェクト指向は相性が良いのかもしれません。
ゲーム専門学校はこれからC#で教えりゃいいのに…と考えてしまうが、
まだまだコンシューマだとCとC++は現役らしいですね。

もっとハードの性能が上がればいいのに。

GUIでしかデータを作れない、ということになってしまうとそれもまた緊急時に困ることになるんですよね。

ゲームのデータは、コード上は構造体の初期化データという形ではなく、バイトデータになっている場合が多いのですが、そういうときはマクロが活躍します。
コードを読んだり直接編集するときの助けになるようにマクロを使い、GUIツールはマクロを含んだコードを吐くという感じにするとトラブルに強くなります。
開発効率は若干落ちますが。

ISLeさん
コメントありがとうございます。
＞ゲームのデータは、コード上は構造体の初期化データという形ではなく、バイトデータになっている場合が多いのですが
端末依存の機能の関係もあって今回はBinaryReaderやStreamが使えないため、
今回はテキスト形式でデータ取り込みを行っているのでGUIツールから吐き出すコードは実はバイトデータではなかったりします。
具体的にはJSON化されたデータ文字列を出しているだけなのですが、これをパーサを使って解析→データ化
といった感じです。

＞コードを読んだり直接編集するときの助けになるようにマクロを使い、
＞GUIツールはマクロを含んだコードを吐くという感じにするとトラブルに強くなります。

ツールからだけではなく直接編集できるような機能もあったほうが緊急時に役立つというわけですね。
検討しなくては…

いまはプリプロセッサのない処理系が多く使われていますから、作業工程そのものが大きく見直されているようですね。

ガラケーのアプリを開発しているときは、Javaのソースコードをプリプロセッサに通したり、自動化できそうなところは処理系の枠を超えてやってましたけど、そういった細かい工夫の余地が少なくなりましたね。
その分、ソーシャルゲームの開発とかは、物理的に手を速く動かすことが求められるようになっているようにも感じます。