A3サイズの升目帖(旧)

ゲーム制作やプログラミングに関する雑記

【祝】サイト移転しました

ホームページ作ったぞ

このたび、ホームページを制作してそちらに移転することにした。

リンクは以下。

A3サイズの升目帖

移転の理由はあちらにも書いているが、一応ざっと羅列するとこんな感じ。

  • 失踪せずコンスタントに続けられそうだとわかった。
  • ゲームが完成した際の配布場所が欲しかった。
  • モチベーション上げたかった。

ホームページは自力で制作したので、UIとかレスポンシブ対応とか多分まだガバガバだが、とりあえず動くものはできたので公開に踏み切った。

決してはてなブログが悪いわけではないが、やっぱりクリエイターの端くれとして自分のホームページ持ちたいよね、ということで、思い立ったが吉日、ここ2週間ほどかけて制作していたわけだ。


今後どうするの?

今後は、ゲーム制作の記録はすべて自分のホームページのほうにアップしていく予定。

なお、はてなブログのほうは旧サイトとして残しておく。
記念という意味もあるが、ひょっとしたらどっかからリンクを貼られている可能性も否定できないので・・・


はや半年

ゲーム制作の記録をつけ始めてから、早いもので半年が経とうとしている。

はてなブログにはお世話になった。

ゲームも灰色のウインドウを表示した最初の頃に比べて随分と形になったもんだなあ。

今後もぼちぼちやっていくのでどうぞよろしく。

ありがとう。

ではまた。



はてなブログは動画の管理が難しいなあ

フィルムフレームと再生マークの画像


早いもんで、はてなブログでゲーム制作の過程を公開し始めてからそろそろ半年になる。

特別不満はないのだけれど、ただ1点、動画ファイルの管理が結構難儀だなあと個人的に感じ始めているところ。

mp4がアップできない…

はてなブログにアップできるファイルの種類は jpeg png gif なので、mp4 などの動画ファイルは取り扱いできない。
したがって、はてなのサービス内で完結する形で動画をアップしようとするとアニメーションgif一択になってしまう。

でもアニメーションgifは重い…

言うまでもなく、アニメーションgifはほんの数秒でも軽くウンMBいくクソ重奴なので、まずそれだけでも大いに問題だ。

そこに加えて、はてなブログには「1ファイルのサイズは10MB以下」という制限があるため、動画時間がちょっと長めになっただけで即アウトとなる。

なので、進捗動画を録画する際は、録画時間に細心の注意を払わなきゃならない。
それでもgifに変換すれば大抵は上限を超えてしまうので、長さを削り、画質を落とし、フレームレートを下げ… やっとこさアップロードに漕ぎつけるわけだ。

表現できることの幅が狭まって正直しんどい。

mp4gif の変換に手間がかかるのも割と無視できない問題点。

動画サイトを介するのもなんか違う

かといって、高々10数秒そこらの味も素っ気もない動画をいくつもニコ動とかにぶちまけて…もといアップしてリンクを貼るのも違う気がする。

ああいう動画投稿サイトには、ある程度まとまった、単独でも意味を成すコンテンツをアップしたいんだよなあ。

Dropboxからリンク、という手もあるけれど

Dropboxに置いて共有リンクを作る方法もあるが、個人的なストレージ内にむやみに変更できないディレクトリを設けるのはなんだかモヤモヤする。

動画を貼るためだけにサービスをまたぐのも、いびつ。

第一、大事な記録やデータが散逸している感じがして、なんか嫌だ。少なからぬ抵抗感がある。

結論:うまい方法がないです

…と、いうようなことに最近頭を悩ませているっていう話でした。

大抵のはてなブロガーにとってはあまり問題にならないポイントなのだろうけれど、ゲーム制作というジャンルゆえ、短めの動画を公開することが多いのでちょっと困っている。

どーしたもんかねえ…?

参考文献



ステータスバーのUIを考え中

ステータスバーのUIデザインを考えている絵


先日 立ち絵に取り掛かろうとしたときに、ステータスバーのデザインをまだ考えていなかったことを思い出したので、今日はそっちのアイデア出しをやっていた。

UIはやっぱりムズいな。デザイン系の学問はこれっぽっちも修めてないので、勘所もノウハウもまったく持ち合わせていない。

これまでやったゲームで見てきたUIを色々思い出しながら、あーでもないこーでもない…と試行錯誤していた。

とりあえず、ひと段落付いたところでプロトタイプ2号を作ってみたが、まあ個人的には及第点かなあと思えるものは何とか完成したので良かった。

ただ、前にも書いたように、表示できるパラメータがまだプレイヤーのライフくらいしかないので、ステータスバーの件はここでいったん置いておく。今後パラメータが充実してきたら再開することにしよう。


