tmp

岐阜：射美、竹雀、氷室

徳島：LED夢酵母、三芳菊、旭 若松、芳水、鳴門鯛

セブン

カフェラテ レギュラー：300ml 213¥ 0.71

ファミマ

カフェラテ深煎り焙煎：360ml 248¥ 0.68

カフェラテ レギュラー：240ml 178¥ 0.74

DOUTOR：270ml 236¥ 0.83

ローソン

MtRカフェラッテ：240ml 190¥ 0.79

猿田彦：220ml 208¥ 0.94

やはり人類は友人で集まってやることに困っている。

これに対して適切な回答を出せるソリューションを作りたい。あるいは作ってほしい。

ログ

デバッグ

セキュリティ

API定義

rest

バリデーション

ルーティング

アーキテクチャ

concern

マイグレーション

DB定義

非同期タスク

スケール性

ーーー

code:ebnf

# いつものプログラムみたいにかけるシェル

delimiter = " " | "\n" | ","

if = "if" expr "{" stmt* "}" ( "else" "{" stmt* "}" )?

foreach = "foreach" "(" var "of" expr ")" "{" stmt* "}"

assign = var "=" expr

hash = "{" expr* "}"

fun = "fun" SYMBOL "(" ")" "{" "}"

var = "$" SYMBOL

fun_call = SYMBOL expr*

ifexpr = expr "?" expr ":" expr

literal = "true" | "false" | "null" | "eof" | NUMBER | STRING

code:text

標準入力と標準出力

pipe = array | channel "|" channel

direct = expr ">>" channel

ライブラリで書くような部分では基礎として Go のチャンネルのような仕組みを持つ。

ユーザーが書くような部分では Enumerable をパイプで繋げて使う。

stdin | map(lam -> $it * 2) | stdout

even = (->

@in | filter(lam -> x % 2 == 0) | @out

)

counter = (->

count = 0

-> count += 1

)()

sum = (->

result = Channel()

total = 0

@in.onReady(() => total += @in.wait())

@in.onClose(() => total >> result)

return result

)

function range(start, end) {

result = Channel()

loop {

start -> result

if end <= start { break }

start.increment()

}

return result

}

range(1, 100) | even() | sum() | stdout

function merge(channels) {

result = Channel()

close_count = 0

foreach(c of channels) {

c.onReady(() => c.wait() >> result)

c.onClose(() => {

close_count++

if channels.size() <= close_count { close(result) }

})

}

return result

}

ch1 = range(1, 100) | filter(x => x %2 == 0)

ch2 = range(1, 100) | filter(x => x %2 == 1)

デッドロック

a = Box.new(1)

b = Box.new(1)

// 単純な排他制御だとデッドロック

ch1.onHoge(() => a.update(v => v + b.value))

ch2.onHoge(() => b.update(v => v + a.value))

// MVCC なら update でもデッドロックは起きないが、厳密な直列化ではなくなる

// トランザクション分離レベルにおいては、Read Committed

// a がちゃんとインクリメンタルされるか微妙

ch1.onHoge(() => a.set( a.get + 1 ) )

ch2.onHoge(() => a.set( a.get + 1 ) )

ch1.onHoge()

ーーー

１人１人が自分の目的のために動いていて、それが複雑に交差し作用するゲーム。

その中の１人としてプレイヤーは自由に作用を働きかける。

テキストゲームでええやろ。

人物の顔画像ぐらい。

どうやって目的を設定して、どう解決していくか、どうドラマに仕上げるか

仮説

困りごとがあって、それが他キャラの作用によって解決するとドラマが生まれる説

困りごとを解決した影響として、他キャラに作用がかかると面白い説

プレイヤーが斡旋やマッチングをする説

困りごとを相談にくる

適切な人を斡旋する

プレイヤーが政治家をする説

困りごとを調査する

建物や制度で解決する

色々な人に影響がでる

そこに支持率とかあっても良さげ

ホームズの推理小説を複数持ってきて絡めたら良い感じの群像劇できる説

職業が同じ人を同一人物にしたり

場所を重ねさせたり

「こういうことやりそうだなぁ」ってのまとめて１人にしたり

群像劇のパブリックドメインから設定を持ってこれんかな？

ムズイっぽい

どれがPDなのか判定がちょいムズイ

検索で群像劇のPDがヒットしづらい

ストーリー仕立てじゃなくて、無造作にランダムに交差

グランド・ホテル

病気で余命が幾ばくかで金を使い切ろうとする陰キャの星クリンゲライン

長い間、プライジングが経営する工場で低賃金で働いてきた。（恨みが募っている）

病気にかかり余命が少ないことが判明し、財産を使い切ろうと高級ホテルにやってきた

カイゲルン男爵と仲良くなり、その繋がりでフレムヒェンとも仲良くなる

フレムヒェンとダンスを楽しんでいる所をプライジングに邪魔され、恨みを爆発させる

カイゲルン男爵が味方してくれ仲を深める

カイゲルン男爵が金に困っていることを知る。男爵がギャンブルをやりたがる

ギャンブルでボロ儲けして上機嫌になり酔い潰れる

酔って落とした財布を男爵が盗もうとするが、クリンゲラインが必死に探す姿を見て男爵はサイフを盗むのをやめる

