I can build the project on Windows 10 via make build-windows, however, when I run the exe:

dan@dan-laptop MINGW64 ~/git/OpenPokemonRed (master) $ ./build/windows-amd64/pokered.exe panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x18 pc=0x11150b7]

goroutine 1 [running, locked to thread]: pokered/pkg/audio.newMusic(0x0, 0x0, 0x11bf183, 0xf, 0x11bbfb0, 0x8, 0x0) C:/Users/dan/git/OpenPokemonRed/pkg/audio/music.go:62 +0x57 pokered/pkg/audio.newMusicMap(0xac44) C:/Users/dan/git/OpenPokemonRed/pkg/audio/music.go:31 +0x7c pokered/pkg/audio.init() C:/Users/dan/git/OpenPokemonRed/pkg/audio/music.go:24 +0x4b

I've looked into it and it looks like the func newMusic in music.go is crashing, probably unable to find the file? I'm not sure what the music paths represent (for example /1-00 Intro.ogg), where are this files supposed to be located? I can't find any .ogg file in the project.

現在のシステムでは複数枚の画面描画を再現しきれないのでレイヤーシステムを導入する

各パッケージのVBlankではこのレイヤーにイメージをセットしていって最後にそれらを組み合わせて画面を作る

• 最後の画像合成先をstore.TileMapにする
• store.TileMapには最後の画像合成以外で書き込みを禁止する
• menuのZ軸はこのレイヤーのZ軸と統合する

現在の設計では

type Layer struct {
	Name  string
	Z     int
	Image *ebiten.Image
}

var Layers = []Layer{}

こんな感じ

Name はレイヤーの識別子とする予定

マップでの処理

format

PokeTraveler方式を考えたが、原作と同じ方式で良さそう

PolishedMapを使えばそこまでDXは悪くない

map

• header/ マップヘッダ
• object/ マップオブジェクト
• wild/ 野生のポケモン
• mapmeta/ その他のメタデータ
• hidden/ hidden objects
• blk/ blockdata

実際にエンジン部分を組み合わせてゲームを作っていく方法

戦闘

1. map script
2. text engine
3. 戦闘開始

2 -> 3 のつなぎ目

ショップ

1. 売り物のlist menu
2. 個数

1 -> 2 のつなぎ目

solution

現在実行中のハンドラ関数という項目を作り、それによって個別の処理を実現していく？

ゲームボーイと違って、vblankが終わっても元の処理に戻ることはない テキスト描画中なら次のフレームでもテキスト描画を続けるように、Overworld中なら次のフレームでもOverworld処理を続けるようにしてやる必要がある PokeTraveler同様にModeによる処理の分岐を実装してやる予定 VBlankという毎フレーム必ず実行される処理も作る予定

Mode

• mainモード (下記のモードを組み合わせて様々なゲーム内の処理を実現する)
• overworld
• text
• アニメーション
• menu(textに含む?)
• ポケモン図鑑
• A/Bボタンを押してもらうウィンドウ(ステータス,タウンマップ, Diploma)

subMode

textのscroll待機処理など、思った以上にloopが多く、複数のモードが必要なのではと思ってきた

一番上の階層にモードを大量に作るのは問題があるのでsubModeを使うのが良い気がする

その前にscrollの問題を別の手法で解決できるか考える

人や、ものなどのスプライト全般

Render

OAMシートを作ってスプライトはそこに配置していき、最後にそれをtilemapの上に描画する予定

草むら

草むらでは、 BG > SPR になっており草むらのタイルをスプライトのタイルの上から 下半分だけ描画する必要がある

BG > SPR の現象は草むらだけなので草むらは特殊なタイルにして上から描画するようにする？

テキストボックス

テキストボックスに隠れたスプライトは非表示にしてやる必要がある

• テキストボックス層
• スプライト層
• BG層

とレイヤを分けるのがいい気がする

API list

• [x] UpdateSprites
• [x] UpdatePlayerSprite
• [x] UpdateNonPlayerSprite
• [x] DoScriptedNPCMovement
• [x] UpdateNPCSprite
• [x] UpdateSpriteMovementDelay
• [x] UpdateSpriteInWalkingAnimation
• [x] InitializeSpriteScreenPosition
• [x] TryWalking
• [x] UpdateSpriteImage
• [x] MoveSprite
• [x] AdvancePlayerSprite
• [x] SpriteFacingAndAnimationTable
• [x] AnimScriptedNPCMovement
• [x] InitializeSpriteStatus
• [x] CheckSpriteAvailability
• [x] MakeNPCFacePlayer

Data

静的データ GB版ではROMに格納されていたデータ このパッケージは利用するだけの単方向のパッケージにする

Dataの中に入れるのは

• baseStats
• mapHeaders
• mapObjects
• wildPokemon
• *.asm
• テキストデータ

など大量のデータがあるがこれらを go のデータ構造にするか、jsonなどの汎用DSLを使うかは要検討

goのデータ構造じゃないとシングルバイナリにできない

constantsのデータはenumなので別ディレクトリ？

Text

テキストエンジン このパッケージは単方向に利用されるだけのパッケージである必要がある

機能

• テキストコマンドの処理
• 特殊文字の処理

テキストコマンド

TX_RAM -> "{関数名}" 事前に対象の値を返す関数をmapに登録しておき、それを実行する
TX_LINE -> "${line}"
TX_BLINK -> "${blink}"
TX_ASM -> "${関数名}" 事前に関数をmapに登録しておき、それを実行する