明日からはメッセージボックスに表示するキャラクターの立ち絵を描いていかなきゃいけない。

筆者の画力やタッチのほどは、前回アップした動画でなんとなくわかって頂けると思う。

a3masume.hatenablog.com

さーて週末、頑張るぞい。



背景のブラッシュアップとかをしていた

ゲーム画面

ここまでに書き散らしてきた酷いソースコードの整理を引き続きやっている最中。

そのついでに、ほぼ仮置き状態だった背景などのブラッシュアップをやっていた。

若干だけど描き込みが濃くなってると思う。

MP切れでこれ以上は作りこめなかったので、続きはまた後日。


しかしあれだなあ。ソースコードの整理くらいパパっと終わるかと思ったけど、案外時間食うもんだね。

次はメッセージボックスに表示するキャラクターの立ち絵を描いていかなきゃいけない。
やること盛りだくさんだぞ。


あ、そういえば、ステータスバーのデザイン改善もやってなかったわ。ひえ~



ステータスバー(仮)を実装した

ゲーム画面

プレイヤーの状態を表示するステータスバーを実装した。

表示できる情報は今のところライフしかなくてちょっと寂しい。ほんとにプロトタイプって感じだなあ。

まあここから改善を重ねていこう。


ステータスバー全体を囲むボックスを表示するかどうかが一番悩ましいところ。

ボックスが無いとなると、背景とかに紛れて見づらくならないよう、数字やアイコンに縁取りが必要になる。
しかし、今作は濃い縁取りを原則として付けないことをデザインの柱のひとつにしているので、非常に悩ましい。
でもボックスを表示すると、画面が窮屈に感じるしなあ…


まあ、デザインのことは、この休みにでもじっくり考えよう。

とりあえず動くものはできたので良かった良かった。



面倒なイベントの実装が終わった

ゲーム画面

プロローグの最も面倒くさいイベントのひとつがようやく終わったので、次からステータス表示などの実装していて楽しい部品に移ることができる。

あ~ 久しぶりに気乗りするのが来ましたね。

趣味のゲーム制作とはいえ、全部が全部やってて楽しいわけじゃないんだよなあ。

やっぱり、労力に対して出来上がるものが地味なことは、どうしてもスピードもモチベーションも落ちがちなんだ。
対策とかはあんまりないから、結局は腰を据えてえいやでやっちゃうしかないんだけどね…

そういう時にブログや動画へのレスポンスは本当に強い後押しになってくれる。ありがたいなあ。


さて、進捗に遅れが出てるから、ぼちぼち追いついていきましょ。



【D言語】クラスのインスタンスをスタック上に構築する

D言語のロゴマーク


サイズの小さいクラスを関数内でサクッと使い捨てしたいことが稀にある。

そういうインスタンスは、ヒープ上ではなくスタック上に確保したくなるのが人情というもの。

で、D言語ではそれができるのだが、個人的に「あれ?やり方とか色々どうだっけ?」となりがちなので備忘録としてメモ。

dmd 2.098.0 で動作確認。


結論

例えば Color というクラスがあったとして、以下の一文でインスタンスをスタック上に構築できる。

scope c = new Color();

scope で変数が修飾されているのがポイントだ。

変数定義を単に auto c とか Color c とかにしてしまうと、ヒープ上に確保されGCの管理下に入る。


その他補足

補足1

クラスのコンストラクタとデストラクタが @nogc なら、new しているにもかかわらず関数を @nogc で修飾できるらしい。すごい。

void func() @nogc // <- 関数を @nogc にできる!
{
    scope c = new Color(); // <- "new" してるのに! やったね!
}

当然、デストラクタはスコープを抜ける際に 即時 呼び出される。

補足2

スタックへの参照なので、外部に漏れるとマズい。

しかし、関数が @safe で修飾されていれば、参照を逃がそうとするコードはすべてコンパイルエラーになるので安心だ。

Color g_Color;

Color func() @nogc @safe // <- @safeコード下なので…
{
    scope c = new Color();

    // ↓こいつらはコンパイルがそもそも通りません。助かったぜ。
    version (none)
    {
        g_Color = c;

        return c;
    }
}


未検証のこと

@nogc 関数内で、でかいインスタンスをスタックに作ろうとするとどうなるんかね?

C#stackalloc みたいに StackOverflow 的なエラーになるなら、閾値はどんなもんなんだろう?

プリミティブ型のメンバを2,3持つ程度のクラスなら、まあまず大丈夫だろうから、個人的には問題にはならなさそうではあるが…

こんど時間に余裕があったら調べてみよう。

-preview=in の参照渡し境界サイズみたいに、環境依存とかだったら怖いからね…