An Interesting Discussion Topic, I guess...

[Jubby]

Don't really know where to put this, because while it's a question, it's not like I couldn't get something working or anything, it's more an opinion-y kinda question :P

Just out of curiosity, do you think the gamemakers at Nintendo have created a whole bunch of tools and tutorials like we have? (And by we I mostly mean Nintenlord, Xeld, and Zahlman but I guess the hacking community in general :P) I mean, I'm sure they probably have some sort of graphics compressing program and all, but do you think they have things like FEditor and that kinda thing?

[CT075]

Seeing as they (for the most part) don't have an existing framework to use, I'm guessing a lot of work is done 'manually', that is using raw file editors (I'm hesitant to say they use a hex/binary editor, but it's possible).

[CrashGordon94]

Probably not since they only make very few actual games compared to the number of hacks floating around (obviously) and they probably make every one of them mostly from scratch. Making a game and hacking it are very different after all.

[Celice]

You both are wrong >_>

Developers usually have tools which help them compile and edit data, yes. If you take a stroll through sites like The Cutting Room Floor, some of the resources are still left on the disk. For example, in FE9 (or FE10?) there's remnants of a map editor which includes generic tiles describing what's going to be here (things like Forest, Torch, Chest, Event, etc.). Pikmin seems to have a functional editor still on the disk, though I'm not sure if it has all the necessary files on it to compile with. If you look at pretty much any of the Rareware games on the GBA, you'll find remnants of their audio compilers. TONS of games also have text referencing what programs were used, sometimes even the exact names.

Sadly, I can't find the Fire Emblem image in question :o VincentASM as probably seen it though

EDIT: There are also numerous interviews of developers who have gone on record about how they dealt with coding and producing video games, and mentionings of their programs are included.

EDIT2: It was Pikmin 2, not one :p

Edited January 14, 2012 by Celice

[CT075]

Well, they obviously have tools to manipulate the engine once the engine is in place. Otherwise that's just plain inefficient although with some of the shit that they do in FE7 it wouldn't surprise me

[Jubby]

Yeah, I guess it wouldn't be all that useful to them to have something like FEditor for portrait insertion and whatnot, but maybe some sort of editor that interprets commands and such, similar to how FEditor runs animation scripts? :P And like I said they would almost certainly have some sort of compression stuff. Do you think they'd have something like Nightmare? Editing a table in hex seems like it'd be a huuuuuuge pain :/ And that could work for any game, like GBAGE does, if you made new modules for it.

[Anouleth]

Probably not since they only make very few actual games compared to the number of hacks floating around (obviously) and they probably make every one of them mostly from scratch. Making a game and hacking it are very different after all.

Pretty sure that they don't. There were plenty of odd items from FE7, for instance, that are in the data for FE8 that they didn't bother to take out, such as many of the S Rank weapons and the Rings.

[Celice]

To top that, all of Thracia's items are in the early temp files for FE9 and FE10 (FE10 also is built directly from FE9, as numerous files were carried over and also unused).

icons in question

And as well, Twilight Princess has evidence of being built from Wind Waker :p

Edited January 14, 2012 by Celice

[Crimson Red]

They probably even have a better way of creating the engine to start with. Once everything's in place I'd imagine that they have a bunch of programs and compilers that make their job easier. Take event codes, for instance--similar event codes tend to be next to each other but the actual values for them in FE6 and FE7 are quite different. My guess is that they had a system for defining what value was for what event code (with what parameter(s), naturally) and that when they made FE7 they simply inserted new event codes wherever and that new values were assigned to old event codes, as opposed to just adding any new event codes to the end of the list. e.g.

(this is all made-up)

in FE6, the MOVE code is 0x10

in FE7, it's 0x26

what they probably did was add a bunch of codes BEFORE 0x10 until the MOVE code got shifted up to 0x26. And they likely have a system for defining what values are for what codes to make everything easy. I'm also guessing that in their compilers it was easy to move offsets around because the compiler probably did all of the pointing for them. The system was probably more like the NDS than people think except not nearly as organized or easy to hack. Though IIRC the GBA was considered one of the harder systems to hack for a while due to a lack of "organization" in the data that both older and newer systems seemed to have. However since I forgot where I got this information it could be wrong and so I would not take my word on it.

When you're using the framework of one game for another and you keep the data, it would mean that the data is there but is not used by the code, and it just gets moved around to wherever "necessary". Since FE7 is a more "complex" game than FE6, it's only natural that similar data tends to be found later in the ROM of FE7 than FE6--they added more data to FE7 which shifted old data forward/further into the ROM. I'd imagine things like map sprites, music, etc. are all found later in FE7 than FE6.

