FC2ブログ

プログラミング配信してみた

とりあえず一回プログラミング配信してみた、内容としてはウィンドウの基本部分の実装をした
配信ページ

やった感想としては、当然ながら人もこないしコメントもなく最低でも体験版出してて進捗が気になるとか人でもいないと配信してどう?って明確なあれはないんですが、見られているかもしれないというのでちょっと緊張感があるのと自然と独り言が増えてラバーダックタイピングが無理なく出来るので配信の手間がほとんどかからないから定期的にやろうかなと思いました

・新作の実装あれこれ
ゲームバランス的なのは作りながら考えるのでまずは各種ウィンドウを作ってUIを形にする
UIは触れるけど内部の処理はハリボテで後から実装する感じ

必要なウィンドウと操作方法案
FBS同様RTS風だけど実際はターン終了時までに操作を仮決定して次の日確定する方式にすると思う
前作同様右クリックでヘルプウィンドウをオンオフするので左クリック/ドラッグだけで操作可能

・従業員の雇用
雇える従業員が一覧で表示
チェックを入れると一日の終わりに雇って、翌日の朝に雇用される
この仕様だと雇ったその日はどこにも配属されないので研修でもしてる事になる

・従業員一覧とパーティ編成
従業員右クリックしてウィンドウ出して装備変更とかやると操作性が悪そう
「仕事内容」「パーティ配属人員・・・・」といった感じで部隊が並ぶ
仕事内容のところにダンジョンをドラッグすると、探索するダンジョンが変わる
人員をドラッグして別パーティに放り込むとパーティメンバーの入れ替えができる
「New」ってところにダンジョンやアイテムをドラッグすると空のパーティが新しく作られる
といった感じ
装備の変更は在庫があるアイテムをドラッグしてメンバーにドロップすると装備が交換される

FBSだとトグル式で解雇昇給減給も同じウィンドウだったけど分かりにくいし指示忘れが起こりやすかったので月末に専用画面で決定するようにしようかな?

・アイテム一覧
素材と作れるアイテム(作ったアイテム)とそれぞれの在庫が表示される
ドラッグして従業員に装備、納品依頼にドラッグで依頼完了する
アイテムは作りたい上限数を設定すると在庫数に応じて作っていく感じにFBSから変更
縦1列に並べて横に◀ 数字▶みたいなのを置いて、三角クリック or ドラッグ or 数字上でマウスホイールで数値変更って感じかな?

・ダンジョン一覧
発見したダンジョンと攻略率、ダンジョンレベルが一覧で表示、ドラッグでパーティに探索場所を指示する

・経営戦術の選択
操作方法はFBSと一緒、最大MPの上限はなくすので表示は色々変わる
タブで戦術カテゴリーを選んでその日に実行する戦術をクリックで仮指定して次の日の朝に実行される

・納品依頼やクエスト
現在来ている依頼一覧、納品依頼なら必要数や性能要件、討伐依頼なら対象や達成率が表示される
アイテムをドラッグして納品する形だけど終盤につれ一口辺りの納品数を増やすとか自動納品設定なんかをつけて依頼が増えて操作が大変みたいな事にならないようにする

・ギルドの各種情報
各種ギルドの情報が表示

・ログ-収支
イベントメッセージや統計情報を表示

・目標
勝利条件とかの確認

・その他
ゲームスピード/タイトルへ戻る/コンフィグ/ヘルプなどを開くボタン

・店舗
FBSではあったけど今回は無しかな?
今回は地図が無いので代わりギルドの様子をそこに表示する感じでも

大体こんな感じかな?そんなにややこしいことはなさそうではある
スポンサーサイト

面接落ちました

とりあえず先日の面接は落選になりました
理由としては推測と就活サイトに来た会社の不採用理由みたいなのによると
・面接の受け答えもあれでメンタルも弱そうだし鬱病が再発しそうな感じに思われた?のか受け入れが難しい
・単純に緊張しすぎて声小さかったりコミュ力低いと思われた
・技術的な質問の受け答えをミスったのと、チームでの開発経験が少ない
とかこんな感じかな、全体的に面接のときうまくしゃべれなくてやっぱりって感じ(´・@・)トホホ

