24BのMPです。今回は僕が制作した謎解きゲーム「Grids」についてのヒント/解説記事です。
※内容的にプレイ体験を大きく損なう可能性が高いです。未プレイの方は先にプレイすることを強くお勧めします。

#web謎 #謎解き
「Grids」を公開しました！
試行錯誤を繰り返し条件をクリアしましょう

スマホ・PCのブラウザから無料で遊べます
想定プレイ時間 45分程度

▼プレイはこちらからhttps://t.co/6XmMl92HnF pic.twitter.com/2VdThQqcSX

— MP / ゲーム制作・DTM (@MP_cornpotage) September 26, 2026

▶プレイはこちらから

ヒント・解説

 1   2   3   4
 5   6   7   8
 9  10  11  12
13  14  15  ◇

◇ A
 B C

◇ B
 C A

◇ C
 A B

A + B = x
B + C = y
C + A = z

おわりに・宣伝

ここまで読んでいただきありがとうございました！
他にも謎解き、パズル系ゲームをよく作っています。全て無料で遊べるのでチェックしてみてください！

▼最近のおすすめはこちらです

#謎解き #web謎
「Planets」を公開しました！
試行錯誤を繰り返し条件をクリアしましょう

ある作品のリスペクト作品です

スマホ・PCのブラウザから無料で遊べます
想定プレイ時間 5~30分

▼プレイはこちらからhttps://t.co/lqTMdD8tzC pic.twitter.com/KqKXUHwRiH

— MP / ゲーム制作・DTM (@MP_cornpotage) July 18, 2026

#スーパーゲ制デー #謎解き
【数字当て×条件推測】
Understandライクな数字当てゲーム「NUMQUETE」を公開しました！

数字から条件を、条件から数字を推測し
試行錯誤して問題を解き明かそう

スマホ・PCのブラウザから無料で遊べます
想定時間60分~

▼プレイはこちらからhttps://t.co/zsrf6v9W7x pic.twitter.com/bKpj1fLdhz

— MP / ゲーム制作・DTM (@MP_cornpotage) July 10, 2026

競技プログラミング(AtCoder)をしていると、水レートあたりから顔を出し始めて、青になってくるとみんな知ってる、そんなアルゴリズム、畳み込み。僕もようやくこれに手を付けて、少しばかり勉強して、自分のライブラリに入れました。

畳み込み自体は数年前から知っていたのですが、複素数やら、整数環やらと出てくるとかなり構えてしまい、また読み進めると何をやっているのかよくわからなくなって、幾度も理解を諦めていました。今回の記事では、よくある他の記事とは順序を変えて、僕が理解した順序で説明を書いてみます。複雑な数学的背景は可能な限り飛ばしますが、どうしても数式を使うことは避けられないので、その点は頑張ってください。また、具体的なコードの実装の説明も行いません。あくまでも理論的な部分を理解する土台を作るための記事です。

またtatyamさんが、前にも畳み込みに使われるアルゴリズムであるFFTの解説を書いて下さっています。この記事よりも正確になっているので、数式が全く怖くない、FFTの仕組みをしっかり理解したい、という方はこちらを見た方がいいかもしれません。

【競プロer向け】FFT を習得しよう！