TX_SFX_ITEM_2         
TX_SFX_KEY_ITEM       
TX_SFX_CAUGHT_MON     
TX_SFX_DEX_PAGE_ADDED 
TX_CRY_NIDORINA       
TX_CRY_PIDGEOT 

特殊文字のformat

text   EQUS "db $00," -> なし
next   EQUS "db $4e," -> \n
line   EQUS "db $4f," -> \n
para   EQUS "db $51," -> \p
cont   EQUS "db $55," -> \c
done   EQUS "db $57"  -> \d
prompt EQUS "db $58"  -> \▼
page				  -> ??
dex       			  -> ??

テキストデータ

ゲーム内で扱うテキストデータと、人間が書くテキストデータは違うフォーマットにして、内部で変換を行う

_AgathaEndBattleText::
	text "Oh ho!"
	line "You're something"
	cont "special, child!"
	prompt

var text = `
Oh ho!
You're something
special, child!
▼` // $tOh ho!\nYou're something\nspecial, child!\▼

_PewterCityPokecenterGuyText::
	text "Yawn!"

	para "When JIGGLYPUFF"
	line "sings, #MON"
	cont "get drowsy..."

	para "...Me too..."
	line "Snore..."
	done

var text = `
Yawn!

When JIGGLYPUFF
sings, #MON
get drowsy...

...Me too...
Snore...
` // "Yawn!\pWhen JIGGLYPUFF\nsings, #MON\nget drowsy...\p...Me too...\nSnore..."

_DexSeenOwnedText::
	text "#DEX   Seen:@"
	TX_NUM wDexRatingNumMonsSeen, 1, 3
	text ""
	line "         Owned:@"
	TX_NUM wDexRatingNumMonsOwned, 1, 3
	db "@"

var text = `
#DEX    Seen:${DexSeen}
		Owned:${DexOwned}
`

menu

start menuのような具体的なmenuではなく、menuのエンジン部分

• 通常menu
• listmenu
• 個数選択Menu(DisplayChooseQuantityMenu)

関連する関数

• DisplayListMenuID -> InitListMenuID
• DisplayListMenuIDLoop
• DisplayChooseQuantityMenu
• ExitListMenu
• PrintListMenuEntries
• HandleMenuInput
• PlaceMenuCursor
• PlaceUnfilledArrowMenuCursor
• EraseMenuCursor

memo

• 2択メニューは特別扱いしない
• startmenuはmenuの一種だし、機能として独立してるのでwidget
• InitListMenuID で listを特定の変数に入れると list menuモードになる？
• list menuモードでは DisplayListMenuIDLoop が実行され続ける
• menuモードでは HandleMenuInput が実行され続ける

menuは複数存在しうるがその構造体をすべて作ってしまう？

format

個人的には一つのバイナリにしたいので画像データはバイト列として抜き出す

画像データが必要なもの

• ポケモン(前面、背面)
• トレーナー(デフォルメなし)
• スプライト(人、ポケモン、...)

タウンマップ

• カントー地方の画像を作っておいてそれを1枚の画像として使う
• タイルセットから形成する

https://github.com/pokemium/OpenPokemonRed/blob/206e9bc65856ea44934870418dd9a3cab2cd4e8d/pkg/text/preprocess.go#L9

https://github.com/pokemium/OpenPokemonRed/blob/206e9bc65856ea44934870418dd9a3cab2cd4e8d/pkg/util/util.go#L33

Due the the text being store in in the source file line endings are Based on the file encoding and not the os version. When compiled for The opening interaction with oak has no text and crashes due the the line not splitting and be made empty with the sub select. Pull request incoming.

By making version a public const string, you eliminate a function call. Defaulting it to "Develop" obtains the same result as the old function call getVersion().

特殊な処理が多いのでEngineは必要な可能性が高い？

依存関係がぐちゃぐちゃになりそうだが...

• battle -> パッケージとして独立
• items -> パッケージとして独立
• menu -> widgetパッケージ
• overworld -> パッケージとして独立
• *.asm -> これをengineとする？

結論 engine/*.asm の部分だけを engineにし、他はパッケージとして独立

engine が参照するのは data のみにする?

items

• inventory かばんとPCボックス
• itemfinder ダウジングマシン
• items アイテムを使う処理
• tm 技マシンに関する処理

inventory

機能

• インベントリのアイテムの追加・削除
• アイテムのスワップ
• インベントリが満タンか

itemfinder

ダウジングマシン

items

アイテムを使う処理 いろいろな上の階層のステートをいじる必要が出てくるのでこれは別パッケージにおいた方がいいかも？

tm

• 技マシンの価格を取得
• ポケモンが指定した技マシンの技をすでに覚えているか -> 拡張性を考えて全ての技に変更?
• ポケモンが技マシンの技を覚えられるかチェック

PokemonRed

ポケモン赤を忠実に再現

ただ拡張性を考えて作る

使用技術

MonsterEngineでの再利用性を考えて選びたい

1. Go + ebiten

• 使用経験がある
• Goなのである程度のパフォーマンスが見込める
• PokeTravelerやBoJのコードが再利用できる
• wasm化でwebに組み込むこともできる

2. TypeScript + React

• Webで遊べる
• electronでデスクトップアプリも可能
• CSSで見た目に拘れる
• MonsterEngineでのUI作りが楽

結論 wasm化を考えると Go で作った方が良さそう

memo

• 完全再現なのでアセットの妥協はしたくない
• ただ戦闘のアニメーションは後回しでいいかも
• バグの再現はしない
• マップは一枚の画像で作るのではなくタイルごとにレンダリングする
• 図鑑番号とポケモンIDは別に定義する
• ポケモン作成のゲームエンジンの名前は Pokemium