Camlorn I gave you a +1 for this statement alone.  There are a lot, and I mean a lot of people who don't seem to understand this.  Audio game developers jump languages, swear by languages, and condemn languages all based on performance problems that were really due to how they coded their projects, and not the languages themselves.  Well said sir.

I've tried making an editor for aspects other than just the map (one of these attempts got far enough I could conceivably upload it? Eh, might as well. My plan was to add projectiles and upload it within a week or so of where it got cut off for external reasons, anyway).
And, well, it comes down to pretty much what Camlorn said. Editing the map is simple; editing anything else ultimately reverts to editing properties with menus, which might as well be coded by hand. And this doesn't even get into events or anything of the sort.
(I went ahead and upoaded it, since you asked. Warning: includes my crappy sounds from the time, + Swamp's Footsteps, + terrible, terrible voice clips made with Sam, Mike and Mary. Did I mention this was from 2012?)

Having said all that... I think we can still come up with something better, given sufficient time/effort/creativity.

The only reason I see at all to use LLVM is speed.  Otherwise, you're bringing in a huge amount of complexity for nothing.  Pick a language and use it for the engine.  Pick another language (possibly the same one) and use it for letting the user program.  Do not write your own, and do not even think about LLVM.  You will spend an astronomical amount of time writing your compiler and getting all that working, or you can just spend an afternoon or a couple days to figure out how to obfuscate.  Why do you want LLVM so badly?
there's two answers to the question of why you're making an engine.  Either you want an engine or you want to have a project that never ends and gives you an outlet for learning.  The former means no LLVM.  The latter means that asking questions about what technologies you should use is kind of pointless because the question is which technologies you want to learn.  But only the former will give you something in any reasonable amount of time.

Why?  Is this a learning project?
We probably have very, very different definitions of executable compiler.  You can get very, very far by distributing an executable that looks for main.bytecode in the same folder as itself and runs that.  If you truly must have a single-file executable, require the user to install a C++ compiler, use any of the scripting languages that C++ can interface with, and spit out a C++ file that embeds the source as a string.  To get around people yanking it apart with a debugger or hex editor, that string can be bytecode or base64 encoded or encrypted or base 64 encrypted bytecode or something even more esoteric.  But the statementrs "I need a single-file executable" and "I need to write a compiler with LLVM" are not linked at all.
If the question is "how do I write a compiled programming language?" that's an entirely different conversation.  I can point you in the right direction, but it comes with a disclaimer that it's basically pointless these days.  Pick any set of characteristics you want in your programming language, and you can almost certainly find a language that has all of them.  Compilers are the domain of learning or programming language researchers and can serve as a stepping stone to working on LLVM or Pypy or something, but don't serve so much of a purpose in themselves.
If I had to suggest anything, I'd suggest a modified Python interpreter and Py2exe.  You can mod the interpreter to read/write encrypted .pyc files and compile Py2exe against it, or just screw obfuscation and use Py2exe until much later in the project.  This will possibly stop a very few C extensions from working, but shouldn't hurt anything major.  But this is my bias, and isn't a strong recommendation.
If the project were done and you were going to release tomorrow, what would you say?  What are the features?  Why do I want to use it over BGT or Python or C++?  Until you answer these questions for us, I can't strongly suggest any approaches.  I suspect no one else can either.  If this is just a learning project, that's a fine answer. If it's not, tell us what problems you hope to solve with it.  We can move from that to implementation concerns.  Going straight to implementation concerns is just going to go in circles all day long.  Laying this out is the next step for this thread.  I've seen other threads by you about this and you're always able to list short-term goals.  But I have yet to see anything long-term or anything that resembles a "and when we get here it is 1.0".  Do not consider programmer skill, this is purely about what you would want to have if you were the best programmer ever.  We can remove stuff that's too out there later.

A home-brew compiler isn't the answer: if you're looking for community contributions, then a compiler is too complex.  Not to mention the fact that it's going to be ugly and hard to understand, at least unless it's something you've done before.  Most worthwhile contributions aren't going to be done via the engine, they're going to be done in the engine.  This is an important point to think about.
But you've still not answered the question.  I can provide at least 50 different definitions for game, varying mostly according to  supported gameplay features, and at least  3 different definitions for engine.  In order to discuss this we need more.
let me put it another way.  Bare with me on this, because it's important.  Accuracy to reality is not the point: I know that, by the definition of community contributions, it's intended to be free.  But we're visiting fantasy land for a moment.
You are the CEO of a company and you've just developed your amazing and commercial audiogame engine.  Bob Smith comes along and asks you "Why should I buy this? I've already got x, y, and z".  What do you tell him?  What does your engine, now that it is finished in some sense, let our imaginary consumer do?  Your goal is not to portray your company's values or your personal opinions.  Your goal is to tell Bob why he cares.
Once we know why Bob cares, we can talk about how to get you to that point.  This is not something unique to this thread.  Other people do this.  Libaudioverse did it, though less explicitly: I knew from Camlorn_audio what people wanted and couldn't get, and I knew what I wanted and couldn't get.  I did not do this for Camlorn_audio, and now I've got several thousand lines of abandoned code.  Before I even wrote a single line of code for Libaudioverse, I had answered the question as to how my imaginary Bob Smith would program with it, and what it would let him do that he couldn't do elsewhere.  This particular idea is not unique to me: imagining the imaginary customer is a pretty standard thing, even at places like Microsoft.
And don't make the mistake of thinking that your engine is free.  It's not. It might not cost money nor get you anything, but it's going to cost Bob time and effort to learn it and transition from what he used to use.  And so in this sense Bob had to pay.
Saying "community contributions are good" and "lets people make games" is broad.  So broad that assembly language fits in some sense.  With those two statements together, you could use literally anything.  Because of the nature of your project, you need not be concerned with being friendly to other programmers from the community: any programmer who can't learn more than one language is probably not at the point of being able to write robust, reusable code for other game developers.
And, to be honest, your project won't get far without more definition.  If I say anything goes, then everything goes.  And the project collapses from its own weight and complexity.  The input library has 10 special cases for everything from card to rhythm to first-person shooters, all in different coding styles and uncommented.  Saying what your project is also says what it is not and, from that base, lets you know what you can and must exclude.

I was considering flex and bison when making my compiler comments.  I do not know anyone who doesn't use those or a similar tool these days; there are advantages to recursive descent parsers, but they're a lot more work to write.  Flex and bison probably aren't even the best thing on the block these days: compilers can be written in hgher-level languages, and there's a lot of other options.  This is because those tools aren't just for copilers, even if that is their most common association.  If you're trying to write a compiler without them, you've gone from hard to hell-in-life, or something we don't have an adjective for.
Even with flex and bison (or similar), the top companies in the world recruit the top computer science people in the world, pay them huge quantities of money, and throw them at a compiler.  5 or 6 years later, it's worth using.
I'll be completely honest.  You can get a compiler, in the sense of compiling hello world.  This can happen around the same time you're ready to make your first audiogame.  yay, you say!  It compiles.  But your work is only 1% done, because you're probably not anywhere near doing error messages right (VC++ has somewhere around a thousand), you're going to need an optimizer (usually a grad-level compiler course), reimplement all the tools (ever wanted to know everything about your processor?  yeah, thought not.  Too bad you need to implement a good debugger...).  You'll be refactoring like crazy: you can compile the print statement, but even adding the function restructures the entire internals of the compiler, and hello there Mr. Class, fiend of the extra 3 weeks of recoding things.  Or you could spend 4 or 5 hours learning to embed a scripting language or something of the like (I'm almost sure you can find a compiler for some language or other as a library.  No telling which language, though).  Quality compilers are hard.  Really, really, bone-crunchingly hard.  And that's not even talking about language design--if you're just copying another language, then use the other language; otherwise, you need to invent your own and most things that you can think of can and have already been done for you.
In terms of code in general?  Comments are nice for new programmers, but the need of them lessens with programming skill; most big code-bases don't have them nearly as much as one would expect.  The best thing you can do is establish and stick to style guidelines  What you choose doesn't matter so much as being consistent: I should be able to tell if x is a function, variable, or whatever by lookinga t how you styled its name.  personally (C++), I use underscores and lower case for global and class variables, camelcase with capital first letter for types, underscores and all-caps for constants defined with macros, and camelcase with lower-case first letter for functions.  I follow them draconically.
And here's the biggest one.  The game engine is not the place for a new coder to contribute.  The game engine must contain the best of the best in terms of features and code quality; it's not one game, it's hundreds, and any flaws are going to affect orders of magnitude more people.  This is probably the hardest part of the whole thing.
I can be more focused once you give me what I'm asking for: a description of why Mr. Bob Smith cares.

