No, sorry, that won't happen any time soon (if at all). The problem is that we don't have control over the compiler, in fact, it's not even one compiler. Windows uses MSVC, Mac and iOS use LLVM/Clang and Linux and Android use GCC, so adding this into the compiler won't happen from our side. The other solution for this would be a custom pre-processor, which would force the user to run their script through it before handing it over to their compiler. This can be done by having the user explicitly call the pre-processor, or we do this on their behalf from within a custom editor, and we will certainly not provide a custom code editor. Nothing that we could come up with can compete to Visual Studio or Xcode, and forcing the user to use an inferior editor instead of a preferred one just for the sake of a few macros... Hell no. And we don't want to force the user to run their code through an intermediate program, we want them to be able to hit build and run in their IDE and get going.

Rayne is all about not standing in the way of the user, and implementing new language features would mean that we do have to get in their way, and that is not worth the marginal gain of comfort.

So yeah, long rant, but I hope that clarifies why we won't be able to provide such a solution.


Edit: Btw, a few points:
"Basic data types": We provide data types with fixed length that work across platforms and architectures (x86, x86_64, ARM)
"Specifying Default Values for Class Members": That's a C++11 feature
"16-bit (Unicode) Characters and Strings": Rayne has something better: A string class that is input agnostic. It can work with ASCII strings, utf8, utf16 and utf32 (eg. because you want to use UTF16 for asian strings because in UTF8 most asian characters are a 3 byte sequence), and you can work with them interchangeably (the string class takes care of transforming its internal storage if needed). It also gives you a ton of connivence methods to work with the encapsulated data.
"Accessing Base Class": There is no __super in C++... That doesn't work because of multiple inheritance, and even if it did, you should know what you inherit from.



Well, we do have a level editor, which generates a custom format, but there is no compilation step. Modern hardware can deal with dynamic scenes, there is no need to have offline compilation of levels, unless you explicitly want to piss of the user. I mean, sure, there are still cases where a compiled level makes sense, eg. to precompute light maps, but there are tools for that.

Now, I know you asked how levels are build up, but as a good marketing PR SEO master shenanigans talker, I would like to talk about Rampart Scenes for a bit: Rayne doesn't force you to use a scene manager. I mean, it does, but it doesn't force you to a specific one. Your game might be a minecraft clone with lots of equally sized blocks, an ABT(ree) can go fuck itself in such a case, what you really want is a spatial hash in such a case. Likewise, there are levels where an octree kicks ass, and levels where you may want to use an AABB tree. Bottom line, there is no silver bullet, and forcing the user to something doesn't do any good here. So Rayne lets you choose what you want, and it allows you to create a custom scene manager. A scene manager is really just an extension to the scene itself (encapsulated in a World object), while the world does the heavy lifting when it comes to scene node management, it also acts like an event tap for various kinds of attachments to it, for example the scene manager. It's plug and play, and the documentation tells you what scene manager you should use in what scenario.

And besides of that, just throw your scene nodes into the world, or place them in the editor. The entities are asset agnostic, meaning you can plug your own resource loader into the engine, tell it how it can identify your files (or provide your own predicate), and then just create an entity and point it to the file.
The custom model format was really just for the beginning so that we had something to get going that was easy to parse and load, model files are a huge bitch. But there are going to be more supported formats.