IIRC there were many universal programs that developers used to do certain things that were done in many games, like music insertion and compressions. Again, I don't remember where I heard this, but it only makes sense. More game-specific things likely had more specific programs... but I doubt that there was much "hex" editing. Most everything was probably done with some sort of program (stats/other "table-format data" with some sort of table editor that a program could compile, ASM with of course some set of programming programs, graphics and music also probably had their own sort of program... and all of these programs would likely take care of any "pointer tables" automatically). Hex editing would be far too inefficient IMO, and cause problems in that hex edits are static; to move them, you have to manually move them because they aren't in the code. It'd be like using the EA to point to some obscure hex data for a certain code--if said hex data isn't written as part of the EA code, it is its own "entry". You have to manually point to it with a hex pointer instead of a label and you couldn't move the data without using a hex editor, so it has a highly static location, which is a problem if you needed to use that space for something else in the future.

tl;dr

developers are much more efficient than us, that's why they can make full games in less than half the time we can hack them, and we are only making EDITS--I'd imagine if they made the same edits they'd be incredibly faster than us due to their access to tons of materials and a large team that works on the game (whereas most hacks have 1-3 main people working on it).

[Celice]

Developers are often not more efficient than us. Numerous fans have improved how a game is coded or found better compression and implemented it in than the devs had Part of their large team is what allows them to finish projects faster than a single fan playing around with a favorite game--not to mention able and hired programmers to make the process infinitely quicker. Then again, that largeness also makes it more difficult to do quality-control in terms of efficiency. Fans who are more intimate with the completed project can often find ways of getting even more out of the game than the devs did, simply because they didn't have to deal with bringing together EVERYTHING each part of the dev team was working on.

To exemplify, that horrible scrolling in Super Mario Bros. 3, that incorrectly pulls the wrong tiles and colors from the left of the screen when you move right? Fixed with a single edit. Mere oversights often seep through larger dev teams, is all

Edited January 14, 2012 by Celice

[Crimson Red]

Yes, true. Very true. I meant in general, due to their access to programs. Often times like you said, they don't code things as well as they could. Or develop nice systems for everything. I think the spell animation system is an example of that. Of course there are also more obvious things like bugs/glitches. Again, I just meant in general their progress and ways of doing things tend to be easier, though for experienced hackers, they can actually find better ways/systems/methods of doing things than the developers did. I call that "the hacker is smarter than the developer".

[Celice]

A bit of a bump, but I thought this was a very interesting response to Jubby's question. This text not only answers your question on whether they do (indirectly), it also helps you understand some side comments on processes as well. Mostly an interest piece.

I found those developer notes for you' date=' DarkLinkael. I'm not sure this is all of them, so you could look around for others if you're interested.

Filepath:

TP DISK \ Partition #1（the game itself） \ res \ Object \ Sample.arc \ archive \ dir \ file2.txt

It's developed/expanded by Sample.arc

---

●地形ユニットMOVEBGにスイッチ1の情報は渡されてないらしい。酒井さん談。

たしかに、マップデータ変換時に使い捨ててだいたいOKな情報だからそうなってる気がしてきたけど、

やっぱりそうなの？

●レイヤーについて整理。昼夜と表裏をなんとか。

・昼夜については、切り替えをどうする？ゆっくり(「タクト」)かばっさり(「ムジュラ」)か？

・表裏については、もう1つ2つ追加があるかもとか。

●自動化したい。odemrun引数とかObjectSenderとか使えばできるような気が。

・メモリマップの出力。

・メモリバンクの配置設定。

●コリジョンポリゴンを全表示したい。確認のために。