こんにちは、20B の @tatyam [https://trap.jp/author/tatyam] です。この記事は、traP夏のブログリレー[/tag/summer-blog-relay] 33日目の記事です。 高速フーリエ変換 といえば、競技プログラミングで数列の畳み込みなどに使われるテクニックですね。今日は高速フーリエ変換と高速フーリエ変換を利用した畳み込みを習得していきましょう。 ポエム一般的なフーリエ変換の 定義 / 説明 と異なる部分があるかもしれませんが、競プロであればこれで十分だと思います。AtCoder では AC Library[https://atcod…

東京科学大学デジタル創作同好会traPtatyam

畳み込みとは

定義

原義的な畳み込み、特に離散的な方の畳み込みは、次のようにして定義されます。

$$(f\ast g)(m)=\sum _{n}f(n)g(m-n)$$

言葉で言うと、二つの関数の引数の和が一定になるようにして足し合わせたものです。ここで出てきた関数 $f$ や $g$ は、この記事では数列と解釈して差し支えないでしょう。そこで、この畳み込みを二つの数列$A$と$B$に対して定義して、その結果を$C$とします。すると、次のように書くことができます。

$$C_n=\sum _{m=0}^n{A}_m{B}_{n-m}$$

競技プログラミングで出てくる畳み込みは、この式で計算される $C_n$ を、定義できる全ての$n$について求める計算を指します。

計算量

この畳み込みを計算することを考えます。各$n$について$n$個の総和を計算することになるので、時間計算量は$O(N^2)$になります。これでは遅いので、もう少し早くしたいところです。線形時間とは言いませんが、$O(N\log N)$程度になってくれると嬉しい。

そしてこの計算量は実現可能で、これを実現するのが 高速フーリエ変換　(FFT) と呼ばれるアルゴリズムです。ここからは、畳み込みがどう高速化されているのか、FFTは何に使われるのかをゆっくりと理解していきましょう。

数列から多項式へ

畳み込みを理解する前に、少し数列の表現方法について説明します。

係数による表現

フーリエ変換を用いた畳み込みの計算では、数列を多項式として解釈します。つまり、長さ$N$の数列$A=(a_0,a_1,...,a_{n-1})$があるとき、これを多項式$f_A(x)=a_0+a_{1}x+a_2{x}^2+...+a_{n-1}{x}^{n-1}$で表される$N-1$次の多項式として見ます。こうすると、畳み込みを多項式の積として解釈できます。

例として長さが3と2の数列$A=(a_0,a_1,a_2)$と$B=(b_0,b_1)$を用意し、それぞれに対応する多項式を$f_A(x)$、$f_B(x)$とします。この積$f_C(x)$を計算してみましょう。

$$\begin{gathered} f_C(x)=f_A(x)\times f_B(x)=(a_0+a_{1}x+a_2{x}^2)(b_0+b_{1}x) \\ =(a_0{b}_0)+(a_0{b}_1+a_1{b}_0)x+(a_1{b}_1+a_2{b}_0)x^2+(a_2{b}_1)x^3 \end{gathered}$$

各項の係数についている添え字に注目します。すると、どの項でも$A$の添え字と$B$の添え字の和がその項の$x$の次数に一致することがわかります(2乗の項の$a_0{b}_2$は$b_2=0$と解釈する影響で消えてしまっています)。特に、$x$の$n$乗の項の係数を$c_n$として$C=(c_0,c_1,c_2,c_3)$とすると、$C$は$A$と$B$の畳み込みになっています。

値による表現

前項では数列から多項式を作ることができることがわかりました。今度は、一つの多項式を数列で表現することを考えます。各行の係数を取ってきた数列は、元の多項式をよく表現してくれます。ところで、多項式を表現する、一つに指定する方法はそれだけでしょうか？

直線は1次の多項式を使って表すことができます。そして、その直線を特定するには、その直線が通る2点の情報があれば十分です。2次関数なら2次の多項式を用いて、通過する3点があればよく、3次関数では3次の多項式で4つの通過点があると特定できます。

一般に、$n$次の多項式$f(x)=a_0+a_{1}x+...+a_n{x}^n$の各係数は、グラフ$y=f(x)$の通過する点が$n+1$個あれば求めることができます。言い換えると$n+1$個(以上)の点の情報$(f(r_0),f(r_1),...,f(r_n))$があれば、一つの多項式を表現できるということです。

尚、各多項式がどの数列によるものなのかをわかりやすくするため、数列$A$から作られた多項式$f_A$を単に$A(x)$、その出力値から得られる数列を$\hat{A}=({\hat{a}}_0,{\hat{a}}_1,...,{\hat{a}}_{n-1})$とします。
(数列$A$と混同しないよう気を付けてください)。

多項式の掛け算

さて、数列から作られる多項式の表現として

1. 係数からなる数列
2. 多項式の出力値からなる数列

の2種類を得ることができました。今回やりたいことである畳み込みは多項式の積と対応するので、多項式の積を取ったときにこれらの数列がどう変わるのかを調べてみます。これまで通り、数列$A$と$B$からなる多項式$A(x)$と$B(x)$を考えます。

まず、係数からなる数列は先述の通り二つの数列の畳み込みとなります。問題は出力値の方です。こちらは単なる値の積となってくれます。つまり、$C(x)$について、

$$(C(r_0),C(r_1),...,C(r_{n-1}))=(A(r_0)B(r_0),A(r_1)B(r_1),...,A(r_{n-1})B(r_{n-1}))$$

です。$C(x)=A(x)B(x)$で定義したので当然ですが、こちらはかなり簡単になりました。$\hat{A}$と$\hat{B}$さえわかれば$\hat{C}$の値が即座にわかります。

問題の変換

$C(r_i)=A(r_i)B(r_i)$と、積の計算が随分と楽になりました。しかし、これで終わりではありません。ここまで言及していなかった、重要な事項がいくつかあります。

まずは$A(r_i)$を実際に計算するときの計算量です。$A(x)$は$N-1$次の多項式ですから、この値を愚直に計算するには$O(N)$の時間計算量が必要になります。これを必要なだけ求めると、$\hat{A}$の計算には最終的に$O(N^2)$時間必要となり、高速化は実現されていません。
第二に、$C$から$\hat{C}$への変換に使う引数$r_i$の決定です。どのような値を使えばよいでしょうか？
第三に、$\hat{C}$から$C$への変換です。ここまで、$C$から$\hat{C}$の変換方法は説明しましたが、その逆はまだです。

次の章からは、数列の畳み込みを多項式の積と解釈したことによって出たこの課題を解決する手段を説明します。少しフライングすると、$r_i$を適切に決めることで、これらの問題を一気に解決します。

高速フーリエ変換

入力 $r_i$ の決定

$N$要素の数列$A$から$\hat{A}$を計算することで、畳み込みの計算が1歩進むことがわかりました。ここからはその計算方法を実際に追っていきます。

まずは$A(x)$への入力とする$r_i$の決定です。$r_i$はどんな値がいいでしょうか？まず、異なる$N$個の点が欲しいので、$r_i$も互いに異なっていてほしいですね。他にどんな条件があるといいでしょうか。離散フーリエ変換で用いられる$r_i$は、追加で次の性質を持っています。

• $r_i$は次の性質を満たす数$\omega$の$i$乗
  • ${\omega }^N=1$
  • ${\omega }^{(N/2)}=-1$ ($N$が偶数のとき)

アルゴリズムの解説に集中したいので、この記事では具体的な$\omega$の値は説明しません。ほとんどのFFTの解説記事には書いてあるので、気になる人は調べに行ってみましょう。

$A(r_i)$の計算

では、このような値を使って計算したとき、どんなことが起こるでしょうか。
ここでは、$N$を偶数として計算をしてみます。(もし$N$が偶数じゃないなら、数列に0の項を一つ付け足せば良いです)
まず、$A(x)$は${\sum }_{j=0}^{N-1}{a}_j{x}^j$ ですから、

$${\hat{a}}_i=\sum _{j=0}^{N-1}{a}_j{r}_i^j=\sum _{j=0}^{N-1}{a}_j{\omega }^{ij}$$

と書けます。$N$が偶数なので、この総和について$j$が偶数の項と奇数の項とで分けてみます。

$${\hat{a}}_i=\sum _{j=0}^{N-1}{a}_j{\omega }^{ij}=\sum _{j=0}^{N/2-1}{a}_{2j}{\omega }^{2ij}+\sum _{j=0}^{N/2-1}{a}_{2j+1}{\omega }^{i(2j+1)}$$

ここの第二項について、${\omega }^i$をくくって

$${\hat{a}}_i=\sum _{j=0}^{N/2-1}{a}_{2j}{\omega }^{2ij}+{\omega }^i\sum _{j=0}^{N/2-1}{a}_{2j+1}{\omega }^{2ij}$$

となります。では同じ計算を、${\hat{a}}_{i+N/2}$についても行ってみると、なんやかんやあって ($i$を$i+N/2$に変えるだけです)

$${\hat{a}}_{i+N/2}=\sum _{j=0}^{N/2-1}{a}_{2j}{\omega }^{2(i+N/2)j}+{\omega }^{i+N/2}\sum _{j=0}^{N/2-1}{a}_{2j+1}{\omega }^{2(i+N/2)j}$$

となります。$\omega$周りは、$\omega$の持つ性質、${\omega }^N=1$、${\omega }^{(N/2)}=-1$を使ってさらに整理できて

$${\hat{a}}_{i+N/2}=\sum _{j=0}^{N/2-1}{a}_{2j}{\omega }^{2ij}-{\omega }^i\sum _{j=0}^{N/2-1}{a}_{2j+1}{\omega }^{2ij}$$

となります。

この二つを見比べてみると、なんと足し引きが違うだけでほとんど同じであることがわかります。試しに

$$\begin{gathered} {\hat{e}}_i=\sum _{j=0}^{N/2-1}{a}_{2j}{\omega }^{2ij} \\ {\hat{o}}_i=\sum _{j=0}^{N/2-1}{a}_{2j+1}{\omega }^{2ij} \end{gathered}$$

なんて書けば、

$$\begin{gathered} {\hat{a}}_i={\hat{e}}_i+{\omega }^i{\hat{o}}_i \\ {\hat{a}}_{i+N/2}={\hat{e}}_i-{\omega }^i{\hat{o}}_i \end{gathered}$$

となります。つまり、実質的に計算が必要な${\hat{a}}_i$が半分になっています。
そして、${\hat{e}}_i$や${\hat{o}}_i$の式を見ると、これもまた同じ出力値の計算になっていることがわかります。

再帰計算

少し詳しく書きます。$E=(e_0,e_1,...,e_{N/2})=(a_0,a_2,a_4,...,a_{n-1})$ として、$\hat{E}$を考えます。$E$は$A$のちょうど半分から作っているので、その要素数が$N/2$個であることに注意すると、計算に使う$r_i$として$({\omega }^2{)}^i$を使うことができます。実際、

• $({\omega }^2{)}^{N/2}={\omega }^N=1$
• $({\omega }^2{)}^{(N/2)/2}={\omega }^{N/2}=-1$

となって、$A$に対する計算で使った$\omega$と同様の性質を満たします。

では計算してみましょう。$E(r_i)$を求めます。

$$\begin{gathered} E(r_i)=\sum _{j=0}^{N/2-1}{e}_j{r}_i^j=\sum _{j=0}^{N/2-1}{a}_{2j}({\omega }^2{)}^{ij} \\ ={\hat{e}}_i \end{gathered}$$

となって、確かに${\hat{e}}_i$が$E(r_i)$となっています。同様に、${\hat{o}}_i=O(r_i)$です。

ここまでをまとめると、$\hat{A}$($N$要素)を求める問題を、$\hat{E}$と$\hat{O}$ ($N/2$要素)を求める問題に分割することができました。もし$E$や$O$も偶数個からなる場合、これをさらに分割できます。もし$N$が2冪であれば、この分割を繰り返すことができて、高速に計算できそうです。特に、数列の末尾に0をつけ足しても結果は変わらないので、$N$はいつでも2冪にすることができます。ﾔｯﾀｰ

こんな風に偶奇で分割して計算していくのをバタフライ演算とか呼んだりするらしいです。僕にはどこが蝶なのかわからなかった...

これによる計算量を見積もります。$A$を$E$と$O$に分割して同じ問題を解いた後、$\hat{A}$はその結果$\hat{E}$と$\hat{O}$から各要素を定数時間で計算できる(${\hat{a}}_i={\hat{e}}_i+{\omega }^i{\hat{o}}_i,{\hat{a}}_{i+N/2}={\hat{e}}_i-{\omega }^i{\hat{o}}_i$)ので、後半の計算は$O(N)$となります。そして、数列の分割は$O(\log N)$段階まで出来るので、$A$から$\hat{A}$の計算は全体で$O(N\log N)$時間で計算できました。

尚、計算を二つに分け、分割しながら計算したこのアルゴリズムを高速フーリエ変換 (FFT) と呼びます。

逆変換

ここで目的を再確認しましょう。当初の目的は数列$A$と$B$の畳み込み$C$を計算することです。そのため、$A$や$B$で作られる多項式$A(x)$と$B(x)$の積を考えました。ここで、$A(x)$や$B(x)$にいくつかの値を代入して得られる数列$\hat{A}$と$\hat{B}$を使うと、$C(x)$を表現している$\hat{C}$を簡単に求めることができます。

ここまで、そのうち$A$、もとい$A(x)$から$\hat{A}$を高速に計算する方法を解説しました。あとは$\hat{C}$から$C(x)$を復元し、$C$を得ることができれば目的達成です。

結論から書くと、この逆変換は

$$a_i=\frac{1}{N}\sum _{j=0}^{N-1}{\hat{a}}_j{r}_i^{-j}=\frac{1}{N}\sum _{j=0}^{N-1}{\hat{a}}_j{\omega }^{-ij}$$

です。
これが正しいことを実際に確かめます。まずは左辺に${\hat{a}}_j$の計算式を代入します。

$$\frac{1}{N}\sum _{j=0}^{N-1}\left(\sum _{k=0}^{N-1}{a}_k{\omega }^{jk}\right){\omega }^{-ij}$$

和の順序を入れ替えて

$$\frac{1}{N}\sum _{k=0}^{N-1}{a}_k\sum _{j=0}^{N-1}{\omega }^{j(k-i)}$$

ここで出てきた${\sum }_{j=0}^{N-1}{\omega }^{j(k-i)}$をさらに計算します。
$i=k$のとき、${\omega }^{j(k-i)}=1$なので、${\sum }_{j=0}^{N-1}{\omega }^{j(k-i)}=N$です。

$i\ne k$なら、${\sum }_{j=0}^{N-1}{\omega }^{j(k-i)}$は初項$1$、公比${\omega }^{k-i}$の等比数列の和になります。(${\omega }^{k-i}$は$1$にならないという性質を持ちます。)

そのため、等比数列の和の公式から

$$\sum _{j=0}^{N-1}{\omega }^{j(k-i)}=\frac{({\omega }^{k-i}{)}^N-1}{{\omega }^{k-i}-1}=\frac{({\omega }^N{)}^{k-i}-1}{{\omega }^{k-i}-1}=\frac{1^{k-i}-1}{{\omega }^{k-i}-1}=0$$

です。以上まとめると、

$$\frac{1}{N}\sum _{k=0}^{N-1}{a}_k\sum _{j=0}^{N-1}{\omega }^{j(k-i)}$$

は$i=k$の場合だけが残って、

$$\frac{1}{N}\sum _{k=0}^{N-1}{a}_k\sum _{j=0}^{N-1}{\omega }^{j(k-i)}=\frac{1}{N}\times N{a}_i=a_i$$

となって、確かに逆変換が成立していることがわかりました。

順変換との差異

$a_i$と${\hat{a}}_i$の相互変換を求めることができました。
2つの式を比べてみます。

$$\begin{gathered} {\hat{a}}_i=\sum _{j=0}^{N-1}{a}_j{\omega }^{ij} \\ {a}_i=\frac{1}{N}\sum _{j=0}^{N-1}{\hat{a}}_j{\omega }^{-ij} \end{gathered}$$

まず逆変換の方は、和の後に$N$で割っています。もう一点、$\omega$が${\omega }^{-1}$に置き換わっていますね。
それ以外は順変換と逆変換は何も変わっていません。はい、何も変わっていません。つまり、順変換のアルゴリズムを逆変換にも使うことができ、順変換、逆変換ともに高速に計算出来るのです。

まとめ

さて、ここまでをまとめます。

二つの数列$A=(a_0,a_1,...,a_{N-1})$と$B=(b_0,b_1,...,b_{M-1})$について、その畳み込み$C=(c_0,c_1,...,c_{N+M-1})$を求めることを考えます。

まず、整数$L$を、$N+M-1$以上となる2の累乗で求めて、$A$と$B$の長さを$L$にします。(新しい部分は0で埋める)
次に$A$から

$${\hat{a}}_i=\sum _{j=0}^{L-1}{a}_j{\omega }^{ij}$$

で得られる$\hat{A}=({\hat{a}}_0,{\hat{a}}_1,...,{\hat{a}}_{L-1})$を高速フーリエ変換により計算し、同様に$\hat{B}$も求めます。これら二つから

$${\hat{c}}_i={\hat{a}}_i{\hat{b}}_i$$

で$\hat{C}=({\hat{c}}_0,{\hat{c}}_1,...,{\hat{c}}_{L-1})$が得られます。
これに対して、

$$c_i=\frac{1}{N}\sum _{j=0}^{L-1}{\hat{c}}_j{\omega }^{-ij}$$

で得られる$C$を再び高速フーリエ変換により計算することで、最初の目的を達成することができました。

以上のアルゴリズムが高速フーリエ変換により畳み込みを高速に計算する方法です。

最後に

(説明のまとめに「まとめに」を使ってしまったので「最後に」です)

お疲れさまでした！！！

🎉これであなたも畳み込み・高速フーリエ変換を理解できました！🎉

と言ってみたものの、実はまだ一つ巨大な問題が2つほど残っています。

まず一つ目は、今回の記事で出てきた謎の数$\omega$の正体です。個人的に、この$\omega$がFFTの理解における一番の壁だと思っています。水や青コーダーでこの類の分割統治につまずく人はほとんどいませんからね。今回、$\omega$は単なる都合のいい数としてしか出ていません。しかし、その性質だけを抑えておくことで、難しい部分をスキップして説明をすることができています。

二つ目は、この畳み込み、およびFFTを処理する実装です。この記事では理論的な部分の(それも一部の)説明にとどめています。今回説明しなかったこれら二つはまた別の記事としていずれ出す、かもしれません。しかし、ここまで理解出来たら、$\omega$の理解も、実装の理解も容易いはずです。

では、またの機会に。

参考

【競プロer向け】FFT を習得しよう！

こんにちは、20B の @tatyam [https://trap.jp/author/tatyam] です。この記事は、traP夏のブログリレー[/tag/summer-blog-relay] 33日目の記事です。 高速フーリエ変換 といえば、競技プログラミングで数列の畳み込みなどに使われるテクニックですね。今日は高速フーリエ変換と高速フーリエ変換を利用した畳み込みを習得していきましょう。 ポエム一般的なフーリエ変換の 定義 / 説明 と異なる部分があるかもしれませんが、競プロであればこれで十分だと思います。AtCoder では AC Library[https://atcod…

東京科学大学デジタル創作同好会traPtatyam

この記事は夏のブログリレー36日目の記事です。

目次

• PixelComposerについて
  • サクッと作れる表現
  • PixelComposerを始めるにあたって
  • 前半のまとめ
• PixelComposerで作れる「ボーンアニメーション」紹介のコーナー)
  • PixelComposerでの「ボーンアニメーション」
  • ルコンポのここが強い！ここが弱い！
  • アニメーションの作り方

PixelComposerについて

前半部分は「PixelComposerとはそもそも何か？」「どんなことができるのか？」「始めてみたいけど何すればいいのかようわからん」という人に向けた内容です！
執筆はMimiが担当します。よろしくお願いします。
(ちなみに以前にもPixelComposerブログを出しているので、是非こちらもご覧ください)

公式の説明

Pixel Composer is a node based VFX compositor for pixel art. Using nodes to pass data and apply different effects. It also support keyframe-based animation with timeline.

PixelComposerはピクセルアートのためのノードベースのVFXコンポジター
と公式ドキュメントで言っています。

blenderのGeometryノードやUnityのShaderGraphを触ったことがある人ならわかると思いますが、

処理を連鎖的に組み合わせて複雑な処理を実現する が根本的なアイディアです。

例えば

例えば上の画像は

1. 円を一つ用意して大きくする
2. 更に内側にもう一つ円を用意し、1の円より少しタイミングを遅らせて大きくする
3. 1の円を2の円で削る
4. ↑でできた画像を複製する(配列として持つ)
5. 回転や位置、色がランダムになるようにする(インデックスごとにバラバラな値を持つ)
6. 一つ一つにアウトラインをつける
7. 複製したものを少しづつタイミングをずらしながら一気に生成する

という風に、処理が連鎖されてできています！

今回はそんなPixelComposerについて

1. 基本的なこと
2. PixelComposerにおけるボーンアニメーション

をまとめた記事となっています！

サクッと作れる表現

爆発・衝撃波

衝撃波も兼ねた簡単な爆発表現なら
①円を膨らませる
②その内側に少し遅れて円を膨らませる
で作ることが出来ます。前後にパーティクルを置いてあげるとちょっと見栄えが良くなるかも

水・液体表現

Displacementノードという歪み処理ができるノードを使った屈折表現や、Blur+Thresholdで液体っぽい表現を作ることが出来ます。

炎の模様表現

ノイズをつかってゆらゆら揺れる表現を作ることが出来ます。それを上にスクロールさせることで炎が上がっていくような表現が作れます。

3D的な表現

なんとPixelComposer内で3Dモデルを読み込んだり生成し、カメラで写したものを画像として扱ったりできます。スゴイ！

このように、色んなノードを組み合わせる事で簡単に色々な表現ができるのがPixelComposer(というかコンポジットツール全般)の強みです。

PixelComposerを始めるにあたって

PixelComposer興味あるよ！という方に向けて、いくつかのノード群の特徴をまとめます！

Generate(生成)

万物の祖です！
Generateという名前の通り、生成ができます。
何が生成できるのかというと

• 図形
  • 
  • テンプレとしてこんな感じのが用意されてる。パラメータとかもいじれる(例えばドーナツなら内側の円と外側の円の半径など)ので、嬉しい
• ノイズ
  • 
  • 色んなノイズがいっぱい。もちろんパラメータつきで。
• 模様
  • 
  • 模様もいっぱい。
• その他にも
  • 
  • UVMapやグラデーション、なんとパーティクルもある。

など、万物を生成できます。
(一応Luaでスクリプトも書けるんですが、)数式的な処理が面倒なぶんこういった素材が充実してるのがアツい所です。

Transform(変形)

モーショングラフィックスっぽいことやるならコイツです。
Transformというノード群があるのになぜかTransformという単一のノードがあります。しかもこのノードは結構他のノードの機能を包含してる。

僕はこんな感じでいっぱいキーフレーム打って使うことが多いです。

Filter(加工)

画像全体への加工を扱えるノード群です。

• アウトライン
• ぼかし(Blur)
  • ブラーだけで15個ぐらいノードある
• ポストプロセス(Bloom、色収差、Vignette...)
• ゆがみ(Warp)
  • これもノードめっちゃある

など、本当に色々あります(本当に色々ある。)

個人的超便利Filterノードは

• Colorize(黒~白をグラデーションの色に置換したりできます。超便利)
  • 
• Threshold
  • 閾値処理。「明度がこの数値以上の部分だけ映す」「透明度がこの数値以上の部分だけ映す」ができる。BlurとかNoiseとかと合わせると大変アツい
  • 
• Posterize
  • 色を段階に無理やりn段階に分けることが出来る。
  • 特に解像度の高い(ちょっとAAがかかりすぎているもの)をドット調にするのにお勧め
  • 

です。特にColorizeはいつも使ってる。

大体この3種類のノードを使い、
Generateで生成→Transform・パラメータのアニメーションで動かす→Filterで加工
の一連の流れでそれっぽいものは出来上がって、嬉しい気持ちになります。

他にも、3D系のノードやシミュレーション系のノードなど様々なノードがあるので、手を動かしてみると良いかもしれません！

前半のまとめ

• PixelComposerはピクセルアート向けのノードベースで色々できるソフト
• 割と色々できる
• Generate→Transform・パラメータのアニメーション→Filter　でそれっぽいものが作れる

PixelComposerで作れる「ボーンアニメーション」紹介のコーナー

執筆担当代わりましてここからは飛ぶ人がお送りします！
私の担当分では、PixelComposer（以下、見出しとか以外ではルコンポと略します）の活用方法の一つとして「ボーンアニメーション」を作成する手法とかを解説します。
レイヤー分けされた1枚のイラストから

こんなのとか

こんなのが作れます！
画像の各レイヤーのパーツを回転させたり位置を変えたりするアニメーションを、パーツごとにボーンに対応させてそのボーンを動かすことでアニメーションが作れちゃいます！

しかも、上の二つのアニメーションに使用している特殊なノードは3つだけなので以外と使うハードルは低いかも！？

そんなルコンポでのボーンアニメーションの世界に、そろりそろりと参ります！

PixelComposerでの「ボーンアニメーション」

ボーンアニメーション（スケルタルアニメーション） とはざっくり言うと「骨格と関節となるボーンとジョイントを動かして作ったアニメーションに、表面の見た目を適用して動きを作るアニメーション」です！
　ルコンポでもそんなボーンアニメーションを行うためのノードシリーズである「Armature」シリーズがあります

たくさんある

ノードごとに役割は決まっており、「ボーンを作成する」「ボーンに動きをつける」「ボーンに画像を設定する」「ボーン情報を統合する」「ボーンに様々な情報を付加する」など様々なノードが存在します
全部紹介しているとブログがもう一本書けてしまうので、今回のこのコーナーでは

• Armature Create（ボーンを作成するノード）
• Armature Pose（ボーンに動きをつけるノード）
• Armature Bind（ボーン情報を統合するノード）

の3つのノードにフォーカスして最小限の構成でのボーンアニメーション作成について解説を行います

この3つのノードで作れちゃうんです

出力はボーンデータではなくあくまでスプライトシートやGifで、複雑なボーンアニメーションやメッシュ変形による3Dライクな表現は苦手ですが、かなり簡単に最低限のアニメーションを作成することができます！

ルコンポのここが強い！ここが弱い！

ボーンアニメーションとなると、Unityで直接作ったりSpineなど他のソフトによる制作したりする方が様々な利点があるように思えます。
実際、ゲーム内で動的にボーンを管理できたり、作ったアニメーション情報をjsonファイルでUnity等のゲームエンジンに直接インポートできたりと、UnityとかSpineの方が正直優秀な部分が多いです…

まぁあくまで「ルコンポでついでにこういうこともできるんだな」程度で考えると良いかもしれません

ルコンポのボーンアニメーションのここが強い！

• Asepriteファイルの連携に強い
  　ルコンポではAsepriteとの相性がめっちゃいいのが強いです！
  Asepriteファイルからレイヤー情報の一括分離する機能があるため、レイヤー分けが適切であればいちいちパーツごとに出力する必要がなくめっちゃ便利です！
  ↓
  
  layersのレイヤーに+が書いてあるボタンをワンクリックでできちゃいます、嬉しい～
  Asepriteで作ったデータをそのままアニメーション作成に持ち込めるのはめっちゃ嬉しいポイントです
  　レイヤー名がそのまま出力名になるためレイヤー名が適当だと面倒になることもありますが、なんとルコンポ側からも出力されるものの名前はいじれるので嬉しいですね
  　レイヤー分けしたpng画像を1枚1枚適用していくことも可能です、柔軟で嬉しいですね（【衝撃】やったことありますが、大変です【苦しさ】）

• ピクセルパーフェクトなアニメーションに強い
  　出力結果がUnityのPixelCameraのようにPixel単位での出力になるためドット絵の雰囲気を崩さずにアニメーションの作成ができます！
  
  アニメーションの1フレーム1フレームがピクセルパーフェクトで嬉しさ満天
  Unityなどでは実際の見た目を確認しながら作業をするのが地味に面倒なのでリアルタイムで描画結果を返してくれるのは結構ありがたいポイントですね

• 平面（xy座標）内での変形に強い
  　斜めの要素が入っていないトップダウンやサイドビューなど、アニメーションが平面のxy座標で完結するものに非常に強いです
  単純な組み合わせであればアニメーションで管理するパラメータが要素が少なく直感的なのでどの要素をいじればどういう動きになるかが想像しやすいです！
  
  　こんな感じで「これをいじると回転するんだな」などがわかりやすいです！
  　ルコンポでの立体アニメーションやメッシュ変形周りでの表現も工夫すればできますが、使用するノードや管理するパラメータが増えまくるので管理が大変になってしまう萎えぽよな面もあります

• Unityできなくても使える
  　これ実は結構嬉しいです
  　色んなメリットがあるから最終的にUnityを選ぶのがおすすめなんですけど、世の中にはどうしてもプログラムが絡むとアレルギーを発動する人間がいます、俺とか
  　そういうタイプの人がグラフィッカーである場合やプログラマ側がまだグラフィック方面の処理を作れない場合などでこのソフトは大いに活躍してくれます！

  • グラフィッカーだけで完結する
    ノーコードでGUI操作なので直感的にアニメーションを作れるのが偉いです
    ゲーム側があんまりできあがっていない段階でもじゃんじゃん作れるのでUnityから分離されているというのが短期開発であったりCodexなどにバリバリUnityプロジェクトを編集させる場合は嬉しい場面が多いです
  • 安い
    制作ソフトは「迷うな……全部買うか………」vs「全部買うと破産ですしねぇ……」問題に直面しがちです
    円安の今、Spineが学生目線では高い… ちょっとお高めの他のソフトもあるので、安く本実装の物が作れるのはありがたいです
  • アニメーション出力が再生やコンパイルを待たずにできる
    シェーダーっぽい表現やエフェクト周りに非常に強いのがルコンポなので、プレビューで一瞬で見た目の確認ができるのがマジでうれしいです
  • 他エフェクトと合わせた見た目をすぐ試せる
    単品でしか使わないようなシェーダー作成の手間を省けるのが短期開発だと開発リソースが限られているのでUnity以外でエフェクト合成などができるのはかなり偉い場面があります
    長期開発や準備段階でも実装イメージをプログラマと視覚的に共有できるのも偉いポイントですね
    
    「こういう感じの効果・計算を組み合わせてこうしたい！」が伝わりやすいです

ルコンポのボーンアニメーションのここが弱い！

• メッシュ変形やz軸方向の変形、画像切り替えに弱い
  　結構重めのデメリットです涙
  　できるっちゃできるんですけど、ノードの組み方やパラメータ調整などが結構大変になってしまいます
  　慣れたらいいんですけど慣れるまでは、ぽよじゃないですね

• サイズの大きな画像では計算処理が重く弱い
  　ルコンポはアニメーションを再生するとデフォルトでは全てのノードのアニメーションプレビューが再生されます
  　画像サイズが大きい状態で考え無しに全てのプレビューの再生を付けていると、ピクセルパーフェクトで計算してくれる都合上計算される量が跳ね上がり普通に重くなります
  　あくまで3桁前半くらいまでの画像サイズじゃないと重さのストレスで、ぽよじゃないですね

• Unityなどに直接ボーン情報がエクスポートできない
  　ゲーム開発だと一番重いデメリットですね
  　一応プロジェクトファイル全体をjsonファイルとしてエクスポートすること自体はできますが、どうやら直接は読み込めない？模様です（ルコンポがGameMaker製であることがUnityとの互換性に影響しているんですかね？詳しくないのでよく分からないです）
  　file→Exportからプロジェクトファイル全体のjsonファイル自体は作れるっぽいので、Unity側でなんやかんや変換したらもしかしたら読み込めるかも？まぁよく分からないので助けてマルグリート！

アニメーションの作り方

さて、使用するノードの紹介とやり方解説のコーナーです
このソフト、Ctrl+Zが不自然な戻り方をするうえにCtrl+Yを押しても元に戻らないです！まるで現実なので気をつけてください！ リアリティ溢れるソフトですね
あんまり日本語で解説してる記事がないのと独学なので、とんちんかんな方法でやってるかもですが許してください
まぁ我流ってかっこいいしな、漢我流もかっこいいしな

やり方はこんな感じ↓の流れです、一個一個解説していきます

やり方の手順

0. 動かしたいイラストを用意
1. ルコンポにイラストをインポート
2. ボーンの骨格作成
3. 各ノード接続
4. ボーンにイラストの各パーツを割り当て
5. 動きを作成
6. エクスポートして完成！

0.動かしたいイラストを用意

レイヤー分けを意識して描きましょう
ポイントとしては「関節」「骨格」を意識してレイヤー分けを行うと良いです
例えば人間の腕を動かしたい場合、「肩」「肘」「手首」が関節（ジョイント）に対応して「二の腕」「前腕」「手のひら」が骨格（ボーン）に対応します
その骨格（ボーン）を動かしたときに回転する関節（ジョイント）を一個のまとめたレイヤーにすると画像の適用がやりやすいです
例えば「肩+二の腕」「肘+前腕」「手首+手のひら」など

↑のイラストでは「足の根元の関節」と「足の上側」を一個のレイヤーにしてます

イラスト部分は気合で作ってください、熱血🔥

1.ルコンポにイラストをインポート

ルコンポにインポートするには、ノードを用いてイラストをインポートします

1-1.Aseperiteファイルをインポートする場合

操作するノード：ASE File In

1. 上のバーの「Graph→Add Node」もしくはShift+Aでノード追加ウィンドウを出す
2. 「ASE File In」を検索
3. インポートしたいAsepriteファイルを選ぶ
4. インポートしたらノードをクリックして画面右のインスペクター上で「layers」の欄の右端の「Generate layers」をクリック
   
   
   ↑の右端
   この時「Use Cell Dimension」は必ずFalseにすること！ これをしないと出力されたレイヤーがそのレイヤーの描画範囲にCropされるので、ボーンに適用するときに大変です、すごく
5. 全てのレイヤーが別々のノードとして出力される
   
6. 必要な場合はレイヤー名をパーツごとにわかりやすい名前にする

俺Boneのスペルずっと間違ってて面白いw

1-2.pngファイルをインポートする場合

Asepriteファイルを扱えるソフトを持っていないor宗教上の理由でpngしか扱えない人向けです

操作するノード：Image

1. 上のバーの「Graph→Add Node」もしくはShift+Aでノード追加ウィンドウを出す
2. 「Image」を検索
3. インポートしたいpngファイルを選ぶ
4. 気合のインポート作業、気合ンポート作業をする
5. 全てのレイヤーが別々のノードとして出力される
6. 必要な場合はレイヤー名をパーツごとにわかりやすい名前にする

pngでやる人向けの注意として、この後の作業の時に便利なので以下のことをやっておくといいです

• 全部のパーツを統合した1枚絵のpngもインポートしておく
• レイヤーが下の物からインポートしておき、画面上から下に向かってレイヤーが下の物→レイヤーが上の物の並びになるようにする

また、統合した1枚絵からCropしてパーツ分けするのは、ボーンへの適用の際に位置がめちゃめちゃになって不便なのでオススメしません （1敗）

2. ボーンの骨格作成

ボーンの作成です、初見だと分からない要素多めなので丁寧丁寧丁寧に描くと決めていたよ

2-1.ノードを出す

操作するノード：Armature Create

1. 上のバーの「Graph→Add Node」もしくはShift+Aでノード追加ウィンドウを出す
2. 「Armature Create」を検索

クリックして画面に出たらオッケーです

2-2.ボーンを作成する

操作するノード：Armature Create

1. プレビューに表示するため、AsepriteならASE File Inの、pngならレイヤー統合されたノードをダブルクリック
   これをやることでプレビューにレイヤー統合されたイラストを表示でき、ボーンを置く基準にできます（これをやらないと何もない画面にボーンを置くことになる）
2. Armature Createをクリック
   ダブルクリックするとプレビューが消えるので注意！
3. プレビュー画面を見て、Add Boneのうち「Add Control Bone」をクリックしてControl Boneを重心の位置に追加
   
   通常のBoneは骨格と関節なのですが、Control Boneはイメージで言うと「重心」の要素でControl Boneを親にもつ子ボーンはその重心の動きに合わせて制御できます（超重要）
   これの何が嬉しいかは実際のアニメーション制作でわかります！
   ジャンプだったり体が傾く動きだったり歩きのように微妙な重心の変化が起こるアニメーションでは、Control Boneを設定しないと自然な動きにするためにいちいち重心の移動に合わせてボーン一つ一つの位置を調整しないといけません
   しかし、Control BoneがあるとControl Boneの位置を重心の動きに合わせて上下させると、それに子ボーンが追従してくれます！
   親子関係にあるボーンは、デフォルトだと親のボーンが動くと子のボーンも追従して動きます！この動くか動かないかの追従関係は一応Armature Bindで変えられますが、親子関係自体の変更は後からできない（たぶん）ので注意！
   
   
   これのおかげで角度や位置の微調整だけでアニメーションが作れるようになります！
   このControl Boneから色んなボーンを生やすので中心（人物キャラクターなら腰くらい？）の位置に置いておくと良いです
4. Add BoneでControl Boneからドラックしてボーンを追加
   
   こんな感じControl Boneから生やしてください
   ボーンの位置や大きさは後からいじれます
5. Control Boneの開始点と関節の位置が一致していない場合、Detach Boneでボーンの開始点側の関節の位置をControl Boneから離す
   
   こいつをクリックして選んで
   
   離したいボーンの根元からドラックすると分離できます！
   これの何が嬉しいかというと、余計なボーンを追加せずに、最小限の数でボーンのジョイントの位置設定ができるので後々アニメーションさせるときに管理するボーンの数が減ります！
6. Move Selectionでボーンの終点側の関節の位置を調整
   
   これでジョイントの位置を調整します
7. Add Boneで追加のボーンをどんどん追加してDetach BoneやMove Selectionでジョイントの位置調整！
   
   
   これでボーンが配置できました！ジョイントの位置がイラストの関節or動かしたいものの終点の位置になるように調整するとアニメーションが作りやすいです（重要）
   また、ボーンのコピペ機能は無いのですが、Mirror Bonesでボーンを複製した後に複製したやつをもう一回複製するとミラーのミラーなので実質的なコピペができます（超裏技）
   
   
   ↑のミラーしたボーンを更にミラーしてもう片方の足のボーンを作っています
   上にはみ出た一回目のミラーは削除しましょう
8. Boneの名前の変更をしておく
   インスペクター上で変えられるので変えて起きましょう、後で地獄を見ますよ（暗黒微笑）
   

3. 各ノード接続

操作するノード：ASE File Inから出力したASE layer（もしくはImage）、Armature Create、Armature Pose、Armature Bind、Export

1. 上のバーの「Graph→Add Node」もしくはShift+Aでノード追加ウィンドウを出す
2. 「Armature Pose、Armature Bind、Export」を検索
   
   
   
   ExportはクリックするとExportのウィンドウがいきなり出ますがキャンセルをクリックするとノードが追加されます
3. 各ノードを以下の様に繋ぎ合わせる
   
   Armature Create→Armature Pose
   
   Armature Pose→Armature Bind
   
   ASE layer（もしくはImage）→Armature Bind
   レイヤーが下側の物から接続すること！ Armature Bindのインスペクター上でレイヤーが追加されて行っている部分がいわゆる「レイヤーの上下関係」を表しており、後に追加されたものは最終出力でレイヤーの上側に配置されてしまいます！
   
   後から変更することもできますが、「ボーンへの適用後にここをいじるとボーンの適用関係まで変わります！なんでやねん！」地獄を見ないようここでレイヤーの上下関係は整えておきましょう（1敗）
   
   Armature Bind→Export（ここだけ全部終わった後につなげてるので既に完成してますが気にしないでください）

4. ボーンにイラストの各パーツを割り当て

操作するノード：Armature Bind

1. Armature Bindのインスペクターをクリックして開く
   
2. インスペクターのレイヤー欄から、適用したいボーンにレイヤーをドラック＆ドロップ
   
   
   上記のように適用すると画像の位置がずれて表示されますが、これはボーンの中心位置に合わせて適用されるためです
   これは後で直せるので一旦全てのレイヤーを適用しましょう
   
3. ずれたレイヤーをプレビュー上で直す
   
   
   ドラックして直せます
   元のイラストと同じ縦横サイズであれば枠に合わせるだけでオッケーです
   ここで最初のASE File InでレイヤーごとにUse Cell DimensionをTrueにしていたりpngでレイヤーをCropで切り出すと位置調整が大変なんですね（1敗）
   
   一回位置調整したやつを再度選択しないように矢印マークをクリックするとそのレイヤーの位置調整がオフになるので、有効活用しながら全てのレイヤーを位置調整しましょう
   
   できたー！

ここまでができれば、同じボーンで別のアニメーションを作る際は接続したノードやプロジェクト自体をコピペして5.動きを作成からやればいけます！嬉しい～～～～

5. 動きを作成

ついに動きを作成します！結構泥臭い作業なので耐えましょう
また、ここからはArmature Bindをダブルクリックしてプレビューに表示させましょう

操作するノード：Armature Pose

1. 時間に合わせてアニメーションさせたいボーンの「Toggle Animation」をクリックしてオンにする
   
   オンでない場合、Armature Poseでは時間に関係ない変化として全てのフレームに適用されます
2. 画面下側のタイムラインのうち変化の最終地点にしたいフレームを選ぶ
   
   
   15フレームを選びました
3. そのフレームを選択した状態でインスペクター上の数値を変えるorArmature Poseのプレビュー上でボーン直接動かす
   
   上記の画像では「gun」ボーンが1フレームのx=0,y=0,rot=0,sx=1（大きさ）から15フレームのx=0,y=0,rot=30,sx=1（大きさ）まで変更されています
   これにより左下の再生ボタンを押すかスペースキーを押して再生すると2~14フレームではrotの値が0から30が滑らかに変わるように適用されます
   この時タイムラインに追加される四角のマークをキーフレームといいます
   ドラックで位置調整などができたり、キーフレームをダブルクリックしながら左右にドラックすると滑らかに変化する数値の度合いをタイムライン上で変更できたり、タイムライン左側のボーンの部分の波みたいなマークをクリックして変化の仕方を変えられたりします
   アニメーション再生する速度やフレームの長さを変更したい場合はタイムライン右下の歯車マークから変えられます
4. この作業を繰り返し、アニメーションを作成する
   
   後は気合です
   上記の画像は先に添付したこのアニメーションのキーフレームです
   
   あるボーンの動きを別のボーンにコピペしたいときは、1行（1種類のボーンのタイムライン上のキーフレーム）を選択して別のボーンのコピペしたいフレーム列、コピペしたいボーン行の部分をクリックしてCtrl+Vしてください
   しっかり選ばないと、コピー元のボーンにキーフレームが張り付けられてしまいます
   また、複数行を選択してコピペはできないので注意してください

6. エクスポートして完成！

Expotノードのインスペクターからファイルの保存先、ファイル名、アニメーションのファイルFormat（TypeからAnimationにしましょう）、ファイル形式、主力サイズなどの設定をします
その後インスペクター右上の「再生ボタンみたいな緑色の三角」を押してエクスポートです

初見でわかるか～w

いかがだったでしょうか。
どうしてもルコンポでボーンアニメーションを作りたいという情熱をお持ちの人はどんどん開拓していってください！（他人任せ）

おわりに

読んでくださりありがとうございました！かなりボリューミーな記事になってしまいましたが、ここまで読んでくれたあなたなら大丈夫。PixelComposerと共に日々を歩んでいきましょう。

Pixel Composer on Steam

A Node-based pixel art generator, editor, and VFX compositor. Create beautiful and complex effects in a non-destructive manner. Pixel Composer comes with a powerful graph system that supports multiple image manipulation, feedback effects, loop, physics, and fluid simulation.

STEAM

次のブログリレーの記事の担当者は@2251799813685248です。

この記事は夏のブログリレー34日目の記事です。

traPでは、年2回合宿を開催しています。今年も合宿先の山中湖から大学までの100kmを歩いて帰ってきたので、その様子をお伝えします。

前回開催時の記事はこちら：

traP夏合宿から歩いて帰りました

この記事はtraP夏のブログリレー30日目の記事です。 traPは年2回「合宿」というイベントを開催しています。今回の合宿は山中湖で開催され、ほとんどの部員は往復にバスを使用しました...が、我々はバスに乗らず、山梨県の山中湖の合宿先から東京都の大岡山キャンパスまでの100kmを歩いて帰りました。今回はその旅程を紹介します。 1日目 荷物を発送し、トイレを済ませて午前10:00に宿の玄関に集合。100kmの長い道のりがスタートします。途中までお見送りをしてくれた2人と別れて、10人でいざ出発。 山の中の道ですれ違うのは車ばかりなのですが、途中で歩行者の集団とすれ違いました。向こうの集団から「俺たちなんでこんなことやってるんだろう」という声が聞こえてきましたが、多分そういうことは考えないほうが良いと思います。 2020東京オリンピックの自転車競技にこの道が使用されたそうです。18%の坂ってすごくないですか？ 10km歩いたところでようやく人里が。自販機のありがたみを噛みしめました。 小山町内の飲食店で昼食を取った後、駿河小山で2人が離脱。 ここで3日目の夜までお世話にな

東京科学大学デジタル創作同好会traPramdos

概要

合宿先の山中湖から大学のある大岡山までの100kmを歩きました。

また、今年は✝Vibe Coding✝した専用アプリで進捗をリアルタイムで共有していました。

合宿中のLT会で登壇したときの資料があるので、興味のある方はご覧ください：

徒歩帰宅にVibe Codingを！.pptx

徒歩帰宅にVibe Codingを！ ramdos

Google Docs

1日目

1日目は山中湖から開成までを歩きました。

山中湖を6人で出発。1日中大雨に降られており、なかなか大変でした...

峠の上は霧が深かったです。

国道246号線に入り、神奈川県へ。

2年前には繋がっていなかった橋が繋がっていて感動しました。

2日目

開成から海老名までを2人で歩きました。

開成を東に向かい、秦野でお昼を食べます。

国道246号線をひたすら東に進みます。

晩ご飯はお肉を食べました。

そして厚木へ。

3日目

海老名から大岡山キャンパスまで歩きました。

すずかけ台横浜キャンパスを通過し、サークルの友人からの激励を受け東を目指します。

東名青葉ICを抜け、市が尾でおやつを食べました。

鷺沼で応援に来た先輩と合流。二子玉川まで同行してくださいました。

二子玉川を抜ければ、あとは大井町線沿いの住宅地を抜け感動のフィナーレです。

感想

足のマメが潰れたり、雨で体温が奪われたりと想像通り大変な行程でしたが、山を抜け246のロードサイドの移り変わりを眺め、東京の住宅地を通り抜ける行程を一歩ずつ歩くことは何事にも代えがたい経験になりました。

明日の担当はMimi_yearさんです。お楽しみに！（この記事は遅れて投稿されたので、すでに投稿されています）

この記事は夏のブログリレー35日目の記事です。

こんにちは！かっこいいエフェクト作りたいですよね。作ってみました。

今回は普段Unityで主に2Dゲームの制作をしている僕が初めて3Dのエフェクト(?)に手を出した話をします。

ちなみにこれはClaudeにお世話になりながら丸一日かけました。パラメータ調整がしんどかった。

目次

• blenderMCPありがとう
• リムライトありがとう
• VFXGraphありがとう
• Timelineありがとう
• Cinemachineありがとう
• Unityありがとう

blenderMCPありがとう

さて、3Dに手を出すと決めたんですが、なんと筆者は3DCGのソフトをまともに触れません。ｺﾏｯﾀ...

どうやら世界にはMCPというものがあるらしいです。自然言語ｶﾀｶﾀで勝手にソフト内のAPIを叩いて良い感じにしてくれるんだとか。
今回使いたい素材は↓コイツだったので(多分)そこまで労力はかからないと思いましたが、ここで時間食うのも嫌なのでガッツリ頼りました。

こんな感じで雑にお願いしたら一瞬でやってくれました。ありがとう。

自分が求めるクオリティぐらいなら秒でお出ししてくれてすごいですね。どうなってるんだ最近のAIは。
というわけでblenderMCPとAIありがとう。

リムライトありがとう

イメージしてたのはの形をしたエネルギー弾みたいな感じでした。
でもエネルギー感出すの難しい！ただ光らせるだけだと表面にLED付けただけっぽく見えるんですよね。

ふとスーパーゴーストカミカゼアタックのゴーストが参考になるんじゃないかと思って最近出たドラゴンボールのゲームの動画を漁ってみました。
見つけました。

ちょっと眺めて「これリムライトつけたらぽくなるんじゃね？」と思いました。なんでかはあんまわかってないです。
リムライトについてはこちら(もしかしたら↑はリムライトじゃないのかも。詳しい人がいたら教えてください。)

というわけでリムライトを実装し(てちょっと色味いじった)らこうなりました。

さっきよりなんとなくエネルギーっぽい気がします。
ドラゴンボールの気弾(特に元気玉とか)って端っこの方が白くて中心部にほんの少し寄ると色が濃くなると思うのでそういうイメージが反映されてるのかもしれないですね。
リムライトありがとう。

VFXGraphありがとう

UnityにはVFXGraphという大量のパーティクル等のVFXをノードベースで扱えるパッケージがあります。
雑にパーティクルを出していきましょう。こんなんなんぼあってもいいですからね。

パーティクルを置く事で画面の余白が少なくなってぱっと見良さそうですね。

あと雑に衝撃波も出してます。最初はテクスチャ一枚で賄うつもりでした。が、地味だったのでShaderGraphで良い感じのものを作りました。

VFXgraph(あとShaderGraph)ありがとう。

Timelineありがとう

UnityにはTimelineという機能があって、これを使う事で「一連の流れが決まっているもの」を楽に扱うことが出来ます。
Animatorという機能も似たようなこと(AnimationClipの再生)ができるんですが、これだとVFXGraphの発火のようなイベントの発火を扱うのが大変面倒です。
しかもTimelineにはVisualEffectControllTrackというVFXGraphを扱うための機能があります。最高か！

後述しますがCinemachineControlltrackという、Cinemachineカメラに対する機能もあるそう。嬉しいですね。(まぁそりゃ扱えるだろという気もしなくもないですが...)
Timelineありがとう。

Cinemachineありがとう

ここまでやりましたがまだちょっと地味です。

大体こういう時は画面揺らせば何とかなります。
UnityにはCinemachineという機能があります。超ざっくり言うとカメラに関するアレコレを良い感じにしてくれる機能です。Cinemachineを使って画面を揺らすことが出来るのでインパクト時に揺らしてみましょう。

さっきよりかなりドパくなったんじゃないでしょうか。
Cinemachineありがとう。

Unityありがとう

というわけで完成したのが冒頭の動画になります。
リッチな3Dエフェクトを目指すならUEとか触れると良いんでしょうが今回は初めて3Dに手を出したのもあって普段使い慣れてるUnityで作りました。
学びとしては

• 光ると嬉しい
• パーティクルいっぱい出てると嬉しい
• 画面揺れると嬉しい
• フレーム単位の調整がしんどい
• AnimationCurveの使い心地とAnimationClipのCurveの使い心地違いすぎないか？

などがありました。全体的にずっと嬉しかったです。Unityありがとう。

ありがとう

ここまで読んでくれてありがとうございました。
明日のブログリレー担当者は
@Mimi_year,@tobuhitodesuです！お楽しみに！

参考

• https://github.com/ahujasid/mcp-for-blender
• ドラゴンボール Sparking! ZERO
• スーパーゴーストカミカゼアタック ゴテンクス ブラスト技【ドラゴンボールスパーキングゼロ】
• 【UE5】キャラクターに立体感を–「リムライト」の追加方法【アニメ調表現:part5】

この記事は 夏のブログリレー 33日目の記事です。

この記事では東京科学大学の一部の講義内容を取り扱っていますが、すべて学生有志により執筆されており、大学が公認するものではないことをご留意いただきたいほか、本稿についての問い合わせを大学に対して行うことはお控え願います。

また、基本的には 2026 年度のシラバス・講義内容に基づいています。将来的には講義内容等が変更されうることに注意してください。受講を検討している方は当該年度のシラバスを熟読されるとよいでしょう。

「プログラミング創造演習」のすゝめ

東京科学大学 情報理工学院 情報工学系 では毎年「プログラミング創造演習」という講義が開かれていることをご存知でしょうか。

詳細についてはシラバス等の資料をご一読いただきたいのですが、概要だけを簡単に紹介すると、学生が各々プログラミングに関連する何かしらのテーマを設定し、それに取り組むというものです。

毎年、本当に多種多様なテーマがあるようで、本年も一口にプログラミングといえど、コンパイラの基礎にはじまり、証明支援ツール、アルゴリズムの応用、ヒューリスティック最適化、Web 開発、などなど....本当に様々な分野・レイヤーにまつわるテーマ・発表がありました。

1Q, 2Q の 2 四半期にわたる授業ですが、講義自体は初回のオリエンテーションと中間発表、そして最終発表くらいで、それらを除けば学生自身が主体となって取り組んでいくことが求められます (が、テーマを設定の自由度が非常に高く、基本的には自分の好きなテーマを設定できるため非常に楽しいです。)

講義そのものは週に 6 時間ですが、上述の講義以外は出席が求められないどころかそもそも授業自体がないので、好きな時間に好きなだけ取り組むことができます。(もちろんアルバイトやサークル活動等をすることもできます。)

講義室自体は受講者に対して解放されているため、他人に邪魔されない作業スペースとしてもそれなりに優秀といえるでしょう。

......などなど、プログラミングやコンピュータサイエンスが好きな学生にとっては本当に夢のような講義ですので、情報工学系に進学される皆様はぜひ履修していただければと思う次第です。

注意点

プログラミング創造演習は「手続き型プログラミング基礎」(1Q)  / 「手続き型プログラミング発展」(2Q) という講義に干渉する形で開講されています。(シラバスでも述べられていますが) これらの講義は、C/C++ 言語の基礎を学ぶための非常に重要な講義ですから、本当にプログラミングが初めてで、C/C++ の基礎も怪しいといった方は、創造演習ではなく、こちらを受講されるのがよいかもしれません。(現代には様々なプログラミング言語が存在しますが、しかしやはり、大学という機関でコンピューターサイエンスを学ぶにあたっては、C/C++ の基礎知識は必須であるといって差し支えないでしょう。)

FAQ

Q. 絶対 $100\text{点/単位}\times 6\text{単位}$ が貰えるって本当？

A. オリエンテーションによれば、「そのような事実はない」らしいです。

テーマ例

今年の受講者は 23 名でしたが、そのうちの数名のテーマについてご紹介します。(みんなありがとう！)

受講を検討している方は、ぜひ温度感の参考になさってください。

@uni_kakurenbo

pure-Go を用いて、.wav や .falc 等の一部の音声フォーマット/コーデックのデコーダやエンコーダおよび音声処理を行うフィルタなどを実装しました。

関連ブログ:「pure-Go で FFmpeg の subset を実装したい！」

@n3

シークエント計算の証明をチェックできる Ｃ++-like な言語を作成しました。

論理学や形式証明に興味があったのでこのテーマを選びました。Pythonで証明の探索を実装し、得られた証明を C++ で実装したカーネルが検証する、という機構まで実装しました。

カリーハワード同型対応、自動証明、コンパイラやLSPの仕組み、などが理解できていい勉強になりました。

GitHubのリンク: https://github.com/n-and-n3/ProofAssistant
（適当に作ってるので汚いですが...）

@Haru_18

Roslyn (正式名称： .NET Compiler Platform) という C# のコンパイラ基盤を用いて、Unity によるゲーム開発を手助けするツールを作成しました。
計 4 ツール作成しましたが、一番最初につくった「クラス図ジェネレータ」が一番好きです。
今回学んだ Roslyn の知識を活かして、今後も痒いところに手が届くようなツールをつくっていこうかな、と思います！

リンク: https://github.com/haru018/UnityArchitectureTools

@Ida-ji

AHC (AtCoder Heuristic Contest) の過去問を解いたりコンテストに参加したりして、ヒューリスティック問題に対する実装力や理解力を深めました。
70 時間くらい AHC をやったらレートが 700 くらい上がりました。

関連ブログ: 「3分半で分かるかもしれないAHC020」

@fken_57

React と Go、D3.js などを組み合わせることで競技プログラミングを支援するサイトを作りました！グラフと配列とランダムテストに対応。Web 初心者ながら基本的な Go/React プログラミング、Clean Architecture を学習するのにいい機会になりました！

@genMira

React と Go でタスクを管理するためのアプリを作りました。今まで web サイトを作るときにはずっと Vue を使っていたので、React を勉強するいい機会になりました。

@rurun

ArCoder と競技プログラミングを通じて発展的なアルゴリズムの学習に取り組みました。

明日のブログリレーの投稿者は @ramdos です。お楽しみに！

こんにちは、vPhosと申します。
準備期間1ヶ月、制作期間1ヶ月で制作を行うイベント、1-Monthonに1人で参加し、テーマ賞を頂きました。ありがとうございます。

作ったもの

以下の動画を参照してください！

これは実際の制作物と違い、声をそれぞれゆっくりに置き換えています。

最終発表自体が制作物、というものです。

この記事では制作中に考えたこと、やったこと、参考にしたものなど、動画内で書けなかったものを書いていきます。

準備期間

自分のできることは以下のとおりです:
サウンド: 電子音楽であればそれなりに作れる、劇伴系と歌ものは無理
3DCG: やったことはありますが……。
動画編集: 音声波形の出し方だけわかります
プログラム: Unity触ってゲーム作ったことはあるが、楽しいと思えなかった
イラスト: 無理！

これでどうやって戦えばいいんだ?

まあ順当に動画編集の神になって動画を作ることに決めました。

というわけで構想を練り、ストーリーのプロットを考え、リファレンスを用意してどのような映像を作るかも決めました。

そこで私は気づいたのです！

これ、作れるわけなくない？

何をどう考えてもまともな絵描きと3DCG人間が必要で、なおかつ自分の得意な作風の音楽にならない、ということに気づきました。
どういうものを作ろうとしてたかについてめちゃくちゃ書きたい気持ちは大いにありますが、似たようなコンセプトで冬ハッカソンなどで人を集めてやりたいな、と思っているのでここでは内容を控えさせていただきます。震えて待ってください。今年は卒論あるし無理かも

結局この案は没にして、代案を考えなければいけませんでした。

制作1~2週目

今回1人で参加した理由の1つでもあるのですが、私はB日程での院試がありました。
ワンマンソンは8/8制作開始、9/5に最終発表という日程でしたが、院試は8/18に筆記試験、8/25に口頭試問という日程でした。
すなわち基本的にはワンマンソンの前半は基本的に何も出来ません。無謀ですね。
このような状況でチーム参加して他人に迷惑をかけるわけにも行かなかったので、一人で参加しました。

というわけでこの時期は院試勉強して院試受けてました。筆記試験を受けた感じまあよほどのことが無い限り通るだろって感じでした。
口頭試問はあまり重くないので、筆記試験終わってから作り始めました。

このあと口頭試問全然答えられず痛い目に遭いました。結果受かったから良いんですけど。

制作3週目

ここでは残り2週間でも間に合うよう、テーマ「あい」→藍として藍色メインの動画を作りたいと思っていました。世間一般(私が見ている周りのこと)での流行りとして#0000FFをメインにした動画があるなと思ったので、そっち系に寄せたいなという気持ちがありました。

参考：

まあこういう動画どうやって作ってるか未だにわからないんですけどね！！！！！
見ていただいた制作物に上の動画群のかっこよさは全然載せられてないんですが、少しでも要素を感じていただければ嬉しいです。

ただこのような動画を作るうえで、少し葛藤もありました。

とある部員のこのような投稿が頭の片隅に残っていました：

ワンマンだったら別にイベント関係なくやれば良くないって考えちゃったり

全くもっておっしゃる通りだと思います！
自分でもこの段階では、「こりゃあ個人制作で良いですね」状態でした。
勿論締切が設定できたり、発表の機会が設けられたりする点は個人制作では実現できない魅力なのですが。
そうはいっても、自分の作品は何かワンマンソンであることに意味を持つ物がいい！という思いがありました。
そんなことを考えているうちに、発表自体を制作する、というアイデアにたどり着きました。

最近のtraPのハッカソンでは、動画を制作する場合、完成品の動画を垂れ流すだけの発表は禁止されていて、必ずこだわりポイントやツールなどについて触れる必要があります。
この制約から、逆に、動画だけを流しても、それらの説明さえすればルールに触れないのではないか？という発想が生まれ、このような1発ネタ発表の構想が立ちました。
ルールの穴を突くって魅力的ですよね。
コンセプトから要件定義がしやすいというメリットもあります。
というわけでなんとなく考えた要件が

• 普通の発表のように始めること
• 道中でコンセプトなど説明をすること
• 藍色に合う音楽
• 発表時間2分を厳密に守ること

という感じです。

最初は音楽から作り始めました。
電子音楽らしさが欲しいと思い、Complextroというジャンルを主軸に作りたいな、という目標で作り始めました。また、そのとき、Sharks, Chime - Water Elementalを知りSharksにドはまりしていたので、SharksのようなColour Bassに寄り道したり、映像表現として面白いだろうと思い、Chiptuneを混ぜようと思いました。多分発想の大本はlitmus* - Flashdanceらへんんだと思います。

このブログを読む人の大多数はComplextroを知らないと思いますので軽く説明すると、ComplextroはElectro Houseというジャンルをより複雑に、色んな音を混ぜたりしたジャンルです。(名前の由来もComplex + Electro)
有名なもの、好きなものを貼っておきます：

実際に作ってみると、Complextroか微妙な感じになりましたね。特にウワモノがあんまりうまく作れてない感じがします。

メインのベースはうまく出来た気がします。
どこかで見かけた、PhaserのRateを0にしてFrequencyをS&Hで動かすやつが大活躍した感じですね。ベースの元はなんか適当なFMとかSpectral系にSine Fold系のDistorotionをかけて、最後Disperserで質感出した感じです。多分シンセいじってない人には呪文にしか聞こえないと思うんですけど、普段僕らもプログラムできる人に「プログラム人間しかわからない単語を唱えられるハラスメント」通称プロハラをされてるのでお互い様ってことで。

Colour Bass地帯は自分の中でかなりできが良いなと思ってます。大体Chromaのおかげ。
あとは水の音を作る再考のチュートリアルのおかげでもあります：

無料で導入できる最強シンセであるところのVitalで作られてるのがいいですよね。

制作4週目

曲が完成したので、動画を作っていきます。
Adobeに払うお金はないので、Aviutlを使いました。
さて、私は動画編集初心者です。どうすればいいでしょうか？

考えたこととして、オブジェクトが少ないとよほどのセンスが無い限り初心者感が出る、ということがあります。
作曲と同じで、情報量を増やさなければと考えました。

というわけでFL Studioの画面録画を擦り続けました。ありがとうFL Studio。
FL Studioの垂れ流しって世界で一番かっこいいと思うんですよ、どっかの生きてるDAWよりもずっと生き生きとしてます、異論は認めません。
ちょっと前から名前に騙されて死にに行く人が増えて悲しかったんですが、最近Bitwigってのが出来てから皆そっちに移動しているイメージがあってざまあみやがれって感じです。
というわけで基盤ができました：

他にも極座標変換したものもariiolっぽくていいですよね

文字は大体全自動リリックモーションというものを入れてなんとかしてます。結構歌詞MVだと定番らしい？
初心者なので許して〜みたいなクオリティです。まあスライドアニメーションの拡張だと思えばこんなもんという言い訳ができます。

この立方体はAviutlの立方体(3D制御)を使ってます。本当はもっと色々したかったんですけど、パソコンのスペックの問題と普通にカメラ制御と仲良くなれなかった関係であんまり大したことしてないです。Aviutlってなんか結構3Dで色々できるらしいんですけどね。
参考：

最後は全部まとめて終わり！
構成もシンプルですね。

動画の構成の都合上見た皆さんの反応が見れなくて悔しかったです。

テーマ賞をいただいたときは驚きました。今回は「あい」「まい」のそれぞれに賞があるのではなく、テーマを回収できていたか？みたいな部分での評価でしたので、そこが有利に働いたのかなと思います。このへんの賞はプレゼン自体の印象に左右されますし。

何にせよ楽しかったので良かったです！
ここまで読んでいただきありがとうございました！

この記事は 夏のブログリレー 32日目の記事です。

FFmpeg の提供する機能全体からなる集合を $F$ とします。
$\{\}\subseteq F$ より、$\{\}$ を実装することで、題意を満たすことができました。

いかがでしたか？

こんばんは、25B のみどりむしと申します。

情報工学系の 200 番台には「プログラミング創造演習」という講義があり、パソカタをするだけことで単位が貰えます (しかも結構いい点数が来たり来なかったりします)。なんとも夢のような話です。

そこで私は「pure-Go によるマルチメディアトランスコーディングのためのオープンソース FFmpeg 代替アーキテクチャの開発」テーマで開発に取り組むことにしました。

実際にはこんな大層なものが 2 四半期で終わるわけがないので、音声コーデックの、そしてそのさらに一部に限って実装することにしていました (FFmpeg 代替とか言ってますがタイトルでカッコつけただけです。)。

動機

私は traP で traQ というチャットツールを開発しているのですが (紛らわしいですね)、その中で .m4a の波形のプレビューをしたいという要望がありました (波形画像を生成するために Linear PCM に変換する必要があるため，現在は .wav や .mp3 のみ対応しています)。

しかし、Go にはそこそこ動きそうな .m4a のデコーダライブラリがなさそうだったため、FFmpeg を導入することも考えられたのですが、せっかくサーバーが pure-Go なのにもったいないといったような議論があり一時保留となりました。

それを機に pure-Go で音声コーデックを実装することに関して興味を持ったという流れになります (先にオチを話すと、.m4a に記録できるコーデックのうち ACC の仕様書が学生には高額すぎたため、結局 .m4a は実装してません。)。

また、個人的に Go はあまり好きではなかったのですが、そういえば大してなにも作っていないのに毛嫌いするのもよくないかと思い、もう少し真面目に Go を触ってみることにしました (結果的には今は「普通」くらいに思っています。Python よりちょっと好きくらい)。

作ったもの

どーん

GitHub - godexture/workspace

Contribute to godexture/workspace development by creating an account on GitHub.

GitHubgodexture

最初はポリレポにしようと思って一丁前に Organization まで作ったのですが、複数リポジトリの同期リリースが面倒すぎてやめました (ちょっと時期尚早だったね。)。

AI 君と特大リファクタリングを行っている最中に飽きて放り投げたので結構コードがひどいことになっていますが、た、多分動くと思います...... (やる気が戻ってきたらまたメンテナンスします。)

創造演習当時のバージョンを

go install github.com/godexture/godec@latest

でインストールもできます (リリースをサボっているので今の master とは若干サブコマンドとかが違います)。

あとは

godec convert in.mp3 out.wav
godec play out.wav

とかできます (再生には https://github.com/ebitengine/oto を使ってます。God Library．)。

楽しくなって  delay とか reverb とか resample とか FFT convolver とかいろんなフィルタつくりました。

godec play out.flac --filter trim --filter fade:fade-in=10s 

とか

godec convert \
	in.wav out.wav \
	--filter "split=mixer[in=1,out=2]" \
	--filter reverb \
	--filter delay \
	--filter "join=mixer[in=2,out=1]" \
	--wire "split.in0=@in" \
	--wire "reverb.in=split.out0" \
	--wire "delay.in=split.out1" \
	--wire "join.in0=reverb.out" \
	--wire "join.in1=delay.out" \
	--wire "@out.in=join.out0"

とかできます。たのしい！

Go の API もあります。Go としてどうなのかはわかりません。

例によって今の master では動きません (:person_facepalming:)

package main

import (
	"context"
	"fmt"
	"os"
	"runtime"
	"runtime/debug"
	"runtime/pprof"

	"github.com/godexture/filter-audio"
	"github.com/godexture/sdk/dsp"
	"github.com/godexture/sdk/profiling"
	"github.com/godexture/sdk/timer"

	godec "github.com/godexture/core"
	"github.com/godexture/core/domain/media"
	"github.com/godexture/core/routing"

	flacFormat "github.com/godexture/format-flac"

	_ "github.com/godexture/codec-flac"
	_ "github.com/godexture/codec-mp3"
	_ "github.com/godexture/codec-pcm"
	_ "github.com/godexture/format-flac"
	_ "github.com/godexture/format-mp3"
	_ "github.com/godexture/format-wav"
)

const targetCodec = media.CodecFLAC

func main() {
	inputPath := os.Args[1]
	outputPath := os.Args[2]

	inputFile, err := os.Open(inputPath)
	if err != nil {
		fmt.Printf("Failed to open input: %v\n", err)
		return
	}
	defer inputFile.Close()

	outputFile, err := os.Create(outputPath)
	if err != nil {
		fmt.Printf("Failed to create output: %v\n", err)
		return
	}
	defer outputFile.Close()

	negotiator := godec.NewNegotiator()

	spec := routing.ConversionSpec{
		Input:       inputFile,
		Output:      outputFile,
		TargetCodec: targetCodec,
		Filters: []routing.FilterSpec{
			{
				Config: filter.MustNewResampleConfig(
					filter.WithSampleRate(48000),
				),
			},
		},
		MuxConfig: flacFormat.MustNewMuxerConfig(),
	}

	geometry, err := negotiator.NegotiateConversion(context.Background(), spec)
	if err != nil {
		fmt.Printf("Failed to negotiate conversion: %v\n", err)
		return
	}

	builder := godec.NewBuilder()
	conversion, err := builder.Build(geometry)
	if err != nil {
		fmt.Printf("Failed to build pipeline: %v\n", err)
		return
	}
	defer conversion.Close()

	if err := conversion.Run(context.Background()); err != nil {
		fmt.Printf("Pipeline execution failed: %v\n", err)
		return
	}
}

実は SIMD を有効にすると一部 SIMD で動きます。それなりにパフォーマンスチューニングを頑張りました。

あとは調子に乗って Web で動くエディタも作りました (半分くらい Claude と Codex が)。
いろいろできて結構楽しいです。 

Godexture

Go なので WASM で動かすこともできます。遅いけど。

サポート

Formats (Demultiplexing / Multiplexing)

• WAV, RIFF (Demux, Mux)
  • U8, S8, S16, S32, S64, F32, F64
  • Big Endian, Little Endian
  • RF64
• FLAC (Demux, Mux)
• MP3 (Demux)

Metadata (Unmarshalling / Marshalling)

• ID3 (Unmarshall, Marshall)
  • ID3v1
  • ID3v2.1, ID3v2.2, ID3v2.3, ID3v2.4
• Vorbis Comments (Unmarshall, Marshall)

Codecs (Decoding / Encoding):

• PCM (Decode, Encode)
  • Linear PCM
  • G.711: μ-Law, A-Law
  • ADPCM
    • MS ADPCM
    • IMA ADPCM
• FLAC (Decode, Encode)
  • Full Support!!
• MP3 (Decode)
  • MPEG-1 Audio Layer-3

Filters (Processing):

• Resample
• Remix
• Gain
• Normalize
• Fade
• Gate
• Trim
• Retime
• Convert Format
• Remove DC Offset
• Compress
• Equalize
• Reverb
• Delay
• Convolve (FFT)

感想

Go ちょっと楽しいかもって思いました。
でもバイナリ操作したりするなら流石に Rust とか C++ のほうがいいね。

GC 便利だけどやっぱりパフォーマンスチューニングとかしようとすると結局 GC のお気持ちを考えてご機嫌取りしないといけないのがつらいです、私は GC 無い方が好きかな、嘘です、参照カウントくらいは欲しいかも。

でも Go にもゼロアロケーションを謳ってるライブラリとかあるらしくてすごい。正気？

あと仕様書が有料ってちょっと嫌な気持になりますね。いやしょうがないけど、こっちも学生なので許してほしい。というか工業大学って名前なら ISO/IEC とか JIS の規格書くらい全部タダで読めてほしくないですか？　あ今は工業大学じゃないんでしたねそういえば。(ISO/IEC 14882:2024 の寄贈待ってます♡)

学生に使ってほしい人は無料で仕様書を公開するといいと思います (?)

FLAC とかすべてが無料で読めてとても楽しかったです。
皆様もよき FFmpeg ライフを。

あと創造演習はいいですよ、ぜひ履修してください。

二時間前くらいに書き始めてなんとか間に合いました。
殴り書きですみません。

明日のブログリレーの投稿者は 25/jk と @ramdos です、お楽しみに。

この記事は2026年ワンマンソン18班の参加記事です。

技術賞をいただきました！！

制作物

ライブをもっと身近に体験できるものにしたいという思いから、スマホをペンライトに見立てた同時視聴アプリを作成しました。
youtubeやニコニコ動画のボカロ曲のURLを貼るだけでルームが作成され、初音ミクがリズムに合わせて踊ってくれます

メンバー

24B エルマer　全員自認の魔法少女ということがきっかけにチームが結成されました。悪魔役担当です。そこ、黙りなさい。
24B あきも　最近はワスのことばかり考えています。すき……
24B otima　進捗の魔女。その性質はシンギュラリティ。勝手に手下だと思っているClaude Codeにコードを書かせ、自分で書くことはない。

サービス紹介

曲選択画面

似たサービスとして挙げられる音ゲーなんかは遊べる曲に限りがありますが、このアプリの対象楽曲は無限です！
『初音ミク「マジカルミライ 2026」楽曲コンテスト』の６曲から選んでもよし、YouTubeやニコニコ動画から好きな曲のURLを貼っても曲情報を解析できます。産総研のAPIスゴイネ。

待機画面

曲情報の解析が終わると部屋が作成され、QRコードを読み込むことで観客として参加できます。
スマホの画面は以下のようにペンライト風の画面になります。

ペンライトの色を変えられるだけでなくライブ中にtraQ上のスタンプを画面に送ることもできるよ！

ライブ画面

ライブが始まったらあとはスマホを心赴くままに振りまくってください。手元で設定したペンライトの色や振りがリアルタイムに反映されます！

開発の流れ

TextAlive App APIを使って何か作りたいという話があり、いろいろアイデアを出し合った結果リアルタイム型のアプリケーションを作ることになりました。分担は成り行きで

• フロントエンド：エルマer、otima
• バックエンド、同期周り：あきも

という感じになりました。

フロントエンド

なぜかフロントも最初の二週間くらいは何も動いてませんでしたね（？？？）
バックエンド側でAPIを叩いて楽曲情報を取得が実装されるまでに画面構成とか考えようとしたんですが、、、、
結局、最終発表前日に画面を作り終えました。

フロント側で特筆すべき点があるとすれば、MMD（初音ミクの3Dモデル）をブラウザ上で動かす部分ですかね。three.jsにMMDとVMDを読み込むための公式アドオンが用意されていたのでこれを軸に実装しました。
APIからサビかどうかの判定がもらえるので、サビ用のモーション配列とサビ以外でのモーション配列をあらかじめ作っておいて曲の小節ごとにモーションを切り替えるといった構成になっています。

バックエンド＆同期周り

仕様を決めるが大変というか面倒くさくて、最初の2週間ぐらいは何もしていませんでした。

技術賞をいただいたので技術的な部分について触れると、サーバーはRustで実装しています。これはリソースにそれほど余裕がないNeoShowcaseにデプロイするためです。しかし楽曲情報の取得にはTextAlive App APIを使わねばならず、規約上公式のJavaScriptクライアント以外を使うのは怪しそうだったため、必要なときだけDenoを起動して楽曲情報を取得するという構成にしました。

同期はWebTransportと、独自に定義した形式のバイナリで行っています。サーバー内部ではそれほど複雑な処理を行わないので、実装自体は思っていたより順調に進みました。ラスト3日ぐらいでフロントエンドとの繋ぎこみをやって完成！

感想

エルマer

マジカルミライにアプリ開発のプログラミングコンテストがあるんだ、いつか作ってみたいなと思っていたので、付き合っていただいた二人は感謝です。
TextAlive App APIを使ってアプリを作りたいと言い出した身として最初の二週間、班として動きがなかったのは反省ですね。最終発表があと一週間先だったら一曲を通してミクさんに気持ちよく歌ってもらえたかなぁって。でもwebの王と産総研にキャリーしてもらえて技術賞もらえてはっぴーなのでよしとしよう。
来年はプログラミングコンテストに作品を提出できるようにがんばります。

あきも

元々今年の1-Monthonは参加を見送ろうと考えていたのですが、おだてられたので気分が良くなってうっかり参加してしまいました。

思ったより夏休みにバイトを入れすぎてしまったので最初はちょっと後悔していましたが、結果は技術賞ということで頑張った甲斐があったなぁと感じています。

個人的には今年の春ハッカソンで最終日にいざサーバーを動かそうとしたら大量のバグが見つかって上手くいかなかった反省を踏まえ、ちゃんとテストを書くようにしたことで（問題はそれなりにあったものの）一応動くものが作れたのが良かったです。

WebTransportを触るのは初めてでしたが、使ってみて初めて分かること（ブラウザ間の挙動の差）などもありました。やっぱり新しい技術に触れるのは楽しいな〜と思います。

otima

主にスケジュール管理とコミュニケーションができてないせいで最後地獄を見ましたが、案と行動があればものって作れるもんだなと思いました。必要なのは金とコミュニケーション💪💪💪
技術賞は王とClaudeのおかげです。

この記事は夏のブログリレー21日目に投稿された @quarantineeeeeeeeeeによる 講習会をシステム化するサービスを作ろうとした【ハッカソン反省】 の続きです。

作品紹介

私たちが作ったのは、「stoQ」という講習会ナレッジベースです。部内で開催された講習会をストックしていき、資産として新たな学習者に届けることを目指しました。

GitHub - traP-jp/1m26_13

Contribute to traP-jp/1m26_13 development by creating an account on GitHub.

GitHubtraP-jp

さらに、このサービスが使われるようになるために、講習会運営にデータを入力してもらう必要があったため、情報入力用のUIを誰でも編集できるような機能も実装し、運営の入力の手間を減らすことも考えました。

この作品は、ハッカソンにご協賛いただいた株式会社ナレッジワーク様より、企業賞に選定いただきました！

また、話の成り行きでUIライブラリを自作することになりました。

GitHub - traP-jp/basiq-ui

Contribute to traP-jp/basiq-ui development by creating an account on GitHub.

GitHubtraP-jp

それでは、今回のサービスを作るにあたっての背景や、設計時の意思決定について紹介していきます。

作品を作るに至った背景

traPでは、経験者が知識やノウハウを参加者に伝えていく「講習会」がたくさん開かれています。例えばtraP内のゲーム班ではUnity講習会を、アルゴリズム班ではアルゴリズム基礎講習会を開催しています。

しかしここには大きな問題が3つあります。

問題①：講習会を開催するための手続きが複雑

講習会を開く前には様々な準備が必要です。
講習会の日時を決めたり、資料を作ったり、部内のスケジュール管理アプリに講習会を登録したり、開催する講義室を予め予約してもらったり、部内に向けて告知したり、......などなど、たくさんあります。

そのため、初めて講師をやることになったり、講習会の運営に初めて携わることになった人は、「何から手を付ければ良いのか分からない」となってしまいます。

問題②：手続きが明文化されておらず、属人化してしまっている

また、講習会の準備は講習会によって少しずつ違います。講習会によって開催する回数が異なるのはもちろん、受講できない人を減らすため、全く同じ内容の講習会が複数回開催されるものもあります。例えば、ゲーム班のUnity講習会は全3回からなる講習会ですが、プログラミング基礎講習会は全8回からなります。（ちなみに、プログラミング基礎講習会のテキスト は公開されています！）

それにも関わらず、講習会の準備はほとんど明文化されていません。毎年行われる講習会であれば、たいてい先輩が書き残した引継ぎ資料がありますが、講習会によって充実度はまちまちです。準備のやり方を特定の人しか把握していない属人化した現状は良いとは言えません。

問題③：過去の講習会の情報が、アクセスしやすい場所に体系化されてまとまっていない

もちろん講習会が実施された当時は、その講習会に関する様々な情報をあちこちから得られるでしょう。たとえばtraQ（※1）の投稿やknoQ（※2）に追加されたイベント情報を見ることで、いつどこで誰がどんな講習会を実施するのかや、どこでテキストを見れるのかに加え、質問したい場合はだれに聞けばいいのかなど、を知ることができるようになっています。多くの講習会は録画を撮影しており、サークルメンバーであれば、だれでもアーカイブを視聴できるようになっています。

とはいえ、講習会のデータはたくさん残っていても、有効活用できているとは言い難い状況でした。部内Wikiはあるが、使いにくく、別に講習会に特化して情報が書かれているわけではありません。また、初心者に講習会を受けてもらいたくても、初心者ほどtraPに慣れておらず情報を探すのが難しい傾向にあると考えています。

※1 traQ：部内連絡用チャットツール。部内イベントに関するお知らせ、サークル運営のためのやり取りに加え、traPのメンバー間での情報共有や雑談などもおこなわれている。2026/9/6時点での総メッセージ数は993万件！ https://github.com/traPtitech/traQ , https://github.com/traPtitech/traQ_S-UI

※2 knoQ：部内イベント管理サービス。借りている講義室の情報やイベント対象者、出欠確認などを行えるサービス。 https://github.com/traPtitech/knoQ , https://github.com/traPtitech/knoQ-UI

問題の解決に向けて

これらの問題を解消するため、講習会の知見を資産としてまとめるサービスを作ろうと考えました。また、ただまとめるだけではなく、情報が集まるための仕組みも一緒に作ることにしました。

講習会の情報を集めるためには、講習会を開催する人に入力してもらうのが手っ取り早いです。しかし、講習会を開催する人にお願いしても、全員が全員書いてくれるわけではないでしょう。そこで、情報を登録するだけではなく、講習会の開催を丸ごとサポートするサービスとすることで、自然と情報を入力してもらえるようにしようと考えました。

講習会を開催したい人に、まずこのサービスを開いてもらいます。開催にあたって必要な手順がすべて書いてあるので、講習会主催者はこの流れに従って準備すればよいし、サービス側にとっては必要な情報を入力してもらえるわけです。

ただ、ここでさらに別の問題が発生します。「講習会の開催にあたって必要な手順」というのは、しょっちゅう変更されます。手順をソースコードに書いてしまうと、プログラミングに詳しい一部の人しか書き替えられなかったり、そもそも更新が大変で放置されてしまったりといった問題がおきるでしょう。

誰でも簡単に書き換えられるようにするため、講習会開催のための一連のフローを投稿できるようにしました。

フローの中に書いた、{{ }} は、対応するIDの入力欄となります。入力画面を自由にカスタマイズできるようにすることで、講習会開催マニュアルがだれでも簡単に修正できるようにしました。

自作UIライブラリ「BasiQ-UI」について

余談ですが、今回のハッカソンのために開発していたUIライブラリについても紹介します。

部内チャットツール traQ のデザインを参考にしつつ、最低限UIを作るために必要なコンポーネントをたくさん作りました。しかし、traQは6年近くにわたって継続的に開発されていることもあって、必ずしも一貫したデザインとなっているわけではありません。

そのため、traQのデザインをできるだけ再現しようとはせず、短期間で開発を進められるよう大胆に整理してあります。また、アクセシビリティ対応を重視した設計・デザインを行いました。

開発の様子

準備期間

開発期間（前半）

8/23にBasiQ UI v0.1.0-beta.0をリリースしました。

開発期間（後半）

完成までにやらなければならないタスクが概ね整理されたのは8/30で、やっと画面の構成やデータベースの設計が始まりました。

最終発表まで毎日のようにDiscordで通話しながら開発したり、大学に集まって開発したりしていました。

感想

mikannkann

正直、今回は今まで参加したハッカソンの中でも、だんとつで時間がありませんでした...

仕様をかなり詰めていたぶん、もう少し開発に時間をかけられたらよかったな、という少しもったいない気持ちがあります。

一方で、時間がなかったにもかかわらず、今までのハッカソンの中で一番深く仕様を考えられたことは、実はかなり嬉しかったりもします。

一見すると、このサービスは単純で、すぐに作れそうです。
ただ、真剣に設計しようとすると、実はかなり難しく、とても考えごたえがありました。

設計の段階で妥協してしまえば、もっと簡単に、
それこそ数時間で「それっぽいサービス」を作れたと思います。

ただ、今回のチームには、そういう妥協では納得する人がいませんでした。

しかも、メンバーそれぞれが違う方向に長けていたので、
それぞれの視点から本気で考えて、本気でぶつかり合うことができました。
（そして、自分も含めて全員ちゃんとバトルするので、ただでさえ時間がないのに全然話がまとまらない）

1-monthonなのに、結果的には開発に使えた時間がかなり短く、そこはやっぱり悔しいです。
ただ、自分はこういうぶつかり合いが大好物なので、本当に楽しかったです。

簡単には話がまとまらない。
でも結局、こういうめんどくさいチームが、自分は好きなんだと思います。

次は、スケジューリング、もっと頑張りたい！！

rurun

AIを叩きながら案を出したり、ちゃぶ台返しをしたり、旅行に行ったり、プレゼンの一発ネタを作ったり、旅行に行ったりしていました。

これはハッカソンに限らないことかもしれませんが、これまで何度かハッカソンに参加する中で、「アイデア」と「完成」、「ハッカソン後に使い続けてもらう」というそれぞれの間に大きな壁があることを感じてきました。今回のハッカソンでは、「ハッカソン後に使い続けてもらう」ところまで見据えてやってきましたが、結果的にはそこまで辿り着けませんでした。

今回の開発では、Codexの有料プランを持っている人が複数人いて、最初は余裕だろ、と思っていた部分もありました。しかし、いくらAIがプログラミングをできるようになったとしても、こちらがきちんと指示をしていかないと、「なんとなく良さそうなもの」はできても、「traPの現状に即した、みんなが使ってくれるもの」は出来上がりません。その部分のハンドリングをうまくやり切ることができなかったのが、当初目指していたところまで完成しきれなかった要因だと感じています。

みんなで議論をする中で、サービスを継続して使ってもらうためのアプローチ（講習会運営のサポート、編集・投稿可能なフローなど）は良いアイデアを出せました。しかし、どんな情報を載せるか、どういう流れでサービスを使ってもらうか、といったところの具体的な設計までは詰めきることができませんでした。各々の頭の中にはあっても、それぞれのメンバーでちょっとずつ思い描いているものが違ったり、それをAIにうまく共有できなかったりしたのが難しいところでした。

とはいえ、AIが自律的にできる部分と、人間が介入しないといけない部分の境目を見ているようで、とても面白かったです。

また、チーム開発ならではの難しさとしてみんなでなかなか集まれなかったのも反省の一つです。考えていることがみんな少しずつ違って、それを擦り合わせていくのは対面でなければ難しいと思います。対面で意見をぶつけ合ったり、みんなでわいわいしたりする方が楽しいですしね。その分AIに文脈を渡すのは難しくなっていくけど...

さらに、メンバーによって開発経験やAIへのアクセスに差がある中で、もっとみんなが楽しんで参加できるチーム運営にも課題があったなと感じています。

色々と書いてきましたが、反省の裏返しで、さまざまな学びのあるハッカソンでした！

yasako

コンポーネントライブラリって作るの難しいんですね。かろうじて「ライブラリ」を名乗れるくらいのコンポーネント数や品質は達成できたのでは無いかなと思っています。詳しくはBasiQ-UIについて紹介した項を読んでほしいのですが、最初の一週間半は、ずっとFigmaをいじっていました。大変だった...。Figmaをいじって、使う色や余白等のデザインに関する大まかな方針が決まったあとは、コンポーネントをどんどん実装しつつ、他の人が作ってくれたモックに、作ったコンポーネントを導入して置き換えていく作業を担当していました。

どんなサービスを作るのか議論する際に、とくに僕が意識していたのは、「実際に使われるサービスにしたい」ということです。上でも書きましたが、情報を集めるための場所を用意したとしても、継続的に情報が入力・更新され、どんどん蓄積されていくような状態までもっていきたいなと思っていました。

何を作るのかについてはいろいろと考えたものの、完成させることが目標のハッカソンとしては、あんまりうまく行かなかったなという印象です。UIライブラリは僕が一人で作りましたし、講習会サービスも設計に時間をかけすぎた結果バイブコーディングで無理やりそれらしいものにする、という感じになってしまいました。また、Web開発が比較的初心者の人をサポートする余裕が無くなってしまったのもかなり悔しいです。

次回への反省としては、ちゃんと対面で集まって話し合いをしましょう、開発開始前に何をつくるかちゃんと話し合っておきましょう、という2点です。

みんな忙しいのは分かり切っているので、早めに動きましょう。

y_33550336

アイコンのデザインと、バッジを生成したときの見た目が大丈夫そうかに少し関わりましたー！
今回具体的な実装はAIになり自分は課金をしていなかったので見守る係になってしまいましたが、実際に初めて本格的にAIコーディングをしている人を見てその使い方の上手さに驚かされました…！
最終的なゴールを見失わずに、どうやったらそこにたどり着くことができるかを一緒に考えて、必ず認識の齟齬が生まれないように常にどこまで理解しているかを確認することが大切なのだと感じました
これは人間同士のコミュニケーションでもお互いに理解度をしっかり把握して、考えていることや持っている情報を交換することが重要だと改めて思ったので、チームメンバーとの報連相はもちろんのこと、AIとの関わり方も同じようにすればうまくやっていける(いけた)のではないかなーと思いました
正直、ここまでしっかりターゲットを明確に決めてどのようなプロダクトがユーザーにとって快適なものになるか、ということについて考えたことがなく、仕様書についてこんなにも議論したことがなかったので個人的に新鮮で難しい経験でした…
それぞれが思う「よいサービス」というものが微妙に違うこともあるのかなかなか意見がまとまらず、あまり自分がうまく参加することができなかったので少し悔しかったです
ただ、こういう失敗もよい経験になるはずであり、AIの活用方法などいくつかの学びを得ることもできたので、今回のハッカソンに参加できてとても貴重な機会でした！

Ida-ji

講習会の事情を元に案出しをしたり、日程調整などのマネジメントを行いました。
良い開発か良くない開発かで言うと、間違いなく良くない開発でした。私が実装において何もできず無力だったことが何より悲しかったです。
チームメンバーで日程が中々合わなかったり、対面で会って話し合っても目指す方向性を中々決めきれなかったことが要因だと思います。やっぱり言語化をして相手にちゃんと伝えることが重要だと思いました。
言い訳をすると、現在のtraPの講習会システムがあまりにも複雑すぎるのもありました。どこから手を付ければ良いのか分からなかったです。それでも、チームメンバーなりに話し合って良さそうな択を選び続けてこれたのは意義があると思っています。
web制作のモチベは上がりました！これからもtraPのweb制作の分野に携わっていきたいですね。

quarantineeeeeeeeee

AIって使うのムズいですね！コンテキストとかいうのムズすぎてムズいです。今回の開発では、AIへのアクセス状況がメンバーによって違う中で、AIの恩恵を預かりながらも、アクセス状況による体験の差が少ないような開発方法を模索していました。しかし、最終的に時間が足りなくなって、結局はAIを使える人によるバイブコーディング気味で完成まで押し進めざるを得なくなってしまったのが悔しいです。
本当に役に立つサービスはなんなのか、というような議論はとても盛り上がったと感じているし、AIの使いこなし方の知見も、メンバー同士で色々共有することができました。その一方で、マネジメントとしてはまだまだ成長の余地を痛感しています。これからの集団開発では、良いチーム作りのための考え方などにも力を入れていきたいです。

この記事は 夏のブログリレー 31 日目の記事です。

こんにちは、24B のりすりすです。

突然ですが、タイトルの問題を考えてみてください。厳密な問題文も書いておきます。

以下、補足です。

• 数学では $-3^2=-9$ であり、$(-3{)}^2=9$ です。
• JS で console.log(-(3 ** 2)); を実行すれば -9 が、console.log((-3) ** 2); を実行すれば 9 が出力されます。
• Python で print(-3**2) を実行すると -9 と出力されます。

では、結果を予想してみましょう！

↓ スクロールして正解発表 ↓

数式的には -9、演算子の優先順位的には 9 が出力されそうで、迷った方も多いと思います。

お手元に JS の実行環境がある方は、実際に試してみましょう。ブラウザーの DevTools の Console から実行してもよいですし、手元のターミナルで Node.js の REPL を開いて実行してもよいです。

さて、正解発表といきましょう。

$ node
Welcome to Node.js v24.19.0.
Type ".help" for more information.
> console.log(-3 ** 2);
console.log(-3 ** 2);
            ^^^^^

Uncaught:
SyntaxError: Unary operator used immediately before exponentiation expression. Parenthesis must be used to disambiguate operator precedence
>

はい。びっくりしましたか？ 正解は、

でした。実はこれ、-9 でも 9 でもなく、構文エラーになるのです。紛らわしい所をあらかじめ防いでいてくれてありがたいですね！

ヒントは優先順位は単項マイナス演算子の方が上と書いてたのにどういうことやと思いましたか？ 実は MDN では「左辺は優先順位 14 になることはできません。」と補足があり、またべき乗のページでは以下のように説明されています。

PHP や Python など、べき乗演算子 (**) を持つほとんどの言語では、べき乗演算子は単項演算子（単項 + や単項 - など）よりも優先順位が高いと定義されていますが、いくつかの例外があります。例えば、Bash では ** 演算子は単項演算子よりも優先順位が低いと定義されています。

JavaScript では、あいまいなべき乗式を記述することはできません。 つまり、基数の直前に単項演算子（優先順位 14、+/-/~/!/++/--/delete/void/typeof/await）を置くことはできません。 これを行うと、SyntaxError が発生します。

例えば、-2 ** 2 は Bash では 4 ですが、それ以外の言語（Python など）では -4 です。これは JavaScript では演算子が曖昧であるため、無効な操作です。意図を明確にするには、いずれかの辺を括弧で囲む必要があります。例えば -(2 ** 2) のようにします。

べき乗演算子 (**) - JavaScript | MDN

べき乗演算子 (**) は、1 つ目のオペランドを 2 つ目のオペランドでべき乗した結果を返します。これは Math.pow() と同等ですが、オペランドとして長整数も受け入れます。

MDN

この仕様を既に知っていたという人は、是非コメントで伝えてください。実は過去に Twitter で同じクイズを出題していたのですが、245 票のうち正解していたのは 38 票だけでした。

JavaScript クイズ！

console.log(-3 ** 2);

の出力は？

— 🐿りすりす/TwoSquirrels🐿 (@TwoSquirrels) November 14, 2024

こういうプログラミング言語に関するマニアックな知識って、面白いですよね。そんな面白さを皆さんにも共有したくて、クイズ形式の記事にしてみました。

最後までお読みいただきありがとうございました。それでは、また次の記事で会いましょう！ またね！

明日のブログリレーの投稿者は @uni_kakurenbo です。お楽しみに！

この記事は、2026年の1-Monthon 4班のブログです。
最終発表では新入生賞をいただくことができました。ありがとうございます！

ゲームについて

プレイリンク

unityroomで公開しています！

てんてこモアイランド

モアイが次々と出してくるミニゲームをクリアしていくマルチタスク型ゲーム!自分だけのモアイ編成を見つけてハイスコアを目指そう!

unityroom田中次郎

概要

モアイのお世話をしながら、次々来るミニゲーム（約30種類）をさばいてお金を稼ぐマルチタスク型スコアアタックゲームです。編成したモアイの個性をもとに様々なミニゲームが次々とやってくるので、戦略性や素早い判断が求められます。モアイたちの機嫌を損なわずに大金持ちになろう！

ゲームの流れ

編成画面には様々な個性をもったモアイがおり、ここで自分に合った組み合わせを作れます

ゲーム画面ではモアイが吹き出しを定期的に出すので、それをクリックすることでミニゲームを開始できます。ミニゲーム失敗したり、吹き出しが出たまま放置しすぎたりするとライフが減少し、ライフがすべてなくなるか100秒経過するかでゲーム終了となります。

リザルト画面ではスコア情報の他に、プレイヤー名を入力することでランキングに登録することができます

開発の流れ

メンバー

• watapro26B：プログラマー、リーダー
• ita：プログラマー、サブリーダー
• Oe：プログラマー
• 9key：プログラマー
• onkyonin：プログラマー
• son：グラフィッカー

準備期間

今回の1-Monthonのテーマである「あい」と「まい」に関して案出しを行ったところ、「モアイ」というインパクトのあるテーマが浮かんだので、モアイに関するゲームを作成することに決めました。さらに、「モアイ」に関するゲーム案を考えた結果、次のような要素を持つ「モアイの欲求も満たし、動かないように説得するゲーム」を採用しました。

• 次々の出てくるミニゲームを攻略するマルチタスク型ゲーム
• 生き残った時間とクリアしたミニゲーム数でスコアを決定
• それぞれのモアイに個性がある
• ガチャでモアイを入手できる(実装が厳しいので最終的には没になった)

また、これを実装するにあたって

• モアイのパラメータ(個性)や必要なプログラム、グラフィックの洗い出し
• メンターのどぐえぐさんのアドバイスを参考に実装の優先順位の決定
• UI、シーン遷移やクラスなどの設計

といったことを行いました。

そのほか、メンバー間で情報共有などを行う機会を確保するために、月・金に定例会を行うことも決めました。

開発開始～中間発表前

中間発表までに、ゲームとして最低限遊べる、ゲーム一連の流れを実装することを目標に開発を進め、実際にゲームの基本システムの実装しきることができました。また、中間発表直前にタイトルを、今回の1-Monthonのテーマに関連して、それぞれモアイ、てんてこ舞いからなる「てんてこモアイランド」に決めました。

中間発表後～最終発表前

ランキングを実装するとともに、ミニゲームをひたすら作っていました。また、最終発表二日前に全体の難易度・バランス調整を行いました。

制作を振り返って

よかったこと

• メンバー間でしっかりとコミュニケーションがとれた
  • MDに相談したい内容を共有しておき、話し合いが必要な内容は週２で開かれる会議で議論できるようにしていた。

課題・改善点

• 初心者向けのモアイを選ばないとすぐにゲームオーバーになる
  • 最初は風邪モアイ(ミニゲームが出てこないので楽になる)、プカオモアイ(ミニゲームの難易度、頻度ともに低め)を編成に組み込むよう誘導できるとよさそう
  • チュートリアルなどを入れて難易度感や操作感をつかめるようにしてもいいかも
• ミニゲームの操作方法がわかりずらい
  • ドラッグするオブジェクトとクリックするオブジェクトが区別しにくい
    • ドラッグするオブジェクトを赤枠、クリックするオブジェクトを青枠で囲むなどの区別が必要そう

これから

第23回Game^3や工大祭に出展予定です。
これまでには上で挙がった課題を解消していきたいな...

感想

watapro26B

1-monthonでは、リーダー兼プログラマーを担当していました。
　リーダーとしてはMVPパターンを利用したクラス設計を行い、1-monthon開始直後はひたすらイシューを投げていました。一方で、メンバーが非常に優秀で、リーダーとしてメンバーをまとめるなどの仕事はあまりありませんでした。プログラマーとしては、モアイの吹き出し表示やランキング表示の実装、UnityRoomへのゲームの投稿を行いました。
　最後の十日間ぐらいは諸事情によりほとんど開発に参加できなかったのですが、副リーダーのitaさんをはじめとして、ゲーム内容の充実のために大変頑張っていただきました。本当に感謝しています。
チームで期間1~2カ月のプロジェクトに取り組む経験やクラス設計を行った経験はほとんどなかったのですが、優秀なメンバーに囲まれて非常に多くのことを学べたと思います。
　メンバーの皆さん本当にありがとうございました!

ita

プログラマー兼副リーダーを担当しました。
ミニゲームの進行を制御するシステムを作ったり、ミニゲームを大量生産したりなんなりしました。春ハッカソン時の脳筋実装から脱却してMVPパターンでコーディングしたり、データベースを利用したりするなどでき、学びの多い充実した一ヵ月でした。
皆さん一ヵ月間ありがとうございました！

Oe

今回プログラマーとして参加した26BのOeです
開発期間前半は編成画面だったりをいじって、後半ではいろいろバグを直したりミニゲームを作ったりしていました
後半はあまり開発に参加できていなかったりしてたので特にミニゲームを大量に作ってくれたみんなにはただ感謝です
今回作ったゲームは大量のミニゲームが出てくる関係上、初見だとどうしても難しくなってしまいました。(ずっと開発していた私達にとっても正直げろむずでした)ただ、ある程度慣れてくると非常に面白くなってくるのでここまで読んでくださった方は暇なときにでも遊んでみてください！
最後に、皆さん一ヶ月ありがとうございました！

9key

プログラマーとして参加した9keyです。ハッカソンは今回が初めての参加だったため、チーム開発に参加するにあたっての不安もありました。しかし、チームメンバーが私にも分かるようなとても丁寧な指示を出してくれたため、無事完走することができました。ハッカソン期間中の早い段階で、メンバーがクラス設計やミニゲームのテンプレートを用意してくれていたので、自分の作りたいミニゲームを実装することに注力できてとても楽しかったです。チームメンバーのみなさん、1か月間ありがとうございました。

onkyonin

今回プログラマーとして参戦したonkyoninです。
今回予定の都合もあってあまり開発に全力を注ぐことはなかなかできませんでした。でも実際に人と力を合わせて開発をするほどの規模のゲームを作るために、どのような工夫をしなければいけないのかを知る機会となりました。
(実際OOPが初耳で、クラス設計のfigmaを見てinterface？model？わけわからんというところから勉強を進めながらちょっとずつやっていくことは楽しかったです。)
本当にチームのみなさんありがとうございました。

son

グラフィックを担当しました。
私が普段描くものは人間の女の子なので、モアイや背景素材を描くのは新鮮でした。
チームで作品を作るのは春ハッカソン以来で、その時はタスクの大部分を先輩に任せてしまいました。今回はグラフィック担当が私一人だったこともあり、自分の仕事を独力でこなす経験ができました。これは今後の制作にも生きるのではないかと思います。
全体的に楽しい一ヶ月でした。皆さんありがとうございました。

おはようございます。組版の話をしましょう。
きょうは共通テストみたいな組版を試みようと思います。
まず本家を調査して， 次に再現します。
※数式などの込み入った話は後編に回します。

§1. 本家を調査

模倣するにあたり， まず最初に本家を調べましょう。
大学入試センターは， 大学入試共通テストの表紙の参考イメージをウェブ上で公開しています。
例えばこれは， 令和 3 年度の共通テストの国語の表紙 （参考イメージ） です。437 686 バイトあります。これをダウンロードして， 詳しく解析します。

§1.1 PDF の中身

PDF ファイルの中身は以下のような構造になっています。

① PDF のバージョン指定
② オブジェクトの列挙
③ オブジェクトの場所やファイル情報
④ ③がどこから始まるのかの情報

ダウンロードした PDF をバイナリエディタで開くと， 一番最初は %PDF-1.6 で， 確かに①のバージョン指定になっています。このあと第 16 バイトからしばらくオブジェクトの列挙が続いています。

さらに一番下までスクロールすると，

startxref
437262
%%EOF

という部分があります。これが先ほどでいう④にあたります。③は 437 262 バイト目から始まっている， ということです。
③の部分は 2 つの形式があり， xref で始まる独自の構造を持ったクロスリファレンステーブルを使用するか， 通常のオブジェクトを用いて指定するクロスリファレンスストリームを使用することができます。オブジェクトは， オブジェクト番号， 世代番号， obj， 中身， endobj という構造を持っており， 今回のファイルの③は 47 0 obj… で， 2 つの数と obj という文字列で始まりましたから， オブジェクトです。したがって， この PDF ではクロスリファレンステーブルではなくクロスリファレンスストリームが使用されていることがわかります。

47 0 obj
<</DecodeParms<</Columns 5/Predictor 12>>/Filter/FlateDecode ... >>
stream
...
endstream
endobj

§1.2 クロスリファレンスストリーム

PDF のオブジェクトにはいくつかの種類があります。

• boolean… 真と偽の 2 つのみ。
• 数… 数値を直接書く。
• 文字列… ( で始まり ) で終わる。文字列中に丸括弧が含まれる場合は \ を用いてエスケープする。
• 配列… [ で始まり ] で終わる。要素は空白区切りで並べる。
• バイナリ… < で始まり > で終わる。中に 16 進数を書く。桁数が奇数の場合は末尾に 0 を補って解釈される。
• 名前… / で始まる。ASCII 文字を並べたものだが， 一部の ASCII 文字は使用できない。
• 辞書… << で始まり >> で終わる。中身がなくてもよい。中にキーと値を交互に並べる。ストリームが続く場合があり， このときは endobj の前に stream， ストリーム本体， endstream が入る。
• 参照… オブジェクト番号， 世代番号， R をスペース区切りで書くと， そのオブジェクトへの参照になる。

さて， 今見ている 47 番のオブジェクトは << で始まり >> で終わっているため， 辞書です。その中に /Info 43 0 R とありますから， 文書の情報は 43 番のオブジェクトにあります。また， /Root 7 0 R とありますから， 7 番のオブジェクトが階層構造のトップに存在することもわかります。したがって， これらのオブジェクトがこのファイルのどこに存在するのかを調べる必要があります。そこでこのオブジェクトのストリームを読まなければなりません。
第 437 475 バイトからがストリームです。/Length 166 は， このストリームが 166 バイトであることを意味しています。/Filter/FlateDecode は圧縮方法が Deflate 圧縮であるということです。まずはこの圧縮を解除する必要があります。圧縮方法の詳細はここに書いてあります。

このストリーム 166 バイトのうち， 最初の 2 バイトはヘッダ， 最後の 2 バイトはチェックサムですから， その間の 162 バイトの部分が， 上記のリンク先に書かれたアルゴリズムで圧縮されている部分になります。

圧縮を解除すると， 288 バイトのデータが得られます。ここで先ほどの辞書には /W[1 3 1] とあります。これは， 各オブジェクトに関するデータが 3 つの要素からなり， 第 1 の要素と第 3 の要素は 1 バイトずつ， 第 2 の要素は 3 バイトからなる， という意味です。では 5 バイトごとに区切って読めばいいのかというと， そうではありません。/DecodeParms<</Columns 5/Predictor 12>> に注意が必要です。Predictor が 12 ですから， PNG 予測アルゴリズムにより， 各データは 1 バイトずつ増えていることを意味します。したがって， Columns の 5 より 1 つ多い 6 バイトに区切って読まなければなりません。さらに， このデータはそのまま用いるのではなく， 今までのデータの累積和 （mod 256） を取らなければ値が読めません。

例えば 7 番について調べましょう。まず最初に， 6 バイトのうちの各バイトについて， 0 番から 7 番までの 8 つ分の値を， 全部足します。最初の 1 バイトは 2 が 8 回足されて 16 になりますが， これは関係のない部分です。次の 1 バイトは 1 になります。このオブジェクトが圧縮されていないことを意味します。 続く 3 バイト （4603） がその先頭の位置， 最後の 1 バイト （0） が世代番号です。したがって第 4603 バイトからは 7 0 obj という記述があるはずです。

実際， 第 4603 バイトに移動すると， 7 0 obj があります。

7 0 obj
<</Metadata 4 0 R/OpenAction 42 0 R/PageLayout/OneColumn/Pages 3 0 R/Type/Catalog>>
endobj

このオブジェクトも辞書です。ページ数などの情報は 3 番のオブジェクトにあります。

では今度は 43 番も調べましょう。今度は第 437 071 バイトを参照します。

43 0 obj
<</CreationDate(D:20200515103513Z)/Creator(EdianWing) ... >>
endobj

この辞書には Creator という項目があり， 中に EdianWing とありますから， 共通テストは EdianWing で組版されていることがわかりました。NEC ネクサソリューションズの出していた， Windows 用組版ツールです。

§1.3 ページ情報

ページに関する情報を調べましょう。先ほどのクロスリファレンスストリームを見て， 足し算をすると， 今度は第 1 要素が 2 になります。このオブジェクトが圧縮されていることを意味します。第 2 要素が 44， 第 3 要素が 1 ですから， 3 番のオブジェクトは， 44 番のオブジェクトについたストリームのインデックス 1 にあることになります。したがって， 今度は 44 番を探す必要があります。
これは第 16 バイトから始まっています。ストリームが圧縮されているため， 解除すると， 以下のようなものが得られます。

8 0 3 154 <</BleedBox[0 0 516 729]/Contents 13 0 R/CropBox[0 0 516 729]/MediaBox[0 0 516 729]/Parent 3 0 R/Resources 9 0 R/Rotate 0/TrimBox[0 0 516 729]/Type/Page>><</Count 1/Kids[8 0 R]/Type/Pages>>

最初の部分に， どのオブジェクトがどこから始まるかに関する情報があり， そのあとにオブジェクト列挙部分本体があります。8 番のオブジェクトがオブジェクト列挙部分先頭から， 3 番のオブジェクトがその 154 バイトあとから始まることがわかります。

ページ数は 1 ページで， そのページの情報は 8 番のオブジェクトにあります。8 番のオブジェクトは今見たストリームの前半部分で， BleedBox， CropBox， MediaBox， TrimBox はいずれも B5 サイズに指定されています。なぜ同じ値を 4 回も書くのかというと， 意味が同じではないからですが， その話は割愛します。

このページに必要なリソースのデータは， 9 番のオブジェクトを参照する必要があり， またページの中身は 13 番のオブジェクトにあります。前者は圧縮されており， これは 45 番のオブジェクトについたストリームのインデックス 0 にあります。ストリームはファイルの第 324 バイトから始まります。後者は圧縮されていません； ファイルの第 4737 バイトから始まります。

まずは 9 番から：

9 0 <</ColorSpace<</Cs9 12 0 R/DefaultCMYK 12 0 R>>/ExtGState<</GS1 18 0 R/GS2 19 0 R>>/Font<</F1 14 0 R/F2 15 0 R/G1 10 0 R/G2 11 0 R/G3 16 0 R>>/ProcSet[/PDF/Text]>>

フォントの部分を調査しましょう。F1 が 14 番， F2 が 15 番， G1 が 10 番， G2 が 11 番， G3 が 16 番にあり， 合計で 5 つのフォントを含んでいます。これらはすべて 46 番のストリームに圧縮されており， G1， G2， F1， F2， G3 の順番で出現します。

これらのフォントが何者か調べます。まず G1 は DFHSGothicPro6N-W5-Identity-H という名前で， これは DF 平成ゴシック体 Pro6N W5 です。G2 は DFHSMinchoPro6N-W3-Identity-H という名前で， これは DF 平成明朝体 Pro6N W3 です。F1 と F2 は名前からは何のフォントだかわかりませんが， おそらく作ったのでしょう。G3 は HeiMinGaiji-W3-Identity-H ですから平成明朝の外字です。

§1.4 中身を調査

ページの中身 （13 番） を見てみましょう。これは第 4737 バイトから始まるのですが， 中身が <</Filter/FlateDecode/Length 1847>> であり， 実際にはストリームのほうに本体があります。
ストリームの圧縮を解除すると 312 行の長ーい文字列が出てきます。ここに， このページを描画するための指示がすべて入っています。最初に描画するテキストは， ゴシック体のテキストです。

/G1 1 Tf
10 0 0 10 88 545.7001 Tm
.99 Tc

となっていて， フォントサイズは 10 ポイントであることがわかります。さらに， 文字と文字の間に 0.99 の間隔があいていますから， おそらくこれは「注意事項」の部分です。

その次のテキストには，

/G2 1 Tf
8.197 0 0 10 71.4016 525.7001 Tm

とあるので， y 座標がちょうど 20 減少しています。したがって行送りは 20 ポイントです。

次に， 注意事項の 4 番に出てくる $\boxed{\text{10}}$ がどのようになっているのかも調べましょう。

1.134 w
348.233 397.567 34.134 -16.134 re

線の幅は 1.134， 箱の寸法は横幅 34.134， 高さ 16.134 です。

これで必要な情報はほとんど揃ったので， 再現を始めます。テキストの具体的な位置は， §2 で述べます。

§2. 再現

版面のサイズを B5 にします。フォントは DF 平成明朝 W3 と DF 平成ゴシック W5 を使用します。

§2.1 表紙

表紙から作ります。表紙には以下の項目が記載されます。

• 「試験開始の指示があるまで， この問題冊子の中を見てはいけません」（枠で囲む）
• 科目名（22 ポイント）
• 満点・時間
• 注意事項
• ページ番号（二つ）

まず第一の注意書きを書きましょう。(103, 642.7) の位置から始めます。書いたらそこに枠をつけます。左下は (97.8, 638.52) で， 幅 320.4， 高さ 15.96 です。

このようになります。

次に科目名を大きく書きます。(228, 584.14) に中央揃えです。

満点と時間は， 大きい括弧の中に 2 行に分けて書き，科目名の右側に配置します。右揃えにし， 満点は (433, 598.7)， 時間は (433, 578.7) に揃えます。

次に注意事項です。「注意事項」という文字列は， 文字と文字の間隔を 10 ポイントにします。(88, 545.7) から開始します。注意事項の各項目は字下げに注意が必要です。

解答欄のマーク方法の例も表示しましょう。

本家では 10 番の解答欄に 3 をマークした図ですが， ここは乱数で変えるようにしました。

注意事項を列挙したら最後にノンブルです。「1」と中央揃えで (258, 60) に書き， 前後に em-ダッシュを入れます。

右下に管理番号みたいなもう一つのノンブルも入れましょう。

この番号は 10 ポイントではなく 8 ポイントにします。

これで表紙ができました。

§2.2 本文

表紙だけでは物足りないので中身も作りましょう。

ページを改めて， 再び大きな文字で科目名を書きます。(258, 626) に配置し， 中央揃えにします。

科目名の下に， 解答番号が何番から何番までなのかを示します。「解答番号」という文字列の左下は (193, 595) です。

そのあとから設問を並べます。後ろに配点も書きます。

最後に表紙と同じ要領でページ番号をつけます。

§3 今後やること

2 ページの組版再現でしたが， 組版ソフトを用いたわけではありません。実は文字の配置は自動計算ではなく， すべて手でポチポチやっています。

まずはこの位置の計算などを自動化する必要があります。

その次に， 数式にも対応できるように拡張します。

その二つの作業を， 後編に記すことにしましょう。

ということで前編はここまでです。後編がいつ出るかは未定ですが， おそらく冬になると思います。お楽しみに。

この記事は 夏のブログリレー 30日目の記事です。

こんにちは。Cd_48です。普段は作曲をしたりサウンドデザインに明け暮れ変な音を錬成したりしています。

Cd

Listen to Cd | SoundCloud is an audio platform that lets you listen to what you love and share the sounds you create.

SoundCloud

世はまさに

Twitterを見ていると、個人でVSTプラグインを作成している人を多く見かけるようになりました。
全てがそうかはわかりませんが、ほとんどがAIを駆使して作られたものでしょう。
とりあえず実際に動くものを作ることが簡単にできるような時代になったということですね。

ならば、私のようなプログラミングの知識もWebやアプリの知識もほぼゼロな人でも、欲しい機能をもったツールを自作できるんじゃないかということで、ChatGPTを使っていろいろやろうと思います。

作りたいもの

今回はWavetableエディターを作ってみます。
権利周りの話がめんどそうなので配布は今のところ考えていません。欲しくなったらAIに頼んでください

私はソフトシンセサイザーが好きで、楽曲制作ではよくVitalやPhase Plant、Currentといったシンセサイザープラグインを使います。

こいつらはそれぞれ独自の強みを持っていますが、共通しているのはどれもWavetableを扱えるシンセだということです。

Vital、CurrentのWavetable編集機能はとても優秀ですが、Phase Plantほどの自由性がありません。
ですが、結局Wavetableをいじって音を作るのであれば、そのWavetableを自作してしまえばいいわけです。
どのシンセもwavファイルをWavetableとして読み込めるので、そのwavファイルを編集するツールを作ろう、というのが動機です。

「VitalにもWavetable出力できる機能あるからそれ使えばよくね？」とこれを書きながら思ったのですが、Vitalはwavを読み込んだとき、振幅と位相をフリーハンドで編集できないんですよね。

しかし今回できたツールではそれを克服しているためこの時点で使う価値があります。やったね
それに、大元の波形編集機能さえできてしまえば追加でいろいろな機能を持たせられるはず（実際そうでした）と考えていたので、私のAIとキーボードをを叩く手は止まりませんでした。

作ってみよう、否、作らせよう

最初は様子見程度に考えていたので、ChatGPTの無料プランで作り始めました。
本当にアプリの類を作ったことがなかったので、まずは設計？とやらを一緒に考えるところから始めます。

これがこのアカウントでの初めての会話で、挨拶も何もなしに始めてしまいましたが、普通に自分がやりたいことを大体理解してくれました。すごい

しかも、なんとなく悩んでいた「アプリとして作るのか、webで動くようにするのか」という点についても、何も言わずとも提案してくれました。
書きぶりからどっちでもいけそうですね。今回は完全に個人的な使途しか考えていないのでアプリにします。

使用する技術の選定までやってくれました。が本当に知識がないので言いなりになるしかないです。
挨拶もなしに会話を始めたやつに最善の提案をするか？と当時の私は疑う余地もなく、そのまま作り進めてもらうことにしました。

そこから10分もせずに初版のアプリが完成しました。すご

見た目がちょっとイマイチですね。あと名前もなんか普通。
ですがとりあえず機能がしっかりしていればいいので、見た目はいったん後回しです。

とはいえ見てわかるとおり、SerumやVitalのような振幅と位相の編集画面はなく、できるのは正規化、DC除去、あと謎の端点を滑らかにする機能のみ。
無料ならこんなもんかと思いつつ、ここから欲しい機能の実装をお願いしていきます。

機能を増やす

なんやかんやあって振幅と位相の編集ができるようになりました。

画面下部に見えますが、なんと最初は一つ一つの倍音にゲインを数値で入力して編集するように実装していました。
1フレームに512倍音、それが最大256フレームもあるwavetableの倍音一つ一つをちまちま編集していたら日が暮れます。

Serum、Vitalのような編集画面にして！とお願いしたはずなんですが、まあ有料プランにしていないのが悪いかと思うことにしました。詳しく仕様を指定したらちゃんと作ってくれたのでOKです。

あと地味にうれしいポイントとして、振幅・位相表示に線形スケールと対数スケールを選べるようにしました。
こういう機能をお願いするだけでサクッと作ってくれるのはありがたいですね。

デバッグもしてくれる

ここで試しにwavetableを書き出してみたのですが、書き出したwavetableをSerumに読み込んだところきれいに鳴らず。

このエラーについてもChatGPTに聞いてみました。

確かにSerumのwavetableは、wavetable positionの上限が256以下のものもありますね。（Default Shapesは9）
さらに、Serum2でのwavetable編集UIをみると、wavetable positionが256まであるwavetableでも、実際には少ないフレーム数のwavetableを滑らかにつないで256フレームにしているものもあります。

Vitalだとフレーム数を気にしないので盲点でした。

VitalやSerumで意図しない挙動が起きたら、とりあえずマニュアルを見たり、ほかにも実験をして自力で原因を突き止める癖があり、今回のエラーも15分くらい自力で格闘していました。
ですが、これもAIに聞いたらええやんと気づくのは時間の問題でしたね。

ひとまず問題点が洗い出せたので、エラーの解決をお願いしようとしたところで利用制限に達してしまいました。

金の力

これから機能を追加すれば実用的なものにはなりそうだけど、ちょっと開発に時間がかかりすぎるな～と思っていた矢先に、新モデル「GPT-6 Astra」が発表されました。
それに加え、課金プランであるPlusユーザー以上はAstraのリリースまで毎日利用制限リセットするよみたいな情報を見た気がしたので、上位モデルを使わずにプロダクトを諦めるのはなんか違うかと思いとりあえずPlusまで課金してみました。

課金してから半日くらいかけてこんな感じになりました。

上の画面は編集ウィンドウで、Vitalのような波形編集をノードベースで行えるようにしています。
これにより、Vitalのノブの機能(Inharmonic Stretchや、Spectral Phaserなど)を一度に複数かけられるようにしました。嬉しい！

他にも、DistortionノードによるSoftClip,HardClipや、多種多様なFilterなど基本的な波形編集エフェクトも実装されました。

課金してからは若干賢くなったような気がします。
UIはどうしても微妙になりますが、欲しい機能を即座に理解してくれるし、それの実装もスマートに感じました。

実際書き出したwavetable（実際にはwavファイル）はこんな感じです。

Alternating Harmonics edited

0:00

/0:02

1×

元のwavetableは、VitalのGlorkglunkフォルダにおそらく元から入っているAlternating Harmonicsです。ここに貼ると二次配布とかになりそうなので自分で鳴らして比較してみてください。

ふりかえり

開発には結構時間がかかった気がします。
開発初期の会話の時点で必要そうな機能のリストアップをしてくれていたので、一つ一つの実装を詳細にお願いするより、いったんできるところまでやってとお願いした方が時短になったかもしれません。

とはいえある程度は実用的なものが作れたので満足です。
個人で、しかも開発の知識不要でここまでできるとなると、楽曲制作のスキルアップにはいろんな手段を取れるようになるな～と思いました。

では

今月は気が向いたら開発の続きをしてみます。
気になった人はやってみる価値があると思います！

明日のブログリレー担当者は@HokubuRailway,TwoSquirrelsです。お楽しみに！