That this sounds like BGT, and I don't see why you wouldn't just use that.
In terms of 3D audio, I'm pretty sure I'm the only person on the block for anything under $10k, and it's not ready.  It's close enough to ready that you can get it running, but it's not ready.
As for actually doing this, there's not much point unless it's more than a scripting language with easy libraries.  In that case, just develop the easy libraries and don't even worry about the rest: whether I have to do "import magic_audiogame_engine", "using magic_audiogame_engine", etc, isn't a big deal.  And it avoids a ton of stuff.
My current methodology is what I call library-driven development.  I develop libraries as I develop projects.  The intent is that they're separable: audiogame_engine is the core part of any game (use pyglet, it's deprecated because I didn't know pyglet existed) but really it's also half the code to a space invaders.  Once you've got 10 or so of these handling everything you need, you've done it.  Just release them all separately, or as an installer that installs them all, or whatever.
Python is a bit hard to distribute, but if you're going to develop the distribution component for people that doesn't matter so much.  Ironically, C++ is probably the easiest: statically link the runtime and all the libraries in, and you're done.  You don't even need an installer.  In the middle is something like LuaJit, Angelscript, etc: you don't have some of the distribution complexities of Python, but you do have to develop the entire host environment (so not really a fair trade-off).  I'm not saying that C++ is really on the table: C++ is a horrible thing for new and old coders alike.
In python, adding the following things to your mixing pot gives a full game engine.  No coding is required, save perhaps for distributing.  Pyglet (graphics, sound), pickle (built-in and can serialize anything), SQLAlchemy (talk to databases), requests (talk to web servers, i.e. scoreboards or update checking), any of several astar implementations (pathfinding), either PyBox2D or PyODE (the former is better. Solves the collision checking problem), and maybe blist (faster containers in a profound way i can't go into via a parenthetical note).  What might be left is writing easier wrapers on top of these, but I can't think of a game that needs something that list of Python packages doesn't offer.  Other languages have similar and equally effective combinations-the fact that I can't tell you what c# needs means simply that you need to Google, for example.
If we want to talk about the Unity road, we get to talk about inventing interfaces that don't even exist yet.  I don't think you're talking about that, but feel free to correct me.

I'm not saying use Python.  I'm not sure why so many blind people are against Python, but there are plenty of other languages that are just as good as it.  My list of packages applies to Python, but was merely an illustrative example: similar lists can be compiled with almost no effort for any of the top 20 programming languages in the world.  Even PHP has realtime audio output (yes, really.  It's disturbing).  I also said to explicitly not use C++ because even experienced coders hate it.
I am saying don't use LLVM.  I'm not sure how you're thinking you can somehow get LuaJIT and LLVM in the same project-not only are they not really compatible, the JIT in LuaJIT means that it's just-in-time compiling.  So LLVm isn't part of it, because you've got a just-in-time compiler.
Distributing a single executable and having a compiler are not synonymous.  Just use some basic encryption.  Really.
So since you want an opinion, don't use LLVm.  Not only don't use LLVm, put LLVM inside a big fortified fortress with giant hazard signs on it.  I think that you probably aren't clear as to what LLVM is for.  LLVm is the nuclear bomb for your project.  If you go down the LLVm road, we'll maybe see you in a few years with a project.  If you pick an embedded scripting language, we'll see you in a couple months.  If you just do what I said and pick some language that already exists with a full-fledged compilation and distribution system, you can have the libraries you need installed in an hour with identical functionality as the other two approaches.  If you still need to make it more newbie friendly, write simpler libraries on top of those-you can do one a day, easily, which gives you a project in a few weeks but also gives you something useful and ready and able to be used in a real game in a couple hours.  It also lets the user add literally anything that you don't provide because someone outside this community has already written it and all they have to do is install it.  I'd be willing to bet a very large sum of money that a library exists for every possible Audiogame-related development task that anyone cares to name.  This is especially true of C++, C#, and Java.
if someone has a truly good reason for disagreeing with me, say so.  But this kind of thing is close enough to fact that I'm hesitating to say "my opinion" at all here.  The only reason *not* to go down the road of preparing a list of preexisting libraries and bundling them together as a super-library package is to learn something.  Literally the only reason.  Sighted people use exactly the same stuff as you, so you've got a pool of programming talent that's probably 100000 times larger than the one on this forum.  And they've already done your project.  Completely.  There's nothing left.

@visualstudio, I do not recommend you make a compiler at all. For now, just have an interpreter. A compiler isn't actually needed yet. Wait until your very good with assembly language, machine language (I know, but its required to assemble a game into direct machine code without use of an already available assembler), or, if you are able to use assembly, find a good assembler (I recommend NASM), and then use that instead. Simply have your interpreter translate the game into assembly language and have NASM assemble it. Below, I have an example hello world program in NASM:
This is a Hello world program for the DOS operating system.
section .text
org 0x100; semicolons are comments and ignored. 0x100 is 256 in our decimal system.
    mov    ah, 0x9
    mov    dx, hello
    int    0x21

    mov    ax, 0x4c00
    int    0x21

section .data
hello:    db 'Hello, world!', 13, 10, '$'
An example of a similar program for Microsoft Windows:
global _main
extern _MessageBoxA@16
extern _ExitProcess@4

section code use32 class=code
_main:
    push    dword 0      ; UINT uType = MB_OK
    push    dword title  ; LPCSTR lpCaption
    push    dword banner ; LPCSTR lpText
    push    dword 0      ; HWND hWnd = NULL
    call    _MessageBoxA@16

    push    dword 0      ; UINT uExitCode
    call    _ExitProcess@4

section data use32 class=data
    banner:    db 'Hello, world!', 0
    title:    db 'Hello', 0
An equivalent program for Linux:
global _start

section .text
_start:
    mov    eax, 4 ; write
    mov    ebx, 1 ; stdout
    mov    ecx, msg
    mov    edx, msg.len
    int    0x80   ; write(stdout, msg, strlen(msg));

    mov    eax, 1 ; exit
    mov    ebx, 0
    int    0x80   ; exit(0)

section .data
msg:    db    "Hello, world!", 10
.len:    equ    $ - msg
For X64 processors:
section .text
org 0x100
    mov    ah, 0x9
    mov    dx, hello
    int    0x21

    mov    ax, 0x4c00
    int    0x21

section .data
hello:    db 'Hello, world!', 13, 10, '$'
An example of a similar program for Microsoft Windows:
global _main
extern _MessageBoxA@16
extern _ExitProcess@4

section code use32 class=code
_main:
    push    dword 0      ; UINT uType = MB_OK
    push    dword title  ; LPCSTR lpCaption
    push    dword banner ; LPCSTR lpText
    push    dword 0      ; HWND hWnd = NULL
    call    _MessageBoxA@16

    push    dword 0      ; UINT uExitCode
    call    _ExitProcess@4

section data use32 class=data
    banner:    db 'Hello, world!', 0
    title:    db 'Hello', 0
An equivalent program for Linux:
global _start

section .text
_start:
    mov    rax, 4 ; write
    mov    rbx, 1 ; stdout
    mov    rcx, msg
    mov    rdx, msg.len
    int    0x80   ; write(stdout, msg, strlen(msg));

    mov    rax, 1 ; exit
    mov    rbx, 0
    int    0x80   ; exit(0)

section .data
msg:    db    "Hello, world!", 10
.len:    equ    $ - msg
I know, it looks complicated, but its actually quite easy. Of course, after the assembly is done, have the program link it with ld or some other linker. Do not try and design your own linker!

instead of using nasm, we can use inline assembly in C++
but, how to create an interpretor for that?
i'm learning LLVM!
if i want to use lua, i can use LLVM_lua for this
but i havent found anything for AngelScript
i know assembly and that's not have so much problems, but when the project becomes bigger and bigger, it'll be harder than to use assembly for that
C++'s inline assembly is better i think, because you can mix C++ and assembly together

so, if LLVM isnt good, what do you recommend?
how to make an interpreter?
this thread is started, for just 1 reason that i've mentioned