Funny how this is one of the most neglected subjects on the net. No ones seems to have covered some different techniques to simply entities and compilation.
But Claustrophobic Irony is different, it has been called a "next level" engine, because of the planned features it will support. I have been designing the engine for a bit, and have for "finally" moved to code (I have actually moved to code before, but stopped, and realised that something better is available. But CI is near close to the peak for now). It also will handle it's levels nearly totally different to any engine I know of.
As mentioned, in the news on my page, I will be compiling my levels into .CPP files, in OCTREE form, using my native geometry classes. They will then be compiled to .DLL files, or whatever, depending on the OS. The important thing about this, is that using my pluggable .DLL system, I can load normal CI levels, or Pluggable imported files or whatever. I can also add new geometry features directly into a level using a loop call back for LOD and such.
In fact, having this method means I can create backwards compatable file types, and just add extensions to support new features. Say a new type of curve, or trigger, can be compiled directly into the .DLL. Triggers and level hooks also exist in machine code, so they can happen much faster.
Also, no parsing has to occur at runtime, which in many cases will speed up load time. Also importantly, more than one level can be compiled into a .DLL, and switched rather quickly. This means that games such as hexen 2, which switch levels rather often, wouldn't always be hampered by the "loading" signs. It would also enable multiplayer-multilevel games to occur, with an accurate server system.
But before being in .CPP, they will probably be in a simple ascii or binary format... I was going to use quake .map files, as they are very easy to handle, but instead I decided that it would be better to use my own level format, as .map, although very widely supported, and easy, has many limitations that do not exist in CI. Also, it relies on that crappy system of sub-spaces which IMHO is far too restrictive. CI will allow for fully free triangle + convex polygon world, and there for is not suited to such worlds. Also, most free ware modellers, which do support this are not that great. So, I will create my own modeller which will support both CI models and levels. Models being different, as they have a skin, instead of multiple textures.
This demonstrates my points, that A) It is best to make a level format, or use a format that suites your engine, especially one that doesn't add limitations that your engine doesn't have B) Don't be afraid of doing something different and C) Innovate, and see if you can use your level file format to add features, not detract.