まぁ一次面接通っただけ良かったし、何社か受ければ面接も上手くなる可能性はあるんかな~
個人的にはいっそのことインディーズゲーム開発とかで生計立てれたらなとも思うけどそれも難しいよね

ていうかいつプログラミング配信するんだろね?

あけおめ 2019

あけおめことよろ(´・@・)

 ゲーム配信は数回やってますが、ブログ更新さぼってました。私は元気です
面接は一次は一応通って来週最終面接ですので頑張るぞい

 配信コメント(読み上げつけ忘れて気づかなかった)でFBSのフルスクリーンが可能かどうか質問がありましたが、ウィンドウの解像度は上げれるけどフルスクリーンモードは無理なはず

 PoEばっかやっててゲーム開発進んでない気がするけど、どっかでプログラミング配信したいと思います、その時はツイッターにも告知するかな?

ギルド運営ゲームネタ

〇ゲーム配信
明日Path of Exileの新拡張がくるのでそれの配信をテストを兼ねてやってみます
ネットワークのラグどうとかが酷かったらやらない
ツイッチ配信ページ
何万年かぶりに来週面接なので喋る練習になるかなって

※追記
予想通り視聴者いなくてコメントは0でした・・・(多分、ちょっと覗いてスッと見るのやめた人は数人いたっぽい?)
やってみた感じとしては人がいないのは分かっていても見られているような緊張感があるので、例えどんだけ過疎ろうともプログラミング配信やるのはモチベ管理としてはわりと効果がありそうな気がしました
ネットワークのラグとかは気にならなかったけど、マイクの位置の関係でノイズとか発声とかがちょっとあれだったかも
明日以降はやるか分かりませんが、配信告知とかツイッターでした方が良いのかな?

〇新作案
経営ゲームはアイデアを詰めてたんですが、どうしてもFBSと差別化が難しいのと、焼き直しみたいになると制作モチベーションの維持がむずかしいってなりそうなのでギルド運営ゲームって感じにしようかなと企画し直す事にしますよ~

 UIとか操作方法全般はFBSを踏襲したりブラック度とかMPに相当するシステムとか雇用のあれこれとかノウハウやアイデアやら基本コンセプトはかなり流用する感じ

ダンジョンがあって、いくつかある冒険者ギルドの長になって活動して勝利条件を満たすのが目的
勝利条件は例えばお金をいくら貯めるとか、社会貢献度が一定以上とかダンジョン制覇とかそんな感じでモード毎に違うとか

ギルド員は戦闘メインだったり探索メインだったり拠点での生産や研究が得意とか武器経営ゲーに比べると従業員のパラメータにゲームデザインの幅が広くなるかな~って感じ

プログラムの設計~

というわけで新作のコード設計などを進める

 最近の自分のコード設計は
・プログラム全体から参照するような変数と処理
・ゲームでの各場面
・各場面に存在するオブジェクト
みたいな感じに各ソースコードをフォルダに分けて、管理しています

1.プログラム全体から参照するような変数と処理
 各画像や音声などの読み込み処理
 列挙型の定義
 設定値やゲームの最高記録などの変数の定義
 データの保存
 設定の変更

 上のコードはSystemってフォルダに入れる。最近はどんなゲームでも上5つは固定で実装してる感じで、そこまで大きな設計上の変更は起こりにくい、変数や列挙型はどんどん増える。

2.ゲームでの各場面
 タイトル画面
 メインメニュー画面
 設定変更画面
 ゲーム難易度やモード設定画面
 セーブ&ロード画面
 メインゲーム画面
 
 こんな感じで各ゲームの場面毎にクラスを作って、Sceneってフォルダに入れてる。ゲームによってどんなクラスを作るかはまぁまぁ変わる。それぞれは独立しているので後から増えてもあまり問題は無い。
 メインゲーム画面とかはソースコードが肥大化しやすいのでその辺りはうまいことオブジェクトに処理を持たせるようにする。