男爵はプライジングの客室から財布を盗もうとするが、見つかってしまいプライジングに殺されてしまう。

悲しむクリンゲラインとフレムヒェン

男爵が金に困って盗みを働いたことと、フレムヒェンが金に困っていることを聞いて「金は出すから一緒に旅しよう」

フレムヒェンも喜んでついていく。END

ジャイアンみたいな社長のプライジング

マンチェスター社との提携？に失敗する

もう一つの会社との合併はマンチェスター社との提携が要だった。

合併しないとプライジングの会社は経営がよろしくない

追い詰められたプライジングは嘘をついて合併してしまった。

自棄になったプライジングはタイピストのフレムヒェンが美人だったから飲みに誘おうとする

そしたらクリンゲラインがまとわりついているし、なんか文句言ってくる

フレムヒェンと金で体の関係を持とうとしたところに男爵が盗みに来て激高して殺してしまう

警察に連れてかれる

金がなくて追われている客室荒らしだが紳士なガイゲルン男爵

グルシンスカヤの真珠を盗もうとして部屋に忍び込もうとする過程で惚れてしまう

グルシンスカヤから盗むのやめて、クリンゲラインから盗もうとしたけどやめて、

プライジングから盗もうとして殺されてしまう

バレリーナのグルシンスカヤ

なんか最近、客のウケも悪いし最悪だとヒスってたら男爵といい感じになる

男爵が殺されたのも知らずに待ち合わせに向かってEND

タイピストのフレムヒェン

ーーー

花見 Hanami

code:ebnf

stmt = hoge　"。"

if = "もし" expr "ならば" expr ( "違えば" expr )?

// 手続き：「A」と「B」を足す：ここから　ここまで

fun_def = "手続き：" prog! "：" expr

var_def = expr "を"　SYMBOL "とする"

iterate = expr "の中身を" SYMBOL "として" expr "繰り返す"

for = SYMBOL "を"　expr "から" expr "まで"

import = string "を" ( string "として" )? "取り込む"

package = "パッケージを" SYMBOL "とする"

expr = hoge

block = "ここから" stmt* "ここまで"

group = "（" expr ")"

string = "「"　　prog! "」"

list = "リスト「" ( expr ( "、" expr )* )? "」"

(list_at = expr "の" expr "番目")

hash = "辞書「" ( expr "は" expr ( "、" expr "は" expr )* )? "」"

(hash_at = expr "の" expr "を引く")

fun_call = prog!

or =

and =

literal = NUMBER | STRING | "真" | "偽" | "なし" | SYMBOL

throw =

catch =

code:text

// 日時.hn

パッケージを日時とする。

手続き：「$文字列」の日時を作成する：ここから

辞書「」を返す

ここまで

手続き：「＄数値」日の日時：ここから

ここまで

手続き：「＄日時」の日時を「＄数値」進める：ここから

ここまで

// メイン.hn

「日時.hn」を取り込む

「2024/3/25」の日時を作成する

それを今とする

今の日時を（1日の日時）だけ進める

それを明日とする

code:ebnf

// JavaScript, Scala

lambda = SYMBOL "->" expr

lambda = "(" SYMBOL* ")" "->" expr

// Haskell

lambda = "\\" SYMBOL* "->" expr

// Rust

lambda = "|" SYMBOL* "|" expr

// my

lambuda = "fun" SYMBOL* "->" expr

カッコを駆逐して最小限の構文

code:ebnf

expr = ( pair ~ literal )

pair = "pair" expr expr

var_call = "$" SYMBOL

fun_call = SYMBOL expr

literal = "null" | "true" | "false" | NUMBER | STRING | SYMBOL

code:text

let pair a 1

let pair b 2

if pair eq pair $a $b pair print "true" print "false"

fun pair add add pair L $it R $it

fun pair L

if pair? $it

L $it

error "引数がペアではありません。"

カッコを駆逐する構文

code:ebnf

expr = ( if ~ literal )

if = "if" expr expr expr

let = "let" SYMBOL expr

pair = "pair" expr expr

block = "|" expr expr

var_call = "$" SYMBOL

fun = "fun" expr

fun_call = SYMBOL expr

literal = "null" | "true" | "false" | NUMBER | STRING | SYMBOL

code:text

let list pair 1 pair 2 pair 3 4

each pair list print

let each fun

| or pair? $ error "引数がペアじゃないです"

| let list L $

| let callback R $

if let item L $list

| callback item

each pair R $list $callback

null

let last fun

if pair? $

last R $

$

let last_pair? fun

if pair? $

| let right R $

if pair? $right

false

true

false

let push fun

| let list L $

| let value R $

if last_pair? $list

set_r pair $list pair $list value

push pair R list value

map pair list fun add pair $ 1

let map fun

| let list L $

| let callback R $

if pair? $list

if last_pair? $list

pair callback L $list callback R $list

pair callback L $list map pair R $list $callback

callback $list

let drop fun

if pair? $

todo

$

できるだけカッコを消去する構文

code:ebnf

let = SYMBOL ( "=" let )* | list

list = binary_a ( ":" list )* | binary_a

binary_a = binary_b ( ( "+" | "-" ) binary_b )*