ObjectReflector[/Node/zelda地形チェック内部|デバッグポリゴン描画']で表示されるけど、

その場合はリンクのそばのポリゴンだけなのでわりと残念。

# そういえば、吉田さんのポリゴン統合とかの動作確認はどうやってるのかな。

●2Dマップレール

○十字キー上で表示されるマップの実装はどうなってますか？とりあえず確認だけ。

→とりあえず先にやっとく。岩脇さん談。

→進行中。吉田さんが。

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

■　対処済み

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

●地形ユニットについて確認。半透明ポリゴンはどうなりますか？

半透明地形ユニット同士の重なりは問題になるけど、そうでなければいいの？

たとえば、シャドウ用の半透明ポリゴンとか。エフェクトなどで使用する半透明ポリゴンとの重なりは大丈夫？

→禁止。うまく描画されるときもあるけど、それは偶然。

実際にはマテリアルソートとの関係で出たり出なかったりするはず。

→マテリアル名で描画順序を指定できるようにしてもらった。これによって、ディティール表現の

ための重ね合わせる半透明は使用可能に。

しかし、水面のような真の意味での半透明はやはり不可。ポリゴンソートとかしないから。

真の半透明はMOVEBGでやる方向で。

→地形ユニットMOVEBGとしてモデル描画オブジェクトを追加。

●jccが大量のメモリを使用してる。800MB近く。減りませんか。

→岩脇さん、松谷さんに連絡済み。

→半分くらいに減らしてもらった。もうちょっと減らしてほしいので、いずれさらに調べてもらう。

→激減。別物なくらい高速化。

●デモアーカイブについて。

○リソース登録所でつくることができるか？見た感じ、アクターとかと同じみたいだけど。

→できる。まったく同じ。

○xnim_id_conv.plって何？arcファイルのリソースIDに0x10000をたしてるけど、どうして？

→オブジェクト用リソースかデモ用リソースかの区別。

汎用アクターでは、デモデータによるアニメーションモード指定を解釈するかどうかも

→指定を一度に行えるようにIDをビット分割する方向で。

●シーン指定モーニング起動について、レイヤーもオプションで指定したい。

→対応済み。佐々木さんが。

●シーン指定モーニング起動について、--menu=LEVEL2とすると、ステージが選択されない。

部屋番号を指定しないと無効っぽい。

→対処済み。岩脇さんが。

●particle.xnimの登録はどうしようか？

d_particle_name.*同様に、particle.xnimもParticle/mk_arc.batでcvs updateしちゃうか。

→対処済み。

●アーカイブファイル名の制限は？

7文字以下って聞いたような気もするけど、それはオブジェクト登録名だっけ？

じゃあ何文字以下？DOS8.3形式？ロングファイルネーム？

# 「W_motion」というのがあるということはDOS8.3形式なのか。

→アーカイブ名は9文字以下。森田さんから。

●シーン指定モーニング起動について、たとえば、

% OdemRun ... -a --noopening --menu=LEVEL3,0

のように実行すると、「LEVEL3」部屋0ではなく「Fire_Dungeon(Room7)」が選択されてる。

ちなみに、このメニュー項目は

--------ここから--------

(前略)

LEVEL3,（0）,LEVEL3,0,0,-1,

LEVEL3,（1）,LEVEL3,1,0,-1,

LEVEL3,（2）,LEVEL3,2,0,-1,

(中略)

Fire_Dungeon(Room3),,LEVEL3,3,0,-1,

Fire_Dungeon(Room4),,LEVEL3,4,0,-1,

Fire_Dungeon(Room7),,LEVEL3,7,0,-1,

(後略)

--------ここまで--------

となっていて、メニューテキストmenu.datの中でもっとも後にある「LEVEL3」ディレクトリ。

同じディレクトリに属する部屋が異なる表示タイトルのステージに含まれていた場合、もっとも後の

ステージになってしまうのか？ちなみに、メニューの「LEVEL3」はちゃんと＜(3)＞になってる。

→対処済み。岩脇さんが。もっとも前のステージになるように。

●「リソース登録所」について。

○SRDさんのPCの環境は？Admin権限は使えるか？ActiveXのインストールは可能か？

→可能。

○リソースファイルをローカルPCにコピーするとき、そのコピー先パスは？%ZELDA_JMAP_DIR%\rom\DVDRoot？

→%GCZELDA1_ROOT%/GDEVImage/DVDRootで。%GCZELDA1_ROOT%が未定義ならダメ。

●bdlデータをbmdcuttex3.exeで処理していいのか？非トゥーン指向という話だけど。滝沢さんは問題なさそうと言った。

→よい。やっとくこと。メモリ削減とかで効果があるかもしれないし。

→対処済み。csvファイルは空で。

●パーティクル。

○古いデータがdolzelに残ってるくさい。処分する？

→処分するならすれば。dolzel/res/Particleディレクトリを空にしてからmk_arc.bat。岩脇さん談。

→近日中に伊藤が実行する予定。

○PSceneのグループを整理したい。254を残してばっさりと。伊藤談。

→jmpデータで使用されてなければやってよし。岩脇さん談。

→伊藤が実行済み。

○mk_arc.bat で //d/zelda/dolzel/ にリソースをコピーしてるけど、これはひどく環境依存。ちょっと心配。

→伊藤に通達済み。

●jccでunionみたいなデータは生成できるか？

できるんだったら、イベントデータについて、zevとstbのときに必要だけど、カメライベントには必要のない

ファイル名の情報があるので、それをunionの一方にする。

→生成可。じゃあそれ。

→仕様を提出済み。小川さんに。

●2Dマップレール

○ポリゴンにまったく属さない頂点があった場合、その頂点はたぶん誤り。エラーに。

→対処済み。岩脇さんが。

○ラインにも色指定を。

→jccの対応がまだだけど、それはデータ仕様がまだだから。あわせて、2Dマップレール警告をエラーに。

→対処済み。岩脇さんが。

[Celice]

And on another note, tUME has been used in several games as a generic editor. There are several other generic programs that were used, I think one is linked to in the wiki, but several were discussed on some pirate cart wiki (since some pirate developers have intentionally explained what tools they have used).