Sometimes the in game editors can trick you a bit but yeah they are nice to have. Similarly if the wifi had provided bonus levels (things like Picross and professor layton being examples) then that also can help.,
The ways levels get constructed in games varies infinitely but it does usually boil to a handful of concepts.
1) All in one, tends to be for simpler games like your basic maze or something.
2) Base level, objects map and possibly another for enemies. Tends to be for anything vaguely complex. The following is actually for a 3d game but does show things well enough http://treeki.rustedlogic.net/romhacking/docs.html
3) Normally seen in 3d stuff where you get an overlay on top of a graphics file. For the DS then the Mario Kart kcl files are a good example. Mario Kart itself has full 3d worlds but no concept of where anything is from the 3d alone so it has those files to tell it where the track, the dirt and completely off the level is. Not so common in 2d any more as sprite collision detection is doable within the hardware on most systems.
Anyway if there are not another bunch of files, or a simple file with it all in named hopefully fairly obviously (or able to be discerned by elimination)
Time for some maths thenhttp://problemkaputt.de/gbatek.htm#lcdobjoverview
covers how to fully define a sprite location. If the game set that as an initial condition then as "Each entry consists of 6 bytes (three 16bit Attributes)" we can start.
6 bytes * 20 items per level (possibly a bit high when looking at that video but I am OK with that) * 256 levels = 30720 bytes, or about 30 kilobytes. Multiply that by 4 for reasons (it has to say what the object is, maybe does not want to pack it all tightly) and you have 120 kilobytes of what could be considered key game data, for a system with 4 megs of RAM. To that end there might well be a massive table somewhere in the binary (usually called arm9.bin in things that extract DS ROMs), an overlay or even a standalone file.