3.各オブジェクト
 従業員
 職人
 店員
 装備品
 店
 店AI
 経営戦術
 ボタン
 つまみ
 選択ボタン
 ベース経営ウィンドウ
 雇用ウィンドウ etc
 ハンター
 ・・・

 各場面のメンバー変数として使う各種クラスをObjectってフォルダに入れている。何のクラスが必要かを考えていってゲームの設計と同時に仕様を固めていく。処理が肥大化したり、同じ処理が見られた場合はオブジェクトとしてコード書いて分割して何やっているかを分かりやすくする。
この分類の処理は基本的に初期の設計からソースコードが増えたり減ったりするし、種類も多く機能の分割やら設計でセンスが問われると思いました。

・設計作業まとめ
 まずは何も書いてないソースコードだけ先に作り各ソースに処理書いていけば完成って状態になれば設計完了、実際には見落としだったり新しいアイデアを思いついたり、作ってみたら微妙だったりで新しい場面やオブジェクトが必要になるので、変更に強いコード設計の重要性がうんたらかんたら。
 先に設計をして各コードに何の処理を実装するか決めていれば複数人でも実装を並行して進める事も出来るんちゃいますかね?

・設計の時気をつける事
1.仕様変更への耐性
 作っている途中で企画の良くない点が明らかになったり、新しいアイデアを思いついたり、仕様に見落としがあったりで、仕様変更というものがそれなりに起こるため、仕様変更が面倒になるコードは良くないし、FBSとかはその辺りが色々ひどかった。
 仕様変更をしやすいコードの基本としては、機能を分割して変更の影響がどこに出るか分かりやすくする。どこで何の処理をしているか分かりやすくする。同じ処理は一箇所にまとめる。複数のアイディアがあって事前に仕様変更が想定出来る場合は処理の切り替えが可能な組み方にする等を気をつけます。
 すべてケースバイケースですが、経験的にどういう感じの仕様変更が起こりやすいかがわかってくると良い設計がしやすいので、何を作ろうとしているかの理解が大事だと思う。

2.分かりやすさ
 コードを書いていくと行数が何万行とかソースファイルの数が三桁とかになるので、わかりやすさはとても大事。
ファイル名をみただけで何の処理をしているか分かる。変数をみただけで何の変数か分かる。関数の処理を抽象化して何をしているか分かりやすくする、適切なコメントをつける。
 変数名を日本語にするのと、関数が肥大化したらサブルーチン的な感じにする、改行やらインデントやら変数の命名規則を守っていく等のコーディングレベルでの対策と、設計の段階で処理を適切に分割してクラスを定義する等設計レベルでの心がけが大事。

3.バグの耐性
 プログラムは複雑なので意図した通りに動かない状態になることはままあるので、不具合が起こりにくい、不具合が起こってもどこで不具合が起こっているか特定しやすい状態にするのが望ましい。
 不具合を起こりにくくするには、機能分割や単純な実装や分かりやすいコードを心がけてミスを起こりにくくする。特定しやすくするには機能を分割する、単体で機能テストを行いやすくする等を頑張りますが、どうあがいでもバグは起こると思うのでデバッグしやすいモードなんかを入れたりします。

4.作業を楽に
 例えば単体テストのコードをいっぱいかけばバグ耐性は高まるけど、単体テストのコードを書く時間で普通にデバッグした方が楽だったり、殆ど起こらないヒューマンエラーを無くすためのコードは書かないなどコードの品質を問題無いレベルで犠牲にしていく。誤差みたいな高速化のためのコードは書かない、例外処理はどうせ強制終了すればいいから書かない、定数データは直接打ち込まずに専用エディタやら表計算ソフトやらで管理等、色々楽していきます。

色々大変やで(´・@・)
プロフィール

(´・@・)

Author:(´・@・)
ゲームの製作日誌です
 コメントや拍手コメントは返したり返さなかったり

メール:mr.dagonn★gmail.com
★を@に変えて下さい

twitter(更新情報をつぶやくbot)
アカウント

●公開しているゲーム
Vector作者ページ

●アンケート
FBSアンケート

●製作中のゲームライブラリ
SDXフレームワーク

●自由ソフトウェア財団
[FSF Associate Member]

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
リンク