Reverse engineering a file format has a major down-side to it. You can never be 100% sure that you've made all the right gueses. Sometimes there are entire sections of the file that are still unknown. Is it right to jump ahead and start coding a level editor when you still don't know how to manipulate some of the data structures?

If you don't start coding then you're stuck waiting for things to happen that might never happen. So what's the best approach, do you put the idea of writing a level editor on the back burner until you have figured out the remainder of the file format, that could take years, Or do you go ahead and start into the level editor hoping that tinkering around with the editor will unlock the secrets of the unknown data.

Now sometimes it actually is way too soon. I have almost completely reversed a 3D model format but the animation files that these models use is a brick wall that I just can't break through. It'd just be a waste of time coding a model ripper without the animations to go with them.

But with levels there is so much more going on. Do you really need to know how switches effect doors, and how to control the path followed by floating stones, etc., Before you start coding a level editor? Most of the time you can get by just fine without those features.

So I guese my question boils down to this:

Sooner rather than later? Or slow down there young padawan?

I usually start coding my tools when I think I got most of the stuff figured out or when I begin losing motivation to continue reversing the format; if it's taking too long for instance. \

I rarely predict every possible scenario in a compression algorithm or custom format, so having the chance to start extracting/inserting stuff early on helps me a lot to understand the whole picture.

So I definitely prefer sooner than later but to me it's also a matter of keeping things fresh; if you have been reversing the format for a long time it might do you good to take a break by coding what you already know.

Even if you end up starting over at some point after realizing your first approach just doesn't work for certain features you discovered later on, you can make it much better this time around with the experience and first-hand knowledge you already got. Even with all information available beforehand I'm sure one can still easily fall into a design trap that requires a complete rewrite. Things like that just happen.

Yes, it's fine. You can do what I do, which is start making crappy tools and learning as you go along. Eventually your programming skills will be good enough to create an efficient and optimistic level editor, which is what too many people seem to can't do (Like making poor GUI decisions and doing things with poor speed. Just so you know, x.SetPixel is a bad way to go). Then, finding data is the next part. When I started working on my Zelda Oracle(s) (of Ages) level editor, I barely knew anything. I didn't know how the maps or graphics compression worked, and over a few days and tons of debugging I actually got somewhere. Then after more debugging, I found things like warps and such and created more as I went along.

Basically, don't ever go building a level editor off of someone else's data finding unless you can actually build something very good and worth using and your data finding skills suck. You'll find it creates a lot more confusing and less flexibility in the future.