binary_b = binary_c ( ( "*" | "/" ) binary_c )*

if = "if" stmt stmt stmt

for = "for" SYMBOL stmt stmt

fun = "fun" SYMBOL stmt

var_call = "$" SYMBOL

fun_call = SYMBOL expr

literal = "null" | "true" | "false" | "[]" | NUMBER | STRING | SYMBOL

// print a = add 1 : 2 : []

my_lisp の構文

code:ebnf

expr = ( list | literal )*

list = "(" expr* ")"

literal = "null" | "true" | "false" | NUMBER | STRING | SYMBOL

関数の引数を一つ限定。制御式も句の数が固定。

code:ebnf

program = expr*

expr = let

let = ( SYMBOL | annotate ) "=" let | equal

equal = compatible ( ( "==" | "!=" compatible )*

compatible = or ( ( "<" | "<=" | ">" | ">=" or )*

or = and ( "or" and )*

and = binary_a ( "and" binary_a )*

binary_a = binary_b ( ( "+" | "-" ) binary_b )*

binary_b = binary_c ( ( "*" | "/" ) binary_c )*

binary_c = stmt ( ( "." | "::" ) stmt )*

stmt = ( record ~ literal )

record = "record" "{" ( SYMBOL type )* "}"

trap = "trap" stmt stmt

raise = "raise" stmt

if = "if" stmt stmt stmt

for = "for" SYMBOL stmt stmt

fun_def = "(" SYMBOL* ")" "->" stmt

block = "(" stmt* ")"

name_tuple = "{" ( SYMBOL ":" stmt )* "}"

tuple = "{" stmt* "}"

unary = "!" stmt

var_call = "$" SYMBOL

fun_call = SYMBOL stmt

literal = "null" | "true" | "false" | NUMBER | STRING | SYMBOL | fun_call

// print (a + (b * c)) + d

annotate = SYMBOL ( ":" type )+

type = fun_type | generic_type | unary_type

name_tuplu_type = "{" ( SYMBOL ":" type )* "}"

tuple_type = "{" type* "}"

generic_type = "(" SYMBOL type* ")"

unary_type = SYMBOL

ーーー

やりたいこと

質問対策

スプラ

ドミニオンメーカー

Sumup

ポルカ

NISA

金曜会

ーーー

多重ディスパッチがややこしいのは継承のせい。

継承は同じ構造を持つデータ型に対して、実装を省略できるのがメリット。

インターフェースは同じメソッドを持つデータ型に対して、実装を省略できるメリット。

つまり、インターフェース（メソッド）とインターフェース（構造）の二つを持てば継承がなくても省略できるのでは？

code:text

interface Animal {

weight Num // 構造（構造体のフィールド）に対するインターフェース

fn eat(Self, Food) // メソッドに対するインターフェース

bark (Fn Str) // 構造に対するインターフェース（構造体のフィールドで関数データを持つ）

}

多重ディスパッチの問題を何も解決してなくて草

多重ディスパッチの問題点は、一つのデータ構造配列に対して一つのメソッドを決定できないこと

一つのメソッドで複数のデータ構造に対応しようとして、重複が起きるから問題になる

重複が起きた時点でエラーにしてしまう

本当は一つに決定できるケースもエラーにしてしまうが、色々マシになるかもしれない

code:text

Human < Animal

Fn Human Animal

Fn Animal Human

Fn Animal

Fn Human

マシにならなくて草

勝手にダウンキャストしなければ継承する型があっても多重ディスパッチできる

code:text

Human < Animal

add = Fn Human Animal

add = Fn Animal Human

add human animal // 上で確定

add human human // 対応する関数が見つからないでエラー

振る舞いによる多重ディスパッチはどうする？

重複する関数定義の禁止で良さそう？ダメかも

code:text

List = struct {}

next = fn list List {}

Hash = struct {}

next = fn hash Hash {}

for = fn list Nextable {}

for = fn list Animal {} //　Animal　は next を実装してないのでOK

for = fn list List {} // List は next が実装してあるのでNG

for = fn list List {}

for = fn list Nextable {} // 先に List が定義されているのでNG。となるとキツイ。

Listable = interface {

next = Fn<T> List<T> -> T

length = Fn<T> List<T> -> Num

} // Listable であり Nextable なデータ型が生まれてしまう

インターフェースを実装してもいいけど、重複が解消されない……？いや明示的なダウンキャストで解決するんじゃない？

code:text

Nextable = interface<T> {

next (Fn (Self T) -> T)

}

List = struct {}

next = fn<T> list (List T) -> T {}

Hash = struct {}

next = fn<T> hash (Hash T) -> T {}

for = fn<T> list (Nextable T) callback (Fn) {}

for hash::Nextable (fn ...)

毎回ダウンキャストするの面倒そう。明らかな場合は自動でダウンキャストして欲しいかも

ダウンキャストしないで検索する

なかったら、ダウンキャストありで検索する

複数候補見つかったらエラーにする

面倒な問題を含んでそう

後から関数が追加されて複数候補になってしまったら？クロージャがあるから平気？

詳細レベルによる優先度はつけない方が良さそう

インターフェースに沿って関数を自動で生成してくれたら楽そう。暗黙的なダウンキャストなし。ダメそう

code:text

Nextable = interface<T> { next (Fn (Self T) -> T) }

for = fn<T> Nextable<T> callback (Fn T -> Null) {}

List = struct {}

next = fn<T> list (List T) -> T {}

impl List Nextable // for = fn<T> List<T> callback (Fn T -> Null) {}

zip = fn<A B> Nextable<A> Nextable<B> -> Nextable<{A B}> {}

// 組み合わせ爆発が起きそう

ーーー

CDNをどう？

注意点

個人情報の誤キャッシュ

更新のリアルタイム性

React にしちゃえば個人情報の誤キャッシュは防げそう

まとめの閲覧はキャッシュしちゃいたい

SSR してキャッシュする：個人情報を載せない

React でデータ部分を memcached ：一番無難

React もするし Go で SSR もする：シンプルでない

更新系と参照系でページごとに React と Go の SSR を分ける：React の便利なところを参照系でも使いたい

メインを SSR にして、サブの動的な部分を Web Component にする

フロントエンドどうするか？

Bootstrap

JS は少し大変そう

デザインはいけそう

SSR はいけそう

CDN は個人情報に注意。効率は良い

Material UI

JS はいけそう

デザインはいけそう

SSR は壊滅的

CDN で考えることは減りそう

Web Component

JS は大変そう

デザインは大変そう

SSR はある程度いけそう

CDN はいけそう

Lit

JS はいけそう

デザインは大変そう

SSR はある程度いけそう

CDN はいけそう

Bootstrap ＋ Web Components

処理フローがごちゃごちゃする

最初から動作する

Bulma + Web Components

処理フローはスッキリする

動作部分を作る必要あり

Web Component のテンプレートどんなん？

丸ごと置換型

実装が楽だが、パフォーマンスが心配

仮想DOMがよぎる

ピンポイント変更型

コンストラクタで保持型

グチャグチャになりそう

効率良さそう

毎回クエリ型

まぁあり。

コンストラクタでクエリ型

一番バランス良いかも

id の重複が怖い

乱数をつかう

data-id 属性をつかう

Web Component のイベントどうする？

コンストラクタでクエリ型ならリスナーでいけそう

connected で解決するなら

代入でいけるなら q が必要ないかも

on_ マジックがいらないかも。

on_ マジックはあったらあったで便利。ただ bind がなくなるなら嬉しい

エラーハンドリング

システムエラー

説明：システムが起こすエラー（例：メモリ不足）

対応：詳細は見せずに統一な画面で表示しちゃう

ユーザーエラー

説明：ユーザーが間違った操作した時のエラー（例：電話番号のところに漢字が入ってる）

対応：サーバーで検知してクライアントで知らせる（クライアントで検知できないものもあるため一括でサーバー側で検知する（例：メールアドレスのユニーク性））

不正エラー

説明：不正な行為を検知した時のエラー（例：本来あり得ない値などを直接HTTPで送信するなど）

対応：システムエラーと同一

エラーをサーバーで検知してクライアントで表示する手法

ーーー

人をまとめる、言うことを聞いて貰うには信頼が大事

31:30 ぐらい

https://open.spotify.com/episode/7s8tZBi4rUyWnRS0okXrMX?si=9x4EQu1-ShWznMq18hAsGA

ーーー

セキュリティわからん

CORS

オリジンが違うリクエストであってもサーバー側の処理が走ってしまう実装が多い。良いのか？

CSP

CSRF

対策として秘密情報をページごとに仕込むとあるが、CDNでページ配信した場合はどうなる？

ーーー

まとめジェネレータ

著作権の問題

信頼性の問題

（SEOの問題）

NAVER のアーカイブ

ーーー

ウエンツが好きそう

ーーー

ヒメロプ（承認欲求を満たせる場所。オンラインキャバクラ。姫はチヤホヤされ、男は貢いで優越感と承認欲求を満たす）

カラミバ（満足いくまでダル絡みができる場所）

オークション

まとめジェネレータ

BUZZER（ブザー）

はてぶ

爆砕

SESSION

シークレットミッション

靴踏み

シード

ボトルメール

ーーー

エディター

DAP

Treesitter

nvim-cmp

Kakoune

ーーー

ガーゼ

e-bike

TextAlive

年金？

ーーー

自作言語

LLM

Zig, Hashkell, Go

WASM

WebRTC

自作OS

ーーー

Edge は信号が変わったら out に通知する

Gate は人力信号の変更通知が来たら再計算して出力する

Gate は Edge としか連結しない

Edge は Gate としか連結しない

Edge をインスタンス化したくない。Gate と Gate で繋ぎたい

ーーー

速読

脳内で音声化するのをやめる（内言語、内声化）

スキミング（拾い読み）

ーーー

「生活リズムを保つ＋外出する」が最強そう

精神的に前向きになって色々なことができる

一日が充実しやすい

健康にも良い

（試してないから分からないが、もしかしたら外出だけでも良いかもしれない）

これを継続したい。ナッジとスラッジを作る

外出する動機がない＆辛い

知識を仕入れて（本を読んで）試して評価する流れを作りたい

習慣化について早速試す

速読できるようにしたい

流れを整理したい

知識の仕入れ

やってみるリストの作成

実行

結果をリストに追加

ナッジ・スラッジについて知識を深めたい

後回しにするのをやめたい

そのための習慣化やナッジか？

ーーー

Giron

記事を肴にあーだこーだ盛り上がれる

はてブでいいのでは？

専用にすることで、

肴にして良いことが明示される

議論したいという意思が明示される

UXを良くできる

機能

記事を書く

コメントをする

コメントを見る

Range

完全一致

まるごと含む

まるごと含まれている

開始位置は含むが、終了位置は含まない

開始位置は含まないが、終了位置は含まない

ーーー

攻守がハッキリ別れており、守り側はできるだけ速く攻守の交代を狙い、攻め側は交代させられる前にできるだけ得点を稼ぐ。

守り側が有利になっている

非対称型？でバランスの取り方も良いと思うけど、肝心の面白さのコアが行方不明

引き出しにしまっておくぐらいか？

ーーー

特定のエリアにバフをかけるのが主軸の戦略ゲー

陣形に意味がつく

方向に意味がつく

部隊展開（部隊をどう配置するか、部隊の移動速度）に意味がつく

足りないのは

実装できるレベルの仕様

部隊展開のシステム

ようは生産部分だけど、１回いらないかも

部隊展開なしで１回作って良さそう

プロトタイプは手を動かして作るで良さそう

拡大再生産はなくて良い

移動例

乗り物

ジップライン

動く歩道

位置の入れ替え

召喚者の側に召喚

任意の位置にワープ

ワープゲート

ユニットキャノン

ぶっ飛ばす

カタパルト

インターネット（デジタルデータのみの移動）

方法

特定の位置に移動

移動速度上昇

特定の距離を移動

制限

装置が必要

コストが必要

時間がかかる

入れ替え

使い捨て

運ぶものが傷つく

障害

高さ

傾斜

崖

川

ぬかるみ

森

藪

溶岩

洞窟

温度

視界の悪さ

道の平坦さ

直進性

キャッチーな世界観

チアリーダー

応援団

ボクシング

犬のマーキング

リード

魔法陣

パーソナルスペース

ソーシャルディスタンス

wifi

台風

ライト

カリスマ

オーラ

磁力

ワード

ゾーン

縄張り

間合い

応援

支援

サポート

扇

繋がり

エリア

支配

領域

群れ

フォーメーション

遊牧

帯域

ーーー

気になった本（2023\6\30）

ソフトウェアアーキテクチャの基礎

STAFF ENGINEER

システム設計のセオリー

Docker（オライリー）

マスタリング TCP/IP 入門編

データ指向プログラミング

詳細データベース

入門モダンLinux

プログラミング文体練習

フィンランド人はなぜ午後4時に仕事が終わるのか

ーーー

プラネタリーなんとかタイタン

難しいー。

リソース管理が面倒くさい。

逆にリソース管理さえできれば簡単なのか？

リソース管理だけしてても防衛しなきゃしなきゃあかんし。

工兵作って資源集めて、敵が来たら防衛施設で対抗する？

貯蔵するのに頭を回すのも面倒。

やることが多い。頭が回らない。

やることが多い。生産楽しいけど手が回らない。

リアルタイムで防衛するの楽しくない。

初手、工場建設、資源の抽出

工場から工兵

工兵でタレットを少し

工兵とタレットだけで防衛したい

コマンダーを破壊する

戦力を揃える

工場を揃える

工兵を揃える

工場を稼働させる

資源を確保する

敵の生産を妨害する

敵から防衛する

工兵による工場支援はあんまり考えなくていいかも。工兵が暇になったら支援するぐらいの感覚

分析

基本は戦力で押し潰すしか選択がない

物量で攻めるのか、質なのか、惑星破壊兵器かの違いはあれど、基本は資源を拡大再生産して無駄なく運用するのが肝

生産（資源確保と生産効率）と戦闘があって、戦闘で工夫のしどころがなくてイマイチ

あまり三すくみがなくて駆け引きがない

タイタンで攻撃されたからといって、対策があるわけではない

地理を活かした戦いも微妙

レーダーもユニットの配置が分かるだけで、どんな種類がいるのか分からない。おそらく防衛施設は表示すらされない

裏回ったら防衛薄いんじゃね？ぐらいの予想しかない。いやユニットが分かれば戦力の多寡は大体わかるか。

けどそこには結局、資源の殴り合いがあるだけ。

もうちょっとユニットの特徴を活かした戦いがしたかった

生産効率を良くするのは、あんまりだなぁ

効率良く運用するのが楽しいといえば楽しいのかな。

それはそれで楽しいかもだけど、工場の稼働より、どう攻撃をしかけて敵を倒すかの効率のが楽しいと思う

俺が弱いのはあるだろうけど

なんなら生産は基本同じにして、どう攻めるかをコンセプトに作った方が良いかも。攻め方のバリエーションの中に生産の拡大再生産がある。（工場稼働率ではない）

攻め方のバリエーション

タイタンや物量でゴリ押す

惑星破壊（生産勝利）

防衛を固めて上級迫撃

ユニットを運んで

でも戦い方にフォーカスしたのがクラロワだよなぁ。あるいはMOBA。ポケモンユナイト研究してもええかもしれん。

ある意味生産に特化させて正解なのかもしれん。

いや、言うほど生産特化ではないけど

クソ単純にTITAN＋クラロワにしたら面白そうだよな。作るの死ぬし、操作も大変だけど

拠点を構えて、資源を確保して、工場作って、ユニットを生産し、生産したユニットを指揮する

生産は簡略化され工夫のし所がなくなり、ユニットの戦闘は物量がメインになり大味になる。

生産力を上げるんじゃなくて、ユニットの配置を補助するシステム構築をする

生産力を上げて、物量ではなくグレードの高いユニットを出していく

１試合に１回みたいな必殺技を用意して、逆転のチャンスを作る

システムとユニットで使う資源を分けて獲得方法も変える？

最悪逆転の仕組みはなくてもいい

地理的にユニットを活かすシステム難しそう。

地形を使って有利不利を作る

高さや地質の有利

パワースポットや一方的に攻撃できたり、草むらや土嚢で命中率下げたり

拠点確保

挟み打ちや背後などの方向

味方や敵の隣接

距離減衰

陣形

攻撃範囲の形や重ね、それによるコンボ

特定の位置にいることで何かが起きる

移動することで何かが起きる

速く通過すると何か起きる

離れることで何か起きる

特定の位置から特定の位置に移動すると何か起きる

跨ぐことで何か起きる

ある位置で待機すると何か起きる

特定の範囲にバフをかける

時間をかけ算

「何秒以内に」

「何秒の間」

強くなるとか、キープせよ

「特定のタイミングで」

時期によってユニットの強さが変わる

イフリートが降臨してる間は火属性ユニットの攻撃力が〜

降臨させるものをある程度操作できたり

クラロワ分析

ユニットの得意不得意、出すタイミング、配置

盾役の後ろに長物

盾役をある程度スルーして長物から処理したり

延命

弱点ユニットを出されるから、それをカバーして延命する

カバーされると弱点ユニットを多くは持ってないので困る

さんぽ

敵のユニットをこちらのユニットで誘導する

目的の妨害になる

働いてない状態で自陣に長くとどまらせてバリスタで弱らせる

こういう細かいテクニックが生まれるような豊かな土台を作りたい……

特定の範囲にバフをかけるのをメインに据える

前方の扇形とかにする

陣形に意味が出る

方向にも意味が出る

戦略レベルの配置にも意味が出る

指揮官クラスのユニットは範囲をデカく、バフもデカく、見た目も目立つ

指揮官クラスから部隊の傾向を判断して相性の良い部隊、悪い部隊が見分けつく

引くべきか援軍を寄越すか、近くに援軍は配置してあるか、素早く援軍を届けられるか、それで間に合うのか

色んなことに意味を持たせられる！最強かよ。ただキャッチーさは無さそうだから別途付与する必要はありそうだけど。

ーーー

くだらないけど笑ってしまうようなのも作りたい。

いや、むっず

ボタンを置いて、押すと画像がちょっとだけ出てきて連打していくと最後「ポンッ」と飛び出す。

画像によっては卵かと思ったら禿頭だったみたいなオモシロができるはず

画像トースター

ーーー

RTSの「色々なユニットで色々な攻め方ができる」をメインにしたゲーム

ユニット

耐久力

移動速度

攻撃力

攻撃間隔

射程

攻撃範囲

索敵範囲

その他

ステルス

積載量

生産可能性

生産速度

アクティブスキル

パッシブスキル

スペシャル

資源獲得

悪路踏破

トラップ

道の開拓

道の破壊

遮蔽の設置

移動できないユニットは工兵が作り、移動できるユニットは工場で作る

陸海空はダルいのでなくす。あっても良いけど、どんなユニットでも陸から空に攻撃できる

ユニット配置の巧みさで争う

ドミノでも良いし、シャンパンタワーでも良い

どうもクラロワに引っ張られてる気がする

局所的な戦闘は省略するとて、

戦術的なやり取り

ガチエリア

人数有利

ポジション有利

エリア確保してから固めに入いる

スペシャルを潰すようにスペシャルを使う

打開では人数揃えてスペシャル

ーーー

開拓の拡大再生産

資産を増やして勝利点を獲得したら勝ち

土地を開拓することで資産が増え、資産が増えることで開拓できる

ーーー

拡大再生産

RTS の拡大再生産だけを抜き出したゲーム

マシンを生産し、敵の拠点を破壊せよ

マシン

工兵

コスト

耐久力

生産速度

戦闘兵

コスト

耐久力

攻撃力

移動できるか

マシンにはグレードがあり、グレードが高いほど、コストは高くなるが、コスパが良くなる

戦いは、工兵を作りまくって、ちょうど相手を削り切れるタイミングで決戦するのが最適解

しかし決戦前に戦闘兵を送って敵の工兵を破壊できれば相手の生産力を落とすことができる

防衛用の戦闘兵を用意する。

それを超えて工兵を破壊できたら、拠点ごと占領できちゃう

投資したリソース以上に敵のリソースを削れるかどうかの駆け引き

つまり情報戦になる。

敵の防衛リソースと自分の攻撃リソースを比較して勝てる時だけ仕掛ける

情報戦をどこまでやるか

全ての情報を公開する

自然に分かる部分だけ公開する

偵察

偵察と隠蔽

偵察と隠蔽と撹乱

スパイ

コンセプトは拡大再生産なのであんまり情報戦したくない。

逆転が難しそう

生産力で生産力を増加させるゲームなので……

内政と防衛を固められたら逆転の目がない

防衛を固めると内政がキツくなる仕組みがあると良い？

「攻撃→内政→防衛→攻撃」の三すくみ？

対等な戦いだと、先に敵の生産力を落とせたら、そのまま決着がついてしまいそう。

特に防衛戦力を壊滅させられたら、そのまま決着しちゃう

格差をつけるのが楽しいゲームではある

序盤で勝敗が決まってしまうと楽しくない

局所的な勝利

地理的に離れると不利になるようにする

局所的に情報戦を制して勝つ。

局所的に勝利して生産力を削る

普通に相手もやってくるから結局総力が強い方が有利。それはそれで良いのかもだけど逆転にならない

格差がわかりづらいようにする

情報を隠蔽する

格差の計算をしづらくする

曖昧にはしたくないなー

次に何をすれば良いのか分からなくなる原因になる

「攻撃、内政、防衛」の三すくみを設計する

工兵（内政）

工兵はマシンを生産することができる

工兵は戦闘力を持たず敵からの攻撃で簡単に破壊されてしまう。

防衛施設（防衛）

能動的に攻撃できないが多大な戦闘力を持ち、戦闘兵に強い。

敵から攻撃には強く、自分の内政の邪魔になるように

防衛施設には工兵を常設（消費）する必要があり、生産力が低下する？

工兵の生産コストだけで済んでいるので内政に対するデメリットとは言えないかも

工兵の生産速度にデバフをかける？

防衛する度、損耗を工兵で回復させる必要がある？

防衛施設を建設するのに時間がかかる？

敵が防衛施設に取り掛かっている間に自分の内政を進めると有利になる

戦闘兵（攻撃）

工兵は戦闘力を持たないため、一方的に破壊できる

配置的に防衛の薄いところから食い破る

拡大再生産によるリソースの多寡と部隊展開の上手さ

拡大方針が１つしかないのは面白くないかも

逆転

逆転不可能なのを受け入れる

情報を隠蔽する

乱数を取り入れる

別軸の争いを入れる

地理的な部隊展開の上手さ

局所戦闘をタワーディフェンスにする

情報戦

拡大再生産の方向性を複数用意する

状況を変化させる

特定の何かが有利になったり不利になったりする

拡大再生産だけをコンセプトにするなら敵はいなくて良いかも

制限がだんだんとキツくなっていくなかで、どこまで拡大できるかの遊び

拡大再生産で対戦するなら、どうやって駆け引きを作るかが大切そう

RTSを活かすなら、地理的な要素を上手く取り入れるのが良さそう

RTSの本質は「敵を倒す」なのかも

敵を倒すために生産し戦闘し占領する

点と点での戦いはこれで良いかも

グラフ上での戦いに発展させて格差の問題を解決する？

点と点の戦いも一本道にする？

地理をどこまで取り入れるか？

ゼロ

一本道

疎なグラフ

蜜なグラフ

マス目

無軌道

バトルロワイヤル形式も面白そう

一つの拠点から採掘できる資源量に上限を設ける

敵の拠点を占領することで採掘できる資源量を増やして、生産性をアップさせる

リアルタイム性をどこまで入れるか？

ターン制

クールタイム制

RTS

属性相性をどこまで入れるか？

ゼロ

三すくみ

射程、攻撃力、移動速度

ローグライク形式で拡大再生産

類似作品が無限にありそう……

開拓をテーマにするのは良さそう。

開拓をすると、より開拓しやすくなって、たくさん開拓できるようになる

ーーー

スプラトゥーンからエイム要素を抜いた戦略ゲーム

スプラトゥーンをプロトタイプに思考を進めて、徐々に最適化していく

戦略ゲームは経験がなくとっかかりがないと考えるのも難しい

索敵

潜伏

裏どり

挟み撃ち

射程

インク

キル速

イカ速

索敵範囲は二段階あり「範囲は狭いが潜伏を発見できる索敵」「範囲は広いが潜伏してない敵だけを発見できる索敵」

潜伏は移動が遅くなり索敵範囲も狭くなる

最大４キャラを操作して敵の拠点を破壊せよ。

キャラのパラメータは、体力、攻撃力、射程、移動速度、索敵範囲

基本操作はキャラの移動だけにしたい。

それでも四人も操作するの大変な気がする。

スナイパーとかどうするんだ？

命中率にする？

リッターじゃくてジェットにする？

遮蔽物の影に隠れたりしたい

クリアリングをどうするか

視点が俯瞰だから索敵が微妙いな……

指向性のある視界を用意して、視認判定で良いかも

ーーー

任意の時空間にワープして、物語を自分好みに展開させるゲーム

目的と達成するためのタスクをチェーンで繋げるように行動するAIでNPCを作る

主人公はNPCに干渉することでNPCの行動を変化させ物語を変化させる

NPCに目的を与えて、上手くクロスさせる必要があって、群像劇を作っていくようなシナリオ能力が必要そうで難しそう。

基本システムだけ作るからライターさん書いてくれねぇかな。

無造作に物語を作って交差させてくだけでも、なんか良い感じに面白くできるんじゃねぇかな。

著作権切れの物語を持ってきて交差させてみるか。

走れメロスとか良さそう。

目的がハッキリしてるし、対立してる

王は人間が信用ならないことを白日の下に

メロスは信用できる人間がいることを示したい

メロスは妹の結婚式に出たい

セリヌンティウスは王を説得してメロスの援助を行うとか

メロスは１人で困難に立ち向かっちゃう感じで交差しない。

なんか困難をアレンジして交差するようにしたい

ヘラクレスの試練と交差させる？

現代風アレンジ？

シン・ゴジラ的な

それこそシン・ゴジラなら色々な人が色々な関わり方をしていて面白そう。見たことないけど……

地球規模とか、日本規模な危機に対して、色々な人が関わって解決していく感じ。サマーウォーズみたいな

それだとエンディングが１つに定まってしまって面白くないかも

どんなエンディングでも余韻を残せるような、色々あっても前に向いて歩けるような終わり方にしたい

んなこと言ってもなぁ

もっと単純にパン屋を持ちたいとか、借金返したいとか、働きたくないとか、そういうので良い気がする

今度は交差させるのが難しくなる

１人１人に身近なテーマを持たせる

夢を追いかけるべきか

働きたくない

恋愛が上手くいかない

このままぬるま湯でいいのか

ダメ人間テーマの方が良いか？

働きたくない

努力できない

恋愛できない

何かしらの対立構造、あるいは干渉点を持たせる

生成的に物語を作り出して、たくさんのキャラを交差させて、如何様にでも物語を展開できるようにできたら面白いかも

LLM に群像劇書かせてみたり、登場人物考えてみてもらっても良いかも

ーーー

タイトルを決めない全文検索がメインのメモ帳

できればページも作りたくない

でもグルーピングはしたい。インデント？

関係ないものは遠く、関係あるものは近くに

何も考えずに書き始められて、勝手に整理されてほしい。

整理というのは

すぐ取り出せる

関連するものは近く

ーーー

描画Lib。KK-Painter

レスポンシブ対応

Canvas のアンカー

画像自体のアンカー

Canvas に座標を指定して画像を表示する。

画像の拡大縮小

画像の回転

アニメーションLib。KK-Animator

ーーー

音階が取れているか分からない

フォールダウンで滑らかに音階を下げられてるか分からない

ミックスボイスっぽいものをやると喉じめになる

コンパイルとか無しに簡単にレンダーしたい。

リアクティブなコンポーネントじゃなくても良い気がする。

手続き的に簡単にHTMLをCRUDしたい。

DOMを簡単にJSで扱えるライブラリ

DOMを簡単に生成できる

DOMを簡単に取得できる

DOMを簡単に変更できる

DOMを簡単に挿入できる

DOMを簡単に削除できる

他ライブラリ

DOMmy.js が似たような方向性でライブラリを作っていた

jQuery は色々出来すぎるけど、この方向性で使うことも可能

バニラJSでも勿論できる

理想は基本DOM操作で、DOMを渡してちょっと便利にできるメソッド群があると良い

あまりDOMをラップして独自の抽象化層を作りたくない

DOM の取得

querySelector() と querySelectorAll() で良さそう

jQuery の内部でもあれば上記のメソッドを使っている

DOM の生成

文字列でHTML書いてDOM生成するのが良さそう

文字列を構文解析するのダルい

jQuery 使っちゃうか？

もしくはJSX

コンポーネント単位で扱えるようにする

ツリー状の DOM をデータとし、メソッドが定義してあるクラス

基本操作

生成

マウント、アンマウント

DOM の取得

コンポーネント同士のやり取り

イベント

コンポーネントマネージャー

コンポーネントの参照を渡し合う

プロップ

code:text

fn aaa(x, y, z)

def {x}({y})

z

end

end

{aaa "add", "x, y", <<EOF

z = x + y

z * 2

EOF}

しらたき

大根

牛すじ

つみれ

しゅうまい揚げ

餅巾着

さつまあげ

まる天

がんも

ちくわ

頭の中のでの暇つぶし

自作言語

エラーハンドリング

マクロ

構文解析

証明構造

グラフ

集合

キャリア

グラフ理論の最小全域木を使った例題

なんかサービスやらゲームやら

仕事

エラーハンドリングどうするか

例外の何が嫌か？

戻り値でエラーを返せるなら、それで十分だと思うだけで、嫌ではない

どの例外が発生するのか網羅できない

キャッチの構文が嫌だ

今の問題

漸進型を目指してる感じなのでタイプエラーが出るよ

関数呼び出しとかでもタイプエラーが出る可能性がある

どうハンドリングしたらええんやろう

戻り値で戻してもなぁ

例外投げてもなぁ

any 型を許さず、unkown 型のみにする？

any 型の時とそれ以外で動作を分ける

any 型の時に出るエラーは戻り値でエラー値を返す

コンパイル時に any 型と判定したかどうかで処理も変えたい